On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore wrote:
>> This change moves the flags from AccessFlags to either ConstMethodFlags or
>> MethodFlags, depending on whether they are set at class file parse time,
>> which makes them essentially const, or at runtime, which makes them needing
>>
> 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 Fri, 28 Apr 2023 07:43:24 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, 26 Apr 2023 18:35:45 GMT, Thomas Stuefe wrote:
>> src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 649:
>>
>>> 647:
>>> 648: __ flush();
>>> 649: return AdapterHandlerLibrary::new_entry(fingerprint, i2c_entry,
>>> c2i_entry, c2i_unverified_entry);
>>
>> This change seems out of plac
On Wed, 26 Apr 2023 18:58:13 GMT, Roman Kennke wrote:
>>> @rkennke - I'm planning to do another crawl thru review next week.
>>
>> Thanks! That is greatly appeciated!
>
>> @rkennke - finished my second crawl thru review of 60/68 files changed. I
>> only skipped the RISC-V files since I know nad
On Fri, 28 Apr 2023 07:43:24 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
Hi all,
Please review this change to avoid CleanClassLoaderDataMetaspaces safepoint
when there is nothing that can be cleaned up.
**Summary**
When transforming/redefining classes a previous version list is linked together
in the InstanceKlass. The original class is added to this list if it is
> Hi, heap dump brings about pauses for application's execution(STW), this is a
> well-known pain. JDK-8252842 have added parallel support to heapdump in an
> attempt to alleviate this issue. However, all concurrent threads
> competitively write heap data to the same file, and more memory is req
On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore wrote:
>> This change moves the flags from AccessFlags to either ConstMethodFlags or
>> MethodFlags, depending on whether they are set at class file parse time,
>> which makes them essentially const, or at runtime, which makes them needing
>>
On Wed, Apr 19, 2023 at 12:29 AM Ron Pressler wrote:
>
> Hi.
>
> Following last month’s email about changing the default of
> EnableDynamicAgentLoading [1], we’ve now published two JEP drafts.
>
> The first is an informational JEP describing what integrity is and why we
> need it,
> and motivates
> This change moves the flags from AccessFlags to either ConstMethodFlags or
> MethodFlags, depending on whether they are set at class file parse time,
> which makes them essentially const, or at runtime, which makes them needing
> atomic access.
>
> This leaves AccessFlags int size because Kla
On Fri, 28 Apr 2023 14:18:11 GMT, Matias Saavedra Silva
wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove bool argument from ConstMethodFlags.set function.
>
> src/hotspot/share/oops/method.hpp line 615:
Hello,Want to mention another point. In the past there has been a tendency of JRE to hide internal implementations. That’s somewhat understandable, however it was always a convinience to be able to poke at internals. I mean it took so long to offer a API for base64, or bei
On Fri, 28 Apr 2023 12:48:44 GMT, Stefan Johansson wrote:
> Hi all,
>
> Please review this change to avoid CleanClassLoaderDataMetaspaces safepoint
> when there is nothing that can be cleaned up.
>
> **Summary**
> When transforming/redefining classes a previous version list is linked
> toget
On Fri, 28 Apr 2023 11:32:54 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
> Convert this ThreadReference.interrupt() test to support virtual threads. I
> believe this is the only test for ThreadReference.interrupt() that we have.
>
> Tested by running with and without -Dmain.wrapper=Virtual on all supported
> platforms.
Chris Plummer has updated the pull request incr
> Note this PR depends on the #13546 PR for the following:
>
> [JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of
> virtual threads to JVMTI StopThread
>
> So it can't be finalized and push until after JDK-8306434 is pushed. There
> will also be GHA failures until then.
On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore wrote:
>> This change moves the flags from AccessFlags to either ConstMethodFlags or
>> MethodFlags, depending on whether they are set at class file parse time,
>> which makes them essentially const, or at runtime, which makes them needing
>>
On Fri, 28 Apr 2023 18:29:50 GMT, Frederic Parain wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove bool argument from ConstMethodFlags.set function.
>
> src/hotspot/share/oops/constMethod.cpp line 438:
>
On Fri, 28 Apr 2023 16:48:12 GMT, Daniel D. Daugherty
wrote:
> http://bugs.openjdk.java.net/browse/JDK-8307103
Should be based on JDK-8307103 now. Thanks for all your testing!
-
PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1527972396
> 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 Fri, 28 Apr 2023 15:42:58 GMT, Coleen Phillimore wrote:
>> This change moves the flags from AccessFlags to either ConstMethodFlags or
>> MethodFlags, depending on whether they are set at class file parse time,
>> which makes them essentially const, or at runtime, which makes them needing
>>
A trivial fix to remove broken EnableThreadSMRExtraValidityChecks option.
-
Commit messages:
- 8307067: remove broken EnableThreadSMRExtraValidityChecks option
Changes: https://git.openjdk.org/jdk/pull/13704/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13704&range=00
Is
On Fri, 28 Apr 2023 18:39:21 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/oops/constMethod.cpp line 438:
>>
>>> 436: }
>>> 437: st->cr();
>>> 438: st->print(" - flags: "); _flags.print_on(st);
>>>st->cr();
>>
>> Method prints its flags as an int and in de
> This change moves the flags from AccessFlags to either ConstMethodFlags or
> MethodFlags, depending on whether they are set at class file parse time,
> which makes them essentially const, or at runtime, which makes them needing
> atomic access.
>
> This leaves AccessFlags int size because Kla
> Note this PR depends on the #13546 PR for the following:
>
> [JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of
> virtual threads to JVMTI StopThread
>
> So it can't be finalized and push until after JDK-8306434 is pushed. There
> will also be GHA failures until then.
On Fri, 28 Apr 2023 19:23:24 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
> Note this PR depends on the #13546 PR for the following:
>
> [JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of
> virtual threads to JVMTI StopThread
>
> So it can't be finalized and push until after JDK-8306434 is pushed. There
> will also be GHA failures until then.
Hi Ron,
Thanks for writing up the JEP draft outlining the proposal to disallow
dynamic loading of agents by default. The Red Hat Java team has continued
to discuss this proposal internally and with our stakeholders.
While there is a general agreement (or at least acceptance) with the
overall dir
30 matches
Mail list logo
