Re: Stack unwinder for SA

Hi David, Chris, I want to fix `jhsdb jstack --mixed` in JDK-8245234 with third-party library at first. Fixing hs_err log is an another issue IMHO, but I just want to say we may divert it for hs_err log. We need further discussion for it of course. Thanks, Yasumasa On 2021/01/25 12:32,

Re: Stack unwinder for SA

On 1/24/21 7:14 PM, David Holmes wrote: On 25/01/2021 12:41 pm, Yasumasa Suenaga wrote: Hi all, Chris and I discussed about fixing JDK-8245234 to see all mixed stacks via `jhsdb jstack --mixed`. In the discussion, we agree to use stack unwinder, but we haven't yet decided which library to

Re: Stack unwinder for SA

On 25/01/2021 12:41 pm, Yasumasa Suenaga wrote: Hi all, Chris and I discussed about fixing JDK-8245234 to see all mixed stacks via `jhsdb jstack --mixed`. In the discussion, we agree to use stack unwinder, but we haven't yet decided which library to use. Can you suggest the stack unwinder

Stack unwinder for SA

Hi all, Chris and I discussed about fixing JDK-8245234 to see all mixed stacks via `jhsdb jstack --mixed`. In the discussion, we agree to use stack unwinder, but we haven't yet decided which library to use. Can you suggest the stack unwinder for SA? I fixed similar issue in JDK-8234624 to

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly [v2]

Alex, On 20/01/2021 11:47 am, Alex Menkov wrote: On Tue, 19 Jan 2021 23:16:30 GMT, David Holmes wrote: What do you mean by this? The -J args are not "translated" here but later in TranslateApplicationArgs. I meant that they are translated in TranslateApplicationArgs. Looks like it's not

Re: RFR: 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs [v12]

On Fri, 22 Jan 2021 11:27:38 GMT, Serguei Spitsyn wrote: >> This change have been already reviewed by Mandy, Sundar, Alan and David. >> Please, see the jdk 15 review thread: >> >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html >> >> Now, the PR approval is

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

On Sat, 23 Jan 2021 11:43:31 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > >

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

On Sat, 23 Jan 2021 11:42:48 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > >

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

On Sat, 23 Jan 2021 11:10:17 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > >

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

On Fri, 22 Jan 2021 20:18:51 GMT, Erik Joelsson wrote: >> Anton Kozlov has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back > > make/autoconf/flags-cflags.m4

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

> 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 new calling convention (subtasks > JDK-8253817, JDK-8253818)