Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Wed, 17 Jul 2024 06:39:14 GMT, David Holmes wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 >> additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3]

2024-07-16 Thread David Holmes
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported >> compilers for Windows, Visual Studio since version 2015 and gcc since, well, >> forever. snprintf is conforming to C99 since the start when compiling using >>

Re: RFR: 8336275: Move common Method and Constructor fields to Executable [v2]

2024-07-16 Thread David Holmes
On Wed, 17 Jul 2024 02:57:51 GMT, Chen Liang wrote: >> What would be the terminology for a final field that's set by hotspot, >> against the regular java constrcutor rules? > > I have chosen the wording "all final fields are used by the VM" I don't know of any specific terminology - we typicall

Re: RFR: 8336275: Move common Method and Constructor fields to Executable [v2]

2024-07-16 Thread David Holmes
On Wed, 17 Jul 2024 03:03:23 GMT, Chen Liang wrote: >> Move fields common to Method and Field to executable, which simplifies >> implementation. Removed useless transient modifiers as Method and Field were >> never serializable. > > Chen Liang has updated the pull request incrementally with one

Re: RFR: 8336275: Move common Method and Constructor fields to Executable [v2]

2024-07-16 Thread Chen Liang
On Tue, 16 Jul 2024 22:41:40 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/reflect/Executable.java line 54: >> >>> 52: public abstract sealed class Executable extends AccessibleObject >>> 53: implements Member, GenericDeclaration permits Constructor, Method { >>> 54: //

Re: RFR: 8336275: Move common Method and Constructor fields to Executable [v2]

2024-07-16 Thread Chen Liang
> Move fields common to Method and Field to executable, which simplifies > implementation. Removed useless transient modifiers as Method and Field were > never serializable. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Redundant tr

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index

2024-07-16 Thread Chen Liang
On Mon, 15 Jul 2024 13:39:02 GMT, Aleksey Shipilev wrote: >> Indeed, for some reason I thought the range of short is -256 to 255 instead >> of -65536 to 65535 > >> Indeed, for some reason I thought the range of short is -256 to 255 instead >> of -65536 to 65535 > > Yeah, I thought something li

Re: RFR: 8334714: Class-File API leaves preview

2024-07-16 Thread Chen Liang
On Mon, 15 Jul 2024 13:26:39 GMT, ExE Boss wrote: >> Class-File API is leaving preview. >> This is a removal of all `@PreviewFeature` annotations from Class-File API. >> It also bumps all `@since` tags and removes >> `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`. >> >> Please review

Re: RFR: 8336275: Move common Method and Constructor fields to Executable

2024-07-16 Thread Chen Liang
On Tue, 16 Jul 2024 22:00:49 GMT, David Holmes wrote: >> Move fields common to Method and Field to executable, which simplifies >> implementation. Removed useless transient modifiers as Method and Field were >> never serializable. > > src/java.base/share/classes/java/lang/reflect/Executable.jav

Re: RFR: 8336275: Move common Method and Constructor fields to Executable

2024-07-16 Thread David Holmes
On Tue, 16 Jul 2024 03:45:36 GMT, Chen Liang wrote: > Move fields common to Method and Field to executable, which simplifies > implementation. Removed useless transient modifiers as Method and Field were > never serializable. Hotspot changes look good. Core-libs do too but I will leave that fo

Re: RFR: 8336275: Move common Method and Constructor fields to Executable

2024-07-16 Thread David Holmes
On Tue, 16 Jul 2024 03:45:36 GMT, Chen Liang wrote: > Move fields common to Method and Field to executable s/Field/Constructor I was a bit confused about executable fields for a moment. :) - PR Comment: https://git.openjdk.org/jdk/pull/20188#issuecomment-2231889229

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v5]

2024-07-16 Thread Jorn Vernee
On Tue, 16 Jul 2024 19:59:41 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1388: >> >>> 1386: Name withIndex(int i) { >>> 1387: if (i == this.index) return this; >>> 1388: return new Name(i, type, function, arguments,

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v5]

2024-07-16 Thread Jorn Vernee
On Tue, 16 Jul 2024 03:10:29 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids >> inlining `0`. On a strategic view, this index field should just become final >> so that `Name` becomes eligible for value class migration once valhalla >> comes. Thi

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v5]

2024-07-16 Thread Chen Liang
On Tue, 16 Jul 2024 19:39:16 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update src/java.base/share/classes/java/lang/invoke/LambdaForm.java >> >> Co-authored-by: ExE Boss <3889017+exe-b...@

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v5]

2024-07-16 Thread Jorn Vernee
On Tue, 16 Jul 2024 03:10:29 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids >> inlining `0`. On a strategic view, this index field should just become final >> so that `Name` becomes eligible for value class migration once valhalla >> comes. Thi

Re: RFR: 8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory

2024-07-16 Thread Roger Riggs
On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote: > Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added > support for functionality required to continue to support IIOP and custom > serializers in light of additional module-based restrictions on reflection. > It was ex

Re: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v5]

2024-07-16 Thread Jorn Vernee
On Tue, 16 Jul 2024 15:12:15 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when >> closing a shared Arena. The initial intent of this was to improve the >> performance of shared arena closure in cases where a lot of threads are >> accessing and clo

Re: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v6]

2024-07-16 Thread Jorn Vernee
> This PR limits the number of cases in which we deoptimize frames when closing > a shared Arena. The initial intent of this was to improve the performance of > shared arena closure in cases where a lot of threads are accessing and > closing shared arenas at the same time (see attached benchmark

RFR: 8162500: Receiver annotations of inner classes of local classes not found at runtime

2024-07-16 Thread Chen Liang
In annotated types, local and inner class types should be annotated as "top-level" types. For example, in the test here public static Class getLocalsMember() { class Local { class Member { @Annot(2635) Member(@Annot(2732) Local Local.this) {} }

Re: RFR: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance [v2]

2024-07-16 Thread Justin Lu
On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato wrote: >> Removing a redundant private method, which has the same implementation with >> the public sibling and obsolete method description. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revisio

Re: RFR: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance [v2]

2024-07-16 Thread Iris Clark
On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato wrote: >> Removing a redundant private method, which has the same implementation with >> the public sibling and obsolete method description. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revisio

Re: RFR: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance [v2]

2024-07-16 Thread Joe Wang
On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato wrote: >> Removing a redundant private method, which has the same implementation with >> the public sibling and obsolete method description. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revisio

Re: RFR: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance [v2]

2024-07-16 Thread Naoto Sato
> Removing a redundant private method, which has the same implementation with > the public sibling and obsolete method description. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed unnecessary `this` - Changes: -

RFR: 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance

2024-07-16 Thread Naoto Sato
Removing a redundant private method, which has the same implementation with the public sibling and obsolete method description. - Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/20199/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20199&range=0

Re: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v4]

2024-07-16 Thread Jorn Vernee
On Tue, 16 Jul 2024 15:00:04 GMT, Doug Simon wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> JVMCI support > > src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java > line 62: > >>

Re: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v5]

2024-07-16 Thread Jorn Vernee
> This PR limits the number of cases in which we deoptimize frames when closing > a shared Arena. The initial intent of this was to improve the performance of > shared arena closure in cases where a lot of threads are accessing and > closing shared arenas at the same time (see attached benchmark

Re: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v4]

2024-07-16 Thread Doug Simon
On Tue, 16 Jul 2024 14:46:13 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when >> closing a shared Arena. The initial intent of this was to improve the >> performance of shared arena closure in cases where a lot of threads are >> accessing and clo

Re: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v4]

2024-07-16 Thread Jorn Vernee
On Tue, 16 Jul 2024 14:46:13 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when >> closing a shared Arena. The initial intent of this was to improve the >> performance of shared arena closure in cases where a lot of threads are >> accessing and clo

Re: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v4]

2024-07-16 Thread Jorn Vernee
> This PR limits the number of cases in which we deoptimize frames when closing > a shared Arena. The initial intent of this was to improve the performance of > shared arena closure in cases where a lot of threads are accessing and > closing shared arenas at the same time (see attached benchmark

Re: RFR: 8261400: Reflection member filtering registration might be flawed

2024-07-16 Thread Chen Liang
On Tue, 16 Jul 2024 13:35:50 GMT, Alan Bateman wrote: >> Please review this patch that address the reflection member filtering flaws. >> >> 1. Remove a pointless bootstrap check to ensure no filter is accidentally >> bypassed due to class-loading order. >> 2. Clarify the scenarios for filtering

Re: RFR: 8261400: Reflection member filtering registration might be flawed

2024-07-16 Thread Alan Bateman
On Fri, 5 Jul 2024 19:27:27 GMT, Chen Liang wrote: > Please review this patch that address the reflection member filtering flaws. > > 1. Remove a pointless bootstrap check to ensure no filter is accidentally > bypassed due to class-loading order. > 2. Clarify the scenarios for filtering, and th

Re: RFR: 8261400: Reflection member filtering registration might be flawed

2024-07-16 Thread Alan Bateman
On Fri, 5 Jul 2024 19:27:27 GMT, Chen Liang wrote: > 3. Remove the filter in `sun.misc.Unsafe`; users are already using other ways > to steal this instance, bypassing the filtered getter. JEP 471 has the roadmap for sun.misc.Unsafe, which is to wind it down over time. Relaxing the filter to a

Re: RFR: 8334394: Race condition in Class::protectionDomain [v2]

2024-07-16 Thread Alan Bateman
On Mon, 17 Jun 2024 15:24:27 GMT, Weijun Wang wrote: >> Make sure `pd` is always the same object when `getProtectionDomain0` is null. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > explain why the test is related to the fix

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread Roman Kennke
On Tue, 16 Jul 2024 12:37:43 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 >> additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread Roman Kennke
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3]

2024-07-16 Thread Daniel JeliƄski
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported >> compilers for Windows, Visual Studio since version 2015 and gcc since, well, >> forever. snprintf is conforming to C99 since the start when compiling using >>

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2]

2024-07-16 Thread Kim Barrett
On Tue, 16 Jul 2024 08:52:01 GMT, Julian Waters wrote: >> src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h line 32: >> >>> 30: #include /* for _MAx_PATH */ >>> 31: >>> 32: typedef unsigned long long UNSIGNED_JLONG; >> >> This change has nothing to do with _sprintf. Not sure why it's

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3]

2024-07-16 Thread Kim Barrett
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported >> compilers for Windows, Visual Studio since version 2015 and gcc since, well, >> forever. snprintf is conforming to C99 since the start when compiling using >>

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3]

2024-07-16 Thread Julian Waters
> snprintf has been available for all officially and unofficially supported > compilers for Windows, Visual Studio since version 2015 and gcc since, well, > forever. snprintf is conforming to C99 since the start when compiling using > gcc, and 2015 when using Visual Studio. Since it conforms to

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2]

2024-07-16 Thread Julian Waters
On Mon, 15 Jul 2024 16:30:02 GMT, Kim Barrett wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> USe os::snprintf in HotSpot > > src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h line 32: > >> 30: #include /