On Mon, 16 May 2022 15:14:25 GMT, Jaroslav Bachorik <jbacho...@openjdk.org> 
wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup 
>> when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which 
>> is still on stack. While this would indicate a serious error for the normal 
>> execution flow, in case of ASGCT being in progress when the executing thread 
>> can be expected at any possible method this is something which may happen 
>> and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash 
>> other that testing in our production where the crash is happening 
>> sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress 
>> test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be 
>> reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Restore the original find_blob behavior regarding dead blobs

src/hotspot/share/prims/forte.hpp line 53:

> 51:   ASGCTMark() : ASGCTMark(JavaThread::current()) {}
> 52:   ~ASGCTMark() {
> 53:     JavaThread::current()->set_in_asgct(false);

You can't call `JavaThread::current()` in any of this code as it is not safe 
from a signal handling context. (There is an existing use in ASGCT that is also 
unsafe.) I suggest not having the no-arg constructor and require the current 
JavaThread, or null, to be passed in (having already been safely obtained by 
the caller). You can then assert using `Thread::current_or_null_safe()`.

Personally I find the ASGCTMark complete overkill for this situation as there 
is only ever going to be a single use - sorry @tstuefe - it is just 
complicating things IMO.

src/hotspot/share/runtime/thread.hpp line 1650:

> 1648:   static void vm_exit_on_osthread_failure(JavaThread* thread);
> 1649: 
> 1650: 

Don't need two blank lines. Thanks.

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

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

Reply via email to