Re: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475

2024-07-10 Thread Matthias Baesken
On Tue, 9 Jul 2024 12:52:34 GMT, Thomas Stuefe wrote: > Checked and Alpine processes have a [heap] segment. Could you try that? Yes there is an entry [heap] in the file column of the lengthy table. Do you think this is present on all Linux platforms? If I replace the vdso with [heap] maybe

Re: RFR: 8335743: jhsdb jstack cannot print some information on the waiting thread [v2]

2024-07-10 Thread KIRIYAMA Takuya
On Mon, 8 Jul 2024 12:16:51 GMT, KIRIYAMA Takuya wrote: >> This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" >> was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161. >> >> When "jhdsb jstack" is executed, the stack and lock information are printed >>

Re: RFR: 8335743: jhsdb jstack cannot print some information on the waiting thread [v2]

2024-07-10 Thread duke
On Mon, 8 Jul 2024 12:16:51 GMT, KIRIYAMA Takuya wrote: >> This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" >> was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161. >> >> When "jhdsb jstack" is executed, the stack and lock information are printed >>

RFR: 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960

2024-07-10 Thread Christoph Langer
The change of JDK-8294960 has brought an increase of required metaspace for this test on AIX which seems to go beyond 23m in most cases. So I propose another slight increment. Why AIX needs more metaspace compared to other platforms is probably a different topic. - Commit messages

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v4]

2024-07-10 Thread Axel Boldt-Christmas
> When inflating a monitor the `ObjectMonitor*` is written directly over the > `markWord` and any overwritten data is displaced into a displaced `markWord`. > This is problematic for concurrent GCs which needs extra care or looser > semantics to use this displaced data. In Lilliput this data als

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v3]

2024-07-10 Thread Axel Boldt-Christmas
On Tue, 9 Jul 2024 20:44:58 GMT, Coleen Phillimore wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Add JVMCI symbol exports >> - Revert "More graceful JVMCI VM option interaction" >> >>This rever

Re: Proposal: Option to ignore non-existent -javaagent

2024-07-10 Thread Jaroslav Bachorik
On Mon, Jul 8, 2024 at 11:19 AM Alan Bateman wrote: > On 03/07/2024 11:26, Thiago Henrique Hupner wrote: > > Dear JDK developers, > > > > I'd like to propose adding an option that allows the JVM to ignore a > > non-existent -javaagent instead of aborting. > > > > Currently, if a -javaagent is spe

Re: Proposal: Option to ignore non-existent -javaagent

2024-07-10 Thread Alan Bateman
On 10/07/2024 16:37, Jaroslav Bachorik wrote: : This may not always be possible. Some systems have rather complex and inlexible launchers - for example Apache Spark with its clusters, drivers and executors and automatic distribution of resources. For that system, if one needs to add an on-sta

Re: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475

2024-07-10 Thread Thomas Stuefe
On Wed, 10 Jul 2024 07:15:38 GMT, Matthias Baesken wrote: > > Checked and Alpine processes have a [heap] segment. Could you try that? > > Yes there is an entry [heap] in the file column of the lengthy table. Do you > think this is present on all Linux platforms? If I replace the vdso with > [h

Re: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent

2024-07-10 Thread Chris Plummer
On Wed, 10 Jul 2024 06:46:56 GMT, Chris Plummer wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java >> line 356: >> >>> 354: } >>> 355: >>> 356: // We need to resume the main thread because thread2 >>> might be blocked on it, >

Re: RFR: 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960

2024-07-10 Thread Thomas Stuefe
On Wed, 10 Jul 2024 09:14:11 GMT, Christoph Langer wrote: > The change of JDK-8294960 has brought an increase of required metaspace for > this test on AIX which seems to go beyond 23m in most cases. So I propose > another slight increment. > > Why AIX needs more metaspace compared to other pla

Re: RFR: 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960

2024-07-10 Thread Matthias Baesken
On Wed, 10 Jul 2024 09:14:11 GMT, Christoph Langer wrote: > The change of JDK-8294960 has brought an increase of required metaspace for > this test on AIX which seems to go beyond 23m in most cases. So I propose > another slight increment. > > Why AIX needs more metaspace compared to other pla

Re: RFR: 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960

2024-07-10 Thread Thomas Stuefe
On Wed, 10 Jul 2024 11:24:14 GMT, Thomas Stuefe wrote: > There is nothing I know off-hand that would be AIX-specific. Or is it > PPC-specific? If the latter, does the delta go away with -Xint, or if you > only run with C1? > > Other than that, to analyze the problem, I would stop the test on a

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v5]

2024-07-10 Thread Axel Boldt-Christmas
> When inflating a monitor the `ObjectMonitor*` is written directly over the > `markWord` and any overwritten data is displaced into a displaced `markWord`. > This is problematic for concurrent GCs which needs extra care or looser > semantics to use this displaced data. In Lilliput this data als

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v4]

2024-07-10 Thread Volker Simonis
> Since Java 5 the `java.lang.instrument` package provides services that allow > Java programming language agents to instrument (i.e. modify the bytecode) of > programs running on the Java Virtual Machine. The `java.lang.instrument` > functionality is based and implemented on top of the native J

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v3]

2024-07-10 Thread Alan Bateman
On Tue, 9 Jul 2024 14:18:53 GMT, Volker Simonis wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow >> Java programming language agents to instrument (i.e. modify the bytecode) of >> programs running on the Java Virtual Machine. The `java.lang.instrument` >>

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v3]

2024-07-10 Thread Volker Simonis
On Wed, 10 Jul 2024 12:53:46 GMT, Alan Bateman wrote: >> Volker Simonis has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Addressed @AlanBateman's suggestions and updated copyright year > > src/java.instrument/share/classes/java/lang/instr

Re: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v3]

2024-07-10 Thread Albert Mingkun Yang
> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel. > As a result, the corresponding code in `SerialHeap` and > `ParallelScavengeHeap` share much similarity. > > The easiest way to review is to start from these two VM operations, > `VM_ParallelCollectForAllocation` a

Re: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v2]

2024-07-10 Thread Zhengyu Gu
On Mon, 8 Jul 2024 16:31:43 GMT, Albert Mingkun Yang wrote: >> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in >> Parallel. As a result, the corresponding code in `SerialHeap` and >> `ParallelScavengeHeap` share much similarity. >> >> The easiest way to review is to start f

Re: RFR: 8207908: JMXStatusTest.java fails assertion intermittently

2024-07-10 Thread Chris Plummer
On Thu, 4 Jul 2024 14:39:50 GMT, Kevin Walls wrote: > Test failure, reproducible running batches of tests at the same time on the > same machine. > The use of "jcmd TestApp ..." gathers more output than the test wants and > than its regexes can handle. > > Using the PID to match only the wante

Re: RFR: 8267887: RMIConnector_NPETest.java fails after removal of RMI Activation (JDK-8267123)

2024-07-10 Thread Chris Plummer
On Fri, 5 Jul 2024 14:06:39 GMT, Kevin Walls wrote: > The test > test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java > should be removed. > > This test was added when 6984520 was fixed in 6u25. It has been > problemlisted since JDK-8267123 removed RMI Activation (

Re: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent

2024-07-10 Thread Chris Plummer
On Wed, 10 Jul 2024 17:10:46 GMT, Chris Plummer wrote: >>> This does not look correct to me. >>> This is the last test scenario - thread2.resume should resumes the thread >>> while vm is suspended. >>> thread2 should not be blocked on main thread. >>> Looking at the debuggee I suppose the blocki

Re: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent

2024-07-10 Thread Alex Menkov
On Wed, 10 Jul 2024 20:50:50 GMT, Chris Plummer wrote: >> I was finally able to reproduce the issue with the stack dumping support in >> place. mainThread is in the middle of printing the 1st of the two logs >> mention above. mainThead is suspended and is holding a println related lock, >> and

Re: RFR: 8207908: JMXStatusTest.java fails assertion intermittently

2024-07-10 Thread Alex Menkov
On Thu, 4 Jul 2024 14:39:50 GMT, Kevin Walls wrote: > Test failure, reproducible running batches of tests at the same time on the > same machine. > The use of "jcmd TestApp ..." gathers more output than the test wants and > than its regexes can handle. > > Using the PID to match only the wante

Re: RFR: 8207908: JMXStatusTest.java fails assertion intermittently

2024-07-10 Thread Kevin Walls
On Thu, 4 Jul 2024 14:39:50 GMT, Kevin Walls wrote: > Test failure, reproducible running batches of tests at the same time on the > same machine. > The use of "jcmd TestApp ..." gathers more output than the test wants and > than its regexes can handle. > > Using the PID to match only the wante

Re: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent

2024-07-10 Thread Chris Plummer
On Wed, 10 Jul 2024 20:56:17 GMT, Alex Menkov wrote: >> I was able to add synchronization between the debugger and debuggee to fix >> this issue, but I don't really like the solution. It just adds more >> complexity and makes the test even harder to follow. What I'd like to do is >> just put a

Re: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent

2024-07-10 Thread Daniel D . Daugherty
On Wed, 10 Jul 2024 21:28:50 GMT, Chris Plummer wrote: >> Thank you for the confirming the reason of the timeout. >> >> To be more clear about my point: >> The test has 3 scenarios (see the test description): >> ThreadReference.resume() resumes the thread suspended with: >> * - with thread2.s

Re: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent

2024-07-10 Thread Chris Plummer
On Wed, 10 Jul 2024 22:29:08 GMT, Daniel D. Daugherty wrote: >> Removing log() statements to fix the problem can be risky because someone >> could re-add them in the future. What about my idea of doing a short sleep >> before the vm.suspend() to make sure the main thread has advanced to the >

Re: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent

2024-07-10 Thread David Holmes
On Wed, 10 Jul 2024 23:09:05 GMT, Chris Plummer wrote: >> Adding a `sleep()` between two statements does not scale when the test in >> question is under different loads or run with different options. All it will >> do >> is make a hang more rare (and frustrating to analyze). >> >> We do use sho

Integrated: 8335743: jhsdb jstack cannot print some information on the waiting thread

2024-07-10 Thread KIRIYAMA Takuya
On Fri, 5 Jul 2024 09:23:21 GMT, KIRIYAMA Takuya wrote: > This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" > was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161. > > When "jhdsb jstack" is executed, the stack and lock information are printed > in "s

[jdk23] RFR: 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt

2024-07-10 Thread Jaikiran Pai
I would like to backport this test-only change into `jdk23`. This cleans up the incorrect problem listing that was caused by a change that we introduced in JDK 23 as part of https://bugs.openjdk.org/browse/JDK-8333130. This is a clean backport of the commit that was integrated into master branch

Re: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent

2024-07-10 Thread Chris Plummer
On Thu, 11 Jul 2024 01:57:33 GMT, David Holmes wrote: >> I believe we've done quite a few short sleeps like this in the past. Scaling >> is not really an issue. It should only require at most a few ms, even with >> -Xcomp, so we wait 1000ms and then never have to think about the timing >> agai