CRR (M): 7127706: G1: re-enable survivors during the initial-mark pause

[Tony Printezis]

Hi Bengt,

Inline.

On 1/19/2012 3:39 AM, Bengt Rutisson wrote:
>
>>> why is it not enough with the normal -XX:+PrintGCTimeStamps 
>>> information? 
>>
>> Not quite sure what you mean with "is it not enough with the normal 
>> ... information". Each log record needs either a GC time stamp or a 
>> GC date stamp and we have to print either or both depending on the 
>> two -XX parameters. Unfortunately, the logging code has not been well 
>> abstracted and/or refactored so we have this unfortunate replication 
>> throughout the GCs.
>
>
> Sorry, this was a misunderstanding from my side. I have never really 
> thought about how the time stamping was implemented. I could not 
> imagine that it was implemented as three different print statements, 
> so I thought you were doing something extra here. I realize now that 
> this is the "normal" time stamping.
>
> Stating the obvious: We desperately need a new logging framework!

+1

>
>>> Finally, just some food for thought. Could this be generalized to 
>>> more roots? I mean take a snapshot and scan it concurrently.
>>
>> By scanning the IM snapshot regions we say "these guys are all roots, 
>> instead of scanning them during the GC we will scan them 
>> concurrently". And we can do that for any object / region a) as long 
>> as we know they will not move while they are being scanned and b) 
>> because we have the pre-barrier. If any references on the snapshot 
>> objects are updated, the pre-barrier ensures that their values at the 
>> start of marking will be enqueued and processed.
>>
>> For external arbitrary roots we don't have a write barrier (and we 
>> shouldn't as it'd be too expensive). So, we cannot do that for 
>> non-object roots without a "pre-barrier"-type mechanism.
>
> But if we have roots that do not change between initial mark and the 
> first young GC we could do it without the pre-barrier, right?

This is indeed correct. However, also note that those roots might also 
point into the collection set so we have to scan them during the 
initial-mark pause anyway. So, might as well mark what they point to. 
Having said that, we can somehow tag roots as "non-young" after we know 
they do not point into the young gen so that we don't have to scan them 
during subsequent young GCs. If we know that they also don't change, we 
could scan them concurrently.

> I'm thinking of classes for example. But then again there is class 
> redefinition, so maybe they can change...

Again, this is a good point. We can talk with the folks who are working 
on the perm gen removal project to classify (if they have not already 
done it) which refs on metadata can be updated after a class is 
initialized and which cannot. There might be some opportunities for 
improvement here.

> Anyway, not something we should do now, just wanted to mention it.
>

Agreed. And I have to say the first phase I'd try to optimize would be 
the remark (do it mostly concurrently), not the initial-mark.

Tony