RFR (S): 7129271 G1: Interference from multiple threads in PrintGC/PrintGCDetails output

Bengt Rutisson bengt.rutisson at oracle.com
Mon Jan 16 10:47:02 UTC 2012


John,

With the doConcurrentMark() call just before the "return true" statement 
I think this looks good too.

Nice that it no longer conflicts with my marking cycle changes for 
humongous object allocations. :-)

Ship it!
Bengt

On 2012-01-13 18:48, Tony Printezis wrote:
> Thanks John, ship it. :-)
>
> On 01/13/2012 12:48 PM, John Cuthbertson wrote:
>> Hi Tony,
>>
>> Thanks. Good point. I missed the print_heap_after_gc() call. Consider 
>> it done.
>>
>> JohnC
>>
>> On 01/13/12 09:25, Tony Printezis wrote:
>>> John,
>>>
>>> Thanks for taking into account my feedback! My only comment is that 
>>> you should maybe move the doConcurrentMark() call to even further 
>>> down (i.e., as the last thing we do in that method before return 
>>> true;) given that there's still some output that can be generated 
>>> after its current location (e.g., PrintHeapAtGC).
>>>
>>> Tony
>>>
>>> On 01/13/2012 12:11 PM, John Cuthbertson wrote:
>>>> Hi Everyone,
>>>>
>>>> Based upon feedback from Tony, I have a much simpler version of 
>>>> this change. The new changes can be found at: 
>>>> http://cr.openjdk.java.net/~johnc/7129271/webrev.1/
>>>>
>>>> Thanks,
>>>>
>>>> JohnC
>>>>
>>>> On 01/12/12 11:28, John Cuthbertson wrote:
>>>>> Hi Everyone,
>>>>>
>>>>> Can I have a couple of volunteers review the changes for this CR? 
>>>>> The webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~johnc/7129271/webrev.0/
>>>>>
>>>>> The issue was that the when PrintGC or PrintGCDetails was enabled, 
>>>>> during an initial pause, the "concurrent-mark-start" message from 
>>>>> the ConcurrentMark thread was interfering with the output (by the 
>>>>> VM thread) from the GC pause. This was adding a randomness and 
>>>>> irregularity to the output that was making it difficult to parse. 
>>>>> It was also seen more frequently when the GC logging output was 
>>>>> directed to a file rather than stdout.
>>>>>
>>>>> The solution is to move the code that signals the Concurrent Mark 
>>>>> thread to after when the output from the GC pause is complete.
>>>>>
>>>>> In the webrev, please ignore the counts of the number of lines 
>>>>> changed. I added an inner scope and so indented a bunch of code 
>>>>> which I think has confused the webrev tool. Fortunately the actual 
>>>>> web diffs seem to have not included the extra whitespace.
>>>>>
>>>>> Testing: the GC test suite (with a low marking threshold - 2% to 
>>>>> create lots of marking cycles)
>>>>>
>>>>> Thanks,
>>>>>
>>>>> JohnC
>>>>>
>>>>>
>>>>
>>




More information about the hotspot-gc-dev mailing list