On Fri, 20 May 2022 15:52:04 GMT, Nick Gasson wrote:
> When the VM is run with `-XX:UseBranchProtection=pac-ret` on a supported CPU,
> the upper bits of the saved link register contain a "pointer authentication
> code" which must be checked and removed by a special i
When the VM is run with `-XX:UseBranchProtection=pac-ret` on a supported CPU,
the upper bits of the saved link register contain a "pointer authentication
code" which must be checked and removed by a special instruction before a
function returns. The serviceability agent is unaware of this and s
On Tue, 27 Jul 2021 09:24:38 GMT, Nick Gasson wrote:
> This test fails reliably with `-XX:TieredStopAtLevel=1` since JDK-8251462.
> MDOs are no longer allocated in this mode so the clhsdb `printmdo -a` command
> prints nothing. The failure is basically the same as JDK-8236
On Fri, 16 Jul 2021 10:24:56 GMT, Nick Gasson wrote:
> The clhsdb jstack command crashes when the debugged program is run with
> `-Xcomp -XX:+StressGCM -XX:StressSeed=2` on AArch64:
>
>
> sun.jvm.hotspot.utilities.AssertionFailure: sanity check
> at
This test fails reliably with `-XX:TieredStopAtLevel=1` since JDK-8251462. MDOs
are no longer allocated in this mode so the clhsdb `printmdo -a` command prints
nothing. The failure is basically the same as JDK-8236042 which happened with
`-Xcomp -XX:TieredStopAtLevel=1` so the workaround for th
On Mon, 19 Jul 2021 23:50:07 GMT, Tom Rodriguez wrote:
>> The clhsdb jstack command crashes when the debugged program is run with
>> `-Xcomp -XX:+StressGCM -XX:StressSeed=2` on AArch64:
>>
>>
>> sun.jvm.hotspot.utilities.AssertionFailure: sanity check
>> at jdk.hotspot.agent/sun.jvm.hotspo
The clhsdb jstack command crashes when the debugged program is run with `-Xcomp
-XX:+StressGCM -XX:StressSeed=2` on AArch64:
sun.jvm.hotspot.utilities.AssertionFailure: sanity check
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
at
jdk.hotspot.agent/sun.jvm.hot
On Fri, 9 Jul 2021 08:37:00 GMT, Nick Gasson wrote:
> Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
> -XX:-TieredCompilation fails with the following exception:
>
> Error: java.lang.NullPointerException: Cannot invoke
> "sun.jvm.hotspot.debugge
On Fri, 9 Jul 2021 08:37:00 GMT, Nick Gasson wrote:
> Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
> -XX:-TieredCompilation fails with the following exception:
>
> Error: java.lang.NullPointerException: Cannot invoke
> "sun.jvm.hotspot.debugge
On Tue, 13 Jul 2021 17:49:40 GMT, Chris Plummer wrote:
>> Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
>> -XX:-TieredCompilation fails with the following exception:
>>
>> Error: java.lang.NullPointerException: Cannot invoke
>> "sun.jvm.hotspot.debugger.Address.getJLon
On Tue, 13 Jul 2021 17:49:40 GMT, Chris Plummer wrote:
> This looks like a dup of
> [https://bugs.openjdk.java.net/browse/JDK-8247351](JDK-8247351). If so,
> please close this CR out as a dup and target this PR to JDK-8247351.
Yes, I missed that one. Thanks.
-
PR: https://git.ope
On Mon, 12 Jul 2021 22:01:37 GMT, Chris Plummer wrote:
> How did you even get the test to run without running into
> [JDK-8270199](https://bugs.openjdk.java.net/browse/JDK-8270199)
Linux not macOS.
-
PR: https://git.openjdk.java.net/jdk/pull/4737
Running the jtreg test serviceability/sa/ClhsdbWhere.java with -Xcomp
-XX:-TieredCompilation fails with the following exception:
Error: java.lang.NullPointerException: Cannot invoke
"sun.jvm.hotspot.debugger.Address.getJLongAt(long)" because "valueAddr" is null
java.lang.NullPointerException:
On Tue, 20 Oct 2020 09:27:45 GMT, Nick Gasson wrote:
> When using the Linux "perf" tool to do system profiling, symbol names of
> running Java methods cannot be decoded, resulting in unhelpful output
> such as:
>
> 10.52% [JIT] tid 236748 [.] 0x7f6fdb75d223
&g
On Fri, 30 Oct 2020 04:34:19 GMT, Yasumasa Suenaga wrote:
>
> Sure, the change looks good to me. However I don't understand why CSR is not
> needed. It introduces new dcmd for Linux.
I think because interfaces that are for diagnostic purposes don't require a
CSR. See question 4 on the CSR FAQ
On Wed, 21 Oct 2020 04:35:14 GMT, Yasumasa Suenaga wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make DumpPerfMapAtExit a diagnostic option
>
> Changes requested by ysuenaga (Revi
On Tue, 27 Oct 2020 04:17:34 GMT, Nick Gasson wrote:
>> Hi Nick,
>>
>> This looks good.
>> Thank you for the update.
>>
>> Thanks,
>> Serguei
>
>> I don't see any reason for this to be a product flag, rather than diagnostic.
>
&
will become stale if methods are compiled later or unloaded.
> However this shouldn't be a big problem in practice if the map file is
> generated after the application has warmed up.
>
> [1]
> https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-inte
On Tue, 27 Oct 2020 01:07:04 GMT, Serguei Spitsyn wrote:
>> Nick Gasson has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains four commits:
>>
>> - Merge master
>> - Add -XX:+DumpPerfMapAtExit option
&g
On Wed, 21 Oct 2020 18:03:11 GMT, Chris Plummer wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update for review comments
>
> src/hotspot/share/code/codeCache.cpp line 1582:
>
On Thu, 22 Oct 2020 07:09:47 GMT, Nick Gasson wrote:
>> Hi Nick,
>>
>> this is a very useful idea! I missed this in the past.
>>
>> Some remarks. I'll try to keep bikeshedding to a minimum since you already
>> have enough input. Mostly ergonomics.
&
On Thu, 22 Oct 2020 02:06:25 GMT, Yasumasa Suenaga wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update for review comments
>
> src/hotspot/share/code/codeCache.cpp line 1571:
will become stale if methods are compiled later or unloaded.
> However this shouldn't be a big problem in practice if the map file is
> generated after the application has warmed up.
>
> [1]
> https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.t
will become stale if methods are compiled later or unloaded.
> However this shouldn't be a big problem in practice if the map file is
> generated after the application has warmed up.
>
> [1]
> https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-inte
On Thu, 22 Oct 2020 05:00:10 GMT, Thomas Stuefe wrote:
>
> 1. Like Alexey, I would really wish for an print-at-exit switch. The
> common naming seems to be xxxAtExit (so not, OnExit). "PrintXxx" seems to be
> printing stuff out to tty, "DumpXxxx" for writing separate files (e.g. CDS
> map
On Thu, 22 Oct 2020 04:57:18 GMT, Thomas Stuefe wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update for review comments
>
> src/hotspot/share/code/codeCache.hpp line 194:
>
&g
On Wed, 21 Oct 2020 17:57:46 GMT, Chris Plummer wrote:
>> I'm not sure, I didn't want to add too much `#ifdef` mess. The code will
>> compile on other platforms, it just won't be called. Better to add `#ifdef`s
>> around all of it?
>
> Any reason not to have this dcmd supported on all platforms
On Wed, 21 Oct 2020 04:34:44 GMT, Yasumasa Suenaga wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update for review comments
>
> src/hotspot/share/code/codeCache.cpp line 1562:
&
On Tue, 20 Oct 2020 11:43:17 GMT, Vladimir Sitnikov
wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update for review comments
>
> test/hotspot/jtreg/serviceability/dcmd/compiler/Perf
will become stale if methods are compiled later or unloaded.
> However this shouldn't be a big problem in practice if the map file is
> generated after the application has warmed up.
>
> [1]
> https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-inte
On Tue, 20 Oct 2020 10:52:27 GMT, Aleksey Shipilev wrote:
>
> Because it seems that for the short jobs, we would like to just do "perf
> record java -XX:+WhatEver", followed by "perf report", without requiring user
> to invoke the diagnostic command while JVM is still running?
Yes that sounds
When using the Linux "perf" tool to do system profiling, symbol names of
running Java methods cannot be decoded, resulting in unhelpful output
such as:
10.52% [JIT] tid 236748 [.] 0x7f6fdb75d223
Perf can read a simple text file format describing the mapping between
address ranges and symbol
Thanks Andrew and Chris. Pushed here:
https://hg.openjdk.java.net/jdk/jdk/rev/902cef494e66
Nick
On 14/08/2019 16:10, Andrew Dinn wrote:
On 14/08/2019 03:28, Chris Plummer wrote:
On 8/13/19 6:26 PM, Nick Gasson wrote:
Hi Chris,
The changes look good, although I think the new file should
Hi Chris,
The changes look good, although I think the new file should go in the
serviceability/sa test directory, unless you think this is a generally
useful class that might be used by tests outside of the sa.
The new file is under test/hotspot/jtreg/serviceability/sa/ - the same
directory
Hi Chris,
Adding to Andrew comments, maybe the solution is to have the test extend
LingeredApp so it can produce a more reliable stack trace other than the
default one you get with LingeredApp. If that's too much trouble, I
don't mind the solution you came up with, but seems writing a
LingeredA
Thanks Andrew. Can someone from the serviceability team check this is OK
to push?
Nick
On 08/08/2019 18:16, Andrew Dinn wrote:
Hi Nick,
On 08/08/2019 10:32, Nick Gasson wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8229118
Webrev: http://cr.openjdk.java.net/~ngasson/8229118/webrev.0
Hi,
Bug: https://bugs.openjdk.java.net/browse/JDK-8229118
Webrev: http://cr.openjdk.java.net/~ngasson/8229118/webrev.0/
This test starts a sub-process with -Xcomp and then uses the SA to get a
stack trace of it. It expects to see this line:
In code in NMethod for jdk/test/lib/apps/LingeredApp.
Hi,
Could I get another reviewer to look at this please?
Thanks!
Nick
On 18/03/2019 18:04, Nick Gasson wrote:
Hi Sharath,
On 15/03/2019 23:32, Sharath Ballal wrote:
Fix looks good. How have you tested it ?
I ran the test using the "make test" target with and without
JTRE
On 22/03/2019 00:17, Daniel D. Daugherty wrote:
You can list both bug IDs in the same changeset like this:
8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2
is not alive"
8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT
while waiting for event"
Thanks
Hi,
Please review this small fix to a bug that causes the following tests to
fail when run with jtreg -timeoutFactor > 10 after the changes in 8207367:
vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java
vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.jav
Thanks! Do I need to get any more official Reviewers to look at this
before it's OK to push?
Nick
On 19/03/2019 00:17, Jean Christophe Beyler wrote:
Hi Nick,
Looks good to me :)
Jc
On Mon, Mar 18, 2019 at 3:05 AM Nick Gasson <mailto:nick.gas...@arm.com>> wrote:
Hi Shara
Hi Sharath,
On 15/03/2019 23:32, Sharath Ballal wrote:
Fix looks good. How have you tested it ?
I ran the test using the "make test" target with and without
JTREG="MAX_MEM=512m" on AArch64 and x86. Previously it would fail with
that argument.
Thanks,
Nick
Hi Jean Christophe,
On 15/03/2019 22:47, Jean Christophe Beyler wrote:
Not a reviewer but looks good to me :) I would perhaps put a comment
above the argument creation to note that the order is important, ie
something like:
"// Need to add the default arguments first to have explicit -Xmx8g
Hi,
Please review this very small test fix to
serviceability/sa/TestHeapDumpForLargeArray.java:
Bug: https://bugs.openjdk.java.net/browse/JDK-8220707
Webrev: http://cr.openjdk.java.net/~ngasson/8220707/webrev.0/
If you run this test with jtreg option -vmoption:-Xmx512m (or any value
< 8g) th
On 18/02/2019 17:22, Andrew Haley wrote:
>>
>> Should we do this now? There's only two places I can see:
>> StubGenerator::generate_throw_exception and the set_last_Java_frame
>> overload that takes a Label.
>
> I hate cruft like this, but it's not actually a bug, and any change in this
> delicate
32, Andrew Haley wrote:
> What's the status of this? Are you still looking at it?
>
> On 2/7/19 3:39 PM, Andrew Haley wrote:
>> On 2/7/19 2:36 PM, Nick Gasson (Arm Technology China) wrote:
>>>
>>> Yeah I tried this method too (see the end of my first email).
On 12/02/2019 23:32, Andrew Haley wrote:
> What's the status of this? Are you still looking at it?
>
Apologies, I was on holiday until today so haven't done anything on it.
I'll send an updated patch shortly...
Nick
(and set this.pc to null
otherwise).
Nick
From: Andrew Haley
Sent: 07 February 2019 21:03:29
To: Nick Gasson (Arm Technology China); serviceability-dev@openjdk.java.net
Cc: nd; aarch64-port-...@openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR: 8209413: AA
__
From: Andrew Haley
Sent: 06 February 2019 18:00:16
To: Nick Gasson (Arm Technology China); serviceability-dev@openjdk.java.net
Cc: nd; aarch64-port-...@openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack
command
On 2/5/19 5:57 PM, Andrew Haley wrote:
&
#x27;t know
why you don't get the NPE, I guess it depends on what's in that stack slot.
Nick
From: Andrew Haley
Sent: 06 February 2019 01:26:41
To: Nick Gasson (Arm Technology China); serviceability-dev@openjdk.java.net
Cc: nd; aarch64-port-...@openjdk.java.
Hi Andrew
> Please tell me which code it is that jumps to
the native code.
SharedRuntime::generate_native_wrapper. The SP here is saved in the thread
state by set_last_Java_frame.
Nick
From: Andrew Haley
Sent: 05 February 2019 02:25:34
To: Nick Gasson (
Hi Jini,
On 02/02/2019 02:16, Jini George wrote:
> Do we reach here after AARCH64CurrentFrameGuess.run() fails to get the
> PC ?
Yes, that's right. It's the else branch (not interpreter and not
compiler) that sets this.pc to null.
> If so, was wondering if it would make more sense to scan fro
Hi all,
Please review this patch to fix a crash in the clhsdb "jstack -v"
command on AArch64:
Bug: https://bugs.openjdk.java.net/browse/JDK-8209413
Webrev: http://cr.openjdk.java.net/~ngasson/8209413/webrev.01/
On AArch64, if you use "jhsdb clhsdb --pid=..." to attach a debugger to
a Java proc
53 matches
Mail list logo
