steveblackburn
commented
4 years ago This needs clarification.
Although the words "going to be" above suggest some kind of feature add or change, actually this (and mmtk/mmtk-core#73) is just a bug fix.
Allocation slow paths have always been, and still are allocator-specific, not mutator-specific. They are part of the respective allocators (eg bump pointer, and LOS).
The fast path of the mutator's allocation sequence does two things (and has done so since the early days of MMTk):
- It uses a switch statement (which is usually compiled away) to select the concrete allocator required according to an argument to the alloc function.
- It calls the fast path of the respective allocator (for example, the fast path of the bump pointer or the fast path of the free list). This call is inlined, and the switch statement gets compiled away, so in fact the fast path at a given allocation site consists of just this step.
After the switch statement, we've moved from plan-specific code to allocator-specific code. So if the selected allocator is a bump pointer (immortal space, say), then if that fast path fails, it calls the bump pointer slow path. Whereas if the selected allocator is a free-list, then if the fast path of the free list fails, it calls the free list slow path, etc.
For whatever reason, the above was not correctly implemented. So instead of the allocator directly calling its slow path as was originally written (bump pointer, free list, LOS, etc), for some reason the slow path went back to the mutator, re-did the switch in step 1 above and then called the allocator slow path. (aside: the LOS allocation is by definition heavyweight, so the slow path and fast path are the same thing).
qinsoon
As of https://github.com/mmtk/mmtk-core/pull/73, the slow paths are going to be specific to allocators. JikesRVM binding needs to be changed to reflect this new structure