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

[John Coomes]

Tony Printezis (tony.printezis at oracle.com) wrote:
> Ramki,
> 
> Thanks again for the feedback. So two votes for Regulate / Ignore so 
> far. :-)

I discussed it briefly with John to clarify the concept, and we both
used the same terms:  the threads usually ignore safepoints
(safepoints do not wait for them, they keep running), but sometimes
participate in safepoints (the safepoint waits for them to yield).

I like ignore and participate.  Not sure how to best turn participate
into a class name, though.  Possibilities:

   {
      ParticipateInSafepoints      xxx;
      SafepointParticipator        xxx;
      SafepointParticipationMark   xxx;
      EnableSafepointParticipation xxx;
      ...
   }

The first seems clearest.

-John

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