On Thu, 11 Jul 2024 17:30:21 GMT, Alan Bateman wrote:
> Bringover some of the changes accumulated in the loom repo to the main line,
> most of these changes are test updates and have been baking in the loom repo
> for several months. The motive is partly to reduce the large set o
- Reimplement of JVMTI VThreadEvent test to improve reliability
> - Rename some tests to get consistent naming
> - Diagnostic output in several stress tests to help trace progress in the
> event of a timeout
>
> Testing: tier1-6
Alan Bateman has updated the pull request with a new ta
On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote:
> Before RC we need to update the man pages in the repo from their Markdown
> sources. All pages at a minimum have 23-ea replaced with 23, and publication
> year set to 2024 if needed.
>
> This also picks up the unpublished changes to
On Thu, 18 Jul 2024 10:52:43 GMT, Serguei Spitsyn wrote:
> Q: There are some new files with a copyright year ranges.
I will check but there are a few renames that have to keep the initial year.
Also there are some new files that have been checked into the loom repo for a
long time so they
On Thu, 18 Jul 2024 10:46:16 GMT, Serguei Spitsyn wrote:
>> Bringover some of the changes accumulated in the loom repo to the main line,
>> most of these changes are test updates and have been baking in the loom repo
>> for several months. The motive is partly to reduce the large set of
On Wed, 17 Jul 2024 14:07:55 GMT, Thomas Stuefe wrote:
>> Sonia Zaldana Calles has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updating copyright headers
>
> src/hotspot/share/services/diagnosticCommand.cpp line 1138:
>
>> 1136:
Bringover some of the changes accumulated in the loom repo to the main line,
most of these changes are test updates and have been baking in the loom repo
for several months. The motive is partly to reduce the large set of changes
that have accumulated in the loom repo, and partly to improve
On Mon, 15 Jul 2024 09:04:24 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test-only change which proposes to fix the
>> test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167?
>>
>> The JBS issue has comments which explains what causes the timeout. The
>> commit
On Mon, 15 Jul 2024 08:16:25 GMT, Jaikiran Pai wrote:
> Hello David,
>
> > @jaikiran there is a lot of unrelated refactoring and style changes here
> > that obscures what the actual fix is.
>
> I've updated the PR to undo some of the cosmetic changes that were introduced
> to cleanup the
On Fri, 12 Jul 2024 09:22:54 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only change which proposes to fix the
> test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167?
>
> The JBS issue has comments which explains what causes the timeout. The commit
> in
On Wed, 10 Jul 2024 20:10:13 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 16:56:37 GMT, Volker Simonis wrote:
>> src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java
>> line 179:
>>
>>> 177: * This means that a {@link LinkageError} triggered during
>>> transformation of
>>> 178: * {@code C} in a class {@code D} not
On Thu, 11 Jul 2024 15:38:29 GMT, Kevin Walls wrote:
>> Follow-on from JDK-8207908.
>>
>> Two tests are broken by that change:
>> sun/management/jmxremote/startstop/JMXStartStopTest.java
>> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java
>>
>> These are additional tests
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 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 Fri, 5 Jul 2024 07:28:13 GMT, Volker Simonis wrote:
> @AlanBateman would you mind having a quick look at this trivial,
> documentation-only PR and let me know if you're OK with it?
(Catching up as I was away for a few days).
I agree it would be useful to have an API note on this topic.
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 specified but the agent jar file doesn't
exist, the JVM aborts with an
On Tue, 25 Jun 2024 08:25:00 GMT, Kevin Walls wrote:
>> Man page update for JDK-8327793 which marked jstatd as deprecated for
>> removal in JDK 24.
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the last revision:
>
> text update
Marked as
On Fri, 21 Jun 2024 14:05:51 GMT, Kevin Walls wrote:
> Man page update for JDK-8327793 which marked jstatd as deprecated for removal
> in JDK 24.
I assume we should hold off reviewing until the warning and the experiment note
are combined.
-
PR Comment:
On Tue, 11 Jun 2024 21:09:14 GMT, Sean Mullan wrote:
>> I also think a period at the end is not necessary.
>
> For the Security Manager, the warning was worded a little differently:
>
> "WARNING: The Security Manager is deprecated and will be removed in a future
> release"
>
> I think that
On Wed, 19 Jun 2024 07:31:41 GMT, David Holmes wrote:
> I don't follow. We have checked vt is not null and not the carrier, so we do
> have it.
My comment was about the case where the thread dump happens during a transition
so sees the self-reference. In the loom repo the JavaThread has the
On Wed, 19 Jun 2024 06:18:12 GMT, David Holmes wrote:
> FWIW I would have kept the vt name just in case it does have one. But as Alan
> said that can be added in later if desired.
I suggested we drop this for now because the thread dump can happen at times
when there isn't a reference to the
On Tue, 18 Jun 2024 11:51:31 GMT, Inigo Mediavilla Saiz
wrote:
>> Follow up to https://github.com/openjdk/jdk/pull/19482 that was causing
>> issues when the PrintMountedVirtualTest.java was
>> running with `JTREG_TEST_THREAD_FACTORY=Virtual` in the loom repo.
>>
>> - Fixes issues where the
On Mon, 17 Jun 2024 13:24:23 GMT, Inigo Mediavilla Saiz
wrote:
>> Follow up to https://github.com/openjdk/jdk/pull/19482 that was causing
>> issues when the PrintMountedVirtualTest.java was
>> running with `JTREG_TEST_THREAD_FACTORY=Virtual` in the loom repo.
>>
>> - Fixes issues where the
On Mon, 17 Jun 2024 20:51:34 GMT, Kevin Walls wrote:
>> JMX uses APIs related to the Security Mananger which are deprecated. Use of
>> AccessControlContext will be removed when Security Manager is removed.
>>
>> Until then, updates are needed to not require setting
>>
On Mon, 17 Jun 2024 12:37:01 GMT, David Holmes wrote:
>> Follow up to https://github.com/openjdk/jdk/pull/19482 that was causing
>> issues when the PrintMountedVirtualTest.java was
>> running with `JTREG_TEST_THREAD_FACTORY=Virtual` in the loom repo.
>>
>> - Fixes issues where the test
On Mon, 17 Jun 2024 12:35:15 GMT, David Holmes wrote:
> We need a comment explaining why we have to check for this as without knowing
> the implementation quirks it seems non-sensical for a thread to have mounted
> itself!
Just to note that JavaThread._vthread is always the "current thread".
On Wed, 12 Jun 2024 08:45:46 GMT, Inigo Mediavilla Saiz
wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Remove
On Thu, 13 Jun 2024 14:37:45 GMT, Inigo Mediavilla Saiz
wrote:
> Would you mind explaining why unparking the main (virtual) thread can end up
> with the main thread observing the dummy thread in transition ?
The unpark of main requires queueing the task for main. This can trigger a new
FJP
On Wed, 12 Jun 2024 08:45:46 GMT, Inigo Mediavilla Saiz
wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Remove
On Wed, 12 Jun 2024 14:23:07 GMT, Daniel Fuchs wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> udpates
>
> test/jdk/javax/management/remote/mandatory/notif/policy.negative line 7:
>
>> 5: permission
On Wed, 12 Jun 2024 07:14:59 GMT, Inigo Mediavilla Saiz
wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Fix scope
On Tue, 11 Jun 2024 21:05:38 GMT, Inigo Mediavilla Saiz
wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Require
On Tue, 11 Jun 2024 18:11:55 GMT, Kevin Walls wrote:
>> jstatd is an RMI server application which monitors HotSpot VMs, and provides
>> an interface to the monitoring tool jstat, for use across a remote RMI
>> connection.
>>
>> RMI is not how modern applications communicate. It is an old
On Tue, 11 Jun 2024 16:54:36 GMT, Kevin Walls wrote:
>> jstatd is an RMI server application which monitors HotSpot VMs, and provides
>> an interface to the monitoring tool jstat, for use across a remote RMI
>> connection.
>>
>> RMI is not how modern applications communicate. It is an old
On Tue, 11 Jun 2024 16:52:13 GMT, Kevin Walls wrote:
> Sure, happy to not add annotations in sun.jvmstat.monitor.remote
> (RemoteHost.java, RemoteVm.java).
Right, you can drop it from all the source files except for module-info.java.
-
PR Comment:
On Tue, 11 Jun 2024 13:09:06 GMT, Kevin Walls wrote:
> jstatd is an RMI server application which monitors HotSpot VMs, and provides
> an interface to the monitoring tool jstat, for use across a remote RMI
> connection.
>
> RMI is not how modern applications communicate. It is an old transport
On Mon, 10 Jun 2024 07:36:50 GMT, Inigo Mediavilla Saiz
wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request with a new target base due
> to a merge or a rebase. The incremental webrev excludes
On Tue, 4 Jun 2024 08:06:28 GMT, Alan Bateman wrote:
>> Inigo Mediavilla Saiz has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Cleanup test
>>
>>- Stop virtualthread
>>- Remo
On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls wrote:
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
>
On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in
> java.1) are handled separately.
>
> This initial generation also picks up the unpublished
On Wed, 5 Jun 2024 15:58:28 GMT, Thomas Stuefe wrote:
>> Thanks !
>>
>> Your PR looks very promising @tstuefe, I would indeed prefer to wait for
>> your changes as a way to add additional indentation to the stack of the
>> virtual thread.
>>
>> What do you think if I leave the current PR
On 05/06/2024 07:45, Iñigo Mediavilla wrote:
Thanks, Alan. Sorry, I wasn't clear in my message. I wasn't thinking
about including unmounted threads in the output of `Thread.print`, I
agree with you that besides the formatting things that still need to
be fixed there's no need to add more
On 04/06/2024 21:52, Iñigo Mediavilla wrote:
Hello,
While there's ongoing work on:
https://github.com/openjdk/jdk/pull/19482
to add the stack trace of mounted virtual threads to the `jcmd
Thread.print` command, I'm starting to think about how I could do to
print the stack trace for virtual
On Wed, 5 Jun 2024 01:21:36 GMT, Nizar Benalla wrote:
>> This is a simple noreg cleanup. The motivation was that I noticed javac
>> doesn't recognise package.html files well.
>>
>> Some of the contents of the `package.html` files (and code in the package)
>> may be outdated, but I think it is
On Mon, 27 May 2024 09:01:48 GMT, Nizar Benalla wrote:
>> This is a simple noreg cleanup. The motivation was that I noticed javac
>> doesn't recognise package.html files well.
>>
>> Some of the contents of the `package.html` files (and code in the package)
>> may be outdated, but I think it
On Tue, 4 Jun 2024 07:25:41 GMT, Inigo Mediavilla Saiz wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with two
> additional commits since the last revision:
>
> - Cleanup
On Tue, 4 Jun 2024 06:38:36 GMT, Serguei Spitsyn wrote:
>> The intent is to provide a definition of what a null pointer is, for both C
>> and C++ programs. Is there a better place to do that so that elsewhere the
>> spec can simply to refer to "a null pointer" or "null"?
>
> Thanks, David. I
On Mon, 3 Jun 2024 11:26:27 GMT, Inigo Mediavilla Saiz wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add
On Thu, 30 May 2024 01:13:20 GMT, SendaoYan wrote:
>> Hi all,
>> ObjectMonitorUsage.java failed with `unexpected waiter_count` after
>> [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
>> There are two changes in this PR:
>> 1. In
On Fri, 31 May 2024 02:07:25 GMT, David Holmes wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> I'd probably give preference to the stack of the virtual thread, as the stack
> of the carrier when a vthread is mounted is generally quite
On Thu, 30 May 2024 14:13:34 GMT, Inigo Mediavilla Saiz
wrote:
> Print the stack traces of mounted virtual threads when calling `jcmd
> Thread.print`.
Thanks for take this one. Here's the result with the changes in 1a75277e.
"ForkJoinPool-1-worker-1" #25 [33795] daemon prio=5 os_prio=31
On Thu, 30 May 2024 06:51:54 GMT, David Holmes wrote:
>> Hopefully the ports will catch up someday and the alternative implementation
>> can be removed.
>>
>> We decided not to rename java.lang.VirtualThread when introducing the
>> alternative implementation as it's just too disruptive. The
On Thu, 30 May 2024 06:14:21 GMT, David Holmes wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> change from java_lang_VirtualThread::is_instance(thread_oop) to
>> hread_oop->is_a(vmClasses::BaseVirtualThread_klass())
On Wed, 29 May 2024 20:17:30 GMT, Chris Plummer wrote:
> Fixed broken javadoc link. I confirmed that it currently is broken as can be
> seen in the JDK 22 javadocs:
>
> https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/jdk.jdi/com/sun/jdi/VirtualMachine.html#allThreads()
>
>
I don't know if Alex Menkov is subscribed here, better to ask on
serviceability-dev.
-Alan
On 28/05/2024 11:03, Iñigo Mediavilla wrote:
On Tue, May 28, 2024 at 11:28 AM Iñigo Mediavilla
wrote:
Hello,
I've been looking at possible tickets that I could work on under
the
On Sun, 26 May 2024 14:24:27 GMT, SendaoYan wrote:
> > That would mean it's not tested. I suspect the
> > java_lang_VirtualThread::is_instance checks will need to be changed to test
> > with is_a(vmClasses::BaseVirtualThread_klass()) to allow for the
> > alternative implementation.
>
> Do
On Sun, 26 May 2024 09:27:00 GMT, SendaoYan wrote:
> Hi all,
> ObjectMonitorUsage.java failed with `unexpected waiter_count` after
> [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
> It should be predicated with `@requires vm.continuations` to be skipped.
>
>
On Fri, 24 May 2024 18:11:18 GMT, Nizar Benalla wrote:
> This is a simple noreg cleanup. The motivation was that I noticed javac
> doesn't recognise package.html files well.
>
> Some of the contents of the `package.html` files (and code in the package)
> may be outdated, but I think it is out
On Wed, 15 May 2024 20:29:17 GMT, Serguei Spitsyn wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads are not
>> listed in the
On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth wrote:
> Further, I confirm that if I pass that option to jlink or jpackage when
> creating a custom runtime, there is no warning.
Great! What about jpackage without a custom runtime, wondering if
--java-options can be tested.
-
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end
On Mon, 20 May 2024 18:39:31 GMT, Phil Race wrote:
>> make/conf/module-loader-map.conf line 105:
>>
>>> 103: java.smartcardio \
>>> 104: jdk.accessibility \
>>> 105: jdk.attach \
>>
>> The list of allowed modules has been rewritten from scratch, by looking at
>> the set of modules
On Thu, 16 May 2024 08:25:17 GMT, Kevin Walls wrote:
>>> > ...Is there any way to run jconsole in a way that would result in it
>>> > passing a non-empty delegationSubjects, resulting in this issue still
>>> > reproducing?
>>>
>>> I don't think there is, JConsole has a hard null in this call.
On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik wrote:
>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while
>> current thread is in native thread state.
>>
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>>
On Thu, 16 May 2024 10:39:43 GMT, Nizar Benalla wrote:
> Please review this change. I converted the `package.html` file to
> `package-info.java`, because `javac` cannot recognize `package.html`.
> I already brought this up [in the mailing
>
On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls wrote:
>> Running JConsole from a previous JDK, and attaching to jdk-23 (after
>> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
>> Management Extension (JMX) Subject Delegation feature), the MBean tab is
>> blank.
>>
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Fri, 17 May 2024 00:38:07 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmti.xml line 1008:
>>
>>> 1006: function descriptions. Empty lists, arrays, sequences, etc are
>>> 1007: returned as nullptr which is C programming language
>>> 1008: null pointer.
>>
>> Perhaps
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Thu, 16 May 2024 02:37:40 GMT, Serguei Spitsyn wrote:
> The following RFE was fixed recently:
> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with
> nullptr in JVMTI generated code
>
> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI
> agents
On Wed, 15 May 2024 10:40:34 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Wed, 15 May 2024 10:34:01 GMT, Maurizio Cimadamore
wrote:
> I don't fully agree that this option is not module related (which is why I
> gave it that name). The very definition of illegal native access is related
> to native access occurring from a module that is outside a specific set. So
On 15/05/2024 09:16, Magnus Ihse Bursie wrote:
On 2024-05-15 02:13, Nizar Benalla wrote:
Hello,
I discovered after some recent work around javadoc that `javac` does
not recognize `package.html` files, which predate
`package-info.java`. Some tools that want to analyze doc comments
need
On Wed, 15 May 2024 00:54:43 GMT, David Holmes wrote:
>> src/hotspot/share/runtime/arguments.cpp line 2271:
>>
>>> 2269: } else if (match_option(option, "--illegal-native-access=",
>>> )) {
>>> 2270: if (!create_module_property("jdk.module.illegal.native.access",
>>> tail,
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Sun, 12 May 2024 01:58:38 GMT, Nizar Benalla wrote:
> Please review this simple change where I add `@since` tags to the
> package-info file of the following packages
> ```com.sun.jdi
> com.sun.jdi.connect
> com.sun.jdi.connect.spi
> com.sun.jdi.event
> com.sun.jdi.request
>
> I used the
On Fri, 3 May 2024 18:31:21 GMT, Chris Plummer wrote:
> What "debugging option" are you referring to.
`-Djdk.tracePinnedThreads=full`. When this system property is set then it means
the onPinned callback is running the printing code. This is happen in a
transition when running with JVMTI
On Thu, 2 May 2024 22:40:02 GMT, Chris Plummer wrote:
> It seems maybe we should instead be trying to avoid these events by
> preloading the classes as was suggested as an option in the CR.
I don't think preloading PinnedThreadPrinter will solve it completely. First
usage could potentially
On Thu, 2 May 2024 21:44:43 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: Corrections in: 1) JVMTI/JDWP spec; 2) test vthread checks; 3)
>> test comments
>
>
On Thu, 2 May 2024 07:33:09 GMT, Serguei Spitsyn wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads are not
>> listed in the
On Mon, 18 Mar 2024 23:45:29 GMT, Serguei Spitsyn wrote:
>> Please, review this fix correcting the JVMTI `RawMonitorWait()`
>> implementation.
>> The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to
>> update the interrupt status of the interrupted waiting thread. The issue
On Mon, 18 Mar 2024 16:47:24 GMT, Bill Huang wrote:
> This task addresses an essential aspect of our testing infrastructure: the
> proper handling and cleanup of temporary files and socket files created
> during test execution. The motivation behind these changes is to prevent the
>
On Sat, 16 Mar 2024 22:33:49 GMT, Serguei Spitsyn wrote:
>> Please, review this fix correcting the JVMTI `RawMonitorWait()`
>> implementation.
>> The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to
>> update the interrupt status of the interrupted waiting thread. The issue
On Fri, 8 Mar 2024 10:12:06 GMT, Matthias Baesken wrote:
> There are a number of places remaining in the linux/macOS native JDK codebase
> where we use the RESTARTABLE macro with close, but this is unwanted on
> Linux/macOS.
src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c line 200:
On Fri, 8 Mar 2024 05:56:24 GMT, Serguei Spitsyn wrote:
> > Can you check if
> > vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/TestDescription.java
> > is passing now? That test is a bit annoying in that it fails every time we
> > touch j.l.Object so you might have to update
> >
On Thu, 7 Mar 2024 06:45:01 GMT, David Holmes wrote:
>> Fixed as suggested by Alan.
>>
>>> Also need to think through if Object.wait will need to be changed as part
>>> of this.
>>
>> Still need to look at this.
>
> Use of `ObjectLocker` here will introduce a new pinning point for Loom. We
>
On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Thu, 7 Mar 2024 00:13:56 GMT, Serguei Spitsyn wrote:
>> Please, review this fix correcting the JVMTI `RawMonitorWait()`
>> implementation.
>> The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to
>> update the interrupt status of the interrupted waiting thread. The issue
On Wed, 6 Mar 2024 10:44:15 GMT, Serguei Spitsyn wrote:
>> Please, review this fix correcting the JVMTI `RawMonitorWait()`
>> implementation.
>> The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to
>> update the interrupt status of the interrupted waiting thread. The issue
On Wed, 6 Mar 2024 15:45:16 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Wed, 6 Mar 2024 14:25:09 GMT, Matthias Baesken wrote:
> We could maybe also use the existing
> https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/include/jni_md.h
> - what do you think ?
jni_md.h goes into the JDK run-time image (for jni.h to include) so I don't
think we
On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken wrote:
> We define the RESTARTABLE macro again and again at a lot of places in the JDK
> native codebase. This could be centralized to avoid repeating it again and
> again !
src/java.base/share/native/libjava/jni_util.h line 243:
> 241: }
On Wed, 6 Mar 2024 09:14:18 GMT, Serguei Spitsyn wrote:
>> Please, review this fix correcting the JVMTI `RawMonitorWait()`
>> implementation.
>> The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to
>> update the interrupt status of the interrupted waiting thread. The issue
On Tue, 5 Mar 2024 01:06:32 GMT, Serguei Spitsyn wrote:
>>> AFAIK, as it is not a good idea to post the JVMTI events recursively
>>
>> We already do. When the debug agent is handling a JVMTI event and
>> RawMonitorWait is interrupted, that results in the debug agent later on
>> calling
On Mon, 4 Mar 2024 13:24:05 GMT, Kevin Walls wrote:
>> The deprecated Subject Delegation feature in JMX will be removed.
>>
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the
core-libs-dev is the place to send this.
-Alan
On 04/03/2024 12:11, S A wrote:
Hi all,
after moving our application to Java 21 (up from Java 17), we noticed
a class loader leak. A memory snapshot points to a ProtectionDomain
object held by a ForkJoinWorkerThread, the protection domain holds
1 - 100 of 577 matches
Mail list logo
