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
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
>>
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
>>
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
> 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
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
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
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
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
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,
>
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
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
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
> 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
> 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
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`
>>
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
> 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
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
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
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 (
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
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
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
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
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
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
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
>
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
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
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
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
32 matches
Mail list logo