Cleanup stacks in pc group collection code #2461
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The first commit is motivated by the Julia GC work: the classic pc group collected code in the kernel (ab)used T_PLIST_EMPTY resp. T_STRING objects to store various stacks, but overwrote the length slot with garbage in the process. We change it to use a T_DATOBJ, and take care not to overwrite its type slot.
The second commit adds in-kernel stacks for the "new" pc(p) group collector, used by the polycyclic package. Right now, every pcp group collector has its own set of stacks, resulting in collector objects which are several hundred kilobytes big. This is a crazy waste if you have many collectors around.
TODO: more tests; and in order to allow polycyclic to smoothly transition away from the stacks-in-collectors, we need to add a way for it to find out when it can do that. I guess I'll just add a constant
NO_STACKS_INSIDE_COLLECTORS
or so, and then make a polycyclic release using it to disable the stack if it is set to true. And once that happened, we can think about removing the relevant constants likePC_WORD_EXPONENT_STACK
from the kernel...