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

Y. S. Ramakrishna y.s.ramakrishna at oracle.com
Thu Oct 6 10:40:46 PDT 2011


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.

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.

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

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.

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