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

[Tony Printezis]

Ramki,

Thanks again for the feedback. So two votes for Regulate / Ignore so 
far. :-)

Tony

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