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

[Tony Printezis]

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