On Thu, 29 May 2025 07:58:41 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Fri, 23 May 2025 19:37:15 GMT, Serguei Spitsyn wrote:
> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file
> bytes with the result returned by JNI `GetByteArrayElements()`. It violates
> the JVMTI `Class
On Fri, 23 May 2025 19:37:15 GMT, Serguei Spitsyn wrote:
> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file
> bytes with the result returned by JNI `GetByteArrayElements()`. It violates
> the JVMTI `Class
> This is the code for the [JEP 509: CPU Time based profiling for
> JFR](https://openjdk.org/jeps/509).
>
> Currently tested using [this test
> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
> profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... d
ignore this... apologies
On 5/29/25 11:51 AM, Laurence Cable wrote:
https://github.com/openjdk/jdk/pull/25526
On 5/29/25 11:05 AM, Kevin Walls wrote:
OK thanks Philippe, and Larry -
I can't provoke a problem as it stands but yes it would be good to
take the recommendation of the API Note, th
Please review this small fix to update pipe mode for attach operation
communication.
- `FILE_FLAG_FIRST_PIPE_INSTANCE`: there is "retry" logic if pipe creation
failed [1], with this flag `CreateNamedPipe` fails when pipe with the same name
already exists;
- `PIPE_REJECT_REMOTE_CLIENTS`: attach w
On Wed, 28 May 2025 18:51:09 GMT, Aleksey Shipilev wrote:
> SonarCloud reports an issue since
> [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) integration:
> duplicate index in `metadataTypeArray` initialization code. Looks like a
> simple typo, this PR fixes it.
>
> Additional t
On Thu, 29 May 2025 18:10:55 GMT, Leonid Mesnik wrote:
>> Based on the log output, the test failure seems to be the result of two
>> threads trying to set and access variables that are not volatile, so I've
>> made them volatile. Since I can't reproduce the failure, I can't confirm
>> that it
https://github.com/openjdk/jdk/pull/25526
On 5/29/25 11:05 AM, Kevin Walls wrote:
OK thanks Philippe, and Larry -
I can't provoke a problem as it stands but yes it would be good to
take the recommendation of the API Note, that should keep us
efficient. 8-)
I created a JBS issue: https://bug
On Tue, 20 May 2025 20:10:20 GMT, Chris Plummer wrote:
> Extend try block to cover debuggee.classByname() call. I would suggest
> disabling whitespace diffs when doing the review. It makes code movement and
> deletions more obvious.
>
> There are a number of places where I removed a try/catch
probably makes sense to fix regardless... my bad
On 5/29/25 3:21 AM, Kevin Walls wrote:
Hi --
Just to be clear, is this an actual persistent leak that we can
observe, or is it that we could close earlier with try-with-resources?
I'm not seeing a leak when calling a line like this over and over
On Thu, 29 May 2025 18:21:11 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Thu, 29 May 2025 07:57:57 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with five additional
>> commits since the last revision:
>>
>> - removed retry_handshake logic
>> - removed AbstractOwnableSynchronizer.exclusiveOwnerThread support
>> - cleanup
> This is first (hotspot) part of the update for
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
> include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.
On Thu, 29 May 2025 17:57:09 GMT, Kevin Walls wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update src/hotspot/share/services/threadService.cpp
>>
>> Co-authored-by: David Holmes
>> <62092539+dholmes-...@use
On Thu, 29 May 2025 08:53:44 GMT, Alan Bateman wrote:
>> Let's check the logic before and now:
>> - before:
>>`walk_cont = _java_thread != nullptr && !is_virtual &&
>> _thread->vthread_continuation() != nullptr`
>> - now:
>>`walk_cont = _java_thread != nullptr && _thread->vthread_conti
On Fri, 23 May 2025 19:37:15 GMT, Serguei Spitsyn wrote:
> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file
> bytes with the result returned by JNI `GetByteArrayElements()`. It violates
> the JVMTI `Class
On 29.05.25 12:21, Kevin Walls wrote:
Hi --
Just to be clear, is this an actual persistent leak that we can observe, or is
it that we could close earlier with try-with-resources?
I'm not seeing a leak when calling a line like this over and over in a tight
loop:
final var cmdline = Files
On Wed, 14 May 2025 18:54:49 GMT, Chris Plummer wrote:
> Based on the log output, the test failure seems to be the result of two
> threads trying to set and access variables that are not volatile, so I've
> made them volatile. Since I can't reproduce the failure, I can't confirm that
> it is n
> Extend try block to cover debuggee.classByname() call. I would suggest
> disabling whitespace diffs when doing the review. It makes code movement and
> deletions more obvious.
>
> There are a number of places where I removed a try/catch of
> InterruptedException around a Thread.sleep. This wi
OK thanks Philippe, and Larry -
I can't provoke a problem as it stands but yes it would be good to take the
recommendation of the API Note, that should keep us efficient. 8-)
I created a JBS issue: https://bugs.openjdk.org/browse/JDK-8358088
Thanks!
Kevin
From:
actually so did I ...
On 5/29/25 11:05 AM, Kevin Walls wrote:
OK thanks Philippe, and Larry -
I can't provoke a problem as it stands but yes it would be good to
take the recommendation of the API Note, that should keep us
efficient. 8-)
I created a JBS issue: https://bugs.openjdk.org/brows
On Wed, 14 May 2025 18:54:49 GMT, Chris Plummer wrote:
> Based on the log output, the test failure seems to be the result of two
> threads trying to set and access variables that are not volatile, so I've
> made them volatile. Since I can't reproduce the failure, I can't confirm that
> it is n
> This is first (hotspot) part of the update for
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
> include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.
On Thu, 29 May 2025 17:02:09 GMT, Chris Plummer wrote:
>> Extend try block to cover debuggee.classByname() call. I would suggest
>> disabling whitespace diffs when doing the review. It makes code movement and
>> deletions more obvious.
>>
>> There are a number of places where I removed a try/c
On Thu, 29 May 2025 20:42:41 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionEvent/_itself_/exevent008.java
>> line 83:
>>
>>> 81: private ReferenceType rType, rTypeEx;
>>> 82: private String cmd;
>>> 83: private volatile int counter1 = 0, counter2 = 0;
>
> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and
> jcmd Thread.dump_to_file to include thread state and lock information. Also
> update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a
> description of the JSON format dump as that format is inten
On Sun, 25 May 2025 06:21:05 GMT, Alan Bateman wrote:
>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and
>> jcmd Thread.dump_to_file to include thread state and lock information. Also
>> update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a
>>
Hi --
Just to be clear, is this an actual persistent leak that we can observe, or is
it that we could close earlier with try-with-resources?
I'm not seeing a leak when calling a line like this over and over in a tight
loop:
final var cmdline = Files.lines(path).findFirst();
Thanks!
Kevin
_
On Tue, 20 May 2025 20:24:25 GMT, Chris Plummer wrote:
>> The references are still correct, as we haven't changed the struct layout.
>> We're also not planning on doing so. I don't think that there is a bug here.
>
> Ok. It's just unusual to see constants like these that are needed by SA but
>
On Thu, 22 May 2025 17:55:07 GMT, Johan Sjölen wrote:
>> Hi,
>>
>> The constant pool currently has a lot of methods specific to extracting
>> parts of the operands array. What this array actually is, is a sequence of
>> bootstrap method attribute entries, where each entry has the following
>
On Thu, 29 May 2025 05:52:53 GMT, David Holmes wrote:
>>> Why this change?
>> To be more clear about the change:
>> We need JvmtiVTMSTransitionDisabler for virtual threads only, for platform
>> threads handshake is enough. And currently for platform threads
>> JvmtiVTMSTransitionDisabler disabl
On Thu, 29 May 2025 08:01:00 GMT, Alex Menkov wrote:
>> src/hotspot/share/services/threadService.cpp line 1296:
>>
>>> 1294: }
>>> 1295:
>>> 1296: bool walk_cont = (_java_thread != nullptr) &&
>>> (_java_thread->vthread_continuation() != nullptr);
>>
>> Can you double check this? It l
On Thu, 29 May 2025 07:58:41 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Thu, 29 May 2025 03:26:49 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Thu, 29 May 2025 08:12:35 GMT, Alan Bateman wrote:
>> The logic is the same as before.
>> The problem is the variable name. it's `bool vthread_carrier` argument of
>> vframeStream ctor. Will change the name
>
> Something isn't right here. Are you sure walk_cont is correctly for the
> mounted
On Fri, 9 May 2025 22:34:45 GMT, Chen Liang wrote:
>> For early eval; test by changing the ClassReader max accepted version of
>> test ASM to 24 instead of 25
>
> Chen Liang has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unr
> This is first (hotspot) part of the update for
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
> include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.
On Thu, 29 May 2025 07:19:45 GMT, Alan Bateman wrote:
>> Alex Menkov has updated the pull request incrementally with five additional
>> commits since the last revision:
>>
>> - removed retry_handshake logic
>> - removed AbstractOwnableSynchronizer.exclusiveOwnerThread support
>> - cleanup
>>
On Wed, 28 May 2025 07:35:55 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1160:
>
>> 1158:
>> 1159: Type _typ
On Thu, 29 May 2025 03:26:49 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Thu, 29 May 2025 08:26:07 GMT, Serguei Spitsyn wrote:
>> Something isn't right here. Are you sure walk_cont is correctly for the
>> mounted virtual thread case? There are several tests failing now.
>
> Let's check the logic before and now:
> - before:
>`walk_cont = _java_thread != nullpt
On Tue, 20 May 2025 20:10:20 GMT, Chris Plummer wrote:
> Extend try block to cover debuggee.classByname() call. I would suggest
> disabling whitespace diffs when doing the review. It makes code movement and
> deletions more obvious.
>
> There are a number of places where I removed a try/catch
On Thu, 29 May 2025 21:39:37 GMT, Alex Menkov wrote:
>> Thanks for explanation. Can you please add corresponding comment. The
>> volatile counters are rare thing...
>
> I think the evaluation is not correct (lack of synchronization is an issue
> too).
> main thread also writes the value and I t
On Thu, 29 May 2025 21:18:03 GMT, Leonid Mesnik wrote:
>> Since there is only one writer thread, volatile should be sufficient. The
>> only requirement is to make writes visible to the reader thread. volatile
>> accomplishes that.
>
> Thanks for explanation. Can you please add corresponding com
> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file
> bytes with the result returned by JNI `GetByteArrayElements()`. It violates
> the JVMTI `ClassFileLoadHook` spec saying:
>
> "The agent must allocate t
On Thu, 29 May 2025 19:53:50 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: add a call to ReleaseByteArrayElements to new function
>> jni_array_to_jvmti_allocated
>
> test/lib/jdk/te
On Thu, 29 May 2025 19:50:33 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: add a call to ReleaseByteArrayElements to new function
>> jni_array_to_jvmti_allocated
>
> test/lib/jdk/test
On Fri, 30 May 2025 05:25:56 GMT, Serguei Spitsyn wrote:
>> This update is fixing a couple of `nsk/jvmti/ scenarios` tests.
>> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file
>> bytes with the result returned by JNI `GetByteArrayElements()`. It violates
>> the JVMTI `C
> This is the code for the [JEP 509: CPU Time based profiling for
> JFR](https://openjdk.org/jeps/509).
>
> Currently tested using [this test
> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
> profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... d
> Based on the log output, the test failure seems to be the result of two
> threads trying to set and access variables that are not volatile, so I've
> made them volatile. Since I can't reproduce the failure, I can't confirm that
> it is now fixed, but the lack of volatile is clearly a bug so sh
On Fri, 30 May 2025 01:12:34 GMT, Chris Plummer wrote:
>> I think the evaluation is not correct (lack of synchronization is an issue
>> too).
>> main thread also writes the value and I think this is the problem here.
>> Look at line 148 - it resets `counter1` instead of `counter2` and this
>> h
52 matches
Mail list logo
