RFR(s): 8197994: Move JavaThread::initialize_queues() logic to G1SATBCardTableLoggingModRefBS
Erik Österlund
erik.osterlund at oracle.com
Thu Feb 15 11:56:54 UTC 2018
Hi Per,
Looks good.
/Erik
On 2018-02-15 12:46, Per Liden wrote:
> After some off-line discussions with Erik we agreed that "attach" and
> "detach" are good words for this (instead of "create" and "destroy").
>
> Updated patch:
> http://cr.openjdk.java.net/~pliden/8197994/webrev.1/
>
> Diff:
> http://cr.openjdk.java.net/~pliden/8197994/webrev.0vs1/
>
> /Per
>
> On 02/15/2018 12:30 PM, Erik Österlund wrote:
>> Hi Per,
>>
>> I wonder how we feel about the name on_thread_create in particular.
>> It is crucial that this is performed not just when creating the
>> thread, but particularly when adding it to the thread list while
>> holding the Threads_lock to block safepoints, otherwise the G1
>> barriers would blow up. Therefore I would have preferred the name
>> on_thread_add instead of on_thread_create. Would you agree with that?
>>
>> Thanks,
>> /Erik
>>
>> On 2018-02-15 10:45, Per Liden wrote:
>>> We introduced BarrierSet::flush_deferred_barriers() so that we could
>>> move G1's SATB logic out from JavaThread and into the
>>> G1SATBCardTableLoggingModRefBS barrier set. We should do the same
>>> thing with JavaThread::initialize_queues().
>>>
>>> The new function on BarrierSet is called on_thread_create(). After
>>> talking to Erik Ö, we also decided to rename
>>> BarrierSet::flush_deferred_barriers() to on_thread_destroy(), to
>>> better match the existing on_slowpath_allocation_exit() and the new
>>> on_thread_create().
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8197994
>>> Webrev: http://cr.openjdk.java.net/~pliden/8197994/webrev.0/
>>> Testing: hs-tier1,hs-tier2
>>>
>>> /Per
>>
More information about the hotspot-gc-dev
mailing list