On Tue, 28 Mar 2023 16:33:09 GMT, Martin Doerr wrote:
>> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 652:
>>
>>> 650: // Scale the index to be the entry index *
>>> sizeof(ResolvedInvokeDynamicInfo)
>>> 651: __ sldi(size, size, log2i_exact(sizeof(ResolvedIndyEntry)));
> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
> APIs that were preview APIs in Java 19/20 are changed to permanent and their
> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
> JNI and JVMTI versions are bumped as this is the first chan
On Tue, 28 Mar 2023 21:36:04 GMT, Leonid Mesnik wrote:
>> Alan Bateman has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four additional
>> commit
On Wed, 29 Mar 2023 07:31:40 GMT, Alan Bateman wrote:
>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
>> APIs that were preview APIs in Java 19/20 are changed to permanent and their
>> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
>>
On Tue, 28 Mar 2023 19:57:12 GMT, Paul Sandoz wrote:
>> Alan Bateman has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four additional
>> commits
> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
> APIs that were preview APIs in Java 19/20 are changed to permanent and their
> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
> JNI and JVMTI versions are bumped as this is the first chan
On Wed, 29 Mar 2023 07:29:06 GMT, Andrey Turbanov wrote:
>> Alan Bateman has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test updates
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/premain/AgentWithVThreadTest.java
> line 40:
>
>>
Why, well, you get more features, it's easier for the end user, and
not any harder for the developer. Those are pretty concrete reasons
why people would want to do it that way. I'd suggest trying Conveyor
out yourself before worrying about rigging or customization, because
straightforward Java apps
On Wed, 29 Mar 2023 02:40:09 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fixed trailing spaces in two files
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1554:
>
>> 1552: // Cor
On Tue, 28 Mar 2023 14:00:12 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
> On 29 Mar 2023, at 01:29, Gregg G Wonderly wrote:
>
> This is exactly my point! Why would any one want to do something like this?
> This level of workaround and specialized deployment is the kind of breakage
> that I am referring to. I just don’t understand how this kind of rigging and
> This change adds a fast-locking scheme as an alternative to the current
> stack-locking implementation. It retains the advantages of stack-locking
> (namely fast locking in uncontended code-paths), while avoiding the overload
> of the mark word. That overloading causes massive problems with Li
> This change adds a fast-locking scheme as an alternative to the current
> stack-locking implementation. It retains the advantages of stack-locking
> (namely fast locking in uncontended code-paths), while avoiding the overload
> of the mark word. That overloading causes massive problems with Li
Hi Gregg,
Thanks for your reply. I only have one small point to make.
On 28/03/2023 16:35, Gregg Wonderly wrote:
Again, the supposition is that somehow users of software systems are always
surrounded by version planning and management. . . .
No, actually, my supposition is that users of softw
On Tue, 28 Mar 2023 16:00:34 GMT, Thomas Stuefe wrote:
>> Please also verify against over- and underflow, and better than just null
>> checks check that every oop really is an oop. I added this to my code:
>>
>> assert((_offset <= end_offset()), "lockstack overflow: _offset %d
>> end_offset
I think while this discussion is an interesting one, and clearly one the
elicits strong opinions; I believe that the focus on the proposed change
on dynamic loading of agents has truly been lost therein, further
exchanges have little relevance to the topic of Java serviceability and
the issue a
> This change adds a fast-locking scheme as an alternative to the current
> stack-locking implementation. It retains the advantages of stack-locking
> (namely fast locking in uncontended code-paths), while avoiding the overload
> of the mark word. That overloading causes massive problems with Li
On Tue, 21 Mar 2023 22:38:18 GMT, Chris Plummer wrote:
>> There are two GC related issues with this test that are being addressed. The
>> test was limiting the heap size to 6m so if there is still a leak, it will
>> be detected quickly. This proved to be too small of a size when using ZGC.
>>
> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which
> does enabling JVMTI VTMS transition notifications in case of agent loaded
> into running VM. This function executes a VM
On Wed, 29 Mar 2023 10:16:39 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1554:
>>
>>> 1552: // Correct jt->jvmti_thread_state() and jt->jvmti_vthread() if
>>> necessary.
>>> 1553: // It was not maintained while notifyJvmti was disabled.
>>> 1554:
On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman wrote:
>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
>> APIs that were preview APIs in Java 19/20 are changed to permanent and their
>> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
>>
On Wed, 29 Mar 2023 07:27:50 GMT, Alan Bateman wrote:
>> test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 143:
>>
>>> 141: long[] tids = new long[] { tid0, tid1 };
>>> 142: long[] cpuTimes = bean.getThreadCpuTime(tids);
>>> 143: if (Thread.cur
On Wed, 29 Mar 2023 18:47:03 GMT, Chris Plummer wrote:
>> tid0 is the thread ID of a platform therad. tid1 is the threadID of a
>> virtual thread. The only change here is allow this test run with the main
>> wrapper plugin
>> ([CODETOOLS-7903373](https://bugs.openjdk.org/browse/CODETOOLS-79033
On Wed, 29 Mar 2023 18:30:01 GMT, Chris Plummer wrote:
>> Alan Bateman has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix ThreadSleepEvent again
>
> test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java
On Tue, 21 Mar 2023 22:38:18 GMT, Chris Plummer wrote:
>> There are two GC related issues with this test that are being addressed. The
>> test was limiting the heap size to 6m so if there is still a leak, it will
>> be detected quickly. This proved to be too small of a size when using ZGC.
>>
Hi all,
could someone clarify the following difference in javac behavior between
Java 11 and Java 17? Which one is correct?
There are two source files:
package p;
public class Exceptions {
private static class E extends Exception {
public void m() { }
}
public static class E1
On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman wrote:
>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
>> APIs that were preview APIs in Java 19/20 are changed to permanent and their
>> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
>>
On Wed, 29 Mar 2023 19:42:58 GMT, Daniel D. Daugherty
wrote:
> What kind of testing has been done on this fix?
I ran this tests 25 times on each supported platform, both with and with ZGC.
-
PR Comment: https://git.openjdk.org/jdk/pull/13130#issuecomment-1489276679
On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman wrote:
>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
>> APIs that were preview APIs in Java 19/20 are changed to permanent and their
>> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
>>
On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman wrote:
>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
>> APIs that were preview APIs in Java 19/20 are changed to permanent and their
>> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
>>
On Tue, 21 Mar 2023 22:38:18 GMT, Chris Plummer wrote:
>> There are two GC related issues with this test that are being addressed. The
>> test was limiting the heap size to 6m so if there is still a leak, it will
>> be detected quickly. This proved to be too small of a size when using ZGC.
>>
On Tue, 21 Mar 2023 22:38:18 GMT, Chris Plummer wrote:
>> There are two GC related issues with this test that are being addressed. The
>> test was limiting the heap size to 6m so if there is still a leak, it will
>> be detected quickly. This proved to be too small of a size when using ZGC.
>>
On Wed, 29 Mar 2023 13:51:51 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Tue, 28 Mar 2023 10:28:00 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman wrote:
>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
>> APIs that were preview APIs in Java 19/20 are changed to permanent and their
>> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
>>
On Wed, 29 Mar 2023 16:05:05 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Wed, 29 Mar 2023 21:55:35 GMT, Daniel D. Daugherty
wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Process lock-stack oops before inspecting them, when in foreign thread and
>> not at safepoint. Add verificati
On Wed, 29 Mar 2023 22:02:02 GMT, Daniel D. Daugherty
wrote:
>> src/hotspot/share/runtime/threads.cpp line 1423:
>>
>>> 1421:
>>> 1422: JavaThread* Threads::owning_thread_from_object(ThreadsList * t_list,
>>> oop obj) {
>>> 1423: assert(SafepointSynchronize::is_at_safepoint(), "not safe out
On Wed, 29 Mar 2023 18:02:38 GMT, Serguei Spitsyn wrote:
>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which
>> does enabling JVMTI VTMS transition notifications in case
On Tue, 28 Mar 2023 18:57:23 GMT, Serguei Spitsyn wrote:
>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which
>> does enabling JVMTI VTMS transition notifications in case
On Wed, 29 Mar 2023 16:05:05 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Wed, 29 Mar 2023 16:05:05 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman wrote:
>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The
>> APIs that were preview APIs in Java 19/20 are changed to permanent and their
>> `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The
>>
On Tue, 21 Mar 2023 21:38:12 GMT, Chris Plummer wrote:
> There are two GC related issues with this test that are being addressed. The
> test was limiting the heap size to 6m so if there is still a leak, it will be
> detected quickly. This proved to be too small of a size when using ZGC. For
>
Hi,
This is the wrong mailing list for this issue - you want compiler-dev
for javac issues.
Cheers,
David
On 30/03/2023 6:15 am, S A wrote:
Hi all,
could someone clarify the following difference in javac behavior between
Java 11 and Java 17? Which one is correct?
There are two source fil
On Wed, 29 Mar 2023 01:52:18 GMT, Patricio Chilano Mateo
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fixed trailing spaces in two files
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1550:
>
>> 1548:
>
> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which
> does enabling JVMTI VTMS transition notifications in case of agent loaded
> into running VM. This function executes a VM
On Wed, 29 Mar 2023 21:36:04 GMT, Patricio Chilano Mateo
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: updated correction of jt->jvmti_thread_state() links in
>> VM_SetNotifyJvmtiEventsMode
>
> src/h
On Wed, 29 Mar 2023 22:15:35 GMT, Patricio Chilano Mateo
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: updated correction of jt->jvmti_thread_state() links in
>> VM_SetNotifyJvmtiEventsMode
>
> Hi Se
On Wed, 29 Mar 2023 21:44:56 GMT, Patricio Chilano Mateo
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: updated correction of jt->jvmti_thread_state() links in
>> VM_SetNotifyJvmtiEventsMode
>
> test/
> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which
> does enabling JVMTI VTMS transition notifications in case of agent loaded
> into running VM. This function executes a VM
Can I please get a review of this trivial doc only change which addresses
https://bugs.openjdk.org/browse/JDK-8304988?
I've run `make docs-image` after this change and the generated javadoc for this
class looks fine.
-
Commit messages:
- 8304988: unnecessary dash in @param gives d
52 matches
Mail list logo
