CMS parallel initial mark; vm thread sneaking in Thread::try_lock()
jon.masamitsu at oracle.com
Mon Jun 17 14:22:47 UTC 2013
On 6/17/13 2:22 AM, Thomas Schatzl wrote:
> On Thu, 2013-06-13 at 13:46 -0700, Hiroshi Yamauchi wrote:
>> On Thu, Jun 13, 2013 at 4:45 AM, Thomas Schatzl
>> <thomas.schatzl at oracle.com> wrote:
>> [... summary of the current state ...]
>> Thomas, thanks for summarizing the discussion so far.
>> I agree that if try_lock()/unlock() does what the manual/custom
>> synchronization does (and as efficiently), it should suffice. No need
>> to roll one's own.
>> I also agree that adding the assert(!
>> SafepointSynchronize::is_at_safepoint()) (or assert(!
>> Thread->current()->is_VM_thread())) may be good enough and if sneaking
>> can be turned off for a case like this, it'd be safer.
> I think we should go for this solution, i.e. adding the assert (because
> it would be wrong anyway to call this code during safepoint) and using
> Try_lock() itself is the same as the current code, and unlock() too
> (except for some additional checks that should fail fast). The code that
> is guarded handles occasional skipping already and actually exits fast
> if the frequency is too high, so I do not see a big advantage doing
> custom code.
I like this solution.
More information about the hotspot-gc-dev