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