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

[Tony Printezis]

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