Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v4]

2022-05-05 Thread Daniel D . Daugherty
On Thu, 5 May 2022 13:02:58 GMT, Jaroslav Bachorik  
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.
>> 
>> 
>> 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.
>> 
>> 
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   AGCT -> ASGCT

> I would like to disagree: The abbreviation "ASGCT" is used in multiple places 
> in the JVM,
> especially in `forte.cpp` (where "AGCT" cannot be found).

That was a very old mistake on my part. It should have been `AGCT` instead of 
`ASGCT`
and I never got around to fixing that.

-

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


Re: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v4]

2022-05-05 Thread Jaroslav Bachorik
> 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.
> 
> 
> 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.
> 
> 
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has updated the pull request incrementally with one 
additional commit since the last revision:

  AGCT -> ASGCT

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/71e5a919..caf43e39

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=02-03

  Stats: 15 lines in 3 files changed: 4 ins; 8 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549

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