CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances
John Cuthbertson
john.cuthbertson at oracle.com
Thu Oct 6 16:29:28 UTC 2011
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