Re: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6]

2022-04-14 Thread Ludovic Henry
On Thu, 14 Apr 2022 13:06:58 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and >> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` >> like it is done in >> [JFR](https://github.com/openjdk/jdk/blob/965ea8d

Re: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4]

2022-04-14 Thread Ludovic Henry
On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and >> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` >> like it is done in >> [JFR](https://github.com/openjdk/jdk/blob/965ea8d

Withdrawn: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks

2021-09-14 Thread Ludovic Henry
On Wed, 9 Jun 2021 17:16:23 GMT, Ludovic Henry wrote: > When the signal sent for AsyncGetCallTrace or JFR would land on a runtime > stub (like arraycopy), a vtable stub, or the prolog of a compiled method, it > wouldn't be able to detect the sender (caller) frame for multiple re

Re: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks [v4]

2021-09-14 Thread Ludovic Henry
On Mon, 19 Jul 2021 09:25:59 GMT, Ludovic Henry wrote: >> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime >> stub (like arraycopy), a vtable stub, or the prolog of a compiled method, >> it wouldn't be able to detect the sender (caller) frame f

Re: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks [v4]

2021-08-20 Thread Ludovic Henry
Hello, As it's been quite a while already, I wanted to nudge this RFR forward. Who would be best qualified to review this PR? Thank you! Ludovic On Wed, Aug 18, 2021 at 9:21 PM Marcus Hirt wrote: > On Mon, 19 Jul 2021 09:25:59 GMT, Ludovic Henry > wrote: > > >> W

Re: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks [v4]

2021-08-20 Thread Ludovic Henry
[Sending again now with the email address properly registered to the mailing lists] Hello, As it's been quite a while already, I wanted to nudge this RFR forward. Who would be best qualified to review this PR? Thank you! Ludovic On Fri, Aug 20, 2021 at 8:49 AM Ludovic Henry wrote: &g

Re: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks [v3]

2021-07-19 Thread Ludovic Henry
On Sun, 11 Jul 2021 22:21:31 GMT, Andrei Pangin wrote: >> Ludovic Henry has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix comments > > Hi Ludovic, > > Thank you for working on this long-standing bu

Re: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks

2021-06-29 Thread Ludovic Henry
On Wed, 9 Jun 2021 19:04:54 GMT, Serguei Spitsyn wrote: >> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime >> stub (like arraycopy), a vtable stub, or the prolog of a compiled method, >> it wouldn't be able to detect the sender (caller) frame for multiple >> reasons.

Re: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks [v3]

2021-06-18 Thread Ludovic Henry
t 6.6,s 5.4) Prof2$$Lambda$28.0x000800081000::get > (t 5.7,s 5.0) Prof2$$Lambda$26.0x000800080a08::get > (t 5.9,s 5.0) Prof2$$Lambda$27.0x000800080c28::get > (t 4.9,s 4.9) AGCT::Unknown Java[ERR=-5] > (t 1.2,s 1.2) Prof2::lambda$main$2

Re: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks

2021-06-10 Thread Ludovic Henry
On Wed, 9 Jun 2021 19:04:54 GMT, Serguei Spitsyn wrote: >> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime >> stub (like arraycopy), a vtable stub, or the prolog of a compiled method, >> it wouldn't be able to detect the sender (caller) frame for multiple >> reasons.

Re: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks [v2]

2021-06-10 Thread Ludovic Henry
t 6.6,s 5.4) Prof2$$Lambda$28.0x000800081000::get > (t 5.7,s 5.0) Prof2$$Lambda$26.0x000800080a08::get > (t 5.9,s 5.0) Prof2$$Lambda$27.0x000800080c28::get > (t 4.9,s 4.9) AGCT::Unknown Java[ERR=-5] > (t 1.2,s 1.2) Prof2::lambda$main$

RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks

2021-06-09 Thread Ludovic Henry
When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method, it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame p

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Ludovic Henry
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the

RE: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

2020-10-01 Thread Ludovic Henry
It’s me who made a mistake. This PR should be associated with JEP 388 as you are rightly pointing out. From: Daniel D. Daugherty Sent: Thursday, October 1, 2020 3:05 PM To: Ludovic Henry ; David Holmes ; David Holmes ; Andrew Haley ; Chris Plummer ; Magnus Ihse Bursie ; build

RE: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

2020-10-01 Thread Ludovic Henry
Hi David, > The JEP is not yet targeted so we have to wait for that formality. But once > that happens I can sponsor for you. Perfect, I didn't know about the need for the JEP to be targeted before the merge. > Also note that the PR references the wrong JEP so can you please edit the > descri

RE: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

2020-10-01 Thread Ludovic Henry
Hi, As we now have a whole bunch of reviews (thank you all!), we would need a sponsor to get it merged. Thank you :) - PR: https://github.com/openjdk/jdk/pull/212