Re: RFR: 8319961: JvmtiEnvBase doesn't zero _ext_event_callbacks

2023-11-13 Thread David Holmes
On Tue, 14 Nov 2023 06:50:58 GMT, Roman Marchenko wrote: > Zero'ing memory of extension event callbacks Marked as reviewed by dholmes (Reviewer). src/hotspot/share/prims/jvmtiEnvBase.cpp line 217: > 215: // all callbacks initially null > 216: memset(&_event_callbacks,0,sizeof(jvmtiEventCa

RFR: 8319961: JvmtiEnvBase doesn't zero _ext_event_callbacks

2023-11-13 Thread Roman Marchenko
Zero'ing memory of extension event callbacks - Commit messages: - JDK-8319961: JvmtiEnvBase doesn't zero _ext_event_callbacks Changes: https://git.openjdk.org/jdk/pull/16647/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16647&range=00 Issue: https://bugs.openjdk.org/brow

Re: RFR: JDK-8318671: Potential uninitialized uintx value after JDK-8317683 [v4]

2023-11-13 Thread David Holmes
On Mon, 13 Nov 2023 11:51:30 GMT, Tobias Hartmann wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix Windows build > > I think this is ready for integration given that both @dholmes-ora and > @jdksjolen are okay

Re: RFR: 8319935: Ensure only one JvmtiThreadState is create for one JavaThread associated with attached native thread

2023-11-13 Thread David Holmes
On Mon, 13 Nov 2023 21:52:22 GMT, Jiangli Zhou wrote: > Please review JvmtiThreadState::state_for_while_locked change to handle the > state->get_thread_oop() null case. Please see > https://bugs.openjdk.org/browse/JDK-8319935 for details. Is this a case where the code should be checking for `i

Re: RFR: 8319935: Ensure only one JvmtiThreadState is create for one JavaThread associated with attached native thread

2023-11-13 Thread Jiangli Zhou
On Mon, 13 Nov 2023 23:21:56 GMT, Man Cao wrote: >> Please review JvmtiThreadState::state_for_while_locked change to handle the >> state->get_thread_oop() null case. Please see >> https://bugs.openjdk.org/browse/JDK-8319935 for details. > > src/hotspot/share/prims/jvmtiThreadState.inline.hpp li

Re: RFR: 8319935: Ensure only one JvmtiThreadState is create for one JavaThread associated with attached native thread

2023-11-13 Thread Man Cao
On Mon, 13 Nov 2023 21:52:22 GMT, Jiangli Zhou wrote: > Please review JvmtiThreadState::state_for_while_locked change to handle the > state->get_thread_oop() null case. Please see > https://bugs.openjdk.org/browse/JDK-8319935 for details. Changes requested by manc (Committer). src/hotspot/sha

Re: RFR: 8319935: Ensure only one JvmtiThreadState is create for one JavaThread associated with attached native thread

2023-11-13 Thread Jiangli Zhou
On Mon, 13 Nov 2023 22:15:18 GMT, Daniel D. Daugherty wrote: > @jianglizhou - I fixed a typo in the bug's synopsis line. Change this PR's > title: s/is create/is created/ Thanks, @dcubed-ojdk! - PR Comment: https://git.openjdk.org/jdk/pull/16642#issuecomment-1809279446

Re: RFR: 8319935: Ensure only one JvmtiThreadState is create for one JavaThread associated with attached native thread

2023-11-13 Thread Daniel D . Daugherty
On Mon, 13 Nov 2023 21:52:22 GMT, Jiangli Zhou wrote: > Please review JvmtiThreadState::state_for_while_locked change to handle the > state->get_thread_oop() null case. Please see > https://bugs.openjdk.org/browse/JDK-8319935 for details. @jianglizhou - I fixed a typo in the bug's synopsis lin

RFR: 8319935: Ensure only one JvmtiThreadState is create for one JavaThread associated with attached native thread

2023-11-13 Thread Jiangli Zhou
Please review JvmtiThreadState::state_for_while_locked change to handle the state->get_thread_oop() null case. Please see https://bugs.openjdk.org/browse/JDK-8319935 for details. - Commit messages: - 8319935: Ensure only one JvmtiThreadState is create for one JavaThread associated

Re: RFR: JDK-8318671: Potential uninitialized uintx value after JDK-8317683 [v5]

2023-11-13 Thread Thomas Stuefe
> When using 'MemStat' CompileCommand, we accidentally register the command if > an invalid suboption had been specified. Fixed, added regression test > (verified). Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six co

Re: RFR: JDK-8318671: Potential uninitialized uintx value after JDK-8317683 [v4]

2023-11-13 Thread Thomas Stuefe
On Mon, 13 Nov 2023 11:51:30 GMT, Tobias Hartmann wrote: > I think this is ready for integration given that both @dholmes-ora and > @jdksjolen are okay with it. Well, they did not approve yet; @jdksjolen or @dholmes-ora, if you are happy with this, could you hit the big green button please? -

Re: RFR: JDK-8318671: Potential uninitialized uintx value after JDK-8317683 [v4]

2023-11-13 Thread Tobias Hartmann
On Thu, 26 Oct 2023 16:17:14 GMT, Thomas Stuefe wrote: >> When using 'MemStat' CompileCommand, we accidentally register the command if >> an invalid suboption had been specified. Fixed, added regression test >> (verified). > > Thomas Stuefe has updated the pull request incrementally with one ad

Re: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on AIX if prefixLen of mask is larger than 32 in IPv6 case

2023-11-13 Thread Matthias Baesken
On Wed, 8 Nov 2023 14:37:29 GMT, Matthias Baesken wrote: > In parseAllowedMask (file socketTransport.c) , prefixLen of mask is compared > with a maxValue (32 for IPv4, 128 otherwise). This fails on AIX if it is > larger than 32, because getaddrinfo seems to often (always ?) detect IPv4 > famil

Integrated: JDK-8318636: Add jcmd to print annotated process memory map

2023-11-13 Thread Thomas Stuefe
On Sun, 22 Oct 2023 10:08:49 GMT, Thomas Stuefe wrote: > Analysts and supporters often use /proc/xx/maps to make sense of the memory > footprint of a process. > > Interpreting the memory map correctly can help when used as a complement to > other tools (e.g. NMT). There even exist tools out th

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v9]

2023-11-13 Thread Thomas Stuefe
On Thu, 9 Nov 2023 07:03:34 GMT, David Holmes wrote: >>> > As this adds a JCmd, doesn't this need both a CSR and a manual entry? >>> >>> * CSR: not sure; there are precedences for going with CSR and without >>> CSR. Since we get awfully close to JDK22 freeze, I would prefer for a CSR >>> n