A followup to [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773).
Convert a bunch more tests to fetch the ThreadReference from a static field in
the debuggee. [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773)
focused on the easier tests that already had a static field, and the n
On Thu, 1 May 2025 00:26:27 GMT, Chris Plummer wrote:
> A followup to [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773).
> Convert a bunch more tests to fetch the ThreadReference from a static field
> in the debuggee. [JDK-8355773](https://bugs.openjdk.org/browse/JDK-8355773)
> focuse
On Wed, 30 Apr 2025 22:58:09 GMT, Igor Veresov wrote:
>> Improve warm-up time by making profile data from a previous run of an
>> application instantly available, when the HotSpot Java Virtual Machine
>> starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483)
>> to store me
On Fri, 25 Apr 2025 06:10:46 GMT, Chris Plummer wrote:
> As part of the work for
> [JDK-8353955](https://bugs.openjdk.org/browse/JDK-8353955) I am reducing the
> number of tests that need to be run with includevirtualhreads=y due to using
> JDI to lookup threads in the debuggee. There are many
On Wed, 30 Apr 2025 21:07:01 GMT, Chris Plummer wrote:
>> As part of the work for
>> [JDK-8353955](https://bugs.openjdk.org/browse/JDK-8353955) I am reducing the
>> number of tests that need to be run with includevirtualhreads=y due to using
>> JDI to lookup threads in the debuggee. There are
On Mon, 28 Apr 2025 17:35:13 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 32 commits:
>>
>> - Merge branch 'master' into pp2
>> - Fix class filtering
>> - Remove the workaround of
> Improve warm-up time by making profile data from a previous run of an
> application instantly available, when the HotSpot Java Virtual Machine
> starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483)
> to store method execution profiles from training runs, reducing profili
On Wed, 30 Apr 2025 20:59:23 GMT, Leonid Mesnik wrote:
>> Yes, as long as there is a good value captured, Windows should pass.
>> We could get into how many good values we should see, I might suggest 6 out
>> of 10? But that seems like a guessing game.
>> The breakage in this feature before mean
> Improve warm-up time by making profile data from a previous run of an
> application instantly available, when the HotSpot Java Virtual Machine
> starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483)
> to store method execution profiles from training runs, reducing profili
> As part of the work for
> [JDK-8353955](https://bugs.openjdk.org/browse/JDK-8353955) I am reducing the
> number of tests that need to be run with includevirtualhreads=y due to using
> JDI to lookup threads in the debuggee. There are many tests that lookup the
> "main" thread. They can instead
On Wed, 30 Apr 2025 18:33:31 GMT, Kevin Walls wrote:
>> test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java
>> line 60:
>>
>>> 58: // A good reading: forget any previous -1.
>>> 59: ex = null;
>>> 60: good++;
>>
>> The `ex =
On Sat, 26 Apr 2025 22:36:11 GMT, Vladimir Kozlov wrote:
>> Igor Veresov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove the proxy class counter
>
> src/hotspot/share/cds/archiveBuilder.cpp line 770:
>
>> 768: relocate_embedded
> Improve warm-up time by making profile data from a previous run of an
> application instantly available, when the HotSpot Java Virtual Machine
> starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483)
> to store method execution profiles from training runs, reducing profili
On Mon, 28 Apr 2025 19:13:07 GMT, Chris Plummer wrote:
>> As part of the work for
>> [JDK-8353955](https://bugs.openjdk.org/browse/JDK-8353955) I am reducing the
>> number of tests that need to be run with includevirtualhreads=y due to using
>> JDI to lookup threads in the debuggee. There are
On Mon, 28 Apr 2025 19:13:07 GMT, Chris Plummer wrote:
>> As part of the work for
>> [JDK-8353955](https://bugs.openjdk.org/browse/JDK-8353955) I am reducing the
>> number of tests that need to be run with includevirtualhreads=y due to using
>> JDI to lookup threads in the debuggee. There are
On Mon, 28 Apr 2025 07:44:04 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
On Mon, 28 Apr 2025 07:44:04 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
On Mon, 28 Apr 2025 07:44:04 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
On Fri, 25 Apr 2025 13:05:51 GMT, Radim Vansa wrote:
>> Radim Vansa has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Fix VerifyRawIndexesTest
>> - Fix reordering in layout and annotations
>> - Use qsort_r for different platforms
>
>
On Thu, 10 Apr 2025 06:41:42 GMT, Serguei Spitsyn wrote:
>> This fixes the issue with lack of synchronization between JVMTI thread
>> suspend and resume functions in a self-suspend case. More detailed fix
>> description is in the first PR comment.
>>
>> Testing: Ran mach5 tiers 1-6.
>
> Sergue
On Wed, 30 Apr 2025 17:44:13 GMT, Chris Plummer wrote:
>> This is hard to reproduce, and at first I'd only seen -1 returned on the
>> first calls to mbean.getProcessCpuLoad().
>> But eventually I observed a -1 at any time, including in middle of the
>> iterations, or on the last iteration which
On Wed, 30 Apr 2025 18:42:27 GMT, Kevin Walls wrote:
>> This is hard to reproduce, and at first I'd only seen -1 returned on the
>> first calls to mbean.getProcessCpuLoad().
>> But eventually I observed a -1 at any time, including in middle of the
>> iterations, or on the last iteration which m
> This is hard to reproduce, and at first I'd only seen -1 returned on the
> first calls to mbean.getProcessCpuLoad().
> But eventually I observed a -1 at any time, including in middle of the
> iterations, or on the last iteration which makes the current test fail.
>
> Should fail on Windows onl
On Wed, 30 Apr 2025 17:44:09 GMT, Chris Plummer wrote:
>> This is hard to reproduce, and at first I'd only seen -1 returned on the
>> first calls to mbean.getProcessCpuLoad().
>> But eventually I observed a -1 at any time, including in middle of the
>> iterations, or on the last iteration which
On Wed, 30 Apr 2025 11:13:53 GMT, Kevin Walls wrote:
> This is hard to reproduce, and at first I'd only seen -1 returned on the
> first calls to mbean.getProcessCpuLoad().
> But eventually I observed a -1 at any time, including in middle of the
> iterations, or on the last iteration which makes
On Mon, 28 Apr 2025 18:27:26 GMT, Chris Plummer wrote:
> In an effort go get rid of calls to Debugee.threadByName() or
> Debugee.threadByNameOrThrow(), I found that many tests store the thread being
> looked up in a static field of the debuggee. The test can fetch the
> ThreadReference from th
On Mon, 28 Apr 2025 18:27:26 GMT, Chris Plummer wrote:
> In an effort go get rid of calls to Debugee.threadByName() or
> Debugee.threadByNameOrThrow(), I found that many tests store the thread being
> looked up in a static field of the debuggee. The test can fetch the
> ThreadReference from th
On Thu, 24 Apr 2025 05:28:09 GMT, Chris Plummer wrote:
> nsk.share.jdi.Debugee.waitingEvent() takes a timeout argument. However, if
> the call to EventQueue.remove() times out and returns null, waitingEvent()
> just keep on retrying. The logic is incorrect for a null result. It should
> immedi
On Fri, 25 Apr 2025 06:17:38 GMT, Chris Plummer wrote:
>> nsk.share.jdi.Debugee.waitingEvent() takes a timeout argument. However, if
>> the call to EventQueue.remove() times out and returns null, waitingEvent()
>> just keep on retrying. The logic is incorrect for a null result. It should
>> im
On Wed, 30 Apr 2025 10:16:06 GMT, Radim Vansa wrote:
> @fparain Hi, could I bring your attention here? Thanks!
Sure, I'll take a look at it.
Thanks.
-
PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2841972655
On Wed, 30 Apr 2025 12:00:45 GMT, Robbin Ehn wrote:
>> Hi, for you to consider.
>>
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not
>> implemented'" for SA
On Wed, 30 Apr 2025 11:57:32 GMT, Robbin Ehn wrote:
> I don't see any alternatives - if this approach is not liked, any suggestions?
The changes seems fine to me. It's just a pity that this would only work for
riscv for now.
I guess we don't have a better choice given current status of qemu-use
> Hi, for you to consider.
>
> These tests constantly fails in qemu-user.
> Either the require host to be same arch explicit or implicit (sysroot).
> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'"
> for SA tests.
>
> From bug:
>> qemu-user/rv64 sets uarch to "qemu"
On Mon, 31 Mar 2025 10:45:54 GMT, Robbin Ehn wrote:
>> Hi, for you to consider.
>>
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not
>> implemented'" for SA
This is hard to reproduce, and at first I'd only seen -1 returned on the first
calls to mbean.getProcessCpuLoad().
But eventually I observed a -1 at any time, including in middle of the
iterations, or on the last iteration which makes the current test fail.
Should fail on Windows only if we only
On Mon, 28 Apr 2025 07:44:04 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
36 matches
Mail list logo
