Remapping phase

[Per Liden]

Hi,

On 10/17/19 5:55 PM, Simone Bordet wrote:
> Hi,
> 
> 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)
> marking phase.

Correct.

> 
> 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?

Walking the entire object graph is a very expensive operation, so if we 
can do that only once per GC cycle, we've saved a lot of CPU cycles. In 
most (close to all) cases, the application will not touch the entire 
object graph between two GCs, only a smaller subset. Having the Java 
thread remap a reference is not terribly expensive and will only happen 
once per reference, as it self-heals. We then let the next marking phase 
(when we have to walk the entire object graph anyway) remap the 
references that the Java threads didn't touch.

I'm curious, since you're asking, do you have a real world workload 
where you suspect letting the GC immediately remap the entire graph 
would actually pay off?

cheers,
Per

> 
> Am I missing something?
> 
> Thanks!
>