On Fri, 17 Mar 2023 06:33:43 GMT, Roman Kennke wrote:
>
> > > In my last changes I made a stupid mistake and don't set the condition
> > > flags correctly to force the slow-path, on aarch64. This is only relevant
> > > when we exceed the lock-stack capacity, that is why it's failing so
> >
On Fri, 17 Mar 2023 06:15:28 GMT, Thomas Stuefe wrote:
> > In my last changes I made a stupid mistake and don't set the condition
> > flags correctly to force the slow-path, on aarch64. This is only relevant
> > when we exceed the lock-stack capacity, that is why it's failing so rarely.
> > I
On Thu, 16 Mar 2023 20:47:59 GMT, Roman Kennke wrote:
> In my last changes I made a stupid mistake and don't set the condition flags
> correctly to force the slow-path, on aarch64. This is only relevant when we
> exceed the lock-stack capacity, that is why it's failing so rarely. I don't
> see
> This is needed for performance improvements in support of virtual threads.
> The update includes the following:
>
> 1. Refactored the `VirtualThread` native methods:
> `notifyJvmtiMountBegin` and `notifyJvmtiMountEnd` =>
> `notifyJvmtiMount`
> `notifyJvmtiUnmountBegin` and `not
The com/sun/jdi tests are located in the on package, and classes with same name
cause 'class duplication error' when this directory is opened as source code in
IDE.
The simplest fix to avoid this is just to rename class.
-
Commit messages:
- renamed classes
Changes: https://git.o
On Thu, 16 Mar 2023 21:02:09 GMT, Chris Plummer wrote:
> The debuggee main method creates two threads and then starts them:
>
>
> public static void main(String[] args) {
> System.out.println("Howdy!");
> Thread t1 = TestScaffold.newThread(new InvokeHangTarg(), name1);
>
On Wed, 15 Mar 2023 15:41:17 GMT, Frederic Parain wrote:
>> Please review this change re-implementing the FieldInfo data structure.
>>
>> The FieldInfo array is an old data structure storing fields metadata. It has
>> poor extension capabilities, a complex management code because of lack of
>>
On Thu, 16 Mar 2023 16:11:57 GMT, Richard Reingruber wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fixed aarch64 interpreter mistake
>
> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2335:
>
>>
On Thu, 16 Mar 2023 20:56:15 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 Thu, 16 Mar 2023 21:02:09 GMT, Chris Plummer wrote:
> The debuggee main method creates two threads and then starts them:
>
>
> public static void main(String[] args) {
> System.out.println("Howdy!");
> Thread t1 = TestScaffold.newThread(new InvokeHangTarg(), name1);
>
On Thu, 16 Mar 2023 21:05:54 GMT, Daniel D. Daugherty
wrote:
> > I pushed a fix for aarch64.
>
>
>
> Do you think this is the cause for the -Xcheck:jni failures that I ran into
>
> in my Tier4 testing?
Yes, and with high probability also for some/all of the other failures. It
leads to the
On Thu, 16 Mar 2023 21:02:09 GMT, Chris Plummer wrote:
> The debuggee main method creates two threads and then starts them:
>
>
> public static void main(String[] args) {
> System.out.println("Howdy!");
> Thread t1 = TestScaffold.newThread(new InvokeHangTarg(), name1);
>
The debuggee main method creates two threads and then starts them:
public static void main(String[] args) {
System.out.println("Howdy!");
Thread t1 = TestScaffold.newThread(new InvokeHangTarg(), name1);
Thread t2 = TestScaffold.newThread(new InvokeHangTarg(), name2);
On Thu, 16 Mar 2023 20:57:31 GMT, Roman Kennke wrote:
>> src/hotspot/cpu/x86/x86_32.ad line 617:
>>
>>> 615: int bangsize = C->output()->bang_size_in_bytes();
>>> 616:
>>> 617: __ verified_entry(framesize,
>>> C->output()->need_stack_bang(bangsize)?bangsize:0, C->in_24_bit_fp_mode(),
>>>
On Thu, 16 Mar 2023 20:47:59 GMT, Roman Kennke wrote:
> I pushed a fix for aarch64.
Do you think this is the cause for the -Xcheck:jni failures that I ran into
in my Tier4 testing?
-
PR: https://git.openjdk.org/jdk/pull/10907
On Thu, 16 Mar 2023 20:50:12 GMT, Daniel D. Daugherty
wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Several changes (mostly cosmetic) in response to reviews
>
> src/hotspot/cpu/x86/x86_32.ad line 617:
>
>> 615:
On Thu, 16 Mar 2023 12:51:10 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 Thu, 16 Mar 2023 12:51:10 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
> 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 Wed, 15 Mar 2023 00:34:00 GMT, Alex Menkov wrote:
>> The change:
>> - updates UniqueVtableTest to follow standard SA way - attach to target from
>> subprocess and use SATestUtils.addPrivilegesIfNeeded for the subprocess;
>> - updates several tests in the same directory to resolve
>> NoClassD
On Thu, 16 Mar 2023 12:51:10 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 Thu, 16 Mar 2023 12:51:10 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, 15 Mar 2023 00:34:00 GMT, Alex Menkov wrote:
>> The change:
>> - updates UniqueVtableTest to follow standard SA way - attach to target from
>> subprocess and use SATestUtils.addPrivilegesIfNeeded for the subprocess;
>> - updates several tests in the same directory to resolve
>> NoClassD
Hi.
In JDK 21 we intend to disallow the dynamic loading of agents by default. This
will affect tools that use the Attach API to load an agent into a JVM some time
after the JVM has started [1]. There is no change to any of the mechanisms that
load an agent at JVM startup (-javaagent/-agentlib on t
On Thu, 16 Mar 2023 18:31:23 GMT, Justin Lu wrote:
>> This PR converts Unicode sequences to UTF-8 native in .properties file.
>> (Excluding the Unicode space and tab sequence). The conversion was done
>> using native2ascii.
>>
>> In addition, the build logic is adjusted to support reading in t
> This PR converts Unicode sequences to UTF-8 native in .properties file.
> (Excluding the Unicode space and tab sequence). The conversion was done using
> native2ascii.
>
> In addition, the build logic is adjusted to support reading in the
> .properties files as UTF-8 during the conversion fro
On Wed, 15 Mar 2023 16:18:44 GMT, Archie L. Cobbs wrote:
>> Justin Lu has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - Bug6204853 should not be converted
>> - Copyright year for CompileProperties
>> - Redo translation for CS.properti
On Wed, 15 Mar 2023 20:19:51 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - Bug6204853 should not be converted
>> - Copyright year for CompileProperties
>> - Redo translation for CS.properties
>>
On Thu, 16 Mar 2023 18:19:29 GMT, Justin Lu wrote:
>> This PR converts Unicode sequences to UTF-8 native in .properties file.
>> (Excluding the Unicode space and tab sequence). The conversion was done
>> using native2ascii.
>>
>> In addition, the build logic is adjusted to support reading in t
> This PR converts Unicode sequences to UTF-8 native in .properties file.
> (Excluding the Unicode space and tab sequence). The conversion was done using
> native2ascii.
>
> In addition, the build logic is adjusted to support reading in the
> .properties files as UTF-8 during the conversion fro
On Wed, 15 Mar 2023 18:45:00 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 Thu, 16 Mar 2023 14:50:14 GMT, Alan Bateman wrote:
>> test/jdk/java/util/ServiceLoader/BadProvidersTest.java line 216:
>>
>>> 214: clb.withSuperclass(CD_Object);
>>> 215: clb.withFlags(AccessFlag.PUBLIC, AccessFlag.SUPER);
>>> 216: var provider$1Desc = Clas
> Summaries:
> 1. A few recommendations about updating the constant API is made at
> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html
> and I may update this patch shall the API changes be integrated before
> 2. One ASM library-specific test, `LambdaAsm` is removed. Oth
> Summaries:
> 1. A few recommendations about updating the constant API is made at
> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html
> and I may update this patch shall the API changes be integrated before
> 2. One ASM library-specific test, `LambdaAsm` is removed. Oth
On Wed, 15 Mar 2023 15:41:17 GMT, Frederic Parain wrote:
>> Please review this change re-implementing the FieldInfo data structure.
>>
>> The FieldInfo array is an old data structure storing fields metadata. It has
>> poor extension capabilities, a complex management code because of lack of
>>
> Summaries:
> 1. A few recommendations about updating the constant API is made at
> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html
> and I may update this patch shall the API changes be integrated before
> 2. One ASM library-specific test, `LambdaAsm` is removed. Oth
On Tue, 14 Mar 2023 07:53:25 GMT, Alan Bateman wrote:
> This is class descriptor for ProviderFactory$1, not "Provider" so maybe
> rename this to providerFactory1 or something a bit clearer.
The updated version looks good. I assume you'll do a pass over the updated
tests to bump their copyright
On Wed, 15 Mar 2023 04:09:04 GMT, Chen Liang wrote:
>> Summaries:
>> 1. A few recommendations about updating the constant API is made at
>> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html
>> and I may update this patch shall the API changes be integrated before
>> 2.
On Wed, 15 Mar 2023 04:09:04 GMT, Chen Liang wrote:
>> Summaries:
>> 1. A few recommendations about updating the constant API is made at
>> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html
>> and I may update this patch shall the API changes be integrated before
>> 2.
> 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 Sat, 11 Mar 2023 14:52:54 GMT, Thomas Stuefe 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
>> - Use nullptr instead of NULL in touche
On Sat, 11 Mar 2023 14:57:19 GMT, Thomas Stuefe 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
>> - Use nullptr instead of NULL in touche
On Thu, 16 Mar 2023 10:26:26 GMT, Thomas Stuefe wrote:
> Sounds good. Just to be clear, you mean enforce symmetric locking? resp.
> forbid asymmetric locking?
Yes, sorry, thanks for correcting! :)
-
PR: https://git.openjdk.org/jdk/pull/10907
On Thu, 16 Mar 2023 10:20:21 GMT, Robbin Ehn wrote:
>
> > > > @rkennke I must be missing something. In aarch64, why do we handle the
> > > > non-symmetric-unlock case in interpreter, but not in C1/C2? There, we
> > > > just seem to pop whatever is on top.
> > >
> > >
> > > C1 and C2 don't
On Thu, 16 Mar 2023 09:02:19 GMT, Roman Kennke wrote:
>> I like -XX:+UseNewLocks, too. I wouldn't overcomplicate things: this flag is
>> meant to be transitional, it is not meant to be used by end-users (except
>> the bravest nerds) at all. When it lands, the Lilliput flag (e.g.
>> +UseCompact
On Wed, 15 Mar 2023 18:45:00 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 Thu, 16 Mar 2023 09:21:26 GMT, Martin Doerr wrote:
>> Basically I kept the local variable as a name for the (now) constant value
>> passed in the call at L3409.
>>
>> The parameter cannot be eliminated since `load_invoke_cp_cache_entry()` is
>> declared in a shared header.
>>
>> I could re
On Thu, 16 Mar 2023 09:07:27 GMT, Richard Reingruber wrote:
>> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 3398:
>>
>>> 3396: const Bytecodes::Code code = bytecode();
>>> 3397: const bool is_invokeinterface = code ==
>>> Bytecodes::_invokeinterface;
>>> 3398: const bool is_invokedy
On Wed, 15 Mar 2023 19:04:41 GMT, Martin Doerr wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fixed aarch64 interpreter mistake
>
> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 3398:
>
>> 3396: co
On Thu, 16 Mar 2023 09:02:19 GMT, Roman Kennke wrote:
>
> > @rkennke I must be missing something. In aarch64, why do we handle the
> > non-symmetric-unlock case in interpreter, but not in C1/C2? There, we just
> > seem to pop whatever is on top.
>
> C1 and C2 don't allow assymmetric locking.
On Thu, 16 Mar 2023 08:36:45 GMT, Roman Kennke wrote:
>> Roman Kennke has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - More RISCV changes (by Fei Yang)
>> - Use -w instructions in fast_unlock()
>> - Increase stub size of C2HandleAno
On Thu, 16 Mar 2023 08:36:45 GMT, Roman Kennke wrote:
>> Roman Kennke has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - More RISCV changes (by Fei Yang)
>> - Use -w instructions in fast_unlock()
>> - Increase stub size of C2HandleAno
On Wed, 15 Mar 2023 09:41:30 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 Thu, 16 Mar 2023 08:00:38 GMT, Thomas Stuefe wrote:
> I like UseNewLocks but fear that this may conflict with Oracles plan (?) to
> move OMs into heap, which would be another revamp of locking - fat locks in
> this case - and may come with yet another switch. Other than that,
> UseNewLocks
On Wed, 15 Mar 2023 09:41:30 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, 15 Mar 2023 09:41:30 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
> This is needed for performance improvements in support of virtual threads.
> The update includes the following:
>
> 1. Refactored the `VirtualThread` native methods:
> `notifyJvmtiMountBegin` and `notifyJvmtiMountEnd` =>
> `notifyJvmtiMount`
> `notifyJvmtiUnmountBegin` and `not
On Wed, 15 Mar 2023 20:02:11 GMT, Alex Menkov wrote:
> It seems to me that it's much simpler to remove build action from 4 tests in
> the directory than add it for other 55
True. Sadly we keep getting bitten over and over by CODETOOLS-7902847.
Sometimes the "fix" is to remove build directives
58 matches
Mail list logo
