On Wed, 29 Mar 2023 02:29:16 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
>
>
On Wed, 29 Mar 2023 01:32:41 GMT, Leonid Mesnik wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1547:
>>
>>> 1545: JvmtiThreadState* ct_state =
>>> java_lang_Thread::jvmti_thread_state(jt->threadObj());
>>> 1546: JvmtiThreadState* vt_state = vt_oop != nullptr ?
>>>
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 01:16:55 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 1547:
>
>> 1545:
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
customization can even start to feel right.
Gregg Wonderly
>
On Wed, 29 Mar 2023 00:08:21 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/lang/System.java line 2566:
>>
>>> 2564:
>>> 2565: public V executeOnCarrierThread(Callable task)
>>> throws Exception {
>>> 2566: if (Thread.currentThread() instanceof
On Tue, 28 Mar 2023 23:47:02 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
>>
On Tue, 28 Mar 2023 19:36:18 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 02:48:30 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Ensure safepoint when processing lock-stack
>
> src/hotspot/share/runtime/threads.cpp line 1433:
>
>> 1431:
>> 1432:
> The current structure used to store the resolution information for
> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
> ambigious fields f1 and f2. This structure can hold information for fields,
> methods, and invokedynamics and each of its fields can hold
On Tue, 28 Mar 2023 19:36:18 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 Mon, 27 Feb 2023 21:37:34 GMT, Matias Saavedra Silva
wrote:
> The current structure used to store the resolution information for
> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
> ambigious fields f1 and f2. This structure can hold information for fields,
>
On Tue, 28 Mar 2023 15:00:14 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
> 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
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
> 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
On Tue, 28 Mar 2023 15:00:14 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie wrote:
> According to [the
> specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
> trailing whitespaces in the values of properties files are (somewhat
> surprisingly)
On Tue, 28 Mar 2023 10:53:10 GMT, Roman Kennke wrote:
>> src/hotspot/share/runtime/threads.cpp line 1422:
>>
>>> 1420: }
>>> 1421:
>>> 1422: JavaThread* Threads::owning_thread_from_object(ThreadsList * t_list,
>>> oop obj) {
>>
>> Is this thread-safe?
>
> My last commit changed that code to
On Tue, 28 Mar 2023 12:54:41 GMT, Amit Kumar wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> RISCV patch and aarch64 improvement
>
> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 652:
>
Hi Gregg,
Distributing little apps as JARs indeed doesn't work well anymore out
of the box, but it doesn't have to be the end of the line for them.
I've spent a couple of years writing a tool designed explicitly to
solve all these problems [1]. You give Conveyor your JARs (or a
Maven/Gradle
On Fri, 24 Mar 2023 16:54:59 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/runtime/lockStack.cpp line 42:
>>
>>> 40:
>>> 41: #ifndef PRODUCT
>>> 42: void LockStack::validate(const char* msg) const {
>>
>> Would you also like to check there are no `nullptr` elements on stack here?
>
> Please
Gregg I don’t understand your problem, nearly all desktop java programs I know (and there are not many left) come with included runtimes. The user just does not care about Java versions. Also i dont really know any enterprise desktops which ship (only) recent plan java
> On Mar 28, 2023, at 4:13 AM, Andrew Dinn wrote:
>
> Greeg,
>
> I won't respond point by point to your comments as I cannot see any great
> value in doing so. I really only want to make one general comment about your
> account below, which is that you appear to me to be relaying your own
> The current structure used to store the resolution information for
> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
> ambigious fields f1 and f2. This structure can hold information for fields,
> methods, and invokedynamics and each of its fields can hold
On Mon, 27 Mar 2023 14:43:04 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
> 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
On Fri, 24 Mar 2023 11:17:05 GMT, Aleksey Shipilev wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly
On Fri, 24 Mar 2023 10:50:39 GMT, Aleksey Shipilev wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly
On Fri, 24 Mar 2023 10:47:11 GMT, Aleksey Shipilev wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly
On Fri, 24 Mar 2023 02:49:11 GMT, David Holmes wrote:
> > Is anybody familiar with the academic literature on this topic? I am sure I
> > am not the first person which has come up with this form of locking. Maybe
> > we could use a name that refers to some academic paper?
>
> Well not to
Applications can now control the Java version available to them (and this is
something we’ll keep improving), and the JRE, the centralised Java environment
installed on user machines, has not existed for some time.
Strong encapsulation (which this change is part of) has made compatibility
> 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
> 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
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 change in
On Fri, 24 Mar 2023 06:55:55 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after
> 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
On Wed, 22 Mar 2023 18:05:49 GMT, Vladimir Kozlov wrote:
>> I don't think so, unless we also want to change all the stuff in x86_32.ad
>> to not fetch the thread before calling into fast_unlock(). However, I think
>> it is a nice and useful change. I could break it out of this PR and get it
> 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
> 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
Greeg,
I won't respond point by point to your comments as I cannot see any
great value in doing so. I really only want to make one general comment
about your account below, which is that you appear to me to be relaying
your own experience as a desktop Java user and universalising it to all
On Mon, 27 Mar 2023 14:43:04 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
42 matches
Mail list logo
