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

[Y. S. Ramakrishna]

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