-
-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor arena & pool guards and logs #700
Conversation
🤖 Upon creation, pull request description does not have a link to an issue. If there is a related issue, please add it to the description using any of the supported formats. |
- Instead of more generic "flags" enum, use more specific "guards", so that it's easier to understand the purpose - Use separate flag for each type of guard - Extract method that increments failure counter and checks if panics are enabled for a guard - Use same logging format as in MemoryLimiter
//! Default memory pool guards. | ||
enum { | ||
SlabPool_DefaultGuards = | ||
(SlabPool_LeakGuard | SlabPool_OverflowGuard | SlabPool_OwnershipGuard) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With HeapArena, we don't want leak guard being the default, but, over here, we're ok with that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes,
We would enable it for heap arena too, but when roc is used from a C library, some allocation & deallocation requests come from the user. We don't want to crash user's app if user decides not to free some resources upon exit, for example. So leak detection is disabled by default and is enabled explicitly in tools and tests.
All requests to pool, on the other hand, are controlled only by us, so we can place stricter defaults.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one!
Thanks for review! |
Instead of more generic "flags" enum, use more specific "guards", so that it's easier to understand the purpose
Use separate flag for each type of guard
Extract method that increments failure counter and checks if panics are enabled for a guard
Use same logging format as in MemoryLimiter