CMS parallel initial mark; vm thread sneaking in Thread::try_lock()
Thomas Schatzl
thomas.schatzl at oracle.com
Tue Jun 11 23:07:29 UTC 2013
Hi,
On Tue, 2013-06-11 at 15:30 -0700, Jon Masamitsu wrote:
> On 6/10/13 12:49 PM, Thomas Schatzl wrote:
> > Hi,
> >
> > On Fri, 2013-06-07 at 11:28 -0700, Jon Masamitsu wrote:
> >> On 6/7/2013 4:23 AM, Thomas Schatzl wrote:
> >>> - the code to get the lock on _eden_chunk_sampling_active seems to be
> >>> needlessly complicated.
> >>>
> >>> Please consider using a dedicated Monitor in conjunction with
> >>> try_lock(). I.e.
> >> Thomas,
> >>
> >> Any concerns about the "sneak" code in try_lock()? That would only
> >> matter if the VM thread were involved in the eden sampling along with
> >> other GC threads, yes?
> > I do not think so in this case. Only the VM thread can sneak, and only
> > during safepoint. The sampling is done only for eden space and eventually
> > from-space, which are never allocated to during gc (only by java threads
> > outside of stw pauses), aren't they?
> >
> > The code could assert that in the sampling too.
> Where would the assert go that asserts sampling is
> being done?
>
> Or do you mean at the use of try_lock() assert that
> we're not the VM thread?
>
Sorry, I was unclear. In the sampling code itself: sampling should not
be performed during a safepoint as far as I can see. So e.g. add to the
sampling method an
assert(!SafepointSynchronize::is_at_safepoint(), "...");
There is also the option to add a parameter to try_lock() that prohibits
sneaking.
E.g.
bool try_lock(bool allow_vm_thread_to_sneak = true) {
...
bool can_sneak = allow_vm_thread_to_sneak && ...
...
}
Then in the code
if (...->try_lock(false)) {
...
...->unlock();
}
All other uses would be unaffected.
I would simply prefer using the existing synchronization primitives
instead of rolling our own just for that particular use.
They make the code also much more readable.
Another reason I am not worried about vm thread sneaking in this case is
that during gc only the vm thread runs (and try_lock() does not seem to
be a synchronization point for the safepoint), which cannot sneak itself
(or is at least benign).
Thomas
More information about the hotspot-gc-dev
mailing list