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

Tony Printezis tony.printezis at
Tue Oct 11 16:27:42 UTC 2011


I like the suggestion and I also like the version you recommended:

ParticipateInSafepoints x;
IgnoreSafepoints x;

Any objections to this?


On 10/7/2011 5:31 PM, John Coomes wrote:
> Tony Printezis (tony.printezis at wrote:
>> Ramki,
>> Thanks again for the feedback. So two votes for Regulate / Ignore so
>> far. :-)
> I discussed it briefly with John to clarify the concept, and we both
> used the same terms:  the threads usually ignore safepoints
> (safepoints do not wait for them, they keep running), but sometimes
> participate in safepoints (the safepoint waits for them to yield).
> I like ignore and participate.  Not sure how to best turn participate
> into a class name, though.  Possibilities:
>     {
>        ParticipateInSafepoints      xxx;
>        SafepointParticipator        xxx;
>        SafepointParticipationMark   xxx;
>        EnableSafepointParticipation xxx;
>        ...
>     }
> The first seems clearest.
> -John
>> On 10/6/2011 7:15 PM, Y. S. Ramakrishna wrote:
>>> On 10/06/11 11:23, Tony Printezis wrote:
>>>> Hi again,
>>>> Disclaimer: John and I IMed behind your backs. :-)
>>>> Y. S. Ramakrishna wrote:
>>>>> I think the "notice" / "ignore" here would be slightly different
>>>>> and use of the similar terminology may possibly cause some confusion.
>>>>> AllowSafepoints / DisallowSafepoints would perhaps be closer to what
>>>>> one is
>>>>> doing in this specific case.
>>>> Well, if I can be a bit picky too :-), DisallowSafepoints is not
>>>> totally true either given that the thread can allow safepoints to
>>>> happen but it has to do so explicitly with a yield call.
>>> True, as I indicated further below.
>>>> How about (and it'd be obvious that I resorted in consulting a
>>>> thesaurus):
>>>> RegulateSafepoints and IgnoreSafepoints
>>>> Both are descriptive in what the thread will do.
>>> Sounds good to me.
>>>>> If AllowSafepoints / DisallowSafepoints is not favoured, perhaps
>>>>> something like SafepointLocker/Unlocker terminology in analogy to
>>>>> MutexLocker/Unlocker
>>>>> might be acceptable to people here because admission to the set
>>>>> actually does lockout safepoints until the members of the set
>>>>> cooperatively
>>>>> allow the safepoint because of "yield"s etc.
>>>> I'll be OK with SafepointLocker / Unlocker even though I think it's
>>>> less descriptive than Regulate / Ignore.
>>> I agree.
>>>>> Tony, I agree that MutexLocker/Unlocker exposes the fact that
>>>>> there's a lock,
>>>>> but that's a historical artifact of mutual exlcusion and critical
>>>>> sections
>>>>> having evolved primarily as mutexes in most of computer science and
>>>>> systems history. Thus readers closely associate one with the other.
>>>>> In fact "mutex" is after all "mutual exclusion" (which is a high level
>>>>> concept independent of the mechanism of "locks" used for it).
>>>> Indeed, and point taken.
>>>>> Having said that, I agree with Tony that there are pros and cons in
>>>>> both cases
>>>>> and may be mentioning safepoints makes it too high level and abstract
>>>>> and in fact we do want the mention of suspendible thread sets, the
>>>>> underlying
>>>>> mechanism.
>>>>> So, having aired some of these thoughts, I'll go with whatever you
>>>>> folks decide sounds best here.
>>>> As always, thanks for the feedback!
>>> I think I like the names you have chosen above; thanks!
>>> -- ramki
>>>> Tony
>>>>> thanks!
>>>>> -- ramki
>>>>> On 10/06/11 09:29, John Cuthbertson wrote:
>>>>>> Hi Everyone,
>>>>>> I think the template interpreter uses the names notice_safepoints()
>>>>>> and ignore_safepoints() so in the same vein: NoticeSafepoints and
>>>>>> IgnoreSafepoints.
>>>>>> JohnC
>>>>>> 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