CMS parallel initial mark; vm thread sneaking in Thread::try_lock()

Jon Masamitsu 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()/unlock().
>
> 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.
>
> Jon?

I like this solution.

Thanks.

Jon
>
> Thanks,
> Thomas
>
>




More information about the hotspot-gc-dev mailing list