From mcimadamore at openjdk.org  Mon Sep  1 10:42:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 10:42:53 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v2]
In-Reply-To: <Avfg0PVdwWlAtuLdVYsESArMco0tGSu4tyCKvDi7-vs=.2c44ae60-27e7-48e3-a94f-d7a0df1630c1@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
 <Avfg0PVdwWlAtuLdVYsESArMco0tGSu4tyCKvDi7-vs=.2c44ae60-27e7-48e3-a94f-d7a0df1630c1@github.com>
Message-ID: <1E4JI89ENoaalCML79GurgcQ3vsD7gNB7zhjWLJ1CaY=.067d13bc-05f9-4b5f-9a61-b181ab341391@github.com>

On Thu, 28 Aug 2025 23:03:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve access flag reflection for preview on/off.
>> 
>> In this process, I noted javac is incorrectly injecting ACC_IDENTITY to 69.0 class' `InnerClasses` attribute and fixed that.
>> 
>> There is still some inconsistency, such as implying ACC_IDENTITY when preview is on for classes. Don't know if we have discussed on this yet.
>> 
>> No new test failures.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Years

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1772:

> 1770:         } else {
> 1771:             poolbuf.appendChar(target.minorVersion);
> 1772:             markedPreview = target.minorVersion == ClassFile.PREVIEW_MINOR_VERSION;

I don't think `target.minorVersion` can ever be preview?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2313595881

From mcimadamore at openjdk.org  Mon Sep  1 10:46:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 10:46:56 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v2]
In-Reply-To: <Avfg0PVdwWlAtuLdVYsESArMco0tGSu4tyCKvDi7-vs=.2c44ae60-27e7-48e3-a94f-d7a0df1630c1@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
 <Avfg0PVdwWlAtuLdVYsESArMco0tGSu4tyCKvDi7-vs=.2c44ae60-27e7-48e3-a94f-d7a0df1630c1@github.com>
Message-ID: <IOyO0P97QOGSPZJbtzs-7ZUBu_MUE1yhl6HrynPWLVM=.a42a1751-34bb-4931-b2e0-7a9f684d26b8@github.com>

On Thu, 28 Aug 2025 23:03:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve access flag reflection for preview on/off.
>> 
>> In this process, I noted javac is incorrectly injecting ACC_IDENTITY to 69.0 class' `InnerClasses` attribute and fixed that.
>> 
>> There is still some inconsistency, such as implying ACC_IDENTITY when preview is on for classes. Don't know if we have discussed on this yet.
>> 
>> No new test failures.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Years

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 3348:

> 3346:             flags |= MODULE;
> 3347:         }
> 3348:         if (((flags & ACC_IDENTITY) != 0 && !isMigratedValueClass(flags))

do we still need the `isMigratedValueClass` ? Aren't migrated value classes treated the same as ordinary value classes thanks to the work we did to load different classfiles based on preview-ness?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2313605382

From mcimadamore at openjdk.org  Mon Sep  1 11:03:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 11:03:57 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v2]
In-Reply-To: <Avfg0PVdwWlAtuLdVYsESArMco0tGSu4tyCKvDi7-vs=.2c44ae60-27e7-48e3-a94f-d7a0df1630c1@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
 <Avfg0PVdwWlAtuLdVYsESArMco0tGSu4tyCKvDi7-vs=.2c44ae60-27e7-48e3-a94f-d7a0df1630c1@github.com>
Message-ID: <rMFD881o9YmHgQjx7-omjytiLata0bTDGTEP9So-O7I=.e5bb0242-96b9-456b-9e4d-36a8a396f0d6@github.com>

On Thu, 28 Aug 2025 23:03:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve access flag reflection for preview on/off.
>> 
>> In this process, I noted javac is incorrectly injecting ACC_IDENTITY to 69.0 class' `InnerClasses` attribute and fixed that.
>> 
>> There is still some inconsistency, such as implying ACC_IDENTITY when preview is on for classes. Don't know if we have discussed on this yet.
>> 
>> No new test failures.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Years

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 348:

> 346:                         .build(proxyDesc, clb -> {
> 347:             clb.withSuperclass(CD_Object)
> 348:                .withFlags(ACC_SUPER | ACC_FINAL | ACC_SYNTHETIC)

I presume this change is because the classfile API will be able to filter out ACC_SUPER based on the target version?

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 461:

> 459:          * @jvms 4.1 The {@code ClassFile} Structure
> 460:          */
> 461:         CLASS(ACC_PUBLIC | ACC_FINAL | ACC_IDENTITY |

Shouldn't we have a mapping here for `JDK N - 1` that has ACC_SUPER instead of ACC_IDENTITY ? For inner classes this is not needed because inner classes could never have ACC_SUPER -- but regular classes could?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2313641040
PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2313636952

From mcimadamore at openjdk.org  Mon Sep  1 11:07:59 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 11:07:59 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <ofmC8m_hlxPgPSpKRePkS7M94nm-JYJmhdd_iesCjRQ=.0b05d84f-d188-4f27-9b1a-f90f5539c1b8@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
 <1LVa6gpDkvhjwbObQ0PmxjZzFRBIH_1qxXviLRypkBk=.da27ddd9-a2de-4a0c-b1f9-3732b4c565b9@github.com>
 <CKn_mWYfg-4Sn7yCcBIsvJJEiLATBdD8oCRHKDt5lUw=.21cdc091-5e62-4daf-9f02-2894ee7d2bdb@github.com>
 <0TlPQHFNxMNl22ulZGcxf4UURpcu4WT12xiTJsgYxqY=.c48a3949-b372-4adc-9ec7-d21b1ff88b79@github.com>
 <EgtRgQkXxB3nhTbdcgsZ9uKy7b787ajX2yCelHLGeZ4=.345d7e46-1cde-456e-bbf6-75001a08d9b4@github.com>
 <ofmC8m_hlxPgPSpKRePkS7M94nm-JYJmhdd_iesCjRQ=.0b05d84f-d188-4f27-9b1a-f90f5539c1b8@github.com>
Message-ID: <sDR16DRroKxaNaG76VszAwDDfkSggB5QeNwDoodZQZ4=.ac146ee5-e518-401a-9b7c-ac02dbf41fed@github.com>

On Fri, 29 Aug 2025 14:27:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> (or, do we only do local proxies for strict fields? If so, should we be more uniform here?)
>
> we do local proxies for every field read in the prologue, a getField with a larval `this` will be an error in the VM

ok, so I guess I still don't get whether this _must_ be an error. In principle `y` could have a local proxy, in which case the lambda could be thought of as accessing that proxy, so no need to capture `this` ?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2313648547

From mcimadamore at openjdk.org  Mon Sep  1 11:45:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 11:45:58 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v19]
In-Reply-To: <xUG_UhPW3CKq8-bedVYGDOzDKHotf_J5kf9zyRBQefI=.c13f4c8a-5608-4264-8b01-28c9438bde18@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <xUG_UhPW3CKq8-bedVYGDOzDKHotf_J5kf9zyRBQefI=.c13f4c8a-5608-4264-8b01-28c9438bde18@github.com>
Message-ID: <TBEL7d8tXDoRFtDeXE9559E1EYLMMx7cIBCIhutsGiY=.b68f7222-04ff-413a-8fa6-3419553685d4@github.com>

On Fri, 29 Aug 2025 20:10:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some documentation

Do we still need the changes in `Attr.checkAssignable` -- e.g. flexible constructor bodies used to check some extra properties in there. Now that we have an LHS variable in the prologue scanner, I wonder if we can unify the checks?

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1523#pullrequestreview-3173319602

From mcimadamore at openjdk.org  Mon Sep  1 11:57:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 11:57:57 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <34538axagjf2FjcY19gxrvx-jr4-dquXyDRaLPMQwvA=.74eb51af-8ec1-4bee-8956-97484afa42f8@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
 <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>
 <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
 <34538axagjf2FjcY19gxrvx-jr4-dquXyDRaLPMQwvA=.74eb51af-8ec1-4bee-8956-97484afa42f8@github.com>
Message-ID: <2-HFsK1FjPRyX08j95bjJveZQGqO93fGE7tsB-BvP4A=.3b36d5ef-0a56-4ed5-97c4-8e3de3c1d09a@github.com>

On Fri, 29 Aug 2025 12:02:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> I understand -- but in the prologue of Foo we can have a Bar.this where Bar is some enclosing class?
>> 
>> 
>> class Foo {
>>         class Bar {
>>             Bar() { Object o = Foo.this; super();}
>>         }
>> }
>
> yep I see, there seems to be a bug here, thanks

What has fixed this exactly? It seems like this was already working as expected because `TreeInfo.isExplicitThisReference` already checks for possible enclosing types?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2313751756

From mcimadamore at openjdk.org  Mon Sep  1 12:20:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 12:20:01 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v19]
In-Reply-To: <TBEL7d8tXDoRFtDeXE9559E1EYLMMx7cIBCIhutsGiY=.b68f7222-04ff-413a-8fa6-3419553685d4@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <xUG_UhPW3CKq8-bedVYGDOzDKHotf_J5kf9zyRBQefI=.c13f4c8a-5608-4264-8b01-28c9438bde18@github.com>
 <TBEL7d8tXDoRFtDeXE9559E1EYLMMx7cIBCIhutsGiY=.b68f7222-04ff-413a-8fa6-3419553685d4@github.com>
Message-ID: <6-ljfwhhEVJgLROhAq-nr6je90eyUVm3yO9iZkkuB-g=.c0f071aa-b572-4f45-bbb2-949c1d50173e@github.com>

On Mon, 1 Sep 2025 11:42:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Do we still need the changes in `Attr.checkAssignable` -- e.g. flexible constructor bodies used to check some extra properties in there. Now that we have an LHS variable in the prologue scanner, I wonder if we can unify the checks?

I did an experiment, and adding this:


            if (isInLHS && !insideLambdaOrClassDef) {
                // Check instance field assignments that appear in constructor prologues
                if (isEarlyReference(localEnv, tree.hasTag(SELECT) ? ((JCFieldAccess)tree).selected : null, sym)) {
                    // Field may not be inherited from a superclass
                    if (sym.owner != localEnv.enclClass.sym) {
                        log.error(tree, Errors.CantRefBeforeCtorCalled(sym));
                        return;
                    }

                    // Field may not have an initializer
                    if ((sym.flags() & HASINIT) != 0) {
                        log.error(tree, Errors.CantAssignInitializedBeforeCtorCalled(sym));
                        return;
                    }
                }
                return;
            };
 ```
 
 At the start of `analyzeSymbol` seems to work fine. Maybe we want to break `analyzeSymbol` in different parts, one for reads and one for writes.

But one nice consequence of this is that now `isEarlyReference` is only called inside this visitor -- this means we can probably avoid having to pass `isPrologue = true` and, we can also avoid this dance:


tree.hasTag(SELECT) ? ((JCFieldAccess)tree).selected : null


Which is required at every callsite.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1523#issuecomment-3242145986

From acobbs at openjdk.org  Mon Sep  1 18:14:56 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 1 Sep 2025 18:14:56 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <sDR16DRroKxaNaG76VszAwDDfkSggB5QeNwDoodZQZ4=.ac146ee5-e518-401a-9b7c-ac02dbf41fed@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
 <1LVa6gpDkvhjwbObQ0PmxjZzFRBIH_1qxXviLRypkBk=.da27ddd9-a2de-4a0c-b1f9-3732b4c565b9@github.com>
 <CKn_mWYfg-4Sn7yCcBIsvJJEiLATBdD8oCRHKDt5lUw=.21cdc091-5e62-4daf-9f02-2894ee7d2bdb@github.com>
 <0TlPQHFNxMNl22ulZGcxf4UURpcu4WT12xiTJsgYxqY=.c48a3949-b372-4adc-9ec7-d21b1ff88b79@github.com>
 <EgtRgQkXxB3nhTbdcgsZ9uKy7b787ajX2yCelHLGeZ4=.345d7e46-1cde-456e-bbf6-75001a08d9b4@github.com>
 <ofmC8m_hlxPgPSpKRePkS7M94nm-JYJmhdd_iesCjRQ=.0b05d84f-d188-4f27-9b1a-f90f5539c1b8@github.com>
 <sDR16DRroKxaNaG76VszAwDDfkSggB5QeNwDoodZQZ4=.ac146ee5-e518-401a-9b7c-ac02dbf41fed@github.com>
Message-ID: <EzijMb2TPwlVJgHvwbEsKkJTGfNst47EZoChyExYskU=.5f743354-2623-4137-8c35-ba8ac34e103a@github.com>

On Mon, 1 Sep 2025 11:04:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> ok, so I guess I still don't get whether this _must_ be an error. In principle `y` could have a local proxy, in which case the lambda could be thought of as accessing that proxy, so no need to capture `this` ?

I wonder what is the mental model supposed to be here.

@mcimadamore what is your opinion on whether this should compile?

class A {
    int y;
    A() {
        y = 1;
        class B {
            static void m() {  // static context
                System.out.println(y);
            }
        }
        super();
    }
}

If your answer is "No" then aren't you then implying that `y` shouldn't be available whenever `A.this` is not available? In which case doesn't that answer your question?

If your answer is "Yes", then doesn't that imply that _this_ should also compile...

class A {
    int y;
    A() {
        y = 1;
        class B {
            static void m() {  // static context
                System.out.println(A.this.y);
            }
        }
        super();
    }
}

even though this doesn't:

class A {
    int y;
    A() {
        y = 1;
        class B {
            static void m() {  // static context
                System.out.println(A.this);
            }
        }
        super();
    }
}

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2314430958

From mcimadamore at openjdk.org  Mon Sep  1 18:36:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 18:36:56 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <EzijMb2TPwlVJgHvwbEsKkJTGfNst47EZoChyExYskU=.5f743354-2623-4137-8c35-ba8ac34e103a@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
 <1LVa6gpDkvhjwbObQ0PmxjZzFRBIH_1qxXviLRypkBk=.da27ddd9-a2de-4a0c-b1f9-3732b4c565b9@github.com>
 <CKn_mWYfg-4Sn7yCcBIsvJJEiLATBdD8oCRHKDt5lUw=.21cdc091-5e62-4daf-9f02-2894ee7d2bdb@github.com>
 <0TlPQHFNxMNl22ulZGcxf4UURpcu4WT12xiTJsgYxqY=.c48a3949-b372-4adc-9ec7-d21b1ff88b79@github.com>
 <EgtRgQkXxB3nhTbdcgsZ9uKy7b787ajX2yCelHLGeZ4=.345d7e46-1cde-456e-bbf6-75001a08d9b4@github.com>
 <ofmC8m_hlxPgPSpKRePkS7M94nm-JYJmhdd_iesCjRQ=.0b05d84f-d188-4f27-9b1a-f90f5539c1b8@github.com>
 <sDR16DRroKxaNaG76VszAwDDfkSggB5QeNwDoodZQZ4=.ac146ee5-e518-401a-9b7c-ac02dbf41fed@github.com>
 <EzijMb2TPwlVJgHvwbEsKkJTGfNst47EZoChyExYskU=.5f743354-2623-4137-8c35-ba8ac34e103a@github.com>
Message-ID: <mFnBF4T437E5xnoXPrI4teM8ZqyKMSPst1mlZld1VpU=.ebdbadfb-0f67-4ff8-9b33-4adb7089551b@github.com>

On Mon, 1 Sep 2025 18:12:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> ok, so I guess I still don't get whether this _must_ be an error. In principle `y` could have a local proxy, in which case the lambda could be thought of as accessing that proxy, so no need to capture `this` ?
>
>> ok, so I guess I still don't get whether this _must_ be an error. In principle `y` could have a local proxy, in which case the lambda could be thought of as accessing that proxy, so no need to capture `this` ?
> 
> I wonder what is the mental model supposed to be here.
> 
> @mcimadamore what is your opinion on whether this should compile?
> 
> class A {
>     int y;
>     A() {
>         y = 1;
>         class B {
>             static void m() {  // static context
>                 System.out.println(y);
>             }
>         }
>         super();
>     }
> }
> 
> If your answer is "No" then aren't you then implying that `y` shouldn't be available whenever `A.this` is not available? In which case doesn't that answer your question?
> 
> If your answer is "Yes", then doesn't that imply that _this_ should also compile...
> 
> class A {
>     int y;
>     A() {
>         y = 1;
>         class B {
>             static void m() {  // static context
>                 System.out.println(A.this.y);
>             }
>         }
>         super();
>     }
> }
> 
> even though this doesn't:
> 
> class A {
>     int y;
>     A() {
>         y = 1;
>         class B {
>             static void m() {  // static context
>                 System.out.println(A.this);
>             }
>         }
>         super();
>     }
> }

I suppose what I'm saying is: I understand why the code doesn't compile in today's world. But as we relax more restrictions and we resort to more complex translation strategies, I do wonder if some of these rules that prevent reads from lambdas will feel too tight. E.g. imagine the case of a final field -- that is written only once. If we already saw a write for that field, what stops us from being able to reference it from a lambda -- through a local proxy?

I don't buy the argument that `A.this.y` working implies `A.this`. This is already not the case in the code added by this PR, where reading an already written field in a prologue is fine, even through `A.this.y` -- but accessing `this` of a class from the prologue is never ok (if it was you could pass such a larval `this` to another method).

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2314445939

From mcimadamore at openjdk.org  Mon Sep  1 18:36:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 18:36:56 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <mFnBF4T437E5xnoXPrI4teM8ZqyKMSPst1mlZld1VpU=.ebdbadfb-0f67-4ff8-9b33-4adb7089551b@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
 <1LVa6gpDkvhjwbObQ0PmxjZzFRBIH_1qxXviLRypkBk=.da27ddd9-a2de-4a0c-b1f9-3732b4c565b9@github.com>
 <CKn_mWYfg-4Sn7yCcBIsvJJEiLATBdD8oCRHKDt5lUw=.21cdc091-5e62-4daf-9f02-2894ee7d2bdb@github.com>
 <0TlPQHFNxMNl22ulZGcxf4UURpcu4WT12xiTJsgYxqY=.c48a3949-b372-4adc-9ec7-d21b1ff88b79@github.com>
 <EgtRgQkXxB3nhTbdcgsZ9uKy7b787ajX2yCelHLGeZ4=.345d7e46-1cde-456e-bbf6-75001a08d9b4@github.com>
 <ofmC8m_hlxPgPSpKRePkS7M94nm-JYJmhdd_iesCjRQ=.0b05d84f-d188-4f27-9b1a-f90f5539c1b8@github.com>
 <sDR16DRroKxaNaG76VszAwDDfkSggB5QeNwDoodZQZ4=.ac146ee5-e518-401a-9b7c-ac02dbf41fed@github.com>
 <EzijMb2TPwlVJgHvwbEsKkJTGfNst47EZoChyExYskU=.5f743354-2623-4137-8c35-ba8ac34e103a@github.com>
 <mFnBF4T437E5xnoXPrI4teM8ZqyKMSPst1mlZld1VpU=.ebdbadfb-0f67-4ff8-9b33-4adb7089551b@github.com>
Message-ID: <Fpgly2GR8R5yJ9HKzH67XUrUpvpz-SHlE0too46HGhY=.31440235-511a-4fff-b02f-ffafb398fddf@github.com>

On Mon, 1 Sep 2025 18:30:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> ok, so I guess I still don't get whether this _must_ be an error. In principle `y` could have a local proxy, in which case the lambda could be thought of as accessing that proxy, so no need to capture `this` ?
>> 
>> I wonder what is the mental model supposed to be here.
>> 
>> @mcimadamore what is your opinion on whether this should compile?
>> 
>> class A {
>>     int y;
>>     A() {
>>         y = 1;
>>         class B {
>>             static void m() {  // static context
>>                 System.out.println(y);
>>             }
>>         }
>>         super();
>>     }
>> }
>> 
>> If your answer is "No" then aren't you then implying that `y` shouldn't be available whenever `A.this` is not available? In which case doesn't that answer your question?
>> 
>> If your answer is "Yes", then doesn't that imply that _this_ should also compile...
>> 
>> class A {
>>     int y;
>>     A() {
>>         y = 1;
>>         class B {
>>             static void m() {  // static context
>>                 System.out.println(A.this.y);
>>             }
>>         }
>>         super();
>>     }
>> }
>> 
>> even though this doesn't:
>> 
>> class A {
>>     int y;
>>     A() {
>>         y = 1;
>>         class B {
>>             static void m() {  // static context
>>                 System.out.println(A.this);
>>             }
>>         }
>>         super();
>>     }
>> }
>
> I suppose what I'm saying is: I understand why the code doesn't compile in today's world. But as we relax more restrictions and we resort to more complex translation strategies, I do wonder if some of these rules that prevent reads from lambdas will feel too tight. E.g. imagine the case of a final field -- that is written only once. If we already saw a write for that field, what stops us from being able to reference it from a lambda -- through a local proxy?
> 
> I don't buy the argument that `A.this.y` working implies `A.this`. This is already not the case in the code added by this PR, where reading an already written field in a prologue is fine, even through `A.this.y` -- but accessing `this` of a class from the prologue is never ok (if it was you could pass such a larval `this` to another method).

(in your example with static context, my answer is that no, it should _not_ compile. A static context can't access instance fields from an enclosing class)

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2314448628

From acobbs at openjdk.org  Mon Sep  1 19:38:57 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 1 Sep 2025 19:38:57 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <Fpgly2GR8R5yJ9HKzH67XUrUpvpz-SHlE0too46HGhY=.31440235-511a-4fff-b02f-ffafb398fddf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
 <1LVa6gpDkvhjwbObQ0PmxjZzFRBIH_1qxXviLRypkBk=.da27ddd9-a2de-4a0c-b1f9-3732b4c565b9@github.com>
 <CKn_mWYfg-4Sn7yCcBIsvJJEiLATBdD8oCRHKDt5lUw=.21cdc091-5e62-4daf-9f02-2894ee7d2bdb@github.com>
 <0TlPQHFNxMNl22ulZGcxf4UURpcu4WT12xiTJsgYxqY=.c48a3949-b372-4adc-9ec7-d21b1ff88b79@github.com>
 <EgtRgQkXxB3nhTbdcgsZ9uKy7b787ajX2yCelHLGeZ4=.345d7e46-1cde-456e-bbf6-75001a08d9b4@github.com>
 <ofmC8m_hlxPgPSpKRePkS7M94nm-JYJmhdd_iesCjRQ=.0b05d84f-d188-4f27-9b1a-f90f5539c1b8@github.com>
 <sDR16DRroKxaNaG76VszAwDDfkSggB5QeNwDoodZQZ4=.ac146ee5-e518-401a-9b7c-ac02dbf41fed@github.com>
 <EzijMb2TPwlVJgHvwbEsKkJTGfNst47EZoChyExYskU=.5f743354-2623-4137-8c35-ba8ac34e103a@github.com>
 <mFnBF4T437E5xnoXPrI4teM8ZqyKMSPst1mlZld1VpU=.ebdbadfb-0f67-4ff8-9b33-4adb7089551b@github.com>
 <Fpgly2GR8R5yJ9HKzH67XUrUpvpz-SHlE0t
 oo46HGhY=.31440235-511a-4fff-b02f-ffafb398fddf@github.com>
Message-ID: <v33d0f7gi3vTENFhMorwAurWzrUTlfsAyZQv7Kj1ODg=.54e13f74-96aa-454d-9c2a-44bcbccecbdf@github.com>

On Mon, 1 Sep 2025 18:33:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> (in your example with static context, my answer is that no, it should _not_ compile. A static context can't access instance fields from an enclosing class)

Yep, sorry that was a dumb example - I should have replaced the static context with a lambda.

I'm all for increased flexibility, it's just that it would be nice if that came with a clean mental model.

For example, one possible mental model could be "works like effectively final" - which I think is what you're advocating - but for that we'd have to break the equivalence between `y` and `A.this.y` (probably worth it).

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2314503944

From vromero at openjdk.org  Mon Sep  1 20:12:57 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 Sep 2025 20:12:57 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <2-HFsK1FjPRyX08j95bjJveZQGqO93fGE7tsB-BvP4A=.3b36d5ef-0a56-4ed5-97c4-8e3de3c1d09a@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
 <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>
 <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
 <34538axagjf2FjcY19gxrvx-jr4-dquXyDRaLPMQwvA=.74eb51af-8ec1-4bee-8956-97484afa42f8@github.com>
 <2-HFsK1FjPRyX08j95bjJveZQGqO93fGE7tsB-BvP4A=.3b36d5ef-0a56-4ed5-97c4-8e3de3c1d09a@github.com>
Message-ID: <Q6jSth-qXZV77enOI8rK1uVsPdKp9iwLx3knP6oo6EM=.2c466cc5-7f2e-4584-a1c6-a8b4ff38a463@github.com>

On Mon, 1 Sep 2025 11:55:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> What has fixed this exactly? It seems like this was already working as expected because `TreeInfo.isExplicitThisReference` already checks for possible enclosing types?

yes that could be the case

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2314529945

From vromero at openjdk.org  Mon Sep  1 20:19:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 Sep 2025 20:19:52 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <v33d0f7gi3vTENFhMorwAurWzrUTlfsAyZQv7Kj1ODg=.54e13f74-96aa-454d-9c2a-44bcbccecbdf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
 <1LVa6gpDkvhjwbObQ0PmxjZzFRBIH_1qxXviLRypkBk=.da27ddd9-a2de-4a0c-b1f9-3732b4c565b9@github.com>
 <CKn_mWYfg-4Sn7yCcBIsvJJEiLATBdD8oCRHKDt5lUw=.21cdc091-5e62-4daf-9f02-2894ee7d2bdb@github.com>
 <0TlPQHFNxMNl22ulZGcxf4UURpcu4WT12xiTJsgYxqY=.c48a3949-b372-4adc-9ec7-d21b1ff88b79@github.com>
 <EgtRgQkXxB3nhTbdcgsZ9uKy7b787ajX2yCelHLGeZ4=.345d7e46-1cde-456e-bbf6-75001a08d9b4@github.com>
 <ofmC8m_hlxPgPSpKRePkS7M94nm-JYJmhdd_iesCjRQ=.0b05d84f-d188-4f27-9b1a-f90f5539c1b8@github.com>
 <sDR16DRroKxaNaG76VszAwDDfkSggB5QeNwDoodZQZ4=.ac146ee5-e518-401a-9b7c-ac02dbf41fed@github.com>
 <EzijMb2TPwlVJgHvwbEsKkJTGfNst47EZoChyExYskU=.5f743354-2623-4137-8c35-ba8ac34e103a@github.com>
 <mFnBF4T437E5xnoXPrI4teM8ZqyKMSPst1mlZld1VpU=.ebdbadfb-0f67-4ff8-9b33-4adb7089551b@github.com>
 <Fpgly2GR8R5yJ9HKzH67XUrUpvpz-SHlE0t
 oo46HGhY=.31440235-511a-4fff-b02f-ffafb398fddf@github.com>
 <v33d0f7gi3vTENFhMorwAurWzrUTlfsAyZQv7Kj1ODg=.54e13f74-96aa-454d-9c2a-44bcbccecbdf@github.com>
Message-ID: <rMS21GB0-A2lEBXOuldCezZnJDIyuuCeWeQzrr25sDI=.f6ad532d-b7e3-407f-9125-2e02dc146e08@github.com>

On Mon, 1 Sep 2025 19:35:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> (in your example with static context, my answer is that no, it should _not_ compile. A static context can't access instance fields from an enclosing class)
>
>> (in your example with static context, my answer is that no, it should _not_ compile. A static context can't access instance fields from an enclosing class)
> 
> Yep, sorry that was a dumb example - I should have replaced the static context with a lambda.
> 
> I'm all for increased flexibility, it's just that it would be nice if that came with a clean mental model.
> 
> For example, one possible mental model could be "works like effectively final" - which I think is what you're advocating - but for that we'd have to break the equivalence between `y` and `A.this.y` (probably worth it).

I guess that we should discuss access from a lambda with Dan, and if we decide the rules should be relaxed then do it but I think as part of a future PR. I'm also all in for relaxing restrictions

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2314534459

From vromero at openjdk.org  Mon Sep  1 21:42:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 Sep 2025 21:42:54 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v20]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <hXgrVotNRaixMYRmyAmEWz87zmF8AAAs72Lt_9Uw28U=.733eebe2-9755-4ec7-8eeb-87154a861ceb@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/e87108da..9014afc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=19
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=18-19

  Stats: 102 lines in 1 file changed: 43 ins; 55 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

PR: https://git.openjdk.org/valhalla/pull/1523

From vromero at openjdk.org  Mon Sep  1 21:42:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 Sep 2025 21:42:54 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v19]
In-Reply-To: <6-ljfwhhEVJgLROhAq-nr6je90eyUVm3yO9iZkkuB-g=.c0f071aa-b572-4f45-bbb2-949c1d50173e@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <xUG_UhPW3CKq8-bedVYGDOzDKHotf_J5kf9zyRBQefI=.c13f4c8a-5608-4264-8b01-28c9438bde18@github.com>
 <TBEL7d8tXDoRFtDeXE9559E1EYLMMx7cIBCIhutsGiY=.b68f7222-04ff-413a-8fa6-3419553685d4@github.com>
 <6-ljfwhhEVJgLROhAq-nr6je90eyUVm3yO9iZkkuB-g=.c0f071aa-b572-4f45-bbb2-949c1d50173e@github.com>
Message-ID: <g9cOrSWSDW0jF6cQ-Q8M33q_kGnAji0U41oaTUuRw2c=.7b6fe981-99ee-46ff-b9d6-49c34841c427@github.com>

On Mon, 1 Sep 2025 12:17:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Do we still need the changes in `Attr.checkAssignable` -- e.g. flexible constructor bodies used to check some extra properties in there. Now that we have an LHS variable in the prologue scanner, I wonder if we can unify the checks?
> 
> I did an experiment, and adding this:
> 
> ```
>             if (isInLHS && !insideLambdaOrClassDef) {
>                 // Check instance field assignments that appear in constructor prologues
>                 if (isEarlyReference(localEnv, tree.hasTag(SELECT) ? ((JCFieldAccess)tree).selected : null, sym)) {
>                     // Field may not be inherited from a superclass
>                     if (sym.owner != localEnv.enclClass.sym) {
>                         log.error(tree, Errors.CantRefBeforeCtorCalled(sym));
>                         return;
>                     }
> 
>                     // Field may not have an initializer
>                     if ((sym.flags() & HASINIT) != 0) {
>                         log.error(tree, Errors.CantAssignInitializedBeforeCtorCalled(sym));
>                         return;
>                     }
>                 }
>                 return;
>             };
> ```
> 
> At the start of `analyzeSymbol` seems to work fine. Maybe we want to break `analyzeSymbol` in different parts, one for reads and one for writes.
> 
> But one nice consequence of this is that now `isEarlyReference` is only called inside this visitor -- this means we can probably avoid having to pass `isPrologue = true` and, we can also avoid this dance:
> 
> ```
> tree.hasTag(SELECT) ? ((JCFieldAccess)tree).selected : null
> ```
> 
> Which is required at every callsite.

addressed in last commit, thanks!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1523#issuecomment-3243287853

From vromero at openjdk.org  Mon Sep  1 22:01:49 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 Sep 2025 22:01:49 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v21]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <MmJNoos2p1Rdi6e4Wt0HAdV_7MDRv7yLQ_gfueEOa9A=.41afa9ba-2826-4982-80c1-f94812aa8503@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  minor refactoring

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/9014afc5..792d98f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=20
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=19-20

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

PR: https://git.openjdk.org/valhalla/pull/1523

From coleenp at openjdk.org  Tue Sep  2 16:44:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Sep 2025 16:44:58 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data
In-Reply-To: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
Message-ID: <EVzrKvDQ8WrK5qfeUd0604itTnFpM1TcjpNHdKPpyR8=.adc1eb71-fdb5-4737-bf34-2b4535ff34c8@github.com>

On Fri, 9 May 2025 19:13:50 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.

Makes sense - found a typo.  Are you going to check this in with UseNewCode2 or you could add a global flag for this because I think you're going to need a new one?

src/hotspot/share/oops/refArrayKlass.hpp line 33:

> 31: class ClassLoaderData;
> 32: 
> 33: // RefjArrayKlass is the klass for arrays of references

you have an extra j in this.

src/hotspot/share/oops/refArrayKlass.hpp line 45:

> 43: 	 // Constructor
> 44: 	 RefArrayKlass(int n, Klass *element_klass, Symbol *name, bool null_free);
> 45: 	 static RefArrayKlass *allocate(ClassLoaderData *loader_data, int n, Klass *k, Symbol *name, bool null_free, TRAPS);

The stars go with the types, ie ClassLoaderData* loader_data.

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1452#pullrequestreview-2829768901
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2082556067
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2082556373

From fparain at openjdk.org  Tue Sep  2 16:44:58 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 2 Sep 2025 16:44:58 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data
Message-ID: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>

Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.

-------------

Commit messages:
 - Moved get_Klass() back to protected and updated usages
 - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
 - Linked TODOs to JDK-8366668
 - Multidim array fix
 - Cleanup T_FLAT_ELEMENT related code
 - Fix for isAssignableFrom + tests
 - Problem listing due to 8366440
 - EnableValhalla by default
 - More JIT fixes
 - Test fix
 - ... and 53 more: https://git.openjdk.org/valhalla/compare/bd1d97b7...810a36fa

Changes: https://git.openjdk.org/valhalla/pull/1452/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366705
  Stats: 4736 lines in 177 files changed: 2940 ins; 1061 del; 735 mod
  Patch: https://git.openjdk.org/valhalla/pull/1452.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1452/head:pull/1452

PR: https://git.openjdk.org/valhalla/pull/1452

From fparain at openjdk.org  Tue Sep  2 17:44:25 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 2 Sep 2025 17:44:25 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v2]
In-Reply-To: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
Message-ID: <cG6J9PhvoUX7QFdIjCPqj929y0GZC-CYAKM2MNYquTo=.633acc79-ca5b-412a-930a-43766302543f@github.com>

> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Small cleanup

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1452/files
  - new: https://git.openjdk.org/valhalla/pull/1452/files/810a36fa..6087dbda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1452.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1452/head:pull/1452

PR: https://git.openjdk.org/valhalla/pull/1452

From fparain at openjdk.org  Tue Sep  2 17:49:28 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 2 Sep 2025 17:49:28 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v3]
In-Reply-To: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
Message-ID: <dXhbp5M6ANCXeaJdgfILwCJP8MSKS7KHtY7znO-oJl8=.7f240e61-a3b7-4595-b57e-0aa7d79a3863@github.com>

> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Forgot a TODO

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1452/files
  - new: https://git.openjdk.org/valhalla/pull/1452/files/6087dbda..9b254f2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1452.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1452/head:pull/1452

PR: https://git.openjdk.org/valhalla/pull/1452

From liach at openjdk.org  Tue Sep  2 22:10:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Sep 2025 22:10:56 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v2]
In-Reply-To: <rMFD881o9YmHgQjx7-omjytiLata0bTDGTEP9So-O7I=.e5bb0242-96b9-456b-9e4d-36a8a396f0d6@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
 <Avfg0PVdwWlAtuLdVYsESArMco0tGSu4tyCKvDi7-vs=.2c44ae60-27e7-48e3-a94f-d7a0df1630c1@github.com>
 <rMFD881o9YmHgQjx7-omjytiLata0bTDGTEP9So-O7I=.e5bb0242-96b9-456b-9e4d-36a8a396f0d6@github.com>
Message-ID: <hPjOrk8B4IevJz4Hvork38iz9tQd23Zz9DUDQ610yEA=.e08a53fc-a52b-4ee0-af73-0c9a4aead579@github.com>

On Mon, 1 Sep 2025 11:01:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Years
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 348:
> 
>> 346:                         .build(proxyDesc, clb -> {
>> 347:             clb.withSuperclass(CD_Object)
>> 348:                .withFlags(ACC_SUPER | ACC_FINAL | ACC_SYNTHETIC)
> 
> I presume this change is because the classfile API will be able to filter out ACC_SUPER based on the target version?

No, because the old code is wrong - the flags are no-ops if the class file version is not latest release's preview (by default it is latest release.0)

> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 461:
> 
>> 459:          * @jvms 4.1 The {@code ClassFile} Structure
>> 460:          */
>> 461:         CLASS(ACC_PUBLIC | ACC_FINAL | ACC_IDENTITY |
> 
> Shouldn't we have a mapping here for `JDK N - 1` that has ACC_SUPER instead of ACC_IDENTITY ? For inner classes this is not needed because inner classes could never have ACC_SUPER -- but regular classes could?

This is just the bit masks, where ACC_SUPER is equivalent to ACC_IDENTITY. So 0x20 is always there in classes, but newly introduced to inner classes, so yes.

> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 3348:
> 
>> 3346:             flags |= MODULE;
>> 3347:         }
>> 3348:         if (((flags & ACC_IDENTITY) != 0 && !isMigratedValueClass(flags))
> 
> do we still need the `isMigratedValueClass` ? Aren't migrated value classes treated the same as ordinary value classes thanks to the work we did to load different classfiles based on preview-ness?

I only adjusted this because this is incorrectly marking Java 25 classes as value classes in InnerClasses. This call didn't affect my patch, should I investigate it now?

> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1772:
> 
>> 1770:         } else {
>> 1771:             poolbuf.appendChar(target.minorVersion);
>> 1772:             markedPreview = target.minorVersion == ClassFile.PREVIEW_MINOR_VERSION;
> 
> I don't think `target.minorVersion` can ever be preview?

Sure. I thought this path could have been used by -XDforcePreview. Do you think I can just do:


boolean markedPreview = preview.isEnabled() && preview.usesPreview(c.sourcefile);
if (markedPreview) {

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2317278677
PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2317276520
PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2317273110
PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2317270357

From liach at openjdk.org  Wed Sep  3 02:43:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 02:43:03 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v3]
In-Reply-To: <dXhbp5M6ANCXeaJdgfILwCJP8MSKS7KHtY7znO-oJl8=.7f240e61-a3b7-4595-b57e-0aa7d79a3863@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <dXhbp5M6ANCXeaJdgfILwCJP8MSKS7KHtY7znO-oJl8=.7f240e61-a3b7-4595-b57e-0aa7d79a3863@github.com>
Message-ID: <IwMeGxEiG9wYBUNaybVKcvzXIFw8XxMM_bBi0_DKEAc=.b9fe4996-2cdf-481e-9e7c-d267018d47ac@github.com>

On Tue, 2 Sep 2025 17:49:28 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
>> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
>> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot a TODO

src/hotspot/share/cds/archiveBuilder.cpp line 827:

> 825:         num_obj_array_klasses ++;
> 826:         type = "ref array";
> 827:     } else if (k->is_objArray_klass()) {

Is this redundant? I think flat arrays union ref arrays = obj arrays?

src/hotspot/share/cds/cdsEnumKlass.cpp line 92:

> 90:   }
> 91:   oop oop_field = mirror->obj_field(fd.offset());
> 92:   Klass* oop_field_klass = oop_field->is_objArray() ? oop_field->klass()->super() : oop_field->klass();

Hmm, what does this do? I assume `is_objArray` tests if something can be converted to Java `Object[]`. In this case, CDS should check if the component type of the array instead of the array supepr class, I think? The original code did not call `super()`.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2317612466
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2317611161

From dsimms at openjdk.org  Wed Sep  3 07:12:39 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 3 Sep 2025 07:12:39 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <dApbB4UDKy1YGeZ5n49yN8rE6MZokDBsxukTCjvHAHU=.ce275527-fc3e-435a-9858-ffacafbceddb@github.com>
References: <dApbB4UDKy1YGeZ5n49yN8rE6MZokDBsxukTCjvHAHU=.ce275527-fc3e-435a-9858-ffacafbceddb@github.com>
Message-ID: <7xytaKJ74H4uB2cILIiKj3fBAAO02NKAaTt5cEQu-Ak=.00cf0b5d-ea48-47b8-9df0-0f2cada57e1f@github.com>

> Merge tag 'jdk-25+26' into lworld_merge_jdk_25_26
> 
> Added tag jdk-25+26 for changeset c59e44a7

David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 220 commits:

 - Adjust testing
 - Merge branch 'lworld' into lworld_merge_jdk_25_26
 - TemplateTable::fast_storefield r3 -> r5
 - Merge jdk
   
   Merge tag 'jdk-25+26' into lworld_merge_jdk_25_26
   
   Added tag jdk-25+26 for changeset c59e44a7
 - 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual
   
   Reviewed-by: lmesnik, dholmes, sspitsyn, syan
 - 8337666: AArch64: SHA3 GPR intrinsic
   
   Reviewed-by: aph
 - 8358689: test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build  after JDK-8351594
   
   Reviewed-by: alanb
 - 8358633: Test ThreadPoolExecutorTest::testTimedInvokeAnyNullTimeUnit is broken by JDK-8347491
   
   Reviewed-by: alanb
 - 8358590: JFR: Include min and max in MethodTiming event
   
   Reviewed-by: mgronlun
 - 8351594: JFR: Rate-limited sampling of Java events
   
   Reviewed-by: mgronlun, alanb
 - ... and 210 more: https://git.openjdk.org/valhalla/compare/63314117...1753307e

-------------

Changes: https://git.openjdk.org/valhalla/pull/1530/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1530&range=01
  Stats: 69099 lines in 1073 files changed: 42262 ins; 16729 del; 10108 mod
  Patch: https://git.openjdk.org/valhalla/pull/1530.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1530/head:pull/1530

PR: https://git.openjdk.org/valhalla/pull/1530

From dsimms at openjdk.org  Wed Sep  3 07:29:08 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 3 Sep 2025 07:29:08 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <dApbB4UDKy1YGeZ5n49yN8rE6MZokDBsxukTCjvHAHU=.ce275527-fc3e-435a-9858-ffacafbceddb@github.com>
References: <dApbB4UDKy1YGeZ5n49yN8rE6MZokDBsxukTCjvHAHU=.ce275527-fc3e-435a-9858-ffacafbceddb@github.com>
Message-ID: <rXILhIuKB2NkGZopnNgfhjUcfKSPOmBKBhV4M0O6r4M=.d6ef8835-b29b-4802-b616-a5623355512c@github.com>

On Fri, 22 Aug 2025 09:03:29 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-25+26' into lworld_merge_jdk_25_26
> 
> Added tag jdk-25+26 for changeset c59e44a7

This pull request has now been integrated.

Changeset: 43c6b8a4
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/43c6b8a42af17f61e93480e6b4341b604df53855
Stats:     69099 lines in 1073 files changed: 42262 ins; 16729 del; 10108 mod

Merge jdk

Merge jdk-25+26 jdk-26+0

-------------

PR: https://git.openjdk.org/valhalla/pull/1530

From dsimms at openjdk.org  Wed Sep  3 09:01:16 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 3 Sep 2025 09:01:16 GMT
Subject: [lworld] Integrated: Adjust testing 8366774
In-Reply-To: <QOzA-DFp6kW0mLKrtes2fyMcNKMI0WLmugZVx-gVDWw=.0da0965b-5cbf-4aeb-8189-39ad9300fd1d@github.com>
References: <QOzA-DFp6kW0mLKrtes2fyMcNKMI0WLmugZVx-gVDWw=.0da0965b-5cbf-4aeb-8189-39ad9300fd1d@github.com>
Message-ID: <_7Gqw67m_B2D81ig1y7tFYO-uxupzDrCVzjy4D_qAf8=.7fdce07a-b510-40b3-ae00-b88fd552c60d@github.com>

On Wed, 3 Sep 2025 08:56:28 GMT, David Simms <dsimms at openjdk.org> wrote:

> Problem listed 8366774

This pull request has now been integrated.

Changeset: 22e9d5f5
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/22e9d5f58415d20d89a96a3bbcb6d7fffde9f8c1
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

Adjust testing 8366774

-------------

PR: https://git.openjdk.org/valhalla/pull/1541

From dsimms at openjdk.org  Wed Sep  3 09:01:16 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 3 Sep 2025 09:01:16 GMT
Subject: [lworld] Integrated: Adjust testing 8366774
Message-ID: <QOzA-DFp6kW0mLKrtes2fyMcNKMI0WLmugZVx-gVDWw=.0da0965b-5cbf-4aeb-8189-39ad9300fd1d@github.com>

Problem listed 8366774

-------------

Commit messages:
 - Adjust testing 8366774

Changes: https://git.openjdk.org/valhalla/pull/1541/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1541&range=00
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1541.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1541/head:pull/1541

PR: https://git.openjdk.org/valhalla/pull/1541

From mcimadamore at openjdk.org  Wed Sep  3 11:32:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 Sep 2025 11:32:57 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v2]
In-Reply-To: <hPjOrk8B4IevJz4Hvork38iz9tQd23Zz9DUDQ610yEA=.e08a53fc-a52b-4ee0-af73-0c9a4aead579@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
 <Avfg0PVdwWlAtuLdVYsESArMco0tGSu4tyCKvDi7-vs=.2c44ae60-27e7-48e3-a94f-d7a0df1630c1@github.com>
 <rMFD881o9YmHgQjx7-omjytiLata0bTDGTEP9So-O7I=.e5bb0242-96b9-456b-9e4d-36a8a396f0d6@github.com>
 <hPjOrk8B4IevJz4Hvork38iz9tQd23Zz9DUDQ610yEA=.e08a53fc-a52b-4ee0-af73-0c9a4aead579@github.com>
Message-ID: <YmLp1rlVcCXYEopk2SxeGIPxNw40-yEwICjq1GP-IYA=.42d77061-2d07-49dd-a3e3-0214b351e395@github.com>

On Tue, 2 Sep 2025 22:08:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 348:
>> 
>>> 346:                         .build(proxyDesc, clb -> {
>>> 347:             clb.withSuperclass(CD_Object)
>>> 348:                .withFlags(ACC_SUPER | ACC_FINAL | ACC_SYNTHETIC)
>> 
>> I presume this change is because the classfile API will be able to filter out ACC_SUPER based on the target version?
>
> No, because the old code is wrong - the flags are no-ops if the class file version is not latest release's preview (by default it is latest release.0)

Ok, but then shouldn't this add both ACC_IDENTITY and ACC_SUPER and leave it to the API to decide what to emit based on version?

>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 3348:
>> 
>>> 3346:             flags |= MODULE;
>>> 3347:         }
>>> 3348:         if (((flags & ACC_IDENTITY) != 0 && !isMigratedValueClass(flags))
>> 
>> do we still need the `isMigratedValueClass` ? Aren't migrated value classes treated the same as ordinary value classes thanks to the work we did to load different classfiles based on preview-ness?
>
> I only adjusted this because this is incorrectly marking Java 25 classes as value classes in InnerClasses. This call didn't affect my patch, should I investigate it now?

It's ok to investigate in a separate PR

>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1772:
>> 
>>> 1770:         } else {
>>> 1771:             poolbuf.appendChar(target.minorVersion);
>>> 1772:             markedPreview = target.minorVersion == ClassFile.PREVIEW_MINOR_VERSION;
>> 
>> I don't think `target.minorVersion` can ever be preview?
>
> Sure. I thought this path could have been used by -XDforcePreview. Do you think I can just do:
> 
> 
> boolean markedPreview = preview.isEnabled() && preview.usesPreview(c.sourcefile);
> if (markedPreview) {

IIRC, `forcePreview` makes use of _any_ feature behave as if they were preview features, meaning you will get classfile version pollution. But it doesn't alter Target. So yes, the code you suggest should be correct.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2318671623
PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2318672870
PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2318676190

From mcimadamore at openjdk.org  Wed Sep  3 13:29:55 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 Sep 2025 13:29:55 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v21]
In-Reply-To: <MmJNoos2p1Rdi6e4Wt0HAdV_7MDRv7yLQ_gfueEOa9A=.41afa9ba-2826-4982-80c1-f94812aa8503@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <MmJNoos2p1Rdi6e4Wt0HAdV_7MDRv7yLQ_gfueEOa9A=.41afa9ba-2826-4982-80c1-f94812aa8503@github.com>
Message-ID: <K7VqapYa7arzBfYZFUQ9vlt6Ym8jTYeglSLBK0S15S4=.d373385f-66f7-422f-918e-3a609e753a99@github.com>

On Mon, 1 Sep 2025 22:01:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor refactoring

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1387:

> 1385:         void analyzeSymbol(JCTree tree) {
> 1386:             Symbol sym = TreeInfo.symbolFor(tree);
> 1387:             if (isInLHS && !insideLambdaOrClassDef) {

Question: for stuff that is NOT in LHS -- shouldn't we check that preview features are enabled? E.g. we don't want to allow reads in prologue unless `--enable-preview` is present, right?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1465:

> 1463:                     sym.isMemberOf(env.enclClass.sym, types)) {
> 1464:                 // Allow "Foo.this.x" when "Foo" is (also) an outer class, as this refers to the outer instance
> 1465:                 if (base != null) {

(optional) style only -- instead of setting `base` and then checking `base != null`, we could just rewrite the `if` as `if (tree.hasTag(SELECT))` ?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2318981814
PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2318977499

From liach at openjdk.org  Wed Sep  3 14:13:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 14:13:59 GMT
Subject: [lworld] RFR: 8366214: [lworld] Use Objects.equals in HashMap and
 ConcurrentHashmap
In-Reply-To: <ir9FyNvCzXm0bk72lW9C_tY2EsVIC5E2L8m3vbkjfQo=.812d0d1c-6d7d-4127-98b6-a2e6e8b49633@github.com>
References: <ir9FyNvCzXm0bk72lW9C_tY2EsVIC5E2L8m3vbkjfQo=.812d0d1c-6d7d-4127-98b6-a2e6e8b49633@github.com>
Message-ID: <qgMEb7bmY5ZLVKvO0byLVrlvtjzpchxYhEnneY22QuM=.f28490c0-db9e-4559-8db4-86323a6c8f32@github.com>

On Wed, 27 Aug 2025 19:40:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> As observed in [JDK-8366043](https://bugs.openjdk.org/browse/JDK-8366043) [lworld] (LIFE = Legacy Idiom For Equality) causes performance regressions.
> Updating HashMap and ConcurrentHashMap to use `java.util.Objects.equals` will make it easier to measure performance of options that remove or modify the use of `==`
> 
> Replace constructs like:
> 
> -                        ((k = e.key) == key || (key != null && key.equals(k))))
> with:
> +                        Objects.equals(key, k))
> 
> 
> The changes in ConcurrentHashMap are a bit different due to the use of null as a sentinel.
> 
> The order of arguments to the .equals methods must remain the same to ensure compatibility.

I think my concerns are addressed so far.

-------------

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1536#pullrequestreview-3180866440

From liach at openjdk.org  Wed Sep  3 14:18:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 14:18:06 GMT
Subject: [lworld] RFR: 8366802: [lworld]
 jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails since jdk-26+26
Message-ID: <xIEK7W3jwVr6dSeGVgwd13aWzhkCV2SBhSx_QJeKuv8=.48a1f4f9-b76f-4eba-b357-655f62a66c32@github.com>

The missing link points to the preview note on `Attributes::loadableDescriptors`. Simply marking this API as preview fixes it.

Also I fixed the since version from 23 to Valhalla.

-------------

Commit messages:
 - 8366802: [lworld] jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails since jdk-26+26

Changes: https://git.openjdk.org/valhalla/pull/1542/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1542&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366802
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1542.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1542/head:pull/1542

PR: https://git.openjdk.org/valhalla/pull/1542

From liach at openjdk.org  Wed Sep  3 14:19:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 14:19:03 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v2]
In-Reply-To: <YmLp1rlVcCXYEopk2SxeGIPxNw40-yEwICjq1GP-IYA=.42d77061-2d07-49dd-a3e3-0214b351e395@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
 <Avfg0PVdwWlAtuLdVYsESArMco0tGSu4tyCKvDi7-vs=.2c44ae60-27e7-48e3-a94f-d7a0df1630c1@github.com>
 <rMFD881o9YmHgQjx7-omjytiLata0bTDGTEP9So-O7I=.e5bb0242-96b9-456b-9e4d-36a8a396f0d6@github.com>
 <hPjOrk8B4IevJz4Hvork38iz9tQd23Zz9DUDQ610yEA=.e08a53fc-a52b-4ee0-af73-0c9a4aead579@github.com>
 <YmLp1rlVcCXYEopk2SxeGIPxNw40-yEwICjq1GP-IYA=.42d77061-2d07-49dd-a3e3-0214b351e395@github.com>
Message-ID: <a_SHd8uWYV4-FSMl941svGAD_OSy0NKGMoMQpXfF5AQ=.a3e0fad9-f91f-4db2-9f90-eb8626a64346@github.com>

On Wed, 3 Sep 2025 11:28:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> No, because the old code is wrong - the flags are no-ops if the class file version is not latest release's preview (by default it is latest release.0)
>
> Ok, but then shouldn't this add both ACC_IDENTITY and ACC_SUPER and leave it to the API to decide what to emit based on version?

ACC_ ones are bit masks, and distinguishing them is meaningless. AccessFlag.IDENTITY and AccessFlag.SUPER are the actual differing ones. Validation of access flags by version requires somewhat invasive changes to the ClassFile API, so is not included in this patch.

Reminder, this class building is completely in non-preview. There is no point talking about identity here.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2319129713

From dsimms at openjdk.org  Wed Sep  3 14:22:00 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 3 Sep 2025 14:22:00 GMT
Subject: [lworld] RFR: 8366802: [lworld]
 jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails since jdk-26+26
In-Reply-To: <xIEK7W3jwVr6dSeGVgwd13aWzhkCV2SBhSx_QJeKuv8=.48a1f4f9-b76f-4eba-b357-655f62a66c32@github.com>
References: <xIEK7W3jwVr6dSeGVgwd13aWzhkCV2SBhSx_QJeKuv8=.48a1f4f9-b76f-4eba-b357-655f62a66c32@github.com>
Message-ID: <XQ-MslMWX0552e9w0H6bvIucgL4Nw2nb4Cg4CTKi1ms=.1a449bad-5283-49c1-800a-775f32290c2b@github.com>

On Wed, 3 Sep 2025 14:12:47 GMT, Chen Liang <liach at openjdk.org> wrote:

> The missing link points to the preview note on `Attributes::loadableDescriptors`. Simply marking this API as preview fixes it.
> 
> Also I fixed the since version from 23 to Valhalla.

Looks good, thanks !

-------------

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1542#pullrequestreview-3180909587

From liach at openjdk.org  Wed Sep  3 14:24:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 14:24:50 GMT
Subject: [lworld] RFR: 8366802: [lworld]
 jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails since jdk-26+26
In-Reply-To: <xIEK7W3jwVr6dSeGVgwd13aWzhkCV2SBhSx_QJeKuv8=.48a1f4f9-b76f-4eba-b357-655f62a66c32@github.com>
References: <xIEK7W3jwVr6dSeGVgwd13aWzhkCV2SBhSx_QJeKuv8=.48a1f4f9-b76f-4eba-b357-655f62a66c32@github.com>
Message-ID: <0LweOA_oBt7lKzs0iR7UifhDv4lRORbA2YbhvaOxC5g=.37f420dd-1025-4109-8411-50495deb2b69@github.com>

On Wed, 3 Sep 2025 14:12:47 GMT, Chen Liang <liach at openjdk.org> wrote:

> The missing link points to the preview note on `Attributes::loadableDescriptors`. Simply marking this API as preview fixes it.
> 
> Also I fixed the since version from 23 to Valhalla.

Will integrate once CI is clear.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1542#issuecomment-3249478551

From mchevalier at openjdk.org  Wed Sep  3 14:31:39 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 3 Sep 2025 14:31:39 GMT
Subject: [lworld] RFR: 8365996: [lworld] Register corruption in GC barrier slow
 paths in scalarized calling convention on AArch64
Message-ID: <3Iava9CQw9XwGAx4b_6_nWV0bzaXXQSGJeyZoyBN2fM=.2805f743-b731-4e19-8d7c-5666c8a552de@github.com>

That fixes a pair of issues. @TobiHartmann fixed one where some native function call would mess up registers. Pushing and popping them solves it.

The second part is about using `x29`, aka `fp` (frame pointer), as a regular register. Even when not used as the frame pointer register `x29` is nevertheless saved on the stack when setting up the frame, for when it's used as actually the frame pointer. On exit, `x29` and `x30` are restored from there. But with Valhalla, they can be saved twice on the stack! When the non-scalarized entry point of a C2-compiled method is used, one might need a bit more space to scalarize the arguments. This leads to shape such as drawn here.

https://github.com/openjdk/valhalla/blob/63314117aa0c30f1a5928b56d21d944de063b8c6/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6107-L6126

Currently, `LR` and `FP` are restored from the copy `#1`. But the comment is not quite exact: `FP #1` and `FP #2` won't be always the same in case it contained an oop to an object that the GC moved between frame creation and frame destruction: the GC knows only one spilled location for each register, and in the case of `x29`, it's `FP #2.`

It seems difficult to adapt the GC mechanisms to handle more than one location to update for a register. Likewise, we know that `LR #1` is update, but `LR #2` doesn't seem to be: it's fine to update only one, if we know which one is the trustworthy one. Updating only one `FP` won't mess with the cases where we are actually using `x29` as frame pointer since then, the GC won't update any of them as they won't contain oops.

The process is rather simple: since we need to load `sp_inc` to know how much to pop from the stack, by changing the `ldr` into a `ldp`, we can load `FP #2` into `x29` at the same time. Then, we reduce the stack by `sp_inc`, we read LR#1 (always 1 word under the new top), and we pop the two last words left. This works whether we need some stack extension or not, and makes sure `sp` stays 16-byte aligned when reading `LR #1` (I've learned the hard way, the SIGBUS way, it's a thing...). This requires only one more instruction than the old way. Let's call that a lesser evil.

Thanks,
Marc

-------------

Commit messages:
 - Remove some enter/leave
 - TODO 8366717
 - Apply Tobias' patch
 - Remove big test not to integrate
 - Comment + test
 - Testing
 - More TODOs
 - Some more alignment between AArch64 and x64 code
 - Enable test on AArch64
 - Some TODOs
 - ... and 3 more: https://git.openjdk.org/valhalla/compare/68b13b46...6bf70658

Changes: https://git.openjdk.org/valhalla/pull/1540/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1540&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365996
  Stats: 272 lines in 14 files changed: 184 ins; 30 del; 58 mod
  Patch: https://git.openjdk.org/valhalla/pull/1540.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1540/head:pull/1540

PR: https://git.openjdk.org/valhalla/pull/1540

From fparain at openjdk.org  Wed Sep  3 14:43:55 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 3 Sep 2025 14:43:55 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
Message-ID: <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>

> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.

Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:

 - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
 - Forgot a TODO
 - Small cleanup
 - Merge remote-tracking branch 'upstream/lworld' into array_klasses
 - Moved get_Klass() back to protected and updated usages
 - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
 - Linked TODOs to JDK-8366668
 - Multidim array fix
 - Cleanup T_FLAT_ELEMENT related code
 - Fix for isAssignableFrom + tests
 - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6

-------------

Changes: https://git.openjdk.org/valhalla/pull/1452/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=03
  Stats: 4735 lines in 177 files changed: 2938 ins; 1060 del; 737 mod
  Patch: https://git.openjdk.org/valhalla/pull/1452.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1452/head:pull/1452

PR: https://git.openjdk.org/valhalla/pull/1452

From liach at openjdk.org  Wed Sep  3 14:56:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 14:56:59 GMT
Subject: [lworld] RFR: 8366802: [lworld]
 jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails since jdk-26+26
In-Reply-To: <xIEK7W3jwVr6dSeGVgwd13aWzhkCV2SBhSx_QJeKuv8=.48a1f4f9-b76f-4eba-b357-655f62a66c32@github.com>
References: <xIEK7W3jwVr6dSeGVgwd13aWzhkCV2SBhSx_QJeKuv8=.48a1f4f9-b76f-4eba-b357-655f62a66c32@github.com>
Message-ID: <45f1hWcGy4eOyhM58n2k-sHTlFgrXgk-Tbd1GMF2Za0=.b90330f9-3345-429a-8008-99f34417edeb@github.com>

On Wed, 3 Sep 2025 14:12:47 GMT, Chen Liang <liach at openjdk.org> wrote:

> The missing link points to the preview note on `Attributes::loadableDescriptors`. Simply marking this API as preview fixes it.
> 
> Also I fixed the since version from 23 to Valhalla.

Turns out this requires a docs profile to run on CI, but since this passes locally with local docs I will assume this is good.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1542#issuecomment-3249597104

From liach at openjdk.org  Wed Sep  3 14:56:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 14:56:59 GMT
Subject: [lworld] Integrated: 8366802: [lworld]
 jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails since jdk-26+26
In-Reply-To: <xIEK7W3jwVr6dSeGVgwd13aWzhkCV2SBhSx_QJeKuv8=.48a1f4f9-b76f-4eba-b357-655f62a66c32@github.com>
References: <xIEK7W3jwVr6dSeGVgwd13aWzhkCV2SBhSx_QJeKuv8=.48a1f4f9-b76f-4eba-b357-655f62a66c32@github.com>
Message-ID: <PyS1SNwA3WUNMn-zI0B4_n-X31_1v7BhjG7XLiUPAWs=.37c4894c-4cdb-4854-98e4-676461601485@github.com>

On Wed, 3 Sep 2025 14:12:47 GMT, Chen Liang <liach at openjdk.org> wrote:

> The missing link points to the preview note on `Attributes::loadableDescriptors`. Simply marking this API as preview fixes it.
> 
> Also I fixed the since version from 23 to Valhalla.

This pull request has now been integrated.

Changeset: 480094c9
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/480094c9458054e8fdb76ea4a84efad132ef5ea5
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8366802: [lworld] jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails since jdk-26+26

Reviewed-by: dsimms

-------------

PR: https://git.openjdk.org/valhalla/pull/1542

From fparain at openjdk.org  Wed Sep  3 15:01:04 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 3 Sep 2025 15:01:04 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v3]
In-Reply-To: <IwMeGxEiG9wYBUNaybVKcvzXIFw8XxMM_bBi0_DKEAc=.b9fe4996-2cdf-481e-9e7c-d267018d47ac@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <dXhbp5M6ANCXeaJdgfILwCJP8MSKS7KHtY7znO-oJl8=.7f240e61-a3b7-4595-b57e-0aa7d79a3863@github.com>
 <IwMeGxEiG9wYBUNaybVKcvzXIFw8XxMM_bBi0_DKEAc=.b9fe4996-2cdf-481e-9e7c-d267018d47ac@github.com>
Message-ID: <DkV64TVlLNDkHVkLIV25VJLpxO5f5ZNcwpcABgjLHV0=.5e7e0d8b-5ece-4657-ac3a-6b2ae8dd5809@github.com>

On Wed, 3 Sep 2025 02:39:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Forgot a TODO
>
> src/hotspot/share/cds/archiveBuilder.cpp line 827:
> 
>> 825:         num_obj_array_klasses ++;
>> 826:         type = "ref array";
>> 827:     } else if (k->is_objArray_klass()) {
> 
> Is this redundant? I think flat arrays union ref arrays = obj arrays?

The VM creates instances of `ObjArrayKlass` that are not instances of `RefArrayKlass` nor `FlatArrayKlass`.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319260824

From thartmann at openjdk.org  Wed Sep  3 15:10:54 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 3 Sep 2025 15:10:54 GMT
Subject: [lworld] RFR: 8365996: [lworld] Register corruption in GC barrier
 slow paths in scalarized calling convention on AArch64
In-Reply-To: <3Iava9CQw9XwGAx4b_6_nWV0bzaXXQSGJeyZoyBN2fM=.2805f743-b731-4e19-8d7c-5666c8a552de@github.com>
References: <3Iava9CQw9XwGAx4b_6_nWV0bzaXXQSGJeyZoyBN2fM=.2805f743-b731-4e19-8d7c-5666c8a552de@github.com>
Message-ID: <m0RE5Y58dnwAt_dalZdFIfP1CYGsWkkI1YmlTUXQc9k=.e2556ac3-a57e-4964-a4ef-c69059552309@github.com>

On Tue, 2 Sep 2025 15:19:58 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> That fixes a pair of issues. @TobiHartmann fixed one where some native function call would mess up registers. Pushing and popping them solves it.
> 
> The second part is about using `x29`, aka `fp` (frame pointer), as a regular register. Even when not used as the frame pointer register `x29` is nevertheless saved on the stack when setting up the frame, for when it's used as actually the frame pointer. On exit, `x29` and `x30` are restored from there. But with Valhalla, they can be saved twice on the stack! When the non-scalarized entry point of a C2-compiled method is used, one might need a bit more space to scalarize the arguments. This leads to shape such as drawn here.
> 
> https://github.com/openjdk/valhalla/blob/63314117aa0c30f1a5928b56d21d944de063b8c6/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6107-L6126
> 
> Currently, `LR` and `FP` are restored from the copy `#1`. But the comment is not quite exact: `FP #1` and `FP #2` won't be always the same in case it contained an oop to an object that the GC moved between frame creation and frame destruction: the GC knows only one spilled location for each register, and in the case of `x29`, it's `FP #2.`
> 
> It seems difficult to adapt the GC mechanisms to handle more than one location to update for a register. Likewise, we know that `LR #1` is update, but `LR #2` doesn't seem to be: it's fine to update only one, if we know which one is the trustworthy one. Updating only one `FP` won't mess with the cases where we are actually using `x29` as frame pointer since then, the GC won't update any of them as they won't contain oops.
> 
> The process is rather simple: since we need to load `sp_inc` to know how much to pop from the stack, by changing the `ldr` into a `ldp`, we can load `FP #2` into `x29` at the same time. Then, we reduce the stack by `sp_inc`, we read LR#1 (always 1 word under the new top), and we pop the two last words left. This works whether we need some stack extension or not, and makes sure `sp` stays 16-byte aligned when reading `LR #1` (I've learned the hard way, the SIGBUS way, it's a thing...). This requires only one more instruction than the old way. Let's call that a lesser evil.
> 
> Thanks,
> Marc

Great job in deep diving right into this, identifying the root cause and fixing, Marc! Looks good to me.

src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp line 93:

> 91:     if (!precise || (dst.index() == noreg && dst.offset() == 0)) {
> 92:       if (tmp3 != noreg) {
> 93:         // TODO This change is from before the 'tmp3' arg was added to mainline, check if it's still needed. Same on x64. Also, this should be a __ lea

Suggestion:

        // TODO 8366717 This change is from before the 'tmp3' arg was added to mainline, check if it's still needed. Same on x64. Also, this should be a __ lea

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 7408:

> 7406:   }
> 7407: 
> 7408:   // TODO This is probably okay but looks fishy because stream is reset in the "Set null marker to zero" case just above. Same on x64.

Suggestion:

  // TODO 8366717 This is probably okay but looks fishy because stream is reset in the "Set null marker to zero" case just above. Same on x64.

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3129:

> 3127: 
> 3128:   int pack_fields_off = __ offset();
> 3129:   // TODO this would need to go to pack_fields_jobject_off as well ...

Suggestion:

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1540#pullrequestreview-3181030650
PR Review Comment: https://git.openjdk.org/valhalla/pull/1540#discussion_r2319278789
PR Review Comment: https://git.openjdk.org/valhalla/pull/1540#discussion_r2319279309
PR Review Comment: https://git.openjdk.org/valhalla/pull/1540#discussion_r2319221692

From rriggs at openjdk.org  Wed Sep  3 15:52:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 3 Sep 2025 15:52:03 GMT
Subject: [lworld] Integrated: 8366214: [lworld] Use Objects.equals in HashMap
 and ConcurrentHashmap
In-Reply-To: <ir9FyNvCzXm0bk72lW9C_tY2EsVIC5E2L8m3vbkjfQo=.812d0d1c-6d7d-4127-98b6-a2e6e8b49633@github.com>
References: <ir9FyNvCzXm0bk72lW9C_tY2EsVIC5E2L8m3vbkjfQo=.812d0d1c-6d7d-4127-98b6-a2e6e8b49633@github.com>
Message-ID: <F9ihqRgHl3mqM9Xn_CbiCDguMfvkyWXXizPCRFYv7IU=.8e36c233-7054-4ca1-957e-7ed9fe10dedb@github.com>

On Wed, 27 Aug 2025 19:40:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> As observed in [JDK-8366043](https://bugs.openjdk.org/browse/JDK-8366043) [lworld] (LIFE = Legacy Idiom For Equality) causes performance regressions.
> Updating HashMap and ConcurrentHashMap to use `java.util.Objects.equals` will make it easier to measure performance of options that remove or modify the use of `==`
> 
> Replace constructs like:
> 
> -                        ((k = e.key) == key || (key != null && key.equals(k))))
> with:
> +                        Objects.equals(key, k))
> 
> 
> The changes in ConcurrentHashMap are a bit different due to the use of null as a sentinel.
> 
> The order of arguments to the .equals methods must remain the same to ensure compatibility.

This pull request has now been integrated.

Changeset: c8d4a247
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c8d4a247861052aa6ed43125bcbe49995326938f
Stats:     45 lines in 2 files changed: 1 ins; 7 del; 37 mod

8366214: [lworld] Use Objects.equals in HashMap and ConcurrentHashmap

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/valhalla/pull/1536

From liach at openjdk.org  Wed Sep  3 15:58:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 15:58:04 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v3]
In-Reply-To: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
Message-ID: <xcdgFPLqqQzgTQeqcC5T52rwitgBeriqblFjdRjUgEw=.3dd0e3a6-02a0-4010-87ea-bf08b6a615a6@github.com>

> Improve access flag reflection for preview on/off.
> 
> In this process, I noted javac is incorrectly injecting ACC_IDENTITY to 69.0 class' `InnerClasses` attribute and fixed that.
> 
> There is still some inconsistency, such as implying ACC_IDENTITY when preview is on for classes. Don't know if we have discussed on this yet.
> 
> No new test failures.

Chen Liang 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 11 additional commits since the last revision:

 - markedPreview handling
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/preview-reflects
 - Years
 - Stage
 - Stage
 - Trivial
 - Unit test
 - Fix identity flag missing for preview inner classes
 - Stage
 - Fixes
 - ... and 1 more: https://git.openjdk.org/valhalla/compare/4caba109...94ee7a1e

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1533/files
  - new: https://git.openjdk.org/valhalla/pull/1533/files/62ed7b13..94ee7a1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1533&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1533&range=01-02

  Stats: 69778 lines in 1121 files changed: 42679 ins; 16925 del; 10174 mod
  Patch: https://git.openjdk.org/valhalla/pull/1533.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1533/head:pull/1533

PR: https://git.openjdk.org/valhalla/pull/1533

From liach at openjdk.org  Wed Sep  3 16:00:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 16:00:10 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v2]
In-Reply-To: <a_SHd8uWYV4-FSMl941svGAD_OSy0NKGMoMQpXfF5AQ=.a3e0fad9-f91f-4db2-9f90-eb8626a64346@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
 <Avfg0PVdwWlAtuLdVYsESArMco0tGSu4tyCKvDi7-vs=.2c44ae60-27e7-48e3-a94f-d7a0df1630c1@github.com>
 <rMFD881o9YmHgQjx7-omjytiLata0bTDGTEP9So-O7I=.e5bb0242-96b9-456b-9e4d-36a8a396f0d6@github.com>
 <hPjOrk8B4IevJz4Hvork38iz9tQd23Zz9DUDQ610yEA=.e08a53fc-a52b-4ee0-af73-0c9a4aead579@github.com>
 <YmLp1rlVcCXYEopk2SxeGIPxNw40-yEwICjq1GP-IYA=.42d77061-2d07-49dd-a3e3-0214b351e395@github.com>
 <a_SHd8uWYV4-FSMl941svGAD_OSy0NKGMoMQpXfF5AQ=.a3e0fad9-f91f-4db2-9f90-eb8626a64346@github.com>
Message-ID: <_JosGnke_pq_RKyRZOT_v4b_c6eAyfQ9go_MrzCocwM=.f23bc85b-b97d-457a-bb37-662832c393e0@github.com>

On Wed, 3 Sep 2025 14:15:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Ok, but then shouldn't this add both ACC_IDENTITY and ACC_SUPER and leave it to the API to decide what to emit based on version?
>
> ACC_ ones are bit masks, and distinguishing them is meaningless. AccessFlag.IDENTITY and AccessFlag.SUPER are the actual differing ones. Validation of access flags by version requires somewhat invasive changes to the ClassFile API, so is not included in this patch.
> 
> Reminder, this class building is completely in non-preview. There is no point talking about identity here.

We can track making LMF/MHP value classes in https://bugs.openjdk.org/browse/JDK-8205668

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2319423466

From mcimadamore at openjdk.org  Wed Sep  3 16:06:59 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 Sep 2025 16:06:59 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v3]
In-Reply-To: <xcdgFPLqqQzgTQeqcC5T52rwitgBeriqblFjdRjUgEw=.3dd0e3a6-02a0-4010-87ea-bf08b6a615a6@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
 <xcdgFPLqqQzgTQeqcC5T52rwitgBeriqblFjdRjUgEw=.3dd0e3a6-02a0-4010-87ea-bf08b6a615a6@github.com>
Message-ID: <xMhv8a1Z_H6bA3wm_h3Bj8SZ4EtvrFqsEk9z7u9csRc=.14ed550f-d65d-42b5-973f-e2cd1d84f5a0@github.com>

On Wed, 3 Sep 2025 15:58:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve access flag reflection for preview on/off.
>> 
>> In this process, I noted javac is incorrectly injecting ACC_IDENTITY to 69.0 class' `InnerClasses` attribute and fixed that.
>> 
>> There is still some inconsistency, such as implying ACC_IDENTITY when preview is on for classes. Don't know if we have discussed on this yet.
>> 
>> No new test failures.
>
> Chen Liang 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 11 additional commits since the last revision:
> 
>  - markedPreview handling
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/preview-reflects
>  - Years
>  - Stage
>  - Stage
>  - Trivial
>  - Unit test
>  - Fix identity flag missing for preview inner classes
>  - Stage
>  - Fixes
>  - ... and 1 more: https://git.openjdk.org/valhalla/compare/f4f8e1d8...94ee7a1e

Marked as reviewed by mcimadamore (Committer).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1533#pullrequestreview-3181344618

From mcimadamore at openjdk.org  Wed Sep  3 16:07:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 Sep 2025 16:07:00 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v2]
In-Reply-To: <_JosGnke_pq_RKyRZOT_v4b_c6eAyfQ9go_MrzCocwM=.f23bc85b-b97d-457a-bb37-662832c393e0@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
 <Avfg0PVdwWlAtuLdVYsESArMco0tGSu4tyCKvDi7-vs=.2c44ae60-27e7-48e3-a94f-d7a0df1630c1@github.com>
 <rMFD881o9YmHgQjx7-omjytiLata0bTDGTEP9So-O7I=.e5bb0242-96b9-456b-9e4d-36a8a396f0d6@github.com>
 <hPjOrk8B4IevJz4Hvork38iz9tQd23Zz9DUDQ610yEA=.e08a53fc-a52b-4ee0-af73-0c9a4aead579@github.com>
 <YmLp1rlVcCXYEopk2SxeGIPxNw40-yEwICjq1GP-IYA=.42d77061-2d07-49dd-a3e3-0214b351e395@github.com>
 <a_SHd8uWYV4-FSMl941svGAD_OSy0NKGMoMQpXfF5AQ=.a3e0fad9-f91f-4db2-9f90-eb8626a64346@github.com>
 <_JosGnke_pq_RKyRZOT_v4b_c6eAyfQ9go_MrzCocwM=.f23bc85b-b97d-457a-bb37-662832c393e0@github.com>
Message-ID: <ABnji8FGhn20MiVNGGvOyoomnvMW1J8ByXFu_PMRQeA=.05da3f33-3a99-410e-8d1b-9aa0b951d9a7@github.com>

On Wed, 3 Sep 2025 15:57:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ACC_ ones are bit masks, and distinguishing them is meaningless. AccessFlag.IDENTITY and AccessFlag.SUPER are the actual differing ones. Validation of access flags by version requires somewhat invasive changes to the ClassFile API, so is not included in this patch.
>> 
>> Reminder, this class building is completely in non-preview. There is no point talking about identity here.
>
> We can track making LMF/MHP value classes in https://bugs.openjdk.org/browse/JDK-8205668

> ACC_ ones are bit masks, and distinguishing them is meaningless. AccessFlag.IDENTITY and AccessFlag.SUPER are the actual differing ones. Validation of access flags by version requires somewhat invasive changes to the ClassFile API, so is not included in this patch.
> 
> Reminder, this class building is completely in non-preview. There is no point talking about identity here.

Ok, I got confused, thought the code was using AccessFlag.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2319443201

From mchevalier at openjdk.org  Wed Sep  3 16:09:53 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 3 Sep 2025 16:09:53 GMT
Subject: [lworld] RFR: 8365996: [lworld] Register corruption in GC barrier
 slow paths in scalarized calling convention on AArch64 [v2]
In-Reply-To: <3Iava9CQw9XwGAx4b_6_nWV0bzaXXQSGJeyZoyBN2fM=.2805f743-b731-4e19-8d7c-5666c8a552de@github.com>
References: <3Iava9CQw9XwGAx4b_6_nWV0bzaXXQSGJeyZoyBN2fM=.2805f743-b731-4e19-8d7c-5666c8a552de@github.com>
Message-ID: <CQeMfB3YcWWeM05ZvY3uBxMoSnfmqEgTi2DbaPvWNeA=.1e66867f-1e01-484c-b3fa-bf5cd0c89a61@github.com>

> That fixes a pair of issues. @TobiHartmann fixed one where some native function call would mess up registers. Pushing and popping them solves it.
> 
> The second part is about using `x29`, aka `fp` (frame pointer), as a regular register. Even when not used as the frame pointer register `x29` is nevertheless saved on the stack when setting up the frame, for when it's used as actually the frame pointer. On exit, `x29` and `x30` are restored from there. But with Valhalla, they can be saved twice on the stack! When the non-scalarized entry point of a C2-compiled method is used, one might need a bit more space to scalarize the arguments. This leads to shape such as drawn here.
> 
> https://github.com/openjdk/valhalla/blob/63314117aa0c30f1a5928b56d21d944de063b8c6/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6107-L6126
> 
> Currently, `LR` and `FP` are restored from the copy `#1`. But the comment is not quite exact: `FP #1` and `FP #2` won't be always the same in case it contained an oop to an object that the GC moved between frame creation and frame destruction: the GC knows only one spilled location for each register, and in the case of `x29`, it's `FP #2.`
> 
> It seems difficult to adapt the GC mechanisms to handle more than one location to update for a register. Likewise, we know that `LR #1` is update, but `LR #2` doesn't seem to be: it's fine to update only one, if we know which one is the trustworthy one. Updating only one `FP` won't mess with the cases where we are actually using `x29` as frame pointer since then, the GC won't update any of them as they won't contain oops.
> 
> The process is rather simple: since we need to load `sp_inc` to know how much to pop from the stack, by changing the `ldr` into a `ldp`, we can load `FP #2` into `x29` at the same time. Then, we reduce the stack by `sp_inc`, we read LR#1 (always 1 word under the new top), and we pop the two last words left. This works whether we need some stack extension or not, and makes sure `sp` stays 16-byte aligned when reading `LR #1` (I've learned the hard way, the SIGBUS way, it's a thing...). This requires only one more instruction than the old way. Let's call that a lesser evil.
> 
> Thanks,
> Marc

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  Review

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1540/files
  - new: https://git.openjdk.org/valhalla/pull/1540/files/6bf70658..cf666298

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1540&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1540&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1540.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1540/head:pull/1540

PR: https://git.openjdk.org/valhalla/pull/1540

From mchevalier at openjdk.org  Wed Sep  3 16:09:54 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 3 Sep 2025 16:09:54 GMT
Subject: [lworld] RFR: 8365996: [lworld] Register corruption in GC barrier
 slow paths in scalarized calling convention on AArch64
In-Reply-To: <3Iava9CQw9XwGAx4b_6_nWV0bzaXXQSGJeyZoyBN2fM=.2805f743-b731-4e19-8d7c-5666c8a552de@github.com>
References: <3Iava9CQw9XwGAx4b_6_nWV0bzaXXQSGJeyZoyBN2fM=.2805f743-b731-4e19-8d7c-5666c8a552de@github.com>
Message-ID: <pDIHyqkbliUxaT9Dd6QEBOETrR8-OyjSc-PQpubYiDg=.0845cb7a-f5fa-4566-bc70-353b07550f03@github.com>

On Tue, 2 Sep 2025 15:19:58 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> That fixes a pair of issues. @TobiHartmann fixed one where some native function call would mess up registers. Pushing and popping them solves it.
> 
> The second part is about using `x29`, aka `fp` (frame pointer), as a regular register. Even when not used as the frame pointer register `x29` is nevertheless saved on the stack when setting up the frame, for when it's used as actually the frame pointer. On exit, `x29` and `x30` are restored from there. But with Valhalla, they can be saved twice on the stack! When the non-scalarized entry point of a C2-compiled method is used, one might need a bit more space to scalarize the arguments. This leads to shape such as drawn here.
> 
> https://github.com/openjdk/valhalla/blob/63314117aa0c30f1a5928b56d21d944de063b8c6/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6107-L6126
> 
> Currently, `LR` and `FP` are restored from the copy `#1`. But the comment is not quite exact: `FP #1` and `FP #2` won't be always the same in case it contained an oop to an object that the GC moved between frame creation and frame destruction: the GC knows only one spilled location for each register, and in the case of `x29`, it's `FP #2.`
> 
> It seems difficult to adapt the GC mechanisms to handle more than one location to update for a register. Likewise, we know that `LR #1` is update, but `LR #2` doesn't seem to be: it's fine to update only one, if we know which one is the trustworthy one. Updating only one `FP` won't mess with the cases where we are actually using `x29` as frame pointer since then, the GC won't update any of them as they won't contain oops.
> 
> The process is rather simple: since we need to load `sp_inc` to know how much to pop from the stack, by changing the `ldr` into a `ldp`, we can load `FP #2` into `x29` at the same time. Then, we reduce the stack by `sp_inc`, we read LR#1 (always 1 word under the new top), and we pop the two last words left. This works whether we need some stack extension or not, and makes sure `sp` stays 16-byte aligned when reading `LR #1` (I've learned the hard way, the SIGBUS way, it's a thing...). This requires only one more instruction than the old way. Let's call that a lesser evil.
> 
> Thanks,
> Marc

Thanks for review @TobiHartmann

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1540#issuecomment-3249875234

From duke at openjdk.org  Wed Sep  3 16:09:54 2025
From: duke at openjdk.org (duke)
Date: Wed, 3 Sep 2025 16:09:54 GMT
Subject: [lworld] RFR: 8365996: [lworld] Register corruption in GC barrier
 slow paths in scalarized calling convention on AArch64
In-Reply-To: <3Iava9CQw9XwGAx4b_6_nWV0bzaXXQSGJeyZoyBN2fM=.2805f743-b731-4e19-8d7c-5666c8a552de@github.com>
References: <3Iava9CQw9XwGAx4b_6_nWV0bzaXXQSGJeyZoyBN2fM=.2805f743-b731-4e19-8d7c-5666c8a552de@github.com>
Message-ID: <_wJFpVy7DnzFqFez_r6MpIYgpLr9WFPAXfwpbuS9OMY=.633be5c3-e681-45e8-bcda-629027e050d2@github.com>

On Tue, 2 Sep 2025 15:19:58 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> That fixes a pair of issues. @TobiHartmann fixed one where some native function call would mess up registers. Pushing and popping them solves it.
> 
> The second part is about using `x29`, aka `fp` (frame pointer), as a regular register. Even when not used as the frame pointer register `x29` is nevertheless saved on the stack when setting up the frame, for when it's used as actually the frame pointer. On exit, `x29` and `x30` are restored from there. But with Valhalla, they can be saved twice on the stack! When the non-scalarized entry point of a C2-compiled method is used, one might need a bit more space to scalarize the arguments. This leads to shape such as drawn here.
> 
> https://github.com/openjdk/valhalla/blob/63314117aa0c30f1a5928b56d21d944de063b8c6/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6107-L6126
> 
> Currently, `LR` and `FP` are restored from the copy `#1`. But the comment is not quite exact: `FP #1` and `FP #2` won't be always the same in case it contained an oop to an object that the GC moved between frame creation and frame destruction: the GC knows only one spilled location for each register, and in the case of `x29`, it's `FP #2.`
> 
> It seems difficult to adapt the GC mechanisms to handle more than one location to update for a register. Likewise, we know that `LR #1` is update, but `LR #2` doesn't seem to be: it's fine to update only one, if we know which one is the trustworthy one. Updating only one `FP` won't mess with the cases where we are actually using `x29` as frame pointer since then, the GC won't update any of them as they won't contain oops.
> 
> The process is rather simple: since we need to load `sp_inc` to know how much to pop from the stack, by changing the `ldr` into a `ldp`, we can load `FP #2` into `x29` at the same time. Then, we reduce the stack by `sp_inc`, we read LR#1 (always 1 word under the new top), and we pop the two last words left. This works whether we need some stack extension or not, and makes sure `sp` stays 16-byte aligned when reading `LR #1` (I've learned the hard way, the SIGBUS way, it's a thing...). This requires only one more instruction than the old way. Let's call that a lesser evil.
> 
> Thanks,
> Marc

@marc-chevalier 
Your change (at version cf666298dadcaaf42767a0820141c3e73734c294) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1540#issuecomment-3249876194

From mchevalier at openjdk.org  Wed Sep  3 17:05:00 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 3 Sep 2025 17:05:00 GMT
Subject: [lworld] Integrated: 8365996: [lworld] Register corruption in GC
 barrier slow paths in scalarized calling convention on AArch64
In-Reply-To: <3Iava9CQw9XwGAx4b_6_nWV0bzaXXQSGJeyZoyBN2fM=.2805f743-b731-4e19-8d7c-5666c8a552de@github.com>
References: <3Iava9CQw9XwGAx4b_6_nWV0bzaXXQSGJeyZoyBN2fM=.2805f743-b731-4e19-8d7c-5666c8a552de@github.com>
Message-ID: <xrGQKYEynE6a7xpiUz1MC8BVqe9dxCChwrb3zzf4piI=.b6349158-f870-435b-a9ac-9326dcd3d5fe@github.com>

On Tue, 2 Sep 2025 15:19:58 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> That fixes a pair of issues. @TobiHartmann fixed one where some native function call would mess up registers. Pushing and popping them solves it.
> 
> The second part is about using `x29`, aka `fp` (frame pointer), as a regular register. Even when not used as the frame pointer register `x29` is nevertheless saved on the stack when setting up the frame, for when it's used as actually the frame pointer. On exit, `x29` and `x30` are restored from there. But with Valhalla, they can be saved twice on the stack! When the non-scalarized entry point of a C2-compiled method is used, one might need a bit more space to scalarize the arguments. This leads to shape such as drawn here.
> 
> https://github.com/openjdk/valhalla/blob/63314117aa0c30f1a5928b56d21d944de063b8c6/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6107-L6126
> 
> Currently, `LR` and `FP` are restored from the copy `#1`. But the comment is not quite exact: `FP #1` and `FP #2` won't be always the same in case it contained an oop to an object that the GC moved between frame creation and frame destruction: the GC knows only one spilled location for each register, and in the case of `x29`, it's `FP #2.`
> 
> It seems difficult to adapt the GC mechanisms to handle more than one location to update for a register. Likewise, we know that `LR #1` is update, but `LR #2` doesn't seem to be: it's fine to update only one, if we know which one is the trustworthy one. Updating only one `FP` won't mess with the cases where we are actually using `x29` as frame pointer since then, the GC won't update any of them as they won't contain oops.
> 
> The process is rather simple: since we need to load `sp_inc` to know how much to pop from the stack, by changing the `ldr` into a `ldp`, we can load `FP #2` into `x29` at the same time. Then, we reduce the stack by `sp_inc`, we read LR#1 (always 1 word under the new top), and we pop the two last words left. This works whether we need some stack extension or not, and makes sure `sp` stays 16-byte aligned when reading `LR #1` (I've learned the hard way, the SIGBUS way, it's a thing...). This requires only one more instruction than the old way. Let's call that a lesser evil.
> 
> Thanks,
> Marc

This pull request has now been integrated.

Changeset: 3699b1c1
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3699b1c1423f56211777e14bdcfd9931f7875378
Stats:     271 lines in 14 files changed: 183 ins; 30 del; 58 mod

8365996: [lworld] Register corruption in GC barrier slow paths in scalarized calling convention on AArch64

Reviewed-by: thartmann

-------------

PR: https://git.openjdk.org/valhalla/pull/1540

From coleenp at openjdk.org  Wed Sep  3 18:04:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Sep 2025 18:04:06 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
Message-ID: <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>

On Wed, 3 Sep 2025 14:43:55 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
>> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
>> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
> 
>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>  - Forgot a TODO
>  - Small cleanup
>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>  - Moved get_Klass() back to protected and updated usages
>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>  - Linked TODOs to JDK-8366668
>  - Multidim array fix
>  - Cleanup T_FLAT_ELEMENT related code
>  - Fix for isAssignableFrom + tests
>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6

I reviewed the runtime/oops/interpreter code.  My comments are questions and very minor suggestions, if you want to do them now. This is a very nice cleanup of the existing lworld repo array code.

make/test/BuildMicrobenchmark.gmk line 97:

> 95:         --add-exports java.base/jdk.internal.misc=ALL-UNNAMED \
> 96:         --add-exports java.base/jdk.internal.util=ALL-UNNAMED \
> 97: 				--add-exports java.base/jdk.internal.value=ALL-UNNAMED \

Indentation?  I hope I got the number of spaces right.
Suggestion:

        --add-exports java.base/jdk.internal.value=ALL-UNNAMED \

src/hotspot/share/cds/cdsProtectionDomain.cpp line 300:

> 298:   // It doesn't matter which racing thread wins, as long as only one
> 299:   // result is used by all threads, and all future queries.
> 300:   // ((objArrayOop)array.resolve())->replace_if_null(index, o);

Delete the commented out line.

src/hotspot/share/cds/dynamicArchive.cpp line 371:

> 369:       if (oak->is_refined_objArray_klass()) {
> 370:         oak = ObjArrayKlass::cast(oak->super());
> 371:       }

Why is this needed?

src/hotspot/share/cds/heapShared.cpp line 1299:

> 1297:       Klass* resolved_k = SystemDictionary::resolve_or_null(k->name(), CHECK);
> 1298:       if (resolved_k->is_array_klass()) {
> 1299:         assert(resolved_k == k || ((ObjArrayKlass*)resolved_k)->next_refined_array_klass() == k, "classes used by archived heap must not be replaced by JVMTI ClassFileLoadHook");

Should this be is_objArray_klass() ? and ObjArrayKlass::cast(resolved_k) instead?

src/hotspot/share/classfile/javaClasses.cpp line 1137:

> 1135:   if (vmClasses::Class_klass_loaded()) {
> 1136: 
> 1137:     if (k->is_refArray_klass() || k->is_flatArray_klass()) {

There was a is_refined_objArray_klass() method added that I think can be used here.

src/hotspot/share/classfile/javaClasses.cpp line 1246:

> 1244:   } else {
> 1245:     ObjArrayKlass* objarray_k = (ObjArrayKlass*)as_Klass(m);
> 1246:     // Mirror is either an ObjArrayKlass or one of its refined array klasses

This is a confusing comment.  Refined array klasses don't have their own mirrors.  Maybe:

Suggestion:

    // Mirror should be restored for an ObjArrayKlass or one of its refined array klasses.

src/hotspot/share/classfile/javaClasses.cpp line 1485:

> 1483: void java_lang_Class::release_set_array_klass(oop java_class, Klass* klass) {
> 1484:   assert(klass->is_klass() && klass->is_array_klass(), "should be array klass");
> 1485:   assert(!klass->is_refArray_klass() && !klass->is_flatArray_klass(), "should not be ref or flat array klass");

Suggestion:

  assert(!klass->is_refined_objArray_klass(), "should not be ref or flat array klass");


Hope that's right.

src/hotspot/share/jfr/jni/jfrUpcalls.cpp line 271:

> 269: 
> 270:   // new String[method_count]
> 271:   objArrayOop signature_array = oopFactory::new_objArray(vmClasses::String_klass(), method_count, ArrayKlass::ArrayProperties::DEFAULT, CHECK_NULL);

I wonder if there are enough of these to create a default ref array to overload oopFactory::new_objArray() for DEFAULT.

src/hotspot/share/memory/oopFactory.cpp line 140:

> 138: 
> 139: objArrayHandle oopFactory::new_objArray_handle(Klass* klass, int length, TRAPS) {
> 140:   // TODO FIXME check if this method should take an array properties argument (probably should)

I was thinking the overload to have the default argument be DEFAULT is good.   Maybe we should remove new_objArray_handle in mainline though.  There aren't that many.

src/hotspot/share/memory/universe.hpp line 32:

> 30: #include "oops/array.hpp"
> 31: #include "oops/oopHandle.hpp"
> 32: #include "oops/refArrayKlass.hpp"

Should be included in the .cpp file instead?  We could fix this later though.

src/hotspot/share/oops/arrayKlass.cpp line 174:

> 172:       // Create multi-dim klass object and link them together
> 173:       ObjArrayKlass* ak = nullptr;
> 174:       ak = RefArrayKlass::allocate_objArray_klass(class_loader_data(), dim + 1, this, CHECK_NULL);

Can you make this one line?

src/hotspot/share/oops/constantPool.cpp line 196:

> 194: oop ConstantPool::set_resolved_reference_at(int index, oop new_result) {
> 195:   assert(oopDesc::is_oop_or_null(new_result), "Must be oop");
> 196:   // return resolved_references()->replace_if_null(index, new_result);

Can remove the commented out line.

src/hotspot/share/oops/klass.hpp line 473:

> 471:   static const unsigned int _lh_array_tag_type_value = 0Xfffffffc;
> 472:   static const unsigned int _lh_array_tag_flat_value = 0Xfffffffa;
> 473:   static const unsigned int _lh_array_tag_ref_value  = 0Xfffffff8;

So there is no more layout_helper value for objArray, right?  Only flat and ref values?

src/hotspot/share/oops/objArrayKlass.cpp line 122:

> 120:     bk = ObjArrayKlass::cast(element_klass)->bottom_klass();
> 121:   } else if (element_klass->is_flatArray_klass()) {
> 122:     bk = FlatArrayKlass::cast(element_klass)->element_klass();  // flat array case should be merge with refArray case once reparented

TODO?  Not sure what this means.  FlatArrayKlass inherits from ObjArrayKlass in your patch, so this is done?

src/hotspot/share/oops/refArrayKlass.hpp line 77:

> 75: 
> 76:  public:
> 77:   static RefArrayKlass *cast(Klass *k) {

Should the cast function supposed to have an precond(is_refArray_klass()); before casting?

src/hotspot/share/oops/typeArrayKlass.cpp line 41:

> 39: #include "oops/typeArrayKlass.inline.hpp"
> 40: #include "oops/typeArrayOop.inline.hpp"
> 41: #include "runtime/arguments.hpp"

Is this include needed?

src/hotspot/share/prims/jni.cpp line 2400:

> 2398:    oop v = JNIHandles::resolve(value);
> 2399:    if (a->is_within_bounds(index)) {
> 2400:     // TODO FIXME Temporary hack, to be removed when FlatArrayKlass is made a sub-class of ObjArrayKlass

You've done this.  Can this be cleaned up here?

-------------

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1452#pullrequestreview-3181368314
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319461654
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319478984
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319484976
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319493987
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319498964
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319504994
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319511716
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319522187
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319529334
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319533046
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319536052
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319540618
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319583320
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319592380
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319740381
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319745779
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2319751308

From vromero at openjdk.org  Wed Sep  3 20:21:28 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 3 Sep 2025 20:21:28 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v22]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <0_BfqIw4c0-XQ-cM0YM1bscG6RilVs5rGpJXBuoYsTE=.676b89a2-7e1a-4828-ae0f-a1594bfa60c6@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing last review comments

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/792d98f1..c5b5e0dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=21
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=20-21

  Stats: 73 lines in 8 files changed: 7 ins; 1 del; 65 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

PR: https://git.openjdk.org/valhalla/pull/1523

From liach at openjdk.org  Wed Sep  3 20:39:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 20:39:00 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
Message-ID: <jrFL77sDmYC70Be6AnToTvdGsOfhfHHLEOShOhLXnO8=.1a74c07d-3dbf-4583-97cc-76026ce4f4fa@github.com>

On Wed, 3 Sep 2025 16:21:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Forgot a TODO
>>  - Small cleanup
>>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>>  - Moved get_Klass() back to protected and updated usages
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Linked TODOs to JDK-8366668
>>  - Multidim array fix
>>  - Cleanup T_FLAT_ELEMENT related code
>>  - Fix for isAssignableFrom + tests
>>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6
>
> src/hotspot/share/cds/dynamicArchive.cpp line 371:
> 
>> 369:       if (oak->is_refined_objArray_klass()) {
>> 370:         oak = ObjArrayKlass::cast(oak->super());
>> 371:       }
> 
> Why is this needed?

I think this is probably to convert specialize array klasses to the ObjArrayKlass that map 1-1 to Java's classes.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2320128462

From liach at openjdk.org  Wed Sep  3 21:04:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 21:04:05 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v3]
In-Reply-To: <xcdgFPLqqQzgTQeqcC5T52rwitgBeriqblFjdRjUgEw=.3dd0e3a6-02a0-4010-87ea-bf08b6a615a6@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
 <xcdgFPLqqQzgTQeqcC5T52rwitgBeriqblFjdRjUgEw=.3dd0e3a6-02a0-4010-87ea-bf08b6a615a6@github.com>
Message-ID: <eVJStAlQQNFKxjFWXkf62nEkuom36fGCWzhY7hnBBy0=.1fc19558-e0fe-4e86-9c6f-2d2a1701bc13@github.com>

On Wed, 3 Sep 2025 15:58:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve access flag reflection for preview on/off.
>> 
>> In this process, I noted javac is incorrectly injecting ACC_IDENTITY to 69.0 class' `InnerClasses` attribute and fixed that.
>> 
>> There is still some inconsistency, such as implying ACC_IDENTITY when preview is on for classes. Don't know if we have discussed on this yet.
>> 
>> No new test failures.
>
> Chen Liang 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 11 additional commits since the last revision:
> 
>  - markedPreview handling
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/preview-reflects
>  - Years
>  - Stage
>  - Stage
>  - Trivial
>  - Unit test
>  - Fix identity flag missing for preview inner classes
>  - Stage
>  - Fixes
>  - ... and 1 more: https://git.openjdk.org/valhalla/compare/e4fa5664...94ee7a1e

Thanks for the reviews! This will fix javap and facilitate further development, and there's no new failure, so I will go ahead and integrate.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1533#issuecomment-3250787597

From liach at openjdk.org  Wed Sep  3 21:04:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 21:04:06 GMT
Subject: [lworld] Integrated: 8364095: [lworld] AccessFlags location and
 release need futher work for Valhalla (IDENTITY and SUPER)
In-Reply-To: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
Message-ID: <IWk5nRWLTE1aXVVqDHeqD5vT40jTBm_haTXYYvOnkT8=.2a74bacd-ee27-41e0-be42-c1ad806f3bc0@github.com>

On Mon, 25 Aug 2025 22:00:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> Improve access flag reflection for preview on/off.
> 
> In this process, I noted javac is incorrectly injecting ACC_IDENTITY to 69.0 class' `InnerClasses` attribute and fixed that.
> 
> There is still some inconsistency, such as implying ACC_IDENTITY when preview is on for classes. Don't know if we have discussed on this yet.
> 
> No new test failures.

This pull request has now been integrated.

Changeset: 24cf5a81
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/24cf5a813f13a01440df1fc89d18d03c9b337dbb
Stats:     361 lines in 43 files changed: 187 ins; 81 del; 93 mod

8364095: [lworld] AccessFlags location and release need futher work for Valhalla (IDENTITY and SUPER)

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/valhalla/pull/1533

From liach at openjdk.org  Wed Sep  3 22:32:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 22:32:20 GMT
Subject: [lworld] RFR: LoadableDescriptorsAttrTest2 uses preview API
 Attributes.loadableDescriptors
Message-ID: <w27pQlGDsGeRP04yuOe4gE_gzAyWGm3pUkL0FfncXgs=.2a691eb2-72dc-48d6-b3e3-d84f264fbc68@github.com>

Fixes new javac failures caused by #1542 when Attributes.loadableDescriptors is now preview. (It should probably be a reflective preview API; that will be addressed in #1439)

-------------

Commit messages:
 - LoadableDescriptorsAttrTest2 uses preview API Attributes.loadableDescriptors

Changes: https://git.openjdk.org/valhalla/pull/1543/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1543&range=00
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1543.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1543/head:pull/1543

PR: https://git.openjdk.org/valhalla/pull/1543

From liach at openjdk.org  Wed Sep  3 22:43:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 22:43:54 GMT
Subject: [lworld] RFR: LoadableDescriptorsAttrTest2 uses preview API
 Attributes.loadableDescriptors
In-Reply-To: <w27pQlGDsGeRP04yuOe4gE_gzAyWGm3pUkL0FfncXgs=.2a691eb2-72dc-48d6-b3e3-d84f264fbc68@github.com>
References: <w27pQlGDsGeRP04yuOe4gE_gzAyWGm3pUkL0FfncXgs=.2a691eb2-72dc-48d6-b3e3-d84f264fbc68@github.com>
Message-ID: <gSZLHlyURLHl692GhqoG2ypdQvpw4nBL3l2g0p29VGA=.7c1c1a83-f0ed-47a2-ad87-23f8cfbec78d@github.com>

On Wed, 3 Sep 2025 22:27:37 GMT, Chen Liang <liach at openjdk.org> wrote:

> Fixes new javac failures caused by #1542 when Attributes.loadableDescriptors is now preview. (It should probably be a reflective preview API; that will be addressed in #1439)

Test passes on CI against existing builds and locally, integrating.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1543#issuecomment-3251032004

From liach at openjdk.org  Wed Sep  3 22:43:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 22:43:54 GMT
Subject: [lworld] Integrated: LoadableDescriptorsAttrTest2 uses preview API
 Attributes.loadableDescriptors
In-Reply-To: <w27pQlGDsGeRP04yuOe4gE_gzAyWGm3pUkL0FfncXgs=.2a691eb2-72dc-48d6-b3e3-d84f264fbc68@github.com>
References: <w27pQlGDsGeRP04yuOe4gE_gzAyWGm3pUkL0FfncXgs=.2a691eb2-72dc-48d6-b3e3-d84f264fbc68@github.com>
Message-ID: <6fD9_rXyOzkUFa_TvzoZGlF9CzaRvNP-iTKPF04eBsg=.d73bd116-d844-44ac-a407-4953d6b9601b@github.com>

On Wed, 3 Sep 2025 22:27:37 GMT, Chen Liang <liach at openjdk.org> wrote:

> Fixes new javac failures caused by #1542 when Attributes.loadableDescriptors is now preview. (It should probably be a reflective preview API; that will be addressed in #1439)

This pull request has now been integrated.

Changeset: 12078415
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1207841579be65b56c3e18d8d13453dd507d6a74
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

LoadableDescriptorsAttrTest2 uses preview API Attributes.loadableDescriptors

-------------

PR: https://git.openjdk.org/valhalla/pull/1543

From coleenp at openjdk.org  Thu Sep  4 02:01:07 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 02:01:07 GMT
Subject: [lworld] RFR: 8366440: [lworld] Two tests broken with JDK-8364483
Message-ID: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>

I added some logging and fixed the tests so that one doesn't rely on a migrated class in java.base to throw a VerifyError (will make a parallel fix to this test in mainline).  The other, I changed the logging message that it is looking for. More tests in this area will be added.
Tested locally.

-------------

Commit messages:
 - 8366440: [lworld] Two tests broken with JDK-8364483

Changes: https://git.openjdk.org/valhalla/pull/1544/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1544&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366440
  Stats: 16 lines in 3 files changed: 9 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/1544.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1544/head:pull/1544

PR: https://git.openjdk.org/valhalla/pull/1544

From dsimms at openjdk.org  Thu Sep  4 05:44:55 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 4 Sep 2025 05:44:55 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <EJSRNnXpE1CxnOT0WUg5IEVl5o3yeR_fubY_GcTiTbc=.f219c41b-c6e7-46d4-beda-97a6c1825476@github.com>

Merge jdk-26+1
Merge branch 'lworld' into lworld_merge_jdk_26_1

-------------

Commit messages:
 - Merge branch 'lworld' into lworld_merge_jdk_26_1
 - Version flick
 - Merge jdk
 - 8357396: Refactor nmethod::make_not_entrant to use Enum instead of "const char*"
 - 8355746: Start of release updates for JDK 26

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1545&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1545&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/1545/files
  Stats: 2046 lines in 99 files changed: 1824 ins; 23 del; 199 mod
  Patch: https://git.openjdk.org/valhalla/pull/1545.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1545/head:pull/1545

PR: https://git.openjdk.org/valhalla/pull/1545

From thartmann at openjdk.org  Thu Sep  4 06:31:58 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 4 Sep 2025 06:31:58 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
Message-ID: <8zAyCPFWvcWlKCerMUQctCSLNXkqI-bu9ZFflh3_NTQ=.25719484-8394-48c9-a45e-96166098acbd@github.com>

On Wed, 3 Sep 2025 14:43:55 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
>> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
>> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
> 
>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>  - Forgot a TODO
>  - Small cleanup
>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>  - Moved get_Klass() back to protected and updated usages
>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>  - Linked TODOs to JDK-8366668
>  - Multidim array fix
>  - Cleanup T_FLAT_ELEMENT related code
>  - Fix for isAssignableFrom + tests
>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6

Marked as reviewed by thartmann (Committer).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1452#pullrequestreview-3183646545

From dsimms at openjdk.org  Thu Sep  4 08:29:01 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 4 Sep 2025 08:29:01 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
Message-ID: <h5mJcB6BJBUZzFtQlkUy6a-Wsv3iluIGhJ-y4DrFk9Q=.4b70050c-d5d7-430e-b8b2-7b020f15938f@github.com>

On Wed, 3 Sep 2025 14:43:55 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
>> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
>> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
> 
>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>  - Forgot a TODO
>  - Small cleanup
>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>  - Moved get_Klass() back to protected and updated usages
>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>  - Linked TODOs to JDK-8366668
>  - Multidim array fix
>  - Cleanup T_FLAT_ELEMENT related code
>  - Fix for isAssignableFrom + tests
>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6

Coleen beat me to most of the formatting issues and comment of deriving flatArray

Overall, this looking awesome.

One issue of concern: refArray and flatArray are distinct from any mainline code. But any cases of objArray changes in mainline, when merged may actually need changing to refArray. Especially if there is additional mainline code that does not overlap, i.e. there will no textual conflict and it will compile.

I took another pass at the PR looking assertions when need refined types. I think you have it covered. That does mean more assertions during merge testing, but they should obvious.

I'm not even going to complain about how textual conflict this PR will produce in future mainline merging, those are trivial to deal with.

If we were interested in catching merge problems earlier, we code rename objArray...but that feels extreme.

src/hotspot/share/ci/ciObjectFactory.cpp line 150:

> 148:   for (int i = T_BOOLEAN; i <= T_CONFLICT; i++) {
> 149:     BasicType t = (BasicType)i;
> 150:     if (type2name(t) != nullptr && t != T_FLAT_ELEMENT && !is_reference_type(t) &&

I can't remember know if we said we would attempt to remove `T_FLAT_ELEMENT` later ? If we still need it, as a "basic type" can "T_FLAT" cover both elements and fields ?

src/hotspot/share/oops/objArrayKlass.cpp line 159:

> 157: ArrayDescription ObjArrayKlass::array_layout_selection(Klass* element, ArrayProperties properties) {
> 158:   // TODO FIXME: the layout selection should take the array size in consideration
> 159:   // to avoid creation of arrays too big to be handled by the VM

There is a related bug (though it is old): [8233189](https://bugs.openjdk.org/browse/JDK-8233189), perhaps we need a new bug noted here (and relate the old one)

-------------

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1452#pullrequestreview-3183603436
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2320951128
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2321035022

From thartmann at openjdk.org  Thu Sep  4 12:26:02 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 4 Sep 2025 12:26:02 GMT
Subject: [lworld] RFR: 8366879: [lworld] C2's lock elimination fails after
 JDK-8335256
Message-ID: <2Vbi6uxNKuhubGCKyYs3tbgeUUc4327-h0ta70O09QE=.fa5c1eae-2720-45c4-9f44-9d1c04bf0351@github.com>

Since [JDK-8335256](https://bugs.openjdk.org/browse/JDK-8335256) / https://github.com/openjdk/valhalla/pull/1447 we attempt lock elimination already before Escape Analysis.  However, allocations of locked objects might block lock elimination if their escape state isn't determined yet and we only got one chance at eliminating the lock:
https://github.com/openjdk/valhalla/blob/1207841579be65b56c3e18d8d13453dd507d6a74/src/hotspot/share/opto/macro.cpp#L3001-L3004

I changed the code such that we only attempt lock elimination after EA and added a corresponding regression test.

Thanks,
Tobias

-------------

Commit messages:
 - 8366879: [lworld] C2's lock elimination fails after JDK-8335256

Changes: https://git.openjdk.org/valhalla/pull/1546/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1546&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366879
  Stats: 107 lines in 5 files changed: 82 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/valhalla/pull/1546.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1546/head:pull/1546

PR: https://git.openjdk.org/valhalla/pull/1546

From phubner at openjdk.org  Thu Sep  4 13:03:08 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 4 Sep 2025 13:03:08 GMT
Subject: [lworld] RFR: 8366440: [lworld] Two tests broken with JDK-8364483
In-Reply-To: <yUCTnuqnLBujvrzsHQ0HRkvqPC8Ba4swnv2T3mzJtEM=.e3a3a5ee-fad3-4e56-a1c4-b9a35b664a50@github.com>
References: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>
 <yUCTnuqnLBujvrzsHQ0HRkvqPC8Ba4swnv2T3mzJtEM=.e3a3a5ee-fad3-4e56-a1c4-b9a35b664a50@github.com>
Message-ID: <muFxeVZUjcddT5MxdUEaHVGlaS50Mx7OT3LAiB4I6Uc=.039905cf-e834-4211-8f26-f937bfd52252@github.com>

On Thu, 4 Sep 2025 12:41:00 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> I added some logging and fixed the tests so that one doesn't rely on a migrated class in java.base to throw a VerifyError (will make a parallel fix to this test in mainline).  The other, I changed the logging message that it is looking for. More tests in this area will be added.
>> Tested locally.
>
> src/hotspot/share/classfile/classFileParser.cpp line 6234:
> 
>> 6232:           // Just poking the system dictionary to see if the class has already be loaded. Looking for migrated classes
>> 6233:           // used when --enable-preview when jdk isn't compiled with --enable-preview so doesn't include LoadableDescriptors.
>> 6234:           // This is temporary.
> 
> I was talking to Simms earlier and we think we should have a classfile check (i.e. ensure we are running whatever major + preview we are on at the moment), and then disable the whole loadabledescriptor functionality if the version doesn't match up. When we do this, we should probably consider that here as well. What do you think?

Just to clarify, this PR is fine as-is but do you agree that we should include this part of code if that classfile checking manifests itself?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1544#discussion_r2322055509

From phubner at openjdk.org  Thu Sep  4 13:03:08 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 4 Sep 2025 13:03:08 GMT
Subject: [lworld] RFR: 8366440: [lworld] Two tests broken with JDK-8364483
In-Reply-To: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>
References: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>
Message-ID: <yUCTnuqnLBujvrzsHQ0HRkvqPC8Ba4swnv2T3mzJtEM=.e3a3a5ee-fad3-4e56-a1c4-b9a35b664a50@github.com>

On Thu, 4 Sep 2025 01:57:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I added some logging and fixed the tests so that one doesn't rely on a migrated class in java.base to throw a VerifyError (will make a parallel fix to this test in mainline).  The other, I changed the logging message that it is looking for. More tests in this area will be added.
> Tested locally.

src/hotspot/share/classfile/classFileParser.cpp line 6234:

> 6232:           // Just poking the system dictionary to see if the class has already be loaded. Looking for migrated classes
> 6233:           // used when --enable-preview when jdk isn't compiled with --enable-preview so doesn't include LoadableDescriptors.
> 6234:           // This is temporary.

I was talking to Simms earlier and we think we should have a classfile check (i.e. ensure we are running whatever major + preview we are on at the moment), and then disable the whole loadabledescriptor functionality if the version doesn't match up. When we do this, we should probably consider that here as well. What do you think?

src/hotspot/share/classfile/classFileParser.cpp line 6240:

> 6238:             _inline_layout_info_array->adr_at(fieldinfo.index())->set_klass(InlineKlass::cast(klass));
> 6239:             log_info(class, preload)("Preloading of class %s during loading of class %s "
> 6240:                                      "(cause: field type not in LoadableDescriptors attribute) succeeded",

"field type not in LoadableDescriptors" yet "succeeded" seems contradictory. Correct me if I'm wrong, but I think successful preloading implies that this class was (potentially transitively) in a LoadableDescriptors attribute of some class being loaded.

I'm not sure I follow why we suddenly introduce a log message here which is never checked in the tests. Could you elaborate?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1544#discussion_r2321981517
PR Review Comment: https://git.openjdk.org/valhalla/pull/1544#discussion_r2322025202

From coleenp at openjdk.org  Thu Sep  4 13:52:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 13:52:53 GMT
Subject: [lworld] RFR: 8366440: [lworld] Two tests broken with JDK-8364483
In-Reply-To: <yUCTnuqnLBujvrzsHQ0HRkvqPC8Ba4swnv2T3mzJtEM=.e3a3a5ee-fad3-4e56-a1c4-b9a35b664a50@github.com>
References: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>
 <yUCTnuqnLBujvrzsHQ0HRkvqPC8Ba4swnv2T3mzJtEM=.e3a3a5ee-fad3-4e56-a1c4-b9a35b664a50@github.com>
Message-ID: <gX4WurQooOII_64urQDa7aLe0orRJ8MFgc6cL3ryLIA=.5cf9542e-68c0-4b56-9564-64bc10a53401@github.com>

On Thu, 4 Sep 2025 12:53:06 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> I added some logging and fixed the tests so that one doesn't rely on a migrated class in java.base to throw a VerifyError (will make a parallel fix to this test in mainline).  The other, I changed the logging message that it is looking for. More tests in this area will be added.
>> Tested locally.
>
> src/hotspot/share/classfile/classFileParser.cpp line 6240:
> 
>> 6238:             _inline_layout_info_array->adr_at(fieldinfo.index())->set_klass(InlineKlass::cast(klass));
>> 6239:             log_info(class, preload)("Preloading of class %s during loading of class %s "
>> 6240:                                      "(cause: field type not in LoadableDescriptors attribute) succeeded",
> 
> "field type not in LoadableDescriptors" yet "succeeded" seems contradictory. Correct me if I'm wrong, but I think successful preloading implies that this class was (potentially transitively) in a LoadableDescriptors attribute of some class being loaded.
> 
> I'm not sure I follow why we suddenly introduce a log message here which is never checked in the tests. Could you elaborate?

I couldn't figure out how to write this test (even though we do reach this code), or rather I didn't want to delay this change while figuring out how to write a test because it was breaking the CI.

Even though this doesn't technically preload the class, I wanted the log message to look like the other preloading messages, so kept "Preloading".  And I wanted to keep "field type".   How about:

Preloading of class %s during loading of class $s (cause: field type where LoadableDescriptors attribute is missing) succeeded

Although that's really long.  Suggestions welcome!

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1544#discussion_r2322246353

From coleenp at openjdk.org  Thu Sep  4 13:52:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 13:52:52 GMT
Subject: [lworld] RFR: 8366440: [lworld] Two tests broken with JDK-8364483
In-Reply-To: <muFxeVZUjcddT5MxdUEaHVGlaS50Mx7OT3LAiB4I6Uc=.039905cf-e834-4211-8f26-f937bfd52252@github.com>
References: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>
 <yUCTnuqnLBujvrzsHQ0HRkvqPC8Ba4swnv2T3mzJtEM=.e3a3a5ee-fad3-4e56-a1c4-b9a35b664a50@github.com>
 <muFxeVZUjcddT5MxdUEaHVGlaS50Mx7OT3LAiB4I6Uc=.039905cf-e834-4211-8f26-f937bfd52252@github.com>
Message-ID: <UFhoN7xH7aVw4JNK8kgsYE0cK-H3x9YmhHOm5QJEbJ4=.9ddfe34c-df1a-4305-8a25-9694eba703f6@github.com>

On Thu, 4 Sep 2025 13:00:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 6234:
>> 
>>> 6232:           // Just poking the system dictionary to see if the class has already be loaded. Looking for migrated classes
>>> 6233:           // used when --enable-preview when jdk isn't compiled with --enable-preview so doesn't include LoadableDescriptors.
>>> 6234:           // This is temporary.
>> 
>> I was talking to Simms earlier and we think we should have a classfile check (i.e. ensure we are running whatever major + preview we are on at the moment), and then disable the whole loadabledescriptor functionality if the version doesn't match up. When we do this, we should probably consider that here as well. What do you think?
>
> Just to clarify, this PR is fine as-is but do you agree that we should include this part of code if that classfile checking manifests itself?

It's under EnablePreview, like a lot of the code.  I'm hoping EnablePreview might check for classfile version?  Although it's a good question, maybe we do this speculative lookup only if classfile version is not preview.

This code unconditionally loads a bunch of classes in the bootclass loader, but doesn't add them to other class loaders as initiated classes unless EnablePreview is on.  I was thinking about how to load them only for EnablePreview as a separate change.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1544#discussion_r2322228555

From matsaave at openjdk.org  Thu Sep  4 15:47:04 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 4 Sep 2025 15:47:04 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <jrFL77sDmYC70Be6AnToTvdGsOfhfHHLEOShOhLXnO8=.1a74c07d-3dbf-4583-97cc-76026ce4f4fa@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
 <jrFL77sDmYC70Be6AnToTvdGsOfhfHHLEOShOhLXnO8=.1a74c07d-3dbf-4583-97cc-76026ce4f4fa@github.com>
Message-ID: <6VkaD4C5VtGGusg8cLmBLw6RjP3-k9o-_BjggRfRAwQ=.04555010-b77c-4745-81a4-a2b510c9d903@github.com>

On Wed, 3 Sep 2025 20:36:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/hotspot/share/cds/dynamicArchive.cpp line 371:
>> 
>>> 369:       if (oak->is_refined_objArray_klass()) {
>>> 370:         oak = ObjArrayKlass::cast(oak->super());
>>> 371:       }
>> 
>> Why is this needed?
>
> I think this is probably to convert specialize array klasses to the ObjArrayKlass that map 1-1 to Java's classes.

We don't want to archive refined array klasses in the dynamic archive, that's why this code ensures we only hold onto the ObjArrayKlass. Without this, the static archive can hold some dimensions of the array klass while the dynamic archive can have others.

The method `setup_array_klasses` tries to link together these different dimensions but we run into some trouble because we have the ObjArrayKlass and the different flavors of refined array klasses. It's better to just avoid putting array klasses in the dynamic archive altogether.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2322609691

From coleenp at openjdk.org  Thu Sep  4 16:00:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 16:00:33 GMT
Subject: [lworld] RFR: 8366267: [lworld] Injected ACC_IDENTITY escapes to
 instrumentation of older classes
Message-ID: <y2m-tQbfWErsEkLCnZW7zJ_Q6yl2ep2Y5H113DdgW70=.6a53688e-c500-426f-8254-27e9581b4752@github.com>

This is a simple fix to mask off the ACC_IDENTITY bit from the inner class attribute that was added in during classfile parsing for non-preview non-value classfiles.
Tested with tier1 and java/lang/instrument manually.

-------------

Commit messages:
 - 8366267: [lworld] Injected ACC_IDENTITY escapes to instrumentation of older classes

Changes: https://git.openjdk.org/valhalla/pull/1547/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1547&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366267
  Stats: 13 lines in 4 files changed: 11 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1547.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1547/head:pull/1547

PR: https://git.openjdk.org/valhalla/pull/1547

From fparain at openjdk.org  Thu Sep  4 16:57:24 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 4 Sep 2025 16:57:24 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <h5mJcB6BJBUZzFtQlkUy6a-Wsv3iluIGhJ-y4DrFk9Q=.4b70050c-d5d7-430e-b8b2-7b020f15938f@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <h5mJcB6BJBUZzFtQlkUy6a-Wsv3iluIGhJ-y4DrFk9Q=.4b70050c-d5d7-430e-b8b2-7b020f15938f@github.com>
Message-ID: <YtOwN0xN0_MdGdqVOMZeVAHNNYexroAcneT7eM2jDWs=.243efd13-ab24-4d1e-8658-2b7bdae19805@github.com>

On Thu, 4 Sep 2025 06:18:57 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Forgot a TODO
>>  - Small cleanup
>>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>>  - Moved get_Klass() back to protected and updated usages
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Linked TODOs to JDK-8366668
>>  - Multidim array fix
>>  - Cleanup T_FLAT_ELEMENT related code
>>  - Fix for isAssignableFrom + tests
>>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6
>
> src/hotspot/share/ci/ciObjectFactory.cpp line 150:
> 
>> 148:   for (int i = T_BOOLEAN; i <= T_CONFLICT; i++) {
>> 149:     BasicType t = (BasicType)i;
>> 150:     if (type2name(t) != nullptr && t != T_FLAT_ELEMENT && !is_reference_type(t) &&
> 
> I can't remember know if we said we would attempt to remove `T_FLAT_ELEMENT` later ? If we still need it, as a "basic type" can "T_FLAT" cover both elements and fields ?

The last use case of a BasicType specific to value types is in the layout_helper of flat arrays. We don't need a specific values for fields. For arrays, it prevents overloading the T_OBJECT semantic. This is a very limited use case, we could explore later if removing it brings us some benefits.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2322795288

From fparain at openjdk.org  Thu Sep  4 16:57:24 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 4 Sep 2025 16:57:24 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
Message-ID: <ip2h8nD-SPHwJOx9QHp4xDNzBpBYrqNzuoU7a3rQIEU=.711ae0af-2347-419d-af7b-8aba25c2e275@github.com>

On Wed, 3 Sep 2025 16:56:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Forgot a TODO
>>  - Small cleanup
>>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>>  - Moved get_Klass() back to protected and updated usages
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Linked TODOs to JDK-8366668
>>  - Multidim array fix
>>  - Cleanup T_FLAT_ELEMENT related code
>>  - Fix for isAssignableFrom + tests
>>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6
>
> src/hotspot/share/oops/klass.hpp line 473:
> 
>> 471:   static const unsigned int _lh_array_tag_type_value = 0Xfffffffc;
>> 472:   static const unsigned int _lh_array_tag_flat_value = 0Xfffffffa;
>> 473:   static const unsigned int _lh_array_tag_ref_value  = 0Xfffffff8;
> 
> So there is no more layout_helper value for objArray, right?  Only flat and ref values?

Correct. The layout_helper provides information about the layout of an allocated Java array. ObjArrayKlass instances cannot contain details about a particular layout.

> src/hotspot/share/prims/jni.cpp line 2400:
> 
>> 2398:    oop v = JNIHandles::resolve(value);
>> 2399:    if (a->is_within_bounds(index)) {
>> 2400:     // TODO FIXME Temporary hack, to be removed when FlatArrayKlass is made a sub-class of ObjArrayKlass
> 
> You've done this.  Can this be cleaned up here?

Fixed

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2322782948
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2322785360

From fparain at openjdk.org  Thu Sep  4 17:44:00 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 4 Sep 2025 17:44:00 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
Message-ID: <7KQs45BRihDkof_shDQQvkJ-7zfsG5FpvVzWKfCsnmg=.61b37b06-05c2-439d-9f16-5f5adfef1890@github.com>

On Wed, 3 Sep 2025 16:11:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Forgot a TODO
>>  - Small cleanup
>>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>>  - Moved get_Klass() back to protected and updated usages
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Linked TODOs to JDK-8366668
>>  - Multidim array fix
>>  - Cleanup T_FLAT_ELEMENT related code
>>  - Fix for isAssignableFrom + tests
>>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6
>
> make/test/BuildMicrobenchmark.gmk line 97:
> 
>> 95:         --add-exports java.base/jdk.internal.misc=ALL-UNNAMED \
>> 96:         --add-exports java.base/jdk.internal.util=ALL-UNNAMED \
>> 97: 				--add-exports java.base/jdk.internal.value=ALL-UNNAMED \
> 
> Indentation?  I hope I got the number of spaces right.
> Suggestion:
> 
>         --add-exports java.base/jdk.internal.value=ALL-UNNAMED \

Fixed.

> src/hotspot/share/classfile/javaClasses.cpp line 1137:
> 
>> 1135:   if (vmClasses::Class_klass_loaded()) {
>> 1136: 
>> 1137:     if (k->is_refArray_klass() || k->is_flatArray_klass()) {
> 
> There was a is_refined_objArray_klass() method added that I think can be used here.

Fixed.

> src/hotspot/share/classfile/javaClasses.cpp line 1246:
> 
>> 1244:   } else {
>> 1245:     ObjArrayKlass* objarray_k = (ObjArrayKlass*)as_Klass(m);
>> 1246:     // Mirror is either an ObjArrayKlass or one of its refined array klasses
> 
> This is a confusing comment.  Refined array klasses don't have their own mirrors.  Maybe:
> 
> Suggestion:
> 
>     // Mirror should be restored for an ObjArrayKlass or one of its refined array klasses.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2322936201
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2322944149
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2322950221

From fparain at openjdk.org  Thu Sep  4 17:44:01 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 4 Sep 2025 17:44:01 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <h5mJcB6BJBUZzFtQlkUy6a-Wsv3iluIGhJ-y4DrFk9Q=.4b70050c-d5d7-430e-b8b2-7b020f15938f@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <h5mJcB6BJBUZzFtQlkUy6a-Wsv3iluIGhJ-y4DrFk9Q=.4b70050c-d5d7-430e-b8b2-7b020f15938f@github.com>
Message-ID: <jqOmpPS8-rWTczaMAsnobz4obb1y9rJN-wFYobozYu4=.aad42a53-efcd-4bb1-b79d-1d0479437b83@github.com>

On Thu, 4 Sep 2025 06:54:46 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Forgot a TODO
>>  - Small cleanup
>>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>>  - Moved get_Klass() back to protected and updated usages
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Linked TODOs to JDK-8366668
>>  - Multidim array fix
>>  - Cleanup T_FLAT_ELEMENT related code
>>  - Fix for isAssignableFrom + tests
>>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6
>
> src/hotspot/share/oops/objArrayKlass.cpp line 159:
> 
>> 157: ArrayDescription ObjArrayKlass::array_layout_selection(Klass* element, ArrayProperties properties) {
>> 158:   // TODO FIXME: the layout selection should take the array size in consideration
>> 159:   // to avoid creation of arrays too big to be handled by the VM
> 
> There is a related bug (though it is old): [8233189](https://bugs.openjdk.org/browse/JDK-8233189), perhaps we need a new bug noted here (and relate the old one)

Comment and CR have been updated.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2322930580

From liach at openjdk.org  Thu Sep  4 17:46:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Sep 2025 17:46:50 GMT
Subject: [lworld] RFR: 8366267: [lworld] Injected ACC_IDENTITY escapes to
 instrumentation of older classes
In-Reply-To: <y2m-tQbfWErsEkLCnZW7zJ_Q6yl2ep2Y5H113DdgW70=.6a53688e-c500-426f-8254-27e9581b4752@github.com>
References: <y2m-tQbfWErsEkLCnZW7zJ_Q6yl2ep2Y5H113DdgW70=.6a53688e-c500-426f-8254-27e9581b4752@github.com>
Message-ID: <DzfzZPkQVG8qW9X00kKQ0_8MK7xNpTQ27iOnDT1_Ha0=.4859d047-92ba-49ce-b5ea-ac03f7dbb3b7@github.com>

On Thu, 4 Sep 2025 15:55:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a simple fix to mask off the ACC_IDENTITY bit from the inner class attribute that was added in during classfile parsing for non-preview non-value classfiles.
> Tested with tier1 and java/lang/instrument manually.

Thank you for this fix!

-------------

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1547#pullrequestreview-3186415608

From liach at openjdk.org  Thu Sep  4 18:13:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Sep 2025 18:13:32 GMT
Subject: [lworld] RFR: 8366913: [lworld] Add ACC_STRICT_INIT to ClassFile
Message-ID: <JGfNefZwAvkuhh6KFyPP97nGRE1keWsJ9pEk8iaY2Z4=.ea4ae88e-0c57-47bb-810d-9789f69352e9@github.com>

@arraying discovered that java.lang.classfile.ClassFile is missing a constant for ACC_STRICT_INIT. This was due to previous iterations of strict fields proposal calling this flag simply ACC_STRICT like strictfp. The usages of ACC_STRICT and Modifier.STRICT has been reviewed, and ones that actually refer to STRICT_INIT (which is also not a source modifier) are migrated.

-------------

Commit messages:
 - Replace ACC_STRICT with ACC_STRICT_INIT

Changes: https://git.openjdk.org/valhalla/pull/1548/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1548&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366913
  Stats: 20 lines in 6 files changed: 3 ins; 4 del; 13 mod
  Patch: https://git.openjdk.org/valhalla/pull/1548.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1548/head:pull/1548

PR: https://git.openjdk.org/valhalla/pull/1548

From coleenp at openjdk.org  Thu Sep  4 18:16:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 18:16:51 GMT
Subject: [lworld] RFR: 8366267: [lworld] Injected ACC_IDENTITY escapes to
 instrumentation of older classes
In-Reply-To: <y2m-tQbfWErsEkLCnZW7zJ_Q6yl2ep2Y5H113DdgW70=.6a53688e-c500-426f-8254-27e9581b4752@github.com>
References: <y2m-tQbfWErsEkLCnZW7zJ_Q6yl2ep2Y5H113DdgW70=.6a53688e-c500-426f-8254-27e9581b4752@github.com>
Message-ID: <Th8elyE-WSbMKZqIe0lBYMjcw1xK3JWmgLVYR4I99Jk=.81c2feeb-f8b1-4eb6-8a84-71a7d4f874c5@github.com>

On Thu, 4 Sep 2025 15:55:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a simple fix to mask off the ACC_IDENTITY bit from the inner class attribute that was added in during classfile parsing for non-preview non-value classfiles.
> Tested with tier1 and java/lang/instrument manually.

Thanks for reporting it and suggested fix, Chen.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1547#issuecomment-3254951918

From coleenp at openjdk.org  Thu Sep  4 18:16:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 18:16:51 GMT
Subject: [lworld] Integrated: 8366267: [lworld] Injected ACC_IDENTITY escapes
 to instrumentation of older classes
In-Reply-To: <y2m-tQbfWErsEkLCnZW7zJ_Q6yl2ep2Y5H113DdgW70=.6a53688e-c500-426f-8254-27e9581b4752@github.com>
References: <y2m-tQbfWErsEkLCnZW7zJ_Q6yl2ep2Y5H113DdgW70=.6a53688e-c500-426f-8254-27e9581b4752@github.com>
Message-ID: <DPYYtF2PyRCI17_8JuIXudvi8vDEDg8FIOSBvnllqiE=.9bf4cebf-1111-4ee7-8869-095c047f5f38@github.com>

On Thu, 4 Sep 2025 15:55:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a simple fix to mask off the ACC_IDENTITY bit from the inner class attribute that was added in during classfile parsing for non-preview non-value classfiles.
> Tested with tier1 and java/lang/instrument manually.

This pull request has now been integrated.

Changeset: 59ffa2df
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/59ffa2dfa856f7c7bb91c2f4e7cbdabf38d8ade2
Stats:     13 lines in 4 files changed: 11 ins; 1 del; 1 mod

8366267: [lworld] Injected ACC_IDENTITY escapes to instrumentation of older classes

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/valhalla/pull/1547

From fparain at openjdk.org  Thu Sep  4 19:08:54 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 4 Sep 2025 19:08:54 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
Message-ID: <n5YIiJTF-TW4gfU-mzmwAueTrSocpXHJUH8DiWNETBA=.222b73de-e734-46e4-a618-b97370d1be87@github.com>

On Wed, 3 Sep 2025 16:37:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Forgot a TODO
>>  - Small cleanup
>>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>>  - Moved get_Klass() back to protected and updated usages
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Linked TODOs to JDK-8366668
>>  - Multidim array fix
>>  - Cleanup T_FLAT_ELEMENT related code
>>  - Fix for isAssignableFrom + tests
>>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6
>
> src/hotspot/share/jfr/jni/jfrUpcalls.cpp line 271:
> 
>> 269: 
>> 270:   // new String[method_count]
>> 271:   objArrayOop signature_array = oopFactory::new_objArray(vmClasses::String_klass(), method_count, ArrayKlass::ArrayProperties::DEFAULT, CHECK_NULL);
> 
> I wonder if there are enough of these to create a default ref array to overload oopFactory::new_objArray() for DEFAULT.

Done.

> src/hotspot/share/memory/oopFactory.cpp line 140:
> 
>> 138: 
>> 139: objArrayHandle oopFactory::new_objArray_handle(Klass* klass, int length, TRAPS) {
>> 140:   // TODO FIXME check if this method should take an array properties argument (probably should)
> 
> I was thinking the overload to have the default argument be DEFAULT is good.   Maybe we should remove new_objArray_handle in mainline though.  There aren't that many.

If new_objArray_handle() should be removed, please do it in mainline first.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2323205682
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2323209901

From fparain at openjdk.org  Thu Sep  4 19:24:00 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 4 Sep 2025 19:24:00 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
Message-ID: <84b3oltk52UeSA1do8LhJTT2At3Qqkh5nvwFe-QkTJk=.139dc2b9-f85f-460e-8067-5bc9f8b21b5d@github.com>

On Wed, 3 Sep 2025 16:43:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Forgot a TODO
>>  - Small cleanup
>>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>>  - Moved get_Klass() back to protected and updated usages
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Linked TODOs to JDK-8366668
>>  - Multidim array fix
>>  - Cleanup T_FLAT_ELEMENT related code
>>  - Fix for isAssignableFrom + tests
>>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6
>
> src/hotspot/share/memory/universe.hpp line 32:
> 
>> 30: #include "oops/array.hpp"
>> 31: #include "oops/oopHandle.hpp"
>> 32: #include "oops/refArrayKlass.hpp"
> 
> Should be included in the .cpp file instead?  We could fix this later though.

Fixed.

> src/hotspot/share/oops/constantPool.cpp line 196:
> 
>> 194: oop ConstantPool::set_resolved_reference_at(int index, oop new_result) {
>> 195:   assert(oopDesc::is_oop_or_null(new_result), "Must be oop");
>> 196:   // return resolved_references()->replace_if_null(index, new_result);
> 
> Can remove the commented out line.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2323247203
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2323249118

From fparain at openjdk.org  Thu Sep  4 19:40:55 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 4 Sep 2025 19:40:55 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
Message-ID: <k2lGE-uZAx_UKVB_2qKkUnobYWMVA5ob2ObqidC3hv0=.22e59847-e129-4531-9ec5-699f96ba97ba@github.com>

On Wed, 3 Sep 2025 17:48:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Forgot a TODO
>>  - Small cleanup
>>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>>  - Moved get_Klass() back to protected and updated usages
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Linked TODOs to JDK-8366668
>>  - Multidim array fix
>>  - Cleanup T_FLAT_ELEMENT related code
>>  - Fix for isAssignableFrom + tests
>>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6
>
> src/hotspot/share/oops/refArrayKlass.hpp line 77:
> 
>> 75: 
>> 76:  public:
>> 77:   static RefArrayKlass *cast(Klass *k) {
> 
> Should the cast function supposed to have an precond(is_refArray_klass()); before casting?

Yes, it should. Fixed.

> src/hotspot/share/oops/typeArrayKlass.cpp line 41:
> 
>> 39: #include "oops/typeArrayKlass.inline.hpp"
>> 40: #include "oops/typeArrayOop.inline.hpp"
>> 41: #include "runtime/arguments.hpp"
> 
> Is this include needed?

Yes, there's a call to Arguments::enable_preview()

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2323299109
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2323303214

From fparain at openjdk.org  Thu Sep  4 19:44:58 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 4 Sep 2025 19:44:58 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
Message-ID: <nee11ruTOsfont0gD8x-RbUI4erhtwhRIizrYa9l0o4=.dacc1a5d-e077-4c84-a3d0-0491bdc0ddbf@github.com>

On Wed, 3 Sep 2025 16:33:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Forgot a TODO
>>  - Small cleanup
>>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>>  - Moved get_Klass() back to protected and updated usages
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Linked TODOs to JDK-8366668
>>  - Multidim array fix
>>  - Cleanup T_FLAT_ELEMENT related code
>>  - Fix for isAssignableFrom + tests
>>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6
>
> src/hotspot/share/classfile/javaClasses.cpp line 1485:
> 
>> 1483: void java_lang_Class::release_set_array_klass(oop java_class, Klass* klass) {
>> 1484:   assert(klass->is_klass() && klass->is_array_klass(), "should be array klass");
>> 1485:   assert(!klass->is_refArray_klass() && !klass->is_flatArray_klass(), "should not be ref or flat array klass");
> 
> Suggestion:
> 
>   assert(!klass->is_refined_objArray_klass(), "should not be ref or flat array klass");
> 
> 
> Hope that's right.

Fixed.

> src/hotspot/share/oops/arrayKlass.cpp line 174:
> 
>> 172:       // Create multi-dim klass object and link them together
>> 173:       ObjArrayKlass* ak = nullptr;
>> 174:       ak = RefArrayKlass::allocate_objArray_klass(class_loader_data(), dim + 1, this, CHECK_NULL);
> 
> Can you make this one line?

Sure. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2323312709
PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2323316189

From liach at openjdk.org  Thu Sep  4 19:57:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Sep 2025 19:57:55 GMT
Subject: [lworld] RFR: 8366913: [lworld] Add ACC_STRICT_INIT to ClassFile
In-Reply-To: <JGfNefZwAvkuhh6KFyPP97nGRE1keWsJ9pEk8iaY2Z4=.ea4ae88e-0c57-47bb-810d-9789f69352e9@github.com>
References: <JGfNefZwAvkuhh6KFyPP97nGRE1keWsJ9pEk8iaY2Z4=.ea4ae88e-0c57-47bb-810d-9789f69352e9@github.com>
Message-ID: <IqbYXNNG3ANC9Zs2GREOCuSG-GXowHGT4xGcrEnjU8w=.a157719b-4401-42bc-b919-ea58de1e9479@github.com>

On Thu, 4 Sep 2025 18:08:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> @arraying discovered that java.lang.classfile.ClassFile is missing a constant for ACC_STRICT_INIT. This was due to previous iterations of strict fields proposal calling this flag simply ACC_STRICT like strictfp. The usages of ACC_STRICT and Modifier.STRICT has been reviewed, and ones that actually refer to STRICT_INIT (which is also not a source modifier) are migrated.

No new failure in tier 1-3, integrating.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1548#issuecomment-3255381179

From liach at openjdk.org  Thu Sep  4 19:57:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Sep 2025 19:57:55 GMT
Subject: [lworld] Integrated: 8366913: [lworld] Add ACC_STRICT_INIT to
 ClassFile
In-Reply-To: <JGfNefZwAvkuhh6KFyPP97nGRE1keWsJ9pEk8iaY2Z4=.ea4ae88e-0c57-47bb-810d-9789f69352e9@github.com>
References: <JGfNefZwAvkuhh6KFyPP97nGRE1keWsJ9pEk8iaY2Z4=.ea4ae88e-0c57-47bb-810d-9789f69352e9@github.com>
Message-ID: <MkcPUhLo64dSzCcoGksItDSOnE0qIznKgaunZbGocv4=.d5f51d1d-1c9a-48b4-bf07-36a1d9a5804c@github.com>

On Thu, 4 Sep 2025 18:08:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> @arraying discovered that java.lang.classfile.ClassFile is missing a constant for ACC_STRICT_INIT. This was due to previous iterations of strict fields proposal calling this flag simply ACC_STRICT like strictfp. The usages of ACC_STRICT and Modifier.STRICT has been reviewed, and ones that actually refer to STRICT_INIT (which is also not a source modifier) are migrated.

This pull request has now been integrated.

Changeset: 2fddd34c
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2fddd34c37cfe7c4d4372217fa4b58bf199aa71d
Stats:     20 lines in 6 files changed: 3 ins; 4 del; 13 mod

8366913: [lworld] Add ACC_STRICT_INIT to ClassFile

-------------

PR: https://git.openjdk.org/valhalla/pull/1548

From coleenp at openjdk.org  Thu Sep  4 20:08:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Sep 2025 20:08:54 GMT
Subject: [lworld] RFR: 8366440: [lworld] Two tests broken with JDK-8364483
In-Reply-To: <gX4WurQooOII_64urQDa7aLe0orRJ8MFgc6cL3ryLIA=.5cf9542e-68c0-4b56-9564-64bc10a53401@github.com>
References: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>
 <yUCTnuqnLBujvrzsHQ0HRkvqPC8Ba4swnv2T3mzJtEM=.e3a3a5ee-fad3-4e56-a1c4-b9a35b664a50@github.com>
 <gX4WurQooOII_64urQDa7aLe0orRJ8MFgc6cL3ryLIA=.5cf9542e-68c0-4b56-9564-64bc10a53401@github.com>
Message-ID: <isNcd5tIsoP6rZxvzjoSiTK6xUIxyinOjjtax7MriP0=.7f251eed-5e02-4ba7-95da-e3bb6aa9975f@github.com>

On Thu, 4 Sep 2025 13:49:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 6240:
>> 
>>> 6238:             _inline_layout_info_array->adr_at(fieldinfo.index())->set_klass(InlineKlass::cast(klass));
>>> 6239:             log_info(class, preload)("Preloading of class %s during loading of class %s "
>>> 6240:                                      "(cause: field type not in LoadableDescriptors attribute) succeeded",
>> 
>> "field type not in LoadableDescriptors" yet "succeeded" seems contradictory. Correct me if I'm wrong, but I think successful preloading implies that this class was (potentially transitively) in a LoadableDescriptors attribute of some class being loaded.
>> 
>> I'm not sure I follow why we suddenly introduce a log message here which is never checked in the tests. Could you elaborate?
>
> I couldn't figure out how to write this test (even though we do reach this code), or rather I didn't want to delay this change while figuring out how to write a test because it was breaking the CI.
> 
> Even though this doesn't technically preload the class, I wanted the log message to look like the other preloading messages, so kept "Preloading".  And I wanted to keep "field type".   How about:
> 
> Preloading of class %s during loading of class $s (cause: field type where LoadableDescriptors attribute is missing) succeeded
> 
> Although that's really long.  Suggestions welcome!

I reworded the logging message so hopefully it makes more sense.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1544#discussion_r2323390814

From vromero at openjdk.org  Thu Sep  4 20:17:08 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 Sep 2025 20:17:08 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v23]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <_hRlAdN2kKWzQceZkovLEdl5Rfqr13TvsLudl3aep-w=.222b0f66-de44-4fd2-a7ae-8a2fa74f8aba@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Merge branch 'lworld' into JDK-8359370-v2
 - addressing last review comments
 - minor refactoring
 - addressing review comments
 - some documentation
 - moving isEarlyReference to Attr
 - additional changes, more tests
 - addressing review comments
 - removing unnecessary imports
 - addressing review comments
 - ... and 25 more: https://git.openjdk.org/valhalla/compare/59ffa2df...bf2310b7

-------------

Changes: https://git.openjdk.org/valhalla/pull/1523/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=22
  Stats: 600 lines in 27 files changed: 320 ins; 158 del; 122 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

PR: https://git.openjdk.org/valhalla/pull/1523

From acobbs at openjdk.org  Thu Sep  4 20:26:00 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 4 Sep 2025 20:26:00 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
 <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>
 <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
Message-ID: <TyENbeAd5-LifEHS7rYK5Qm3F6Oj69gtfpDcp6VvGZE=.c6bfc2eb-63f9-4a4c-957c-00ee1efa07f1@github.com>

On Fri, 29 Aug 2025 10:15:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I think I like the trade-off, we could try to infer if a constructor invocation corresponds to the class we are interested in. Like for example analyzing the symbol associated to a `super` or `this` invocation. But for erroneous invocations the symbol could be null. So what to do when we find a null symbol? We would have no clues I think.
>
> let's wait until we address the other comments first. What I had in mind (but can be addressed in a separate PR) was maybe have a general visitor for prologue -- e.g. an helper visitor class that only visits things inside the prologue. Then you can extend that helper visitor here, to do what you need to do.

Fyi, at one point I determined that you can't assume `super()` calls are always top-level statements because I found that some synthetic calls to `super()` are added inside `{ }` blocks. See also `TreeInfo.ConstructorCallFinder` (which you might be able to modify and/or reuse somehow).

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2323449443

From rriggs at openjdk.org  Thu Sep  4 20:42:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 4 Sep 2025 20:42:56 GMT
Subject: [lworld] RFR: 8366200: Modify jimage package flags to support
 preview mode [v4]
In-Reply-To: <HRikrRZRJ16Ayek8UCWjcx-F1USu0auwEMUcPs7iL7o=.38effd02-fc08-4b4a-b6f5-2161679583c5@github.com>
References: <T9agi8MWtFWN7-c5BwNDea33o6TQkdLft0v83eOv_qM=.9c75b546-ac8b-4a09-9cd4-68ee68e87a72@github.com>
 <HRikrRZRJ16Ayek8UCWjcx-F1USu0auwEMUcPs7iL7o=.38effd02-fc08-4b4a-b6f5-2161679583c5@github.com>
Message-ID: <3a9fhh6WnVnPmYKU-87bUtT99qv5p8kMNZNq7TTBzaY=.04a97014-94e0-4f12-90e8-15d0d61c1e7d@github.com>

On Fri, 29 Aug 2025 15:27:21 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Reuses the previously unused package flags in the /packages/xxx entries of jimage files to support preview mode.
>> 
>> With these flags it becomes simple to determine things like:
>> 1. Which modules are children of /packages/xxx
>>   - This can differ between preview and non-preview mode.
>> 
>> 2. Which modules/packages have any preview content
>>   - Useful in preview mode for faster rejection testing to avoid double-lookup on all resources.
>> 
>> If there are no preview resources built into the jimage file, then the difference between output is that the "isEmpty" flag (old version) has become a "hasContent" flag (but since these flags are not read by anyone right now, this should not be an issue).
>> 
>> Note that bumping the minor version number was done to ensure that, during testing, no undiscovered code is reading the new file with old logic (this would work since there's no structural change, but the semantics are different).
>> 
>> This does mean that on systems where a 'jimage' binary is installed for the JDK (e.g. /usr/bin/jimage), that tool will stop working on files generate by this code, but the version of that binary in the built JDK will work. The alternative is to just not bump the version number (if nobody is reading the flags now, it shouldn't matter what's in them).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More tests and test tweaking for clarity

Looks pretty thorough.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 154:

> 152:      * entry to determine if that module contains resources for the package.
> 153:      *
> 154:      * <p>If all entries are marked with {@code IS_PREVIEW_ONLY}

Is there more to this comment?

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 197:

> 195:             @Override
> 196:             public String toString() {
> 197:                 return String.format("%s [has_normal_content=%s, has_preview_content=%s, is_preview_only=%s]",

A bit verbose for output, very few will see or use.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 230:

> 228:             // It is possible (but not worth checking for) that these flags are the same
> 229:             // as the existing reference (e.g. updating with an empty preview package).
> 230:             unsortedReferences.put(moduleName, new PackageReference(moduleName, flags));

is the any cleaner using `compute` or `computeIfPresent`, etc.

test/jdk/tools/jlink/whitebox/jdk.jlink/jdk/tools/jlink/internal/ImageResourcesTreeTest.java line 61:

> 59:                 "/java.base/java/util/resource.txt",
> 60:                 "/java.logging/java/util/logging/LoggingClass.class",
> 61:                 "/java.logging/java/util/logging/OtherLoggingClass.class");

Would these work well using @ParameterizedTest? And other tests below that use the same lists.
Or should these lists be shared.

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1537#pullrequestreview-3186990961
PR Review Comment: https://git.openjdk.org/valhalla/pull/1537#discussion_r2323366727
PR Review Comment: https://git.openjdk.org/valhalla/pull/1537#discussion_r2323376999
PR Review Comment: https://git.openjdk.org/valhalla/pull/1537#discussion_r2323389797
PR Review Comment: https://git.openjdk.org/valhalla/pull/1537#discussion_r2323483229

From fparain at openjdk.org  Thu Sep  4 21:51:00 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 4 Sep 2025 21:51:00 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v5]
In-Reply-To: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
Message-ID: <9-Vl0eoEdGosLUSBbT3sDJb4XwH_GdYy3kvGc76wqwY=.a7fef3af-2f21-448d-89ea-6783a9ad3a59@github.com>

> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Address comments from reviewers

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1452/files
  - new: https://git.openjdk.org/valhalla/pull/1452/files/527a17b6..c3327d60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=04
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=03-04

  Stats: 92 lines in 32 files changed: 7 ins; 7 del; 78 mod
  Patch: https://git.openjdk.org/valhalla/pull/1452.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1452/head:pull/1452

PR: https://git.openjdk.org/valhalla/pull/1452

From thartmann at openjdk.org  Fri Sep  5 06:10:36 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 5 Sep 2025 06:10:36 GMT
Subject: [lworld] Integrated: 8366879: [lworld] C2's lock elimination fails
 after JDK-8335256
In-Reply-To: <2Vbi6uxNKuhubGCKyYs3tbgeUUc4327-h0ta70O09QE=.fa5c1eae-2720-45c4-9f44-9d1c04bf0351@github.com>
References: <2Vbi6uxNKuhubGCKyYs3tbgeUUc4327-h0ta70O09QE=.fa5c1eae-2720-45c4-9f44-9d1c04bf0351@github.com>
Message-ID: <4PFK5ooHdii20nMRim9M1a66GT0ljPesyTKHlbm82b0=.9236515f-e847-41c1-86ca-9abbef52bf19@github.com>

On Thu, 4 Sep 2025 12:19:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Since [JDK-8335256](https://bugs.openjdk.org/browse/JDK-8335256) / https://github.com/openjdk/valhalla/pull/1447 we attempt lock elimination already before Escape Analysis.  However, allocations of locked objects might block lock elimination if their escape state isn't determined yet and we only got one chance at eliminating the lock:
> https://github.com/openjdk/valhalla/blob/1207841579be65b56c3e18d8d13453dd507d6a74/src/hotspot/share/opto/macro.cpp#L3001-L3004
> 
> I changed the code such that we only attempt lock elimination after EA and added a corresponding regression test.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 858be301
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/858be30119bd5bc37a69d16042523f53bea71a36
Stats:     107 lines in 5 files changed: 82 ins; 9 del; 16 mod

8366879: [lworld] C2's lock elimination fails after JDK-8335256

-------------

PR: https://git.openjdk.org/valhalla/pull/1546

From phubner at openjdk.org  Fri Sep  5 08:29:29 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 5 Sep 2025 08:29:29 GMT
Subject: [lworld] RFR: 8366440: [lworld] Two tests broken with JDK-8364483
In-Reply-To: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>
References: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>
Message-ID: <DwVd2A_ZMblpha44oqNaig3OfYs06Gh1KV-_1-DY4oI=.6f722004-a611-448e-a638-49f80444cf1c@github.com>

On Thu, 4 Sep 2025 01:57:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I added some logging and fixed the tests so that one doesn't rely on a migrated class in java.base to throw a VerifyError (will make a parallel fix to this test in mainline).  The other, I changed the logging message that it is looking for. More tests in this area will be added.
> Tested locally.

I don't see the new logging message but since we discussed this extensively in the meeting I'm very happy to approve nonetheless. Let me know if you would like me to look at anything else, otherwise thank you for fixing these tests!!

-------------

Marked as reviewed by phubner (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1544#pullrequestreview-3188464842

From coleenp at openjdk.org  Fri Sep  5 11:36:25 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 5 Sep 2025 11:36:25 GMT
Subject: [lworld] RFR: 8366440: [lworld] Two tests broken with JDK-8364483
In-Reply-To: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>
References: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>
Message-ID: <1YMM0R_ngyKrUQV7lQkJn8iHHzxkCN8xPCdUgj9kxfg=.7860312e-86d6-493b-802b-6f50d2df2dfe@github.com>

On Thu, 4 Sep 2025 01:57:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I added some logging and fixed the tests so that one doesn't rely on a migrated class in java.base to throw a VerifyError (will make a parallel fix to this test in mainline).  The other, I changed the logging message that it is looking for. More tests in this area will be added.
> Tested locally.

Thanks Paul.  The path with the log message needs a test, but I want to integrate this to fix the noise in the testing.  Thank you for reviewing and your comments.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1544#issuecomment-3258030113

From coleenp at openjdk.org  Fri Sep  5 11:36:25 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 5 Sep 2025 11:36:25 GMT
Subject: [lworld] Integrated: 8366440: [lworld] Two tests broken with
 JDK-8364483
In-Reply-To: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>
References: <_H59YWwD8nDLwEl4uxvCM5BDn4Uu_PdJBeRsx0FTdAA=.9057240f-f641-4563-9a09-79de974a2862@github.com>
Message-ID: <P_T0ok9XWslEynlk5EhNGsLu4EN-ZUs7bdeQTdKANCQ=.df7cedba-b7e5-41a4-aa8e-ddde81894346@github.com>

On Thu, 4 Sep 2025 01:57:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I added some logging and fixed the tests so that one doesn't rely on a migrated class in java.base to throw a VerifyError (will make a parallel fix to this test in mainline).  The other, I changed the logging message that it is looking for. More tests in this area will be added.
> Tested locally.

This pull request has now been integrated.

Changeset: 4b93af71
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4b93af7180db7929aaffb7897cb9d4c80dbb2e51
Stats:     16 lines in 3 files changed: 9 ins; 1 del; 6 mod

8366440: [lworld] Two tests broken with JDK-8364483

Reviewed-by: phubner

-------------

PR: https://git.openjdk.org/valhalla/pull/1544

From mchevalier at openjdk.org  Fri Sep  5 11:51:55 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 5 Sep 2025 11:51:55 GMT
Subject: [lworld] RFR: 8365978: [lworld] C2: assert(vk->maybe_flat_in_array())
 when using compareAndSetFlatValue with -XX:-UseArrayFlattening
Message-ID: <qXUmkLLQw7c2dcRJBs3galgigoG_kfDV7wGhLxmb0xs=.028dbaff-6d74-4637-83d0-c4774c6a2275@github.com>

`Unsafe::compareAndSetFlatValue` calls `Unsafe::compareAndSetFlatValueAsBytes` which then calls `Unsafe::putFlatValue` on a flat array created by `Unsafe::newSpecialArray`.

https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L2870-L2875

`putFlatValue` can be intrinsified in

https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2727

that calls `cast_to_flat_array`

https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2831

which fails the assert

https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/graphKit.cpp#L1875-L1876

because of

https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/oops/inlineKlass.cpp#L287-L290

Of course, if array flattening is disabled, one can't have flat arrays. And indeed, `Unsafe::newSpecialArray` will raise if called. So at runtime, the call to `Unsafe::compareAndSetFlatValue` should simply raise. But when compiled the assert is hit, crashing the VM, because it cannot tell that the code is dead, but can check that if it's not the array is not flat. That doesn't seem reasonable to me. I propose to insert a trap instead. Even in the case where this code wouldn't be dead (like if `Unsafe::newSpecialArray` is just undefined behavior instead of throwing), crashing the compiler doesn't seem like a good option.

The situation is actually more surprising than it seems: using `Unsafe::compareAndSetFlatValue` on a flat field with `-XX:-UseArrayFlattening` sounds reasonable, but doesn't actually work since the implementation will (attempt to) create flat arrays under the hood. It is not clear to me whether it's actually desirable, as `Unsafe::compareAndSetFlatValue` introduce some coupling of field and array flattening, but on the other hand, it's an unsafe API, so it's not that crazy to require more constrains to use.

Thanks,
Marc

-------------

Commit messages:
 - Add a trap and a test

Changes: https://git.openjdk.org/valhalla/pull/1549/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1549&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365978
  Stats: 98 lines in 2 files changed: 88 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/valhalla/pull/1549.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1549/head:pull/1549

PR: https://git.openjdk.org/valhalla/pull/1549

From fparain at openjdk.org  Fri Sep  5 11:57:30 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 5 Sep 2025 11:57:30 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
Message-ID: <JY9YqoOJ_jzxDbjvzAeiX10urPReAhIyDgcTlMv1PFI=.c91c091e-f6a5-4a0e-9c13-fbf2920f7e0e@github.com>

On Wed, 3 Sep 2025 16:58:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Forgot a TODO
>>  - Small cleanup
>>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>>  - Moved get_Klass() back to protected and updated usages
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Linked TODOs to JDK-8366668
>>  - Multidim array fix
>>  - Cleanup T_FLAT_ELEMENT related code
>>  - Fix for isAssignableFrom + tests
>>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6
>
> src/hotspot/share/oops/objArrayKlass.cpp line 122:
> 
>> 120:     bk = ObjArrayKlass::cast(element_klass)->bottom_klass();
>> 121:   } else if (element_klass->is_flatArray_klass()) {
>> 122:     bk = FlatArrayKlass::cast(element_klass)->element_klass();  // flat array case should be merge with refArray case once reparented
> 
> TODO?  Not sure what this means.  FlatArrayKlass inherits from ObjArrayKlass in your patch, so this is done?

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2324894787

From fparain at openjdk.org  Fri Sep  5 12:05:07 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 5 Sep 2025 12:05:07 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v6]
In-Reply-To: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
Message-ID: <Zq4WUtLOAtcAHsmT-7JTmkduEtI0p4nM-LlM5ue2td8=.6fd8e566-3fb9-407e-9a83-2e573485d484@github.com>

> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Remove commented code

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1452/files
  - new: https://git.openjdk.org/valhalla/pull/1452/files/c3327d60..b27def57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=05
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1452.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1452/head:pull/1452

PR: https://git.openjdk.org/valhalla/pull/1452

From fparain at openjdk.org  Fri Sep  5 12:05:10 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 5 Sep 2025 12:05:10 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
Message-ID: <HsIeYrr-U5UmReDDj-0eTih7Nf6EoqKHK2RbguZ7XuI=.7b4bbe3c-5957-45a5-9fe8-9af67b267337@github.com>

On Wed, 3 Sep 2025 16:18:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Forgot a TODO
>>  - Small cleanup
>>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>>  - Moved get_Klass() back to protected and updated usages
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Linked TODOs to JDK-8366668
>>  - Multidim array fix
>>  - Cleanup T_FLAT_ELEMENT related code
>>  - Fix for isAssignableFrom + tests
>>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6
>
> src/hotspot/share/cds/cdsProtectionDomain.cpp line 300:
> 
>> 298:   // It doesn't matter which racing thread wins, as long as only one
>> 299:   // result is used by all threads, and all future queries.
>> 300:   // ((objArrayOop)array.resolve())->replace_if_null(index, o);
> 
> Delete the commented out line.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2324906736

From fparain at openjdk.org  Fri Sep  5 13:57:27 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 5 Sep 2025 13:57:27 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v6]
In-Reply-To: <EVzrKvDQ8WrK5qfeUd0604itTnFpM1TcjpNHdKPpyR8=.adc1eb71-fdb5-4737-bf34-2b4535ff34c8@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <EVzrKvDQ8WrK5qfeUd0604itTnFpM1TcjpNHdKPpyR8=.adc1eb71-fdb5-4737-bf34-2b4535ff34c8@github.com>
Message-ID: <pKOW7p0FRCr3lOxTOd9fNetwEUjcR4arm4G46HTC3qY=.a1190968-7b7e-48ae-92b6-c0e4494a4cfa@github.com>

On Fri, 9 May 2025 22:01:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove commented code
>
> src/hotspot/share/oops/refArrayKlass.hpp line 33:
> 
>> 31: class ClassLoaderData;
>> 32: 
>> 33: // RefjArrayKlass is the klass for arrays of references
> 
> you have an extra j in this.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2325172790

From fparain at openjdk.org  Fri Sep  5 15:02:45 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 5 Sep 2025 15:02:45 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v7]
In-Reply-To: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
Message-ID: <k4qmY5F0YfrdXSFC-0i1aWOU4_jGJPWq7deqFzqqysE=.78e0ec0d-3547-436e-a459-16c9eeeba950@github.com>

> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Fix style

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1452/files
  - new: https://git.openjdk.org/valhalla/pull/1452/files/b27def57..ca75bab8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=06
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=05-06

  Stats: 40 lines in 2 files changed: 0 ins; 3 del; 37 mod
  Patch: https://git.openjdk.org/valhalla/pull/1452.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1452/head:pull/1452

PR: https://git.openjdk.org/valhalla/pull/1452

From matsaave at openjdk.org  Fri Sep  5 15:02:47 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 5 Sep 2025 15:02:47 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
Message-ID: <jLG8ezW8GXaz2EabGoiISX5L9VrYxa-EHJ7FjBcUKd4=.59e0ac68-ccd3-430e-ac5a-00d20c568c17@github.com>

On Wed, 3 Sep 2025 16:25:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
>> 
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Forgot a TODO
>>  - Small cleanup
>>  - Merge remote-tracking branch 'upstream/lworld' into array_klasses
>>  - Moved get_Klass() back to protected and updated usages
>>  - Merge branch 'array_klasses' of github.com:fparain/valhalla into array_klasses
>>  - Linked TODOs to JDK-8366668
>>  - Multidim array fix
>>  - Cleanup T_FLAT_ELEMENT related code
>>  - Fix for isAssignableFrom + tests
>>  - ... and 57 more: https://git.openjdk.org/valhalla/compare/22e9d5f5...527a17b6
>
> src/hotspot/share/cds/heapShared.cpp line 1299:
> 
>> 1297:       Klass* resolved_k = SystemDictionary::resolve_or_null(k->name(), CHECK);
>> 1298:       if (resolved_k->is_array_klass()) {
>> 1299:         assert(resolved_k == k || ((ObjArrayKlass*)resolved_k)->next_refined_array_klass() == k, "classes used by archived heap must not be replaced by JVMTI ClassFileLoadHook");
> 
> Should this be is_objArray_klass() ? and ObjArrayKlass::cast(resolved_k) instead?

Yes that would be more correct. However, the check for `next_refined_array_klass()` may not be valid once CDS heap dumping is enabled as there could be more entries into the linked list. The fix here would be to check for
`assert(resolved_k == k || resolved_k == k->super(), "...")`

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2325335831

From fparain at openjdk.org  Fri Sep  5 15:02:48 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 5 Sep 2025 15:02:48 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v7]
In-Reply-To: <EVzrKvDQ8WrK5qfeUd0604itTnFpM1TcjpNHdKPpyR8=.adc1eb71-fdb5-4737-bf34-2b4535ff34c8@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <EVzrKvDQ8WrK5qfeUd0604itTnFpM1TcjpNHdKPpyR8=.adc1eb71-fdb5-4737-bf34-2b4535ff34c8@github.com>
Message-ID: <ht5gfzbJnq8ShNLqzIK02Mc1MnEixSYMMYKfGnBD-X8=.8fa26c36-6cb9-4287-9ba9-d937ff7505b3@github.com>

On Fri, 9 May 2025 22:02:16 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix style
>
> src/hotspot/share/oops/refArrayKlass.hpp line 45:
> 
>> 43: 	 // Constructor
>> 44: 	 RefArrayKlass(int n, Klass *element_klass, Symbol *name, bool null_free);
>> 45: 	 static RefArrayKlass *allocate(ClassLoaderData *loader_data, int n, Klass *k, Symbol *name, bool null_free, TRAPS);
> 
> The stars go with the types, ie ClassLoaderData* loader_data.

Fixed (in all refArrayKlass.hpp and refArrayKlass.cpp).

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2325332373

From rriggs at openjdk.org  Fri Sep  5 15:23:32 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 5 Sep 2025 15:23:32 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v7]
In-Reply-To: <k4qmY5F0YfrdXSFC-0i1aWOU4_jGJPWq7deqFzqqysE=.78e0ec0d-3547-436e-a459-16c9eeeba950@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <k4qmY5F0YfrdXSFC-0i1aWOU4_jGJPWq7deqFzqqysE=.78e0ec0d-3547-436e-a459-16c9eeeba950@github.com>
Message-ID: <ZkU-PvYKSPtVRFCwgttKjnk2tFPv86TvRiBjGwSI_QY=.0e629b4b-c93d-4350-a4ee-ac8f70f1212b@github.com>

On Fri, 5 Sep 2025 15:02:45 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
>> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
>> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix style

test/hotspot/jtreg/ProblemList.txt line 284:

> 282: 
> 283: runtime/valhalla/inlinetypes/ValuePreloadTest.java 8366440 generic-all
> 284: runtime/verifier/CFLH/TestVerify.java 8366440 generic-all

These two have been fixed by [8366440](https://bugs.openjdk.org/browse/JDK-8366440)

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2325387396

From matsaave at openjdk.org  Fri Sep  5 16:31:29 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 5 Sep 2025 16:31:29 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v3]
In-Reply-To: <IwMeGxEiG9wYBUNaybVKcvzXIFw8XxMM_bBi0_DKEAc=.b9fe4996-2cdf-481e-9e7c-d267018d47ac@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <dXhbp5M6ANCXeaJdgfILwCJP8MSKS7KHtY7znO-oJl8=.7f240e61-a3b7-4595-b57e-0aa7d79a3863@github.com>
 <IwMeGxEiG9wYBUNaybVKcvzXIFw8XxMM_bBi0_DKEAc=.b9fe4996-2cdf-481e-9e7c-d267018d47ac@github.com>
Message-ID: <3ZFfRKV-g0x5Z_I_QxqlVi4iiucbyV0vqleA-05YsXg=.410586c3-9dd9-4732-91f8-44b9f5248b35@github.com>

On Wed, 3 Sep 2025 02:37:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Forgot a TODO
>
> src/hotspot/share/cds/cdsEnumKlass.cpp line 92:
> 
>> 90:   }
>> 91:   oop oop_field = mirror->obj_field(fd.offset());
>> 92:   Klass* oop_field_klass = oop_field->is_objArray() ? oop_field->klass()->super() : oop_field->klass();
> 
> Hmm, what does this do? I assume `is_objArray` tests if something can be converted to Java `Object[]`. In this case, CDS should check if the component type of the array instead of the array supepr class, I think? The original code did not call `super()`.

There should be no oops that are ObjArrayKlass, so in reality this is checking for refined array klasses. The reason it goes up to the super is that the super will be an ObjArrayKlass, specifically the same one that will be returned by `ik->array_klass_or_null()`. 

I think you're right in saying that we can look at the element klass (or bottom klass?) and do the comparison as well.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2325533312

From mcimadamore at openjdk.org  Fri Sep  5 17:48:36 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 Sep 2025 17:48:36 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v23]
In-Reply-To: <_hRlAdN2kKWzQceZkovLEdl5Rfqr13TvsLudl3aep-w=.222b0f66-de44-4fd2-a7ae-8a2fa74f8aba@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <_hRlAdN2kKWzQceZkovLEdl5Rfqr13TvsLudl3aep-w=.222b0f66-de44-4fd2-a7ae-8a2fa74f8aba@github.com>
Message-ID: <6VwpiDKi0gmSOcWe4BMkcjpAVfuX3_yO4Lc_E9vjOK4=.2d62131d-7b4d-4c44-b04b-cbc7334af8b0@github.com>

On Thu, 4 Sep 2025 20:17:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
> 
>  - Merge branch 'lworld' into JDK-8359370-v2
>  - addressing last review comments
>  - minor refactoring
>  - addressing review comments
>  - some documentation
>  - moving isEarlyReference to Attr
>  - additional changes, more tests
>  - addressing review comments
>  - removing unnecessary imports
>  - addressing review comments
>  - ... and 25 more: https://git.openjdk.org/valhalla/compare/59ffa2df...bf2310b7

Very nice code consolidation. The new code is more centralized, and there's no more division of labor between Attr and Resolve. I think we should eventually consider something like this for mainline. Kudos!

-------------

Marked as reviewed by mcimadamore (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1523#pullrequestreview-3190297742

From vromero at openjdk.org  Fri Sep  5 17:58:30 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 Sep 2025 17:58:30 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v23]
In-Reply-To: <6VwpiDKi0gmSOcWe4BMkcjpAVfuX3_yO4Lc_E9vjOK4=.2d62131d-7b4d-4c44-b04b-cbc7334af8b0@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <_hRlAdN2kKWzQceZkovLEdl5Rfqr13TvsLudl3aep-w=.222b0f66-de44-4fd2-a7ae-8a2fa74f8aba@github.com>
 <6VwpiDKi0gmSOcWe4BMkcjpAVfuX3_yO4Lc_E9vjOK4=.2d62131d-7b4d-4c44-b04b-cbc7334af8b0@github.com>
Message-ID: <Er-v4phds8R1fjg2Hg4EvDk0jXlzbbcBnZ_A0CSOf14=.9bf456c5-6754-4ce0-8238-fc53b4c8f774@github.com>

On Fri, 5 Sep 2025 17:45:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Very nice code consolidation. The new code is more centralized, and there's no more division of labor between Attr and Resolve. I think we should eventually consider something like this for mainline. Kudos!

yes I agree that we should consider something like this for mainline. Thanks for all the guidance / comments here and offline!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1523#issuecomment-3259279053

From coleenp at openjdk.org  Fri Sep  5 18:41:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 5 Sep 2025 18:41:35 GMT
Subject: [lworld] RFR: 8294051: [lworld] runtime/AccModule/ConstModule.java
 fails with incorrect error message
Message-ID: <dwlACEOgpPbSZUEwRxZw5gL_RsjRuEwwHuLAN3uFpU8=.743b0dc8-73c9-499e-82ea-a8c958a0e3c6@github.com>

This change moves code back to match mainline that checks access flags and checks for invalid JVM_CONSTANTS_Module/Package before reading the class name out of the constant pool.
Tested with tier1-3.

-------------

Commit messages:
 - remove commented out problem list test.
 - 8294051: [lworld] runtime/AccModule/ConstModule.java fails with incorrect error message

Changes: https://git.openjdk.org/valhalla/pull/1550/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1550&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294051
  Stats: 50 lines in 3 files changed: 17 ins; 22 del; 11 mod
  Patch: https://git.openjdk.org/valhalla/pull/1550.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1550/head:pull/1550

PR: https://git.openjdk.org/valhalla/pull/1550

From vromero at openjdk.org  Fri Sep  5 18:52:29 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 Sep 2025 18:52:29 GMT
Subject: [lworld] Integrated: 8359370: [lworld] allow instance fields of
 identity classes to be readable in the prologue phase
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <4Y2_cAzFBNtQNnfPxNf6UfEytTHd_GX6L8seGuL9h3A=.9f466b8a-e2f1-48f2-97ec-9b150f697f62@github.com>

On Fri, 15 Aug 2025 21:38:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

This pull request has now been integrated.

Changeset: 36201086
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3620108672dd991ee4ba9f0e5aae649de8c913ad
Stats:     600 lines in 27 files changed: 320 ins; 158 del; 122 mod

8359370: [lworld] allow instance fields of identity classes to be readable in the prologue phase

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/valhalla/pull/1523

From coleenp at openjdk.org  Fri Sep  5 19:07:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 5 Sep 2025 19:07:28 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v7]
In-Reply-To: <ZkU-PvYKSPtVRFCwgttKjnk2tFPv86TvRiBjGwSI_QY=.0e629b4b-c93d-4350-a4ee-ac8f70f1212b@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <k4qmY5F0YfrdXSFC-0i1aWOU4_jGJPWq7deqFzqqysE=.78e0ec0d-3547-436e-a459-16c9eeeba950@github.com>
 <ZkU-PvYKSPtVRFCwgttKjnk2tFPv86TvRiBjGwSI_QY=.0e629b4b-c93d-4350-a4ee-ac8f70f1212b@github.com>
Message-ID: <5Wh4lIG7YZRYTrn4lMAcTsQVOaAH0l_ENbim3b3bSqA=.1d167429-7e76-422b-8330-992c615ceaea@github.com>

On Fri, 5 Sep 2025 15:21:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix style
>
> test/hotspot/jtreg/ProblemList.txt line 284:
> 
>> 282: 
>> 283: runtime/valhalla/inlinetypes/ValuePreloadTest.java 8366440 generic-all
>> 284: runtime/verifier/CFLH/TestVerify.java 8366440 generic-all
> 
> These two have been fixed by [8366440](https://bugs.openjdk.org/browse/JDK-8366440)

Yes, I pushed the fix so you can un-problem list these here.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2325838299

From coleenp at openjdk.org  Fri Sep  5 19:12:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 5 Sep 2025 19:12:31 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v7]
In-Reply-To: <k4qmY5F0YfrdXSFC-0i1aWOU4_jGJPWq7deqFzqqysE=.78e0ec0d-3547-436e-a459-16c9eeeba950@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <k4qmY5F0YfrdXSFC-0i1aWOU4_jGJPWq7deqFzqqysE=.78e0ec0d-3547-436e-a459-16c9eeeba950@github.com>
Message-ID: <LbOR6_k12fm5_QxfPJwGdbaTfWb4CDqcCD-9q5HXTb4=.402ba7a8-fa58-4529-aef2-313e9c4a1e38@github.com>

On Fri, 5 Sep 2025 15:02:45 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
>> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
>> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix style

This looks great.  Nice rework and cleanups.

-------------

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1452#pullrequestreview-3190498465

From coleenp at openjdk.org  Fri Sep  5 19:51:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 5 Sep 2025 19:51:00 GMT
Subject: [lworld] RFR: 8294051: [lworld] runtime/AccModule/ConstModule.java
 fails with incorrect error message [v2]
In-Reply-To: <dwlACEOgpPbSZUEwRxZw5gL_RsjRuEwwHuLAN3uFpU8=.743b0dc8-73c9-499e-82ea-a8c958a0e3c6@github.com>
References: <dwlACEOgpPbSZUEwRxZw5gL_RsjRuEwwHuLAN3uFpU8=.743b0dc8-73c9-499e-82ea-a8c958a0e3c6@github.com>
Message-ID: <ZlKcpy2DJj19NLJftm78XapaFShlesJNjlkiFJ4ZPSU=.a8f622ec-0712-4cee-b2ae-5d722875e571@github.com>

> This change moves code back to match mainline that checks access flags and checks for invalid JVM_CONSTANTS_Module/Package before reading the class name out of the constant pool.
> Tested with tier1-3.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra error message printing for inner classes not in mainline.

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1550/files
  - new: https://git.openjdk.org/valhalla/pull/1550/files/2e7eaff4..b0dda156

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1550&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1550&range=00-01

  Stats: 23 lines in 2 files changed: 0 ins; 12 del; 11 mod
  Patch: https://git.openjdk.org/valhalla/pull/1550.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1550/head:pull/1550

PR: https://git.openjdk.org/valhalla/pull/1550

From vromero at openjdk.org  Fri Sep  5 20:07:25 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 Sep 2025 20:07:25 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v8]
In-Reply-To: <RALMQVc01Kqy9vJVky-RHMrU1C1v7lJ48i8A5cNVefk=.1474be39-2409-455c-a6d8-247131d878db@github.com>
References: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
 <RALMQVc01Kqy9vJVky-RHMrU1C1v7lJ48i8A5cNVefk=.1474be39-2409-455c-a6d8-247131d878db@github.com>
Message-ID: <tjoHzbsLtkssN-o84oPTu8qzyv_w_OsshkVYqjmwjKI=.27b3ecdf-54b6-461f-b183-3ddcd75c2cf8@github.com>

On Thu, 17 Jul 2025 15:20:43 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing unused field in Flow

fixed in: https://github.com/openjdk/valhalla/pull/1523

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1490#issuecomment-3259605157

From fparain at openjdk.org  Fri Sep  5 20:16:28 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 5 Sep 2025 20:16:28 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v8]
In-Reply-To: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
Message-ID: <d4Jh6lEhJsNu9kl3yGe_sd6aDWgOg4dwCkF-VZxgjJ0=.810a8f6d-6a53-4ceb-8fe8-2bcacd82699a@github.com>

> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  More fixes from reviewers comments

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1452/files
  - new: https://git.openjdk.org/valhalla/pull/1452/files/ca75bab8..0e8cd32b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=07
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1452&range=06-07

  Stats: 7 lines in 3 files changed: 2 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1452.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1452/head:pull/1452

PR: https://git.openjdk.org/valhalla/pull/1452

From rriggs at openjdk.org  Sat Sep  6 16:47:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 6 Sep 2025 16:47:53 GMT
Subject: [lworld] RFR: 8366841 objects equals no acmp
Message-ID: <BLVgcWd4SUxqIk3Xl0DRiyJ0ES85TExiPyxaWlxGC-k=.a563485e-fd4b-49ab-8868-681959430157@github.com>

Modify java.util.Objects.equals to avoid acmp (==) when --enable-preview.

There is a simple bug fix in the SimpleValueGraphs test.

-------------

Commit messages:
 - Merge branch 'lworld' into 8366841-objects-equals-no-acmp
 - Bug fix in SimpleValueGraphs.SimpleValue.equals; compare corresponding fields
 - 8366841: [lworld] Objects.equals without identity comparison

Changes: https://git.openjdk.org/valhalla/pull/1551/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1551&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366841
  Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/1551.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1551/head:pull/1551

PR: https://git.openjdk.org/valhalla/pull/1551

From liach at openjdk.org  Sun Sep  7 03:37:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 7 Sep 2025 03:37:18 GMT
Subject: [lworld] RFR: 8366841 objects equals no acmp
In-Reply-To: <BLVgcWd4SUxqIk3Xl0DRiyJ0ES85TExiPyxaWlxGC-k=.a563485e-fd4b-49ab-8868-681959430157@github.com>
References: <BLVgcWd4SUxqIk3Xl0DRiyJ0ES85TExiPyxaWlxGC-k=.a563485e-fd4b-49ab-8868-681959430157@github.com>
Message-ID: <kVcZsVRKSpwLENdm6C0yyTZyfGK_LBCLzF-_NNEX1s0=.e00e9a32-f557-464b-aee8-d5f2038f882e@github.com>

On Sat, 6 Sep 2025 16:42:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Modify java.util.Objects.equals to avoid acmp (==) when --enable-preview.
> 
> There is a simple bug fix in the SimpleValueGraphs test.

Looks reasonable.

-------------

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1551#pullrequestreview-3194140533

From mchevalier at openjdk.org  Mon Sep  8 07:13:26 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 8 Sep 2025 07:13:26 GMT
Subject: [lworld] RFR: 8365978: [lworld] C2:
 assert(vk->maybe_flat_in_array()) when using compareAndSetFlatValue with
 -XX:-UseArrayFlattening [v2]
In-Reply-To: <qXUmkLLQw7c2dcRJBs3galgigoG_kfDV7wGhLxmb0xs=.028dbaff-6d74-4637-83d0-c4774c6a2275@github.com>
References: <qXUmkLLQw7c2dcRJBs3galgigoG_kfDV7wGhLxmb0xs=.028dbaff-6d74-4637-83d0-c4774c6a2275@github.com>
Message-ID: <PtlJMx7umsKdv1RDStLNRDckuuZmVjZ4tPdFJa6NqsM=.aafd3fce-7ebb-43bd-b72c-ab53155ac093@github.com>

> `Unsafe::compareAndSetFlatValue` calls `Unsafe::compareAndSetFlatValueAsBytes` which then calls `Unsafe::putFlatValue` on a flat array created by `Unsafe::newSpecialArray`.
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L2870-L2875
> 
> `putFlatValue` can be intrinsified in
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2727
> 
> that calls `cast_to_flat_array`
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2831
> 
> which fails the assert
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/graphKit.cpp#L1875-L1876
> 
> because of
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/oops/inlineKlass.cpp#L287-L290
> 
> Of course, if array flattening is disabled, one can't have flat arrays. And indeed, `Unsafe::newSpecialArray` will raise if called. So at runtime, the call to `Unsafe::compareAndSetFlatValue` should simply raise. But when compiled the assert is hit, crashing the VM, because it cannot tell that the code is dead, but can check that if it's not the array is not flat. That doesn't seem reasonable to me. I propose to insert a trap instead. Even in the case where this code wouldn't be dead (like if `Unsafe::newSpecialArray` is just undefined behavior instead of throwing), crashing the compiler doesn't seem like a good option.
> 
> The situation is actually more surprising than it seems: using `Unsafe::compareAndSetFlatValue` on a flat field with `-XX:-UseArrayFlattening` sounds reasonable, but doesn't actually work since the implementation will (attempt to) create flat arrays under the hood. It is not clear to me whether it's actually desirable, as `Unsafe::compareAndSetFlatValue` introduce some coupling of field and array flattening, but on the other hand, it's an unsafe API, so it's not that crazy to require more constrains to use.
> 
> Thanks,
> Marc

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  comments

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1549/files
  - new: https://git.openjdk.org/valhalla/pull/1549/files/3cc81f07..a988452f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1549&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1549&range=00-01

  Stats: 16 lines in 2 files changed: 8 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1549.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1549/head:pull/1549

PR: https://git.openjdk.org/valhalla/pull/1549

From mchevalier at openjdk.org  Mon Sep  8 07:17:11 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 8 Sep 2025 07:17:11 GMT
Subject: [lworld] RFR: 8365978: [lworld] C2:
 assert(vk->maybe_flat_in_array()) when using compareAndSetFlatValue with
 -XX:-UseArrayFlattening [v3]
In-Reply-To: <qXUmkLLQw7c2dcRJBs3galgigoG_kfDV7wGhLxmb0xs=.028dbaff-6d74-4637-83d0-c4774c6a2275@github.com>
References: <qXUmkLLQw7c2dcRJBs3galgigoG_kfDV7wGhLxmb0xs=.028dbaff-6d74-4637-83d0-c4774c6a2275@github.com>
Message-ID: <-0sk3HKTVvCPpU-cW-hj16LKPnCYn66F4Q0rHm1E9Cw=.09d84205-5aa3-420a-955d-80cf27d8ceec@github.com>

> `Unsafe::compareAndSetFlatValue` calls `Unsafe::compareAndSetFlatValueAsBytes` which then calls `Unsafe::putFlatValue` on a flat array created by `Unsafe::newSpecialArray`.
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L2870-L2875
> 
> `putFlatValue` can be intrinsified in
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2727
> 
> that calls `cast_to_flat_array`
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2831
> 
> which fails the assert
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/graphKit.cpp#L1875-L1876
> 
> because of
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/oops/inlineKlass.cpp#L287-L290
> 
> Of course, if array flattening is disabled, one can't have flat arrays. And indeed, `Unsafe::newSpecialArray` will raise if called. So at runtime, the call to `Unsafe::compareAndSetFlatValue` should simply raise. But when compiled the assert is hit, crashing the VM, because it cannot tell that the code is dead, but can check that if it's not the array is not flat. That doesn't seem reasonable to me. I propose to insert a trap instead. Even in the case where this code wouldn't be dead (like if `Unsafe::newSpecialArray` is just undefined behavior instead of throwing), crashing the compiler doesn't seem like a good option.
> 
> The situation is actually more surprising than it seems: using `Unsafe::compareAndSetFlatValue` on a flat field with `-XX:-UseArrayFlattening` sounds reasonable, but doesn't actually work since the implementation will (attempt to) create flat arrays under the hood. It is not clear to me whether it's actually desirable, as `Unsafe::compareAndSetFlatValue` introduce some coupling of field and array flattening, but on the other hand, it's an unsafe API, so it's not that crazy to require more constrains to use.
> 
> Thanks,
> Marc

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  Add +UseFieldFlattening

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1549/files
  - new: https://git.openjdk.org/valhalla/pull/1549/files/a988452f..e6c26112

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1549&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1549&range=01-02

  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1549.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1549/head:pull/1549

PR: https://git.openjdk.org/valhalla/pull/1549

From thartmann at openjdk.org  Mon Sep  8 07:23:19 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 8 Sep 2025 07:23:19 GMT
Subject: [lworld] RFR: 8365978: [lworld] C2:
 assert(vk->maybe_flat_in_array()) when using compareAndSetFlatValue with
 -XX:-UseArrayFlattening [v3]
In-Reply-To: <-0sk3HKTVvCPpU-cW-hj16LKPnCYn66F4Q0rHm1E9Cw=.09d84205-5aa3-420a-955d-80cf27d8ceec@github.com>
References: <qXUmkLLQw7c2dcRJBs3galgigoG_kfDV7wGhLxmb0xs=.028dbaff-6d74-4637-83d0-c4774c6a2275@github.com>
 <-0sk3HKTVvCPpU-cW-hj16LKPnCYn66F4Q0rHm1E9Cw=.09d84205-5aa3-420a-955d-80cf27d8ceec@github.com>
Message-ID: <NywT7fZ_ru0oVNNLfBku31JqE1Q6Rkio_XVhGOmUpSs=.a15001d2-9046-4959-b465-26964a7c3789@github.com>

On Mon, 8 Sep 2025 07:17:11 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> `Unsafe::compareAndSetFlatValue` calls `Unsafe::compareAndSetFlatValueAsBytes` which then calls `Unsafe::putFlatValue` on a flat array created by `Unsafe::newSpecialArray`.
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L2870-L2875
>> 
>> `putFlatValue` can be intrinsified in
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2727
>> 
>> that calls `cast_to_flat_array`
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2831
>> 
>> which fails the assert
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/graphKit.cpp#L1875-L1876
>> 
>> because of
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/oops/inlineKlass.cpp#L287-L290
>> 
>> Of course, if array flattening is disabled, one can't have flat arrays. And indeed, `Unsafe::newSpecialArray` will raise if called. So at runtime, the call to `Unsafe::compareAndSetFlatValue` should simply raise. But when compiled the assert is hit, crashing the VM, because it cannot tell that the code is dead, but can check that if it's not the array is not flat. That doesn't seem reasonable to me. I propose to insert a trap instead. Even in the case where this code wouldn't be dead (like if `Unsafe::newSpecialArray` is just undefined behavior instead of throwing), crashing the compiler doesn't seem like a good option.
>> 
>> The situation is actually more surprising than it seems: using `Unsafe::compareAndSetFlatValue` on a flat field with `-XX:-UseArrayFlattening` sounds reasonable, but doesn't actually work since the implementation will (attempt to) create flat arrays under the hood. It is not clear to me whether it's actually desirable, as `Unsafe::compareAndSetFlatValue` introduce some coupling of field and array flattening, but on the other hand, it's an unsafe API, so it's not that crazy to require more constrains to use.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add +UseFieldFlattening

Thanks for the detailed analysis Marc. I don't like the coupling between flat arrays and fields in the compareAndSet implementation but that's not something that the JIT can fix :) Looks good to me!

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1549#pullrequestreview-3195269182

From mchevalier at openjdk.org  Mon Sep  8 07:27:27 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 8 Sep 2025 07:27:27 GMT
Subject: [lworld] RFR: 8365978: [lworld] C2:
 assert(vk->maybe_flat_in_array()) when using compareAndSetFlatValue with
 -XX:-UseArrayFlattening [v3]
In-Reply-To: <-0sk3HKTVvCPpU-cW-hj16LKPnCYn66F4Q0rHm1E9Cw=.09d84205-5aa3-420a-955d-80cf27d8ceec@github.com>
References: <qXUmkLLQw7c2dcRJBs3galgigoG_kfDV7wGhLxmb0xs=.028dbaff-6d74-4637-83d0-c4774c6a2275@github.com>
 <-0sk3HKTVvCPpU-cW-hj16LKPnCYn66F4Q0rHm1E9Cw=.09d84205-5aa3-420a-955d-80cf27d8ceec@github.com>
Message-ID: <QngesyG9XGVuxyFUadoRwtgK9JEuO17RPU_pon56NBY=.25e35509-d9d1-4094-a73c-b62a58430b01@github.com>

On Mon, 8 Sep 2025 07:17:11 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> `Unsafe::compareAndSetFlatValue` calls `Unsafe::compareAndSetFlatValueAsBytes` which then calls `Unsafe::putFlatValue` on a flat array created by `Unsafe::newSpecialArray`.
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L2870-L2875
>> 
>> `putFlatValue` can be intrinsified in
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2727
>> 
>> that calls `cast_to_flat_array`
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2831
>> 
>> which fails the assert
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/graphKit.cpp#L1875-L1876
>> 
>> because of
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/oops/inlineKlass.cpp#L287-L290
>> 
>> Of course, if array flattening is disabled, one can't have flat arrays. And indeed, `Unsafe::newSpecialArray` will raise if called. So at runtime, the call to `Unsafe::compareAndSetFlatValue` should simply raise. But when compiled the assert is hit, crashing the VM, because it cannot tell that the code is dead, but can check that if it's not the array is not flat. That doesn't seem reasonable to me. I propose to insert a trap instead. Even in the case where this code wouldn't be dead (like if `Unsafe::newSpecialArray` is just undefined behavior instead of throwing), crashing the compiler doesn't seem like a good option.
>> 
>> The situation is actually more surprising than it seems: using `Unsafe::compareAndSetFlatValue` on a flat field with `-XX:-UseArrayFlattening` sounds reasonable, but doesn't actually work since the implementation will (attempt to) create flat arrays under the hood. It is not clear to me whether it's actually desirable, as `Unsafe::compareAndSetFlatValue` introduce some coupling of field and array flattening, but on the other hand, it's an unsafe API, so it's not that crazy to require more constrains to use.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add +UseFieldFlattening

Thanks @TobiHartmann

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1549#issuecomment-3264953054

From duke at openjdk.org  Mon Sep  8 07:27:28 2025
From: duke at openjdk.org (duke)
Date: Mon, 8 Sep 2025 07:27:28 GMT
Subject: [lworld] RFR: 8365978: [lworld] C2:
 assert(vk->maybe_flat_in_array()) when using compareAndSetFlatValue with
 -XX:-UseArrayFlattening [v3]
In-Reply-To: <-0sk3HKTVvCPpU-cW-hj16LKPnCYn66F4Q0rHm1E9Cw=.09d84205-5aa3-420a-955d-80cf27d8ceec@github.com>
References: <qXUmkLLQw7c2dcRJBs3galgigoG_kfDV7wGhLxmb0xs=.028dbaff-6d74-4637-83d0-c4774c6a2275@github.com>
 <-0sk3HKTVvCPpU-cW-hj16LKPnCYn66F4Q0rHm1E9Cw=.09d84205-5aa3-420a-955d-80cf27d8ceec@github.com>
Message-ID: <UxgUkgvkW18fhajfcb4txHA5wWKIjA9jXYMif8_xwAI=.98805378-eb82-4b2c-a030-741666f7ba7a@github.com>

On Mon, 8 Sep 2025 07:17:11 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> `Unsafe::compareAndSetFlatValue` calls `Unsafe::compareAndSetFlatValueAsBytes` which then calls `Unsafe::putFlatValue` on a flat array created by `Unsafe::newSpecialArray`.
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L2870-L2875
>> 
>> `putFlatValue` can be intrinsified in
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2727
>> 
>> that calls `cast_to_flat_array`
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2831
>> 
>> which fails the assert
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/graphKit.cpp#L1875-L1876
>> 
>> because of
>> 
>> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/oops/inlineKlass.cpp#L287-L290
>> 
>> Of course, if array flattening is disabled, one can't have flat arrays. And indeed, `Unsafe::newSpecialArray` will raise if called. So at runtime, the call to `Unsafe::compareAndSetFlatValue` should simply raise. But when compiled the assert is hit, crashing the VM, because it cannot tell that the code is dead, but can check that if it's not the array is not flat. That doesn't seem reasonable to me. I propose to insert a trap instead. Even in the case where this code wouldn't be dead (like if `Unsafe::newSpecialArray` is just undefined behavior instead of throwing), crashing the compiler doesn't seem like a good option.
>> 
>> The situation is actually more surprising than it seems: using `Unsafe::compareAndSetFlatValue` on a flat field with `-XX:-UseArrayFlattening` sounds reasonable, but doesn't actually work since the implementation will (attempt to) create flat arrays under the hood. It is not clear to me whether it's actually desirable, as `Unsafe::compareAndSetFlatValue` introduce some coupling of field and array flattening, but on the other hand, it's an unsafe API, so it's not that crazy to require more constrains to use.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add +UseFieldFlattening

@marc-chevalier 
Your change (at version e6c2611296846cbb7f11759485588d489dcbab60) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1549#issuecomment-3264955082

From mchevalier at openjdk.org  Mon Sep  8 07:32:22 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 8 Sep 2025 07:32:22 GMT
Subject: [lworld] Integrated: 8365978: [lworld] C2:
 assert(vk->maybe_flat_in_array()) when using compareAndSetFlatValue with
 -XX:-UseArrayFlattening
In-Reply-To: <qXUmkLLQw7c2dcRJBs3galgigoG_kfDV7wGhLxmb0xs=.028dbaff-6d74-4637-83d0-c4774c6a2275@github.com>
References: <qXUmkLLQw7c2dcRJBs3galgigoG_kfDV7wGhLxmb0xs=.028dbaff-6d74-4637-83d0-c4774c6a2275@github.com>
Message-ID: <Rg1L5DBJieDHOtaqU_yRvWm7rUSNmLV_WZU4nN0SoBE=.e0893b04-38db-4378-bce9-b6662a5f0ee8@github.com>

On Fri, 5 Sep 2025 11:42:42 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> `Unsafe::compareAndSetFlatValue` calls `Unsafe::compareAndSetFlatValueAsBytes` which then calls `Unsafe::putFlatValue` on a flat array created by `Unsafe::newSpecialArray`.
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L2870-L2875
> 
> `putFlatValue` can be intrinsified in
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2727
> 
> that calls `cast_to_flat_array`
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/library_call.cpp#L2831
> 
> which fails the assert
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/opto/graphKit.cpp#L1875-L1876
> 
> because of
> 
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/oops/inlineKlass.cpp#L287-L290
> 
> Of course, if array flattening is disabled, one can't have flat arrays. And indeed, `Unsafe::newSpecialArray` will raise if called. So at runtime, the call to `Unsafe::compareAndSetFlatValue` should simply raise. But when compiled the assert is hit, crashing the VM, because it cannot tell that the code is dead, but can check that if it's not the array is not flat. That doesn't seem reasonable to me. I propose to insert a trap instead. Even in the case where this code wouldn't be dead (like if `Unsafe::newSpecialArray` is just undefined behavior instead of throwing), crashing the compiler doesn't seem like a good option.
> 
> The situation is actually more surprising than it seems: using `Unsafe::compareAndSetFlatValue` on a flat field with `-XX:-UseArrayFlattening` sounds reasonable, but doesn't actually work since the implementation will (attempt to) create flat arrays under the hood. It is not clear to me whether it's actually desirable, as `Unsafe::compareAndSetFlatValue` introduce some coupling of field and array flattening, but on the other hand, it's an unsafe API, so it's not that crazy to require more constrains to use.
> 
> Thanks,
> Marc

This pull request has now been integrated.

Changeset: b53b0491
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b53b0491ebafdfc8a3b7f20989b1f49c52e69755
Stats:     101 lines in 2 files changed: 91 ins; 0 del; 10 mod

8365978: [lworld] C2: assert(vk->maybe_flat_in_array()) when using compareAndSetFlatValue with -XX:-UseArrayFlattening

Reviewed-by: thartmann

-------------

PR: https://git.openjdk.org/valhalla/pull/1549

From fparain at openjdk.org  Mon Sep  8 13:39:32 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 8 Sep 2025 13:39:32 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v7]
In-Reply-To: <5Wh4lIG7YZRYTrn4lMAcTsQVOaAH0l_ENbim3b3bSqA=.1d167429-7e76-422b-8330-992c615ceaea@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <k4qmY5F0YfrdXSFC-0i1aWOU4_jGJPWq7deqFzqqysE=.78e0ec0d-3547-436e-a459-16c9eeeba950@github.com>
 <ZkU-PvYKSPtVRFCwgttKjnk2tFPv86TvRiBjGwSI_QY=.0e629b4b-c93d-4350-a4ee-ac8f70f1212b@github.com>
 <5Wh4lIG7YZRYTrn4lMAcTsQVOaAH0l_ENbim3b3bSqA=.1d167429-7e76-422b-8330-992c615ceaea@github.com>
Message-ID: <0f6EeVR_c77PnC-GqYhOi1j3sfi3XbJD2U2BbzK2Cww=.1ce4bee3-f2cc-41e6-bce7-bc23580a1663@github.com>

On Fri, 5 Sep 2025 19:05:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/hotspot/jtreg/ProblemList.txt line 284:
>> 
>>> 282: 
>>> 283: runtime/valhalla/inlinetypes/ValuePreloadTest.java 8366440 generic-all
>>> 284: runtime/verifier/CFLH/TestVerify.java 8366440 generic-all
>> 
>> These two have been fixed by [8366440](https://bugs.openjdk.org/browse/JDK-8366440)
>
> Yes, I pushed the fix so you can un-problem list these here.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2330278551

From fparain at openjdk.org  Mon Sep  8 13:45:31 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 8 Sep 2025 13:45:31 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v3]
In-Reply-To: <3ZFfRKV-g0x5Z_I_QxqlVi4iiucbyV0vqleA-05YsXg=.410586c3-9dd9-4732-91f8-44b9f5248b35@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <dXhbp5M6ANCXeaJdgfILwCJP8MSKS7KHtY7znO-oJl8=.7f240e61-a3b7-4595-b57e-0aa7d79a3863@github.com>
 <IwMeGxEiG9wYBUNaybVKcvzXIFw8XxMM_bBi0_DKEAc=.b9fe4996-2cdf-481e-9e7c-d267018d47ac@github.com>
 <3ZFfRKV-g0x5Z_I_QxqlVi4iiucbyV0vqleA-05YsXg=.410586c3-9dd9-4732-91f8-44b9f5248b35@github.com>
Message-ID: <IlNAYcfwSQyUaEb56CxLE1QqkHSCuotmix1_ORnPMu4=.3b17601b-a787-479d-9f05-fab0a97f4e9b@github.com>

On Fri, 5 Sep 2025 16:28:39 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> src/hotspot/share/cds/cdsEnumKlass.cpp line 92:
>> 
>>> 90:   }
>>> 91:   oop oop_field = mirror->obj_field(fd.offset());
>>> 92:   Klass* oop_field_klass = oop_field->is_objArray() ? oop_field->klass()->super() : oop_field->klass();
>> 
>> Hmm, what does this do? I assume `is_objArray` tests if something can be converted to Java `Object[]`. In this case, CDS should check if the component type of the array instead of the array supepr class, I think? The original code did not call `super()`.
>
> There should be no oops that are ObjArrayKlass, so in reality this is checking for refined array klasses. The reason it goes up to the super is that the super will be an ObjArrayKlass, specifically the same one that will be returned by `ik->array_klass_or_null()`. 
> 
> I think you're right in saying that we can look at the element klass (or bottom klass?) and do the comparison as well.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2330296938

From fparain at openjdk.org  Mon Sep  8 13:45:32 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 8 Sep 2025 13:45:32 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v4]
In-Reply-To: <jLG8ezW8GXaz2EabGoiISX5L9VrYxa-EHJ7FjBcUKd4=.59e0ac68-ccd3-430e-ac5a-00d20c568c17@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <3So9QZtIv6YW6cJMH3jf2HykEPIf8roqqxlizpdsq1g=.7ad9bbaf-a664-459b-a7d0-0cc2d8d4f963@github.com>
 <Yeq_GYfRQOfVwrtqUnn95h-Vu_1OonoRDVEU1pA9RFg=.c0efb3fe-b929-46e6-b9f8-e390ed1bedb8@github.com>
 <jLG8ezW8GXaz2EabGoiISX5L9VrYxa-EHJ7FjBcUKd4=.59e0ac68-ccd3-430e-ac5a-00d20c568c17@github.com>
Message-ID: <nKVTSaX-DFQWp9BiaCXx9EmjwHNh2uNorBtDIYNUsXg=.965a20f3-4f34-43ff-8c62-5fa9848f760c@github.com>

On Fri, 5 Sep 2025 14:58:41 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> src/hotspot/share/cds/heapShared.cpp line 1299:
>> 
>>> 1297:       Klass* resolved_k = SystemDictionary::resolve_or_null(k->name(), CHECK);
>>> 1298:       if (resolved_k->is_array_klass()) {
>>> 1299:         assert(resolved_k == k || ((ObjArrayKlass*)resolved_k)->next_refined_array_klass() == k, "classes used by archived heap must not be replaced by JVMTI ClassFileLoadHook");
>> 
>> Should this be is_objArray_klass() ? and ObjArrayKlass::cast(resolved_k) instead?
>
> Yes that would be more correct. However, the check for `next_refined_array_klass()` may not be valid once CDS heap dumping is enabled as there could be more entries into the linked list. The fix here would be to check for
> `assert(resolved_k == k || resolved_k == k->super(), "...")`

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1452#discussion_r2330293503

From fparain at openjdk.org  Mon Sep  8 13:49:32 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 8 Sep 2025 13:49:32 GMT
Subject: [lworld] RFR: 8366705: [lworld] Re-work of arrays meta-data [v8]
In-Reply-To: <d4Jh6lEhJsNu9kl3yGe_sd6aDWgOg4dwCkF-VZxgjJ0=.810a8f6d-6a53-4ceb-8fe8-2bcacd82699a@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
 <d4Jh6lEhJsNu9kl3yGe_sd6aDWgOg4dwCkF-VZxgjJ0=.810a8f6d-6a53-4ceb-8fe8-2bcacd82699a@github.com>
Message-ID: <q66px2ruOimsA74hpo2ncF0SahQqVzF11rKv77n-zWM=.d63b60ab-077a-469a-85a7-a9b4d6b50e92@github.com>

On Fri, 5 Sep 2025 20:16:28 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
>> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
>> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More fixes from reviewers comments

Many thanks to all contributors and all reviewers for helping on this huge work.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1452#issuecomment-3266421812

From fparain at openjdk.org  Mon Sep  8 13:52:45 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 8 Sep 2025 13:52:45 GMT
Subject: [lworld] Integrated: 8366705: [lworld] Re-work of arrays meta-data
In-Reply-To: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
References: <NkD28BJI-gXYDUU9-kiIlz_SF3eY2g6aVx4GqKZLn9U=.2e5bf745-aaf9-48e3-9dd5-d3bc0d36604b@github.com>
Message-ID: <1i5Afm6zEsk3k6o6-0rQ8Ngnmfv-teUuyCaBBmEpOsg=.b8ef5e1c-d3f7-4940-9251-8ef590230e17@github.com>

On Fri, 9 May 2025 19:13:50 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Since the removal of Q-types and the notion that nullability was not part of the Java type, there was an awkward situation because nullable arrays of value types and null free arrays of value types had each a different Java mirror when they were in fact supposed to have the same Java type.
> In order to accommodate to the new situation, that arrays can have properties (nullability, flatness, atomicity, etc.) that are not part of their Java type, the 1-1 relationship between the *ArrayKlass and the Java mirror must be broken.
> The proposed solution is to dedicate one instance of ObjArrayKlass to represent the Java type of the array in the JVM, and have this instance being the counterpart of the Java mirror of the array, and have several instances of RefArrayKlass and FlatArrayKlass that represent the refinements of the Java array type. Each RefArrayKlass/FlatArrayKlass encodes the characteristic of a Java array for a given element type and a set of properties.

This pull request has now been integrated.

Changeset: 94cca4b7
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/94cca4b78eb5d6ceb6fc47766c03c738893c53a6
Stats:     4662 lines in 164 files changed: 2936 ins; 1063 del; 663 mod

8366705: [lworld] Re-work of arrays meta-data

Co-authored-by: Tobias Hartmann <thartmann at openjdk.org>
Co-authored-by: Coleen Phillimore <coleenp at openjdk.org>
Co-authored-by: Chen Liang <liach at openjdk.org>
Co-authored-by: Matias Saavedra Silva <matsaave at openjdk.org>
Reviewed-by: coleenp, thartmann, dsimms

-------------

PR: https://git.openjdk.org/valhalla/pull/1452

From fparain at openjdk.org  Mon Sep  8 16:15:23 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 8 Sep 2025 16:15:23 GMT
Subject: [lworld] RFR: 8294051: [lworld] runtime/AccModule/ConstModule.java
 fails with incorrect error message [v2]
In-Reply-To: <ZlKcpy2DJj19NLJftm78XapaFShlesJNjlkiFJ4ZPSU=.a8f622ec-0712-4cee-b2ae-5d722875e571@github.com>
References: <dwlACEOgpPbSZUEwRxZw5gL_RsjRuEwwHuLAN3uFpU8=.743b0dc8-73c9-499e-82ea-a8c958a0e3c6@github.com>
 <ZlKcpy2DJj19NLJftm78XapaFShlesJNjlkiFJ4ZPSU=.a8f622ec-0712-4cee-b2ae-5d722875e571@github.com>
Message-ID: <Lqjh48WFPEOy7A67Gyw-pa5vbA77mxhyMA6sVblrgdI=.e7acceb8-879a-4bdf-95c9-b8023f7b1657@github.com>

On Fri, 5 Sep 2025 19:51:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change moves code back to match mainline that checks access flags and checks for invalid JVM_CONSTANTS_Module/Package before reading the class name out of the constant pool.
>> Tested with tier1-3.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra error message printing for inner classes not in mainline.

src/hotspot/share/classfile/classFileParser.cpp line 4465:

> 4463:       "Illegal class modifiers in class %s%s: 0x%X",
> 4464:       _class_name->as_C_string(), class_note, flags
> 4465:     );

By removing the special handling of inner classes, the exception will report the access flag issue on the wrong class. This is going to make debugging/troubleshooting harder.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1550#discussion_r2330725170

From coleenp at openjdk.org  Mon Sep  8 17:51:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 8 Sep 2025 17:51:28 GMT
Subject: [lworld] RFR: 8294051: [lworld] runtime/AccModule/ConstModule.java
 fails with incorrect error message [v2]
In-Reply-To: <Lqjh48WFPEOy7A67Gyw-pa5vbA77mxhyMA6sVblrgdI=.e7acceb8-879a-4bdf-95c9-b8023f7b1657@github.com>
References: <dwlACEOgpPbSZUEwRxZw5gL_RsjRuEwwHuLAN3uFpU8=.743b0dc8-73c9-499e-82ea-a8c958a0e3c6@github.com>
 <ZlKcpy2DJj19NLJftm78XapaFShlesJNjlkiFJ4ZPSU=.a8f622ec-0712-4cee-b2ae-5d722875e571@github.com>
 <Lqjh48WFPEOy7A67Gyw-pa5vbA77mxhyMA6sVblrgdI=.e7acceb8-879a-4bdf-95c9-b8023f7b1657@github.com>
Message-ID: <9WzNCEChUd3BF408cIPGApv0syVRk-sDOcTWtplkyAM=.6de8c76c-1911-45de-afff-5039ae192639@github.com>

On Mon, 8 Sep 2025 16:12:44 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove extra error message printing for inner classes not in mainline.
>
> src/hotspot/share/classfile/classFileParser.cpp line 4465:
> 
>> 4463:       "Illegal class modifiers in class %s%s: 0x%X",
>> 4464:       _class_name->as_C_string(), class_note, flags
>> 4465:     );
> 
> By removing the special handling of inner classes, the exception will report the access flag issue on the wrong class. This is going to make debugging/troubleshooting harder.

This is something we don't have in mainline.  I can add it there instead and it'll get merged in here.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1550#discussion_r2330929075

From vromero at openjdk.org  Mon Sep  8 19:10:32 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 8 Sep 2025 19:10:32 GMT
Subject: Integrated: Merge lworld
Message-ID: <DyoWqA1M0fIlXAlQJdafB94gPvBlWBrNvcaF5jsANsc=.171d0ca9-a699-4f86-bd5a-c90a7bd583ab@github.com>

Merge branch 'lworld' into lw5_merge_lworld
# Conflicts:
#	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java

-------------

Commit messages:
 - Merge branch 'lworld' into lw5_merge_lworld
 - Merge lworld
 - Merge lworld
 - 8347754: [lw5] fix the order of nullness markers in signatures
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - 8340125: [lw5] null checks are not being generated for method invocations and array writes
 - ... and 58 more: https://git.openjdk.org/valhalla/compare/94cca4b7...608ad7f1

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/valhalla/pull/1553/files
  Stats: 6801 lines in 101 files changed: 6675 ins; 5 del; 121 mod
  Patch: https://git.openjdk.org/valhalla/pull/1553.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1553/head:pull/1553

PR: https://git.openjdk.org/valhalla/pull/1553

From vromero at openjdk.org  Mon Sep  8 19:10:35 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 8 Sep 2025 19:10:35 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <DyoWqA1M0fIlXAlQJdafB94gPvBlWBrNvcaF5jsANsc=.171d0ca9-a699-4f86-bd5a-c90a7bd583ab@github.com>
References: <DyoWqA1M0fIlXAlQJdafB94gPvBlWBrNvcaF5jsANsc=.171d0ca9-a699-4f86-bd5a-c90a7bd583ab@github.com>
Message-ID: <5alr5nbtdPhye6LNUuyhC0pkUGskKkBMY0aIeOxt53U=.2b54f598-3974-443e-8517-9994eb800f18@github.com>

On Mon, 8 Sep 2025 18:43:42 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5_merge_lworld
> # Conflicts:
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java

This pull request has now been integrated.

Changeset: aa56177f
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/aa56177f8b5b04a446d16bc92e6dc99879bf24f7
Stats:     222250 lines in 4108 files changed: 138290 ins; 55925 del; 28035 mod

Merge lworld

-------------

PR: https://git.openjdk.org/valhalla/pull/1553

From rriggs at openjdk.org  Mon Sep  8 20:55:22 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 Sep 2025 20:55:22 GMT
Subject: [lworld] Integrated: 8366841: [lworld] Objects.equals without identity
 comparison
In-Reply-To: <BLVgcWd4SUxqIk3Xl0DRiyJ0ES85TExiPyxaWlxGC-k=.a563485e-fd4b-49ab-8868-681959430157@github.com>
References: <BLVgcWd4SUxqIk3Xl0DRiyJ0ES85TExiPyxaWlxGC-k=.a563485e-fd4b-49ab-8868-681959430157@github.com>
Message-ID: <oYdso2XCpiPVs8wBTF-CC5p-OJyZ72pWSwZGtzcKD2c=.54c4fd70-b951-49a6-a680-7fd72ba06f8f@github.com>

On Sat, 6 Sep 2025 16:42:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Modify java.util.Objects.equals to avoid acmp (==) when --enable-preview.
> 
> There is a simple bug fix in the SimpleValueGraphs test.

This pull request has now been integrated.

Changeset: ba4e7678
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ba4e76780ce63aae96a03ba8f825390aa8415a84
Stats:     9 lines in 2 files changed: 6 ins; 0 del; 3 mod

8366841: [lworld] Objects.equals without identity comparison

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/valhalla/pull/1551

From mchevalier at openjdk.org  Tue Sep  9 09:22:49 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 9 Sep 2025 09:22:49 GMT
Subject: [lworld] RFR: 8352737: [lworld] Fix TestIntrinsics after VarHandle
 support cleanup
Message-ID: <5Iyhd5d2q5WzJejy3SSsNrrozsgtjiPcKmYAOC1JZh0=.2813c7d7-9b66-43b3-aff6-0c842deeab1a@github.com>

This remove bailout in 8 cases in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java`. This use a new small type that is tiny enough to be safely flattened in any case.

This change also makes sure that both branches in `test_*` are taken by asserting the value of `UseArrayFlattening`/`UseFieldFlattening`. One can check that there is at least one scenario for each case. Just add `Asserts.assertTrue(false);` if you have a doubt. Since each case run in a separate VM, I couldn't find an easy way to count that across scenarii, each branch is taken at least once.

There are still some bailout since `compareAndSetFlatValue` (and exchange one too) require array flattening. See https://github.com/openjdk/valhalla/pull/1549 & [JDK-8365978](https://bugs.openjdk.org/browse/JDK-8365978).

Thanks,
Marc

-------------

Commit messages:
 - cleanup
 - More
 - Progress

Changes: https://git.openjdk.org/valhalla/pull/1555/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1555&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352737
  Stats: 178 lines in 1 file changed: 84 ins; 0 del; 94 mod
  Patch: https://git.openjdk.org/valhalla/pull/1555.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1555/head:pull/1555

PR: https://git.openjdk.org/valhalla/pull/1555

From phubner at openjdk.org  Tue Sep  9 11:01:46 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 9 Sep 2025 11:01:46 GMT
Subject: [lworld] RFR: 8327257: [lworld] Tests are needed to stress class
 preloading with concurrent class loadings
Message-ID: <5BhLWx8JG5TtyJ-CueXpUfFq_QCWg5x_9oDaPJNr4Gw=.d1f668f7-ff8a-4307-b1d2-294a7f14fbbf@github.com>

Hi all,

This change strengthens our Valhalla-specific classloading test suite and guards against regressions. An overview of the new changes is as follows:
* `BigClassTreeClassLoader`: a utility classloader that generates huge class trees on the fly. The idea is to generate a tree that is deep (lots of parent classes) and very wide (classes have lots of value classes as fields, which have value class fields, etc.). 
* `ConcurrentClassLoadingTest` strains the classloading and preloading by classloading many classes at the same time.
* `LoadableDescriptorsTest` ensures that the `LoadableDescriptors` attribute can handle unexpected data. This may need to be revisited if https://bugs.openjdk.org/browse/JDK-8366907 changes the semantics.
* `PreLoadCircularityTest` ensures that preloading happens even when there are cycles (via inheritance, fields, and both). 
* `PreLoadDoesNotInitTest` is a regression test that ensures preloading will not initialize a class.
* `PreLoadFailuresDoNotImpactApplicationTest` ensures that a flaky classloader during preloading will not cause crashes as long as the classloader can find the class when it is actually used.
* `ValueClassInheritanceTest` is a regression test that ensures one cannot have a value class inherit from something that's not an abstract value class.

-------------

Commit messages:
 - Reindent.
 - More reviewer comments.
 - Incorporate feedback.
 - Move to JUnit and refactor.
 - Concurrent non-deadlocking huge tree test.
 - Iterate.
 - First draft.

Changes: https://git.openjdk.org/valhalla/pull/1552/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1552&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327257
  Stats: 892 lines in 11 files changed: 892 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1552.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1552/head:pull/1552

PR: https://git.openjdk.org/valhalla/pull/1552

From thartmann at openjdk.org  Tue Sep  9 11:24:39 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 9 Sep 2025 11:24:39 GMT
Subject: [lworld] RFR: 8352737: [lworld] Fix TestIntrinsics after VarHandle
 support cleanup
In-Reply-To: <5Iyhd5d2q5WzJejy3SSsNrrozsgtjiPcKmYAOC1JZh0=.2813c7d7-9b66-43b3-aff6-0c842deeab1a@github.com>
References: <5Iyhd5d2q5WzJejy3SSsNrrozsgtjiPcKmYAOC1JZh0=.2813c7d7-9b66-43b3-aff6-0c842deeab1a@github.com>
Message-ID: <FqB-s6zoyZZR_d-gazeHx5XVIPEKo2KFzjuYslkA93w=.74f6425b-2d43-47b8-a408-1b5fcb16ddfe@github.com>

On Tue, 9 Sep 2025 09:14:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> This remove bailout in 8 cases in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java`. This use a new small type that is tiny enough to be safely flattened in any case.
> 
> This change also makes sure that both branches in `test_*` are taken by asserting the value of `UseArrayFlattening`/`UseFieldFlattening`. One can check that there is at least one scenario for each case. Just add `Asserts.assertTrue(false);` if you have a doubt. Since each case run in a separate VM, I couldn't find an easy way to count that across scenarii, each branch is taken at least once.
> 
> There are still some bailout since `compareAndSetFlatValue` (and exchange one too) require array flattening. See https://github.com/openjdk/valhalla/pull/1549 & [JDK-8365978](https://bugs.openjdk.org/browse/JDK-8365978).
> 
> Thanks,
> Marc

Looks good to me!

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1555#pullrequestreview-3201002480

From phubner at openjdk.org  Tue Sep  9 11:29:28 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 9 Sep 2025 11:29:28 GMT
Subject: [lworld] RFR: 8327257: [lworld] Tests are needed to stress class
 preloading with concurrent class loadings [v2]
In-Reply-To: <5BhLWx8JG5TtyJ-CueXpUfFq_QCWg5x_9oDaPJNr4Gw=.d1f668f7-ff8a-4307-b1d2-294a7f14fbbf@github.com>
References: <5BhLWx8JG5TtyJ-CueXpUfFq_QCWg5x_9oDaPJNr4Gw=.d1f668f7-ff8a-4307-b1d2-294a7f14fbbf@github.com>
Message-ID: <86FkwRT5rMpdT1XAH2IfkrFubrubs0L8nWl4pnNaxYg=.2a56aaa2-ce15-4deb-ae7e-9cddd3ac7d0e@github.com>

> Hi all,
> 
> This change strengthens our Valhalla-specific classloading test suite and guards against regressions. An overview of the new changes is as follows:
> * `BigClassTreeClassLoader`: a utility classloader that generates huge class trees on the fly. The idea is to generate a tree that is deep (lots of parent classes) and very wide (classes have lots of value classes as fields, which have value class fields, etc.). 
> * `ConcurrentClassLoadingTest` strains the classloading and preloading by classloading many classes at the same time.
> * `LoadableDescriptorsTest` ensures that the `LoadableDescriptors` attribute can handle unexpected data. This may need to be revisited if https://bugs.openjdk.org/browse/JDK-8366907 changes the semantics.
> * `PreLoadCircularityTest` ensures that preloading happens even when there are cycles (via inheritance, fields, and both). 
> * `PreLoadDoesNotInitTest` is a regression test that ensures preloading will not initialize a class.
> * `PreLoadFailuresDoNotImpactApplicationTest` ensures that a flaky classloader during preloading will not cause crashes as long as the classloader can find the class when it is actually used.
> * `ValueClassInheritanceTest` is a regression test that ensures one cannot have a value class inherit from something that's not an abstract value class.

Paul H?bner has updated the pull request incrementally with three additional commits since the last revision:

 - Adjust stress rate.
 - Re-enable test.
 - Increase concurrent loading iterations.

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1552/files
  - new: https://git.openjdk.org/valhalla/pull/1552/files/68324e4b..9df98b53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1552&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1552&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1552.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1552/head:pull/1552

PR: https://git.openjdk.org/valhalla/pull/1552

From thartmann at openjdk.org  Tue Sep  9 11:42:35 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 9 Sep 2025 11:42:35 GMT
Subject: [lworld] RFR: 8366973: [lworld] Deopt/recompilation cycle due to call
 to method with unloaded return type
Message-ID: <8OaLoKuuXUtuX-UdpOu8mp_dIQl6yzipy8RMzNaMYMc=.b1bd1c05-b0ba-46f1-876f-9f31c2fa3b12@github.com>

In some benchmarks we hit an endless deopt/recompilation cycle because of this bailout in C2 when we compile a method with an unloaded return type:
https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/ci/ciTypeFlow.cpp#L766-L772

It's a regression / limitation from [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) that I had planned to fix later with [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443) because I thought it wouldn't have an impact on performance. Turns out it does, so I'll fix it with this issue similar to what we do in `PhaseMacroExpand::expand_mh_intrinsic_return`.

For testing, I added a new `PreloadClasses` debug flag that's enabled by default. Disabling it will disable preloading of all classes from the LoadableDescriptors attributes. Running testing with this caught some more issues that I fixed in this PR as well. I'll add it to our (internal) stress testing job separately.

I also fixed some inconsistency in the preload logging and adjusted the corresponding tests.

Thanks,
Tobias

-------------

Commit messages:
 - And even more
 - Merge branch 'lworld' into JDK-8366973
 - Aaand more fixes
 - Some more fixes
 - Fixed EA
 - First prototype

Changes: https://git.openjdk.org/valhalla/pull/1554/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1554&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366973
  Stats: 317 lines in 25 files changed: 207 ins; 18 del; 92 mod
  Patch: https://git.openjdk.org/valhalla/pull/1554.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1554/head:pull/1554

PR: https://git.openjdk.org/valhalla/pull/1554

From dsimms at openjdk.org  Tue Sep  9 12:51:56 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 9 Sep 2025 12:51:56 GMT
Subject: [lworld] Withdrawn: Merge jdk
In-Reply-To: <EJSRNnXpE1CxnOT0WUg5IEVl5o3yeR_fubY_GcTiTbc=.f219c41b-c6e7-46d4-beda-97a6c1825476@github.com>
References: <EJSRNnXpE1CxnOT0WUg5IEVl5o3yeR_fubY_GcTiTbc=.f219c41b-c6e7-46d4-beda-97a6c1825476@github.com>
Message-ID: <h5euRqRMKULg0Z2icmmLmVzsQ2xSX0ISJkhorWBpu0o=.2ffbbc34-a6b3-458f-a9bc-2ad524e5be7b@github.com>

On Thu, 4 Sep 2025 05:39:22 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+1
> Merge branch 'lworld' into lworld_merge_jdk_26_1

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/valhalla/pull/1545

From mchevalier at openjdk.org  Tue Sep  9 13:07:14 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 9 Sep 2025 13:07:14 GMT
Subject: [lworld] RFR: 8352737: [lworld] Fix TestIntrinsics after VarHandle
 support cleanup
In-Reply-To: <5Iyhd5d2q5WzJejy3SSsNrrozsgtjiPcKmYAOC1JZh0=.2813c7d7-9b66-43b3-aff6-0c842deeab1a@github.com>
References: <5Iyhd5d2q5WzJejy3SSsNrrozsgtjiPcKmYAOC1JZh0=.2813c7d7-9b66-43b3-aff6-0c842deeab1a@github.com>
Message-ID: <lJ34L5D285CKsu52w_ApIMiynpCJDqihYSR9bx41Ub8=.07a2ee64-4e84-4635-b8be-b9d2a5b3cd49@github.com>

On Tue, 9 Sep 2025 09:14:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> This remove bailout in 8 cases in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java`. This use a new small type that is tiny enough to be safely flattened in any case.
> 
> This change also makes sure that both branches in `test_*` are taken by asserting the value of `UseArrayFlattening`/`UseFieldFlattening`. One can check that there is at least one scenario for each case. Just add `Asserts.assertTrue(false);` if you have a doubt. Since each case run in a separate VM, I couldn't find an easy way to count that across scenarii, each branch is taken at least once.
> 
> There are still some bailout since `compareAndSetFlatValue` (and exchange one too) require array flattening. See https://github.com/openjdk/valhalla/pull/1549 & [JDK-8365978](https://bugs.openjdk.org/browse/JDK-8365978).
> 
> Thanks,
> Marc

Thanks @TobiHartmann!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1555#issuecomment-3270652348

From duke at openjdk.org  Tue Sep  9 13:09:16 2025
From: duke at openjdk.org (duke)
Date: Tue, 9 Sep 2025 13:09:16 GMT
Subject: [lworld] RFR: 8352737: [lworld] Fix TestIntrinsics after VarHandle
 support cleanup
In-Reply-To: <5Iyhd5d2q5WzJejy3SSsNrrozsgtjiPcKmYAOC1JZh0=.2813c7d7-9b66-43b3-aff6-0c842deeab1a@github.com>
References: <5Iyhd5d2q5WzJejy3SSsNrrozsgtjiPcKmYAOC1JZh0=.2813c7d7-9b66-43b3-aff6-0c842deeab1a@github.com>
Message-ID: <j6WsUNI5X6NlhkEfDcC0T-URGfZCBP_H6AUWHr-l7Cg=.b1e1e65b-acf8-4ade-b3f4-cf2d674e2b0e@github.com>

On Tue, 9 Sep 2025 09:14:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> This remove bailout in 8 cases in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java`. This use a new small type that is tiny enough to be safely flattened in any case.
> 
> This change also makes sure that both branches in `test_*` are taken by asserting the value of `UseArrayFlattening`/`UseFieldFlattening`. One can check that there is at least one scenario for each case. Just add `Asserts.assertTrue(false);` if you have a doubt. Since each case run in a separate VM, I couldn't find an easy way to count that across scenarii, each branch is taken at least once.
> 
> There are still some bailout since `compareAndSetFlatValue` (and exchange one too) require array flattening. See https://github.com/openjdk/valhalla/pull/1549 & [JDK-8365978](https://bugs.openjdk.org/browse/JDK-8365978).
> 
> Thanks,
> Marc

@marc-chevalier 
Your change (at version e915c02abf40bdb8d802a00d323bb6c3b2385252) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1555#issuecomment-3270665832

From mchevalier at openjdk.org  Tue Sep  9 13:19:51 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 9 Sep 2025 13:19:51 GMT
Subject: [lworld] Integrated: 8352737: [lworld] Fix TestIntrinsics after
 VarHandle support cleanup
In-Reply-To: <5Iyhd5d2q5WzJejy3SSsNrrozsgtjiPcKmYAOC1JZh0=.2813c7d7-9b66-43b3-aff6-0c842deeab1a@github.com>
References: <5Iyhd5d2q5WzJejy3SSsNrrozsgtjiPcKmYAOC1JZh0=.2813c7d7-9b66-43b3-aff6-0c842deeab1a@github.com>
Message-ID: <4bk7fk9XG066Lyi48TGjj8RBe0IJ1MbtuhDYVkmdZ50=.139472ee-0190-482b-a9e6-63ff5be4085b@github.com>

On Tue, 9 Sep 2025 09:14:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> This remove bailout in 8 cases in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java`. This use a new small type that is tiny enough to be safely flattened in any case.
> 
> This change also makes sure that both branches in `test_*` are taken by asserting the value of `UseArrayFlattening`/`UseFieldFlattening`. One can check that there is at least one scenario for each case. Just add `Asserts.assertTrue(false);` if you have a doubt. Since each case run in a separate VM, I couldn't find an easy way to count that across scenarii, each branch is taken at least once.
> 
> There are still some bailout since `compareAndSetFlatValue` (and exchange one too) require array flattening. See https://github.com/openjdk/valhalla/pull/1549 & [JDK-8365978](https://bugs.openjdk.org/browse/JDK-8365978).
> 
> Thanks,
> Marc

This pull request has now been integrated.

Changeset: 45a451a7
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/45a451a73a22e2af2237cbd45bd8140033881737
Stats:     178 lines in 1 file changed: 84 ins; 0 del; 94 mod

8352737: [lworld] Fix TestIntrinsics after VarHandle support cleanup

Reviewed-by: thartmann

-------------

PR: https://git.openjdk.org/valhalla/pull/1555

From thartmann at openjdk.org  Tue Sep  9 13:20:03 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 9 Sep 2025 13:20:03 GMT
Subject: [lworld] RFR: 8366973: [lworld] Deopt/recompilation cycle due to
 call to method with unloaded return type [v2]
In-Reply-To: <8OaLoKuuXUtuX-UdpOu8mp_dIQl6yzipy8RMzNaMYMc=.b1bd1c05-b0ba-46f1-876f-9f31c2fa3b12@github.com>
References: <8OaLoKuuXUtuX-UdpOu8mp_dIQl6yzipy8RMzNaMYMc=.b1bd1c05-b0ba-46f1-876f-9f31c2fa3b12@github.com>
Message-ID: <E4RcDAeFiNOW2YFyWOZhNO0t5VVgQ6RMHCtCWKgQjf0=.58e31795-a251-48ca-8aec-c18693d2c162@github.com>

> In some benchmarks we hit an endless deopt/recompilation cycle because of this bailout in C2 when we compile a method with an unloaded return type:
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/ci/ciTypeFlow.cpp#L766-L772
> 
> It's a regression / limitation from [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) that I had planned to fix later with [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443) because I thought it wouldn't have an impact on performance. Turns out it does, so I'll fix it with this issue similar to what we do in `PhaseMacroExpand::expand_mh_intrinsic_return`.
> 
> For testing, I added a new `PreloadClasses` debug flag that's enabled by default. Disabling it will disable preloading of all classes from the LoadableDescriptors attributes. Running testing with this caught some more issues that I fixed in this PR as well. I'll add it to our (internal) stress testing job separately.
> 
> I also fixed some inconsistency in the preload logging and adjusted the corresponding tests.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Increased timeouts

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1554/files
  - new: https://git.openjdk.org/valhalla/pull/1554/files/ba000c21..a89812ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1554&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1554&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1554.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1554/head:pull/1554

PR: https://git.openjdk.org/valhalla/pull/1554

From thartmann at openjdk.org  Tue Sep  9 14:49:20 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 9 Sep 2025 14:49:20 GMT
Subject: [lworld] Integrated: 8366973: [lworld] Deopt/recompilation cycle due
 to call to method with unloaded return type
In-Reply-To: <8OaLoKuuXUtuX-UdpOu8mp_dIQl6yzipy8RMzNaMYMc=.b1bd1c05-b0ba-46f1-876f-9f31c2fa3b12@github.com>
References: <8OaLoKuuXUtuX-UdpOu8mp_dIQl6yzipy8RMzNaMYMc=.b1bd1c05-b0ba-46f1-876f-9f31c2fa3b12@github.com>
Message-ID: <gOLOpZqrTiZid3OqXVPMMI58AW5m4wUXf9RvYJJiczE=.515be1ca-407d-48de-968c-b430d221df78@github.com>

On Tue, 9 Sep 2025 08:38:06 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> In some benchmarks we hit an endless deopt/recompilation cycle because of this bailout in C2 when we compile a method with an unloaded return type:
> https://github.com/openjdk/valhalla/blob/858be30119bd5bc37a69d16042523f53bea71a36/src/hotspot/share/ci/ciTypeFlow.cpp#L766-L772
> 
> It's a regression / limitation from [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) that I had planned to fix later with [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443) because I thought it wouldn't have an impact on performance. Turns out it does, so I'll fix it with this issue similar to what we do in `PhaseMacroExpand::expand_mh_intrinsic_return`.
> 
> For testing, I added a new `PreloadClasses` debug flag that's enabled by default. Disabling it will disable preloading of all classes from the LoadableDescriptors attributes. Running testing with this caught some more issues that I fixed in this PR as well. I'll add it to our (internal) stress testing job separately.
> 
> I also fixed some inconsistency in the preload logging and adjusted the corresponding tests.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 9014ec21
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9014ec219423a83cf1fb63c496b86fca05c40a8f
Stats:     319 lines in 27 files changed: 207 ins; 18 del; 94 mod

8366973: [lworld] Deopt/recompilation cycle due to call to method with unloaded return type

-------------

PR: https://git.openjdk.org/valhalla/pull/1554

From pchilanomate at openjdk.org  Tue Sep  9 15:13:31 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 9 Sep 2025 15:13:31 GMT
Subject: [lworld] RFR: 8336845: [lworld] Virtual threads don't support the
 value class calling convention
Message-ID: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>

Please review the following patch which adds virtual thread support for the value class calling convention. Most of the changes are needed to handle extended frames, i.e c1 or c2 frames that use more stack space for arguments than the stack space allocated by the caller. These include changes in freeze and thaw code, plus changes in the stackChunk walking code where we now need a similar repair of the caller sp as in the current sender code. In this case though, we only adjust _unextended_sp and keep the value of _sp. This is because frames are walked without a full RegisterMap, but we still need to be able to access the saved fp in the callee for gc purposes. The remaining changes deal with saving and restoring the extra return registers when calling thaw.

Thanks to Tobias for working on the initial changes and for providing the very useful new test TestVirtualThreads.java, included in this PR, which has been great for catching many bugs. I also run the changes with the valhalla-comp-stress job in mach5. It uncovered a couple of extra failures in TestVirtualThreads.java, but I was able to reproduce them with platform threads as well (8367151 and 8367258). I also added extra testing for value classes in existing test Fuzz.java which has proven very useful too.

Thanks,
Patricio

-------------

Commit messages:
 - v1

Changes: https://git.openjdk.org/valhalla/pull/1556/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1556&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336845
  Stats: 1443 lines in 25 files changed: 1304 ins; 57 del; 82 mod
  Patch: https://git.openjdk.org/valhalla/pull/1556.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1556/head:pull/1556

PR: https://git.openjdk.org/valhalla/pull/1556

From coleenp at openjdk.org  Tue Sep  9 19:16:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 9 Sep 2025 19:16:53 GMT
Subject: [lworld] RFR: 8366794: [lworld]
 "assert(!is_null(v)) failed: narrow klass value can never be zero" with -Xint
 and COH
Message-ID: <07AaEPdmd3tVznvsBKjKUqUBxMcN0nzjGNXrSiEzm8Y=.07982f55-4fe4-4e09-9a0e-faf2fc0af4ee@github.com>

The oop_size() function can't get the Klass from the oop with UseCompactObjectHeaders because there's some GC code that moves the klass out of the markWord somewhere.  Pass layout_helper() from the already fetched klass instead and disable the assert, like objArrayKlass::oop_size.
Testing with tier1-4 in progress.

-------------

Commit messages:
 - 8366794: [lworld] "assert(!is_null(v)) failed: narrow klass value can never be zero" with -Xint and COH

Changes: https://git.openjdk.org/valhalla/pull/1557/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1557&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366794
  Stats: 10 lines in 4 files changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/1557.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1557/head:pull/1557

PR: https://git.openjdk.org/valhalla/pull/1557

From fparain at openjdk.org  Tue Sep  9 20:05:56 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 9 Sep 2025 20:05:56 GMT
Subject: [lworld] RFR: 8366794: [lworld]
 "assert(!is_null(v)) failed: narrow klass value can never be zero" with -Xint
 and COH
In-Reply-To: <07AaEPdmd3tVznvsBKjKUqUBxMcN0nzjGNXrSiEzm8Y=.07982f55-4fe4-4e09-9a0e-faf2fc0af4ee@github.com>
References: <07AaEPdmd3tVznvsBKjKUqUBxMcN0nzjGNXrSiEzm8Y=.07982f55-4fe4-4e09-9a0e-faf2fc0af4ee@github.com>
Message-ID: <oN-_tVBiOKOVhZMsrZCLaNoS5-rkYzqdh75ETN4gGZE=.c4c61b05-915e-4edb-b23e-df60de7cc464@github.com>

On Tue, 9 Sep 2025 19:09:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The oop_size() function can't get the Klass from the oop with UseCompactObjectHeaders because there's some GC code that moves the klass out of the markWord somewhere.  Pass layout_helper() from the already fetched klass instead and disable the assert, like objArrayKlass::oop_size.
> Testing with tier1-4 in progress.

Marked as reviewed by fparain (Committer).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1557#pullrequestreview-3203098165

From coleenp at openjdk.org  Wed Sep 10 02:07:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 10 Sep 2025 02:07:49 GMT
Subject: [lworld] RFR: 8366794: [lworld]
 "assert(!is_null(v)) failed: narrow klass value can never be zero" with -Xint
 and COH
In-Reply-To: <07AaEPdmd3tVznvsBKjKUqUBxMcN0nzjGNXrSiEzm8Y=.07982f55-4fe4-4e09-9a0e-faf2fc0af4ee@github.com>
References: <07AaEPdmd3tVznvsBKjKUqUBxMcN0nzjGNXrSiEzm8Y=.07982f55-4fe4-4e09-9a0e-faf2fc0af4ee@github.com>
Message-ID: <V40ABFaXJ2gl4mTFd-zGa0SEiUPpnc4KKryz3KZnzvU=.4a56af1b-14a0-4f79-a532-5392768c0005@github.com>

On Tue, 9 Sep 2025 19:09:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The oop_size() function can't get the Klass from the oop with UseCompactObjectHeaders because there's some GC code that moves the klass out of the markWord somewhere.  Pass layout_helper() from the already fetched klass instead and disable the assert, like objArrayKlass::oop_size.
> Testing with tier1-4 in progress.

Thanks Fred.  Testing done and greenish.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1557#issuecomment-3272931735

From coleenp at openjdk.org  Wed Sep 10 02:07:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 10 Sep 2025 02:07:50 GMT
Subject: [lworld] Integrated: 8366794: [lworld]
 "assert(!is_null(v)) failed: narrow klass value can never be zero" with -Xint
 and COH
In-Reply-To: <07AaEPdmd3tVznvsBKjKUqUBxMcN0nzjGNXrSiEzm8Y=.07982f55-4fe4-4e09-9a0e-faf2fc0af4ee@github.com>
References: <07AaEPdmd3tVznvsBKjKUqUBxMcN0nzjGNXrSiEzm8Y=.07982f55-4fe4-4e09-9a0e-faf2fc0af4ee@github.com>
Message-ID: <eHpF0M3uZGmlbKVfBXhjToAfVU94t9DIiksuw09VDK4=.4f851784-1577-4149-be54-7ff2a63d5bcc@github.com>

On Tue, 9 Sep 2025 19:09:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The oop_size() function can't get the Klass from the oop with UseCompactObjectHeaders because there's some GC code that moves the klass out of the markWord somewhere.  Pass layout_helper() from the already fetched klass instead and disable the assert, like objArrayKlass::oop_size.
> Testing with tier1-4 in progress.

This pull request has now been integrated.

Changeset: 0817750d
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0817750d434463a606523ac03b5461802f0328e1
Stats:     10 lines in 4 files changed: 4 ins; 0 del; 6 mod

8366794: [lworld] "assert(!is_null(v)) failed: narrow klass value can never be zero" with -Xint and COH

Reviewed-by: fparain

-------------

PR: https://git.openjdk.org/valhalla/pull/1557

From thartmann at openjdk.org  Wed Sep 10 05:52:41 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 10 Sep 2025 05:52:41 GMT
Subject: [lworld] RFR: 8336845: [lworld] Virtual threads don't support the
 value class calling convention
In-Reply-To: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
References: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
Message-ID: <ZLgVx_2wnk3gvg_sAemwdt7uh8ivE8y5p9i106qFh4Q=.9288046c-bc26-4b09-8516-93392b4c016a@github.com>

On Tue, 9 Sep 2025 12:50:49 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following patch which adds virtual thread support for the value class calling convention. Most of the changes are needed to handle extended frames, i.e c1 or c2 frames that use more stack space for arguments than the stack space allocated by the caller. These include changes in freeze and thaw code, plus changes in the stackChunk walking code where we now need a similar repair of the caller sp as in the current sender code. In this case though, we only adjust _unextended_sp and keep the value of _sp. This is because frames are walked without a full RegisterMap, but we still need to be able to access the saved fp in the callee for gc purposes. The remaining changes deal with saving and restoring the extra return registers when calling thaw.
> 
> Thanks to Tobias for working on the initial changes and for providing the very useful new test TestVirtualThreads.java, included in this PR, which has been great for catching many bugs. I also run the changes with the valhalla-comp-stress job in mach5. It uncovered a couple of extra failures in TestVirtualThreads.java, but I was able to reproduce them with platform threads as well (8367151 and 8367258). I also added extra testing for value classes in existing test Fuzz.java which has proven very useful too.
> 
> Thanks,
> Patricio

I'm not an expert in this code but the changes look all good to me. I know this was a lot of effort, great work Patricio!

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1556#pullrequestreview-3204518318

From mchevalier at openjdk.org  Wed Sep 10 06:55:31 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 10 Sep 2025 06:55:31 GMT
Subject: [lworld] RFR: 8367263: [lworld] fix
 compiler/valhalla/inlinetypes/TestIntrinsics.java after current merges of
 JDK-8352737 and JDK-8366705
Message-ID: <QbbS1a2Kbx0Y0qU4Ooxzd-9utOpPU_x2JpXhFs73TEY=.bacb51aa-c2e2-4c22-a5d9-8f87e6f0d8a2@github.com>

TEST64_LAYOUT = U.arrayLayout(TEST64_ARRAY.getClass());

is not correct anymore since [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705) as the layout is no longer a class property, but an instance property (if I understood right)

Weirdly enough, code like
 ```
U.arrayBaseOffset(TEST64_ARRAY.getClass());
U.arrayIndexScale(TEST64_ARRAY.getClass());

got also their `.getClass()` removed in [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705):
https://github.com/openjdk/valhalla/blob/0817750d434463a606523ac03b5461802f0328e1/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java#L650-L654
but there the compiler wasn't yelling at me. Is it overloaded and it works with instance or class, and the instance overload will just query the class. Not sure... I'm still removing it!

Thanks,
Marc

-------------

Commit messages:
 - Adapt assert for -XX:-PreloadClasses
 - Fix after JDK-8366705

Changes: https://git.openjdk.org/valhalla/pull/1559/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1559&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367263
  Stats: 16 lines in 1 file changed: 1 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/valhalla/pull/1559.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1559/head:pull/1559

PR: https://git.openjdk.org/valhalla/pull/1559

From thartmann at openjdk.org  Wed Sep 10 07:03:48 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 10 Sep 2025 07:03:48 GMT
Subject: [lworld] RFR: 8367263: [lworld] fix
 compiler/valhalla/inlinetypes/TestIntrinsics.java after current merges of
 JDK-8352737 and JDK-8366705
In-Reply-To: <QbbS1a2Kbx0Y0qU4Ooxzd-9utOpPU_x2JpXhFs73TEY=.bacb51aa-c2e2-4c22-a5d9-8f87e6f0d8a2@github.com>
References: <QbbS1a2Kbx0Y0qU4Ooxzd-9utOpPU_x2JpXhFs73TEY=.bacb51aa-c2e2-4c22-a5d9-8f87e6f0d8a2@github.com>
Message-ID: <hF4WVF2MoWpwlMgTNhnvczqC2Dy3VGF3ylE_wffpqLo=.36347095-1fe2-4f34-8f96-807a2ded200d@github.com>

On Wed, 10 Sep 2025 06:46:08 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> TEST64_LAYOUT = U.arrayLayout(TEST64_ARRAY.getClass());
> 
> is not correct anymore since [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705) as the layout is no longer a class property, but an instance property (if I understood right)
> 
> Weirdly enough, code like
>  ```
> U.arrayBaseOffset(TEST64_ARRAY.getClass());
> U.arrayIndexScale(TEST64_ARRAY.getClass());
> 
> got also their `.getClass()` removed in [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705):
> https://github.com/openjdk/valhalla/blob/0817750d434463a606523ac03b5461802f0328e1/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java#L650-L654
> but there the compiler wasn't yelling at me. Is it overloaded and it works with instance or class, and the instance overload will just query the class. Not sure... I'm still removing it!
> 
> Thanks,
> Marc

Looks good to me. Thanks for quickly fixing this!

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1559#pullrequestreview-3204699778

From dsimms at openjdk.org  Wed Sep 10 07:06:42 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 10 Sep 2025 07:06:42 GMT
Subject: [lworld] RFR: 8367263: [lworld] fix
 compiler/valhalla/inlinetypes/TestIntrinsics.java after current merges of
 JDK-8352737 and JDK-8366705
In-Reply-To: <QbbS1a2Kbx0Y0qU4Ooxzd-9utOpPU_x2JpXhFs73TEY=.bacb51aa-c2e2-4c22-a5d9-8f87e6f0d8a2@github.com>
References: <QbbS1a2Kbx0Y0qU4Ooxzd-9utOpPU_x2JpXhFs73TEY=.bacb51aa-c2e2-4c22-a5d9-8f87e6f0d8a2@github.com>
Message-ID: <k-86AKwrWgFrY_ZBJc9QgU8P1JJuDo3arU5sLKU73GU=.83d1243d-5701-4759-bd77-035379619d01@github.com>

On Wed, 10 Sep 2025 06:46:08 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> TEST64_LAYOUT = U.arrayLayout(TEST64_ARRAY.getClass());
> 
> is not correct anymore since [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705) as the layout is no longer a class property, but an instance property (if I understood right)
> 
> Weirdly enough, code like
>  ```
> U.arrayBaseOffset(TEST64_ARRAY.getClass());
> U.arrayIndexScale(TEST64_ARRAY.getClass());
> 
> got also their `.getClass()` removed in [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705):
> https://github.com/openjdk/valhalla/blob/0817750d434463a606523ac03b5461802f0328e1/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java#L650-L654
> but there the compiler wasn't yelling at me. Is it overloaded and it works with instance or class, and the instance overload will just query the class. Not sure... I'm still removing it!
> 
> Thanks,
> Marc

Thank you !

-------------

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1559#pullrequestreview-3204706961

From mchevalier at openjdk.org  Wed Sep 10 07:15:46 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 10 Sep 2025 07:15:46 GMT
Subject: [lworld] RFR: 8367263: [lworld] fix
 compiler/valhalla/inlinetypes/TestIntrinsics.java after current merges of
 JDK-8352737 and JDK-8366705
In-Reply-To: <QbbS1a2Kbx0Y0qU4Ooxzd-9utOpPU_x2JpXhFs73TEY=.bacb51aa-c2e2-4c22-a5d9-8f87e6f0d8a2@github.com>
References: <QbbS1a2Kbx0Y0qU4Ooxzd-9utOpPU_x2JpXhFs73TEY=.bacb51aa-c2e2-4c22-a5d9-8f87e6f0d8a2@github.com>
Message-ID: <cdtfI3g4oiet2layMaHe1kYU27wdV7UyApVy7BhOqzU=.117b698d-5ac8-4c28-82f6-9119a8f5ded9@github.com>

On Wed, 10 Sep 2025 06:46:08 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> TEST64_LAYOUT = U.arrayLayout(TEST64_ARRAY.getClass());
> 
> is not correct anymore since [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705) as the layout is no longer a class property, but an instance property (if I understood right)
> 
> Weirdly enough, code like
>  ```
> U.arrayBaseOffset(TEST64_ARRAY.getClass());
> U.arrayIndexScale(TEST64_ARRAY.getClass());
> 
> got also their `.getClass()` removed in [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705):
> https://github.com/openjdk/valhalla/blob/0817750d434463a606523ac03b5461802f0328e1/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java#L650-L654
> but there the compiler wasn't yelling at me. Is it overloaded and it works with instance or class, and the instance overload will just query the class. Not sure... I'm still removing it!
> 
> Thanks,
> Marc

Thanks @MrSimms & @TobiHartmann!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1559#issuecomment-3273618690

From mchevalier at openjdk.org  Wed Sep 10 07:15:47 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 10 Sep 2025 07:15:47 GMT
Subject: [lworld] Integrated: 8367263: [lworld] fix
 compiler/valhalla/inlinetypes/TestIntrinsics.java after current merges of
 JDK-8352737 and JDK-8366705
In-Reply-To: <QbbS1a2Kbx0Y0qU4Ooxzd-9utOpPU_x2JpXhFs73TEY=.bacb51aa-c2e2-4c22-a5d9-8f87e6f0d8a2@github.com>
References: <QbbS1a2Kbx0Y0qU4Ooxzd-9utOpPU_x2JpXhFs73TEY=.bacb51aa-c2e2-4c22-a5d9-8f87e6f0d8a2@github.com>
Message-ID: <agZ_gxhj7sl1wBJ6XzTnuEpeOxQezq_T69IF4EN52uw=.5cef3622-585b-429c-a87e-e2506bab6181@github.com>

On Wed, 10 Sep 2025 06:46:08 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> TEST64_LAYOUT = U.arrayLayout(TEST64_ARRAY.getClass());
> 
> is not correct anymore since [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705) as the layout is no longer a class property, but an instance property (if I understood right)
> 
> Weirdly enough, code like
>  ```
> U.arrayBaseOffset(TEST64_ARRAY.getClass());
> U.arrayIndexScale(TEST64_ARRAY.getClass());
> 
> got also their `.getClass()` removed in [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705):
> https://github.com/openjdk/valhalla/blob/0817750d434463a606523ac03b5461802f0328e1/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java#L650-L654
> but there the compiler wasn't yelling at me. Is it overloaded and it works with instance or class, and the instance overload will just query the class. Not sure... I'm still removing it!
> 
> Thanks,
> Marc

This pull request has now been integrated.

Changeset: 72475835
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/72475835ca100885658ba114943aaeee4a2404d9
Stats:     16 lines in 1 file changed: 1 ins; 0 del; 15 mod

8367263: [lworld] fix compiler/valhalla/inlinetypes/TestIntrinsics.java after current merges of JDK-8352737 and JDK-8366705

Reviewed-by: thartmann, dsimms

-------------

PR: https://git.openjdk.org/valhalla/pull/1559

From thartmann at openjdk.org  Wed Sep 10 07:48:46 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 10 Sep 2025 07:48:46 GMT
Subject: [lworld] RFR: 8367304: [lworld] Printing of rematerialized objects is
 broken
Message-ID: <pvobfFIStOTEmGven-5U7plSJc-2dpSrf8m6KYRa_8E=.de294348-e3c9-4212-9b4f-c47fefbfc09d@github.com>

[JDK-8367263](https://bugs.openjdk.org/browse/JDK-8367263) missed a place in `print_objects` where we need to get the refined array klass based on the properties of the rematerialized array. I did not add a regression test for this because `compiler/uncommontrap/TestDeoptOOM.java` reproduces this intermittently.

Thanks,
Tobias

-------------

Commit messages:
 - 8367304: [lworld] Printing of rematerialized objects is broken

Changes: https://git.openjdk.org/valhalla/pull/1560/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1560&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367304
  Stats: 48 lines in 1 file changed: 19 ins; 24 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/1560.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1560/head:pull/1560

PR: https://git.openjdk.org/valhalla/pull/1560

From dsimms at openjdk.org  Wed Sep 10 08:54:28 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 10 Sep 2025 08:54:28 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <qqe5uyAJE_XRCF-JSSRbo2QzPgPjw3XDhhZWioZWdi0=.67d31704-0c0d-4410-b5c6-3d1d8baef259@github.com>

Merge jdk-26+1

-------------

Commit messages:
 - Version flick
 - Merge jdk
 - 8357396: Refactor nmethod::make_not_entrant to use Enum instead of "const char*"
 - 8355746: Start of release updates for JDK 26

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1561&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1561&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/1561/files
  Stats: 2050 lines in 100 files changed: 1827 ins; 22 del; 201 mod
  Patch: https://git.openjdk.org/valhalla/pull/1561.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1561/head:pull/1561

PR: https://git.openjdk.org/valhalla/pull/1561

From thartmann at openjdk.org  Wed Sep 10 08:55:37 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 10 Sep 2025 08:55:37 GMT
Subject: [lworld] Integrated: [lworld] Problem listing
 TestClassLoaderStatsEvent.java
Message-ID: <E6OovAOcc9J--gY6rabZz7O4-TaIzEWJKjrMDFiSZAM=.999d1c8a-f127-48e0-ac7a-549704d340a7@github.com>

See [JDK-8366820](https://bugs.openjdk.org/browse/JDK-8366820).

Thanks,
Tobias

-------------

Commit messages:
 - [lworld] Problem listing TestClassLoaderStatsEvent.java

Changes: https://git.openjdk.org/valhalla/pull/1562/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1562&range=00
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1562.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1562/head:pull/1562

PR: https://git.openjdk.org/valhalla/pull/1562

From thartmann at openjdk.org  Wed Sep 10 08:55:37 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 10 Sep 2025 08:55:37 GMT
Subject: [lworld] Integrated: [lworld] Problem listing
 TestClassLoaderStatsEvent.java
In-Reply-To: <E6OovAOcc9J--gY6rabZz7O4-TaIzEWJKjrMDFiSZAM=.999d1c8a-f127-48e0-ac7a-549704d340a7@github.com>
References: <E6OovAOcc9J--gY6rabZz7O4-TaIzEWJKjrMDFiSZAM=.999d1c8a-f127-48e0-ac7a-549704d340a7@github.com>
Message-ID: <4IHKgti1etLUavhFFdOnWEmcHpPzEadafYCwvMCWQfM=.18a085cf-a90a-4ee8-bd51-490d90d0e618@github.com>

On Wed, 10 Sep 2025 08:49:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> See [JDK-8366820](https://bugs.openjdk.org/browse/JDK-8366820).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 2796f351
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2796f3519f067abe901b8f9b8c427973998ee25d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

[lworld] Problem listing TestClassLoaderStatsEvent.java

-------------

PR: https://git.openjdk.org/valhalla/pull/1562

From dsimms at openjdk.org  Wed Sep 10 09:00:33 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 10 Sep 2025 09:00:33 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <qqe5uyAJE_XRCF-JSSRbo2QzPgPjw3XDhhZWioZWdi0=.67d31704-0c0d-4410-b5c6-3d1d8baef259@github.com>
References: <qqe5uyAJE_XRCF-JSSRbo2QzPgPjw3XDhhZWioZWdi0=.67d31704-0c0d-4410-b5c6-3d1d8baef259@github.com>
Message-ID: <PWTT10grA2BZ8f7YNRtdCld93mdHhk8Wiit8khQjJj0=.65f65628-1151-45a9-81d0-ff7552666dee@github.com>

On Wed, 10 Sep 2025 08:46:21 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+1

This pull request has now been integrated.

Changeset: a80315a4
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a80315a49c6a35903ccf214132968659452c916f
Stats:     2050 lines in 100 files changed: 1827 ins; 22 del; 201 mod

Merge jdk

Merge jdk-26+1

-------------

PR: https://git.openjdk.org/valhalla/pull/1561

From dsimms at openjdk.org  Wed Sep 10 09:03:40 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 10 Sep 2025 09:03:40 GMT
Subject: [lworld] RFR: 8327257: [lworld] Tests are needed to stress class
 preloading with concurrent class loadings [v2]
In-Reply-To: <86FkwRT5rMpdT1XAH2IfkrFubrubs0L8nWl4pnNaxYg=.2a56aaa2-ce15-4deb-ae7e-9cddd3ac7d0e@github.com>
References: <5BhLWx8JG5TtyJ-CueXpUfFq_QCWg5x_9oDaPJNr4Gw=.d1f668f7-ff8a-4307-b1d2-294a7f14fbbf@github.com>
 <86FkwRT5rMpdT1XAH2IfkrFubrubs0L8nWl4pnNaxYg=.2a56aaa2-ce15-4deb-ae7e-9cddd3ac7d0e@github.com>
Message-ID: <flz-zOr8KspQnqUpwi4K5Wc77rXz6wrUNaRvMLMXq8g=.32faca7f-54d7-40e8-8a83-a5366c37bf2a@github.com>

On Tue, 9 Sep 2025 11:29:28 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This change strengthens our Valhalla-specific classloading test suite and guards against regressions. An overview of the new changes is as follows:
>> * `BigClassTreeClassLoader`: a utility classloader that generates huge class trees on the fly. The idea is to generate a tree that is deep (lots of parent classes) and very wide (classes have lots of value classes as fields, which have value class fields, etc.). 
>> * `ConcurrentClassLoadingTest` strains the classloading and preloading by classloading many classes at the same time.
>> * `LoadableDescriptorsTest` ensures that the `LoadableDescriptors` attribute can handle unexpected data. This may need to be revisited if https://bugs.openjdk.org/browse/JDK-8366907 changes the semantics.
>> * `PreLoadCircularityTest` ensures that preloading happens even when there are cycles (via inheritance, fields, and both). 
>> * `PreLoadDoesNotInitTest` is a regression test that ensures preloading will not initialize a class.
>> * `PreLoadFailuresDoNotImpactApplicationTest` ensures that a flaky classloader during preloading will not cause crashes as long as the classloader can find the class when it is actually used.
>> * `ValueClassInheritanceTest` is a regression test that ensures one cannot have a value class inherit from something that's not an abstract value class.
>
> Paul H?bner has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Adjust stress rate.
>  - Re-enable test.
>  - Increase concurrent loading iterations.

Sorry I pushed the jdk-26+1 merge, meaning you'll need to flick major version (69 to 70).

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1552#issuecomment-3274005318

From thartmann at openjdk.org  Wed Sep 10 09:03:47 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 10 Sep 2025 09:03:47 GMT
Subject: [lworld] Integrated: 8367304: [lworld] Printing of rematerialized
 objects is broken
In-Reply-To: <pvobfFIStOTEmGven-5U7plSJc-2dpSrf8m6KYRa_8E=.de294348-e3c9-4212-9b4f-c47fefbfc09d@github.com>
References: <pvobfFIStOTEmGven-5U7plSJc-2dpSrf8m6KYRa_8E=.de294348-e3c9-4212-9b4f-c47fefbfc09d@github.com>
Message-ID: <gGXDoU1P7rmRBAIm0HKHHLzaKgzQM4yOJWYepc3hYSo=.a08ed8c3-7801-4965-a310-3ddeacfdffd4@github.com>

On Wed, 10 Sep 2025 07:41:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> [JDK-8367263](https://bugs.openjdk.org/browse/JDK-8367263) missed a place in `print_objects` where we need to get the refined array klass based on the properties of the rematerialized array. I did not add a regression test for this because `compiler/uncommontrap/TestDeoptOOM.java` reproduces this intermittently.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: d3ec2279
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d3ec227977eb84e85f460c1c33b951a89877cad1
Stats:     48 lines in 1 file changed: 19 ins; 24 del; 5 mod

8367304: [lworld] Printing of rematerialized objects is broken

-------------

PR: https://git.openjdk.org/valhalla/pull/1560

From thartmann at openjdk.org  Wed Sep 10 09:23:11 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 10 Sep 2025 09:23:11 GMT
Subject: [lworld] RFR: [lworld] Problem listing tests failing due to
 JDK-8366806
Message-ID: <zbEdemSF9dYtqbSRkcrbUsnF5kEYFykwgVrbaUrPMEY=.af1a8cf6-dd53-4aa0-9ad1-00c50876335a@github.com>

Problem listing tests affected by [JDK-8366806](https://bugs.openjdk.org/browse/JDK-8366806) to get our CI clean.

Thanks,
Tobias

-------------

Commit messages:
 - [lworld] Problem listing tests failing due to JDK-8366806

Changes: https://git.openjdk.org/valhalla/pull/1563/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1563&range=00
  Stats: 25 lines in 2 files changed: 25 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1563.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1563/head:pull/1563

PR: https://git.openjdk.org/valhalla/pull/1563

From phubner at openjdk.org  Wed Sep 10 10:28:57 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 10 Sep 2025 10:28:57 GMT
Subject: [lworld] RFR: 8327257: [lworld] Tests are needed to stress class
 preloading with concurrent class loadings [v3]
In-Reply-To: <5BhLWx8JG5TtyJ-CueXpUfFq_QCWg5x_9oDaPJNr4Gw=.d1f668f7-ff8a-4307-b1d2-294a7f14fbbf@github.com>
References: <5BhLWx8JG5TtyJ-CueXpUfFq_QCWg5x_9oDaPJNr4Gw=.d1f668f7-ff8a-4307-b1d2-294a7f14fbbf@github.com>
Message-ID: <4ccPqahNZIukkwdZ5gAC5J15ORN6TCp5YN2VXDxQJpM=.c2832ac5-2d8b-41df-aa78-855adf84ec03@github.com>

> Hi all,
> 
> This change strengthens our Valhalla-specific classloading test suite and guards against regressions. An overview of the new changes is as follows:
> * `BigClassTreeClassLoader`: a utility classloader that generates huge class trees on the fly. The idea is to generate a tree that is deep (lots of parent classes) and very wide (classes have lots of value classes as fields, which have value class fields, etc.). 
> * `ConcurrentClassLoadingTest` strains the classloading and preloading by classloading many classes at the same time.
> * `LoadableDescriptorsTest` ensures that the `LoadableDescriptors` attribute can handle unexpected data. This may need to be revisited if https://bugs.openjdk.org/browse/JDK-8366907 changes the semantics.
> * `PreLoadCircularityTest` ensures that preloading happens even when there are cycles (via inheritance, fields, and both). 
> * `PreLoadDoesNotInitTest` is a regression test that ensures preloading will not initialize a class.
> * `PreLoadFailuresDoNotImpactApplicationTest` ensures that a flaky classloader during preloading will not cause crashes as long as the classloader can find the class when it is actually used.
> * `ValueClassInheritanceTest` is a regression test that ensures one cannot have a value class inherit from something that's not an abstract value class.

Paul H?bner 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 12 additional commits since the last revision:

 - Update tests to use JDK 26.
 - Merge branch 'lworld' into JDK-8327257
 - Adjust stress rate.
 - Re-enable test.
 - Increase concurrent loading iterations.
 - Reindent.
 - More reviewer comments.
 - Incorporate feedback.
 - Move to JUnit and refactor.
 - Concurrent non-deadlocking huge tree test.
 - ... and 2 more: https://git.openjdk.org/valhalla/compare/d2cb02bb...d02d931b

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1552/files
  - new: https://git.openjdk.org/valhalla/pull/1552/files/9df98b53..d02d931b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1552&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1552&range=01-02

  Stats: 7228 lines in 277 files changed: 5061 ins; 1103 del; 1064 mod
  Patch: https://git.openjdk.org/valhalla/pull/1552.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1552/head:pull/1552

PR: https://git.openjdk.org/valhalla/pull/1552

From thartmann at openjdk.org  Wed Sep 10 10:49:42 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 10 Sep 2025 10:49:42 GMT
Subject: [lworld] RFR: [lworld] Problem listing tests failing due to
 JDK-8366806 [v2]
In-Reply-To: <zbEdemSF9dYtqbSRkcrbUsnF5kEYFykwgVrbaUrPMEY=.af1a8cf6-dd53-4aa0-9ad1-00c50876335a@github.com>
References: <zbEdemSF9dYtqbSRkcrbUsnF5kEYFykwgVrbaUrPMEY=.af1a8cf6-dd53-4aa0-9ad1-00c50876335a@github.com>
Message-ID: <Sg8MHYWGkKDnbvfEFib45f2JO0qkZ4OMqJSyqop55mk=.5d24d3c0-fae0-4eea-a656-9e4218a44593@github.com>

> Problem listing tests affected by [JDK-8366806](https://bugs.openjdk.org/browse/JDK-8366806) to get our CI clean.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Missed a few

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1563/files
  - new: https://git.openjdk.org/valhalla/pull/1563/files/93c1f245..481f140e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1563&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1563&range=00-01

  Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1563.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1563/head:pull/1563

PR: https://git.openjdk.org/valhalla/pull/1563

From dsimms at openjdk.org  Wed Sep 10 11:02:17 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 10 Sep 2025 11:02:17 GMT
Subject: [lworld] RFR: [lworld] Problem listing tests failing due to
 JDK-8366806 [v2]
In-Reply-To: <Sg8MHYWGkKDnbvfEFib45f2JO0qkZ4OMqJSyqop55mk=.5d24d3c0-fae0-4eea-a656-9e4218a44593@github.com>
References: <zbEdemSF9dYtqbSRkcrbUsnF5kEYFykwgVrbaUrPMEY=.af1a8cf6-dd53-4aa0-9ad1-00c50876335a@github.com>
 <Sg8MHYWGkKDnbvfEFib45f2JO0qkZ4OMqJSyqop55mk=.5d24d3c0-fae0-4eea-a656-9e4218a44593@github.com>
Message-ID: <q3wSNPbw8P801iQcFaA-GmtoT1g_gSL8HaykBaUQMxw=.b3beb774-1ec1-4188-ac93-70fc32e7c1f7@github.com>

On Wed, 10 Sep 2025 10:49:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Problem listing tests affected by [JDK-8366806](https://bugs.openjdk.org/browse/JDK-8366806) to get our CI clean.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed a few

Marked as reviewed by dsimms (Committer).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1563#pullrequestreview-3205616129

From thartmann at openjdk.org  Wed Sep 10 11:24:52 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 10 Sep 2025 11:24:52 GMT
Subject: [lworld] RFR: [lworld] Problem listing tests failing due to
 JDK-8366806 [v2]
In-Reply-To: <Sg8MHYWGkKDnbvfEFib45f2JO0qkZ4OMqJSyqop55mk=.5d24d3c0-fae0-4eea-a656-9e4218a44593@github.com>
References: <zbEdemSF9dYtqbSRkcrbUsnF5kEYFykwgVrbaUrPMEY=.af1a8cf6-dd53-4aa0-9ad1-00c50876335a@github.com>
 <Sg8MHYWGkKDnbvfEFib45f2JO0qkZ4OMqJSyqop55mk=.5d24d3c0-fae0-4eea-a656-9e4218a44593@github.com>
Message-ID: <Bqs7_xD1MSFKl2O8vnY8TUN_XmsL6qVvQf4l6ol5Ctw=.9885544e-5f1f-427b-b51a-03b251138e34@github.com>

On Wed, 10 Sep 2025 10:49:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Problem listing tests affected by [JDK-8366806](https://bugs.openjdk.org/browse/JDK-8366806) to get our CI clean.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed a few

Thanks for the review! Waiting for testing to complete ...

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1563#issuecomment-3274515986

From thartmann at openjdk.org  Wed Sep 10 11:46:10 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 10 Sep 2025 11:46:10 GMT
Subject: [lworld] Integrated: [lworld] Problem listing tests failing due to
 JDK-8366806
In-Reply-To: <zbEdemSF9dYtqbSRkcrbUsnF5kEYFykwgVrbaUrPMEY=.af1a8cf6-dd53-4aa0-9ad1-00c50876335a@github.com>
References: <zbEdemSF9dYtqbSRkcrbUsnF5kEYFykwgVrbaUrPMEY=.af1a8cf6-dd53-4aa0-9ad1-00c50876335a@github.com>
Message-ID: <_1EwTLtHhZTJ6RfBSxB4jlGbzN9bLf_251Uodd_7cyU=.f8c650ce-2f47-4801-a446-3ab1e37422c0@github.com>

On Wed, 10 Sep 2025 09:16:51 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Problem listing tests affected by [JDK-8366806](https://bugs.openjdk.org/browse/JDK-8366806) to get our CI clean.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 320b11cd
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/320b11cda1bf7ca1c273d0d0ac6ad18474b5a174
Stats:     33 lines in 2 files changed: 33 ins; 0 del; 0 mod

[lworld] Problem listing tests failing due to JDK-8366806

Reviewed-by: dsimms

-------------

PR: https://git.openjdk.org/valhalla/pull/1563

From dsimms at openjdk.org  Wed Sep 10 12:09:15 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 10 Sep 2025 12:09:15 GMT
Subject: [lworld] RFR: 8327257: [lworld] Tests are needed to stress class
 preloading with concurrent class loadings [v3]
In-Reply-To: <4ccPqahNZIukkwdZ5gAC5J15ORN6TCp5YN2VXDxQJpM=.c2832ac5-2d8b-41df-aa78-855adf84ec03@github.com>
References: <5BhLWx8JG5TtyJ-CueXpUfFq_QCWg5x_9oDaPJNr4Gw=.d1f668f7-ff8a-4307-b1d2-294a7f14fbbf@github.com>
 <4ccPqahNZIukkwdZ5gAC5J15ORN6TCp5YN2VXDxQJpM=.c2832ac5-2d8b-41df-aa78-855adf84ec03@github.com>
Message-ID: <X39tb64CDn6VcC5JaBLS_xApbMD4xlNcYmmdFn3pjCU=.d4a07a3d-ff34-4516-957d-71edd8025acc@github.com>

On Wed, 10 Sep 2025 10:28:57 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This change strengthens our Valhalla-specific classloading test suite and guards against regressions. An overview of the new changes is as follows:
>> * `BigClassTreeClassLoader`: a utility classloader that generates huge class trees on the fly. The idea is to generate a tree that is deep (lots of parent classes) and very wide (classes have lots of value classes as fields, which have value class fields, etc.). 
>> * `ConcurrentClassLoadingTest` strains the classloading and preloading by classloading many classes at the same time.
>> * `LoadableDescriptorsTest` ensures that the `LoadableDescriptors` attribute can handle unexpected data. This may need to be revisited if https://bugs.openjdk.org/browse/JDK-8366907 changes the semantics.
>> * `PreLoadCircularityTest` ensures that preloading happens even when there are cycles (via inheritance, fields, and both). 
>> * `PreLoadDoesNotInitTest` is a regression test that ensures preloading will not initialize a class.
>> * `PreLoadFailuresDoNotImpactApplicationTest` ensures that a flaky classloader during preloading will not cause crashes as long as the classloader can find the class when it is actually used.
>> * `ValueClassInheritanceTest` is a regression test that ensures one cannot have a value class inherit from something that's not an abstract value class.
>
> Paul H?bner 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 12 additional commits since the last revision:
> 
>  - Update tests to use JDK 26.
>  - Merge branch 'lworld' into JDK-8327257
>  - Adjust stress rate.
>  - Re-enable test.
>  - Increase concurrent loading iterations.
>  - Reindent.
>  - More reviewer comments.
>  - Incorporate feedback.
>  - Move to JUnit and refactor.
>  - Concurrent non-deadlocking huge tree test.
>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/7f7fbe3b...d02d931b

Looks good

-------------

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1552#pullrequestreview-3205841516

From thartmann at openjdk.org  Wed Sep 10 13:13:00 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 10 Sep 2025 13:13:00 GMT
Subject: [lworld] Integrated: [lworld] One more workaround for JDK-8366668
Message-ID: <Ez0YTK5_20AU-D_3vN9PWkLT6PxlOM8bSLRlg94zwkM=.e7abc5c4-7fcd-4226-b6fe-0e20faec7c18@github.com>

Disabling one more test, similar to `test119`, that will be fixed by [JDK-8366668](https://bugs.openjdk.org/browse/JDK-8366668).

Thanks,
Tobias

-------------

Commit messages:
 - [lworld] One more workaround for JDK-8366668

Changes: https://git.openjdk.org/valhalla/pull/1564/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1564&range=00
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1564.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1564/head:pull/1564

PR: https://git.openjdk.org/valhalla/pull/1564

From thartmann at openjdk.org  Wed Sep 10 13:13:00 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 10 Sep 2025 13:13:00 GMT
Subject: [lworld] Integrated: [lworld] One more workaround for JDK-8366668
In-Reply-To: <Ez0YTK5_20AU-D_3vN9PWkLT6PxlOM8bSLRlg94zwkM=.e7abc5c4-7fcd-4226-b6fe-0e20faec7c18@github.com>
References: <Ez0YTK5_20AU-D_3vN9PWkLT6PxlOM8bSLRlg94zwkM=.e7abc5c4-7fcd-4226-b6fe-0e20faec7c18@github.com>
Message-ID: <wTKk8WcKGyhUziUL9FMA2W6TTsVOKbqqieK6TLCqM_M=.595a9975-a62d-434d-8924-6396311514db@github.com>

On Wed, 10 Sep 2025 13:01:40 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Disabling one more test, similar to `test119`, that will be fixed by [JDK-8366668](https://bugs.openjdk.org/browse/JDK-8366668).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 3e84ee6f
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3e84ee6fef82d4ccd62ba7cf077b61c074366171
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

[lworld] One more workaround for JDK-8366668

-------------

PR: https://git.openjdk.org/valhalla/pull/1564

From scolebourne at joda.org  Wed Sep 10 14:52:33 2025
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 10 Sep 2025 15:52:33 +0100
Subject: Method names for Valhalla value types
Message-ID: <CACzrW9Cg4+WB+-yKtgxLSePP+um84Hh4qsJP6OrQ2+HTxCmd0Q@mail.gmail.com>

At some point, hopefully relatively soon, we will see new value types
appear, especially numeric ones. I'd like to talk about the method
naming conventions that should be used for these classes, given that
(a) the classes are immutable, (b) they are likely to be well used,
and (c) the methods will be unaffected by operator overloading AFAICT.

Broadly speaking, there are two naming conventions for immutable
classes in Java (JDK and beyond):

1) Basic - add/subtract/multiply/divide/negate
Used by BigDecimal/BigInteger

2) Past Tense - plus/minus/multipliedBy/dividedBy/negated
Used by Java-Time

It won't surprise anyone if I say I prefer option 2 - I also think it
has better readability:

1) var result = a.add(b).divide(c.subtract(d));
2) var result = a.plus(b).dividedBy(c.minus(d));

Away from numeric methods, the classic example is sort() vs sorted().
sort() is generally assumed to mutate the collection, whereas sorted()
would be assumed to return a sorted version of the original.

>From what I can see, the prototype Float16 class is using option 1. Is
this a firm decision?

thanks
Stephen

From phubner at openjdk.org  Wed Sep 10 15:25:48 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 10 Sep 2025 15:25:48 GMT
Subject: [lworld] RFR: 8327257: [lworld] Tests are needed to stress class
 preloading with concurrent class loadings [v3]
In-Reply-To: <4ccPqahNZIukkwdZ5gAC5J15ORN6TCp5YN2VXDxQJpM=.c2832ac5-2d8b-41df-aa78-855adf84ec03@github.com>
References: <5BhLWx8JG5TtyJ-CueXpUfFq_QCWg5x_9oDaPJNr4Gw=.d1f668f7-ff8a-4307-b1d2-294a7f14fbbf@github.com>
 <4ccPqahNZIukkwdZ5gAC5J15ORN6TCp5YN2VXDxQJpM=.c2832ac5-2d8b-41df-aa78-855adf84ec03@github.com>
Message-ID: <xlh5RMXK4TCM_QhqPBrZyK80Y-0hx3mTycaA1Lyff98=.1f4fb5d9-cd29-43b3-b4b5-9a1b90c51072@github.com>

On Wed, 10 Sep 2025 10:28:57 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This change strengthens our Valhalla-specific classloading test suite and guards against regressions. An overview of the new changes is as follows:
>> * `BigClassTreeClassLoader`: a utility classloader that generates huge class trees on the fly. The idea is to generate a tree that is deep (lots of parent classes) and very wide (classes have lots of value classes as fields, which have value class fields, etc.). 
>> * `ConcurrentClassLoadingTest` strains the classloading and preloading by classloading many classes at the same time.
>> * `LoadableDescriptorsTest` ensures that the `LoadableDescriptors` attribute can handle unexpected data. This may need to be revisited if https://bugs.openjdk.org/browse/JDK-8366907 changes the semantics.
>> * `PreLoadCircularityTest` ensures that preloading happens even when there are cycles (via inheritance, fields, and both). 
>> * `PreLoadDoesNotInitTest` is a regression test that ensures preloading will not initialize a class.
>> * `PreLoadFailuresDoNotImpactApplicationTest` ensures that a flaky classloader during preloading will not cause crashes as long as the classloader can find the class when it is actually used.
>> * `ValueClassInheritanceTest` is a regression test that ensures one cannot have a value class inherit from something that's not an abstract value class.
>
> Paul H?bner 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 12 additional commits since the last revision:
> 
>  - Update tests to use JDK 26.
>  - Merge branch 'lworld' into JDK-8327257
>  - Adjust stress rate.
>  - Re-enable test.
>  - Increase concurrent loading iterations.
>  - Reindent.
>  - More reviewer comments.
>  - Incorporate feedback.
>  - Move to JUnit and refactor.
>  - Concurrent non-deadlocking huge tree test.
>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/dea11177...d02d931b

Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1552#issuecomment-3275452081

From duke at openjdk.org  Wed Sep 10 15:25:49 2025
From: duke at openjdk.org (duke)
Date: Wed, 10 Sep 2025 15:25:49 GMT
Subject: [lworld] RFR: 8327257: [lworld] Tests are needed to stress class
 preloading with concurrent class loadings [v3]
In-Reply-To: <4ccPqahNZIukkwdZ5gAC5J15ORN6TCp5YN2VXDxQJpM=.c2832ac5-2d8b-41df-aa78-855adf84ec03@github.com>
References: <5BhLWx8JG5TtyJ-CueXpUfFq_QCWg5x_9oDaPJNr4Gw=.d1f668f7-ff8a-4307-b1d2-294a7f14fbbf@github.com>
 <4ccPqahNZIukkwdZ5gAC5J15ORN6TCp5YN2VXDxQJpM=.c2832ac5-2d8b-41df-aa78-855adf84ec03@github.com>
Message-ID: <MooZsPBznLMnZjUOVNthGqfNbg8qVUMFhlMoqrYNPzk=.25f6c546-b4f8-49de-a3d1-1f19231c4184@github.com>

On Wed, 10 Sep 2025 10:28:57 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This change strengthens our Valhalla-specific classloading test suite and guards against regressions. An overview of the new changes is as follows:
>> * `BigClassTreeClassLoader`: a utility classloader that generates huge class trees on the fly. The idea is to generate a tree that is deep (lots of parent classes) and very wide (classes have lots of value classes as fields, which have value class fields, etc.). 
>> * `ConcurrentClassLoadingTest` strains the classloading and preloading by classloading many classes at the same time.
>> * `LoadableDescriptorsTest` ensures that the `LoadableDescriptors` attribute can handle unexpected data. This may need to be revisited if https://bugs.openjdk.org/browse/JDK-8366907 changes the semantics.
>> * `PreLoadCircularityTest` ensures that preloading happens even when there are cycles (via inheritance, fields, and both). 
>> * `PreLoadDoesNotInitTest` is a regression test that ensures preloading will not initialize a class.
>> * `PreLoadFailuresDoNotImpactApplicationTest` ensures that a flaky classloader during preloading will not cause crashes as long as the classloader can find the class when it is actually used.
>> * `ValueClassInheritanceTest` is a regression test that ensures one cannot have a value class inherit from something that's not an abstract value class.
>
> Paul H?bner 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 12 additional commits since the last revision:
> 
>  - Update tests to use JDK 26.
>  - Merge branch 'lworld' into JDK-8327257
>  - Adjust stress rate.
>  - Re-enable test.
>  - Increase concurrent loading iterations.
>  - Reindent.
>  - More reviewer comments.
>  - Incorporate feedback.
>  - Move to JUnit and refactor.
>  - Concurrent non-deadlocking huge tree test.
>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/dea11177...d02d931b

@Arraying 
Your change (at version d02d931b7221c80f36df31f85763c4fb5f71678d) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1552#issuecomment-3275456428

From phubner at openjdk.org  Wed Sep 10 15:29:14 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 10 Sep 2025 15:29:14 GMT
Subject: [lworld] Integrated: 8327257: [lworld] Tests are needed to stress
 class preloading with concurrent class loadings
In-Reply-To: <5BhLWx8JG5TtyJ-CueXpUfFq_QCWg5x_9oDaPJNr4Gw=.d1f668f7-ff8a-4307-b1d2-294a7f14fbbf@github.com>
References: <5BhLWx8JG5TtyJ-CueXpUfFq_QCWg5x_9oDaPJNr4Gw=.d1f668f7-ff8a-4307-b1d2-294a7f14fbbf@github.com>
Message-ID: <_Eenc-3FaJfyY1WmREoRRIePx9NtCSQ3IwbRjHtAYfQ=.edf748b1-47c8-49f1-a768-7d3ea712189b@github.com>

On Mon, 8 Sep 2025 14:37:22 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This change strengthens our Valhalla-specific classloading test suite and guards against regressions. An overview of the new changes is as follows:
> * `BigClassTreeClassLoader`: a utility classloader that generates huge class trees on the fly. The idea is to generate a tree that is deep (lots of parent classes) and very wide (classes have lots of value classes as fields, which have value class fields, etc.). 
> * `ConcurrentClassLoadingTest` strains the classloading and preloading by classloading many classes at the same time.
> * `LoadableDescriptorsTest` ensures that the `LoadableDescriptors` attribute can handle unexpected data. This may need to be revisited if https://bugs.openjdk.org/browse/JDK-8366907 changes the semantics.
> * `PreLoadCircularityTest` ensures that preloading happens even when there are cycles (via inheritance, fields, and both). 
> * `PreLoadDoesNotInitTest` is a regression test that ensures preloading will not initialize a class.
> * `PreLoadFailuresDoNotImpactApplicationTest` ensures that a flaky classloader during preloading will not cause crashes as long as the classloader can find the class when it is actually used.
> * `ValueClassInheritanceTest` is a regression test that ensures one cannot have a value class inherit from something that's not an abstract value class.

This pull request has now been integrated.

Changeset: 092078eb
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/092078eba98b476a32a9c43124399771e96bd81a
Stats:     893 lines in 11 files changed: 893 ins; 0 del; 0 mod

8327257: [lworld] Tests are needed to stress class preloading with concurrent class loadings

Reviewed-by: dsimms

-------------

PR: https://git.openjdk.org/valhalla/pull/1552

From pedro.lamarao at prodist.com.br  Wed Sep 10 16:11:04 2025
From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=)
Date: Wed, 10 Sep 2025 13:11:04 -0300
Subject: Method names for Valhalla value types
In-Reply-To: <CACzrW9Cg4+WB+-yKtgxLSePP+um84Hh4qsJP6OrQ2+HTxCmd0Q@mail.gmail.com>
References: <CACzrW9Cg4+WB+-yKtgxLSePP+um84Hh4qsJP6OrQ2+HTxCmd0Q@mail.gmail.com>
Message-ID: <CAC8PkgH-7oTgDrt+46y_gpcD+v=mBB8LrZ8uVf5r0dtm_E3pYA@mail.gmail.com>

Em qua., 10 de set. de 2025 ?s 11:54, Stephen Colebourne <
scolebourne at joda.org> escreveu:


> 1) Basic - add/subtract/multiply/divide/negate
> Used by BigDecimal/BigInteger
>

To me, style 1 communicates "update" -- x.add(y) -- add y to x, update x by
adding y.
It would confuse me if "add" did not update x.
Following Stepanov in "Elements of Programming", I think of this as
"accumulator style".

For immutable data types, I think style 2 communicates "new value".
In my own arithmetic code, I use sum, difference, product, quotient and
remainder; division produces a pair; inverse, half, twice or double etc.

-- 
Pedro Lamar?o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250910/4d7ea76a/attachment.htm>

From chen.l.liang at oracle.com  Wed Sep 10 16:31:39 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Wed, 10 Sep 2025 16:31:39 +0000
Subject: Method names for Valhalla value types
In-Reply-To: <CAC8PkgH-7oTgDrt+46y_gpcD+v=mBB8LrZ8uVf5r0dtm_E3pYA@mail.gmail.com>
References: <CACzrW9Cg4+WB+-yKtgxLSePP+um84Hh4qsJP6OrQ2+HTxCmd0Q@mail.gmail.com>
 <CAC8PkgH-7oTgDrt+46y_gpcD+v=mBB8LrZ8uVf5r0dtm_E3pYA@mail.gmail.com>
Message-ID: <SJ2PR10MB766982F443588221AB988540A20EA@SJ2PR10MB7669.namprd10.prod.outlook.com>

I agree an adjective or a noun method name to indicate a derived distinct object is better. Such pattern is seen in some wrapper class methods, like Integer.lowestOneBit. A verb name like "add" works better for static methods that take two BigDecimal. Since Brian is talking about type classes in this JVMLS, I would assume the verb names like "add" would be more suitable for the type classes than on the numeric types themselves.

Chen
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Pedro Lamar?o <pedro.lamarao at prodist.com.br>
Sent: Wednesday, September 10, 2025 11:11 AM
To: Stephen Colebourne <scolebourne at joda.org>
Cc: valhalla-dev <valhalla-dev at openjdk.java.net>
Subject: Re: Method names for Valhalla value types

Em qua., 10 de set. de 2025 ?s 11:54, Stephen Colebourne <scolebourne at joda.org<mailto:scolebourne at joda.org>> escreveu:

1) Basic - add/subtract/multiply/divide/negate
Used by BigDecimal/BigInteger

To me, style 1 communicates "update" -- x.add(y) -- add y to x, update x by adding y.
It would confuse me if "add" did not update x.
Following Stepanov in "Elements of Programming", I think of this as "accumulator style".

For immutable data types, I think style 2 communicates "new value".
In my own arithmetic code, I use sum, difference, product, quotient and remainder; division produces a pair; inverse, half, twice or double etc.

--
Pedro Lamar?o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250910/e2748345/attachment-0001.htm>

From rriggs at openjdk.org  Wed Sep 10 17:10:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Sep 2025 17:10:53 GMT
Subject: [lworld] RFR: 8367362: ProblemList test
 VarHandleTestMethodHandleAccessValue.java
Message-ID: <mp9BF8dvaigsYxjytJ8ksYLhoDQaAf-6BlByfPGQo1Y=.b875e7a9-4827-456c-825b-8a0a3a4133d9@github.com>

java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessValue.java times out and have a more serious problem.
ProblemList until fixed.

-------------

Commit messages:
 - 8367362: ProblemList test VarHandleTestMethodHandleAccessValue.java

Changes: https://git.openjdk.org/valhalla/pull/1565/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1565&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367362
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1565.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1565/head:pull/1565

PR: https://git.openjdk.org/valhalla/pull/1565

From liach at openjdk.org  Wed Sep 10 17:14:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Sep 2025 17:14:30 GMT
Subject: [lworld] RFR: 8367362: ProblemList test
 VarHandleTestMethodHandleAccessValue.java
In-Reply-To: <mp9BF8dvaigsYxjytJ8ksYLhoDQaAf-6BlByfPGQo1Y=.b875e7a9-4827-456c-825b-8a0a3a4133d9@github.com>
References: <mp9BF8dvaigsYxjytJ8ksYLhoDQaAf-6BlByfPGQo1Y=.b875e7a9-4827-456c-825b-8a0a3a4133d9@github.com>
Message-ID: <uXnlWkTym0dVHuo1rWcF6BUPFpNEl8Lgv0BREXbkf7A=.a6534362-f549-4074-9946-b0a2a5857ed8@github.com>

On Wed, 10 Sep 2025 17:04:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessValue.java times out and have a more serious problem.
> ProblemList until fixed.

Marked as reviewed by liach (Committer).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1565#pullrequestreview-3207083046

From davidalayachew at gmail.com  Wed Sep 10 17:26:56 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 10 Sep 2025 13:26:56 -0400
Subject: Method names for Valhalla value types
In-Reply-To: <SJ2PR10MB766982F443588221AB988540A20EA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CACzrW9Cg4+WB+-yKtgxLSePP+um84Hh4qsJP6OrQ2+HTxCmd0Q@mail.gmail.com>
 <CAC8PkgH-7oTgDrt+46y_gpcD+v=mBB8LrZ8uVf5r0dtm_E3pYA@mail.gmail.com>
 <SJ2PR10MB766982F443588221AB988540A20EA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_NFJC7u7pq8tnHhwDc=sFBZpFB=wqRMWPUu5LOdwrBOhg@mail.gmail.com>

I'm also in camp 2. I prefer the past tense style, for the logic explained
via sort() vs sorted().

On Wed, Sep 10, 2025, 12:31?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> I agree an adjective or a noun method name to indicate a derived distinct
> object is better. Such pattern is seen in some wrapper class methods, like
> Integer.lowestOneBit. A verb name like "add" works better for static
> methods that take two BigDecimal. Since Brian is talking about type classes
> in this JVMLS, I would assume the verb names like "add" would be more
> suitable for the type classes than on the numeric types themselves.
>
> Chen
> ------------------------------
> *From:* valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Pedro
> Lamar?o <pedro.lamarao at prodist.com.br>
> *Sent:* Wednesday, September 10, 2025 11:11 AM
> *To:* Stephen Colebourne <scolebourne at joda.org>
> *Cc:* valhalla-dev <valhalla-dev at openjdk.java.net>
> *Subject:* Re: Method names for Valhalla value types
>
> Em qua., 10 de set. de 2025 ?s 11:54, Stephen Colebourne <
> scolebourne at joda.org> escreveu:
>
>
> 1) Basic - add/subtract/multiply/divide/negate
> Used by BigDecimal/BigInteger
>
>
> To me, style 1 communicates "update" -- x.add(y) -- add y to x, update x
> by adding y.
> It would confuse me if "add" did not update x.
> Following Stepanov in "Elements of Programming", I think of this as
> "accumulator style".
>
> For immutable data types, I think style 2 communicates "new value".
> In my own arithmetic code, I use sum, difference, product, quotient and
> remainder; division produces a pair; inverse, half, twice or double etc.
>
> --
> Pedro Lamar?o
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250910/0d1064ed/attachment-0001.htm>

From rriggs at openjdk.org  Wed Sep 10 18:13:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 10 Sep 2025 18:13:06 GMT
Subject: [lworld] Integrated: 8367362: ProblemList test
 VarHandleTestMethodHandleAccessValue.java
In-Reply-To: <mp9BF8dvaigsYxjytJ8ksYLhoDQaAf-6BlByfPGQo1Y=.b875e7a9-4827-456c-825b-8a0a3a4133d9@github.com>
References: <mp9BF8dvaigsYxjytJ8ksYLhoDQaAf-6BlByfPGQo1Y=.b875e7a9-4827-456c-825b-8a0a3a4133d9@github.com>
Message-ID: <_ml1Ac9WqE2ao5_P80qPdqSh8XB7qwh5Xt-8qqNeDwY=.bf76830c-e92b-4813-8d4f-9df855f8ee75@github.com>

On Wed, 10 Sep 2025 17:04:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessValue.java times out and have a more serious problem.
> ProblemList until fixed.

This pull request has now been integrated.

Changeset: 9a78d542
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9a78d5429727149dc555731b1933c69d10641766
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8367362: ProblemList test VarHandleTestMethodHandleAccessValue.java

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/valhalla/pull/1565

From coleenp at openjdk.org  Wed Sep 10 18:35:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 10 Sep 2025 18:35:47 GMT
Subject: [lworld] RFR: 8294051: [lworld] runtime/AccModule/ConstModule.java
 fails with incorrect error message [v2]
In-Reply-To: <9WzNCEChUd3BF408cIPGApv0syVRk-sDOcTWtplkyAM=.6de8c76c-1911-45de-afff-5039ae192639@github.com>
References: <dwlACEOgpPbSZUEwRxZw5gL_RsjRuEwwHuLAN3uFpU8=.743b0dc8-73c9-499e-82ea-a8c958a0e3c6@github.com>
 <ZlKcpy2DJj19NLJftm78XapaFShlesJNjlkiFJ4ZPSU=.a8f622ec-0712-4cee-b2ae-5d722875e571@github.com>
 <Lqjh48WFPEOy7A67Gyw-pa5vbA77mxhyMA6sVblrgdI=.e7acceb8-879a-4bdf-95c9-b8023f7b1657@github.com>
 <9WzNCEChUd3BF408cIPGApv0syVRk-sDOcTWtplkyAM=.6de8c76c-1911-45de-afff-5039ae192639@github.com>
Message-ID: <zBiS8Zr59Io8WqjJa_8sLxthpq1nyq1BhqdA7f8WkrU=.ac704421-23df-4a43-b575-5050228e00b8@github.com>

On Mon, 8 Sep 2025 17:49:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 4465:
>> 
>>> 4463:       "Illegal class modifiers in class %s%s: 0x%X",
>>> 4464:       _class_name->as_C_string(), class_note, flags
>>> 4465:     );
>> 
>> By removing the special handling of inner classes, the exception will report the access flag issue on the wrong class. This is going to make debugging/troubleshooting harder.
>
> This is something we don't have in mainline.  I can add it there instead and it'll get merged in here.

https://bugs.openjdk.org/browse/JDK-8367368

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1550#discussion_r2337589970

From matsaave at openjdk.org  Wed Sep 10 22:25:40 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 10 Sep 2025 22:25:40 GMT
Subject: [lworld] RFR: 8366743: [lworld]: Verifier adjustments for operations
 on 'uninitialized'
Message-ID: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>

The updated spec places more restrictions on the use of uninitialized and uninitializedThis with certain bytecodes. Those spec changes are implemented with this patch and tested with a new set of tests. Verified with the new test as well as tiers 1-5.

-------------

Commit messages:
 - 8366743: [lworld]: Verifier adjustments for operations on \'uninitialized\'

Changes: https://git.openjdk.org/valhalla/pull/1566/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1566&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366743
  Stats: 226 lines in 6 files changed: 224 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1566.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1566/head:pull/1566

PR: https://git.openjdk.org/valhalla/pull/1566

From liach at openjdk.org  Thu Sep 11 00:24:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Sep 2025 00:24:51 GMT
Subject: [lworld] RFR: 8366743: [lworld]: Verifier adjustments for
 operations on 'uninitialized'
In-Reply-To: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
References: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
Message-ID: <Xp2RP6bBxU6MOn3iqVA9483rQxY79wK1jmWPvLW8e6Y=.18a3bc62-4590-4e21-afe0-793e3fe9309e@github.com>

On Wed, 10 Sep 2025 22:17:45 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The updated spec places more restrictions on the use of uninitialized and uninitializedThis with certain bytecodes. Those spec changes are implemented with this patch and tested with a new set of tests. Verified with the new test as well as tiers 1-5.

I will submit a patch to adjust the ClassFile API verifier to your fork.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1566#issuecomment-3276955173

From liach at openjdk.org  Thu Sep 11 00:44:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Sep 2025 00:44:50 GMT
Subject: [lworld] RFR: 8366743: [lworld]: Verifier adjustments for
 operations on 'uninitialized'
In-Reply-To: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
References: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
Message-ID: <HbJ7rS4lR4FZRGrJ_sD226iKw7UFBKfS9eIV491Z5wA=.61f45e22-c155-4ae8-89dd-688200c41e4b@github.com>

On Wed, 10 Sep 2025 22:17:45 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The updated spec places more restrictions on the use of uninitialized and uninitializedThis with certain bytecodes. Those spec changes are implemented with this patch and tested with a new set of tests. Verified with the new test as well as tiers 1-5.

Sent: https://github.com/matias9927/valhalla/pull/1

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1566#issuecomment-3276988871

From chagedorn at openjdk.org  Thu Sep 11 07:07:31 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 11 Sep 2025 07:07:31 GMT
Subject: [lworld] RFR: 8366701: [lworld] Method profiles for AOT cache
 introduced with JEP 515 miss Valhalla specific profiling
Message-ID: <zpas1fIw50qWsiUy51NThWY1sRJpTi2Avev_KKFMg7c=.fd5e9a34-0939-4f1c-bd31-fa572538416f@github.com>

JEP 515 extended the AOT cache to also collect method profiles during training runs. In Valhalla, we have additional profiling for:
- Array store
- Array load
- Acmp

When JEP 515 was merged in, we did to account for these Valhalla specific profiling information and later crash when trying to create the AOT cache. The fix is straight forward to add the missing collection code for the Valhalla specific profiling.

I also unproblemlisted the affected tests.

Testing:
- tier1-4 + stress

Thanks,
Christian

-------------

Commit messages:
 - 8366701: [lworld] Method profiles for AOT cache introduced with JEP 515 miss Valhalla specific profiling

Changes: https://git.openjdk.org/valhalla/pull/1568/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1568&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366701
  Stats: 71 lines in 2 files changed: 15 ins; 56 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1568.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1568/head:pull/1568

PR: https://git.openjdk.org/valhalla/pull/1568

From thartmann at openjdk.org  Thu Sep 11 07:07:31 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Sep 2025 07:07:31 GMT
Subject: [lworld] RFR: 8366701: [lworld] Method profiles for AOT cache
 introduced with JEP 515 miss Valhalla specific profiling
In-Reply-To: <zpas1fIw50qWsiUy51NThWY1sRJpTi2Avev_KKFMg7c=.fd5e9a34-0939-4f1c-bd31-fa572538416f@github.com>
References: <zpas1fIw50qWsiUy51NThWY1sRJpTi2Avev_KKFMg7c=.fd5e9a34-0939-4f1c-bd31-fa572538416f@github.com>
Message-ID: <Uy_wW4OCR3SkpRO6V7W2RTtvgkpRCxL9neksiBjijbA=.54f7751c-b408-49df-8d2b-8fb60a21fa8b@github.com>

On Thu, 11 Sep 2025 06:58:59 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> JEP 515 extended the AOT cache to also collect method profiles during training runs. In Valhalla, we have additional profiling for:
> - Array store
> - Array load
> - Acmp
> 
> When JEP 515 was merged in, we did to account for these Valhalla specific profiling information and later crash when trying to create the AOT cache. The fix is straight forward to add the missing collection code for the Valhalla specific profiling.
> 
> I also unproblemlisted the affected tests.
> 
> Testing:
> - tier1-4 + stress
> 
> Thanks,
> Christian

Looks good and trivial to me!

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1568#pullrequestreview-3209317249

From chagedorn at openjdk.org  Thu Sep 11 07:14:22 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 11 Sep 2025 07:14:22 GMT
Subject: [lworld] RFR: 8366701: [lworld] Method profiles for AOT cache
 introduced with JEP 515 miss Valhalla specific profiling
In-Reply-To: <zpas1fIw50qWsiUy51NThWY1sRJpTi2Avev_KKFMg7c=.fd5e9a34-0939-4f1c-bd31-fa572538416f@github.com>
References: <zpas1fIw50qWsiUy51NThWY1sRJpTi2Avev_KKFMg7c=.fd5e9a34-0939-4f1c-bd31-fa572538416f@github.com>
Message-ID: <e8nHqkPnmZbCuP3myYsojtQIRC86zDUFMWMEeI6KA00=.dce26288-399e-4416-9d43-ba9646d8eef7@github.com>

On Thu, 11 Sep 2025 06:58:59 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> JEP 515 extended the AOT cache to also collect method profiles during training runs. In Valhalla, we have additional profiling for:
> - Array store
> - Array load
> - Acmp
> 
> When JEP 515 was merged in, we did to account for these Valhalla specific profiling information and later crash when trying to create the AOT cache. The fix is straight forward to add the missing collection code for the Valhalla specific profiling.
> 
> I also unproblemlisted the affected tests.
> 
> Testing:
> - tier1-4 + stress
> 
> Thanks,
> Christian

Thanks Tobias for your quick review!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1568#issuecomment-3278703413

From chagedorn at openjdk.org  Thu Sep 11 07:14:22 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 11 Sep 2025 07:14:22 GMT
Subject: [lworld] Integrated: 8366701: [lworld] Method profiles for AOT cache
 introduced with JEP 515 miss Valhalla specific profiling
In-Reply-To: <zpas1fIw50qWsiUy51NThWY1sRJpTi2Avev_KKFMg7c=.fd5e9a34-0939-4f1c-bd31-fa572538416f@github.com>
References: <zpas1fIw50qWsiUy51NThWY1sRJpTi2Avev_KKFMg7c=.fd5e9a34-0939-4f1c-bd31-fa572538416f@github.com>
Message-ID: <xwi5depxgMSYpLvHab7g75a_lD1waz7hCVGz5KVe2GA=.6e471261-7298-43f8-909a-a707df1d9d19@github.com>

On Thu, 11 Sep 2025 06:58:59 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> JEP 515 extended the AOT cache to also collect method profiles during training runs. In Valhalla, we have additional profiling for:
> - Array store
> - Array load
> - Acmp
> 
> When JEP 515 was merged in, we did to account for these Valhalla specific profiling information and later crash when trying to create the AOT cache. The fix is straight forward to add the missing collection code for the Valhalla specific profiling.
> 
> I also unproblemlisted the affected tests.
> 
> Testing:
> - tier1-4 + stress
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 9aff71a2
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9aff71a2c82e72e58c697bc6dca6baaea5ca1c86
Stats:     71 lines in 2 files changed: 15 ins; 56 del; 0 mod

8366701: [lworld] Method profiles for AOT cache introduced with JEP 515 miss Valhalla specific profiling

Reviewed-by: thartmann

-------------

PR: https://git.openjdk.org/valhalla/pull/1568

From phubner at openjdk.org  Thu Sep 11 07:50:40 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 11 Sep 2025 07:50:40 GMT
Subject: [lworld] RFR: Problem list JCmdTestDynamicDump.java
Message-ID: <xUsKxqbgXK33rE_JWe7CFrlP3ijeWJTbr_PH40OFaLg=.794c256f-0cd0-4c10-9bbe-ef7d758c763d@github.com>

Currently this test is crashing frequently, JBS issue has been filed so it should be problem listed.

-------------

Commit messages:
 - Problemlist JCmdTestDynamicDump.java crash.

Changes: https://git.openjdk.org/valhalla/pull/1569/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1569&range=00
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1569.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1569/head:pull/1569

PR: https://git.openjdk.org/valhalla/pull/1569

From dsimms at openjdk.org  Thu Sep 11 08:03:09 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 11 Sep 2025 08:03:09 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <wr-8xUdWvMZHbTEHG-_8NBvgkZnmVn80zjc6KomK9co=.3544a3c6-3035-4423-8015-821ee1348f58@github.com>

Merge jdk-26+2
Revert 8357141

-------------

Commit messages:
 - Merge branch 'lworld' into lworld_merge_26_2
 - jtreg 7.5.2 broken: CODETOOLS-7903882
 - Merge tag 'jdk-26+2' into lworld_merge_26_2
 - 8357826: Avoid running some jtreg tests when asan is configured
 - 8344556: [Graal] compiler/intrinsics/bmi/* fail when AOTCache cannot be loaded
 - 8358815: Exception event spec has stale reference to catch_klass parameter
 - 8357382: runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp and C1
 - 8358556: Assert when running with -XX:-UseLibmIntrinsic
 - 8358734: Remove JavaTimeSupplementary resource bundles
 - 8358764: (sc) SocketChannel.close when thread blocked in read causes connection to be reset (win)
 - ... and 53 more: https://git.openjdk.org/valhalla/compare/9a78d542...150a2cb6

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1570&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1570&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/1570/files
  Stats: 7641 lines in 280 files changed: 3708 ins; 3101 del; 832 mod
  Patch: https://git.openjdk.org/valhalla/pull/1570.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1570/head:pull/1570

PR: https://git.openjdk.org/valhalla/pull/1570

From dsimms at openjdk.org  Thu Sep 11 08:06:25 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 11 Sep 2025 08:06:25 GMT
Subject: [lworld] RFR: Problem list JCmdTestDynamicDump.java
In-Reply-To: <xUsKxqbgXK33rE_JWe7CFrlP3ijeWJTbr_PH40OFaLg=.794c256f-0cd0-4c10-9bbe-ef7d758c763d@github.com>
References: <xUsKxqbgXK33rE_JWe7CFrlP3ijeWJTbr_PH40OFaLg=.794c256f-0cd0-4c10-9bbe-ef7d758c763d@github.com>
Message-ID: <s2L-JFKIWuO0DWEAe8OXT7OafIBIFCrNFl3KfJDS9gE=.bf0bfe23-1d63-4167-ba24-16eb7ade4bed@github.com>

On Thu, 11 Sep 2025 07:42:17 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Currently this test is crashing frequently, JBS issue has been filed so it should be problem listed.

Marked as reviewed by dsimms (Committer).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1569#pullrequestreview-3209661941

From duke at openjdk.org  Thu Sep 11 08:06:25 2025
From: duke at openjdk.org (duke)
Date: Thu, 11 Sep 2025 08:06:25 GMT
Subject: [lworld] RFR: Problem list JCmdTestDynamicDump.java
In-Reply-To: <xUsKxqbgXK33rE_JWe7CFrlP3ijeWJTbr_PH40OFaLg=.794c256f-0cd0-4c10-9bbe-ef7d758c763d@github.com>
References: <xUsKxqbgXK33rE_JWe7CFrlP3ijeWJTbr_PH40OFaLg=.794c256f-0cd0-4c10-9bbe-ef7d758c763d@github.com>
Message-ID: <0LSyd9t_qUCbYC14Cqc2bRVhyeCL8mIhGR146QwcpLo=.aa481270-38c8-4926-b436-585926f2f83a@github.com>

On Thu, 11 Sep 2025 07:42:17 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Currently this test is crashing frequently, JBS issue has been filed so it should be problem listed.

@Arraying 
Your change (at version 23ecee2a4a62becf8d954eb995d22dfbe02f850b) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1569#issuecomment-3279037987

From phubner at openjdk.org  Thu Sep 11 08:10:03 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 11 Sep 2025 08:10:03 GMT
Subject: [lworld] Integrated: Problem list JCmdTestDynamicDump.java
In-Reply-To: <xUsKxqbgXK33rE_JWe7CFrlP3ijeWJTbr_PH40OFaLg=.794c256f-0cd0-4c10-9bbe-ef7d758c763d@github.com>
References: <xUsKxqbgXK33rE_JWe7CFrlP3ijeWJTbr_PH40OFaLg=.794c256f-0cd0-4c10-9bbe-ef7d758c763d@github.com>
Message-ID: <hgTQpPfUchRHmAldlZSAPZ8IVcA0VfKwO2BIK--SBSY=.f5325942-aaf9-4f4a-91c0-04deb3a7842b@github.com>

On Thu, 11 Sep 2025 07:42:17 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Currently this test is crashing frequently, JBS issue has been filed so it should be problem listed.

This pull request has now been integrated.

Changeset: c600049b
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c600049b7d58966136eb46ccec65479855f1532b
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

Problem list JCmdTestDynamicDump.java

Reviewed-by: dsimms

-------------

PR: https://git.openjdk.org/valhalla/pull/1569

From dsimms at openjdk.org  Thu Sep 11 08:53:34 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 11 Sep 2025 08:53:34 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <wr-8xUdWvMZHbTEHG-_8NBvgkZnmVn80zjc6KomK9co=.3544a3c6-3035-4423-8015-821ee1348f58@github.com>
References: <wr-8xUdWvMZHbTEHG-_8NBvgkZnmVn80zjc6KomK9co=.3544a3c6-3035-4423-8015-821ee1348f58@github.com>
Message-ID: <5eEgXkYtJUEEW7CpyEhhUU2mMG__yK6H3zivm63nYQ4=.83682e36-0f1b-4fbd-b21c-728958bc3b32@github.com>

On Thu, 11 Sep 2025 07:54:58 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+2
> Revert 8357141

This pull request has now been integrated.

Changeset: a7b14049
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a7b140495f6a5f289f609188aab5f8bee009adef
Stats:     7641 lines in 280 files changed: 3708 ins; 3101 del; 832 mod

Merge jdk

Merge jdk-26+2

-------------

PR: https://git.openjdk.org/valhalla/pull/1570

From thartmann at openjdk.org  Thu Sep 11 11:27:35 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Sep 2025 11:27:35 GMT
Subject: [lworld] Integrated: [lworld] Problem listing 8367405
Message-ID: <uznWEMK7F_vgGCKzmMzmp98P70gucuXwgvr2-fgxNCQ=.e31463cb-6629-45a9-81a8-dbb10bd6bf44@github.com>

Problem listing test until [JDK-8367405](https://bugs.openjdk.org/browse/JDK-8367405) is fixed (which is probably a mainline issue but only triggered in Valhalla).

Thanks,
Tobias

-------------

Commit messages:
 - [lworld] Problem listing 8367405

Changes: https://git.openjdk.org/valhalla/pull/1571/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1571&range=00
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1571.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1571/head:pull/1571

PR: https://git.openjdk.org/valhalla/pull/1571

From thartmann at openjdk.org  Thu Sep 11 11:27:36 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Sep 2025 11:27:36 GMT
Subject: [lworld] Integrated: [lworld] Problem listing 8367405
In-Reply-To: <uznWEMK7F_vgGCKzmMzmp98P70gucuXwgvr2-fgxNCQ=.e31463cb-6629-45a9-81a8-dbb10bd6bf44@github.com>
References: <uznWEMK7F_vgGCKzmMzmp98P70gucuXwgvr2-fgxNCQ=.e31463cb-6629-45a9-81a8-dbb10bd6bf44@github.com>
Message-ID: <pu7sOs4MbOssk37P9qUF0pMuO_7YQxsM4f4fnpSsMyA=.e45cbe77-66ce-43bb-828f-779db9c4f2cc@github.com>

On Thu, 11 Sep 2025 11:21:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Problem listing test until [JDK-8367405](https://bugs.openjdk.org/browse/JDK-8367405) is fixed (which is probably a mainline issue but only triggered in Valhalla).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 880ae478
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/880ae47831ed7262a0d3b30b92c3645bc67e5df2
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

[lworld] Problem listing 8367405

-------------

PR: https://git.openjdk.org/valhalla/pull/1571

From dsimms at openjdk.org  Thu Sep 11 11:34:25 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 11 Sep 2025 11:34:25 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <Vfn11uZggfLjeZgqoc0_WJQ9yOggpBoL_YkDxLujI8A=.046d8df8-e104-49e6-a74c-12e84ca1646e@github.com>

Merge tag 'jdk-26+3' into lworld_merge_jdk_26_3
Added tag jdk-26+3 for changeset 08b1fa4c

-------------

Commit messages:
 - Merge tag 'jdk-26+3' into lworld_merge_jdk_26_3
 - 8359972: Problem list TestStaticCallStub until JDK-8359963 is fixed
 - 8359180: Apply java.io.Serial annotations in java.instrument
 - 8357686: Remove unnecessary Map.get from AWTAutoShutdown.unregisterPeer
 - 8359167: Remove unused test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java
 - 8359386: Fix incorrect value for max_size of C2CodeStub when APX is used
 - 8359227: Code cache/heap size options should be size_t
 - 8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar
 - 8359895: JFR: method-timing view doesn't work
 - 8359923: Const accessors for the Deferred class
 - ... and 86 more: https://git.openjdk.org/valhalla/compare/a7b14049...4023108a

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1572&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1572&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/1572/files
  Stats: 18539 lines in 374 files changed: 10947 ins; 5514 del; 2078 mod
  Patch: https://git.openjdk.org/valhalla/pull/1572.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1572/head:pull/1572

PR: https://git.openjdk.org/valhalla/pull/1572

From chagedorn at openjdk.org  Thu Sep 11 12:53:07 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 11 Sep 2025 12:53:07 GMT
Subject: [lworld] RFR: 8367414: Problemlist
 runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot
Message-ID: <fP5YkAZkkba2g-8JNfI9Q_c1uKnx5dNpsjcmZxuIn0s=.445c1aa8-6706-404b-8a92-5e04cce3a8cc@github.com>

Problemlisting the test which is regularly failing in tier3.

Thanks,
Christian

-------------

Commit messages:
 - update
 - 8367414: Problemlist runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot

Changes: https://git.openjdk.org/valhalla/pull/1573/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1573&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367414
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1573.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1573/head:pull/1573

PR: https://git.openjdk.org/valhalla/pull/1573

From chagedorn at openjdk.org  Thu Sep 11 12:54:12 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 11 Sep 2025 12:54:12 GMT
Subject: [lworld] Integrated: 8367414: Problemlist
 runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot
In-Reply-To: <fP5YkAZkkba2g-8JNfI9Q_c1uKnx5dNpsjcmZxuIn0s=.445c1aa8-6706-404b-8a92-5e04cce3a8cc@github.com>
References: <fP5YkAZkkba2g-8JNfI9Q_c1uKnx5dNpsjcmZxuIn0s=.445c1aa8-6706-404b-8a92-5e04cce3a8cc@github.com>
Message-ID: <TjQSQrgL6D6qzq_WdPzqob7oLuqi-hsniAE_laG6cgE=.35f5fec9-ebb6-442c-98f5-298a4bdad75d@github.com>

On Thu, 11 Sep 2025 12:46:21 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Problemlisting the test which is regularly failing in tier3.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 7d4f8fe1
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7d4f8fe1b69bd645e2159f860058e9d17d8fea43
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8367414: Problemlist runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot

-------------

PR: https://git.openjdk.org/valhalla/pull/1573

From dsimms at openjdk.org  Thu Sep 11 12:55:38 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 11 Sep 2025 12:55:38 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <Vfn11uZggfLjeZgqoc0_WJQ9yOggpBoL_YkDxLujI8A=.046d8df8-e104-49e6-a74c-12e84ca1646e@github.com>
References: <Vfn11uZggfLjeZgqoc0_WJQ9yOggpBoL_YkDxLujI8A=.046d8df8-e104-49e6-a74c-12e84ca1646e@github.com>
Message-ID: <fkpJdSebswGQA8JhpnrewkgCnvWaTzNWkjdr0D5zTbs=.7ca8a9a4-c063-4383-bf07-a74341038479@github.com>

> Merge tag 'jdk-26+3' into lworld_merge_jdk_26_3
> Added tag jdk-26+3 for changeset 08b1fa4c

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  Problem list 8367412

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1572/files
  - new: https://git.openjdk.org/valhalla/pull/1572/files/4023108a..562997c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1572&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1572&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1572.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1572/head:pull/1572

PR: https://git.openjdk.org/valhalla/pull/1572

From dsimms at openjdk.org  Thu Sep 11 12:57:59 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 11 Sep 2025 12:57:59 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <Vfn11uZggfLjeZgqoc0_WJQ9yOggpBoL_YkDxLujI8A=.046d8df8-e104-49e6-a74c-12e84ca1646e@github.com>
References: <Vfn11uZggfLjeZgqoc0_WJQ9yOggpBoL_YkDxLujI8A=.046d8df8-e104-49e6-a74c-12e84ca1646e@github.com>
Message-ID: <cVd7UyszrSNjfph4uRXRm9gih9Sz9CaEQozadbMZDIA=.79fe9be6-e818-49fc-9164-7526e0ec412e@github.com>

On Thu, 11 Sep 2025 11:27:17 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-26+3' into lworld_merge_jdk_26_3
> Added tag jdk-26+3 for changeset 08b1fa4c

This pull request has now been integrated.

Changeset: ac35fa7f
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ac35fa7f313d49bd034dcad19936a6dead72c391
Stats:     18540 lines in 374 files changed: 10948 ins; 5514 del; 2078 mod

Merge jdk

Merge jdk-26+3

-------------

PR: https://git.openjdk.org/valhalla/pull/1572

From pchilanomate at openjdk.org  Thu Sep 11 13:02:42 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 11 Sep 2025 13:02:42 GMT
Subject: [lworld] RFR: 8336845: [lworld] Virtual threads don't support the
 value class calling convention
In-Reply-To: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
References: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
Message-ID: <3Fr7LLoc7zlZLGobJDUnOhoYw4HSGHDfGEwdSd0JQLo=.4b8b7a5a-8aac-43d1-adb3-abdbea63cad2@github.com>

On Tue, 9 Sep 2025 12:50:49 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following patch which adds virtual thread support for the value class calling convention. Most of the changes are needed to handle extended frames, i.e c1 or c2 frames that use more stack space for arguments than the stack space allocated by the caller. These include changes in freeze and thaw code, plus changes in the stackChunk walking code where we now need a similar repair of the caller sp as in the current sender code. In this case though, we only adjust _unextended_sp and keep the value of _sp. This is because frames are walked without a full RegisterMap, but we still need to be able to access the saved fp in the callee for gc purposes. The remaining changes deal with saving and restoring the extra return registers when calling thaw.
> 
> Thanks to Tobias for working on the initial changes and for providing the very useful new test TestVirtualThreads.java, included in this PR, which has been great for catching many bugs. I also run the changes with the valhalla-comp-stress job in mach5. It uncovered a couple of extra failures in TestVirtualThreads.java, but I was able to reproduce them with platform threads as well (8367151 and 8367258). I also added extra testing for value classes in existing test Fuzz.java which has proven very useful too.
> 
> Thanks,
> Patricio

Thanks Tobias!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1556#issuecomment-3280535360

From duke at openjdk.org  Thu Sep 11 13:07:32 2025
From: duke at openjdk.org (duke)
Date: Thu, 11 Sep 2025 13:07:32 GMT
Subject: [lworld] RFR: 8336845: [lworld] Virtual threads don't support the
 value class calling convention
In-Reply-To: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
References: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
Message-ID: <wd6J-Imegr8_sUqAiCg4fIzz7_klIraBX1UmqTTqmSI=.f5646ddc-d9cd-4d41-9834-8122ff46792d@github.com>

On Tue, 9 Sep 2025 12:50:49 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following patch which adds virtual thread support for the value class calling convention. Most of the changes are needed to handle extended frames, i.e c1 or c2 frames that use more stack space for arguments than the stack space allocated by the caller. These include changes in freeze and thaw code, plus changes in the stackChunk walking code where we now need a similar repair of the caller sp as in the current sender code. In this case though, we only adjust _unextended_sp and keep the value of _sp. This is because frames are walked without a full RegisterMap, but we still need to be able to access the saved fp in the callee for gc purposes. The remaining changes deal with saving and restoring the extra return registers when calling thaw.
> 
> Thanks to Tobias for working on the initial changes and for providing the very useful new test TestVirtualThreads.java, included in this PR, which has been great for catching many bugs. I also run the changes with the valhalla-comp-stress job in mach5. It uncovered a couple of extra failures in TestVirtualThreads.java, but I was able to reproduce them with platform threads as well (8367151 and 8367258). I also added extra testing for value classes in existing test Fuzz.java which has proven very useful too.
> 
> Thanks,
> Patricio

@pchilano 
Your change (at version 3966983210967da95ac6f0583706a3c9da3799a7) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1556#issuecomment-3280553999

From phubner at openjdk.org  Thu Sep 11 13:52:44 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 11 Sep 2025 13:52:44 GMT
Subject: [lworld] RFR: 8341846: [lworld]
 compiler/valhalla/inlinetypes/TestStressReturnBuffering.java fails to boot
 with genzgc
Message-ID: <4hstsNqBFcs94tQthZfLz7p2A3VUGt5xNKkQJPlTHv0=.87807241-bb2b-44d4-8a14-1f405046b9a6@github.com>

Hi all,

The test `compiler/valhalla/inlinetypes/TestStressReturnBuffering.java` was intermittently failing on all platforms if run enough. This patch increases the memory by 50%, leaving nonetheless a very small heap.

I've run it with the new flag on Linux x64, macOS x64, and Windows x64, 5x 100 iterations on each platform. While with the old heap size this would consistently fail, the new heap size sees no failures.

-------------

Commit messages:
 - Increase TestStressReturnBuffering memory by 50%.

Changes: https://git.openjdk.org/valhalla/pull/1574/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1574&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341846
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1574.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1574/head:pull/1574

PR: https://git.openjdk.org/valhalla/pull/1574

From coleenp at openjdk.org  Thu Sep 11 13:59:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 11 Sep 2025 13:59:26 GMT
Subject: [lworld] RFR: 8341846: [lworld]
 compiler/valhalla/inlinetypes/TestStressReturnBuffering.java fails to boot
 with genzgc
In-Reply-To: <4hstsNqBFcs94tQthZfLz7p2A3VUGt5xNKkQJPlTHv0=.87807241-bb2b-44d4-8a14-1f405046b9a6@github.com>
References: <4hstsNqBFcs94tQthZfLz7p2A3VUGt5xNKkQJPlTHv0=.87807241-bb2b-44d4-8a14-1f405046b9a6@github.com>
Message-ID: <yk8EAMM9Dz0C8Mgmp2HsKh4CbcYso0jueuFe9rlo2Rg=.45f140b2-6ae2-46a7-93cd-d264d8d2dce2@github.com>

On Thu, 11 Sep 2025 13:46:50 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The test `compiler/valhalla/inlinetypes/TestStressReturnBuffering.java` was intermittently failing on all platforms if run enough. This patch increases the memory by 50%, leaving nonetheless a very small heap.
> 
> I've run it with the new flag on Linux x64, macOS x64, and Windows x64, 5x 100 iterations on each platform. While with the old heap size this would consistently fail, the new heap size sees no failures.

Looks good!

-------------

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1574#pullrequestreview-3211770449

From coleenp at openjdk.org  Thu Sep 11 13:59:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 11 Sep 2025 13:59:33 GMT
Subject: [lworld] RFR: 8336845: [lworld] Virtual threads don't support the
 value class calling convention
In-Reply-To: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
References: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
Message-ID: <Qbym8VB7AonrRgjAhxrp3328_8Brq4XqhluCD3zzOqY=.61f32966-82ab-414a-8710-12d7a1831e30@github.com>

On Tue, 9 Sep 2025 12:50:49 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following patch which adds virtual thread support for the value class calling convention. Most of the changes are needed to handle extended frames, i.e c1 or c2 frames that use more stack space for arguments than the stack space allocated by the caller. These include changes in freeze and thaw code, plus changes in the stackChunk walking code where we now need a similar repair of the caller sp as in the current sender code. In this case though, we only adjust _unextended_sp and keep the value of _sp. This is because frames are walked without a full RegisterMap, but we still need to be able to access the saved fp in the callee for gc purposes. The remaining changes deal with saving and restoring the extra return registers when calling thaw.
> 
> Thanks to Tobias for working on the initial changes and for providing the very useful new test TestVirtualThreads.java, included in this PR, which has been great for catching many bugs. I also run the changes with the valhalla-comp-stress job in mach5. It uncovered a couple of extra failures in TestVirtualThreads.java, but I was able to reproduce them with platform threads as well (8367151 and 8367258). I also added extra testing for value classes in existing test Fuzz.java which has proven very useful too.
> 
> Thanks,
> Patricio

src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp line 54:

> 52:                         RegisterMap::WalkContinuation::skip);
> 53:         frame caller = to_frame().sender(&map);
> 54:         assert(caller.is_compiled_frame() && caller.cb()->as_nmethod()->is_compiled_by_c2(), "");

All these asserts with no messages could be precond().  Or they could have strings why these conditions are expected.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1556#discussion_r2340990577

From matsaave at openjdk.org  Thu Sep 11 14:22:34 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 11 Sep 2025 14:22:34 GMT
Subject: [lworld] RFR: 8366743: [lworld]: Verifier adjustments for
 operations on 'uninitialized' [v2]
In-Reply-To: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
References: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
Message-ID: <R1_0lTWfoW-dRGfNWjbMWc7OVG8Mybr0yQNDP-fLxh8=.1135d19c-2198-4957-8e6a-477a4577ceb1@github.com>

> The updated spec places more restrictions on the use of uninitialized and uninitializedThis with certain bytecodes. Those spec changes are implemented with this patch and tested with a new set of tests. Verified with the new test as well as tiers 1-5.

Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #1 from liach/feature/cf-verify-acmp
   
   Restrict acmp etc. in classfile verifier
 - Restrict acmp etc. in classfile verifier

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1566/files
  - new: https://git.openjdk.org/valhalla/pull/1566/files/e1325573..e7e2d94b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1566&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1566&range=00-01

  Stats: 74 lines in 2 files changed: 70 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1566.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1566/head:pull/1566

PR: https://git.openjdk.org/valhalla/pull/1566

From matsaave at openjdk.org  Thu Sep 11 14:22:35 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 11 Sep 2025 14:22:35 GMT
Subject: [lworld] RFR: 8366743: [lworld]: Verifier adjustments for
 operations on 'uninitialized'
In-Reply-To: <HbJ7rS4lR4FZRGrJ_sD226iKw7UFBKfS9eIV491Z5wA=.61f45e22-c155-4ae8-89dd-688200c41e4b@github.com>
References: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
 <HbJ7rS4lR4FZRGrJ_sD226iKw7UFBKfS9eIV491Z5wA=.61f45e22-c155-4ae8-89dd-688200c41e4b@github.com>
Message-ID: <DOZVSvezjhlSSzQjEF-z-cDyeNdz1S1YWamNWAiaE8s=.0580bdef-6319-4396-b4a7-8c2b82c9b187@github.com>

On Thu, 11 Sep 2025 00:42:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The updated spec places more restrictions on the use of uninitialized and uninitializedThis with certain bytecodes. Those spec changes are implemented with this patch and tested with a new set of tests. Verified with the new test as well as tiers 1-5.
>
> Sent: https://github.com/matias9927/valhalla/pull/1

Thanks for the Classfile changes @liach!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1566#issuecomment-3281003975

From pchilanomate at openjdk.org  Thu Sep 11 14:28:23 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 11 Sep 2025 14:28:23 GMT
Subject: [lworld] RFR: 8336845: [lworld] Virtual threads don't support the
 value class calling convention
In-Reply-To: <Qbym8VB7AonrRgjAhxrp3328_8Brq4XqhluCD3zzOqY=.61f32966-82ab-414a-8710-12d7a1831e30@github.com>
References: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
 <Qbym8VB7AonrRgjAhxrp3328_8Brq4XqhluCD3zzOqY=.61f32966-82ab-414a-8710-12d7a1831e30@github.com>
Message-ID: <XEU4LwSSIum0JZcOSdXN48RVIuihVpposPBghf9e_WY=.87fe45f4-b5a5-4b84-9e36-61aa179681da@github.com>

On Thu, 11 Sep 2025 13:53:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review the following patch which adds virtual thread support for the value class calling convention. Most of the changes are needed to handle extended frames, i.e c1 or c2 frames that use more stack space for arguments than the stack space allocated by the caller. These include changes in freeze and thaw code, plus changes in the stackChunk walking code where we now need a similar repair of the caller sp as in the current sender code. In this case though, we only adjust _unextended_sp and keep the value of _sp. This is because frames are walked without a full RegisterMap, but we still need to be able to access the saved fp in the callee for gc purposes. The remaining changes deal with saving and restoring the extra return registers when calling thaw.
>> 
>> Thanks to Tobias for working on the initial changes and for providing the very useful new test TestVirtualThreads.java, included in this PR, which has been great for catching many bugs. I also run the changes with the valhalla-comp-stress job in mach5. It uncovered a couple of extra failures in TestVirtualThreads.java, but I was able to reproduce them with platform threads as well (8367151 and 8367258). I also added extra testing for value classes in existing test Fuzz.java which has proven very useful too.
>> 
>> Thanks,
>> Patricio
>
> src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp line 54:
> 
>> 52:                         RegisterMap::WalkContinuation::skip);
>> 53:         frame caller = to_frame().sender(&map);
>> 54:         assert(caller.is_compiled_frame() && caller.cb()->as_nmethod()->is_compiled_by_c2(), "");
> 
> All these asserts with no messages could be precond().  Or they could have strings why these conditions are expected.

If the c2 frame needs stack repair but was not extended, then caller should be c2 compiled too, i.e. there was no need to extend it. How about adding "needs stack repair but was not extended with c1/interpreter caller"?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1556#discussion_r2341146830

From mchevalier at openjdk.org  Thu Sep 11 14:37:42 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 11 Sep 2025 14:37:42 GMT
Subject: [lworld] RFR: 8367156: [lworld] MacroAssembler::remove_frame hits
 "Field too big for insn"
Message-ID: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>

As suspected, it's just a too big offset. We used to have a
https://github.com/openjdk/valhalla/blob/c8d4a247861052aa6ed43125bcbe49995326938f/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6133

I changed it into
https://github.com/openjdk/valhalla/blob/880ae47831ed7262a0d3b30b92c3645bc67e5df2/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6136

But [`ldp`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDP--Load-pair-of-registers-) has only a 7-bit offset. It's big, but not big enough. In some cases I've looked at, the offset can be as big as `536` which fits on 9 bits. [`ldr`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDR--immediate---Load-register--immediate--) supports a 9-bit offset. Let's change the `ldp` into


ldr(rscratch1, Address(sp, sp_inc_offset))
ldr(rfp, Address(sp, sp_inc_offset + wordSize))

which will be merged into one `ldp` if the offset fits.

But what if the offset is bigger than what fits on 9 bits? Well, us used to have the `ldr(rscratch1, Address(sp, sp_inc_offset))` so either we have a big problem (too big frames?) or `sp_inc_offset` was just bordeline and `sp_inc_offset + wordSize` is too big. But we still have `sp_inc_offset + wordSize == initial_framesize - 2 * wordSize` which would mean that `initial_framesize` doesn't fit on 9 bits either. Once again, that sounds like a bigger (and unlikely) problem.

Thanks,
Marc

-------------

Commit messages:
 - Split ldp into two ldr

Changes: https://git.openjdk.org/valhalla/pull/1575/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1575&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367156
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1575.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1575/head:pull/1575

PR: https://git.openjdk.org/valhalla/pull/1575

From thartmann at openjdk.org  Thu Sep 11 14:57:33 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Sep 2025 14:57:33 GMT
Subject: [lworld] RFR: 8367156: [lworld] MacroAssembler::remove_frame hits
 "Field too big for insn"
In-Reply-To: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
References: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
Message-ID: <V-klzVq-k9VpqjDLaiomyR5P1ckIajoDnyU29mJX-YQ=.0d1c10d7-99b5-4e0c-b7ea-6f2c64ea5495@github.com>

On Thu, 11 Sep 2025 14:13:41 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> As suspected, it's just a too big offset. We used to have a
> https://github.com/openjdk/valhalla/blob/c8d4a247861052aa6ed43125bcbe49995326938f/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6133
> 
> I changed it into
> https://github.com/openjdk/valhalla/blob/880ae47831ed7262a0d3b30b92c3645bc67e5df2/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6136
> 
> But [`ldp`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDP--Load-pair-of-registers-) has only a 7-bit offset. It's big, but not big enough. In some cases I've looked at, the offset can be as big as `536` which fits on 9 bits. [`ldr`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDR--immediate---Load-register--immediate--) supports a 9-bit offset. Let's change the `ldp` into
> 
> 
> ldr(rscratch1, Address(sp, sp_inc_offset))
> ldr(rfp, Address(sp, sp_inc_offset + wordSize))
> 
> which will be merged into one `ldp` if the offset fits.
> 
> But what if the offset is bigger than what fits on 9 bits? Well, us used to have the `ldr(rscratch1, Address(sp, sp_inc_offset))` so either we have a big problem (too big frames?) or `sp_inc_offset` was just bordeline and `sp_inc_offset + wordSize` is too big. But we still have `sp_inc_offset + wordSize == initial_framesize - 2 * wordSize` which would mean that `initial_framesize` doesn't fit on 9 bits either. Once again, that sounds like a bigger (and unlikely) problem.
> 
> Thanks,
> Marc

Looks good to me. Might be worth adding a targeted regression test if easily doable.

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1575#pullrequestreview-3212136783

From matsaave at openjdk.org  Thu Sep 11 18:06:33 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 11 Sep 2025 18:06:33 GMT
Subject: [lworld] RFR: 8366743: [lworld]: Verifier adjustments for
 operations on 'uninitialized' [v3]
In-Reply-To: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
References: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
Message-ID: <5z448R2lXN9KgTgI715d1KCUW321PvtNNNPQLBTVwc0=.3e546bd7-ebfb-493d-9015-a98b7a774916@github.com>

> The updated spec places more restrictions on the use of uninitialized and uninitializedThis with certain bytecodes. Those spec changes are implemented with this patch and tested with a new set of tests. Verified with the new test as well as tiers 1-5.

Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:

 - Merge commit 'refs/pull/1566/head' of github.com:openjdk/valhalla into uninit_implementation_8366271
 - Added fix and tests for old verifier

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1566/files
  - new: https://git.openjdk.org/valhalla/pull/1566/files/e7e2d94b..d81af4ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1566&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1566&range=01-02

  Stats: 168 lines in 6 files changed: 165 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1566.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1566/head:pull/1566

PR: https://git.openjdk.org/valhalla/pull/1566

From coleenp at openjdk.org  Thu Sep 11 19:20:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 11 Sep 2025 19:20:44 GMT
Subject: [lworld] RFR: 8336845: [lworld] Virtual threads don't support the
 value class calling convention
In-Reply-To: <XEU4LwSSIum0JZcOSdXN48RVIuihVpposPBghf9e_WY=.87fe45f4-b5a5-4b84-9e36-61aa179681da@github.com>
References: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
 <Qbym8VB7AonrRgjAhxrp3328_8Brq4XqhluCD3zzOqY=.61f32966-82ab-414a-8710-12d7a1831e30@github.com>
 <XEU4LwSSIum0JZcOSdXN48RVIuihVpposPBghf9e_WY=.87fe45f4-b5a5-4b84-9e36-61aa179681da@github.com>
Message-ID: <Ir18caV7UFILQWVxLm-3NGNZq6um0Cicpxxa35G-LFc=.74c0ab63-6a1b-4484-b23e-c3e40288eac5@github.com>

On Thu, 11 Sep 2025 14:26:08 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp line 54:
>> 
>>> 52:                         RegisterMap::WalkContinuation::skip);
>>> 53:         frame caller = to_frame().sender(&map);
>>> 54:         assert(caller.is_compiled_frame() && caller.cb()->as_nmethod()->is_compiled_by_c2(), "");
>> 
>> All these asserts with no messages could be precond().  Or they could have strings why these conditions are expected.
>
> If the c2 frame needs stack repair but was not extended, then caller should be c2 compiled too, i.e. there was no need to extend it. How about adding "needs stack repair but was not extended with c1/interpreter caller"?

I think that sounds good.  The strings in these asserts (there are a few that you added) might help with understanding this code.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1556#discussion_r2342112498

From liach at openjdk.org  Thu Sep 11 20:44:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Sep 2025 20:44:42 GMT
Subject: [lworld] RFR: 8366743: [lworld]: Verifier adjustments for
 operations on 'uninitialized' [v3]
In-Reply-To: <5z448R2lXN9KgTgI715d1KCUW321PvtNNNPQLBTVwc0=.3e546bd7-ebfb-493d-9015-a98b7a774916@github.com>
References: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
 <5z448R2lXN9KgTgI715d1KCUW321PvtNNNPQLBTVwc0=.3e546bd7-ebfb-493d-9015-a98b7a774916@github.com>
Message-ID: <zL0PTbCAbYva4PMnyg0D-2IT3hggz9Vd_-AYwcJTQfo=.f417d3af-4186-4e5b-a114-12280ff5f61b@github.com>

On Thu, 11 Sep 2025 18:06:33 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The updated spec places more restrictions on the use of uninitialized and uninitializedThis with certain bytecodes. Those spec changes are implemented with this patch and tested with a new set of tests. Verified with the new test as well as tiers 1-5.
>
> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge commit 'refs/pull/1566/head' of github.com:openjdk/valhalla into uninit_implementation_8366271
>  - Added fix and tests for old verifier

Since the ClassFile API doesn't support the old verifier, I won't add a corresponding case - however, it's interesting to find that the old verifier never supported uninitializedX items for if_acmpeq or if_acmpne, so this reduces the incompatibility risk even more.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1566#issuecomment-3282569516

From amenkov at openjdk.org  Thu Sep 11 20:48:26 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 11 Sep 2025 20:48:26 GMT
Subject: [lworld] RFR: 8271910: [lworld] Heap functions/callbacks should
 support value fields
Message-ID: <8yZd6wXtf5hcIBSq5aBRAQTBvI90R_MVN6xEwFE5XoM=.0af979e4-e992-4116-bcf2-c2c45c6f8fa8@github.com>

The fix implements support for flat value object by heapwalking API.

FollowReferences/IterateThroughHeap are executed at safepoint and agent callbacks may request to set/update tags for the reported object. To store tags for flattened object at safepoint a special tag table is used (entries contain strong references to holder objects), entries from the table are converted to entries in main tag table outside of safepoint.

-------------

Commit messages:
 - jcheck
 - heapwalking

Changes: https://git.openjdk.org/valhalla/pull/1576/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1576&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8271910
  Stats: 1749 lines in 6 files changed: 1405 ins; 102 del; 242 mod
  Patch: https://git.openjdk.org/valhalla/pull/1576.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1576/head:pull/1576

PR: https://git.openjdk.org/valhalla/pull/1576

From coleenp at openjdk.org  Thu Sep 11 21:27:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 11 Sep 2025 21:27:47 GMT
Subject: [lworld] RFR: 8367375: [lworld] Crash when using CDS archive created
 with -XX:+UseCompactObjectHeaders and preview mode
Message-ID: <YRVv-IXMfUB8sEwDy7F-C1puWeiKbSCItRGgTnhZ1RQ=.e12a4f08-92e6-44ea-a99a-44849f6f36f4@github.com>

This is a small fix to make -Xshare:dump and -Xshare:on work with --enable-preview and -XX:+UseCompactObjectHeaders and -Xint.

-------------

Commit messages:
 - 8367375: [lworld] Crash when using CDS archive created with -XX:+UseCompactObjectHeaders and preview mode
 - 8366794: [lworld] "assert(!is_null(v)) failed: narrow klass value can never be zero" with -Xint and COH

Changes: https://git.openjdk.org/valhalla/pull/1577/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1577&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367375
  Stats: 19 lines in 9 files changed: 11 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/1577.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1577/head:pull/1577

PR: https://git.openjdk.org/valhalla/pull/1577

From pchilanomate at openjdk.org  Thu Sep 11 23:59:00 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 11 Sep 2025 23:59:00 GMT
Subject: [lworld] RFR: 8336845: [lworld] Virtual threads don't support the
 value class calling convention [v2]
In-Reply-To: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
References: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
Message-ID: <rHMBAqt-Ye3PHjUPV8MVvT_WuQmYZ3ndHZooAjTuLG4=.7f2f7f40-9f1d-4856-912f-4cc69d9e58fb@github.com>

> Please review the following patch which adds virtual thread support for the value class calling convention. Most of the changes are needed to handle extended frames, i.e c1 or c2 frames that use more stack space for arguments than the stack space allocated by the caller. These include changes in freeze and thaw code, plus changes in the stackChunk walking code where we now need a similar repair of the caller sp as in the current sender code. In this case though, we only adjust _unextended_sp and keep the value of _sp. This is because frames are walked without a full RegisterMap, but we still need to be able to access the saved fp in the callee for gc purposes. The remaining changes deal with saving and restoring the extra return registers when calling thaw.
> 
> Thanks to Tobias for working on the initial changes and for providing the very useful new test TestVirtualThreads.java, included in this PR, which has been great for catching many bugs. I also run the changes with the valhalla-comp-stress job in mach5. It uncovered a couple of extra failures in TestVirtualThreads.java, but I was able to reproduce them with platform threads as well (8367151 and 8367258). I also added extra testing for value classes in existing test Fuzz.java which has proven very useful too.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  add string to assert in is_in_frame()

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1556/files
  - new: https://git.openjdk.org/valhalla/pull/1556/files/39669832..e8759568

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1556&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1556&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1556.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1556/head:pull/1556

PR: https://git.openjdk.org/valhalla/pull/1556

From pchilanomate at openjdk.org  Thu Sep 11 23:59:02 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 11 Sep 2025 23:59:02 GMT
Subject: [lworld] RFR: 8336845: [lworld] Virtual threads don't support the
 value class calling convention [v2]
In-Reply-To: <Ir18caV7UFILQWVxLm-3NGNZq6um0Cicpxxa35G-LFc=.74c0ab63-6a1b-4484-b23e-c3e40288eac5@github.com>
References: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
 <Qbym8VB7AonrRgjAhxrp3328_8Brq4XqhluCD3zzOqY=.61f32966-82ab-414a-8710-12d7a1831e30@github.com>
 <XEU4LwSSIum0JZcOSdXN48RVIuihVpposPBghf9e_WY=.87fe45f4-b5a5-4b84-9e36-61aa179681da@github.com>
 <Ir18caV7UFILQWVxLm-3NGNZq6um0Cicpxxa35G-LFc=.74c0ab63-6a1b-4484-b23e-c3e40288eac5@github.com>
Message-ID: <3Ss120_MzQLuSdwDmNICTtshOJu_b1zXGk64nGJ6iCM=.11076b7c-c3e7-4e65-9d79-4b692d10d4ba@github.com>

On Thu, 11 Sep 2025 19:17:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> If the c2 frame needs stack repair but was not extended, then caller should be c2 compiled too, i.e. there was no need to extend it. How about adding "needs stack repair but was not extended with c1/interpreter caller"?
>
> I think that sounds good.  The strings in these asserts (there are a few that you added) might help with understanding this code.

Added.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1556#discussion_r2342605299

From amenkov at openjdk.org  Fri Sep 12 03:05:03 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 12 Sep 2025 03:05:03 GMT
Subject: [lworld] RFR: 8271910: [lworld] Heap functions/callbacks should
 support value fields [v2]
In-Reply-To: <8yZd6wXtf5hcIBSq5aBRAQTBvI90R_MVN6xEwFE5XoM=.0af979e4-e992-4116-bcf2-c2c45c6f8fa8@github.com>
References: <8yZd6wXtf5hcIBSq5aBRAQTBvI90R_MVN6xEwFE5XoM=.0af979e4-e992-4116-bcf2-c2c45c6f8fa8@github.com>
Message-ID: <iuu49gbwfpWVViyPAfcrAOXGhzYrpgGHrvfbYKJN4uc=.2b18b186-0089-4b73-b85d-54b005b163f9@github.com>

> The fix implements support for flat value object by heapwalking API.
> 
> FollowReferences/IterateThroughHeap are executed at safepoint and agent callbacks may request to set/update tags for the reported object. To store tags for flattened object at safepoint a special tag table is used (entries contain strong references to holder objects), entries from the table are converted to entries in main tag table outside of safepoint.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  report flattened objects from IterateThroughHeap

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1576/files
  - new: https://git.openjdk.org/valhalla/pull/1576/files/e5e14bfa..51b31dcd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1576&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1576&range=00-01

  Stats: 108 lines in 1 file changed: 88 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/valhalla/pull/1576.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1576/head:pull/1576

PR: https://git.openjdk.org/valhalla/pull/1576

From coleenp at openjdk.org  Fri Sep 12 11:44:23 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Sep 2025 11:44:23 GMT
Subject: [lworld] RFR: 8336845: [lworld] Virtual threads don't support the
 value class calling convention [v2]
In-Reply-To: <rHMBAqt-Ye3PHjUPV8MVvT_WuQmYZ3ndHZooAjTuLG4=.7f2f7f40-9f1d-4856-912f-4cc69d9e58fb@github.com>
References: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
 <rHMBAqt-Ye3PHjUPV8MVvT_WuQmYZ3ndHZooAjTuLG4=.7f2f7f40-9f1d-4856-912f-4cc69d9e58fb@github.com>
Message-ID: <sVJKVkGvbCdueS3dgz2YzHl66H8lNI9ZCv5gcZqWjfw=.a992708a-3b2c-457a-a05d-dad026e9dc95@github.com>

On Thu, 11 Sep 2025 23:59:00 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review the following patch which adds virtual thread support for the value class calling convention. Most of the changes are needed to handle extended frames, i.e c1 or c2 frames that use more stack space for arguments than the stack space allocated by the caller. These include changes in freeze and thaw code, plus changes in the stackChunk walking code where we now need a similar repair of the caller sp as in the current sender code. In this case though, we only adjust _unextended_sp and keep the value of _sp. This is because frames are walked without a full RegisterMap, but we still need to be able to access the saved fp in the callee for gc purposes. The remaining changes deal with saving and restoring the extra return registers when calling thaw.
>> 
>> Thanks to Tobias for working on the initial changes and for providing the very useful new test TestVirtualThreads.java, included in this PR, which has been great for catching many bugs. I also run the changes with the valhalla-comp-stress job in mach5. It uncovered a couple of extra failures in TestVirtualThreads.java, but I was able to reproduce them with platform threads as well (8367151 and 8367258). I also added extra testing for value classes in existing test Fuzz.java which has proven very useful too.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add string to assert in is_in_frame()

These changes are written generally enough to upstream to mainline so they can also be part of that code. In case mainline has any improvements in this area, this wouldn't be a complicated merge.

-------------

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1556#pullrequestreview-3216239475

From dsimms at openjdk.org  Fri Sep 12 12:04:46 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 12 Sep 2025 12:04:46 GMT
Subject: [lworld] RFR: 8294051: [lworld] runtime/AccModule/ConstModule.java
 fails with incorrect error message [v2]
In-Reply-To: <ZlKcpy2DJj19NLJftm78XapaFShlesJNjlkiFJ4ZPSU=.a8f622ec-0712-4cee-b2ae-5d722875e571@github.com>
References: <dwlACEOgpPbSZUEwRxZw5gL_RsjRuEwwHuLAN3uFpU8=.743b0dc8-73c9-499e-82ea-a8c958a0e3c6@github.com>
 <ZlKcpy2DJj19NLJftm78XapaFShlesJNjlkiFJ4ZPSU=.a8f622ec-0712-4cee-b2ae-5d722875e571@github.com>
Message-ID: <EyGCdXPriP4a7QSi9gsA-coHre52c4pW3uE3KRBJ1cQ=.c97bdc6e-06d0-44f7-8175-2a357bf38588@github.com>

On Fri, 5 Sep 2025 19:51:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change moves code back to match mainline that checks access flags and checks for invalid JVM_CONSTANTS_Module/Package before reading the class name out of the constant pool.
>> Tested with tier1-3.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra error message printing for inner classes not in mainline.

Marked as reviewed by dsimms (Committer).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1550#pullrequestreview-3216352890

From dsimms at openjdk.org  Fri Sep 12 12:15:54 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 12 Sep 2025 12:15:54 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <9IsGOmhU36R4_AjIca0wBRPFLeNY3oBnYuJnDBpWbEQ=.9bd61089-965f-4c96-9159-d6b34520d9e1@github.com>

Merge jdk-26+4

-------------

Commit messages:
 - Adjust Testing
 - 8358821 for Valhalla
 - Header includes sorted
 - Adjust testing
 - Merge jdk
 - 8360255: runtime/jni/checked/TestLargeUTF8Length.java fails with -XX:-CompactStrings
 - 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead
 - 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart failed with Didn't get ThreadStart events in VM early start phase!
 - 8360303: Remove two unused invoke files
 - 8352565: Add native method implementation of Reference.get()
 - ... and 71 more: https://git.openjdk.org/valhalla/compare/ac35fa7f...8931ceb5

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1579&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1579&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/1579/files
  Stats: 6630 lines in 363 files changed: 3444 ins; 1492 del; 1694 mod
  Patch: https://git.openjdk.org/valhalla/pull/1579.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1579/head:pull/1579

PR: https://git.openjdk.org/valhalla/pull/1579

From dsimms at openjdk.org  Fri Sep 12 12:15:54 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 12 Sep 2025 12:15:54 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <9IsGOmhU36R4_AjIca0wBRPFLeNY3oBnYuJnDBpWbEQ=.9bd61089-965f-4c96-9159-d6b34520d9e1@github.com>
References: <9IsGOmhU36R4_AjIca0wBRPFLeNY3oBnYuJnDBpWbEQ=.9bd61089-965f-4c96-9159-d6b34520d9e1@github.com>
Message-ID: <95yRajEpVcHE61OS0c8o0N7TFcYppppqA-RiRX26RGQ=.2f3404b4-d873-4683-ada1-53785c32657d@github.com>

On Fri, 12 Sep 2025 12:06:06 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+4

This pull request has now been integrated.

Changeset: c3bad8fc
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c3bad8fc7eb9ae3431d057a96fe01f82d1798f4f
Stats:     6630 lines in 363 files changed: 3444 ins; 1492 del; 1694 mod

Merge jdk

Merge jdk-26+4

-------------

PR: https://git.openjdk.org/valhalla/pull/1579

From coleenp at openjdk.org  Fri Sep 12 13:20:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Sep 2025 13:20:33 GMT
Subject: [lworld] RFR: 8328777: [lworld] TestSyncOnValueBasedClassEvent.java
 fails with Exception
Message-ID: <CH0evI6DLL0EYgBXxJpsEGkg0mDyI-gN_hBkmFqylp0=.618ff8e1-47cf-41d2-9c22-97445796712e@github.com>

This test doesn't make sense to run with --enable-preview because the option it's testing isn't valid in preview mode.  If there is synchronization on the value class, then the JVM throws IdentityException and cannot continue and log or emit a JFR event for it.

-------------

Commit messages:
 - Fix no-newline problem.
 - Is it missing a blank line?
 - Merge branch 'lworld' into sync
 - 8328777: [lworld] TestSyncOnValueBasedClassEvent.java fails with Exception

Changes: https://git.openjdk.org/valhalla/pull/1558/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1558&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328777
  Stats: 4 lines in 2 files changed: 1 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1558.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1558/head:pull/1558

PR: https://git.openjdk.org/valhalla/pull/1558

From phubner at openjdk.org  Fri Sep 12 13:20:33 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Sep 2025 13:20:33 GMT
Subject: [lworld] RFR: 8328777: [lworld]
 TestSyncOnValueBasedClassEvent.java fails with Exception
In-Reply-To: <CH0evI6DLL0EYgBXxJpsEGkg0mDyI-gN_hBkmFqylp0=.618ff8e1-47cf-41d2-9c22-97445796712e@github.com>
References: <CH0evI6DLL0EYgBXxJpsEGkg0mDyI-gN_hBkmFqylp0=.618ff8e1-47cf-41d2-9c22-97445796712e@github.com>
Message-ID: <aI_xCabH1YSAhLg_G7JBODyTaUife3PUz0HFo2LR7nw=.063f55c5-6245-465d-9a4c-d6b36c094827@github.com>

On Tue, 9 Sep 2025 20:44:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This test doesn't make sense to run with --enable-preview because the option it's testing isn't valid in preview mode.  If there is synchronization on the value class, then the JVM throws IdentityException and cannot continue and log or emit a JFR event for it.

Looks good, will approve once title can be resolved.

Marked as reviewed by phubner (no project role).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1558#pullrequestreview-3216352669
PR Review: https://git.openjdk.org/valhalla/pull/1558#pullrequestreview-3216664336

From coleenp at openjdk.org  Fri Sep 12 13:20:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Sep 2025 13:20:34 GMT
Subject: [lworld] RFR: 8328777: [lworld]
 TestSyncOnValueBasedClassEvent.java fails with Exception
In-Reply-To: <CH0evI6DLL0EYgBXxJpsEGkg0mDyI-gN_hBkmFqylp0=.618ff8e1-47cf-41d2-9c22-97445796712e@github.com>
References: <CH0evI6DLL0EYgBXxJpsEGkg0mDyI-gN_hBkmFqylp0=.618ff8e1-47cf-41d2-9c22-97445796712e@github.com>
Message-ID: <ykbzM7Pg73vegtKc1XYzuhHgFUWlX9GttnayZFSLFzA=.fd3b44f6-5d2c-4d8f-86d2-aa8b5a669304@github.com>

On Tue, 9 Sep 2025 20:44:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This test doesn't make sense to run with --enable-preview because the option it's testing isn't valid in preview mode.  If there is synchronization on the value class, then the JVM throws IdentityException and cannot continue and log or emit a JFR event for it.

test/jdk/ProblemList.txt line 872:

> 870: sun/tools/jhsdb/HeapDumpTest.java 8366806 generic-all
> 871: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java 8366806 generic-all
> 872: sun/tools/jhsdb/JShellHeapDumpTest.java 8366806 generic-all

Suggestion:

sun/tools/jhsdb/JShellHeapDumpTest.java 8366806 generic-all

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1558#discussion_r2340650168

From phubner at openjdk.org  Fri Sep 12 14:14:41 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Sep 2025 14:14:41 GMT
Subject: [lworld] RFR: 8341846: [lworld]
 compiler/valhalla/inlinetypes/TestStressReturnBuffering.java fails to boot
 with genzgc
In-Reply-To: <yk8EAMM9Dz0C8Mgmp2HsKh4CbcYso0jueuFe9rlo2Rg=.45f140b2-6ae2-46a7-93cd-d264d8d2dce2@github.com>
References: <4hstsNqBFcs94tQthZfLz7p2A3VUGt5xNKkQJPlTHv0=.87807241-bb2b-44d4-8a14-1f405046b9a6@github.com>
 <yk8EAMM9Dz0C8Mgmp2HsKh4CbcYso0jueuFe9rlo2Rg=.45f140b2-6ae2-46a7-93cd-d264d8d2dce2@github.com>
Message-ID: <kbj2ljzYWUbW4Nbn_ICI6wfLeGqV3pArbIik23Myxe0=.bc0f3ab7-ed11-4d8f-bf0b-ae452c1b2d9c@github.com>

On Thu, 11 Sep 2025 13:56:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hi all,
>> 
>> The test `compiler/valhalla/inlinetypes/TestStressReturnBuffering.java` was intermittently failing on all platforms if run enough. This patch increases the memory by 50%, leaving nonetheless a very small heap.
>> 
>> I've run it with the new flag on Linux x64, macOS x64, and Windows x64, 5x 100 iterations on each platform. While with the old heap size this would consistently fail, the new heap size sees no failures.
>
> Looks good!

Thanks for the review @coleenp!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1574#issuecomment-3285449045

From duke at openjdk.org  Fri Sep 12 14:14:43 2025
From: duke at openjdk.org (duke)
Date: Fri, 12 Sep 2025 14:14:43 GMT
Subject: [lworld] RFR: 8341846: [lworld]
 compiler/valhalla/inlinetypes/TestStressReturnBuffering.java fails to boot
 with genzgc
In-Reply-To: <4hstsNqBFcs94tQthZfLz7p2A3VUGt5xNKkQJPlTHv0=.87807241-bb2b-44d4-8a14-1f405046b9a6@github.com>
References: <4hstsNqBFcs94tQthZfLz7p2A3VUGt5xNKkQJPlTHv0=.87807241-bb2b-44d4-8a14-1f405046b9a6@github.com>
Message-ID: <xjqFMPyjUBeN1DldBFsqWZco6BbPmA6KHfLWDYwLNFo=.43de12f0-5774-454d-8b52-ab10a0d43cdb@github.com>

On Thu, 11 Sep 2025 13:46:50 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The test `compiler/valhalla/inlinetypes/TestStressReturnBuffering.java` was intermittently failing on all platforms if run enough. This patch increases the memory by 50%, leaving nonetheless a very small heap.
> 
> I've run it with the new flag on Linux x64, macOS x64, and Windows x64, 5x 100 iterations on each platform. While with the old heap size this would consistently fail, the new heap size sees no failures.

@Arraying 
Your change (at version 9e06266ca7abb57c9add2f4b57c3324a91ac32fd) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1574#issuecomment-3285451657

From dsimms at openjdk.org  Fri Sep 12 14:16:43 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 12 Sep 2025 14:16:43 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <aeEILWJt7PvzYQKXaHXNNhJA712geVOFzPw01_bJ7kk=.ec1d8e0f-b8be-46aa-9e41-2aa8741f4663@github.com>

Merge tag 'jdk-26+5' into lworld_merge_jdk_26_5

Added tag jdk-26+5 for changeset 5e40fb6b

-------------

Commit messages:
 - Merge jdk
 - 8277394: Remove the use of safepoint_workers in reference processor
 - 8361198: [AIX] fix misleading error output in thread_cpu_time_unchecked
 - 8361060: Keep track of the origin server against which a jdk.internal.net.http.HttpConnection was constructed
 - 8361037: [ubsan] compiler/c2/irTests/TestFloat16ScalarOperations division by 0
 - 8359602: Ideal optimizations depending on input type are missed because of missing notification mechanism from CCP
 - 8358801: javac produces class that does not pass verifier.
 - 8361238: G1 tries to get CPU info from terminated threads at shutdown
 - 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java
 - 8358183: [JVMCI] crash accessing nmethod::jvmci_name in CodeCache::aggregate
 - ... and 72 more: https://git.openjdk.org/valhalla/compare/c3bad8fc...45762586

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1580&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1580&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/1580/files
  Stats: 8764 lines in 395 files changed: 4802 ins; 2147 del; 1815 mod
  Patch: https://git.openjdk.org/valhalla/pull/1580.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1580/head:pull/1580

PR: https://git.openjdk.org/valhalla/pull/1580

From duke at openjdk.org  Fri Sep 12 14:19:41 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 12 Sep 2025 14:19:41 GMT
Subject: [lworld] RFR: 8367551: Cherrypick ImageReader refactoring PR
 (JDK-8360037)
Message-ID: <-ilCJkdPT1xOAe4BzweCPz2T5KasfsRSeqmpRqif6aU=.ebd07cf1-f36b-4bdc-a80c-b57c341b383d@github.com>

Cherry pick ImageReader work to unblock progress on preview mode in Valhalla.

-------------

Commit messages:
 - Cherrypick ImageReader refactoring (JDK-8360037)

Changes: https://git.openjdk.org/valhalla/pull/1581/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1581&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367551
  Stats: 2319 lines in 10 files changed: 1702 ins; 369 del; 248 mod
  Patch: https://git.openjdk.org/valhalla/pull/1581.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1581/head:pull/1581

PR: https://git.openjdk.org/valhalla/pull/1581

From coleenp at openjdk.org  Fri Sep 12 14:32:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Sep 2025 14:32:29 GMT
Subject: [lworld] RFR: 8294051: [lworld] runtime/AccModule/ConstModule.java
 fails with incorrect error message [v2]
In-Reply-To: <ZlKcpy2DJj19NLJftm78XapaFShlesJNjlkiFJ4ZPSU=.a8f622ec-0712-4cee-b2ae-5d722875e571@github.com>
References: <dwlACEOgpPbSZUEwRxZw5gL_RsjRuEwwHuLAN3uFpU8=.743b0dc8-73c9-499e-82ea-a8c958a0e3c6@github.com>
 <ZlKcpy2DJj19NLJftm78XapaFShlesJNjlkiFJ4ZPSU=.a8f622ec-0712-4cee-b2ae-5d722875e571@github.com>
Message-ID: <0940fdY5-wgtnB3PcKaEpnmXdzNDeYCGaZr9cedm-XE=.6e8ec284-4820-43db-9eaa-a22e1070f0f9@github.com>

On Fri, 5 Sep 2025 19:51:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change moves code back to match mainline that checks access flags and checks for invalid JVM_CONSTANTS_Module/Package before reading the class name out of the constant pool.
>> Tested with tier1-3.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra error message printing for inner classes not in mainline.

Thanks for reviewing Simms and your comments, Fred.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1550#issuecomment-3285511491

From coleenp at openjdk.org  Fri Sep 12 14:32:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Sep 2025 14:32:30 GMT
Subject: [lworld] RFR: 8294051: [lworld] runtime/AccModule/ConstModule.java
 fails with incorrect error message [v2]
In-Reply-To: <zBiS8Zr59Io8WqjJa_8sLxthpq1nyq1BhqdA7f8WkrU=.ac704421-23df-4a43-b575-5050228e00b8@github.com>
References: <dwlACEOgpPbSZUEwRxZw5gL_RsjRuEwwHuLAN3uFpU8=.743b0dc8-73c9-499e-82ea-a8c958a0e3c6@github.com>
 <ZlKcpy2DJj19NLJftm78XapaFShlesJNjlkiFJ4ZPSU=.a8f622ec-0712-4cee-b2ae-5d722875e571@github.com>
 <Lqjh48WFPEOy7A67Gyw-pa5vbA77mxhyMA6sVblrgdI=.e7acceb8-879a-4bdf-95c9-b8023f7b1657@github.com>
 <9WzNCEChUd3BF408cIPGApv0syVRk-sDOcTWtplkyAM=.6de8c76c-1911-45de-afff-5039ae192639@github.com>
 <zBiS8Zr59Io8WqjJa_8sLxthpq1nyq1BhqdA7f8WkrU=.ac704421-23df-4a43-b575-5050228e00b8@github.com>
Message-ID: <5rSPUXx6JibbZU2fl8DyNyc5b0nDdV-CCAvOjqtkKoA=.e93a4500-a9db-4980-86b8-6740eebfd5f5@github.com>

On Wed, 10 Sep 2025 18:32:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is something we don't have in mainline.  I can add it there instead and it'll get merged in here.
>
> https://bugs.openjdk.org/browse/JDK-8367368

Done.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1550#discussion_r2344431843

From coleenp at openjdk.org  Fri Sep 12 14:32:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Sep 2025 14:32:32 GMT
Subject: [lworld] Integrated: 8294051: [lworld]
 runtime/AccModule/ConstModule.java fails with incorrect error message
In-Reply-To: <dwlACEOgpPbSZUEwRxZw5gL_RsjRuEwwHuLAN3uFpU8=.743b0dc8-73c9-499e-82ea-a8c958a0e3c6@github.com>
References: <dwlACEOgpPbSZUEwRxZw5gL_RsjRuEwwHuLAN3uFpU8=.743b0dc8-73c9-499e-82ea-a8c958a0e3c6@github.com>
Message-ID: <GCeVZWM_CvTm9X9foMV44t0cXidrw3c8qUtdlyqdILQ=.7bacb43a-7a9e-4828-8f2d-9219a5f81c1e@github.com>

On Fri, 5 Sep 2025 18:36:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change moves code back to match mainline that checks access flags and checks for invalid JVM_CONSTANTS_Module/Package before reading the class name out of the constant pool.
> Tested with tier1-3.

This pull request has now been integrated.

Changeset: 446d7d55
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/446d7d556a378ca09bc3b52777f188861c49ec0d
Stats:     65 lines in 3 files changed: 17 ins; 34 del; 14 mod

8294051: [lworld] runtime/AccModule/ConstModule.java fails with incorrect error message

Reviewed-by: dsimms

-------------

PR: https://git.openjdk.org/valhalla/pull/1550

From coleenp at openjdk.org  Fri Sep 12 14:33:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Sep 2025 14:33:57 GMT
Subject: [lworld] RFR: 8328777: [lworld]
 TestSyncOnValueBasedClassEvent.java fails with Exception
In-Reply-To: <CH0evI6DLL0EYgBXxJpsEGkg0mDyI-gN_hBkmFqylp0=.618ff8e1-47cf-41d2-9c22-97445796712e@github.com>
References: <CH0evI6DLL0EYgBXxJpsEGkg0mDyI-gN_hBkmFqylp0=.618ff8e1-47cf-41d2-9c22-97445796712e@github.com>
Message-ID: <KQEYYxxRfpEU0kLTCO9F1TCkhH3l42as1quaAptXie4=.26c5b433-bc67-49c1-b855-bc2edc50bc42@github.com>

On Tue, 9 Sep 2025 20:44:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This test doesn't make sense to run with --enable-preview because the option it's testing isn't valid in preview mode.  If there is synchronization on the value class, then the JVM throws IdentityException and cannot continue and log or emit a JFR event for it.

Thanks, Paul!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1558#issuecomment-3285520367

From coleenp at openjdk.org  Fri Sep 12 14:33:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Sep 2025 14:33:58 GMT
Subject: [lworld] Integrated: 8328777: [lworld]
 TestSyncOnValueBasedClassEvent.java fails with Exception
In-Reply-To: <CH0evI6DLL0EYgBXxJpsEGkg0mDyI-gN_hBkmFqylp0=.618ff8e1-47cf-41d2-9c22-97445796712e@github.com>
References: <CH0evI6DLL0EYgBXxJpsEGkg0mDyI-gN_hBkmFqylp0=.618ff8e1-47cf-41d2-9c22-97445796712e@github.com>
Message-ID: <mklBf5JvXQMIjl6xVpMsaUuQ6f2PVtnSdX9fOnuLLGQ=.ecfc4a6b-620c-49e4-a444-41b5e0c00adc@github.com>

On Tue, 9 Sep 2025 20:44:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This test doesn't make sense to run with --enable-preview because the option it's testing isn't valid in preview mode.  If there is synchronization on the value class, then the JVM throws IdentityException and cannot continue and log or emit a JFR event for it.

This pull request has now been integrated.

Changeset: 0836ed54
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0836ed54be3ed832e28500648c9eca5bc4dc86cc
Stats:     4 lines in 2 files changed: 1 ins; 3 del; 0 mod

8328777: [lworld] TestSyncOnValueBasedClassEvent.java fails with Exception

Reviewed-by: phubner

-------------

PR: https://git.openjdk.org/valhalla/pull/1558

From pchilanomate at openjdk.org  Fri Sep 12 14:36:29 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 12 Sep 2025 14:36:29 GMT
Subject: [lworld] RFR: 8336845: [lworld] Virtual threads don't support the
 value class calling convention [v2]
In-Reply-To: <rHMBAqt-Ye3PHjUPV8MVvT_WuQmYZ3ndHZooAjTuLG4=.7f2f7f40-9f1d-4856-912f-4cc69d9e58fb@github.com>
References: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
 <rHMBAqt-Ye3PHjUPV8MVvT_WuQmYZ3ndHZooAjTuLG4=.7f2f7f40-9f1d-4856-912f-4cc69d9e58fb@github.com>
Message-ID: <27s6k2CCY7kHDMxzhs6X9OmuwNefD_0XjSaE482l-p8=.63448f98-38af-4f3e-8819-6dfea03becc5@github.com>

On Thu, 11 Sep 2025 23:59:00 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review the following patch which adds virtual thread support for the value class calling convention. Most of the changes are needed to handle extended frames, i.e c1 or c2 frames that use more stack space for arguments than the stack space allocated by the caller. These include changes in freeze and thaw code, plus changes in the stackChunk walking code where we now need a similar repair of the caller sp as in the current sender code. In this case though, we only adjust _unextended_sp and keep the value of _sp. This is because frames are walked without a full RegisterMap, but we still need to be able to access the saved fp in the callee for gc purposes. The remaining changes deal with saving and restoring the extra return registers when calling thaw.
>> 
>> Thanks to Tobias for working on the initial changes and for providing the very useful new test TestVirtualThreads.java, included in this PR, which has been great for catching many bugs. I also run the changes with the valhalla-comp-stress job in mach5. It uncovered a couple of extra failures in TestVirtualThreads.java, but I was able to reproduce them with platform threads as well (8367151 and 8367258). I also added extra testing for value classes in existing test Fuzz.java which has proven very useful too.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add string to assert in is_in_frame()

Thanks Coleen!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1556#issuecomment-3285519960

From pchilanomate at openjdk.org  Fri Sep 12 14:36:31 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 12 Sep 2025 14:36:31 GMT
Subject: [lworld] Integrated: 8336845: [lworld] Virtual threads don't support
 the value class calling convention
In-Reply-To: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
References: <lY7sZ79QL1mOVdLwjbbnYXPubxFbmIwtJZDWpldTEpY=.aed7b3e6-dd2e-4302-a32f-32213cdc7837@github.com>
Message-ID: <36rNvHgOdc4qzEkXzgxtFjHc-fA4BwC3C970Z5zdFmc=.7115cf15-3cf1-4c78-ad8f-812196ded1b8@github.com>

On Tue, 9 Sep 2025 12:50:49 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following patch which adds virtual thread support for the value class calling convention. Most of the changes are needed to handle extended frames, i.e c1 or c2 frames that use more stack space for arguments than the stack space allocated by the caller. These include changes in freeze and thaw code, plus changes in the stackChunk walking code where we now need a similar repair of the caller sp as in the current sender code. In this case though, we only adjust _unextended_sp and keep the value of _sp. This is because frames are walked without a full RegisterMap, but we still need to be able to access the saved fp in the callee for gc purposes. The remaining changes deal with saving and restoring the extra return registers when calling thaw.
> 
> Thanks to Tobias for working on the initial changes and for providing the very useful new test TestVirtualThreads.java, included in this PR, which has been great for catching many bugs. I also run the changes with the valhalla-comp-stress job in mach5. It uncovered a couple of extra failures in TestVirtualThreads.java, but I was able to reproduce them with platform threads as well (8367151 and 8367258). I also added extra testing for value classes in existing test Fuzz.java which has proven very useful too.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 11cee9ea
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/11cee9eaf97fd211bec756e1c7dc601dcc597903
Stats:     1443 lines in 25 files changed: 1304 ins; 57 del; 82 mod

8336845: [lworld] Virtual threads don't support the value class calling convention

Co-authored-by: Tobias Hartmann <thartmann at openjdk.org>
Reviewed-by: thartmann, coleenp

-------------

PR: https://git.openjdk.org/valhalla/pull/1556

From dsimms at openjdk.org  Fri Sep 12 15:08:46 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 12 Sep 2025 15:08:46 GMT
Subject: [lworld] RFR: 8367551: Cherrypick ImageReader refactoring PR
 (JDK-8360037)
In-Reply-To: <-ilCJkdPT1xOAe4BzweCPz2T5KasfsRSeqmpRqif6aU=.ebd07cf1-f36b-4bdc-a80c-b57c341b383d@github.com>
References: <-ilCJkdPT1xOAe4BzweCPz2T5KasfsRSeqmpRqif6aU=.ebd07cf1-f36b-4bdc-a80c-b57c341b383d@github.com>
Message-ID: <7YaYJ0iUXlLoXtqI_JRakcIDnz7yur_PVvwHHcxrvWk=.70a976b7-c601-4233-8890-49b5aab1519e@github.com>

On Fri, 12 Sep 2025 14:12:00 GMT, David Beaumont <duke at openjdk.org> wrote:

> Cherry pick ImageReader work to unblock progress on preview mode in Valhalla.

Marked as reviewed by dsimms (Committer).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1581#pullrequestreview-3217146102

From duke at openjdk.org  Fri Sep 12 15:08:46 2025
From: duke at openjdk.org (duke)
Date: Fri, 12 Sep 2025 15:08:46 GMT
Subject: [lworld] RFR: 8367551: Cherrypick ImageReader refactoring PR
 (JDK-8360037)
In-Reply-To: <-ilCJkdPT1xOAe4BzweCPz2T5KasfsRSeqmpRqif6aU=.ebd07cf1-f36b-4bdc-a80c-b57c341b383d@github.com>
References: <-ilCJkdPT1xOAe4BzweCPz2T5KasfsRSeqmpRqif6aU=.ebd07cf1-f36b-4bdc-a80c-b57c341b383d@github.com>
Message-ID: <qLcQAQVI_t5zu38zwebVPafZijMOJ6snRXhd1x1JhJg=.658da4d0-0b22-421a-b5ea-19f69dc827db@github.com>

On Fri, 12 Sep 2025 14:12:00 GMT, David Beaumont <duke at openjdk.org> wrote:

> Cherry pick ImageReader work to unblock progress on preview mode in Valhalla.

@david-beaumont 
Your change (at version cd9a73386203401e93b2836c7fb2b212fa5dfa4e) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1581#issuecomment-3285650230

From dsimms at openjdk.org  Fri Sep 12 15:10:50 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 12 Sep 2025 15:10:50 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <aeEILWJt7PvzYQKXaHXNNhJA712geVOFzPw01_bJ7kk=.ec1d8e0f-b8be-46aa-9e41-2aa8741f4663@github.com>
References: <aeEILWJt7PvzYQKXaHXNNhJA712geVOFzPw01_bJ7kk=.ec1d8e0f-b8be-46aa-9e41-2aa8741f4663@github.com>
Message-ID: <cwhsNhjNCv_CHsree0JQ-sTmgfLgWvD89xA6LJRI3w8=.c0a6d1a4-ea62-474d-8ce8-b90f9ba946a2@github.com>

On Fri, 12 Sep 2025 14:07:48 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-26+5' into lworld_merge_jdk_26_5
> 
> Added tag jdk-26+5 for changeset 5e40fb6b

This pull request has now been integrated.

Changeset: 09637e0e
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/09637e0e5970fc79f8edf7c458cd1a8e66f30463
Stats:     8764 lines in 395 files changed: 4802 ins; 2147 del; 1815 mod

Merge jdk

Merge jdk-26+5

-------------

PR: https://git.openjdk.org/valhalla/pull/1580

From duke at openjdk.org  Fri Sep 12 15:12:47 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 12 Sep 2025 15:12:47 GMT
Subject: [lworld] Integrated: 8367551: Cherrypick ImageReader refactoring PR
 (JDK-8360037)
In-Reply-To: <-ilCJkdPT1xOAe4BzweCPz2T5KasfsRSeqmpRqif6aU=.ebd07cf1-f36b-4bdc-a80c-b57c341b383d@github.com>
References: <-ilCJkdPT1xOAe4BzweCPz2T5KasfsRSeqmpRqif6aU=.ebd07cf1-f36b-4bdc-a80c-b57c341b383d@github.com>
Message-ID: <zjCqo6L1nlydJjXkzVKaAAjFbWSnY8nUhogZU59U6MU=.fb27efd6-073f-4847-9b90-5c0cf21c04ea@github.com>

On Fri, 12 Sep 2025 14:12:00 GMT, David Beaumont <duke at openjdk.org> wrote:

> Cherry pick ImageReader work to unblock progress on preview mode in Valhalla.

This pull request has now been integrated.

Changeset: de62c5dc
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/de62c5dcb1875739d776d1c93fb292e2115169c1
Stats:     2319 lines in 10 files changed: 1702 ins; 369 del; 248 mod

8367551: Cherrypick ImageReader refactoring PR (JDK-8360037)

Reviewed-by: dsimms

-------------

PR: https://git.openjdk.org/valhalla/pull/1581

From phubner at openjdk.org  Fri Sep 12 15:16:42 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Sep 2025 15:16:42 GMT
Subject: [lworld] Integrated: 8341846: [lworld]
 compiler/valhalla/inlinetypes/TestStressReturnBuffering.java fails to boot
 with genzgc
In-Reply-To: <4hstsNqBFcs94tQthZfLz7p2A3VUGt5xNKkQJPlTHv0=.87807241-bb2b-44d4-8a14-1f405046b9a6@github.com>
References: <4hstsNqBFcs94tQthZfLz7p2A3VUGt5xNKkQJPlTHv0=.87807241-bb2b-44d4-8a14-1f405046b9a6@github.com>
Message-ID: <VJxqpZ4yX1Ir_uQ89MUBx8MdcLtXvMOeS8ybsgjrLG8=.3475066b-9634-46ab-8495-a4aa8d99c7a8@github.com>

On Thu, 11 Sep 2025 13:46:50 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The test `compiler/valhalla/inlinetypes/TestStressReturnBuffering.java` was intermittently failing on all platforms if run enough. This patch increases the memory by 50%, leaving nonetheless a very small heap.
> 
> I've run it with the new flag on Linux x64, macOS x64, and Windows x64, 5x 100 iterations on each platform. While with the old heap size this would consistently fail, the new heap size sees no failures.

This pull request has now been integrated.

Changeset: 28b96c08
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/28b96c080081b8ebab2656d5dc0f904072d15e40
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8341846: [lworld] compiler/valhalla/inlinetypes/TestStressReturnBuffering.java fails to boot with genzgc

Reviewed-by: coleenp

-------------

PR: https://git.openjdk.org/valhalla/pull/1574

From vromero at openjdk.org  Fri Sep 12 15:18:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Sep 2025 15:18:51 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code after
 fix for JDK-8359370
Message-ID: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>

Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:

class SuperClass<T> {
    public SuperClass(Object o) {}
}

class Sub<T> extends SuperClass<T> {
    public Sub() {
        super(new Object() {
            void foo() {
                getClass();
            }
        });
    }
}


but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`

-------------

Commit messages:
 - Update test/langtools/tools/javac/SuperInit/SuperInitFails.java
 - Update test/langtools/tools/javac/SuperInit/SuperInitFails.java
 - addressing review comments
 - addressing review comments
 - simplifying test
 - 8367323: [lworld] javac is rejecting valid code after fix for JDK-8359370

Changes: https://git.openjdk.org/valhalla/pull/1567/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1567&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367323
  Stats: 29 lines in 4 files changed: 25 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/1567.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1567/head:pull/1567

PR: https://git.openjdk.org/valhalla/pull/1567

From liach at openjdk.org  Fri Sep 12 15:18:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 12 Sep 2025 15:18:53 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370
In-Reply-To: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
Message-ID: <jIzyHjHAV0QLxtlDli-SVueA97lTwKCXwjO4_xmDQCw=.addfbec8-8208-4a82-9624-0f62a7f4c9b9@github.com>

On Thu, 11 Sep 2025 02:14:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
> 
> class SuperClass<T> {
>     public SuperClass(Object o) {}
> }
> 
> class Sub<T> extends SuperClass<T> {
>     public Sub() {
>         super(new Object() {
>             void foo() {
>                 getClass();
>             }
>         });
>     }
> }
> 
> 
> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`

Looks like a very neat solution, thanks so much!

Does the problem still happen without the patch if the method call is to a method that is not present on the outer class? I wonder if we should tweak the `sym.isMemberOf(env.enclClass.sym, types)` part.

Wonder if this can help the bot fetch the JBS issue.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1276:

> 1274: 
> 1275:         boolean insideLambda = false;
> 1276:         boolean insideClassDef = false;

We can revert this split of insideLambda and insideClassDef now.

test/langtools/tools/javac/SuperInit/SuperInitFails.out line 21:

> 19: SuperInitFails.java:180:18: compiler.err.cant.ref.before.ctor.called: x
> 20: SuperInitFails.java:186:32: compiler.err.cant.ref.before.ctor.called: x
> 21: SuperInitFails.java:195:36: compiler.err.cant.ref.before.ctor.called: xx

We should update the comment at https://github.com/openjdk/valhalla/blob/63649dca75abe099fedebbe14140d0da46fda5ea/test/langtools/tools/javac/SuperInit/SuperInitFails.java#L195 to something like:

> // this should resolve to the anonymous class's inherited xx fields

-------------

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1567#pullrequestreview-3213577511
PR Comment: https://git.openjdk.org/valhalla/pull/1567#issuecomment-3277537982
PR Comment: https://git.openjdk.org/valhalla/pull/1567#issuecomment-3285677684
PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2341912903
PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2341911196

From mcimadamore at openjdk.org  Fri Sep 12 15:18:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 12 Sep 2025 15:18:56 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370
In-Reply-To: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
Message-ID: <7pyk_iAXoX0fdEq-4meS3a0eTr2_V7nmq06yFpY7vSo=.197e9fd6-5f38-4424-ab34-b26f4aff4f81@github.com>

On Thu, 11 Sep 2025 02:14:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
> 
> class SuperClass<T> {
>     public SuperClass(Object o) {}
> }
> 
> class Sub<T> extends SuperClass<T> {
>     public Sub() {
>         super(new Object() {
>             void foo() {
>                 getClass();
>             }
>         });
>     }
> }
> 
> 
> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`

Looks good!

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1477:

> 1475:                  * the compiler
> 1476:                  */
> 1477:                 return sym.kind != MTH || !insideClassDef;

I think the "right" thing to do here seems to have to do with membership and whether the access is unqualified or not.

E.g. 
* if we are in the prologue of `A`, and we see a call to `m()`, and `m()` is a member of `A`, then we should fail
* if we are in a class `B` inside the prologue of `A`, and we see a call to `m()`, and `m()` is a member of `B`, then it should be ok
* if we are in a class `B` inside the prologue of `A`, and we see a call to `m()`, and `m()` is a member of _both_ `B` and `A`, then it should be ok
* if we are in a class `B` inside the prologue of `A`, and we see a call to `m()`, and `m()` is a member of `A` then it should fail

The problem seems to be that, by the time we hit the `isEarlyReference` method, we no longer know the "current class" -- so we always check membership against the "outer" class whose prologue we're inspecting.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1478:

> 1476:                     return TreeInfo.isExplicitThisReference(types, (ClassType)env.enclClass.type, fa.selected);
> 1477:                 }
> 1478:                 if (currentClassSym != env.enclClass.sym) {

stylistic (and optional). In a way, if we added that as part of an `else if` it would make it clear that we're in an "implicit" qualifier case (e.g. simple name). Also, maybe adding a one line comment about why we're doing the extra check might be helpful for future reference.

-------------

Marked as reviewed by mcimadamore (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1567#pullrequestreview-3216409900
PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2339555659
PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2344073174

From vromero at openjdk.org  Fri Sep 12 15:18:57 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Sep 2025 15:18:57 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370
In-Reply-To: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
Message-ID: <rr868BTguM8jI8KCRgXydWxjnMrr6mEaPmAvoPH2pq8=.efbd3ebe-3069-42d5-a157-75d00a5a41ee@github.com>

On Thu, 11 Sep 2025 02:14:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
> 
> class SuperClass<T> {
>     public SuperClass(Object o) {}
> }
> 
> class Sub<T> extends SuperClass<T> {
>     public Sub() {
>         super(new Object() {
>             void foo() {
>                 getClass();
>             }
>         });
>     }
> }
> 
> 
> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`

thanks guys for the review

test/langtools/tools/javac/SuperInit/SuperInitFails.java line 195:

> 193:         int i = new SuperInitFails(){
> 194:             void foo() {
> 195:                 System.err.println(xx);  // this one is OK, xx field in the anonymous class

Suggestion:

                System.err.println(xx);  // this one is OK, reading field `xx` in the anonymous class

test/langtools/tools/javac/SuperInit/SuperInitFails.java line 197:

> 195:                 System.err.println(xx);  // this one is OK, reading field `xx` in the anonymous class
> 196:             }
> 197:         }.xx;  // this one is OK, too, field of a fully constructed class

Suggestion:

        }.xx;  // this one is OK too, field of a fully constructed class

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1567#issuecomment-3285063582
PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2342180019
PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2342181644

From vromero at openjdk.org  Fri Sep 12 15:18:59 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Sep 2025 15:18:59 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370
In-Reply-To: <7pyk_iAXoX0fdEq-4meS3a0eTr2_V7nmq06yFpY7vSo=.197e9fd6-5f38-4424-ab34-b26f4aff4f81@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
 <7pyk_iAXoX0fdEq-4meS3a0eTr2_V7nmq06yFpY7vSo=.197e9fd6-5f38-4424-ab34-b26f4aff4f81@github.com>
Message-ID: <ySBqwiVJWxO-2h1r_2iZXsqDNx7lauiM3-Cp298cbGc=.17ad3fd8-4996-4873-a77d-d284b026551a@github.com>

On Thu, 11 Sep 2025 08:53:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
>> 
>> class SuperClass<T> {
>>     public SuperClass(Object o) {}
>> }
>> 
>> class Sub<T> extends SuperClass<T> {
>>     public Sub() {
>>         super(new Object() {
>>             void foo() {
>>                 getClass();
>>             }
>>         });
>>     }
>> }
>> 
>> 
>> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1477:
> 
>> 1475:                  * the compiler
>> 1476:                  */
>> 1477:                 return sym.kind != MTH || !insideClassDef;
> 
> I think the "right" thing to do here seems to have to do with membership and whether the access is unqualified or not.
> 
> E.g. 
> * if we are in the prologue of `A`, and we see a call to `m()`, and `m()` is a member of `A`, then we should fail
> * if we are in a class `B` inside the prologue of `A`, and we see a call to `m()`, and `m()` is a member of `B`, then it should be ok
> * if we are in a class `B` inside the prologue of `A`, and we see a call to `m()`, and `m()` is a member of _both_ `B` and `A`, then it should be ok
> * if we are in a class `B` inside the prologue of `A`, and we see a call to `m()`, and `m()` is a member of `A` then it should fail
> 
> The problem seems to be that, by the time we hit the `isEarlyReference` method, we no longer know the "current class" -- so we always check membership against the "outer" class whose prologue we're inspecting.

I have updated the PR there is a test case that was failing before but now is passing:

class Test {
    public int xx;

    Test() {
        int i = new Test(){
            void foo() {
                System.err.println(xx);
            }
        }.xx;
        super();
    }
}

I think that it is correct that we accept this code as in both cases we are accessing the `xx` field inherited by the anonymous class

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2341885465

From mcimadamore at openjdk.org  Fri Sep 12 15:19:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 12 Sep 2025 15:19:00 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370
In-Reply-To: <ySBqwiVJWxO-2h1r_2iZXsqDNx7lauiM3-Cp298cbGc=.17ad3fd8-4996-4873-a77d-d284b026551a@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
 <7pyk_iAXoX0fdEq-4meS3a0eTr2_V7nmq06yFpY7vSo=.197e9fd6-5f38-4424-ab34-b26f4aff4f81@github.com>
 <ySBqwiVJWxO-2h1r_2iZXsqDNx7lauiM3-Cp298cbGc=.17ad3fd8-4996-4873-a77d-d284b026551a@github.com>
Message-ID: <GkneocuCuVYa7W8EabZ_dLDHHlxcGPP6iSQj9TUzaDE=.bb2c3977-762d-4375-9a99-ca20e4cd1883@github.com>

On Thu, 11 Sep 2025 17:35:55 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1477:
>> 
>>> 1475:                  * the compiler
>>> 1476:                  */
>>> 1477:                 return sym.kind != MTH || !insideClassDef;
>> 
>> I think the "right" thing to do here seems to have to do with membership and whether the access is unqualified or not.
>> 
>> E.g. 
>> * if we are in the prologue of `A`, and we see a call to `m()`, and `m()` is a member of `A`, then we should fail
>> * if we are in a class `B` inside the prologue of `A`, and we see a call to `m()`, and `m()` is a member of `B`, then it should be ok
>> * if we are in a class `B` inside the prologue of `A`, and we see a call to `m()`, and `m()` is a member of _both_ `B` and `A`, then it should be ok
>> * if we are in a class `B` inside the prologue of `A`, and we see a call to `m()`, and `m()` is a member of `A` then it should fail
>> 
>> The problem seems to be that, by the time we hit the `isEarlyReference` method, we no longer know the "current class" -- so we always check membership against the "outer" class whose prologue we're inspecting.
>
> I have updated the PR there is a test case that was failing before but now is passing:
> 
> class Test {
>     public int xx;
> 
>     Test() {
>         int i = new Test(){
>             void foo() {
>                 System.err.println(xx);
>             }
>         }.xx;
>         super();
>     }
> }
> 
> I think that it is correct that we accept this code as in both cases we are accessing the `xx` field inherited by the anonymous class

yes, the accessed `xx` is _another_ field

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2344048138

From mcimadamore at openjdk.org  Fri Sep 12 15:19:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 12 Sep 2025 15:19:01 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370
In-Reply-To: <7pyk_iAXoX0fdEq-4meS3a0eTr2_V7nmq06yFpY7vSo=.197e9fd6-5f38-4424-ab34-b26f4aff4f81@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
 <7pyk_iAXoX0fdEq-4meS3a0eTr2_V7nmq06yFpY7vSo=.197e9fd6-5f38-4424-ab34-b26f4aff4f81@github.com>
Message-ID: <qee01Ca1D9ES6vcH12faDXFIu-sAJv5leWiFDpAG8G8=.6f105134-d11a-483f-8860-71737c649121@github.com>

On Fri, 12 Sep 2025 12:18:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
>> 
>> class SuperClass<T> {
>>     public SuperClass(Object o) {}
>> }
>> 
>> class Sub<T> extends SuperClass<T> {
>>     public Sub() {
>>         super(new Object() {
>>             void foo() {
>>                 getClass();
>>             }
>>         });
>>     }
>> }
>> 
>> 
>> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1478:
> 
>> 1476:                     return TreeInfo.isExplicitThisReference(types, (ClassType)env.enclClass.type, fa.selected);
>> 1477:                 }
>> 1478:                 if (currentClassSym != env.enclClass.sym) {
> 
> stylistic (and optional). In a way, if we added that as part of an `else if` it would make it clear that we're in an "implicit" qualifier case (e.g. simple name). Also, maybe adding a one line comment about why we're doing the extra check might be helpful for future reference.

Question: can we ever get here for a static symbol? I think for statics we should never run `analyzeSymbol` right? I'm not sure: `analyzeSymbol` seems called regardless of static-ness. Then it has two checks inside, one for writes and another for reads. The check for reads excludes `static` symbols, but the check for writes doesn't? I think we should maybe write some tests where we assign to a static field from a prologue :-)

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2344077216

From mcimadamore at openjdk.org  Fri Sep 12 15:19:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 12 Sep 2025 15:19:01 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370
In-Reply-To: <qee01Ca1D9ES6vcH12faDXFIu-sAJv5leWiFDpAG8G8=.6f105134-d11a-483f-8860-71737c649121@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
 <7pyk_iAXoX0fdEq-4meS3a0eTr2_V7nmq06yFpY7vSo=.197e9fd6-5f38-4424-ab34-b26f4aff4f81@github.com>
 <qee01Ca1D9ES6vcH12faDXFIu-sAJv5leWiFDpAG8G8=.6f105134-d11a-483f-8860-71737c649121@github.com>
Message-ID: <mZ2KTUl_vroDJ0_Boz475jKIVStIsycWzrwKGoAfeOM=.9f7af448-4ff8-40d4-b859-9a91b8f0856b@github.com>

On Fri, 12 Sep 2025 12:19:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1478:
>> 
>>> 1476:                     return TreeInfo.isExplicitThisReference(types, (ClassType)env.enclClass.type, fa.selected);
>>> 1477:                 }
>>> 1478:                 if (currentClassSym != env.enclClass.sym) {
>> 
>> stylistic (and optional). In a way, if we added that as part of an `else if` it would make it clear that we're in an "implicit" qualifier case (e.g. simple name). Also, maybe adding a one line comment about why we're doing the extra check might be helpful for future reference.
>
> Question: can we ever get here for a static symbol? I think for statics we should never run `analyzeSymbol` right? I'm not sure: `analyzeSymbol` seems called regardless of static-ness. Then it has two checks inside, one for writes and another for reads. The check for reads excludes `static` symbols, but the check for writes doesn't? I think we should maybe write some tests where we assign to a static field from a prologue :-)

E.g. what I'm referring to is this:
https://github.com/openjdk/valhalla/pull/1567/files#L1395
What happens if `sym` is static?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2344085224

From liach at openjdk.org  Fri Sep 12 15:29:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 12 Sep 2025 15:29:44 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370
In-Reply-To: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
Message-ID: <JMZ__BEWHC78bTaKd5MR7cf5gcpIUKrpNnCW9PyX7R0=.6d05dce8-c853-4110-82a5-8e8363875fea@github.com>

On Thu, 11 Sep 2025 02:14:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
> 
> class SuperClass<T> {
>     public SuperClass(Object o) {}
> }
> 
> class Sub<T> extends SuperClass<T> {
>     public Sub() {
>         super(new Object() {
>             void foo() {
>                 getClass();
>             }
>         });
>     }
> }
> 
> 
> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`

Seems the bot fixes itself. Now we are ready to merge this fix.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1567#issuecomment-3285725329

From chagedorn at openjdk.org  Fri Sep 12 15:58:20 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 12 Sep 2025 15:58:20 GMT
Subject: [lworld] RFR: 8367548: compiler/intrinsics/bmi tests fail with
 -XX:+AOTClassLinking
Message-ID: <HCaYw65hb4zqL02Wz4NkdA6FTbH5Y2HABZMtk8WuGjY=.ae76e5fa-3b04-48ee-9308-4df81e2e3d3f@github.com>

The `compiler/intrinsics/bmi` tests started to fail with new AOT changes merged in. 

### AOT Warnings with Valhalla due to Adapter Hash Collision
>From the log messages, I saw that we have the following warning message printed with UL:

'[0.020s][warning][aot,codecache,stubs] Saved blob's name 'IIIIIIIL' is different from the expected name 'LIIIIIII'

This warning can be traced back to a collision in caching adapters with AOT where two adapters have the same hash. As a result, we need to drop one of the adapters in the AOT cache which is unfortunate but not a problem in correctness. This hash collision seems to be specific to Valhalla because we have a lot more adapters compared to mainline. There is currently an open RFE in mainline ([JDK-8364929](https://bugs.openjdk.org/browse/JDK-8364929)) which tries to improve the situation to give each adapters a unique id.

###  Comparison of `Xint` and `Xcomp` Output Fails due to different Timestamps
The `compiler/intrinsics/bmi` tests call `BMITestRunner` which will run the same test with `-Xint` and `-Xcomp` and then compare the output:
https://github.com/openjdk/valhalla/blob/28b96c080081b8ebab2656d5dc0f904072d15e40/test/hotspot/jtreg/compiler/intrinsics/bmi/BMITestRunner.java#L87-L100
We see the AOT warning actually in both runs. The comparison fails because we have a different timestamp in the log for `-Xint` and `-Xcomp`:

[0.020s][warning][aot,codecache,stubs] Saved blob's name 'IIIIIIIL' is different from the expected name 'LIIIIIII'
[0.013s][warning][aot,codecache,stubs] Saved blob's name 'IIIIIIIL' is different from the expected name 'LIIIIIII'

So, the fix would be to get rid of the timestamps. 

### Getting Rid of Timestamps already Implemented but Wrongly
However, we already have some special code that actually wants to remove timestamps and all AOT logs altogether (introduced with https://github.com/openjdk/valhalla/commit/3b32f6a8ec37338764d3e6713247ff96e49bf5b3 for some Graal specific failure) :
https://github.com/openjdk/valhalla/blob/28b96c080081b8ebab2656d5dc0f904072d15e40/test/hotspot/jtreg/compiler/intrinsics/bmi/BMITestRunner.java#L125-L129
But this does not seem to work. I played around with `Xlog` and found that surprisingly this:

-Xlog:all=warning:stdout:level,tags -Xlog:aot=off

seems to be expanded to

-Xlog:all=warning:stdout:level,tags -Xlog:aot=off:stdout:<default decorators>

and the second `Xlog` overrides the decorators and reintroduces the timestamps again.

### Proposed Fix
The fix is to use one `Xlog` like this:

-Xlog:all=warning,aot=off:stdout:level,tags

I tested tier5 where the tests failed with `-XX:+AOTClassLinking` and this solved the issue.

### Only Apply to Valhalla and not Mainline
I'm not sure why the test was not failing in mainline anymore. Maybe it was too intermittent and thus not noticed again. We could also fix this bug in mainline but since it's only failing in Valhalla, I suggest to do a point fix here and not upstream it to mainline for now.

Thanks,
Christian

-------------

Commit messages:
 - 8367548: compiler/intrinsics/bmi tests fail with -XX:+AOTClassLinking

Changes: https://git.openjdk.org/valhalla/pull/1582/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1582&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367548
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1582.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1582/head:pull/1582

PR: https://git.openjdk.org/valhalla/pull/1582

From mchevalier at openjdk.org  Fri Sep 12 16:06:28 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 12 Sep 2025 16:06:28 GMT
Subject: [lworld] RFR: 8367156: [lworld] MacroAssembler::remove_frame hits
 "Field too big for insn" [v2]
In-Reply-To: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
References: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
Message-ID: <k9LJC859tBg9pvAJUWuCh_uu2OCnn3pVQ7__-3RPZmU=.ca4c88af-ea7e-4266-88d4-1c0771db42d9@github.com>

> As suspected, it's just a too big offset. We used to have a
> https://github.com/openjdk/valhalla/blob/c8d4a247861052aa6ed43125bcbe49995326938f/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6133
> 
> I changed it into
> https://github.com/openjdk/valhalla/blob/880ae47831ed7262a0d3b30b92c3645bc67e5df2/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6136
> 
> But [`ldp`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDP--Load-pair-of-registers-) has only a 7-bit offset. It's big, but not big enough. In some cases I've looked at, the offset can be as big as `536` which fits on 9 bits. [`ldr`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDR--immediate---Load-register--immediate--) supports a 9-bit offset. Let's change the `ldp` into
> 
> 
> ldr(rscratch1, Address(sp, sp_inc_offset))
> ldr(rfp, Address(sp, sp_inc_offset + wordSize))
> 
> which will be merged into one `ldp` if the offset fits.
> 
> But what if the offset is bigger than what fits on 9 bits? Well, us used to have the `ldr(rscratch1, Address(sp, sp_inc_offset))` so either we have a big problem (too big frames?) or `sp_inc_offset` was just bordeline and `sp_inc_offset + wordSize` is too big. But we still have `sp_inc_offset + wordSize == initial_framesize - 2 * wordSize` which would mean that `initial_framesize` doesn't fit on 9 bits either. Once again, that sounds like a bigger (and unlikely) problem.
> 
> Thanks,
> Marc

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  Add test

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1575/files
  - new: https://git.openjdk.org/valhalla/pull/1575/files/098bc1a0..d50560a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1575&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1575&range=00-01

  Stats: 61 lines in 1 file changed: 61 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1575.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1575/head:pull/1575

PR: https://git.openjdk.org/valhalla/pull/1575

From chagedorn at openjdk.org  Fri Sep 12 16:12:20 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 12 Sep 2025 16:12:20 GMT
Subject: [lworld] RFR: 8367156: [lworld] MacroAssembler::remove_frame hits
 "Field too big for insn" [v2]
In-Reply-To: <k9LJC859tBg9pvAJUWuCh_uu2OCnn3pVQ7__-3RPZmU=.ca4c88af-ea7e-4266-88d4-1c0771db42d9@github.com>
References: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
 <k9LJC859tBg9pvAJUWuCh_uu2OCnn3pVQ7__-3RPZmU=.ca4c88af-ea7e-4266-88d4-1c0771db42d9@github.com>
Message-ID: <QtxumqQccDlIop6d9HzVQ5_n9gpfetwOHg0UGdH0u6c=.90da3000-e649-409c-8b75-44bd9a3ceb8f@github.com>

On Fri, 12 Sep 2025 16:06:28 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> As suspected, it's just a too big offset. We used to have a
>> https://github.com/openjdk/valhalla/blob/c8d4a247861052aa6ed43125bcbe49995326938f/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6133
>> 
>> I changed it into
>> https://github.com/openjdk/valhalla/blob/880ae47831ed7262a0d3b30b92c3645bc67e5df2/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6136
>> 
>> But [`ldp`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDP--Load-pair-of-registers-) has only a 7-bit offset. It's big, but not big enough. In some cases I've looked at, the offset can be as big as `536` which fits on 9 bits. [`ldr`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDR--immediate---Load-register--immediate--) supports a 9-bit offset. Let's change the `ldp` into
>> 
>> 
>> ldr(rscratch1, Address(sp, sp_inc_offset))
>> ldr(rfp, Address(sp, sp_inc_offset + wordSize))
>> 
>> which will be merged into one `ldp` if the offset fits.
>> 
>> But what if the offset is bigger than what fits on 9 bits? Well, us used to have the `ldr(rscratch1, Address(sp, sp_inc_offset))` so either we have a big problem (too big frames?) or `sp_inc_offset` was just bordeline and `sp_inc_offset + wordSize` is too big. But we still have `sp_inc_offset + wordSize == initial_framesize - 2 * wordSize` which would mean that `initial_framesize` doesn't fit on 9 bits either. Once again, that sounds like a bigger (and unlikely) problem.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Otherwise, looks good to me!

test/hotspot/jtreg/compiler/valhalla/inlinetypes/RepairStackWithBigFrame.java line 35:

> 33:  *          increment and rfp at the same time, since it only has a 7 bit offset.
> 34:  *          We use two ldr with 9-bit offsets instead.
> 35:  * @library /test/lib /

Do you really need this? You do not seem to use anything from the library.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/RepairStackWithBigFrame.java line 43:

> 41:  *      -XX:CompileCommand=compileonly,compiler.valhalla.inlinetypes.RepairStackWithBigFrame::test
> 42:  *      compiler.valhalla.inlinetypes.RepairStackWithBigFrame
> 43:  * @run main/othervm compiler.valhalla.inlinetypes.RepairStackWithBigFrame

Can be changed to `main`:
Suggestion:

 * @run main compiler.valhalla.inlinetypes.RepairStackWithBigFrame

-------------

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1575#pullrequestreview-3217539332
PR Review Comment: https://git.openjdk.org/valhalla/pull/1575#discussion_r2344704684
PR Review Comment: https://git.openjdk.org/valhalla/pull/1575#discussion_r2344702071

From mchevalier at openjdk.org  Fri Sep 12 16:23:50 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 12 Sep 2025 16:23:50 GMT
Subject: [lworld] RFR: 8367156: [lworld] MacroAssembler::remove_frame hits
 "Field too big for insn" [v3]
In-Reply-To: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
References: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
Message-ID: <eTyY3FGITZ_jjbWIUXsC74tKUIkgJmdh37nbhU4xRSE=.80ef24dc-7894-46f9-88ef-bec3b7e7d376@github.com>

> As suspected, it's just a too big offset. We used to have a
> https://github.com/openjdk/valhalla/blob/c8d4a247861052aa6ed43125bcbe49995326938f/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6133
> 
> I changed it into
> https://github.com/openjdk/valhalla/blob/880ae47831ed7262a0d3b30b92c3645bc67e5df2/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6136
> 
> But [`ldp`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDP--Load-pair-of-registers-) has only a 7-bit offset. It's big, but not big enough. In some cases I've looked at, the offset can be as big as `536` which fits on 9 bits. [`ldr`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDR--immediate---Load-register--immediate--) supports a 9-bit offset. Let's change the `ldp` into
> 
> 
> ldr(rscratch1, Address(sp, sp_inc_offset))
> ldr(rfp, Address(sp, sp_inc_offset + wordSize))
> 
> which will be merged into one `ldp` if the offset fits.
> 
> But what if the offset is bigger than what fits on 9 bits? Well, us used to have the `ldr(rscratch1, Address(sp, sp_inc_offset))` so either we have a big problem (too big frames?) or `sp_inc_offset` was just bordeline and `sp_inc_offset + wordSize` is too big. But we still have `sp_inc_offset + wordSize == initial_framesize - 2 * wordSize` which would mean that `initial_framesize` doesn't fit on 9 bits either. Once again, that sounds like a bigger (and unlikely) problem.
> 
> Thanks,
> Marc

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  remove /othervm

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1575/files
  - new: https://git.openjdk.org/valhalla/pull/1575/files/d50560a5..0e6a16ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1575&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1575&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1575.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1575/head:pull/1575

PR: https://git.openjdk.org/valhalla/pull/1575

From chagedorn at openjdk.org  Fri Sep 12 16:23:50 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 12 Sep 2025 16:23:50 GMT
Subject: [lworld] RFR: 8367156: [lworld] MacroAssembler::remove_frame hits
 "Field too big for insn" [v3]
In-Reply-To: <eTyY3FGITZ_jjbWIUXsC74tKUIkgJmdh37nbhU4xRSE=.80ef24dc-7894-46f9-88ef-bec3b7e7d376@github.com>
References: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
 <eTyY3FGITZ_jjbWIUXsC74tKUIkgJmdh37nbhU4xRSE=.80ef24dc-7894-46f9-88ef-bec3b7e7d376@github.com>
Message-ID: <1aVpOWUIZqacdP6_sT5lMW85jTHU8NRzioSKhVjelHg=.f4b63138-b2c6-44c8-b3bc-1ace0229f205@github.com>

On Fri, 12 Sep 2025 16:20:22 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> As suspected, it's just a too big offset. We used to have a
>> https://github.com/openjdk/valhalla/blob/c8d4a247861052aa6ed43125bcbe49995326938f/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6133
>> 
>> I changed it into
>> https://github.com/openjdk/valhalla/blob/880ae47831ed7262a0d3b30b92c3645bc67e5df2/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6136
>> 
>> But [`ldp`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDP--Load-pair-of-registers-) has only a 7-bit offset. It's big, but not big enough. In some cases I've looked at, the offset can be as big as `536` which fits on 9 bits. [`ldr`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDR--immediate---Load-register--immediate--) supports a 9-bit offset. Let's change the `ldp` into
>> 
>> 
>> ldr(rscratch1, Address(sp, sp_inc_offset))
>> ldr(rfp, Address(sp, sp_inc_offset + wordSize))
>> 
>> which will be merged into one `ldp` if the offset fits.
>> 
>> But what if the offset is bigger than what fits on 9 bits? Well, us used to have the `ldr(rscratch1, Address(sp, sp_inc_offset))` so either we have a big problem (too big frames?) or `sp_inc_offset` was just bordeline and `sp_inc_offset + wordSize` is too big. But we still have `sp_inc_offset + wordSize == initial_framesize - 2 * wordSize` which would mean that `initial_framesize` doesn't fit on 9 bits either. Once again, that sounds like a bigger (and unlikely) problem.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove /othervm

Marked as reviewed by chagedorn (Committer).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1575#pullrequestreview-3217656029

From mchevalier at openjdk.org  Fri Sep 12 16:23:51 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 12 Sep 2025 16:23:51 GMT
Subject: [lworld] RFR: 8367156: [lworld] MacroAssembler::remove_frame hits
 "Field too big for insn" [v2]
In-Reply-To: <QtxumqQccDlIop6d9HzVQ5_n9gpfetwOHg0UGdH0u6c=.90da3000-e649-409c-8b75-44bd9a3ceb8f@github.com>
References: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
 <k9LJC859tBg9pvAJUWuCh_uu2OCnn3pVQ7__-3RPZmU=.ca4c88af-ea7e-4266-88d4-1c0771db42d9@github.com>
 <QtxumqQccDlIop6d9HzVQ5_n9gpfetwOHg0UGdH0u6c=.90da3000-e649-409c-8b75-44bd9a3ceb8f@github.com>
Message-ID: <8PxoNF6z3o-MafwhFwcwXegwEXl72__kUVZKVyzwz_w=.851f7440-5be2-44c0-ba76-fd1ba6bbc863@github.com>

On Fri, 12 Sep 2025 16:05:40 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/RepairStackWithBigFrame.java line 35:
> 
>> 33:  *          increment and rfp at the same time, since it only has a 7 bit offset.
>> 34:  *          We use two ldr with 9-bit offsets instead.
>> 35:  * @library /test/lib /
> 
> Do you really need this? You do not seem to use anything from the library.

I thought so too, and I tried without and it doesn't work. I'm using actually `MyValue1` that is defined in the same package, as we do in a lot of valhalla tests. And this one include a lot of things that needs both these paths (I've tried with each alone).

> test/hotspot/jtreg/compiler/valhalla/inlinetypes/RepairStackWithBigFrame.java line 43:
> 
>> 41:  *      -XX:CompileCommand=compileonly,compiler.valhalla.inlinetypes.RepairStackWithBigFrame::test
>> 42:  *      compiler.valhalla.inlinetypes.RepairStackWithBigFrame
>> 43:  * @run main/othervm compiler.valhalla.inlinetypes.RepairStackWithBigFrame
> 
> Can be changed to `main`:
> Suggestion:
> 
>  * @run main compiler.valhalla.inlinetypes.RepairStackWithBigFrame

Right. Done.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1575#discussion_r2344743110
PR Review Comment: https://git.openjdk.org/valhalla/pull/1575#discussion_r2344751307

From mchevalier at openjdk.org  Fri Sep 12 16:23:52 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 12 Sep 2025 16:23:52 GMT
Subject: [lworld] RFR: 8367156: [lworld] MacroAssembler::remove_frame hits
 "Field too big for insn" [v2]
In-Reply-To: <8PxoNF6z3o-MafwhFwcwXegwEXl72__kUVZKVyzwz_w=.851f7440-5be2-44c0-ba76-fd1ba6bbc863@github.com>
References: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
 <k9LJC859tBg9pvAJUWuCh_uu2OCnn3pVQ7__-3RPZmU=.ca4c88af-ea7e-4266-88d4-1c0771db42d9@github.com>
 <QtxumqQccDlIop6d9HzVQ5_n9gpfetwOHg0UGdH0u6c=.90da3000-e649-409c-8b75-44bd9a3ceb8f@github.com>
 <8PxoNF6z3o-MafwhFwcwXegwEXl72__kUVZKVyzwz_w=.851f7440-5be2-44c0-ba76-fd1ba6bbc863@github.com>
Message-ID: <7nOD0uAm1J454hjRpFRWi_XEl7mi9vT4AhbT75AzsDk=.fd97af95-2035-47cc-b215-afb3ae064bb3@github.com>

On Fri, 12 Sep 2025 16:14:26 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/valhalla/inlinetypes/RepairStackWithBigFrame.java line 35:
>> 
>>> 33:  *          increment and rfp at the same time, since it only has a 7 bit offset.
>>> 34:  *          We use two ldr with 9-bit offsets instead.
>>> 35:  * @library /test/lib /
>> 
>> Do you really need this? You do not seem to use anything from the library.
>
> I thought so too, and I tried without and it doesn't work. I'm using actually `MyValue1` that is defined in the same package, as we do in a lot of valhalla tests. And this one include a lot of things that needs both these paths (I've tried with each alone).

Without that, I would also not need `@modules java.base/jdk.internal.vm.annotation`. Alas, it seems needed...

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1575#discussion_r2344759720

From chagedorn at openjdk.org  Fri Sep 12 16:23:52 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 12 Sep 2025 16:23:52 GMT
Subject: [lworld] RFR: 8367156: [lworld] MacroAssembler::remove_frame hits
 "Field too big for insn" [v2]
In-Reply-To: <7nOD0uAm1J454hjRpFRWi_XEl7mi9vT4AhbT75AzsDk=.fd97af95-2035-47cc-b215-afb3ae064bb3@github.com>
References: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
 <k9LJC859tBg9pvAJUWuCh_uu2OCnn3pVQ7__-3RPZmU=.ca4c88af-ea7e-4266-88d4-1c0771db42d9@github.com>
 <QtxumqQccDlIop6d9HzVQ5_n9gpfetwOHg0UGdH0u6c=.90da3000-e649-409c-8b75-44bd9a3ceb8f@github.com>
 <8PxoNF6z3o-MafwhFwcwXegwEXl72__kUVZKVyzwz_w=.851f7440-5be2-44c0-ba76-fd1ba6bbc863@github.com>
 <7nOD0uAm1J454hjRpFRWi_XEl7mi9vT4AhbT75AzsDk=.fd97af95-2035-47cc-b215-afb3ae064bb3@github.com>
Message-ID: <nhmu0M-rQWysnjMUJl4x-jd27H6LqfZxcTnRwM3YKtE=.3d5cffe7-5d6c-411d-ac32-8c8eb160fa71@github.com>

On Fri, 12 Sep 2025 16:17:39 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> I thought so too, and I tried without and it doesn't work. I'm using actually `MyValue1` that is defined in the same package, as we do in a lot of valhalla tests. And this one include a lot of things that needs both these paths (I've tried with each alone).
>
> Without that, I would also not need `@modules java.base/jdk.internal.vm.annotation`. Alas, it seems needed...

I see! Then let's keep that.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1575#discussion_r2344770849

From vromero at openjdk.org  Fri Sep 12 16:53:17 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Sep 2025 16:53:17 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370
In-Reply-To: <mZ2KTUl_vroDJ0_Boz475jKIVStIsycWzrwKGoAfeOM=.9f7af448-4ff8-40d4-b859-9a91b8f0856b@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
 <7pyk_iAXoX0fdEq-4meS3a0eTr2_V7nmq06yFpY7vSo=.197e9fd6-5f38-4424-ab34-b26f4aff4f81@github.com>
 <qee01Ca1D9ES6vcH12faDXFIu-sAJv5leWiFDpAG8G8=.6f105134-d11a-483f-8860-71737c649121@github.com>
 <mZ2KTUl_vroDJ0_Boz475jKIVStIsycWzrwKGoAfeOM=.9f7af448-4ff8-40d4-b859-9a91b8f0856b@github.com>
Message-ID: <l1pg-8kaLWcuJ34rNIAyd1D0YTLA9JcByYJZQAgNJZQ=.0d44b9d4-3a25-44f3-8fdf-62874ac07a91@github.com>

On Fri, 12 Sep 2025 12:23:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Question: can we ever get here for a static symbol? I think for statics we should never run `analyzeSymbol` right? I'm not sure: `analyzeSymbol` seems called regardless of static-ness. Then it has two checks inside, one for writes and another for reads. The check for reads excludes `static` symbols, but the check for writes doesn't? I think we should maybe write some tests where we assign to a static field from a prologue :-)
>
> E.g. what I'm referring to is this:
> https://github.com/openjdk/valhalla/pull/1567/files#L1395
> What happens if `sym` is static?

`analyzeSymbol` is invoked for static symbols but all paths check if a symbol is static or not. Anyways I have included a explicit check to make this constraint more visible

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2344883303

From vromero at openjdk.org  Fri Sep 12 16:56:36 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Sep 2025 16:56:36 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370 [v2]
In-Reply-To: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
Message-ID: <hHB3CuWji4jRFHY8aV-KymI9McSJWR7B3MiaSEnqsvQ=.7f3f39cb-0bd5-4c12-b564-fdbc2efc9d04@github.com>

> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
> 
> class SuperClass<T> {
>     public SuperClass(Object o) {}
> }
> 
> class Sub<T> extends SuperClass<T> {
>     public Sub() {
>         super(new Object() {
>             void foo() {
>                 getClass();
>             }
>         });
>     }
> }
> 
> 
> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8367323' of https://github.com/vicente-romero-oracle/valhalla into JDK-8367323
 - addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1567/files
  - new: https://git.openjdk.org/valhalla/pull/1567/files/beff0210..33a050b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1567&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1567&range=00-01

  Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1567.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1567/head:pull/1567

PR: https://git.openjdk.org/valhalla/pull/1567

From vromero at openjdk.org  Fri Sep 12 17:44:22 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Sep 2025 17:44:22 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370 [v3]
In-Reply-To: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
Message-ID: <4vpveMnyMomoodcuGHaUJc7HLzafKgjpq4NhfK8srBA=.db239317-e9ef-4f1f-865b-1ffe29c2d788@github.com>

> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
> 
> class SuperClass<T> {
>     public SuperClass(Object o) {}
> }
> 
> class Sub<T> extends SuperClass<T> {
>     public Sub() {
>         super(new Object() {
>             void foo() {
>                 getClass();
>             }
>         });
>     }
> }
> 
> 
> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - fixing comment
 - addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1567/files
  - new: https://git.openjdk.org/valhalla/pull/1567/files/33a050b9..55cbe386

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1567&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1567&range=01-02

  Stats: 62 lines in 2 files changed: 19 ins; 23 del; 20 mod
  Patch: https://git.openjdk.org/valhalla/pull/1567.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1567/head:pull/1567

PR: https://git.openjdk.org/valhalla/pull/1567

From vromero at openjdk.org  Fri Sep 12 17:46:47 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Sep 2025 17:46:47 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370 [v3]
In-Reply-To: <4vpveMnyMomoodcuGHaUJc7HLzafKgjpq4NhfK8srBA=.db239317-e9ef-4f1f-865b-1ffe29c2d788@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
 <4vpveMnyMomoodcuGHaUJc7HLzafKgjpq4NhfK8srBA=.db239317-e9ef-4f1f-865b-1ffe29c2d788@github.com>
Message-ID: <5v5wWNwTWzcApLgHpL0wXailgkjpwpH9IAnlhcKC1K0=.24fcbe35-75bd-4558-852c-290aacd1191c@github.com>

On Fri, 12 Sep 2025 17:44:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
>> 
>> class SuperClass<T> {
>>     public SuperClass(Object o) {}
>> }
>> 
>> class Sub<T> extends SuperClass<T> {
>>     public Sub() {
>>         super(new Object() {
>>             void foo() {
>>                 getClass();
>>             }
>>         });
>>     }
>> }
>> 
>> 
>> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`
>
> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixing comment
>  - addressing review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1405:

> 1403:             }
> 1404:             tree = TreeInfo.skipParens(tree);
> 1405:             if (sym != null) {

I just removed this `if` as the symbol can't be null now, but it has provoked a big diff, mostly an indentation change

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2345028251

From fparain at openjdk.org  Fri Sep 12 17:52:51 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 12 Sep 2025 17:52:51 GMT
Subject: [lworld] RFR: 8367564: Fields access in interpreter needs cleanup and
 refactoring
Message-ID: <ak0SDowOLp-rnFKF8R4Ms6PE6tY8jiCJnAZ4sdcIHBs=.b84d3360-68ad-43fb-a2a9-65c28fc35a33@github.com>

Remove dead code from [get|put][field|static] in the interpreter.
Interpreter code refactoring to remove code duplication and reduce number of tests at runtime.

-------------

Commit messages:
 - Interpreter fields access code cleanup and refactoring

Changes: https://git.openjdk.org/valhalla/pull/1583/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1583&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367564
  Stats: 362 lines in 11 files changed: 85 ins; 194 del; 83 mod
  Patch: https://git.openjdk.org/valhalla/pull/1583.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1583/head:pull/1583

PR: https://git.openjdk.org/valhalla/pull/1583

From vromero at openjdk.org  Fri Sep 12 17:57:02 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Sep 2025 17:57:02 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370 [v4]
In-Reply-To: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
Message-ID: <gPQBBj4PS_Sgc6Is4X_oifbTf5JaJ-YiyzXq8x2kLys=.913589a1-e89b-49fc-91e1-5f94dcfdb75c@github.com>

> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
> 
> class SuperClass<T> {
>     public SuperClass(Object o) {}
> }
> 
> class Sub<T> extends SuperClass<T> {
>     public Sub() {
>         super(new Object() {
>             void foo() {
>                 getClass();
>             }
>         });
>     }
> }
> 
> 
> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  removing unnecessary check

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1567/files
  - new: https://git.openjdk.org/valhalla/pull/1567/files/55cbe386..c34f98b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1567&range=03
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1567&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1567.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1567/head:pull/1567

PR: https://git.openjdk.org/valhalla/pull/1567

From vromero at openjdk.org  Fri Sep 12 17:57:04 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Sep 2025 17:57:04 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370 [v4]
In-Reply-To: <gPQBBj4PS_Sgc6Is4X_oifbTf5JaJ-YiyzXq8x2kLys=.913589a1-e89b-49fc-91e1-5f94dcfdb75c@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
 <gPQBBj4PS_Sgc6Is4X_oifbTf5JaJ-YiyzXq8x2kLys=.913589a1-e89b-49fc-91e1-5f94dcfdb75c@github.com>
Message-ID: <jAWgTGkPk4VDmMa9X14EglPaSW_rpZZjOY4ri8ryebE=.6120f178-4f5e-4961-aa88-27a79a4245a0@github.com>

On Fri, 12 Sep 2025 17:53:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
>> 
>> class SuperClass<T> {
>>     public SuperClass(Object o) {}
>> }
>> 
>> class Sub<T> extends SuperClass<T> {
>>     public Sub() {
>>         super(new Object() {
>>             void foo() {
>>                 getClass();
>>             }
>>         });
>>     }
>> }
>> 
>> 
>> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing unnecessary check

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1414:

> 1412:             }
> 1413:             tree = TreeInfo.skipParens(tree);
> 1414:             if (sym.kind == VAR && sym.owner.kind == TYP) {

also removed a check for static symbol here, not needed now

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2345044114

From vromero at openjdk.org  Fri Sep 12 18:50:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 12 Sep 2025 18:50:50 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370
In-Reply-To: <JMZ__BEWHC78bTaKd5MR7cf5gcpIUKrpNnCW9PyX7R0=.6d05dce8-c853-4110-82a5-8e8363875fea@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
 <JMZ__BEWHC78bTaKd5MR7cf5gcpIUKrpNnCW9PyX7R0=.6d05dce8-c853-4110-82a5-8e8363875fea@github.com>
Message-ID: <z_dTH5kxf1Sr_EGq_mh2820YuOMZWJ8WdGU3A-p8210=.bd9c1815-bd15-4cf4-9796-c087ad7f7a8b@github.com>

On Fri, 12 Sep 2025 15:26:39 GMT, Chen Liang <liach at openjdk.org> wrote:

> Seems the bot fixes itself. Now we are ready to merge this fix.

gonna let it open a bit longer in case @mcimadamore has another comment

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1567#issuecomment-3286467547

From rriggs at openjdk.org  Fri Sep 12 19:11:23 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 Sep 2025 19:11:23 GMT
Subject: [lworld] Integrated: 8367569: [lworld] ImageReaderBenchmark.java
 doesn't compile
Message-ID: <ULj0vXbnwp1h2HxgxLcJ2F6AfU1oWT-2PoaAgPY2FkM=.6c00e31b-d3cb-48bf-ae6f-2498f4ca02ab@github.com>

Build fix for missing --add-exports

-------------

Commit messages:
 - 8367569: [lworld] ImageReaderBenchmark.java doesn't compile

Changes: https://git.openjdk.org/valhalla/pull/1584/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1584&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367569
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1584.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1584/head:pull/1584

PR: https://git.openjdk.org/valhalla/pull/1584

From liach at openjdk.org  Fri Sep 12 19:11:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 12 Sep 2025 19:11:23 GMT
Subject: [lworld] Integrated: 8367569: [lworld] ImageReaderBenchmark.java
 doesn't compile
In-Reply-To: <ULj0vXbnwp1h2HxgxLcJ2F6AfU1oWT-2PoaAgPY2FkM=.6c00e31b-d3cb-48bf-ae6f-2498f4ca02ab@github.com>
References: <ULj0vXbnwp1h2HxgxLcJ2F6AfU1oWT-2PoaAgPY2FkM=.6c00e31b-d3cb-48bf-ae6f-2498f4ca02ab@github.com>
Message-ID: <Ri_CBtzFu-TqeTp71zfkQH6VQKv74LPvT65GdazJmCA=.1ac469cd-0332-4cb5-9c76-7a65cecaf4cc@github.com>

On Fri, 12 Sep 2025 19:04:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Build fix for missing --add-exports

That line from https://github.com/openjdk/jdk/pull/26044 was clearly forgotten by accident.

-------------

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1584#pullrequestreview-3218445254

From rriggs at openjdk.org  Fri Sep 12 19:11:24 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 Sep 2025 19:11:24 GMT
Subject: [lworld] Integrated: 8367569: [lworld] ImageReaderBenchmark.java
 doesn't compile
In-Reply-To: <ULj0vXbnwp1h2HxgxLcJ2F6AfU1oWT-2PoaAgPY2FkM=.6c00e31b-d3cb-48bf-ae6f-2498f4ca02ab@github.com>
References: <ULj0vXbnwp1h2HxgxLcJ2F6AfU1oWT-2PoaAgPY2FkM=.6c00e31b-d3cb-48bf-ae6f-2498f4ca02ab@github.com>
Message-ID: <Rej3qu-zeM4YyBWoXxB7ISNoWxyY3SwmZCyTWdY8LtU=.99445cb2-7a21-48b7-98aa-66061a39bd2e@github.com>

On Fri, 12 Sep 2025 19:04:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Build fix for missing --add-exports

This pull request has now been integrated.

Changeset: 07a4cb42
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/07a4cb42d357346a1dfa4ea00149daee40034c79
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8367569: [lworld] ImageReaderBenchmark.java doesn't compile

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/valhalla/pull/1584

From coleenp at openjdk.org  Fri Sep 12 19:14:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Sep 2025 19:14:54 GMT
Subject: [lworld] RFR: 8367564: Fields access in interpreter needs cleanup
 and refactoring
In-Reply-To: <ak0SDowOLp-rnFKF8R4Ms6PE6tY8jiCJnAZ4sdcIHBs=.b84d3360-68ad-43fb-a2a9-65c28fc35a33@github.com>
References: <ak0SDowOLp-rnFKF8R4Ms6PE6tY8jiCJnAZ4sdcIHBs=.b84d3360-68ad-43fb-a2a9-65c28fc35a33@github.com>
Message-ID: <dWBLAGmQe75OvoCVcMantJ5aJbX4yCuYa0Nddf51s1o=.a16dc02d-1fab-47af-a816-760d6f9e4d39@github.com>

On Fri, 12 Sep 2025 17:47:52 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Remove dead code from [get|put][field|static] in the interpreter.
> Interpreter code refactoring to remove code duplication and reduce number of tests at runtime.

This looks really good!

-------------

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1583#pullrequestreview-3218481897

From fparain at openjdk.org  Fri Sep 12 19:30:37 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 12 Sep 2025 19:30:37 GMT
Subject: [lworld] RFR: 8366743: [lworld]: Verifier adjustments for
 operations on 'uninitialized' [v3]
In-Reply-To: <5z448R2lXN9KgTgI715d1KCUW321PvtNNNPQLBTVwc0=.3e546bd7-ebfb-493d-9015-a98b7a774916@github.com>
References: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
 <5z448R2lXN9KgTgI715d1KCUW321PvtNNNPQLBTVwc0=.3e546bd7-ebfb-493d-9015-a98b7a774916@github.com>
Message-ID: <BN9lEyfsPzCh3W7x2GvCJea4ZRtZ-6DEM8IqM7680iE=.44229228-a376-4503-aa20-7a943904551f@github.com>

On Thu, 11 Sep 2025 18:06:33 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The updated spec places more restrictions on the use of uninitialized and uninitializedThis with certain bytecodes. Those spec changes are implemented with this patch and tested with a new set of tests. Verified with the new test as well as tiers 1-5.
>
> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge commit 'refs/pull/1566/head' of github.com:openjdk/valhalla into uninit_implementation_8366271
>  - Added fix and tests for old verifier

HotSpot changes and tests look good to me.

-------------

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1566#pullrequestreview-3218550849

From fparain at openjdk.org  Fri Sep 12 19:33:53 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 12 Sep 2025 19:33:53 GMT
Subject: [lworld] RFR: 8367564: Fields access in interpreter needs cleanup
 and refactoring
In-Reply-To: <ak0SDowOLp-rnFKF8R4Ms6PE6tY8jiCJnAZ4sdcIHBs=.b84d3360-68ad-43fb-a2a9-65c28fc35a33@github.com>
References: <ak0SDowOLp-rnFKF8R4Ms6PE6tY8jiCJnAZ4sdcIHBs=.b84d3360-68ad-43fb-a2a9-65c28fc35a33@github.com>
Message-ID: <yN8b5XRbS1F1UXlAUV_-rkvhS2nhdTffaW_SRci85Eo=.b74648dc-344b-4fa3-a86c-80b4a5a75d7f@github.com>

On Fri, 12 Sep 2025 17:47:52 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Remove dead code from [get|put][field|static] in the interpreter.
> Interpreter code refactoring to remove code duplication and reduce number of tests at runtime.

Thanks for reviewing Coleen.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1583#issuecomment-3286579939

From fparain at openjdk.org  Fri Sep 12 19:33:53 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 12 Sep 2025 19:33:53 GMT
Subject: [lworld] Integrated: 8367564: Fields access in interpreter needs
 cleanup and refactoring
In-Reply-To: <ak0SDowOLp-rnFKF8R4Ms6PE6tY8jiCJnAZ4sdcIHBs=.b84d3360-68ad-43fb-a2a9-65c28fc35a33@github.com>
References: <ak0SDowOLp-rnFKF8R4Ms6PE6tY8jiCJnAZ4sdcIHBs=.b84d3360-68ad-43fb-a2a9-65c28fc35a33@github.com>
Message-ID: <6aEVseG1LFD-WfC6H73cbJJPNpBGxw1y5numnW9qgzk=.f092d67c-f645-429e-aef4-2417f581454b@github.com>

On Fri, 12 Sep 2025 17:47:52 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Remove dead code from [get|put][field|static] in the interpreter.
> Interpreter code refactoring to remove code duplication and reduce number of tests at runtime.

This pull request has now been integrated.

Changeset: 0492736b
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0492736bfdc61b310d7545da81389710535fcc69
Stats:     362 lines in 11 files changed: 85 ins; 194 del; 83 mod

8367564: Fields access in interpreter needs cleanup and refactoring

Reviewed-by: coleenp

-------------

PR: https://git.openjdk.org/valhalla/pull/1583

From amenkov at openjdk.org  Fri Sep 12 22:04:23 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 12 Sep 2025 22:04:23 GMT
Subject: [lworld] Integrated: 8271910: [lworld] Heap functions/callbacks should
 support value fields
In-Reply-To: <8yZd6wXtf5hcIBSq5aBRAQTBvI90R_MVN6xEwFE5XoM=.0af979e4-e992-4116-bcf2-c2c45c6f8fa8@github.com>
References: <8yZd6wXtf5hcIBSq5aBRAQTBvI90R_MVN6xEwFE5XoM=.0af979e4-e992-4116-bcf2-c2c45c6f8fa8@github.com>
Message-ID: <4R6xkwySs6QHlyIKXPwXLqU_HRy8inCcRzuRq4aaT-4=.e3bd992b-ce3e-4b17-a018-f9dff48d77ae@github.com>

On Thu, 11 Sep 2025 20:33:21 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix implements support for flat value object by heapwalking API.
> 
> FollowReferences/IterateThroughHeap are executed at safepoint and agent callbacks may request to set/update tags for the reported object. To store tags for flattened object at safepoint a special tag table is used (entries contain strong references to holder objects), entries from the table are converted to entries in main tag table outside of safepoint.

This pull request has now been integrated.

Changeset: b916f976
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b916f976ccc08150c1f8e64b914e31a789fc288f
Stats:     1852 lines in 6 files changed: 1493 ins; 103 del; 256 mod

8271910: [lworld] Heap functions/callbacks should support value fields

-------------

PR: https://git.openjdk.org/valhalla/pull/1576

From dsimms at openjdk.org  Sat Sep 13 10:34:39 2025
From: dsimms at openjdk.org (David Simms)
Date: Sat, 13 Sep 2025 10:34:39 GMT
Subject: [lworld] RFR: 8367592: Call to write_flat_field uses a Windows calling
 convention arg
Message-ID: <tLlID_yM9K8RsGPtrpOoxCR04MJzuxb90JlaYmFTaDQ=.5b402bf0-d371-412d-b819-a6c044f484b9@github.com>

Work-around with r11

-------------

Commit messages:
 - 8367592: Call to write_flat_field uses a Windows calling convention arg

Changes: https://git.openjdk.org/valhalla/pull/1585/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1585&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367592
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/1585.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1585/head:pull/1585

PR: https://git.openjdk.org/valhalla/pull/1585

From dsimms at openjdk.org  Sat Sep 13 11:29:43 2025
From: dsimms at openjdk.org (David Simms)
Date: Sat, 13 Sep 2025 11:29:43 GMT
Subject: [lworld] Integrated: 8367592: Call to write_flat_field uses a Windows
 calling convention arg
In-Reply-To: <tLlID_yM9K8RsGPtrpOoxCR04MJzuxb90JlaYmFTaDQ=.5b402bf0-d371-412d-b819-a6c044f484b9@github.com>
References: <tLlID_yM9K8RsGPtrpOoxCR04MJzuxb90JlaYmFTaDQ=.5b402bf0-d371-412d-b819-a6c044f484b9@github.com>
Message-ID: <KYUJKNFwSbjAhy8SrdySIcpa3Pih2YpXaj9Jh2DnULE=.b5c96f27-89d4-4c6b-b0f0-63556f3ca06e@github.com>

On Sat, 13 Sep 2025 10:27:35 GMT, David Simms <dsimms at openjdk.org> wrote:

> Work-around with r11

This pull request has now been integrated.

Changeset: cf863300
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/cf8633007955b3e3ceb53f0790cc575c357d0470
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8367592: Call to write_flat_field uses a Windows calling convention arg

-------------

PR: https://git.openjdk.org/valhalla/pull/1585

From skuksenko at openjdk.org  Mon Sep 15 01:15:14 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Mon, 15 Sep 2025 01:15:14 GMT
Subject: git: openjdk/valhalla: lworld: 8367608: [lworld] Update/reimplement
 valhalla benchmarks for JEP 401
Message-ID: <ce7530be-289b-4b21-a6c6-5ce783ca6967@openjdk.org>

Changeset: 89308395
Branch: lworld
Author:    Sergey Kuksenko <skuksenko at openjdk.org>
Date:      2025-09-15 01:12:48 +0000
URL:       https://git.openjdk.org/valhalla/commit/89308395192c5ac6dc8667c0146591fcf52ce163

8367608: [lworld] Update/reimplement valhalla benchmarks for JEP 401

! make/test/BuildMicrobenchmark.gmk
! test/micro/org/openjdk/bench/valhalla/ackermann/AckermannBase.java
+ test/micro/org/openjdk/bench/valhalla/ackermann/Identity.java
- test/micro/org/openjdk/bench/valhalla/ackermann/Identity64byte.java
- test/micro/org/openjdk/bench/valhalla/ackermann/Identity64int.java
- test/micro/org/openjdk/bench/valhalla/ackermann/Identity64long.java
- test/micro/org/openjdk/bench/valhalla/ackermann/IdentityLong.java
- test/micro/org/openjdk/bench/valhalla/ackermann/Inline64byte.java
- test/micro/org/openjdk/bench/valhalla/ackermann/Inline64int.java
- test/micro/org/openjdk/bench/valhalla/ackermann/Inline64long.java
= test/micro/org/openjdk/bench/valhalla/ackermann/Primitive.java
+ test/micro/org/openjdk/bench/valhalla/ackermann/Value.java
+ test/micro/org/openjdk/bench/valhalla/acmp/array/Identity.java
- test/micro/org/openjdk/bench/valhalla/acmp/array/IdentityIsCmpBranch.java
- test/micro/org/openjdk/bench/valhalla/acmp/array/IdentityIsCmpResult.java
- test/micro/org/openjdk/bench/valhalla/acmp/array/IdentityIsNotCmpBranch.java
- test/micro/org/openjdk/bench/valhalla/acmp/array/IdentityIsNotCmpResult.java
- test/micro/org/openjdk/bench/valhalla/acmp/array/InlineIsCmpBranch64byte.java
- test/micro/org/openjdk/bench/valhalla/acmp/array/InlineIsCmpBranch64long.java
- test/micro/org/openjdk/bench/valhalla/acmp/array/StatesQ64byte.java
- test/micro/org/openjdk/bench/valhalla/acmp/array/StatesQ64long.java
- test/micro/org/openjdk/bench/valhalla/acmp/array/StatesR64long.java
+ test/micro/org/openjdk/bench/valhalla/acmp/array/Value032.java
+ test/micro/org/openjdk/bench/valhalla/acmp/array/Value032NullFree.java
+ test/micro/org/openjdk/bench/valhalla/acmp/array/Value032NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/acmp/array/Value128.java
+ test/micro/org/openjdk/bench/valhalla/acmp/array/Value128NullFree.java
+ test/micro/org/openjdk/bench/valhalla/acmp/array/Value128NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/acmp/field/Identity.java
- test/micro/org/openjdk/bench/valhalla/acmp/field/InlineIsCmpBranch64long.java
- test/micro/org/openjdk/bench/valhalla/acmp/field/StatesQ64long.java
+ test/micro/org/openjdk/bench/valhalla/acmp/field/Value032.java
+ test/micro/org/openjdk/bench/valhalla/acmp/field/Value032NullFree.java
+ test/micro/org/openjdk/bench/valhalla/acmp/field/Value032NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/acmp/field/Value128.java
+ test/micro/org/openjdk/bench/valhalla/acmp/field/Value128NullFree.java
+ test/micro/org/openjdk/bench/valhalla/acmp/field/Value128NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/acmp/trivial/Identity.java
- test/micro/org/openjdk/bench/valhalla/acmp/trivial/IdentityTrivialEquals.java
- test/micro/org/openjdk/bench/valhalla/acmp/trivial/IdentityTrivialNotEquals.java
+ test/micro/org/openjdk/bench/valhalla/acmp/trivial/Value.java
= test/micro/org/openjdk/bench/valhalla/array/copy/CopyBase.java
+ test/micro/org/openjdk/bench/valhalla/array/copy/Identity.java
- test/micro/org/openjdk/bench/valhalla/array/copy/Identity32int.java
- test/micro/org/openjdk/bench/valhalla/array/copy/Inline128int.java
- test/micro/org/openjdk/bench/valhalla/array/copy/Inline32int.java
- test/micro/org/openjdk/bench/valhalla/array/copy/Inline64byte.java
- test/micro/org/openjdk/bench/valhalla/array/copy/Inline64int.java
- test/micro/org/openjdk/bench/valhalla/array/copy/InlineOpt.java
+ test/micro/org/openjdk/bench/valhalla/array/copy/Primitive032.java
- test/micro/org/openjdk/bench/valhalla/array/copy/Primitive128.java
- test/micro/org/openjdk/bench/valhalla/array/copy/Primitive32.java
- test/micro/org/openjdk/bench/valhalla/array/copy/Primitive64.java
+ test/micro/org/openjdk/bench/valhalla/array/copy/Value032.java
+ test/micro/org/openjdk/bench/valhalla/array/copy/Value032NullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/copy/Value032NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/copy/Value128.java
+ test/micro/org/openjdk/bench/valhalla/array/copy/Value128NullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/copy/Value128NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/copy/ValueOop.java
+ test/micro/org/openjdk/bench/valhalla/array/copy/ValueOopNullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/copy/ValueOopNullFreeNonAtomic.java
= test/micro/org/openjdk/bench/valhalla/array/fill/FillBase.java
+ test/micro/org/openjdk/bench/valhalla/array/fill/Identity.java
- test/micro/org/openjdk/bench/valhalla/array/fill/Identity32int.java
- test/micro/org/openjdk/bench/valhalla/array/fill/IdentityOpt.java
- test/micro/org/openjdk/bench/valhalla/array/fill/Inline128int.java
- test/micro/org/openjdk/bench/valhalla/array/fill/Inline32int.java
- test/micro/org/openjdk/bench/valhalla/array/fill/Inline64byte.java
- test/micro/org/openjdk/bench/valhalla/array/fill/Inline64int.java
- test/micro/org/openjdk/bench/valhalla/array/fill/InlineOpt.java
+ test/micro/org/openjdk/bench/valhalla/array/fill/Primitive032.java
- test/micro/org/openjdk/bench/valhalla/array/fill/Primitive64.java
+ test/micro/org/openjdk/bench/valhalla/array/fill/Value032.java
+ test/micro/org/openjdk/bench/valhalla/array/fill/Value032NullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/fill/Value032NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/fill/Value128.java
+ test/micro/org/openjdk/bench/valhalla/array/fill/Value128NullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/fill/Value128NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/fill/ValueOop.java
+ test/micro/org/openjdk/bench/valhalla/array/fill/ValueOopNullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/fill/ValueOopNullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/read/Identity.java
- test/micro/org/openjdk/bench/valhalla/array/read/Inline128int.java
- test/micro/org/openjdk/bench/valhalla/array/read/Inline32int.java
- test/micro/org/openjdk/bench/valhalla/array/read/Inline64byte.java
- test/micro/org/openjdk/bench/valhalla/array/read/Inline64int.java
+ test/micro/org/openjdk/bench/valhalla/array/read/Primitive032.java
- test/micro/org/openjdk/bench/valhalla/array/read/Primitive128int.java
- test/micro/org/openjdk/bench/valhalla/array/read/Primitive32int.java
- test/micro/org/openjdk/bench/valhalla/array/read/Primitive64byte.java
- test/micro/org/openjdk/bench/valhalla/array/read/Primitive64int.java
- test/micro/org/openjdk/bench/valhalla/array/read/Primitive64long.java
= test/micro/org/openjdk/bench/valhalla/array/read/ReadBase.java
+ test/micro/org/openjdk/bench/valhalla/array/read/Value032.java
+ test/micro/org/openjdk/bench/valhalla/array/read/Value032NullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/read/Value032NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/read/Value128.java
+ test/micro/org/openjdk/bench/valhalla/array/read/Value128NullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/read/Value128NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/read/ValueOop.java
+ test/micro/org/openjdk/bench/valhalla/array/read/ValueOopNullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/read/ValueOopNullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/readpartial/Identity.java
+ test/micro/org/openjdk/bench/valhalla/array/readpartial/Primitive128.java
= test/micro/org/openjdk/bench/valhalla/array/readpartial/ReadBase.java
+ test/micro/org/openjdk/bench/valhalla/array/readpartial/Value128.java
+ test/micro/org/openjdk/bench/valhalla/array/readpartial/Value128NullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/readpartial/Value128NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/readpartial/ValueOop.java
+ test/micro/org/openjdk/bench/valhalla/array/readpartial/ValueOopNullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/readpartial/ValueOopNullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/set/Identity.java
- test/micro/org/openjdk/bench/valhalla/array/set/Inline128int.java
- test/micro/org/openjdk/bench/valhalla/array/set/Inline32int.java
- test/micro/org/openjdk/bench/valhalla/array/set/Inline64byte.java
- test/micro/org/openjdk/bench/valhalla/array/set/Inline64int.java
+ test/micro/org/openjdk/bench/valhalla/array/set/Primitive032.java
- test/micro/org/openjdk/bench/valhalla/array/set/Primitive32.java
- test/micro/org/openjdk/bench/valhalla/array/set/Primitive64.java
= test/micro/org/openjdk/bench/valhalla/array/set/SetBase.java
+ test/micro/org/openjdk/bench/valhalla/array/set/Value032.java
+ test/micro/org/openjdk/bench/valhalla/array/set/Value032NullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/set/Value032NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/set/Value128.java
+ test/micro/org/openjdk/bench/valhalla/array/set/Value128NullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/set/Value128NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/set/ValueOop.java
+ test/micro/org/openjdk/bench/valhalla/array/set/ValueOopNullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/set/ValueOopNullFreeNonAtomic.java
- test/micro/org/openjdk/bench/valhalla/array/sum/IdentityOpt.java
- test/micro/org/openjdk/bench/valhalla/array/sum/Inline128int.java
- test/micro/org/openjdk/bench/valhalla/array/sum/Inline32int.java
- test/micro/org/openjdk/bench/valhalla/array/sum/Inline64byte.java
- test/micro/org/openjdk/bench/valhalla/array/sum/Inline64int.java
- test/micro/org/openjdk/bench/valhalla/array/sum/InlineOpt.java
- test/micro/org/openjdk/bench/valhalla/array/sum/Primitive128int.java
- test/micro/org/openjdk/bench/valhalla/array/sum/Primitive32int.java
- test/micro/org/openjdk/bench/valhalla/array/sum/Primitive64byte.java
- test/micro/org/openjdk/bench/valhalla/array/sum/Primitive64int.java
- test/micro/org/openjdk/bench/valhalla/array/sum/Primitive64long.java
- test/micro/org/openjdk/bench/valhalla/array/util/PrimitiveStates.java
- test/micro/org/openjdk/bench/valhalla/array/util/StatesQ128byte.java
- test/micro/org/openjdk/bench/valhalla/array/util/StatesQ128int.java
- test/micro/org/openjdk/bench/valhalla/array/util/StatesQ128long.java
- test/micro/org/openjdk/bench/valhalla/array/util/StatesQ32int.java
- test/micro/org/openjdk/bench/valhalla/array/util/StatesQ64byte.java
- test/micro/org/openjdk/bench/valhalla/array/util/StatesQ64int.java
- test/micro/org/openjdk/bench/valhalla/array/util/StatesQOpt.java
- test/micro/org/openjdk/bench/valhalla/array/util/StatesR128int.java
- test/micro/org/openjdk/bench/valhalla/array/util/StatesR32int.java
- test/micro/org/openjdk/bench/valhalla/array/util/StatesR64byte.java
- test/micro/org/openjdk/bench/valhalla/array/util/StatesR64int.java
- test/micro/org/openjdk/bench/valhalla/array/util/StatesROpt.java
+ test/micro/org/openjdk/bench/valhalla/array/walk/Identity.java
+ test/micro/org/openjdk/bench/valhalla/array/walk/Primitive.java
+ test/micro/org/openjdk/bench/valhalla/array/walk/Value032.java
+ test/micro/org/openjdk/bench/valhalla/array/walk/Value032NullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/walk/Value032NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/walk/Value128.java
+ test/micro/org/openjdk/bench/valhalla/array/walk/Value128NullFree.java
+ test/micro/org/openjdk/bench/valhalla/array/walk/Value128NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/array/walk/WalkBase.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/copy/IdentityArrayCopy.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/copy/IdentityCopy0.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/copy/IdentityCopy1.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/copy/IdentityCopy2.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/copy/IdentityCopy3.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/copy/InlineArrayCopy.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/copy/InlineCopy0.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/copy/InlineCopy1.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/copy/InlineCopy2.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/copy/InlineCopy3.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillDef.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillInstInt.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillInstObj.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillInstRef.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillInstVal.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillInt.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillNew.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillObj.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillRef.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillStatInt.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillStatObj.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillStatRef.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillStatVal.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/fill/Inline64longFillVal.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/read/Inline64long.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/set/Inline64longSetInt.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/set/Inline64longSetNew.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/set/Inline64longSetObj.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/set/Inline64longSetRef.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/set/Inline64longSetVal.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/sum/Identity64long.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/sum/Inline64long.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/util/StatesQ64long.java
- test/micro/org/openjdk/bench/valhalla/arraytotal/util/StatesR64long.java
- test/micro/org/openjdk/bench/valhalla/callconv/Inline64byte.java
- test/micro/org/openjdk/bench/valhalla/callconv/Inline64int.java
- test/micro/org/openjdk/bench/valhalla/callconv/Inline64long.java
+ test/micro/org/openjdk/bench/valhalla/callconv/Primitive1.java
+ test/micro/org/openjdk/bench/valhalla/callconv/Primitive2.java
+ test/micro/org/openjdk/bench/valhalla/callconv/Primitive4.java
+ test/micro/org/openjdk/bench/valhalla/callconv/Primitive8.java
- test/micro/org/openjdk/bench/valhalla/callconv/PrimitiveByte.java
- test/micro/org/openjdk/bench/valhalla/callconv/PrimitiveInt.java
- test/micro/org/openjdk/bench/valhalla/callconv/PrimitiveLong.java
+ test/micro/org/openjdk/bench/valhalla/callconv/Value1.java
+ test/micro/org/openjdk/bench/valhalla/callconv/Value2.java
+ test/micro/org/openjdk/bench/valhalla/callconv/Value4.java
+ test/micro/org/openjdk/bench/valhalla/callconv/Value8.java
= test/micro/org/openjdk/bench/valhalla/field/copy/CopyBase.java
+ test/micro/org/openjdk/bench/valhalla/field/copy/Identity.java
- test/micro/org/openjdk/bench/valhalla/field/copy/Inline128int.java
- test/micro/org/openjdk/bench/valhalla/field/copy/Inline32int.java
- test/micro/org/openjdk/bench/valhalla/field/copy/Inline64byte.java
- test/micro/org/openjdk/bench/valhalla/field/copy/Inline64int.java
- test/micro/org/openjdk/bench/valhalla/field/copy/Inline64long.java
- test/micro/org/openjdk/bench/valhalla/field/copy/Primitive128.java
- test/micro/org/openjdk/bench/valhalla/field/copy/Primitive32.java
- test/micro/org/openjdk/bench/valhalla/field/copy/Primitive64.java
+ test/micro/org/openjdk/bench/valhalla/field/copy/Value032.java
+ test/micro/org/openjdk/bench/valhalla/field/copy/Value032NullFree.java
+ test/micro/org/openjdk/bench/valhalla/field/copy/Value032NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/field/copy/Value128.java
+ test/micro/org/openjdk/bench/valhalla/field/copy/Value128NullFree.java
+ test/micro/org/openjdk/bench/valhalla/field/copy/Value128NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/field/read/Identity.java
- test/micro/org/openjdk/bench/valhalla/field/read/Inline128int.java
- test/micro/org/openjdk/bench/valhalla/field/read/Inline32int.java
- test/micro/org/openjdk/bench/valhalla/field/read/Inline64byte.java
- test/micro/org/openjdk/bench/valhalla/field/read/Inline64int.java
- test/micro/org/openjdk/bench/valhalla/field/read/Inline64long.java
= test/micro/org/openjdk/bench/valhalla/field/read/ReadBase.java
+ test/micro/org/openjdk/bench/valhalla/field/read/Value032.java
+ test/micro/org/openjdk/bench/valhalla/field/read/Value032NullFree.java
+ test/micro/org/openjdk/bench/valhalla/field/read/Value032NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/field/read/Value128.java
+ test/micro/org/openjdk/bench/valhalla/field/read/Value128NullFree.java
+ test/micro/org/openjdk/bench/valhalla/field/read/Value128NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/field/set/Identity.java
- test/micro/org/openjdk/bench/valhalla/field/set/Inline128int.java
- test/micro/org/openjdk/bench/valhalla/field/set/Inline32int.java
- test/micro/org/openjdk/bench/valhalla/field/set/Inline64byte.java
- test/micro/org/openjdk/bench/valhalla/field/set/Inline64int.java
- test/micro/org/openjdk/bench/valhalla/field/set/Inline64long.java
= test/micro/org/openjdk/bench/valhalla/field/set/SetBase.java
+ test/micro/org/openjdk/bench/valhalla/field/set/Value032.java
+ test/micro/org/openjdk/bench/valhalla/field/set/Value032NullFree.java
+ test/micro/org/openjdk/bench/valhalla/field/set/Value032NullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/field/set/Value128.java
+ test/micro/org/openjdk/bench/valhalla/field/set/Value128NullFree.java
+ test/micro/org/openjdk/bench/valhalla/field/set/Value128NullFreeNonAtomic.java
- test/micro/org/openjdk/bench/valhalla/field/util/PrimitiveStates.java
- test/micro/org/openjdk/bench/valhalla/field/util/StatesQ128int.java
- test/micro/org/openjdk/bench/valhalla/field/util/StatesQ32int.java
- test/micro/org/openjdk/bench/valhalla/field/util/StatesQ64byte.java
- test/micro/org/openjdk/bench/valhalla/field/util/StatesQ64int.java
- test/micro/org/openjdk/bench/valhalla/field/util/StatesQ64long.java
+ test/micro/org/openjdk/bench/valhalla/hash/Value1.java
+ test/micro/org/openjdk/bench/valhalla/hash/Value8.java
- test/micro/org/openjdk/bench/valhalla/invoke/IdentityArray.java
- test/micro/org/openjdk/bench/valhalla/invoke/IdentityField.java
- test/micro/org/openjdk/bench/valhalla/invoke/InlineArray0.java
- test/micro/org/openjdk/bench/valhalla/invoke/InlineArray1.java
- test/micro/org/openjdk/bench/valhalla/invoke/InlineArrayHashExplicit.java
- test/micro/org/openjdk/bench/valhalla/invoke/InlineArrayHashImplicit.java
- test/micro/org/openjdk/bench/valhalla/invoke/InlineField.java
- test/micro/org/openjdk/bench/valhalla/invoke/InlineField1.java
- test/micro/org/openjdk/bench/valhalla/invoke/InlineRec.java
+ test/micro/org/openjdk/bench/valhalla/invoke/array/Identity.java
+ test/micro/org/openjdk/bench/valhalla/invoke/array/Value.java
+ test/micro/org/openjdk/bench/valhalla/invoke/array/ValueNullFree.java
+ test/micro/org/openjdk/bench/valhalla/invoke/array/ValueNullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/invoke/field/Identity.java
+ test/micro/org/openjdk/bench/valhalla/invoke/field/Value.java
+ test/micro/org/openjdk/bench/valhalla/invoke/field/ValueNullFree.java
+ test/micro/org/openjdk/bench/valhalla/invoke/field/ValueNullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/mandelbrot/Identity.java
+ test/micro/org/openjdk/bench/valhalla/mandelbrot/MandelbrotBase.java
+ test/micro/org/openjdk/bench/valhalla/mandelbrot/Primitive.java
+ test/micro/org/openjdk/bench/valhalla/mandelbrot/Value.java
- test/micro/org/openjdk/bench/valhalla/matrix/Base.java
! test/micro/org/openjdk/bench/valhalla/matrix/Identity.java
- test/micro/org/openjdk/bench/valhalla/matrix/Inline.java
+ test/micro/org/openjdk/bench/valhalla/matrix/MatrixBase.java
! test/micro/org/openjdk/bench/valhalla/matrix/Primitive.java
+ test/micro/org/openjdk/bench/valhalla/matrix/Value.java
+ test/micro/org/openjdk/bench/valhalla/matrix/ValueNullFree.java
+ test/micro/org/openjdk/bench/valhalla/matrix/ValueNullFreeNonAtomic.java
+ test/micro/org/openjdk/bench/valhalla/sum/Identity.java
+ test/micro/org/openjdk/bench/valhalla/sum/Primitive.java
= test/micro/org/openjdk/bench/valhalla/sum/SumBase.java
+ test/micro/org/openjdk/bench/valhalla/sum/Value.java
+ test/micro/org/openjdk/bench/valhalla/sum/ValueNullFree.java
+ test/micro/org/openjdk/bench/valhalla/sum/ValueNullFreeNonAtomic.java
- test/micro/org/openjdk/bench/valhalla/traversal/Identity32.java
- test/micro/org/openjdk/bench/valhalla/traversal/Identity64.java
- test/micro/org/openjdk/bench/valhalla/traversal/Inline32.java
- test/micro/org/openjdk/bench/valhalla/traversal/Inline64.java
- test/micro/org/openjdk/bench/valhalla/traversal/Primitive32.java
- test/micro/org/openjdk/bench/valhalla/traversal/Primitive64.java
- test/micro/org/openjdk/bench/valhalla/types/A64long.java
- test/micro/org/openjdk/bench/valhalla/types/ByByte.java
- test/micro/org/openjdk/bench/valhalla/types/ByInt.java
- test/micro/org/openjdk/bench/valhalla/types/ByLong.java
- test/micro/org/openjdk/bench/valhalla/types/Complex.java
- test/micro/org/openjdk/bench/valhalla/types/Int128.java
- test/micro/org/openjdk/bench/valhalla/types/Int32.java
- test/micro/org/openjdk/bench/valhalla/types/Int64.java
- test/micro/org/openjdk/bench/valhalla/types/Opt.java
- test/micro/org/openjdk/bench/valhalla/types/Q128byte.java
- test/micro/org/openjdk/bench/valhalla/types/Q128int.java
- test/micro/org/openjdk/bench/valhalla/types/Q128long.java
- test/micro/org/openjdk/bench/valhalla/types/Q32byte.java
- test/micro/org/openjdk/bench/valhalla/types/Q32int.java
- test/micro/org/openjdk/bench/valhalla/types/Q64byte.java
- test/micro/org/openjdk/bench/valhalla/types/Q64int.java
- test/micro/org/openjdk/bench/valhalla/types/Q64long.java
- test/micro/org/openjdk/bench/valhalla/types/QComplex.java
- test/micro/org/openjdk/bench/valhalla/types/QOpt.java
- test/micro/org/openjdk/bench/valhalla/types/R128int.java
- test/micro/org/openjdk/bench/valhalla/types/R128long.java
- test/micro/org/openjdk/bench/valhalla/types/R32byte.java
- test/micro/org/openjdk/bench/valhalla/types/R32int.java
- test/micro/org/openjdk/bench/valhalla/types/R64byte.java
- test/micro/org/openjdk/bench/valhalla/types/R64int.java
- test/micro/org/openjdk/bench/valhalla/types/R64long.java
- test/micro/org/openjdk/bench/valhalla/types/RComplex.java
- test/micro/org/openjdk/bench/valhalla/types/ROpt.java
- test/micro/org/openjdk/bench/valhalla/util/Utils.java


From skuksenko at openjdk.org  Mon Sep 15 01:15:21 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Mon, 15 Sep 2025 01:15:21 GMT
Subject: [lworld] RFR: 8367608: [lworld] Update/reimplement valhalla benchmarks
 for JEP 401
Message-ID: <eeJ1Ai4AQi-ZYSmYcGsYERLii30gvuaNe-bKCyNMcE4=.43e83c45-44f0-4b42-8594-0cbcd9b231d3@github.com>

Update/reimplement valhalla benchmarks (org.openjdk.bench.valhalla.*) for JEP 401

-------------

Commit messages:
 - fix whitespaces
 - 8367608: [lworld] Update/reimplement valhalla benchmarks for JEP 401

Changes: https://git.openjdk.org/valhalla/pull/1586/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1586&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367608
  Stats: 55498 lines in 331 files changed: 20861 ins; 34556 del; 81 mod
  Patch: https://git.openjdk.org/valhalla/pull/1586.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1586/head:pull/1586

PR: https://git.openjdk.org/valhalla/pull/1586

From skuksenko at openjdk.org  Mon Sep 15 01:18:20 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Mon, 15 Sep 2025 01:18:20 GMT
Subject: [lworld] Integrated: 8367608: [lworld] Update/reimplement valhalla
 benchmarks for JEP 401
In-Reply-To: <eeJ1Ai4AQi-ZYSmYcGsYERLii30gvuaNe-bKCyNMcE4=.43e83c45-44f0-4b42-8594-0cbcd9b231d3@github.com>
References: <eeJ1Ai4AQi-ZYSmYcGsYERLii30gvuaNe-bKCyNMcE4=.43e83c45-44f0-4b42-8594-0cbcd9b231d3@github.com>
Message-ID: <SyeOVc0ywrzhnGBQaYwIyYi8XoGbcVlQu1t0wLUAKfk=.98a7b2be-1ea6-4911-a01e-dbc4e0e5401f@github.com>

On Mon, 15 Sep 2025 00:44:51 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> Update/reimplement valhalla benchmarks (org.openjdk.bench.valhalla.*) for JEP 401

This pull request has now been integrated.

Changeset: 89308395
Author:    Sergey Kuksenko <skuksenko at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/89308395192c5ac6dc8667c0146591fcf52ce163
Stats:     55498 lines in 331 files changed: 20861 ins; 34556 del; 81 mod

8367608: [lworld] Update/reimplement valhalla benchmarks for JEP 401

-------------

PR: https://git.openjdk.org/valhalla/pull/1586

From chagedorn at openjdk.org  Mon Sep 15 07:18:59 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 15 Sep 2025 07:18:59 GMT
Subject: [lworld] Integrated: 8367548: compiler/intrinsics/bmi tests fail with
 -XX:+AOTClassLinking
In-Reply-To: <HCaYw65hb4zqL02Wz4NkdA6FTbH5Y2HABZMtk8WuGjY=.ae76e5fa-3b04-48ee-9308-4df81e2e3d3f@github.com>
References: <HCaYw65hb4zqL02Wz4NkdA6FTbH5Y2HABZMtk8WuGjY=.ae76e5fa-3b04-48ee-9308-4df81e2e3d3f@github.com>
Message-ID: <n7V2ZzbJQ9oZuWuw8mXVEZqJPGaLlxzIW9Z1B-LXKuw=.c6d5c354-a870-4d14-9fad-049dfb5318ed@github.com>

On Fri, 12 Sep 2025 15:52:06 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The `compiler/intrinsics/bmi` tests started to fail with new AOT changes merged in. 
> 
> ### AOT Warnings with Valhalla due to Adapter Hash Collision
> From the log messages, I saw that we have the following warning message printed with UL:
> 
> '[0.020s][warning][aot,codecache,stubs] Saved blob's name 'IIIIIIIL' is different from the expected name 'LIIIIIII'
> 
> This warning can be traced back to a collision in caching adapters with AOT where two adapters have the same hash. As a result, we need to drop one of the adapters in the AOT cache which is unfortunate but not a problem in correctness. This hash collision seems to be specific to Valhalla because we have a lot more adapters compared to mainline. There is currently an open RFE in mainline ([JDK-8364929](https://bugs.openjdk.org/browse/JDK-8364929)) which tries to improve the situation to give each adapters a unique id.
> 
> ###  Comparison of `Xint` and `Xcomp` Output Fails due to different Timestamps
> The `compiler/intrinsics/bmi` tests call `BMITestRunner` which will run the same test with `-Xint` and `-Xcomp` and then compare the output:
> https://github.com/openjdk/valhalla/blob/28b96c080081b8ebab2656d5dc0f904072d15e40/test/hotspot/jtreg/compiler/intrinsics/bmi/BMITestRunner.java#L87-L100
> We see the AOT warning actually in both runs. The comparison fails because we have a different timestamp in the log for `-Xint` and `-Xcomp`:
> 
> [0.020s][warning][aot,codecache,stubs] Saved blob's name 'IIIIIIIL' is different from the expected name 'LIIIIIII'
> [0.013s][warning][aot,codecache,stubs] Saved blob's name 'IIIIIIIL' is different from the expected name 'LIIIIIII'
> 
> So, the fix would be to get rid of the timestamps. 
> 
> ### Getting Rid of Timestamps already Implemented but Wrongly
> However, we already have some special code that actually wants to remove timestamps and all AOT logs altogether (introduced with https://github.com/openjdk/valhalla/commit/3b32f6a8ec37338764d3e6713247ff96e49bf5b3 for some Graal specific failure) :
> https://github.com/openjdk/valhalla/blob/28b96c080081b8ebab2656d5dc0f904072d15e40/test/hotspot/jtreg/compiler/intrinsics/bmi/BMITestRunner.java#L125-L129
> But this does not seem to work. I played around with `Xlog` and found that surprisingly this:
> 
> -Xlog:all=warning:stdout:level,tags -Xlog:aot=off
> 
> seems to be expanded to
> 
> -Xlog:all=warning:stdout:level,tags -Xlog:aot=off:stdout:<default decorators>
> 
> and the second `Xlog` overrides the decorators and reintroduces the timestamps again.
> 
> ### Proposed Fix
> The ...

This pull request has now been integrated.

Changeset: 1c011a37
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1c011a377002de35f8086a8ba4fdce1ed898cfca
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8367548: compiler/intrinsics/bmi tests fail with -XX:+AOTClassLinking

-------------

PR: https://git.openjdk.org/valhalla/pull/1582

From dsimms at openjdk.org  Mon Sep 15 08:40:25 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 15 Sep 2025 08:40:25 GMT
Subject: [lworld] Integrated: [BACKOUT] 8367608: [lworld] Update/reimplement
 valhalla benchmarks for JEP 401
Message-ID: <TatQ8SBmAfvPKESoGcV1bQ0jlSO_luIhyB1XHDDARVg=.f0428180-8517-480c-9a95-9588eaeef567@github.com>

Revert 8367608, has build issues

-------------

Commit messages:
 - [BACKOUT] 8367608: [lworld] Update/reimplement valhalla benchmarks for JEP 401

Changes: https://git.openjdk.org/valhalla/pull/1587/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1587&range=00
  Stats: 55904 lines in 331 files changed: 34554 ins; 21291 del; 59 mod
  Patch: https://git.openjdk.org/valhalla/pull/1587.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1587/head:pull/1587

PR: https://git.openjdk.org/valhalla/pull/1587

From dsimms at openjdk.org  Mon Sep 15 08:40:26 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 15 Sep 2025 08:40:26 GMT
Subject: [lworld] Integrated: [BACKOUT] 8367608: [lworld] Update/reimplement
 valhalla benchmarks for JEP 401
In-Reply-To: <TatQ8SBmAfvPKESoGcV1bQ0jlSO_luIhyB1XHDDARVg=.f0428180-8517-480c-9a95-9588eaeef567@github.com>
References: <TatQ8SBmAfvPKESoGcV1bQ0jlSO_luIhyB1XHDDARVg=.f0428180-8517-480c-9a95-9588eaeef567@github.com>
Message-ID: <VAow5wqEqHbi0MchtwRcLE71r1vWIy52kdhfPDLz5rA=.f7e37915-1f46-4a64-b4ee-8cbe5ed7ec3f@github.com>

On Mon, 15 Sep 2025 07:31:55 GMT, David Simms <dsimms at openjdk.org> wrote:

> Revert 8367608, has build issues

This pull request has now been integrated.

Changeset: e40fde69
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e40fde6983ff2723ec4cc4afd8d6361f99afa21b
Stats:     55904 lines in 331 files changed: 34554 ins; 21291 del; 59 mod

[BACKOUT] 8367608: [lworld] Update/reimplement valhalla benchmarks for JEP 401

-------------

PR: https://git.openjdk.org/valhalla/pull/1587

From phubner at openjdk.org  Mon Sep 15 12:02:03 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Sep 2025 12:02:03 GMT
Subject: [lworld] RFR: 8270527: [lworld] markWord::print_on() needs to reflect
 the additional Valhalla mark word bits
Message-ID: <TVMixYdPXHJOE5quIOLdzUxUUPUoGipgwWGR7jRT76c=.b0c01253-60bd-4d22-9332-09aa9d050659@github.com>

Hi all,

This adds debug information to the `markWord::print_on` method for the Valhalla bits. The existing unit tests have been augmented.

Testing: tier 1.

-------------

Commit messages:
 - Pretty print Valhalla mark word bits.

Changes: https://git.openjdk.org/valhalla/pull/1588/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1588&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8270527
  Stats: 33 lines in 2 files changed: 31 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1588.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1588/head:pull/1588

PR: https://git.openjdk.org/valhalla/pull/1588

From chagedorn at openjdk.org  Mon Sep 15 12:09:12 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 15 Sep 2025 12:09:12 GMT
Subject: [lworld] RFR: 8367375: [lworld] Crash when using CDS archive
 created with -XX:+UseCompactObjectHeaders and preview mode
In-Reply-To: <YRVv-IXMfUB8sEwDy7F-C1puWeiKbSCItRGgTnhZ1RQ=.e12a4f08-92e6-44ea-a99a-44849f6f36f4@github.com>
References: <YRVv-IXMfUB8sEwDy7F-C1puWeiKbSCItRGgTnhZ1RQ=.e12a4f08-92e6-44ea-a99a-44849f6f36f4@github.com>
Message-ID: <D_gfz7WWxDATP4hNdGUx75IsSBQ8G1tHd9sB12FnhXA=.56ffb4b6-00c2-434f-95b2-a9fcf9a6a1cf@github.com>

On Thu, 11 Sep 2025 21:21:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a small fix to make -Xshare:dump and -Xshare:on work with --enable-preview and -XX:+UseCompactObjectHeaders and -Xint.

Thanks for fixing this! Looks good to me but @matias9927 should probably also have a look :-)

-------------

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1577#pullrequestreview-3224284968

From mcimadamore at openjdk.org  Mon Sep 15 12:35:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Sep 2025 12:35:51 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370 [v4]
In-Reply-To: <gPQBBj4PS_Sgc6Is4X_oifbTf5JaJ-YiyzXq8x2kLys=.913589a1-e89b-49fc-91e1-5f94dcfdb75c@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
 <gPQBBj4PS_Sgc6Is4X_oifbTf5JaJ-YiyzXq8x2kLys=.913589a1-e89b-49fc-91e1-5f94dcfdb75c@github.com>
Message-ID: <lLeQWzRdj5A-8RyMHSKQ3-GpeusdR57WSH7tLxpyoM0=.08d37904-4c79-432e-b726-95d169a3e35b@github.com>

On Fri, 12 Sep 2025 17:57:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
>> 
>> class SuperClass<T> {
>>     public SuperClass(Object o) {}
>> }
>> 
>> class Sub<T> extends SuperClass<T> {
>>     public Sub() {
>>         super(new Object() {
>>             void foo() {
>>                 getClass();
>>             }
>>         });
>>     }
>> }
>> 
>> 
>> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing unnecessary check

Marked as reviewed by mcimadamore (Committer).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1481:

> 1479:                     /* so we are inside a class, CI, in the prologue of an outer class, CO, and the symbol being
> 1480:                      * analyzed has no qualifier. So if the symbol is a member of CI the reference is allowed,
> 1481:                      * otherwise it is not.

Optional -- maybe we can just add a final sentence saying that, in case reference to CI's member happens inside CI's own prologue, that will be checked separately (e.g. when visiting CI's prologue), so we don't have to report anything (yet) ?

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1567#pullrequestreview-3224397856
PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2348853531

From vromero at openjdk.org  Mon Sep 15 12:56:04 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 15 Sep 2025 12:56:04 GMT
Subject: [lworld] RFR: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370 [v5]
In-Reply-To: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
Message-ID: <mXF6eoPwC5IeXkaf7s9vBDoCESIH7yU0MKqiZN-Z4VM=.35e6df63-133d-4688-ad4b-19f6e0b4e0aa@github.com>

> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
> 
> class SuperClass<T> {
>     public SuperClass(Object o) {}
> }
> 
> class Sub<T> extends SuperClass<T> {
>     public Sub() {
>         super(new Object() {
>             void foo() {
>                 getClass();
>             }
>         });
>     }
> }
> 
> 
> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  updating comment

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1567/files
  - new: https://git.openjdk.org/valhalla/pull/1567/files/c34f98b1..c1b7aaac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1567&range=04
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1567&range=03-04

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1567.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1567/head:pull/1567

PR: https://git.openjdk.org/valhalla/pull/1567

From vromero at openjdk.org  Mon Sep 15 13:11:03 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 15 Sep 2025 13:11:03 GMT
Subject: [lworld] Integrated: 8367323: [lworld] javac is rejecting valid code
 after fix for JDK-8359370
In-Reply-To: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
References: <8Gg4Mk-I8Y-5DORiSvJASmHutlTqHi8o_XtRjE-7Gps=.0e2a6ad1-a0ae-478b-9db5-b4da7bf6da27@github.com>
Message-ID: <TiyqrazPleY9BshXpJV69h9O3FPh3zSiXBJLAWA3gcA=.225c854d-28b3-4e7f-962f-78f95ad3c7b0@github.com>

On Thu, 11 Sep 2025 02:14:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) introduced a minor bug. This code should be accepted by javac:
> 
> class SuperClass<T> {
>     public SuperClass(Object o) {}
> }
> 
> class Sub<T> extends SuperClass<T> {
>     public Sub() {
>         super(new Object() {
>             void foo() {
>                 getClass();
>             }
>         });
>     }
> }
> 
> 
> but it is currently rejected as the `getClass` invocation is considered to be an invocation of an instance method of class `Sub`

This pull request has now been integrated.

Changeset: 04efe5c6
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/04efe5c66b70b9dca1a5c538c9a04e7ad93c107a
Stats:     96 lines in 4 files changed: 52 ins; 23 del; 21 mod

8367323: [lworld] javac is rejecting valid code after fix for JDK-8359370

Reviewed-by: liach, mcimadamore

-------------

PR: https://git.openjdk.org/valhalla/pull/1567

From skuksenko at openjdk.org  Tue Sep 16 01:21:42 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Tue, 16 Sep 2025 01:21:42 GMT
Subject: [lworld] RFR: Jdk 8367608
Message-ID: <GBsWOFpaokahDmfqXBCsO563b6JZippoDEffxQvVGrA=.cdab646f-174a-45cd-babb-a9f9a1a89fb2@github.com>

8367608: [lworld] Update/reimplement valhalla benchmarks for JEP 401
(build issue fixed)

-------------

Commit messages:
 - fix the issue with case insensitive file systems on Windows and MacOS
 - fix whitespaces
 - 8367608: [lworld] Update/reimplement valhalla benchmarks for JEP 401

Changes: https://git.openjdk.org/valhalla/pull/1589/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1589&range=00
  Stats: 55472 lines in 331 files changed: 20835 ins; 34556 del; 81 mod
  Patch: https://git.openjdk.org/valhalla/pull/1589.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1589/head:pull/1589

PR: https://git.openjdk.org/valhalla/pull/1589

From mchevalier at openjdk.org  Tue Sep 16 07:55:52 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 16 Sep 2025 07:55:52 GMT
Subject: [lworld] RFR: 8367156: [lworld] MacroAssembler::remove_frame hits
 "Field too big for insn" [v3]
In-Reply-To: <eTyY3FGITZ_jjbWIUXsC74tKUIkgJmdh37nbhU4xRSE=.80ef24dc-7894-46f9-88ef-bec3b7e7d376@github.com>
References: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
 <eTyY3FGITZ_jjbWIUXsC74tKUIkgJmdh37nbhU4xRSE=.80ef24dc-7894-46f9-88ef-bec3b7e7d376@github.com>
Message-ID: <YWrn5i2Aovhxa-KJuKUwcW_WZC9KgA5V3pPBoeNLwFQ=.3b521b1d-9f3b-4919-be3d-dd96c1c14eee@github.com>

On Fri, 12 Sep 2025 16:23:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> As suspected, it's just a too big offset. We used to have a
>> https://github.com/openjdk/valhalla/blob/c8d4a247861052aa6ed43125bcbe49995326938f/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6133
>> 
>> I changed it into
>> https://github.com/openjdk/valhalla/blob/880ae47831ed7262a0d3b30b92c3645bc67e5df2/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6136
>> 
>> But [`ldp`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDP--Load-pair-of-registers-) has only a 7-bit offset. It's big, but not big enough. In some cases I've looked at, the offset can be as big as `536` which fits on 9 bits. [`ldr`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDR--immediate---Load-register--immediate--) supports a 9-bit offset. Let's change the `ldp` into
>> 
>> 
>> ldr(rscratch1, Address(sp, sp_inc_offset))
>> ldr(rfp, Address(sp, sp_inc_offset + wordSize))
>> 
>> which will be merged into one `ldp` if the offset fits.
>> 
>> But what if the offset is bigger than what fits on 9 bits? Well, us used to have the `ldr(rscratch1, Address(sp, sp_inc_offset))` so either we have a big problem (too big frames?) or `sp_inc_offset` was just bordeline and `sp_inc_offset + wordSize` is too big. But we still have `sp_inc_offset + wordSize == initial_framesize - 2 * wordSize` which would mean that `initial_framesize` doesn't fit on 9 bits either. Once again, that sounds like a bigger (and unlikely) problem.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove /othervm

Thanks @chhagedorn & @TobiHartmann for reviews.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1575#issuecomment-3296361232

From duke at openjdk.org  Tue Sep 16 07:55:53 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Sep 2025 07:55:53 GMT
Subject: [lworld] RFR: 8367156: [lworld] MacroAssembler::remove_frame hits
 "Field too big for insn" [v3]
In-Reply-To: <eTyY3FGITZ_jjbWIUXsC74tKUIkgJmdh37nbhU4xRSE=.80ef24dc-7894-46f9-88ef-bec3b7e7d376@github.com>
References: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
 <eTyY3FGITZ_jjbWIUXsC74tKUIkgJmdh37nbhU4xRSE=.80ef24dc-7894-46f9-88ef-bec3b7e7d376@github.com>
Message-ID: <W4p6ZguIITgNe0VExI0cXkfHNvWtwoHNKLO0CQyOtpk=.da2dd930-754e-4df0-96c1-7b5e44c10520@github.com>

On Fri, 12 Sep 2025 16:23:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> As suspected, it's just a too big offset. We used to have a
>> https://github.com/openjdk/valhalla/blob/c8d4a247861052aa6ed43125bcbe49995326938f/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6133
>> 
>> I changed it into
>> https://github.com/openjdk/valhalla/blob/880ae47831ed7262a0d3b30b92c3645bc67e5df2/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6136
>> 
>> But [`ldp`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDP--Load-pair-of-registers-) has only a 7-bit offset. It's big, but not big enough. In some cases I've looked at, the offset can be as big as `536` which fits on 9 bits. [`ldr`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDR--immediate---Load-register--immediate--) supports a 9-bit offset. Let's change the `ldp` into
>> 
>> 
>> ldr(rscratch1, Address(sp, sp_inc_offset))
>> ldr(rfp, Address(sp, sp_inc_offset + wordSize))
>> 
>> which will be merged into one `ldp` if the offset fits.
>> 
>> But what if the offset is bigger than what fits on 9 bits? Well, us used to have the `ldr(rscratch1, Address(sp, sp_inc_offset))` so either we have a big problem (too big frames?) or `sp_inc_offset` was just bordeline and `sp_inc_offset + wordSize` is too big. But we still have `sp_inc_offset + wordSize == initial_framesize - 2 * wordSize` which would mean that `initial_framesize` doesn't fit on 9 bits either. Once again, that sounds like a bigger (and unlikely) problem.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove /othervm

@marc-chevalier 
Your change (at version 0e6a16ff2c85c96ecaec10062bdbcfac07b8e3cd) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1575#issuecomment-3296368057

From mchevalier at openjdk.org  Tue Sep 16 08:26:46 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 16 Sep 2025 08:26:46 GMT
Subject: [lworld] Integrated: 8367156: [lworld] MacroAssembler::remove_frame
 hits "Field too big for insn"
In-Reply-To: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
References: <1OjX2DDU8zxjIyXW9Uwqx60cEsavBy9AfVTkVsh5_sU=.7156d1e1-f183-46ab-b683-1d53716f27ef@github.com>
Message-ID: <1qoLxS-1LaB8VKhMxlPAlhNz2bDW1NB08Ua4Ohfa47s=.3dc7503e-3e19-45b7-bb9d-0fdb9396aed3@github.com>

On Thu, 11 Sep 2025 14:13:41 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> As suspected, it's just a too big offset. We used to have a
> https://github.com/openjdk/valhalla/blob/c8d4a247861052aa6ed43125bcbe49995326938f/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6133
> 
> I changed it into
> https://github.com/openjdk/valhalla/blob/880ae47831ed7262a0d3b30b92c3645bc67e5df2/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6136
> 
> But [`ldp`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDP--Load-pair-of-registers-) has only a 7-bit offset. It's big, but not big enough. In some cases I've looked at, the offset can be as big as `536` which fits on 9 bits. [`ldr`](https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/LDR--immediate---Load-register--immediate--) supports a 9-bit offset. Let's change the `ldp` into
> 
> 
> ldr(rscratch1, Address(sp, sp_inc_offset))
> ldr(rfp, Address(sp, sp_inc_offset + wordSize))
> 
> which will be merged into one `ldp` if the offset fits.
> 
> But what if the offset is bigger than what fits on 9 bits? Well, us used to have the `ldr(rscratch1, Address(sp, sp_inc_offset))` so either we have a big problem (too big frames?) or `sp_inc_offset` was just bordeline and `sp_inc_offset + wordSize` is too big. But we still have `sp_inc_offset + wordSize == initial_framesize - 2 * wordSize` which would mean that `initial_framesize` doesn't fit on 9 bits either. Once again, that sounds like a bigger (and unlikely) problem.
> 
> Thanks,
> Marc

This pull request has now been integrated.

Changeset: 4da4927e
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4da4927e310fe366421b47f68d5a9662abc75d88
Stats:     63 lines in 2 files changed: 62 ins; 0 del; 1 mod

8367156: [lworld] MacroAssembler::remove_frame hits "Field too big for insn"

Reviewed-by: thartmann, chagedorn

-------------

PR: https://git.openjdk.org/valhalla/pull/1575

From phubner at openjdk.org  Tue Sep 16 09:37:12 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Sep 2025 09:37:12 GMT
Subject: [lworld] RFR: 8367691:
 runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java
 crashes with segmentation fault
Message-ID: <RNj1Eu9e6oDGKbQ5YYxCoY8C3KXF0DtzycU447B3v4o=.ea38793a-bc4a-4259-8c07-659ac549d723@github.com>

Hi all,

A very generous code cache should address the issue where we run out of memory.

Testing: stress testing this test with 50 iterations.

-------------

Commit messages:
 - Update limits.

Changes: https://git.openjdk.org/valhalla/pull/1590/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1590&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367691
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1590.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1590/head:pull/1590

PR: https://git.openjdk.org/valhalla/pull/1590

From matsaave at openjdk.org  Tue Sep 16 16:33:52 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 16 Sep 2025 16:33:52 GMT
Subject: [lworld] RFR: 8366743: [lworld]: Verifier adjustments for
 operations on 'uninitialized' [v3]
In-Reply-To: <BN9lEyfsPzCh3W7x2GvCJea4ZRtZ-6DEM8IqM7680iE=.44229228-a376-4503-aa20-7a943904551f@github.com>
References: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
 <5z448R2lXN9KgTgI715d1KCUW321PvtNNNPQLBTVwc0=.3e546bd7-ebfb-493d-9015-a98b7a774916@github.com>
 <BN9lEyfsPzCh3W7x2GvCJea4ZRtZ-6DEM8IqM7680iE=.44229228-a376-4503-aa20-7a943904551f@github.com>
Message-ID: <lpz0AulYRkcleFQSpytmo4Ar_jlYAWWhxIKCcNq-2T8=.0a238254-810a-48a4-97c1-24421b468f4d@github.com>

On Fri, 12 Sep 2025 19:28:07 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge commit 'refs/pull/1566/head' of github.com:openjdk/valhalla into uninit_implementation_8366271
>>  - Added fix and tests for old verifier
>
> HotSpot changes and tests look good to me.

Thanks for the review @fparain and thank you for the Classfile API changes @liach!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1566#issuecomment-3299516370

From matsaave at openjdk.org  Tue Sep 16 16:33:55 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 16 Sep 2025 16:33:55 GMT
Subject: [lworld] Integrated: 8366743: [lworld]: Verifier adjustments for
 operations on 'uninitialized'
In-Reply-To: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
References: <t0aV1hnnmfHuJ928TuI6AMT2EjohWtXMI44TcKkSP1c=.c4dee82e-09a2-40cc-8a20-afeec6c9fbdc@github.com>
Message-ID: <Xpf8f5foC_GmrZvDf5f4R0Xr-U0TteeFRn8QQkCYzW0=.daf17792-647a-4f7b-bde9-882d0971c926@github.com>

On Wed, 10 Sep 2025 22:17:45 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The updated spec places more restrictions on the use of uninitialized and uninitializedThis with certain bytecodes. Those spec changes are implemented with this patch and tested with a new set of tests. Verified with the new test as well as tiers 1-5.

This pull request has now been integrated.

Changeset: 9a952beb
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9a952beb1a3fc1c9eb87afa14c9e06ea23499b4c
Stats:     467 lines in 13 files changed: 459 ins; 3 del; 5 mod

8366743: [lworld]: Verifier adjustments for operations on 'uninitialized'

Co-authored-by: Chen Liang <liach at openjdk.org>
Reviewed-by: fparain

-------------

PR: https://git.openjdk.org/valhalla/pull/1566

From skuksenko at openjdk.org  Tue Sep 16 17:04:05 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Tue, 16 Sep 2025 17:04:05 GMT
Subject: [lworld] Integrated: 8367608: [lworld] Update/reimplement valhalla
 benchmarks for JEP 401
In-Reply-To: <GBsWOFpaokahDmfqXBCsO563b6JZippoDEffxQvVGrA=.cdab646f-174a-45cd-babb-a9f9a1a89fb2@github.com>
References: <GBsWOFpaokahDmfqXBCsO563b6JZippoDEffxQvVGrA=.cdab646f-174a-45cd-babb-a9f9a1a89fb2@github.com>
Message-ID: <VPjZZ3buL2XGgtmQD8qvyJQi85xl9U8iWpOg1wacZYM=.63d31656-e0bb-4def-8b1e-2a8652c4fa6b@github.com>

On Tue, 16 Sep 2025 01:09:09 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> 8367608: [lworld] Update/reimplement valhalla benchmarks for JEP 401
> (build issue fixed)

This pull request has now been integrated.

Changeset: b1a388b7
Author:    Sergey Kuksenko <skuksenko at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b1a388b795a3f4ebaf867f7705f92887bf0d22b2
Stats:     55472 lines in 331 files changed: 20835 ins; 34556 del; 81 mod

8367608: [lworld] Update/reimplement valhalla benchmarks for JEP 401

-------------

PR: https://git.openjdk.org/valhalla/pull/1589

From matsaave at openjdk.org  Tue Sep 16 18:05:56 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 16 Sep 2025 18:05:56 GMT
Subject: [lworld] RFR: 8367375: [lworld] Crash when using CDS archive
 created with -XX:+UseCompactObjectHeaders and preview mode
In-Reply-To: <YRVv-IXMfUB8sEwDy7F-C1puWeiKbSCItRGgTnhZ1RQ=.e12a4f08-92e6-44ea-a99a-44849f6f36f4@github.com>
References: <YRVv-IXMfUB8sEwDy7F-C1puWeiKbSCItRGgTnhZ1RQ=.e12a4f08-92e6-44ea-a99a-44849f6f36f4@github.com>
Message-ID: <6QhDsZKSVQeGQlAFEOwTRPJiU91yXH9u9I3QraiwoEE=.ccfce3b5-6858-44fb-b4c0-5bd262cbc0fa@github.com>

On Thu, 11 Sep 2025 21:21:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a small fix to make -Xshare:dump and -Xshare:on work with --enable-preview and -XX:+UseCompactObjectHeaders and -Xint.

Change looks good, thanks!

-------------

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1577#pullrequestreview-3231126865

From coleenp at openjdk.org  Tue Sep 16 19:02:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Sep 2025 19:02:37 GMT
Subject: [lworld] RFR: 8367375: Crash when using CDS archive created with
 -XX:+UseCompactObjectHeaders and preview mode
In-Reply-To: <YRVv-IXMfUB8sEwDy7F-C1puWeiKbSCItRGgTnhZ1RQ=.e12a4f08-92e6-44ea-a99a-44849f6f36f4@github.com>
References: <YRVv-IXMfUB8sEwDy7F-C1puWeiKbSCItRGgTnhZ1RQ=.e12a4f08-92e6-44ea-a99a-44849f6f36f4@github.com>
Message-ID: <Ez3fnqerah-1iJrBCuDTVfcRDxLC935YvH_r4yGmmNU=.3f6e9d2b-e039-42d8-9cc8-baf90a58f3a6@github.com>

On Thu, 11 Sep 2025 21:21:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a small fix to make -Xshare:dump and -Xshare:on work with --enable-preview and -XX:+UseCompactObjectHeaders and -Xint.

Thank you Christian and Matias.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1577#issuecomment-3299975217

From coleenp at openjdk.org  Tue Sep 16 19:02:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Sep 2025 19:02:38 GMT
Subject: [lworld] Integrated: 8367375: Crash when using CDS archive created
 with -XX:+UseCompactObjectHeaders and preview mode
In-Reply-To: <YRVv-IXMfUB8sEwDy7F-C1puWeiKbSCItRGgTnhZ1RQ=.e12a4f08-92e6-44ea-a99a-44849f6f36f4@github.com>
References: <YRVv-IXMfUB8sEwDy7F-C1puWeiKbSCItRGgTnhZ1RQ=.e12a4f08-92e6-44ea-a99a-44849f6f36f4@github.com>
Message-ID: <YY7D4RdBE_MhiCqlB0N5uiaf2uIKABSQO6GIZuFkpOk=.016857ac-9c49-42a1-a89a-40c791739212@github.com>

On Thu, 11 Sep 2025 21:21:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a small fix to make -Xshare:dump and -Xshare:on work with --enable-preview and -XX:+UseCompactObjectHeaders and -Xint.

This pull request has now been integrated.

Changeset: 5b910ab2
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5b910ab285106531d19c7426bb8792009267f1c2
Stats:     9 lines in 5 files changed: 7 ins; 0 del; 2 mod

8367375: Crash when using CDS archive created with -XX:+UseCompactObjectHeaders and preview mode

Reviewed-by: chagedorn, matsaave

-------------

PR: https://git.openjdk.org/valhalla/pull/1577

From matsaave at openjdk.org  Tue Sep 16 19:15:49 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 16 Sep 2025 19:15:49 GMT
Subject: [lworld] RFR: 8353303: Configuring with --disable-cds causes
 cdsConfig.hpp compilaition errors
Message-ID: <TI0Gk1gKGqC_5dohuKT3Ne1Xy9m7-f5iH5_k6VBXcwU=.7965c0b5-4d91-4126-8158-da2ea0e8c4e7@github.com>

Configuring with --disable-cds results in compilation errors due to CDS code not being encapsulated correctly. Verified with tier 1-5 tests.

-------------

Commit messages:
 - 8353303: Configuring with --disable-cds causes cdsConfig.hpp compilation errors

Changes: https://git.openjdk.org/valhalla/pull/1591/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1591&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353303
  Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1591.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1591/head:pull/1591

PR: https://git.openjdk.org/valhalla/pull/1591

From fparain at openjdk.org  Tue Sep 16 19:27:59 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Sep 2025 19:27:59 GMT
Subject: [lworld] RFR: 8349037: [lworld]
 runtime/valhalla/inlinetypes/CircularityTest.java crashes with SIGSEGV
Message-ID: <JStZ9fsXh1jhRv9TTYVFMr7QLOQsfzHf0MBizzFKyqM=.7e6fab0c-484b-420f-9cea-474064e5b0c9@github.com>

runtime/valhalla/inlinetypes/CircularityTest.java was written to test the behavior of the JVM with respect of the initialization of classes of default values when the JVM was in charge of initializing null-restricted fields.
JEP 401 went into a different direction, the concept of default value has been removed, and the concept of strict fields has been defined to force user code to reliably initialized all strict fields before their first read.
Strict fields have their own tests ensuring static fields initialization rules are correctly enforced.
This test is then obsolete and should be removed from the repository.

-------------

Commit messages:
 - Remove obsolete test

Changes: https://git.openjdk.org/valhalla/pull/1592/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1592&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349037
  Stats: 207 lines in 2 files changed: 0 ins; 207 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1592.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1592/head:pull/1592

PR: https://git.openjdk.org/valhalla/pull/1592

From lfoltan at openjdk.org  Tue Sep 16 19:46:18 2025
From: lfoltan at openjdk.org (Lois Foltan)
Date: Tue, 16 Sep 2025 19:46:18 GMT
Subject: [lworld] RFR: 8349037: [lworld]
 runtime/valhalla/inlinetypes/CircularityTest.java crashes with SIGSEGV
In-Reply-To: <JStZ9fsXh1jhRv9TTYVFMr7QLOQsfzHf0MBizzFKyqM=.7e6fab0c-484b-420f-9cea-474064e5b0c9@github.com>
References: <JStZ9fsXh1jhRv9TTYVFMr7QLOQsfzHf0MBizzFKyqM=.7e6fab0c-484b-420f-9cea-474064e5b0c9@github.com>
Message-ID: <ihCtiPIiSPE0YEDN5wrKVfczCteFpn_9L7Gqm8cWGb4=.1142bc85-b712-45ab-a70e-a08ba1aee6f6@github.com>

On Tue, 16 Sep 2025 19:22:02 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> runtime/valhalla/inlinetypes/CircularityTest.java was written to test the behavior of the JVM with respect of the initialization of classes of default values when the JVM was in charge of initializing null-restricted fields.
> JEP 401 went into a different direction, the concept of default value has been removed, and the concept of strict fields has been defined to force user code to reliably initialized all strict fields before their first read.
> Strict fields have their own tests ensuring static fields initialization rules are correctly enforced.
> This test is then obsolete and should be removed from the repository.

Looks good.
Lois

-------------

Marked as reviewed by lfoltan (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1592#pullrequestreview-3231465104

From fparain at openjdk.org  Tue Sep 16 21:11:17 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Sep 2025 21:11:17 GMT
Subject: [lworld] RFR: 8349037: [lworld]
 runtime/valhalla/inlinetypes/CircularityTest.java crashes with SIGSEGV
In-Reply-To: <JStZ9fsXh1jhRv9TTYVFMr7QLOQsfzHf0MBizzFKyqM=.7e6fab0c-484b-420f-9cea-474064e5b0c9@github.com>
References: <JStZ9fsXh1jhRv9TTYVFMr7QLOQsfzHf0MBizzFKyqM=.7e6fab0c-484b-420f-9cea-474064e5b0c9@github.com>
Message-ID: <aS1fC_TGS_fnA0wa0ogSNEF8Vg1lBJJkxLeYMUJNgs4=.e24adb88-7432-4163-9c56-881c6c2107fb@github.com>

On Tue, 16 Sep 2025 19:22:02 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> runtime/valhalla/inlinetypes/CircularityTest.java was written to test the behavior of the JVM with respect of the initialization of classes of default values when the JVM was in charge of initializing null-restricted fields.
> JEP 401 went into a different direction, the concept of default value has been removed, and the concept of strict fields has been defined to force user code to reliably initialized all strict fields before their first read.
> Strict fields have their own tests ensuring static fields initialization rules are correctly enforced.
> This test is then obsolete and should be removed from the repository.

Thank your for the review Lois.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1592#issuecomment-3300358621

From fparain at openjdk.org  Tue Sep 16 21:11:18 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Sep 2025 21:11:18 GMT
Subject: [lworld] Integrated: 8349037: [lworld]
 runtime/valhalla/inlinetypes/CircularityTest.java crashes with SIGSEGV
In-Reply-To: <JStZ9fsXh1jhRv9TTYVFMr7QLOQsfzHf0MBizzFKyqM=.7e6fab0c-484b-420f-9cea-474064e5b0c9@github.com>
References: <JStZ9fsXh1jhRv9TTYVFMr7QLOQsfzHf0MBizzFKyqM=.7e6fab0c-484b-420f-9cea-474064e5b0c9@github.com>
Message-ID: <mxeM9N80_WPli8qxy7XQi2EAUcqlQd1Au7QGYQoM8QE=.a0da5080-7129-4a2b-8c03-525bf533a53a@github.com>

On Tue, 16 Sep 2025 19:22:02 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> runtime/valhalla/inlinetypes/CircularityTest.java was written to test the behavior of the JVM with respect of the initialization of classes of default values when the JVM was in charge of initializing null-restricted fields.
> JEP 401 went into a different direction, the concept of default value has been removed, and the concept of strict fields has been defined to force user code to reliably initialized all strict fields before their first read.
> Strict fields have their own tests ensuring static fields initialization rules are correctly enforced.
> This test is then obsolete and should be removed from the repository.

This pull request has now been integrated.

Changeset: 54c8105b
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/54c8105bde3f2bbe62324d67ab4e8df7b3811679
Stats:     207 lines in 2 files changed: 0 ins; 207 del; 0 mod

8349037: [lworld] runtime/valhalla/inlinetypes/CircularityTest.java crashes with SIGSEGV

Reviewed-by: lfoltan

-------------

PR: https://git.openjdk.org/valhalla/pull/1592

From duke at openjdk.org  Tue Sep 16 22:01:44 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Sep 2025 22:01:44 GMT
Subject: [lworld] Withdrawn: 8366200: Modify jimage package flags to support
 preview mode
In-Reply-To: <T9agi8MWtFWN7-c5BwNDea33o6TQkdLft0v83eOv_qM=.9c75b546-ac8b-4a09-9cd4-68ee68e87a72@github.com>
References: <T9agi8MWtFWN7-c5BwNDea33o6TQkdLft0v83eOv_qM=.9c75b546-ac8b-4a09-9cd4-68ee68e87a72@github.com>
Message-ID: <WBo-MtavrPDeH2j-aHWR7ImDsMvz10luqs1arFiAVLI=.d4246b23-c7ff-4a8d-a462-c0c0ec1a2d25@github.com>

On Fri, 29 Aug 2025 13:21:07 GMT, David Beaumont <duke at openjdk.org> wrote:

> Reuses the previously unused package flags in the /packages/xxx entries of jimage files to support preview mode.
> 
> With these flags it becomes simple to determine things like:
> 1. Which modules are children of /packages/xxx
>   - This can differ between preview and non-preview mode.
> 
> 2. Which modules/packages have any preview content
>   - Useful in preview mode for faster rejection testing to avoid double-lookup on all resources.
> 
> If there are no preview resources built into the jimage file, then the difference between output is that the "isEmpty" flag (old version) has become a "hasContent" flag (but since these flags are not read by anyone right now, this should not be an issue).
> 
> Note that bumping the minor version number was done to ensure that, during testing, no undiscovered code is reading the new file with old logic (this would work since there's no structural change, but the semantics are different).
> 
> This does mean that on systems where a 'jimage' binary is installed for the JDK (e.g. /usr/bin/jimage), that tool will stop working on files generate by this code, but the version of that binary in the built JDK will work. The alternative is to just not bump the version number (if nobody is reading the flags now, it shouldn't matter what's in them).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/valhalla/pull/1537

From coleenp at openjdk.org  Tue Sep 16 22:23:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Sep 2025 22:23:12 GMT
Subject: [lworld] RFR: 8337547: Add LoadableDescriptors to comments for class
 loading
Message-ID: <aL_83TJO45WFoxFaSKX70qhpz3lvqTcZtFCzQjQOzJ4=.f161a454-8650-4193-b1de-d4dd1e1561ca@github.com>

This change adds comments for LoadableDescriptors for inline field layout processing to the class loading comments.  The other changes are to make the valhalla version of placeholders and systemDictionary match what is in mainline.  In mainline, interface and super class calls resolve_super_or_fail, otherwise we call resolve_with_circularity_detection.  There are some other comments in mainline in these files that aren't great, that are not addressed here in the Valhalla version.
Tested with tier1 locally.

-------------

Commit messages:
 - adjust blank line
 - 8337547: Add LoadableDescriptors to comments for class loading

Changes: https://git.openjdk.org/valhalla/pull/1594/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1594&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337547
  Stats: 26 lines in 5 files changed: 3 ins; 3 del; 20 mod
  Patch: https://git.openjdk.org/valhalla/pull/1594.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1594/head:pull/1594

PR: https://git.openjdk.org/valhalla/pull/1594

From liach at openjdk.org  Tue Sep 16 22:45:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Sep 2025 22:45:02 GMT
Subject: [lworld] RFR: 8367792: [lworld] Remove the Unsafe remnants of old
 valhalla prototypes
Message-ID: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>

There are some remnants from previous iterations of value objects in Unsafe. We should aim to remove them for cleaner code in the future.

-------------

Commit messages:
 - Remove old unsafe value stuff

Changes: https://git.openjdk.org/valhalla/pull/1593/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367792
  Stats: 630 lines in 13 files changed: 0 ins; 589 del; 41 mod
  Patch: https://git.openjdk.org/valhalla/pull/1593.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1593/head:pull/1593

PR: https://git.openjdk.org/valhalla/pull/1593

From liach at openjdk.org  Tue Sep 16 22:45:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Sep 2025 22:45:03 GMT
Subject: [lworld] RFR: 8367792: [lworld] Remove the Unsafe remnants of old
 valhalla prototypes
In-Reply-To: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
References: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
Message-ID: <TXvqmJ1x8lLxL-TH20wBPMQ9XftC-q-AW-h1_cuB_Go=.3cd14335-1358-4855-8fc4-1c202257eee0@github.com>

On Tue, 16 Sep 2025 22:08:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> There are some remnants from previous iterations of value objects in Unsafe. We should aim to remove them for cleaner code in the future.

Testing: tier 1-3 on linux-x64 finished clear.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1593#issuecomment-3300565858

From coleenp at openjdk.org  Tue Sep 16 23:02:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Sep 2025 23:02:06 GMT
Subject: [lworld] RFR: 8353303: Configuring with --disable-cds causes
 cdsConfig.hpp compilaition errors
In-Reply-To: <TI0Gk1gKGqC_5dohuKT3Ne1Xy9m7-f5iH5_k6VBXcwU=.7965c0b5-4d91-4126-8158-da2ea0e8c4e7@github.com>
References: <TI0Gk1gKGqC_5dohuKT3Ne1Xy9m7-f5iH5_k6VBXcwU=.7965c0b5-4d91-4126-8158-da2ea0e8c4e7@github.com>
Message-ID: <hcx6nrBiTWhkn7Kgwp9GCoeF-8NAxC-3Z_7OsEg369s=.eee5979c-cbec-44aa-b360-8c8d512f203f@github.com>

On Tue, 16 Sep 2025 19:10:23 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Configuring with --disable-cds results in compilation errors due to CDS code not being encapsulated correctly. Verified with tier 1-5 tests.

Looks good!

-------------

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1591#pullrequestreview-3231949210

From coleenp at openjdk.org  Tue Sep 16 23:03:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Sep 2025 23:03:50 GMT
Subject: [lworld] RFR: 8367691:
 runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java
 crashes with segmentation fault
In-Reply-To: <RNj1Eu9e6oDGKbQ5YYxCoY8C3KXF0DtzycU447B3v4o=.ea38793a-bc4a-4259-8c07-659ac549d723@github.com>
References: <RNj1Eu9e6oDGKbQ5YYxCoY8C3KXF0DtzycU447B3v4o=.ea38793a-bc4a-4259-8c07-659ac549d723@github.com>
Message-ID: <Qh8yFeDLy5yqLfHyfLjUNaHj4_huWPfEICDsF4aQ6k8=.ff3cdf52-3065-4030-9238-6b268ec50e9e@github.com>

On Tue, 16 Sep 2025 09:00:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> A very generous code cache should address the issue where we run out of memory.
> 
> Testing: stress testing this test with 50 iterations.

Looks good!

-------------

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1590#pullrequestreview-3231950433

From vromero at openjdk.org  Wed Sep 17 01:03:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 17 Sep 2025 01:03:51 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that would
 not be allowed in the prologue
Message-ID: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>

This PR introduces a new Xlint category: `initialization`. When enabled it will indicate if some code in an identity class couldn't be placed in the prologue phase. This applies to field initializers and constructors with no explicit `super` invocation. So for example for code like:


class Test {
    int i = 0;

    Test() {
        this.i = 1;
    }
}


a warning will be issued as if there were a super invocation at the end of the constructor, the compiler would issue an error.

PS. The new lint warning had to be disabled during the build as in other case it wouldn't finish

-------------

Commit messages:
 - 8367698: [lworld] New lint category for code that would not be allowed in the prologue

Changes: https://git.openjdk.org/valhalla/pull/1595/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1595&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367698
  Stats: 122 lines in 10 files changed: 113 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/valhalla/pull/1595.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1595/head:pull/1595

PR: https://git.openjdk.org/valhalla/pull/1595

From duke at openjdk.org  Wed Sep 17 07:20:12 2025
From: duke at openjdk.org (duke)
Date: Wed, 17 Sep 2025 07:20:12 GMT
Subject: [lworld] RFR: 8367691:
 runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java
 crashes with segmentation fault
In-Reply-To: <RNj1Eu9e6oDGKbQ5YYxCoY8C3KXF0DtzycU447B3v4o=.ea38793a-bc4a-4259-8c07-659ac549d723@github.com>
References: <RNj1Eu9e6oDGKbQ5YYxCoY8C3KXF0DtzycU447B3v4o=.ea38793a-bc4a-4259-8c07-659ac549d723@github.com>
Message-ID: <VTgDis2-qOBby3T0224cr68vO5BDX5mGPhJk1H9FX70=.7a88babb-7143-40cb-8c32-d8e4e96a81cd@github.com>

On Tue, 16 Sep 2025 09:00:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> A very generous code cache should address the issue where we run out of memory.
> 
> Testing: stress testing this test with 50 iterations.

@Arraying 
Your change (at version 667fa36ed9e15c40f87146230d4290da4bc1c936) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1590#issuecomment-3301629669

From phubner at openjdk.org  Wed Sep 17 12:13:12 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Sep 2025 12:13:12 GMT
Subject: [lworld] Integrated: 8367691:
 runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java
 crashes with segmentation fault
In-Reply-To: <RNj1Eu9e6oDGKbQ5YYxCoY8C3KXF0DtzycU447B3v4o=.ea38793a-bc4a-4259-8c07-659ac549d723@github.com>
References: <RNj1Eu9e6oDGKbQ5YYxCoY8C3KXF0DtzycU447B3v4o=.ea38793a-bc4a-4259-8c07-659ac549d723@github.com>
Message-ID: <KMUq9fGsSfWcm12PG8qaH9sduOxYtz3-1l7xKAmXToc=.405fe29c-1dae-4a00-8e84-d482ebbbbe16@github.com>

On Tue, 16 Sep 2025 09:00:05 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> A very generous code cache should address the issue where we run out of memory.
> 
> Testing: stress testing this test with 50 iterations.

This pull request has now been integrated.

Changeset: b006b053
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b006b053ff402157b080c6a35a0d2a7c237e44c1
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8367691: runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java crashes with segmentation fault

Reviewed-by: coleenp

-------------

PR: https://git.openjdk.org/valhalla/pull/1590

From fparain at openjdk.org  Wed Sep 17 13:12:45 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 17 Sep 2025 13:12:45 GMT
Subject: [lworld] RFR: 8337547: Add LoadableDescriptors to comments for
 class loading
In-Reply-To: <aL_83TJO45WFoxFaSKX70qhpz3lvqTcZtFCzQjQOzJ4=.f161a454-8650-4193-b1de-d4dd1e1561ca@github.com>
References: <aL_83TJO45WFoxFaSKX70qhpz3lvqTcZtFCzQjQOzJ4=.f161a454-8650-4193-b1de-d4dd1e1561ca@github.com>
Message-ID: <Pkf4bHetALO6bIgP6AYkpYkIuSodNJL3nzyseI3DF-Y=.5f38430c-a3dc-4aec-a4fc-443911b4e1f7@github.com>

On Tue, 16 Sep 2025 22:16:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change adds comments for LoadableDescriptors for inline field layout processing to the class loading comments.  The other changes are to make the valhalla version of placeholders and systemDictionary match what is in mainline.  In mainline, interface and super class calls resolve_super_or_fail, otherwise we call resolve_with_circularity_detection.  There are some other comments in mainline in these files that aren't great, that are not addressed here in the Valhalla version.
> Tested with tier1 locally.

src/hotspot/share/classfile/systemDictionary.cpp line 479:

> 477:     MutexLocker mu(THREAD, SystemDictionary_lock);
> 478: 
> 479:     // Must check ClassCircularity before resolving next_name (superclass, interface or LoadableDescriptor class).

Could we say "superclass, interface or field type" in order to cover both the loads triggered by the LoadableDescriptors attribute and the loads triggered by the null-restriction annotation?
It applies to the comment at line 503 too.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1594#discussion_r2355474316

From fparain at openjdk.org  Wed Sep 17 13:41:56 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 17 Sep 2025 13:41:56 GMT
Subject: [lworld] RFR: 8337547: Add LoadableDescriptors to comments for
 class loading
In-Reply-To: <Pkf4bHetALO6bIgP6AYkpYkIuSodNJL3nzyseI3DF-Y=.5f38430c-a3dc-4aec-a4fc-443911b4e1f7@github.com>
References: <aL_83TJO45WFoxFaSKX70qhpz3lvqTcZtFCzQjQOzJ4=.f161a454-8650-4193-b1de-d4dd1e1561ca@github.com>
 <Pkf4bHetALO6bIgP6AYkpYkIuSodNJL3nzyseI3DF-Y=.5f38430c-a3dc-4aec-a4fc-443911b4e1f7@github.com>
Message-ID: <amTztYK9sReoai9m7s7k0YEjIEtSLmMjWE6k3osIOFo=.1a15b7f1-c8ca-4aab-b2ab-0c6855a35903@github.com>

On Wed, 17 Sep 2025 13:09:42 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This change adds comments for LoadableDescriptors for inline field layout processing to the class loading comments.  The other changes are to make the valhalla version of placeholders and systemDictionary match what is in mainline.  In mainline, interface and super class calls resolve_super_or_fail, otherwise we call resolve_with_circularity_detection.  There are some other comments in mainline in these files that aren't great, that are not addressed here in the Valhalla version.
>> Tested with tier1 locally.
>
> src/hotspot/share/classfile/systemDictionary.cpp line 479:
> 
>> 477:     MutexLocker mu(THREAD, SystemDictionary_lock);
>> 478: 
>> 479:     // Must check ClassCircularity before resolving next_name (superclass, interface or LoadableDescriptor class).
> 
> Could we say "superclass, interface or field type" in order to cover both the loads triggered by the LoadableDescriptors attribute and the loads triggered by the null-restriction annotation?
> It applies to the comment at line 503 too.

"field type" is not sufficient either, because the LoadableDescriptors attribute is also used to speculative pre-load argument types.
Any thought on a better name ?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1594#discussion_r2355562467

From mcimadamore at openjdk.org  Wed Sep 17 13:46:18 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 Sep 2025 13:46:18 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue
In-Reply-To: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
References: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
Message-ID: <WclAchOEFu9aYlTkBCglDTAlfP1ODvTh5uNMTjIWNzU=.804ae304-0409-4582-b653-096e683c3588@github.com>

On Wed, 17 Sep 2025 00:57:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This PR introduces a new Xlint category: `initialization`. When enabled it will indicate if some code in an identity class couldn't be placed in the prologue phase. This applies to field initializers and constructors with no explicit `super` invocation. So for example for code like:
> 
> 
> class Test {
>     int i = 0;
> 
>     Test() {
>         this.i = 1;
>     }
> }
> 
> 
> a warning will be issued as if there were a super invocation at the end of the constructor, the compiler would issue an error.
> 
> PS. The new lint warning had to be disabled during the build as in other case it wouldn't finish

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 285:

> 283:          * construction due to a this dependency.
> 284:          */
> 285:         INITIALIZATION("initialization"),

IMHO this should contain the word `strict` somewhere.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1257:

> 1255:                     }
> 1256:                     if (!prologueCode.isEmpty()) {
> 1257:                         CtorPrologueVisitor ctorPrologueVisitor = new CtorPrologueVisitor(localEnv, addedSuperInIdentityClass && allowValueClasses);

I suppose I'd rather not run the visitor if the lint warning is disabled?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1601:

> 1599:                             v.type = chk.checkLocalVarType(tree, tree.init.type, tree.name);
> 1600:                         }
> 1601:                         if (allowValueClasses && v.owner.kind == TYP && !v.isStatic()) {

checking again whether value classes are enabled here seems redundant?

test/langtools/tools/javac/SuperInit/InitializationWarningTest.java line 9:

> 7:  */
> 8: 
> 9: class InitializationWarningTest implements Iterable<Object> {

Since the code base is shared -- perhaps a better testing methodology would be to run _all_ the existing early init negative tests in this new mode, to make sure they generate a warning when there was an error before?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2355572298
PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2355557583
PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2355570464
PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2355577796

From mcimadamore at openjdk.org  Wed Sep 17 13:46:19 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 Sep 2025 13:46:19 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue
In-Reply-To: <WclAchOEFu9aYlTkBCglDTAlfP1ODvTh5uNMTjIWNzU=.804ae304-0409-4582-b653-096e683c3588@github.com>
References: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
 <WclAchOEFu9aYlTkBCglDTAlfP1ODvTh5uNMTjIWNzU=.804ae304-0409-4582-b653-096e683c3588@github.com>
Message-ID: <NVS0KFAQVIpx9wpF4Fi8uMScWNvUOQBRFLZEw73u3jI=.a1a24f53-2e8f-4dde-a80c-2c787f88d913@github.com>

On Wed, 17 Sep 2025 13:37:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR introduces a new Xlint category: `initialization`. When enabled it will indicate if some code in an identity class couldn't be placed in the prologue phase. This applies to field initializers and constructors with no explicit `super` invocation. So for example for code like:
>> 
>> 
>> class Test {
>>     int i = 0;
>> 
>>     Test() {
>>         this.i = 1;
>>     }
>> }
>> 
>> 
>> a warning will be issued as if there were a super invocation at the end of the constructor, the compiler would issue an error.
>> 
>> PS. The new lint warning had to be disabled during the build as in other case it wouldn't finish
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1257:
> 
>> 1255:                     }
>> 1256:                     if (!prologueCode.isEmpty()) {
>> 1257:                         CtorPrologueVisitor ctorPrologueVisitor = new CtorPrologueVisitor(localEnv, addedSuperInIdentityClass && allowValueClasses);
> 
> I suppose I'd rather not run the visitor if the lint warning is disabled?

Although, it might be tricky to see whether the warning is enabled or not here. The new design is to issue all warnings all the time, on the basis that typically it's too early to filter here, (but, you don't yet have the latest javac changes here)

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2355561116

From mcimadamore at openjdk.org  Wed Sep 17 13:46:20 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 Sep 2025 13:46:20 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue
In-Reply-To: <NVS0KFAQVIpx9wpF4Fi8uMScWNvUOQBRFLZEw73u3jI=.a1a24f53-2e8f-4dde-a80c-2c787f88d913@github.com>
References: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
 <WclAchOEFu9aYlTkBCglDTAlfP1ODvTh5uNMTjIWNzU=.804ae304-0409-4582-b653-096e683c3588@github.com>
 <NVS0KFAQVIpx9wpF4Fi8uMScWNvUOQBRFLZEw73u3jI=.a1a24f53-2e8f-4dde-a80c-2c787f88d913@github.com>
Message-ID: <qHMWoXrAj_IhWxYQThFfsb-aZkXGVCNlyq23JgHWfm8=.6a2b0291-3328-4c67-9895-4136bcacdb34@github.com>

On Wed, 17 Sep 2025 13:38:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1257:
>> 
>>> 1255:                     }
>>> 1256:                     if (!prologueCode.isEmpty()) {
>>> 1257:                         CtorPrologueVisitor ctorPrologueVisitor = new CtorPrologueVisitor(localEnv, addedSuperInIdentityClass && allowValueClasses);
>> 
>> I suppose I'd rather not run the visitor if the lint warning is disabled?
>
> Although, it might be tricky to see whether the warning is enabled or not here. The new design is to issue all warnings all the time, on the basis that typically it's too early to filter here, (but, you don't yet have the latest javac changes here)

At the very least, we can just not do the scan if `addedSuperInIdentityClass` but `!allowValueClass` -- so that w/o Valhalla enable, there's no weird regression.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2355568690

From mcimadamore at openjdk.org  Wed Sep 17 13:54:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 Sep 2025 13:54:00 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue
In-Reply-To: <qHMWoXrAj_IhWxYQThFfsb-aZkXGVCNlyq23JgHWfm8=.6a2b0291-3328-4c67-9895-4136bcacdb34@github.com>
References: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
 <WclAchOEFu9aYlTkBCglDTAlfP1ODvTh5uNMTjIWNzU=.804ae304-0409-4582-b653-096e683c3588@github.com>
 <NVS0KFAQVIpx9wpF4Fi8uMScWNvUOQBRFLZEw73u3jI=.a1a24f53-2e8f-4dde-a80c-2c787f88d913@github.com>
 <qHMWoXrAj_IhWxYQThFfsb-aZkXGVCNlyq23JgHWfm8=.6a2b0291-3328-4c67-9895-4136bcacdb34@github.com>
Message-ID: <Y4F0X93AlywEQNj3ymEQs16mIwrYA_zC0VY_qU8Gtk8=.8939141f-2951-437a-ba64-1372b07a8022@github.com>

On Wed, 17 Sep 2025 13:40:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Although, it might be tricky to see whether the warning is enabled or not here. The new design is to issue all warnings all the time, on the basis that typically it's too early to filter here, (but, you don't yet have the latest javac changes here)
>
> At the very least, we can just not do the scan if `addedSuperInIdentityClass` but `!allowValueClass` -- so that w/o Valhalla enable, there's no weird regression.

scratch that -- you need the check always. I just don't get the `allowValueClass` filter here, but I guess we want to make the warnings conditional on --enable-preview, which is ok

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2355602582

From vromero at openjdk.org  Wed Sep 17 15:52:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 17 Sep 2025 15:52:06 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue
In-Reply-To: <WclAchOEFu9aYlTkBCglDTAlfP1ODvTh5uNMTjIWNzU=.804ae304-0409-4582-b653-096e683c3588@github.com>
References: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
 <WclAchOEFu9aYlTkBCglDTAlfP1ODvTh5uNMTjIWNzU=.804ae304-0409-4582-b653-096e683c3588@github.com>
Message-ID: <Y67tW9nqQyMOKLry7DTG7C0vphleBbOp9KLbeOcusGY=.f4be558e-f958-41f7-9799-66ef7af17399@github.com>

On Wed, 17 Sep 2025 13:41:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR introduces a new Xlint category: `initialization`. When enabled it will indicate if some code in an identity class couldn't be placed in the prologue phase. This applies to field initializers and constructors with no explicit `super` invocation. So for example for code like:
>> 
>> 
>> class Test {
>>     int i = 0;
>> 
>>     Test() {
>>         this.i = 1;
>>     }
>> }
>> 
>> 
>> a warning will be issued as if there were a super invocation at the end of the constructor, the compiler would issue an error.
>> 
>> PS. The new lint warning had to be disabled during the build as in other case it wouldn't finish
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1601:
> 
>> 1599:                             v.type = chk.checkLocalVarType(tree, tree.init.type, tree.name);
>> 1600:                         }
>> 1601:                         if (allowValueClasses && v.owner.kind == TYP && !v.isStatic()) {
> 
> checking again whether value classes are enabled here seems redundant?

not sure, we don't want to issue the warning if preview mode is not enabled, we can probably check explicitly for preview

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2355984391

From vromero at openjdk.org  Wed Sep 17 16:03:37 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 17 Sep 2025 16:03:37 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue
In-Reply-To: <WclAchOEFu9aYlTkBCglDTAlfP1ODvTh5uNMTjIWNzU=.804ae304-0409-4582-b653-096e683c3588@github.com>
References: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
 <WclAchOEFu9aYlTkBCglDTAlfP1ODvTh5uNMTjIWNzU=.804ae304-0409-4582-b653-096e683c3588@github.com>
Message-ID: <oDN5gCt6eWXvcAceVbxvVcp88tuu8TkRyByEve1vg7g=.9bc7c661-d07d-4eb7-9be8-d164748131dd@github.com>

On Wed, 17 Sep 2025 13:43:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR introduces a new Xlint category: `initialization`. When enabled it will indicate if some code in an identity class couldn't be placed in the prologue phase. This applies to field initializers and constructors with no explicit `super` invocation. So for example for code like:
>> 
>> 
>> class Test {
>>     int i = 0;
>> 
>>     Test() {
>>         this.i = 1;
>>     }
>> }
>> 
>> 
>> a warning will be issued as if there were a super invocation at the end of the constructor, the compiler would issue an error.
>> 
>> PS. The new lint warning had to be disabled during the build as in other case it wouldn't finish
>
> test/langtools/tools/javac/SuperInit/InitializationWarningTest.java line 9:
> 
>> 7:  */
>> 8: 
>> 9: class InitializationWarningTest implements Iterable<Object> {
> 
> Since the code base is shared -- perhaps a better testing methodology would be to run _all_ the existing early init negative tests in this new mode, to make sure they generate a warning when there was an error before?

the problem with reusing existing tests is that most of them have a explicit `super` invocation, but we are interested in constructor bodies without a explicit super invocation, gonna think if there is a way out here

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2356015636

From rriggs at openjdk.org  Wed Sep 17 16:37:41 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 Sep 2025 16:37:41 GMT
Subject: [lworld] RFR: 8367792: [lworld] Remove the Unsafe remnants of old
 valhalla prototypes
In-Reply-To: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
References: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
Message-ID: <FjzfXKehB5LsxEe9eE-2qnSuzWpqTK_MRUHmBwGXpfc=.e51c53cc-80d7-494d-9f31-4cc02c119bf7@github.com>

On Tue, 16 Sep 2025 22:08:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> There are some remnants from previous iterations of value objects in Unsafe. We should aim to remove them for cleaner code in the future.

MakePrivateBuffer is still being used in some prototypes of vector support and should not be removed.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1593#issuecomment-3303772753

From liach at openjdk.org  Wed Sep 17 16:55:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 Sep 2025 16:55:11 GMT
Subject: [lworld] RFR: 8367792: [lworld] Remove the Unsafe remnants of old
 valhalla prototypes
In-Reply-To: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
References: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
Message-ID: <vnLmnwhpHnh7Wfmmo2TD4qJhDa4dnib4HIXhic3Fsyk=.d4be4aba-4914-4a73-8d21-429ae4e680ae@github.com>

On Tue, 16 Sep 2025 22:08:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> There are some remnants from previous iterations of value objects in Unsafe. We should aim to remove them for cleaner code in the future.

The vector support prototype was last updated 5 months ago. makePrivateBuffer introduces significant complexity into core library code and JVM. Besides this complexity, the vector prototype also introduces "multifield", which is also uncertain.

I will reach out to Paul Sandoz and Jatin Bhateja to check on the status of this prototype - it hasn't been updated since the new lworld model, maybe our mainline hacks can continue to work after the vector classes are marked value.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1593#issuecomment-3303831273

From fparain at openjdk.org  Wed Sep 17 19:40:27 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 17 Sep 2025 19:40:27 GMT
Subject: [lworld] RFR: 8367912: Add unit test for LoadableDescriptors attribute
 with invalid entries
Message-ID: <9joLHrPIft6XoQDkr_L2rA-MF1E4B8Ft3EDUoyaV-GY=.915683d5-a200-4a80-862e-2f75d59a66ed@github.com>

New unit test to verify the behavior of the JVM when a LoadableDescriptors attribute contains an invalid descriptor.

-------------

Commit messages:
 - Add new unit test for LoadableDesciptors attribute with invalid entries

Changes: https://git.openjdk.org/valhalla/pull/1598/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1598&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367912
  Stats: 258 lines in 2 files changed: 258 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1598.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1598/head:pull/1598

PR: https://git.openjdk.org/valhalla/pull/1598

From matsaave at openjdk.org  Wed Sep 17 20:01:37 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 17 Sep 2025 20:01:37 GMT
Subject: [lworld] RFR: 8353303: Configuring with --disable-cds causes
 cdsConfig.hpp compilation errors
In-Reply-To: <hcx6nrBiTWhkn7Kgwp9GCoeF-8NAxC-3Z_7OsEg369s=.eee5979c-cbec-44aa-b360-8c8d512f203f@github.com>
References: <TI0Gk1gKGqC_5dohuKT3Ne1Xy9m7-f5iH5_k6VBXcwU=.7965c0b5-4d91-4126-8158-da2ea0e8c4e7@github.com>
 <hcx6nrBiTWhkn7Kgwp9GCoeF-8NAxC-3Z_7OsEg369s=.eee5979c-cbec-44aa-b360-8c8d512f203f@github.com>
Message-ID: <-ZWg2XzIfdvS7rV4SXrMiIWciDIxtYOXsVv321IOh9k=.3df1d753-7de6-4c7e-a90d-b41c2b114ff2@github.com>

On Tue, 16 Sep 2025 22:59:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Configuring with --disable-cds results in compilation errors due to CDS code not being encapsulated correctly. Verified with tier 1-5 tests.
>
> Looks good!

Thanks for the review @coleenp

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1591#issuecomment-3304383841

From matsaave at openjdk.org  Wed Sep 17 20:01:38 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 17 Sep 2025 20:01:38 GMT
Subject: [lworld] Integrated: 8353303: Configuring with --disable-cds causes
 cdsConfig.hpp compilation errors
In-Reply-To: <TI0Gk1gKGqC_5dohuKT3Ne1Xy9m7-f5iH5_k6VBXcwU=.7965c0b5-4d91-4126-8158-da2ea0e8c4e7@github.com>
References: <TI0Gk1gKGqC_5dohuKT3Ne1Xy9m7-f5iH5_k6VBXcwU=.7965c0b5-4d91-4126-8158-da2ea0e8c4e7@github.com>
Message-ID: <obvdrIrnX6y7TKWNPMKoxQtmAC4m41L9gVqNLa5YxZw=.4b4fdebf-aa13-48f7-bec5-3ba4ab5d758c@github.com>

On Tue, 16 Sep 2025 19:10:23 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Configuring with --disable-cds results in compilation errors due to CDS code not being encapsulated correctly. Verified with tier 1-5 tests.

This pull request has now been integrated.

Changeset: 7afbf295
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7afbf295143dae458213513c30fb52245d75d7b4
Stats:     5 lines in 2 files changed: 5 ins; 0 del; 0 mod

8353303: Configuring with --disable-cds causes cdsConfig.hpp compilation errors

Reviewed-by: coleenp

-------------

PR: https://git.openjdk.org/valhalla/pull/1591

From coleenp at openjdk.org  Wed Sep 17 20:26:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 17 Sep 2025 20:26:38 GMT
Subject: [lworld] RFR: 8337547: Add LoadableDescriptors to comments for
 class loading
In-Reply-To: <amTztYK9sReoai9m7s7k0YEjIEtSLmMjWE6k3osIOFo=.1a15b7f1-c8ca-4aab-b2ab-0c6855a35903@github.com>
References: <aL_83TJO45WFoxFaSKX70qhpz3lvqTcZtFCzQjQOzJ4=.f161a454-8650-4193-b1de-d4dd1e1561ca@github.com>
 <Pkf4bHetALO6bIgP6AYkpYkIuSodNJL3nzyseI3DF-Y=.5f38430c-a3dc-4aec-a4fc-443911b4e1f7@github.com>
 <amTztYK9sReoai9m7s7k0YEjIEtSLmMjWE6k3osIOFo=.1a15b7f1-c8ca-4aab-b2ab-0c6855a35903@github.com>
Message-ID: <BbuF6YZAnCsxQALxhTF6okRJtbHMTSenCd51uZrs9pw=.403348f4-dfba-47f2-86f3-50f2c49c64b0@github.com>

On Wed, 17 Sep 2025 13:38:41 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/classfile/systemDictionary.cpp line 479:
>> 
>>> 477:     MutexLocker mu(THREAD, SystemDictionary_lock);
>>> 478: 
>>> 479:     // Must check ClassCircularity before resolving next_name (superclass, interface or LoadableDescriptor class).
>> 
>> Could we say "superclass, interface or field type" in order to cover both the loads triggered by the LoadableDescriptors attribute and the loads triggered by the null-restriction annotation?
>> It applies to the comment at line 503 too.
>
> "field type" is not sufficient either, because the LoadableDescriptors attribute is also used to speculative pre-load argument types.
> Any thought on a better name ?

Thank you - I very much want this comment to be accurate.
Maybe we don't need to say "LoadableDescriptors" here since that's the mechanism.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1594#discussion_r2356682035

From coleenp at openjdk.org  Wed Sep 17 20:26:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 17 Sep 2025 20:26:39 GMT
Subject: [lworld] RFR: 8337547: Add LoadableDescriptors to comments for
 class loading
In-Reply-To: <BbuF6YZAnCsxQALxhTF6okRJtbHMTSenCd51uZrs9pw=.403348f4-dfba-47f2-86f3-50f2c49c64b0@github.com>
References: <aL_83TJO45WFoxFaSKX70qhpz3lvqTcZtFCzQjQOzJ4=.f161a454-8650-4193-b1de-d4dd1e1561ca@github.com>
 <Pkf4bHetALO6bIgP6AYkpYkIuSodNJL3nzyseI3DF-Y=.5f38430c-a3dc-4aec-a4fc-443911b4e1f7@github.com>
 <amTztYK9sReoai9m7s7k0YEjIEtSLmMjWE6k3osIOFo=.1a15b7f1-c8ca-4aab-b2ab-0c6855a35903@github.com>
 <BbuF6YZAnCsxQALxhTF6okRJtbHMTSenCd51uZrs9pw=.403348f4-dfba-47f2-86f3-50f2c49c64b0@github.com>
Message-ID: <qmq6FD5igJg8QmxGU9Vo1oQkP90XEZY6-RQAvDmLmKU=.d14f7584-67c1-40f6-9db8-3f921eec33de@github.com>

On Wed, 17 Sep 2025 20:21:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> "field type" is not sufficient either, because the LoadableDescriptors attribute is also used to speculative pre-load argument types.
>> Any thought on a better name ?
>
> Thank you - I very much want this comment to be accurate.
> Maybe we don't need to say "LoadableDescriptors" here since that's the mechanism.

Suggestion:

    // Must check ClassCircularity before resolving next_name (superclass, interface, field types or speculatively preloaded argument types).

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1594#discussion_r2356685594

From coleenp at openjdk.org  Wed Sep 17 20:26:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 17 Sep 2025 20:26:40 GMT
Subject: [lworld] RFR: 8337547: Add LoadableDescriptors to comments for
 class loading
In-Reply-To: <aL_83TJO45WFoxFaSKX70qhpz3lvqTcZtFCzQjQOzJ4=.f161a454-8650-4193-b1de-d4dd1e1561ca@github.com>
References: <aL_83TJO45WFoxFaSKX70qhpz3lvqTcZtFCzQjQOzJ4=.f161a454-8650-4193-b1de-d4dd1e1561ca@github.com>
Message-ID: <KMlYb1hXnINYVjBNy_9h3aPGrGPRbZq0yMt0qCUdyaI=.49e37e87-ca09-4c71-bfd3-848a33430785@github.com>

On Tue, 16 Sep 2025 22:16:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change adds comments for LoadableDescriptors for inline field layout processing to the class loading comments.  The other changes are to make the valhalla version of placeholders and systemDictionary match what is in mainline.  In mainline, interface and super class calls resolve_super_or_fail, otherwise we call resolve_with_circularity_detection.  There are some other comments in mainline in these files that aren't great, that are not addressed here in the Valhalla version.
> Tested with tier1 locally.

src/hotspot/share/classfile/systemDictionary.cpp line 503:

> 501:   }
> 502: 
> 503:   // Resolve the superclass, superinterface or specified LoadableDescriptor class, and check results on return.

Suggestion:

  // Resolve the superclass, superinterface, field type or speculatively preloaded argument types and check results on return.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1594#discussion_r2356684185