On Tue, 16 May 2023 06:04:42 GMT, Serguei Spitsyn wrote:
>> test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java
>> line 107:
>>
>>> 105: testTaskThread =
>>> Thread.ofPlatform().name("TestTaskThread").start(testTask);
>>> 106: }
>>> 10
On Tue, 16 May 2023 01:57:39 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> moved Thread.interrupted() in StopThreadTest.java above a couple of lines
>
> test/hotspot/jtreg/serviceability/jvm
> This is newly integrated test times out because it has a race in in the Test
> #A.1 and #A.2.
> The main root cause is a print statement which can case target virtual thread
> to unpark and unmount.
> This causes that the `StopThreads` unexpectedly fails with the
> `JVMTI_ERROR_OPAQUE_FRAME` e
On Fri, 12 May 2023 09:15:47 GMT, Kevin Walls wrote:
>> Java Discovery Protocol (perhaps a hidden feature, but maybe should be more
>> widely known!) and -XX:-UsePerfData together cause a failure to startup.
>>
>> PerfData is the mechanism for communicating the URL and other properties for
>>
On Thu, 11 May 2023 18:32:36 GMT, Guoxiong Li wrote:
> Hi all,
>
> This patch revises the code of `ps_proc.c::process_get_lwp_regs`
> to use `PTRACE_GETREGSET` first instead of `PTRACE_GETREGS`.
> The `PTRACE_GETREGS` is not present on all architectures as the man page
> states [1].
> And if we
On Mon, 15 May 2023 23:12:52 GMT, Paul Hohensee wrote:
>> Please review this addition to com.sun.management.ThreadMXBean that returns
>> the total number of bytes allocated on the Java heap since JVM launch by
>> both terminated and live threads.
>>
>> Because this PR adds a new interface meth
On Mon, 8 May 2023 02:15:03 GMT, David Holmes wrote:
>> Paul Hohensee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8304074: [JMX] Add an approximation of total bytes allocated on the Java
>> heap by the JVM
>
> src/jdk.management/sha
On Tue, 9 May 2023 01:40:20 GMT, Paul Hohensee wrote:
>> src/hotspot/share/runtime/atomic.hpp line 310:
>>
>>> 308:
>>> 309: // Platform-specific implementation of add. Support for sizes of 4
>>> 310: // and 8 bytes are required. The class must be default
>>> constructable,
>>
>> Commen
On Mon, 15 May 2023 08:34:53 GMT, David Holmes wrote:
>> Paul Hohensee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8304704: In getTotalThreadAllocatedBytes javadoc, 'launched' -> 'started'
>
> src/hotspot/share/services/#allocationSi
On Tue, 16 May 2023 01:23:41 GMT, Serguei Spitsyn wrote:
>> This is newly integrated test times out because it has a race in in the Test
>> #A.1 and #A.2.
>> The main root cause is a print statement which can case target virtual
>> thread to unpark and unmount.
>> This causes that the `StopThre
On Tue, 16 May 2023 00:08:43 GMT, Leonid Mesnik wrote:
>> The fix excludes svc tests which should be updated to work with the virtual
>> threads factory.
>> Also, ProcessTools updated to skip '-m' '--module' execution, which could
>> not be run with test thread factory
>
> Leonid Mesnik has upd
On Tue, 16 May 2023 01:23:41 GMT, Serguei Spitsyn wrote:
>> This is newly integrated test times out because it has a race in in the Test
>> #A.1 and #A.2.
>> The main root cause is a print statement which can case target virtual
>> thread to unpark and unmount.
>> This causes that the `StopThre
> This is newly integrated test times out because it has a race in in the Test
> #A.1 and #A.2.
> The main root cause is a print statement which can case target virtual thread
> to unpark and unmount.
> This causes that the `StopThreads` unexpectedly fails with the
> `JVMTI_ERROR_OPAQUE_FRAME` e
On Mon, 15 May 2023 21:41:11 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> moved Thread.interrupted() in StopThreadTest.java above a couple of lines
>
> test/hotspot/jtreg/serviceability/jvm
On Mon, 15 May 2023 21:44:37 GMT, Chris Plummer wrote:
>> This is newly integrated test times out because it has a race in in the Test
>> #A.1 and #A.2.
>> The main root cause is a print statement which can case target virtual
>> thread to unpark and unmount.
>> This causes that the `StopThread
On Fri, 12 May 2023 02:14:00 GMT, Patricio Chilano Mateo
wrote:
> The following patch fixes a bug introduced while refactoring the
> VirtualThreadStart/End events. Specifically, the code to delete the
> JvmtiThreadState of a terminating vthread was moved before we start the VTMS
> transition.
On Mon, 15 May 2023 23:03:00 GMT, Chris Plummer wrote:
>> Currently kill001 assumes that JVMTI StopThread (via JDI
>> ThreadReference.stop) is not supported for virtual threads.
>> [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding support
>> for StopThread on a virtual threa
On Mon, 15 May 2023 23:14:37 GMT, Chris Plummer wrote:
>> test/lib/jdk/test/lib/process/ProcessTools.java line 402:
>>
>>> 400: final List unsupportedArgs = List.of(
>>> 401: "-jar", "-cp", "-classpath", "--class-path",
>>> "--describe-module", "-d",
>>> 402: "
> The fix excludes svc tests which should be updated to work with the virtual
> threads factory.
> Also, ProcessTools updated to skip '-m' '--module' execution, which could not
> be run with test thread factory
Leonid Mesnik has updated the pull request incrementally with one additional
commit
On Mon, 15 May 2023 23:12:52 GMT, Paul Hohensee wrote:
>> Please review this addition to com.sun.management.ThreadMXBean that returns
>> the total number of bytes allocated on the Java heap since JVM launch by
>> both terminated and live threads.
>>
>> Because this PR adds a new interface meth
On Mon, 15 May 2023 23:07:20 GMT, Chris Plummer wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> excluded 1 more test after testing
>
> test/lib/jdk/test/lib/process/ProcessTools.java line 402:
>
>> 400: f
On Fri, 12 May 2023 23:39:51 GMT, Leonid Mesnik wrote:
>> The fix excludes svc tests which should be updated to work with the virtual
>> threads factory.
>> Also, ProcessTools updated to skip '-m' '--module' execution, which could
>> not be run with test thread factory
>
> Leonid Mesnik has upd
> Please review this addition to com.sun.management.ThreadMXBean that returns
> the total number of bytes allocated on the Java heap since JVM launch by both
> terminated and live threads.
>
> Because this PR adds a new interface method, I've updated the JMM_VERSION to
> 4, but would be happy t
On Mon, 15 May 2023 22:18:32 GMT, Chris Plummer wrote:
>> Looks good to me.
>> Please update "@summary" statement about "notKilled" (now "killed") field
>
> I went to edit the PR description, but found it is not actually incorrect. It
> says "kill001 suspends all threads at a breakpoint". That i
On Mon, 15 May 2023 22:40:16 GMT, Serguei Spitsyn wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix typo in comment
>
> test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001.java line 39:
>
>> 37: * and t
> Currently kill001 assumes that JVMTI StopThread (via JDI
> ThreadReference.stop) is not supported for virtual threads.
> [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding support
> for StopThread on a virtual thread as long as it is suspended and mounted.
> This means, for
On Mon, 15 May 2023 22:14:01 GMT, Chris Plummer wrote:
>> Currently kill001 assumes that JVMTI StopThread (via JDI
>> ThreadReference.stop) is not supported for virtual threads.
>> [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding support
>> for StopThread on a virtual threa
Hi,
I do share some concerns of the community, however many have voiced it with
a better english that I could ever do. But I'd like to mention two things:
1. There is another usage that I think will be visibly impacted : in tests
it's often necessary to alter part of the system to stress some par
On Mon, 15 May 2023 21:13:45 GMT, Alex Menkov wrote:
>> This became a lot trickier to understand than I expected. The JVM does not
>> have to throw the async exception at the next executed bytecode. The
>> interpreter seems to do it at an invoke or after a goto (so the target of
>> the goto is
On Mon, 15 May 2023 21:59:55 GMT, Chris Plummer wrote:
>> Currently kill001 assumes that JVMTI StopThread (via JDI
>> ThreadReference.stop) is not supported for virtual threads.
>> [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding support
>> for StopThread on a virtual threa
> Currently kill001 assumes that JVMTI StopThread (via JDI
> ThreadReference.stop) is not supported for virtual threads.
> [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding support
> for StopThread on a virtual thread as long as it is suspended and mounted.
> This means, for
> Currently kill001 assumes that JVMTI StopThread (via JDI
> ThreadReference.stop) is not supported for virtual threads.
> [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding support
> for StopThread on a virtual thread as long as it is suspended and mounted.
> This means, for
On Sat, 13 May 2023 07:28:38 GMT, Serguei Spitsyn wrote:
> This is newly integrated test times out because it has a race in in the Test
> #A.1 and #A.2.
> The main root cause is a print statement which can case target virtual thread
> to unpark and unmount.
> This causes that the `StopThreads`
On Sat, 13 May 2023 07:28:38 GMT, Serguei Spitsyn wrote:
> This is newly integrated test times out because it has a race in in the Test
> #A.1 and #A.2.
> The main root cause is a print statement which can case target virtual thread
> to unpark and unmount.
> This causes that the `StopThreads`
On Mon, 15 May 2023 20:22:53 GMT, Chris Plummer wrote:
>>> looks like we just need to move synchronized (or some other code to force
>>> vthread to be mounted) to inside the try and remove Thread.sleep, no other
>>> statements are needed.
>>
>> That should work. At first I was unsure because t
On Mon, 15 May 2023 20:10:08 GMT, Chris Plummer wrote:
>> Currently kill001 assumes that JVMTI StopThread (via JDI
>> ThreadReference.stop) is not supported for virtual threads.
>> [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding support
>> for StopThread on a virtual threa
On Sat, 13 May 2023 03:59:12 GMT, Chris Plummer wrote:
>>> The debugger side checks for the proper notKilled value (it should be 0).
>>> So the test still passes even though it never confirmed that the correct
>>> async exception was thrown and caught. It just knows that the thread did
>>> not
> Currently kill001 assumes that JVMTI StopThread (via JDI
> ThreadReference.stop) is not supported for virtual threads.
> [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding support
> for StopThread on a virtual thread as long as it is suspended and mounted.
> This means, for
On Fri, 12 May 2023 23:24:17 GMT, Chris Plummer wrote:
>> nsk/jdi/stop/stop001 is problem listed due to
>> [JDK-7034630](https://bugs.openjdk.org/browse/JDK-7034630), but that issue
>> doesn't seem to reproduce anymore. It's suspected that it was only an issue
>> on Solaris. For this reason st
On Fri, 12 May 2023 20:46:41 GMT, Chris Plummer wrote:
> nsk/jdi/stop/stop001 is problem listed due to
> [JDK-7034630](https://bugs.openjdk.org/browse/JDK-7034630), but that issue
> doesn't seem to reproduce anymore. It's suspected that it was only an issue
> on Solaris. For this reason stop00
> On 14 May 2023, at 21:28, Alan Snyder wrote:
>
>
>> On May 14, 2023, at 6:07 PM, Ron Pressler wrote:
>>
>> You can continue using JNI, but the application on newer releases will need
>> to allow it. But the way to target multiple releases in a general and
>> elegant way is with multi-rel
On Tue, 9 May 2023 01:23:23 GMT, David Holmes wrote:
>> Paul Hohensee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Implement 32-bit linux Atomic::add()
>
> Also note that the current placement of the `incr_exited_allocated_bytes`
> s
On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona wrote:
> Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc`
> and `PackageDesc` become obsolete after
> [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729).
> All references to `jdk.internal.classfile.java.lang.const
> This is the implementation for JEP 451. There are two parts to this:
>
> 1. A multi-line warning is printed when a JVM TI or Java agent is loaded into
> a running VM. For JVM TI, the message is printed to stderr from
> JvmtiAgent::load. For Java agents, it is printed to System.err (as that may
On Fri, 12 May 2023 09:15:47 GMT, Kevin Walls wrote:
>> Java Discovery Protocol (perhaps a hidden feature, but maybe should be more
>> widely known!) and -XX:-UsePerfData together cause a failure to startup.
>>
>> PerfData is the mechanism for communicating the URL and other properties for
>>
On Sun, 14 May 2023 22:50:03 GMT, Paul Hohensee wrote:
>> Please review this addition to com.sun.management.ThreadMXBean that returns
>> the total number of bytes allocated on the Java heap since JVM launch by
>> both terminated and live threads.
>>
>> Because this PR adds a new interface meth
Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and
`PackageDesc` become obsolete after
[JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729).
All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and
`jdk.internal.classfile.java.lang.constant
47 matches
Mail list logo
