Re: RFR: 8318707: Remove the Java Management Extension (JMX) Management Applet (m-let) feature [v3]

2024-01-11 Thread Kevin Walls
On Wed, 10 Jan 2024 17:06:01 GMT, Daniel Fuchs wrote: >> Checking on the original problem noted in the test, looks like it wasn't >> really about ClassLoaders and MLets: >> JDK-4909536: Standard MBean introspector keeps reference to last class >> introspected >> This is what the test still test

Re: RFR: 8318707: Remove the Java Management Extension (JMX) Management Applet (m-let) feature [v3]

2024-01-11 Thread Daniel Fuchs
On Thu, 11 Jan 2024 11:31:07 GMT, Kevin Walls wrote: >> Yes, that's the whole point of the test. Without using an MBean which is a >> ClassLoader the fix cannot be tested. >> 1. you need to create an MBean which is an URLClassLoader, and it needs to >> be a PrivateClassLoader so that it's not a

Re: [jdk22] RFR: 8322237: Heap dump contains duplicate thread records for mounted virtual threads

2024-01-11 Thread Serguei Spitsyn
On Thu, 11 Jan 2024 00:59:08 GMT, Alex Menkov wrote: > Hi all, > > This pull request contains a backport of commit > [dd8ae616](https://github.com/openjdk/jdk/commit/dd8ae616437398f957f9b4f09cf2c7f1d0bd0938) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit bein

Re: RFR: 8323546: Clarify docs for Compiler.perfmap filename parameter, and other misc related jcmd doc cleanups

2024-01-11 Thread Serguei Spitsyn
On Wed, 10 Jan 2024 21:40:08 GMT, Chris Plummer wrote: > The jcmd docs for Compiler.perfmap currently say: > > - *filename*: (Optional) The name of the map file (STRING, no default > value) > > However, there is a default, so not only should that be made more clear in > the above, but als

Integrated: JDK-8320890: [AIX] Find a better way to mimic dl handle equality

2024-01-11 Thread Joachim Kern
On Fri, 1 Dec 2023 11:33:46 GMT, Joachim Kern wrote: > On AIX, repeated calls to dlopen referring to the same shared library may > result in different, unique dl handles to be returned from libc. In that it > differs from typical libc implementations that cache dl handles. > > This causes prob

Re: RFR: JDK-8318563: GetClassFields should not use random access to field [v3]

2024-01-11 Thread Frederic Parain
On Wed, 10 Jan 2024 22:34:57 GMT, Alex Menkov wrote: >> FieldStream/FilteredFieldStream classes from reflectionUtils.hpp iterate >> class fields in the reverse order and use field indexes to access instead of >> forward iteration. This is performance ineffective (see >> [JDK-8317692](https://b

Re: RFR: 8309271: A way to align already compiled methods with compiler directives [v21]

2024-01-11 Thread Dmitry Chuyko
> Compiler Control (https://openjdk.org/jeps/165) provides method-context > dependent control of the JVM compilers (C1 and C2). The active directive > stack is built from the directive files passed with the > `-XX:CompilerDirectivesFile` diagnostic command-line option and the > Compiler.add_dir

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

2024-01-11 Thread Joachim Kern
In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise). This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue. -

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

2024-01-11 Thread Matthias Baesken
On Thu, 11 Jan 2024 15:46:59 GMT, Joachim Kern wrote: > In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with > a maxValue (32 for IPv4, 128 otherwise). This fails if it is larger than 32, > because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only >

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

2024-01-11 Thread Joachim Kern
On Thu, 11 Jan 2024 16:00:45 GMT, Matthias Baesken wrote: >> Joachim Kern has updated the pull request incrementally with one additional >> commit since the last revision: >> >> cosmetic changes > > src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c line 428: > >> 426: co

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

2024-01-11 Thread Joachim Kern
> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with > a maxValue (32 for IPv4, 128 otherwise). This fails if it is larger than 32, > because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only > some of the last 32 Bits. So we take the wrong maxValue

Re: RFR: 8323546: Clarify docs for Compiler.perfmap filename parameter, and other misc related jcmd doc cleanups [v2]

2024-01-11 Thread Chris Plummer
> The jcmd docs for Compiler.perfmap currently say: > > - *filename*: (Optional) The name of the map file (STRING, no default > value) > > However, there is a default, so not only should that be made more clear in > the above, but also some descriptive text as to how the default is generate

Integrated: 8323213: Fix some javadoc broken links in ObjectReference, and other misc javadoc cleanups

2024-01-11 Thread Chris Plummer
On Mon, 8 Jan 2024 20:16:50 GMT, Chris Plummer wrote: > Fix some broken links and other minor cleanups: > > There are a few broken links in the javadoc for ObjectReference.java. For > example: > > > * Not all target VMs support this operation. See > * VirtualMachine#canGetMonitorIn

Re: RFR: 8323213: Fix some javadoc broken links in ObjectReference, and other misc javadoc cleanups

2024-01-11 Thread Chris Plummer
On Mon, 8 Jan 2024 20:16:50 GMT, Chris Plummer wrote: > Fix some broken links and other minor cleanups: > > There are a few broken links in the javadoc for ObjectReference.java. For > example: > > > * Not all target VMs support this operation. See > * VirtualMachine#canGetMonitorIn

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

2024-01-11 Thread Alex Menkov
On Thu, 11 Jan 2024 16:14:39 GMT, Joachim Kern wrote: >> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with >> a maxValue (32 for IPv4, 128 otherwise). This fails if it is larger than >> 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set >>

Re: RFR: 8318707: Remove the Java Management Extension (JMX) Management Applet (m-let) feature [v4]

2024-01-11 Thread Kevin Walls
> Remove the MLet feature and its tests. > > Some tests use MLet classes but are not testing MLets. These are updated, to > use another test MBean or an MBean which is a URLClassLoader, e.g. > test/jdk/javax/management/MBeanServer/PostExceptionTest.java > test/jdk/javax/management/remote/mandato

Re: RFR: 8318707: Remove the Java Management Extension (JMX) Management Applet (m-let) feature [v3]

2024-01-11 Thread Kevin Walls
On Thu, 11 Jan 2024 12:23:37 GMT, Daniel Fuchs wrote: >> Hi Daniel - >> I am missing see how being a ClassLoader relates to the leak where the >> Introspector holds on to a reference to the most recent MBean. I didn't >> locate the jdk5 change, I only read a short synopsis. >> >> I can make t

Re: RFR: 8318707: Remove the Java Management Extension (JMX) Management Applet (m-let) feature [v3]

2024-01-11 Thread Kevin Walls
On Wed, 10 Jan 2024 14:02:25 GMT, Daniel Fuchs wrote: >> Kevin Walls has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove unnecessary MLET_ Properties > > test/jdk/javax/management/mxbean/MXBeanLoadingTest1.java line 85: > >> 83:

[jdk22] Integrated: 8322237: Heap dump contains duplicate thread records for mounted virtual threads

2024-01-11 Thread Alex Menkov
On Thu, 11 Jan 2024 00:59:08 GMT, Alex Menkov wrote: > Hi all, > > This pull request contains a backport of commit > [dd8ae616](https://github.com/openjdk/jdk/commit/dd8ae616437398f957f9b4f09cf2c7f1d0bd0938) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit bein

Re: RFR: 8323546: Clarify docs for Compiler.perfmap filename parameter, and other misc related jcmd doc cleanups [v3]

2024-01-11 Thread Chris Plummer
> The jcmd docs for Compiler.perfmap currently say: > > - *filename*: (Optional) The name of the map file (STRING, no default > value) > > However, there is a default, so not only should that be made more clear in > the above, but also some descriptive text as to how the default is generate

Re: RFR: 8323546: Clarify docs for Compiler.perfmap filename parameter, and other misc related jcmd doc cleanups [v3]

2024-01-11 Thread Chris Plummer
On Thu, 11 Jan 2024 22:11:00 GMT, Chris Plummer wrote: >> The jcmd docs for Compiler.perfmap currently say: >> >> - *filename*: (Optional) The name of the map file (STRING, no default >> value) >> >> However, there is a default, so not only should that be made more clear in >> the above,

[jdk22] RFR: 8321685: Missing ResourceMark in code called from JvmtiEnvBase::get_vthread_jvf

2024-01-11 Thread Serguei Spitsyn
Hi all, This pull request contains a clean backport of commit [2806adee](https://github.com/openjdk/jdk/commit/2806adee2d8cca6bc215f285888631799bd02eac) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Serguei Spitsyn on 10 Jan

Re: RFR: 8323546: Clarify docs for Compiler.perfmap filename parameter, and other misc related jcmd doc cleanups [v4]

2024-01-11 Thread Chris Plummer
> The jcmd docs for Compiler.perfmap currently say: > > - *filename*: (Optional) The name of the map file (STRING, no default > value) > > However, there is a default, so not only should that be made more clear in > the above, but also some descriptive text as to how the default is generate

Re: RFR: 8323546: Clarify docs for Compiler.perfmap filename parameter, and other misc related jcmd doc cleanups [v3]

2024-01-11 Thread Chris Plummer
On Thu, 11 Jan 2024 22:11:00 GMT, Chris Plummer wrote: >> The jcmd docs for Compiler.perfmap currently say: >> >> - *filename*: (Optional) The name of the map file (STRING, no default >> value) >> >> However, there is a default, so not only should that be made more clear in >> the above,

Re: [jdk22] RFR: 8321685: Missing ResourceMark in code called from JvmtiEnvBase::get_vthread_jvf

2024-01-11 Thread Alex Menkov
On Fri, 12 Jan 2024 00:47:20 GMT, Serguei Spitsyn wrote: > Hi all, > > This pull request contains a clean backport of commit > [2806adee](https://github.com/openjdk/jdk/commit/2806adee2d8cca6bc215f285888631799bd02eac) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The c

RFR: 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

2024-01-11 Thread sendaoYan
Reviewed-by: Yi Yang - Commit messages: - 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed Changes: https://git.openjdk.org/jdk/pull/17386/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17386