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
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
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
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
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
[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
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
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.
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
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.
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$
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
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
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
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
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
16 matches
Mail list logo