CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances

Tony Printezis tony.printezis at
Thu Oct 6 14:03:20 UTC 2011



On 10/6/2011 2:28 AM, Bengt Rutisson wrote:
> Tony,
> Looks good to me. Thanks for adding the extra comments in 
> ConcurrentMarkThread::run(). They will be very useful when getting 
> back to this code.

Of course, that piece of code has some interesting races even though it 
looks quite straightforward. IIRC, we had at least one assert failure 
and one deadlock there in the past.

> Some comments on the email discussion inline...
> On 2011-10-06 02:52, Tony Printezis wrote:
>> On 10/5/2011 8:27 PM, Tony Printezis wrote:
>>>> [1] you will have to invent a suitable other name, perhaps 
>>>> DesynchronizeWithSafepoints
>>>> for when you do the reverse, i.e. perform an action outside of the 
>>>> _sts, as happens
>>>> when you are doing those synch barriers amongst the concurrent marking
>>>> threads in case of overflow and restart.
>>> I can't think of a good name off-hand but I'll think about it for a 
>>> bit... (suggestions are welcome!) 
>> How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, example:
> I like JoinSuspendibleThreadSet. It seems natural. I understand where 
> LeaveSuspendibleThreadSet is coming from, but just seeing it by itself 
> on a code line will give me the wrong impression - I think. It sounds 
> so active, whereas I assume it will have to include some potential 
> waiting for other threads to leave a safe point, right?

Indeed, when a thread leaves the STS it has to wait for a safepoint to 
complete, if there's one in progress.

>> {
>>   JoinSuspendibleThreadSet x;
>>   ...
>> }
>> Both sound very descriptive to me. Alternatively, maybe 
>> InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet?
> I actually like InsideSuspendibleThreadSet / 
> OutsideSuspendibleThreadSet better. It indicates what you really want 
> to achieve with the code block.

I think I like that a bit better. I'll also suggest an alternative when 
I reply to Ramki's e-mail.


More information about the hotspot-gc-dev mailing list