simone.bordet at gmail.com
Thu Oct 17 15:55:53 UTC 2019
I would like a clarification about when the remapping phase happen.
>From what I could lookup in the ZGC team presentations at conferences
and from a look at the code, it seems to be done during the (next)
I understand that there is no hurry to remap, as the load barrier
takes care of that, but this also means that the mutators will pay the
cost of remapping.
Worst case, after a GC cycle the application navigates the whole
object graph and remaps the whole heap before the next marking.
If remapping is done during the next marking, would not be worth to
have the GC doing it just after the relocation so that the mutators
won't pay the remap cost?
The remapping done by the GC could use the same roots from the STW
relocation start, and if something changed in the roots the load
barrier will still take care of the (few) remaps that were not done.
Is this a tradeoff to leave more CPU time to mutators, at the cost of
the mutators trapping the load barrier to remap?
Am I missing something?
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
More information about the zgc-dev