RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v10]

[Erik Österlund]

On Tue, 6 Oct 2020 02:40:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Erik Österlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains 16 commits:
>>  - Review: Deal with new assert from mainline
>>  - Merge branch 'master' into 8253180_conc_stack_scanning
>>  - Review: StackWalker hook
>>  - Review: Kim CR 1 and exception handling fix
>>  - Review: Move barrier detach
>>  - Review: Remove assert that has outstayed its welcome
>>  - Merge branch 'master' into 8253180_conc_stack_scanning
>>  - Review: Albert CR2 and defensive programming
>>  - Review: StefanK CR 3
>>  - Review: Per CR 1
>>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9604ee82...e633cb94
>
> src/hotspot/share/runtime/stackWatermark.hpp line 91:
> 
>> 89:   JavaThread* _jt;
>> 90:   StackWatermarkFramesIterator* _iterator;
>> 91:   Mutex _lock;
> 
> How are you guaranteeing that the Mutex is unused at the time the StackWatermark is deleted?

The StackWatermarks are deleted when the thread is deleted (and its destructor runs). Hence, I'm relying on the Threads
SMR project here. Anyone that pokes around at the StackWatermark is either the current thread, or a thread that has a
ThreadsListHandle containing the thread, making it safe to access that thread without it racingly being deleted.

> src/hotspot/share/runtime/safepointMechanism.cpp line 101:
> 
>> 99: uintptr_t SafepointMechanism::compute_poll_word(bool armed, uintptr_t stack_watermark) {
>> 100:   if (armed) {
>> 101:     log_debug(stackbarrier)("Computed armed at %d", Thread::current()->osthread()->thread_id());
> 
> s/at/for/ ?

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/296