On Tue, 17 May 2022 13:53:36 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: > > Change comment wording src/hotspot/share/code/codeCache.cpp line 662: > 660: bool is_zombie = result != NULL && result->is_zombie(); > 661: bool is_result_safe = !is_zombie || result->is_locked_by_vm() || > VMError::is_error_reported(); > 662: guarantee(is_result_safe || is_in_asgct(), "unsafe access to zombie > method"); Why is this a guarantee? Does it still need to be one? We usually avoid paying for assert setup in release VMs, its rather uncommon to use guarantee. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549
