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

John Cuthbertson john.cuthbertson at
Thu Oct 6 16:29:28 UTC 2011

Hi Everyone,

I think the template interpreter uses the names notice_safepoints() and 
ignore_safepoints() so in the same vein: NoticeSafepoints and 


On 10/06/11 07:27, Tony Printezis wrote:
> Ramki,
> Thanks for your thoughts on this. Please see inline.
> On 10/6/2011 2:41 AM, Ramki Ramakrishna wrote:
>> Doing some late night  loud thinking here ... so please take this
>> with an adequate dose of salt....
>> I am not sure joining or leaving the suspendible thread set
>> says anything about the actual intent of that action. In other words
>> the suspendible thread set is a mechanism or an implementation
>> of what is actually a synchronizing mechanism -- the intent is
>> that the actions in a {join; act; leave} scope are those that
>> want to somehow control the synchronization points of their
>> execution wrt safepoints because safepoints will probably
>> step on their toes or manipulate the same values. It's
>> really a form of mutual exclusion.
> Either way has pros and cons. I agree that abstracting away from how 
> the exclusion is implemented is helpful for someone who's not familiar 
> with the code. However, I'd claim that it's also important to show 
> that we're using the STS in this exclusion so that the reader fully 
> understands what the assumptions of the exclusion are and also because 
> they might need to explicitly yield at some point, which is done 
> through the STS.
> Let me predict what someone will say next: Ah, but we can also wrap 
> the yielding call in those nesting (is that the right word for them?) 
> objects too. Which would be nice. But there are cases where the call 
> to yield() (or the call to should_yield()) is deep into the call 
> hierarchy that's impractical to use the top-level nesting objects for 
> that.
> Also please note: (For better or worse) MutexLocker x(&my_mutex) is 
> very explicit in what it does. It doesn't say "we provide mutual 
> exclusion of that critical section using the given mutex". It says 
> "we'll keep that mutex locked during this critical section". 
> Unfortunately, I cannot think of a similar name for the case we're 
> discussing here.
>> In the same vein, the reverse namely {leave; act; join} seems
>> to be an explicit mechanism to get out of a synchronizing protocol
>> wrt safepoints (in this case presumably because such synchronization
>> would otherwise cause circular dependencies that might result in
>> a deadlock).
> This is indeed correct.
>> Thus while the suspendible thread sets is a specific implementation,
>> the high level idea involves synchronization wrt JVM safepoints
>> during which foreground gc's may do stuff to the same structures
>> that the wrapped actions are manipulating.
>> It is for that reason that I had suggested the name 
>> "SynchronizeWithSafepoints"
>> although that is not an adequate name either. 
> I understand what "synchronize with safepoints" tries to convey (i.e., 
> "synchronize with the safepoint mechanism so that a safepoint does not 
> happen without my consent"). But it's a bit too high-level to cover 
> all the assumptions related to that mechanism.
>> (Perhaps your
>> suggestion of a name that describes the mechanism/implementation
>> may be better suited because of the inadequacy of my suggestion.)
>> Hopefully someone will think of a better name than either of these.
> So, if we want to keep it high level, how about IncludeSafepoints / 
> ExcludeSafepoints or WithSafepoints / WithoutSafepoints? But I have to 
> say my preference would be InsideSuspendibleThreadSet / 
> OutsideSuspendibleThreadSet.
> Tony
>> -- ramki
>> On 10/5/2011 5:52 PM, 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:
>>> {
>>>   JoinSuspendibleThreadSet x;
>>>   ...
>>> }
>>> Both sound very descriptive to me. Alternatively, maybe 
>>> InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet?
>>> I'd love to have something like MutexLocker / MutexUnlocker but I 
>>> can't think of an appropriate noun 
>>> (SuspendibleThreadSetJoiner?!?!?!? this sounds SO wrong!).
>>> Tony

More information about the hotspot-gc-dev mailing list