On Wed, 23 Sep 2020 07:39:55 GMT, Stefan Karlsson <stef...@openjdk.org> wrote:

>> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack 
>> Processing" (cf.
>> https://openjdk.java.net/jeps/376).
>> Basically, this patch modifies the epilog safepoint when returning from a 
>> frame (supporting interpreter frames, c1, c2,
>> and native wrapper frames), to compare the stack pointer against a 
>> thread-local value. This turns return polls into
>> more of a swiss army knife that can be used to poll for safepoints, 
>> handshakes, but also returns into not yet safe to
>> expose frames, denoted by a "stack watermark".  ZGC will leave frames (and 
>> other thread oops) in a state of a mess in
>> the GC checkpoint safepoints, rather than processing all threads and their 
>> stacks. Processing is initialized
>> automagically when threads wake up for a safepoint, or get poked by a 
>> handshake or safepoint. Said initialization
>> processes a few (3) frames and other thread oops. The rest - the bulk of the 
>> frame processing, is deferred until it is
>> actually needed. It is needed when a frame is exposed to either 1) execution 
>> (returns or unwinding due to exception
>> handling), or 2) stack walker APIs. A hook is then run to go and finish the 
>> lazy processing of frames.  Mutator and GC
>> threads can compete for processing. The processing is therefore performed 
>> under a per-thread lock. Note that disarming
>> of the poll word (that the returns are comparing against) is only performed 
>> by the thread itself. So sliding the
>> watermark up will require one runtime call for a thread to note that nothing 
>> needs to be done, and then update the poll
>> word accordingly. Downgrading the poll word concurrently by other threads 
>> was simply not worth the complexity it
>> brought (and is only possible on TSO machines). So left that one out.
>
> src/hotspot/share/gc/z/zCollectedHeap.cpp line 235:
> 
>> 233:   return true;
>> 234: }
>> 235:
> 
> Weird placement between store barrier functions. But even weirder that we 
> still have those functions. I'll remove them
> with JDK-8253516.

Perfect, thanks.

> src/hotspot/share/gc/z/zDriver.cpp line 108:
> 
>> 106:     return false;
>> 107:   }
>> 108:
> 
> Group needs_inactive_gc_locker, skip_thread_oop_barriers, and 
> allow_coalesced_vm_operations together?
> 
> Add a comment about why we chose to skip coalescing here.

Per explicitly wanted skip_thread_oop_barriers grouped with 
needs_inactive_gc_locker. But I should remove
allow_coalesced_vm_operations; it is no longer used since I have removed VM 
operation coalescing completely already.

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

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

Reply via email to