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

[Tony Printezis]

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.

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.

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

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

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