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

From fparain at openjdk.org  Thu Sep 18 19:21:09 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 18 Sep 2025 19:21:09 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: <ZkHQh6Te6jJtaEOR4VQ9874q01ozXISDnTw4U9_s_3A=.38ef4200-fe38-4656-8c7f-bf39d8731d40@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.

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1594#pullrequestreview-3241610880

From coleenp at openjdk.org  Thu Sep 18 19:21:17 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Sep 2025 19:21:17 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: <vOWJmcVe3qutvUaTeHKtPnU7oG44Gyso8AjE6ZviLts=.1365e7a4-3340-4fef-b1df-e899dfad0280@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.

Thanks, Fred.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1594#issuecomment-3309222179

From fparain at openjdk.org  Thu Sep 18 19:21:31 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 18 Sep 2025 19:21:31 GMT
Subject: [lworld] RFR: 8337547: Add LoadableDescriptors to comments for
 class loading
In-Reply-To: <qmq6FD5igJg8QmxGU9Vo1oQkP90XEZY6-RQAvDmLmKU=.d14f7584-67c1-40f6-9db8-3f921eec33de@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>
 <qmq6FD5igJg8QmxGU9Vo1oQkP90XEZY6-RQAvDmLmKU=.d14f7584-67c1-40f6-9db8-3f921eec33de@github.com>
Message-ID: <fYdbbQHCNWfe96PIgsHJBOkRzEVTwb7a3iI4wW1bw8g=.490e9e90-ebb6-4d68-b0c2-04c9d02769ce@github.com>

On Wed, 17 Sep 2025 20:22:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> 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).

Sounds accurate to me, thank you for the update.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1594#discussion_r2360798965

From coleenp at openjdk.org  Thu Sep 18 19:26:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Sep 2025 19:26:56 GMT
Subject: [lworld] RFR: 8337547: Add LoadableDescriptors to comments for
 class loading [v2]
In-Reply-To: <aL_83TJO45WFoxFaSKX70qhpz3lvqTcZtFCzQjQOzJ4=.f161a454-8650-4193-b1de-d4dd1e1561ca@github.com>
References: <aL_83TJO45WFoxFaSKX70qhpz3lvqTcZtFCzQjQOzJ4=.f161a454-8650-4193-b1de-d4dd1e1561ca@github.com>
Message-ID: <YVF73NEUZhJ1aYoNoBFAhqIIpggi24j4vA1gJ1Vba78=.c2d15fed-76b2-4099-887e-8c45a7b76a0b@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.

Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/hotspot/share/classfile/systemDictionary.cpp
 - Update src/hotspot/share/classfile/systemDictionary.cpp

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1594/files
  - new: https://git.openjdk.org/valhalla/pull/1594/files/9a8f7365..39e996c4

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 coleenp at openjdk.org  Thu Sep 18 19:57:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Sep 2025 19:57:04 GMT
Subject: [lworld] Integrated: 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: <h13ydNs5LC06D0LQcltcFdxFBzUt8eVW8nZ4AhxH3OU=.123f3645-3fdf-4444-870c-12b10579118d@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.

This pull request has now been integrated.

Changeset: 9f60a53e
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9f60a53eebe5e1ee6317339c88df05dda1e2ff8b
Stats:     26 lines in 5 files changed: 3 ins; 3 del; 20 mod

8337547: Add LoadableDescriptors to comments for class loading

Reviewed-by: fparain

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

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

From fparain at openjdk.org  Thu Sep 18 20:56:25 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 18 Sep 2025 20:56:25 GMT
Subject: [lworld] RFR: 8368020: Remove preloading of null-restricted static
 fields classes
Message-ID: <701WoJnT2BwYLvTSe3DGQtx8picPQDILIj82CvK9BpI=.97ef0e92-a4e8-4c7d-a762-7d1b1f3c44e0@github.com>

Remove preloading of of null-restricted static fields classes. This code was needed when such fields were initialized with default values. In the current model, null-restricted fields are always strict and are initialized accordingly to the strict fields model.

Tested on Mach5, tiers 1 to 3.

Fred

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

Commit messages:
 - Remove preload of null-restricted static fields types

Changes: https://git.openjdk.org/valhalla/pull/1599/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1599&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368020
  Stats: 289 lines in 2 files changed: 38 ins; 247 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/1599.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1599/head:pull/1599

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

From duke at openjdk.org  Thu Sep 18 23:02:19 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 18 Sep 2025 23:02:19 GMT
Subject: [lworld] RFR: 8368031: Apply mainline changes to support preview mode
 work into Valhalla
Message-ID: <TT7PUcAmZ8OSU8CL4h1NDJar7Q9Bm-nBUsXvGq2MonU=.0b9e667c-b978-4418-84ef-0a8c172a9b84@github.com>

This change rolls up four necessary (and hopefully sufficient) mainline changes needed in Valhalla for the preview mode work.

These were applied bottom-to-top in a Valhalla repo by applying patches created from a recent mainline JDK repo, using "git show" and "git apply".

Note that I needed to use "--theirs" to resolve a small set of mismatches due to other non-exact patching which has already occurred for these classes. I see no intermediate changes in any classes by anyone else, no sign of overwriting other changes, and internal testing is passing. I would have preferred if everything applied 100% clean, but things like copyright years were fixed in one version and not in the other.

[Apply patch from mainline hash: 3fae6013c6]
8365532: java/lang/module/ModuleReader/ModuleReaderTest.testImage fails

[Apply patch from mainline hash: 0b05b7cc92]
8365436: ImageReaderTest fails when jmods directory not present

[Apply patch from mainline hash: 06ce9e89ab]
8365467: Issues with jrtfs implementation for exploded run-time images

[Apply patch from mainline hash: 166210719e]
8367005: ImageReader refactor caused performance regressions for startup and footprint

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

Commit messages:
 - Apply patch from mainline hash: 166210719e
 - Apply patch from mainline hash: 06ce9e89ab
 - Apply patch from mainline hash: 0b05b7cc92
 - Apply patch from mainline hash: 3fae6013c6

Changes: https://git.openjdk.org/valhalla/pull/1600/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1600&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368031
  Stats: 568 lines in 9 files changed: 456 ins; 44 del; 68 mod
  Patch: https://git.openjdk.org/valhalla/pull/1600.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1600/head:pull/1600

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

From liach at openjdk.org  Thu Sep 18 23:51:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Sep 2025 23:51:49 GMT
Subject: [lworld] RFR: 8368031: Apply mainline changes to support preview
 mode work into Valhalla
In-Reply-To: <TT7PUcAmZ8OSU8CL4h1NDJar7Q9Bm-nBUsXvGq2MonU=.0b9e667c-b978-4418-84ef-0a8c172a9b84@github.com>
References: <TT7PUcAmZ8OSU8CL4h1NDJar7Q9Bm-nBUsXvGq2MonU=.0b9e667c-b978-4418-84ef-0a8c172a9b84@github.com>
Message-ID: <5V4Tgdb_nteMG38Ap1xPxpa1EXOQWHVMD_ltO-JHvko=.81937d81-1bf6-438b-aa8a-9ff9bc4ed1e3@github.com>

On Thu, 18 Sep 2025 22:56:36 GMT, David Beaumont <duke at openjdk.org> wrote:

> This change rolls up four necessary (and hopefully sufficient) mainline changes needed in Valhalla for the preview mode work.
> 
> These were applied bottom-to-top in a Valhalla repo by applying patches created from a recent mainline JDK repo, using "git show" and "git apply".
> 
> Note that I needed to use "--theirs" to resolve a small set of mismatches due to other non-exact patching which has already occurred for these classes. I see no intermediate changes in any classes by anyone else, no sign of overwriting other changes, and internal testing is passing. I would have preferred if everything applied 100% clean, but things like copyright years were fixed in one version and not in the other.
> 
> [Apply patch from mainline hash: 3fae6013c6]
> 8365532: java/lang/module/ModuleReader/ModuleReaderTest.testImage fails
> 
> [Apply patch from mainline hash: 0b05b7cc92]
> 8365436: ImageReaderTest fails when jmods directory not present
> 
> [Apply patch from mainline hash: 06ce9e89ab]
> 8365467: Issues with jrtfs implementation for exploded run-time images
> 
> [Apply patch from mainline hash: 166210719e]
> 8367005: ImageReader refactor caused performance regressions for startup and footprint

Looks like what we had in mainline.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1600#pullrequestreview-3242362477

From dsimms at openjdk.org  Fri Sep 19 06:40:41 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 19 Sep 2025 06:40:41 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <S7qWzhl5uVNs6t79XC3A0DgLpV24KFXJAOKaS9Zjbew=.b2605b11-fc52-413d-884d-21d44ff32e3d@github.com>

Merge jdk-26+6

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

Commit messages:
 - Merge branch 'lworld' into lworld_merge_jdk_26_6
 - Merge branch 'lworld' into lworld_merge_jdk_26_6
 - Merge tag 'jdk-26+6' into lworld_merge_jdk_26_6
 - 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value
 - 8361754: New test runtime/jni/checked/TestCharArrayReleasing.java can cause disk full errors
 - 8361447: [REDO] Checked version of JNI Release<type>ArrayElements needs to filter out known wrapped arrays
 - 8361647: Report the error reason on failed semaphore calls on macOS
 - 8344073: Test runtime/cds/appcds/TestParallelGCWithCDS.java#id0 failed
 - 8360122: Fix java.sql\Connection.java indentation
 - 8361615: CodeBuilder::parameterSlot throws undocumented IOOBE
 - ... and 80 more: https://git.openjdk.org/valhalla/compare/9f60a53e...f74e2399

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

Changes: https://git.openjdk.org/valhalla/pull/1601/files
  Stats: 12770 lines in 458 files changed: 7250 ins; 2062 del; 3458 mod
  Patch: https://git.openjdk.org/valhalla/pull/1601.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1601/head:pull/1601

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

From dsimms at openjdk.org  Fri Sep 19 08:13:29 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 19 Sep 2025 08:13:29 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <S7qWzhl5uVNs6t79XC3A0DgLpV24KFXJAOKaS9Zjbew=.b2605b11-fc52-413d-884d-21d44ff32e3d@github.com>
References: <S7qWzhl5uVNs6t79XC3A0DgLpV24KFXJAOKaS9Zjbew=.b2605b11-fc52-413d-884d-21d44ff32e3d@github.com>
Message-ID: <ZjjN5WSGPDu_A8ZPACmA_FZz9TtEOAQcZtks1YCHMoQ=.dd2a4ca5-ef59-4e90-893f-fb4f99d5f85f@github.com>

> Merge jdk-26+6

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  Compilation failed, logical merge error

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1601/files
  - new: https://git.openjdk.org/valhalla/pull/1601/files/f74e2399..cdc55989

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

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

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

From dsimms at openjdk.org  Fri Sep 19 08:45:39 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 19 Sep 2025 08:45:39 GMT
Subject: [lworld] RFR: Merge jdk [v3]
In-Reply-To: <S7qWzhl5uVNs6t79XC3A0DgLpV24KFXJAOKaS9Zjbew=.b2605b11-fc52-413d-884d-21d44ff32e3d@github.com>
References: <S7qWzhl5uVNs6t79XC3A0DgLpV24KFXJAOKaS9Zjbew=.b2605b11-fc52-413d-884d-21d44ff32e3d@github.com>
Message-ID: <uEBSnEtFRo6G1BuBaqnKQQgVCOd2F00Mrsv-c4u3Vvs=.1a370592-a632-4e34-96c8-8cf1db3f29f9@github.com>

> Merge jdk-26+6

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  Adjust testing

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1601/files
  - new: https://git.openjdk.org/valhalla/pull/1601/files/cdc55989..b915b9a2

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

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

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

From dsimms at openjdk.org  Fri Sep 19 08:48:17 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 19 Sep 2025 08:48:17 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <S7qWzhl5uVNs6t79XC3A0DgLpV24KFXJAOKaS9Zjbew=.b2605b11-fc52-413d-884d-21d44ff32e3d@github.com>
References: <S7qWzhl5uVNs6t79XC3A0DgLpV24KFXJAOKaS9Zjbew=.b2605b11-fc52-413d-884d-21d44ff32e3d@github.com>
Message-ID: <ObIH6zXYIq6IOla-R8DaUECC1g4rk4WmHMDFuavjTaY=.55a333df-3a8d-41c7-a5e4-12b8c02ebf18@github.com>

On Fri, 19 Sep 2025 06:33:56 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+6

This pull request has now been integrated.

Changeset: ec61d0a9
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ec61d0a9485d5dfa9cf66a4709ab06f22cb154f5
Stats:     12775 lines in 460 files changed: 7254 ins; 2062 del; 3459 mod

Merge jdk

Merge jdk-26+6

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

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

From coleenp at openjdk.org  Fri Sep 19 11:49:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 Sep 2025 11:49:37 GMT
Subject: [lworld] RFR: 8368020: Remove preloading of null-restricted static
 fields classes
In-Reply-To: <701WoJnT2BwYLvTSe3DGQtx8picPQDILIj82CvK9BpI=.97ef0e92-a4e8-4c7d-a762-7d1b1f3c44e0@github.com>
References: <701WoJnT2BwYLvTSe3DGQtx8picPQDILIj82CvK9BpI=.97ef0e92-a4e8-4c7d-a762-7d1b1f3c44e0@github.com>
Message-ID: <X7fzO7OcAx7KPYfoTg7V2pWJnCrIVSCcR8lcWgmGtCM=.c81479c4-ae38-4f53-bc71-22544d492591@github.com>

On Thu, 18 Sep 2025 20:50:25 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Remove preloading of of null-restricted static fields classes. This code was needed when such fields were initialized with default values. In the current model, null-restricted fields are always strict and are initialized accordingly to the strict fields model.
> 
> Tested on Mach5, tiers 1 to 3.
> 
> Fred

Thank you! This looks really nice.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1599#pullrequestreview-3244502238

From fparain at openjdk.org  Fri Sep 19 13:23:27 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 19 Sep 2025 13:23:27 GMT
Subject: [lworld] RFR: 8368020: Remove preloading of null-restricted static
 fields classes
In-Reply-To: <701WoJnT2BwYLvTSe3DGQtx8picPQDILIj82CvK9BpI=.97ef0e92-a4e8-4c7d-a762-7d1b1f3c44e0@github.com>
References: <701WoJnT2BwYLvTSe3DGQtx8picPQDILIj82CvK9BpI=.97ef0e92-a4e8-4c7d-a762-7d1b1f3c44e0@github.com>
Message-ID: <ixTEvrm0xVZP5Ar5xR78M3Zfn6w5xb63ejzmSiZq0nQ=.8ec11994-9630-4f0c-b2b9-888f2f15f537@github.com>

On Thu, 18 Sep 2025 20:50:25 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Remove preloading of of null-restricted static fields classes. This code was needed when such fields were initialized with default values. In the current model, null-restricted fields are always strict and are initialized accordingly to the strict fields model.
> 
> Tested on Mach5, tiers 1 to 3.
> 
> Fred

Thanks Coleen for the review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1599#issuecomment-3312177725

From fparain at openjdk.org  Fri Sep 19 13:23:28 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 19 Sep 2025 13:23:28 GMT
Subject: [lworld] Integrated: 8368020: Remove preloading of null-restricted
 static fields classes
In-Reply-To: <701WoJnT2BwYLvTSe3DGQtx8picPQDILIj82CvK9BpI=.97ef0e92-a4e8-4c7d-a762-7d1b1f3c44e0@github.com>
References: <701WoJnT2BwYLvTSe3DGQtx8picPQDILIj82CvK9BpI=.97ef0e92-a4e8-4c7d-a762-7d1b1f3c44e0@github.com>
Message-ID: <0B8OGtgl822B_rb_F5CVLMwfQaS6j8g26_TbWIUKsm0=.26fe6dc7-c9ec-4c1d-82e3-9c01e00673e5@github.com>

On Thu, 18 Sep 2025 20:50:25 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Remove preloading of of null-restricted static fields classes. This code was needed when such fields were initialized with default values. In the current model, null-restricted fields are always strict and are initialized accordingly to the strict fields model.
> 
> Tested on Mach5, tiers 1 to 3.
> 
> Fred

This pull request has now been integrated.

Changeset: 443cdd5a
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/443cdd5a5ee4a85fb7e361279722fafbcbc73c46
Stats:     289 lines in 2 files changed: 38 ins; 247 del; 4 mod

8368020: Remove preloading of null-restricted static fields classes

Reviewed-by: coleenp

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

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

From fparain at openjdk.org  Fri Sep 19 13:27:10 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 19 Sep 2025 13:27:10 GMT
Subject: [lworld] Integrated: 8367912: Add unit test for LoadableDescriptors
 attribute with invalid entries
In-Reply-To: <9joLHrPIft6XoQDkr_L2rA-MF1E4B8Ft3EDUoyaV-GY=.915683d5-a200-4a80-862e-2f75d59a66ed@github.com>
References: <9joLHrPIft6XoQDkr_L2rA-MF1E4B8Ft3EDUoyaV-GY=.915683d5-a200-4a80-862e-2f75d59a66ed@github.com>
Message-ID: <4S2XdKYA7ClqwOxcbqMjEPSDdAmdn-9qCL-Gs0Urh-0=.54226a2e-33a4-4044-9faa-48d630d44161@github.com>

On Wed, 17 Sep 2025 19:33:52 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> New unit test to verify the behavior of the JVM when a LoadableDescriptors attribute contains an invalid descriptor.

This pull request has now been integrated.

Changeset: 05d82ab7
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/05d82ab73ca641f4778ce4c91ac562e9ae01eb68
Stats:     258 lines in 2 files changed: 258 ins; 0 del; 0 mod

8367912: Add unit test for LoadableDescriptors attribute with invalid entries

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

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

From rriggs at openjdk.org  Fri Sep 19 14:27:15 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 Sep 2025 14:27:15 GMT
Subject: [lworld] RFR: 8368031: Apply mainline changes to support preview
 mode work into Valhalla
In-Reply-To: <TT7PUcAmZ8OSU8CL4h1NDJar7Q9Bm-nBUsXvGq2MonU=.0b9e667c-b978-4418-84ef-0a8c172a9b84@github.com>
References: <TT7PUcAmZ8OSU8CL4h1NDJar7Q9Bm-nBUsXvGq2MonU=.0b9e667c-b978-4418-84ef-0a8c172a9b84@github.com>
Message-ID: <cXz7vptRA2wDWUCkDn8FMTWp8deMiEMd2OkN5a72cpo=.69b2f3d2-567d-4954-b1eb-ad3294b5def2@github.com>

On Thu, 18 Sep 2025 22:56:36 GMT, David Beaumont <duke at openjdk.org> wrote:

> This change rolls up four necessary (and hopefully sufficient) mainline changes needed in Valhalla for the preview mode work.
> 
> These were applied bottom-to-top in a Valhalla repo by applying patches created from a recent mainline JDK repo, using "git show" and "git apply".
> 
> Note that I needed to use "--theirs" to resolve a small set of mismatches due to other non-exact patching which has already occurred for these classes. I see no intermediate changes in any classes by anyone else, no sign of overwriting other changes, and internal testing is passing. I would have preferred if everything applied 100% clean, but things like copyright years were fixed in one version and not in the other.
> 
> [Apply patch from mainline hash: 3fae6013c6]
> 8365532: java/lang/module/ModuleReader/ModuleReaderTest.testImage fails
> 
> [Apply patch from mainline hash: 0b05b7cc92]
> 8365436: ImageReaderTest fails when jmods directory not present
> 
> [Apply patch from mainline hash: 06ce9e89ab]
> 8365467: Issues with jrtfs implementation for exploded run-time images
> 
> [Apply patch from mainline hash: 166210719e]
> 8367005: ImageReader refactor caused performance regressions for startup and footprint

Looks good assuming it passed the CI tiers 1-3.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1600#pullrequestreview-3245144385

From coleenp at openjdk.org  Fri Sep 19 14:38:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 Sep 2025 14:38:37 GMT
Subject: [lworld] RFR: 8367415: Fully encapsulate array allocation in
 oopFactory
Message-ID: <R4wxCPs3ElS4neWmCx3E6xMzSHudAFn7zt24JUXn608=.6d3327b9-3a35-4ed4-b7e3-867bd8a39afd@github.com>

This makes oopFactory and deoptimization the only friends of private ArrayKlass::allocate_instance.  This is similar to the PR https://github.com/openjdk/jdk/pull/27372 in mainline with some extra handling for new_refArray (rather than calling RefArrayKlass::allocate_instance() directly.
Tested with tier1-4.

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

Commit messages:
 - 8367415: Fully encapsulate array allocation in oopFactory

Changes: https://git.openjdk.org/valhalla/pull/1602/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1602&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367415
  Stats: 53 lines in 10 files changed: 19 ins; 24 del; 10 mod
  Patch: https://git.openjdk.org/valhalla/pull/1602.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1602/head:pull/1602

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

From pchilanomate at openjdk.org  Fri Sep 19 15:14:38 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 19 Sep 2025 15:14:38 GMT
Subject: [lworld] RFR: 8368002: [lworld] Crash in
 ThawBase::remove_top_compiled_frame_from_chunk
Message-ID: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>

Please review this small fix. When thawing in the fast path, the top frame could be a runtime stub due to preempting on monitorenter. In the changes for JDK-8336845 I missed this, leading to a crash when dereferencing the nullptr returned by `f.cb()->as_nmethod_or_null()` in `ThawBase::remove_top_compiled_frame_from_chunk`.

I was able to reproduce the failure locally and verified it is now fixed. I did run into a pre-existing crash with Jetty (filed JDK-8368099). I also run all tests in java/lang/Thread/virtual stressing this path, tests Fuzz.java and TestVirtualThreads.java, plus extra mach5 tier testing.

Thanks,
Patricio

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

Commit messages:
 - fix ThawBase::remove_top_compiled_frame_from_chunk

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

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

From duke at openjdk.org  Fri Sep 19 16:09:28 2025
From: duke at openjdk.org (duke)
Date: Fri, 19 Sep 2025 16:09:28 GMT
Subject: [lworld] RFR: 8368031: Apply mainline changes to support preview
 mode work into Valhalla
In-Reply-To: <TT7PUcAmZ8OSU8CL4h1NDJar7Q9Bm-nBUsXvGq2MonU=.0b9e667c-b978-4418-84ef-0a8c172a9b84@github.com>
References: <TT7PUcAmZ8OSU8CL4h1NDJar7Q9Bm-nBUsXvGq2MonU=.0b9e667c-b978-4418-84ef-0a8c172a9b84@github.com>
Message-ID: <6vmysxEeMTOdf3f07mkrb6JppxHhkvSL3U7BahTq3lo=.812f7229-8e9c-4fd4-adb8-a1cbf54b60a7@github.com>

On Thu, 18 Sep 2025 22:56:36 GMT, David Beaumont <duke at openjdk.org> wrote:

> This change rolls up four necessary (and hopefully sufficient) mainline changes needed in Valhalla for the preview mode work.
> 
> These were applied bottom-to-top in a Valhalla repo by applying patches created from a recent mainline JDK repo, using "git show" and "git apply".
> 
> Note that I needed to use "--theirs" to resolve a small set of mismatches due to other non-exact patching which has already occurred for these classes. I see no intermediate changes in any classes by anyone else, no sign of overwriting other changes, and internal testing is passing. I would have preferred if everything applied 100% clean, but things like copyright years were fixed in one version and not in the other.
> 
> [Apply patch from mainline hash: 3fae6013c6]
> 8365532: java/lang/module/ModuleReader/ModuleReaderTest.testImage fails
> 
> [Apply patch from mainline hash: 0b05b7cc92]
> 8365436: ImageReaderTest fails when jmods directory not present
> 
> [Apply patch from mainline hash: 06ce9e89ab]
> 8365467: Issues with jrtfs implementation for exploded run-time images
> 
> [Apply patch from mainline hash: 166210719e]
> 8367005: ImageReader refactor caused performance regressions for startup and footprint

@david-beaumont 
Your change (at version 7cacf0817bff1dcab10f952995653d5af600b82f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1600#issuecomment-3312776208

From duke at openjdk.org  Fri Sep 19 16:20:28 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 19 Sep 2025 16:20:28 GMT
Subject: [lworld] Integrated: 8368031: Apply mainline changes to support
 preview mode work into Valhalla
In-Reply-To: <TT7PUcAmZ8OSU8CL4h1NDJar7Q9Bm-nBUsXvGq2MonU=.0b9e667c-b978-4418-84ef-0a8c172a9b84@github.com>
References: <TT7PUcAmZ8OSU8CL4h1NDJar7Q9Bm-nBUsXvGq2MonU=.0b9e667c-b978-4418-84ef-0a8c172a9b84@github.com>
Message-ID: <aqBPOe537JodPire3O4m_yhQDCXqaY9dm2lSnoUaYZk=.e270c790-81a9-4a92-80e8-75570700b5e3@github.com>

On Thu, 18 Sep 2025 22:56:36 GMT, David Beaumont <duke at openjdk.org> wrote:

> This change rolls up four necessary (and hopefully sufficient) mainline changes needed in Valhalla for the preview mode work.
> 
> These were applied bottom-to-top in a Valhalla repo by applying patches created from a recent mainline JDK repo, using "git show" and "git apply".
> 
> Note that I needed to use "--theirs" to resolve a small set of mismatches due to other non-exact patching which has already occurred for these classes. I see no intermediate changes in any classes by anyone else, no sign of overwriting other changes, and internal testing is passing. I would have preferred if everything applied 100% clean, but things like copyright years were fixed in one version and not in the other.
> 
> [Apply patch from mainline hash: 3fae6013c6]
> 8365532: java/lang/module/ModuleReader/ModuleReaderTest.testImage fails
> 
> [Apply patch from mainline hash: 0b05b7cc92]
> 8365436: ImageReaderTest fails when jmods directory not present
> 
> [Apply patch from mainline hash: 06ce9e89ab]
> 8365467: Issues with jrtfs implementation for exploded run-time images
> 
> [Apply patch from mainline hash: 166210719e]
> 8367005: ImageReader refactor caused performance regressions for startup and footprint

This pull request has now been integrated.

Changeset: bc7a3d63
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/bc7a3d63bcf9c0b5381f1387bad4ae7c076a3f69
Stats:     568 lines in 9 files changed: 456 ins; 44 del; 68 mod

8368031: Apply mainline changes to support preview mode work into Valhalla

Reviewed-by: liach, rriggs

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

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

From coleenp at openjdk.org  Sat Sep 20 14:33:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 20 Sep 2025 14:33:51 GMT
Subject: [lworld] RFR: 8368002: [lworld] Crash in
 ThawBase::remove_top_compiled_frame_from_chunk
In-Reply-To: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
References: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
Message-ID: <pAAcGc6oBxrqsLJZ4zaLWiH5RGujraGkWBEHdGkKuvs=.45604758-72f8-4b59-a1b1-5a3d19ba55e1@github.com>

On Fri, 19 Sep 2025 14:40:20 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small fix. When thawing in the fast path, the top frame could be a runtime stub due to preempting on monitorenter. In the changes for JDK-8336845 I missed this, leading to a crash when dereferencing the nullptr returned by `f.cb()->as_nmethod_or_null()` in `ThawBase::remove_top_compiled_frame_from_chunk`.
> 
> I was able to reproduce the failure locally and verified it is now fixed. I did run into a pre-existing crash with Jetty (filed JDK-8368099). I also run all tests in java/lang/Thread/virtual stressing this path, tests Fuzz.java and TestVirtualThreads.java, plus extra mach5 tier testing.
> 
> Thanks,
> Patricio

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2075:

> 2073: }
> 2074: 
> 2075: int ThawBase::remove_scalarized_frames(StackChunkFrameStream<ChunkFrames::CompiledOnly>& f, stackChunkOop chunk, int frames_size, int &argsize) {

Thanks for explaining this change to me.  I think this parameter is confusing.  It's the incoming frame_size from the stub frame, and this adds in all the frame sizes from the frames that need a stack repair.
It might make more sense to me to distinguish these things, have the parameter be "stub_frame_size" or "top_frame_size" and to have a local to accumulate the visited frames sizes like:
int frames_size = stub_frame_size;

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1603#discussion_r2365648753

From dsimms at openjdk.org  Mon Sep 22 06:56:59 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 22 Sep 2025 06:56:59 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <oQOkHH6N8cQOVki2nnIHO27i_k57My2OKc3fis5YcN0=.6f70ed08-9c5e-4149-8a7b-b39565dc025b@github.com>

Merge jdk-26+7

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

Commit messages:
 - Merge branch 'lworld' into lworld_merge_jdk_26_7
 - @since latest incorrect
 - Missed merge result (accept ours)
 - Merge tag 'jdk-26+7' into lworld_merge_jdk_26_7
 - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method
 - 8357226: Remove unnecessary List.indexOf from RepaintManager.removeInvalidComponent
 - 8360288: Shenandoah crash at size_given_klass in op_degenerated
 - 8362336: Revert changes in metaspaceShared.cpp done via JDK-8356807
 - 8362276: NMT tests should have locks for the entire tests
 - 8361076: Add benchmark for ImageReader in preparation for Valhalla changes
 - ... and 87 more: https://git.openjdk.org/valhalla/compare/bc7a3d63...51423632

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

Changes: https://git.openjdk.org/valhalla/pull/1604/files
  Stats: 17686 lines in 505 files changed: 10432 ins; 4840 del; 2414 mod
  Patch: https://git.openjdk.org/valhalla/pull/1604.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1604/head:pull/1604

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

From dsimms at openjdk.org  Mon Sep 22 07:39:22 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 22 Sep 2025 07:39:22 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <oQOkHH6N8cQOVki2nnIHO27i_k57My2OKc3fis5YcN0=.6f70ed08-9c5e-4149-8a7b-b39565dc025b@github.com>
References: <oQOkHH6N8cQOVki2nnIHO27i_k57My2OKc3fis5YcN0=.6f70ed08-9c5e-4149-8a7b-b39565dc025b@github.com>
Message-ID: <W-l6O2Mvxm1izeQ8tcY_ZKF300DuRbe-eeUmPm3_pXQ=.73b18164-84d7-464a-b13a-a22d4f47c57a@github.com>

On Mon, 22 Sep 2025 06:49:10 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+7

This pull request has now been integrated.

Changeset: b22f6a47
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b22f6a476ec1f8d52845ba416ca74e5f573d7ae4
Stats:     17686 lines in 505 files changed: 10432 ins; 4840 del; 2414 mod

Merge jdk

Merge jdk-26+7

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

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

From mhaessig at openjdk.org  Mon Sep 22 10:58:03 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 22 Sep 2025 10:58:03 GMT
Subject: [lworld] RFR: 8367518: TestRedundantLea.java fails in Valhalla
Message-ID: <TesTvna9Hnac4nqILX5rFxHSgHMlXgbC62oEqWd4-rE=.1f8b82f9-d2a6-4755-b893-ca1aedc104f4@github.com>

After merging `TestRedundantLea.java` into valhalla it turned out that the `StringInflate` and `StoreN*` subtests fail. This PR fixes that by bringing over two commits from mainline that fix problems with this test, which already fixes `StringInflate`.

The problem with the `StoreN` cases is that with valhalla C2 does not generate spills that the peephole can remove. To still test removing spills I came up with a new test case specifically for spills.

Testing:
 - [x] tier1,tier2 plus some stress testing

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

Commit messages:
 - Fix TestRedundantLea an un-problem-list
 - Unproblemlist TestRedundantLea#InflateString
 - 8360175: C2 crash:  assert(edge_from_to(prior_use,n)) failed: before block local scheduling
 - 8361040: compiler/codegen/TestRedundantLea.java#StringInflate fails with failed IR rules

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

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

From dsimms at openjdk.org  Mon Sep 22 11:45:15 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 22 Sep 2025 11:45:15 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <KMptK5WWcuZn_uQLTZs-vFM48TE39zmBlWRvq7hAp8g=.2e187aea-0b0d-4beb-b4f2-e96d5d4b4bd7@github.com>

Merge jdk-26+8

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

Commit messages:
 - Sort includes
 - Merge tag 'jdk-26+8' into lworld_merge_jdk_26_8
 - 8362193: Re-work MacOS/AArch64 SpinPause to handle SB
 - 8350896: Integer/Long.compress gets wrong type from CompressBitsNode::Value
 - 8356997: /etc/krb5.conf parser should not forbid include/includedir directives after sections
 - 8360520: RISC-V: C1: Fix primitive array clone intrinsic regression after JDK-8333154
 - 8362972: C2 fails with unexpected node in SuperWord truncation: IsFiniteF, IsFiniteD
 - 8360941: [ubsan] MemRegion::end() shows runtime error: applying non-zero offset 8388608 to null pointer
 - 8362889: [GCC static analyzer] leak in libstringPlatformChars.c
 - 8362846: Windows error reporting for dll_load doesn't check for a null buffer
 - ... and 64 more: https://git.openjdk.org/valhalla/compare/b22f6a47...a948eeb9

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

Changes: https://git.openjdk.org/valhalla/pull/1606/files
  Stats: 8531 lines in 318 files changed: 5922 ins; 1456 del; 1153 mod
  Patch: https://git.openjdk.org/valhalla/pull/1606.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1606/head:pull/1606

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

From chagedorn at openjdk.org  Mon Sep 22 11:48:37 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 22 Sep 2025 11:48:37 GMT
Subject: [lworld] RFR: 8367518: TestRedundantLea.java fails in Valhalla
In-Reply-To: <TesTvna9Hnac4nqILX5rFxHSgHMlXgbC62oEqWd4-rE=.1f8b82f9-d2a6-4755-b893-ca1aedc104f4@github.com>
References: <TesTvna9Hnac4nqILX5rFxHSgHMlXgbC62oEqWd4-rE=.1f8b82f9-d2a6-4755-b893-ca1aedc104f4@github.com>
Message-ID: <fqQvzhU3vasXNYrV5fOA2jjBhRl4aaR4RDz65eewTBE=.1e05fca9-9bea-46bf-b012-63fe89d24047@github.com>

On Mon, 22 Sep 2025 10:52:07 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> After merging `TestRedundantLea.java` into valhalla it turned out that the `StringInflate` and `StoreN*` subtests fail. This PR fixes that by bringing over two commits from mainline that fix problems with this test, which already fixes `StringInflate`.
> 
> The problem with the `StoreN` cases is that with valhalla C2 does not generate spills that the peephole can remove. To still test removing spills I came up with a new test case specifically for spills.
> 
> Testing:
>  - [x] tier1,tier2 plus some stress testing

Looks good, thanks for fixing this and adding an additional test case!

test/hotspot/jtreg/compiler/codegen/TestRedundantLea.java line 369:

> 367: 
> 368:     @Test
> 369:     // TODO: Make tests more precise

I guess that was already there for mainline but I'm wondering, is there a tracking issue for that?

test/hotspot/jtreg/compiler/codegen/TestRedundantLea.java line 383:

> 381:     @IR(counts = {IRNode.MEM_TO_REG_SPILL_COPY, ">=20"},
> 382:         phase = {CompilePhase.FINAL_CODE},
> 383:         applyIf ={"OptoPeephole", "false"})

Suggestion:

        applyIf = {"OptoPeephole", "false"})

test/hotspot/jtreg/compiler/codegen/TestRedundantLea.java line 386:

> 384:     @IR(counts = {IRNode.MEM_TO_REG_SPILL_COPY, ">=18"},
> 385:         phase = {CompilePhase.FINAL_CODE},
> 386:         applyIf ={"OptoPeephole", "true"})

Suggestion:

        applyIf = {"OptoPeephole", "true"})

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1605#pullrequestreview-3252158074
PR Review Comment: https://git.openjdk.org/valhalla/pull/1605#discussion_r2367875967
PR Review Comment: https://git.openjdk.org/valhalla/pull/1605#discussion_r2367879273
PR Review Comment: https://git.openjdk.org/valhalla/pull/1605#discussion_r2367878921

From dsimms at openjdk.org  Mon Sep 22 12:10:50 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 22 Sep 2025 12:10:50 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <KMptK5WWcuZn_uQLTZs-vFM48TE39zmBlWRvq7hAp8g=.2e187aea-0b0d-4beb-b4f2-e96d5d4b4bd7@github.com>
References: <KMptK5WWcuZn_uQLTZs-vFM48TE39zmBlWRvq7hAp8g=.2e187aea-0b0d-4beb-b4f2-e96d5d4b4bd7@github.com>
Message-ID: <GMd9IiUr5EK3f51lQKdNIBSD4cfSe6U2LrJ4iVd5W4o=.9a428c2c-5a86-4054-9405-5ab37c01ff65@github.com>

On Mon, 22 Sep 2025 11:37:51 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+8

This pull request has now been integrated.

Changeset: fdea44cc
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/fdea44cce6fea7e98a4cb25273d4f93eac984fbf
Stats:     8531 lines in 318 files changed: 5922 ins; 1456 del; 1153 mod

Merge jdk

Merge jdk-26+8

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

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

From phubner at openjdk.org  Mon Sep 22 12:11:50 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 22 Sep 2025 12:11:50 GMT
Subject: [lworld] RFR: 8270527: [lworld] markWord::print_on() needs to
 reflect the additional Valhalla mark word bits [v2]
In-Reply-To: <TVMixYdPXHJOE5quIOLdzUxUUPUoGipgwWGR7jRT76c=.b0c01253-60bd-4d22-9332-09aa9d050659@github.com>
References: <TVMixYdPXHJOE5quIOLdzUxUUPUoGipgwWGR7jRT76c=.b0c01253-60bd-4d22-9332-09aa9d050659@github.com>
Message-ID: <YoVnTOiT_IXshbyPAlqPsSUoO_2iDF0O_RlQbCVcu1Q=.5fea4cd6-a030-4351-8431-070286a91383@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.

Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:

  Take in reviewer comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1588/files
  - new: https://git.openjdk.org/valhalla/pull/1588/files/325355f1..4f8c4f5b

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 dsimms at openjdk.org  Mon Sep 22 12:11:51 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 22 Sep 2025 12:11:51 GMT
Subject: [lworld] RFR: 8270527: [lworld] markWord::print_on() needs to
 reflect the additional Valhalla mark word bits [v2]
In-Reply-To: <YoVnTOiT_IXshbyPAlqPsSUoO_2iDF0O_RlQbCVcu1Q=.5fea4cd6-a030-4351-8431-070286a91383@github.com>
References: <TVMixYdPXHJOE5quIOLdzUxUUPUoGipgwWGR7jRT76c=.b0c01253-60bd-4d22-9332-09aa9d050659@github.com>
 <YoVnTOiT_IXshbyPAlqPsSUoO_2iDF0O_RlQbCVcu1Q=.5fea4cd6-a030-4351-8431-070286a91383@github.com>
Message-ID: <7KCf8VM0fUN8jck4L8PqtcTFu6N526M3oMOyl_ZHuoc=.80ad2598-d184-4318-83a7-e176863e5975@github.com>

On Mon, 22 Sep 2025 12:07:46 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> 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.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Take in reviewer comments

Minor comment on wording of monitor, otherwise looks good

Marked as reviewed by dsimms (Committer).

src/hotspot/share/oops/markWord.cpp line 75:

> 73:   } else if (has_monitor()) {  // last bits = 10
> 74:     // have to check has_monitor() before is_locked()
> 75:     // Valhalla: inline types/arrays can't be monitored

"can not possess an object monitor" ?

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

PR Review: https://git.openjdk.org/valhalla/pull/1588#pullrequestreview-3252225235
PR Review: https://git.openjdk.org/valhalla/pull/1588#pullrequestreview-3252251348
PR Review Comment: https://git.openjdk.org/valhalla/pull/1588#discussion_r2367936123

From phubner at openjdk.org  Mon Sep 22 12:11:53 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 22 Sep 2025 12:11:53 GMT
Subject: [lworld] Integrated: 8270527: [lworld] markWord::print_on() needs to
 reflect the additional Valhalla mark word bits
In-Reply-To: <TVMixYdPXHJOE5quIOLdzUxUUPUoGipgwWGR7jRT76c=.b0c01253-60bd-4d22-9332-09aa9d050659@github.com>
References: <TVMixYdPXHJOE5quIOLdzUxUUPUoGipgwWGR7jRT76c=.b0c01253-60bd-4d22-9332-09aa9d050659@github.com>
Message-ID: <k38xBJXbnDa6wTKVGLSxvjwIqW5nlrXNcBEhzMI6hbo=.4a01f34d-d687-4b99-ae22-e145bf36c2f8@github.com>

On Mon, 15 Sep 2025 10:03:17 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> 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.

This pull request has now been integrated.

Changeset: f7c59328
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f7c59328f45b5f9bf1aed43f2ec3570b43f6e03b
Stats:     33 lines in 2 files changed: 31 ins; 0 del; 2 mod

8270527: [lworld] markWord::print_on() needs to reflect the additional Valhalla mark word bits

Reviewed-by: dsimms

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

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

From mhaessig at openjdk.org  Mon Sep 22 12:53:24 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 22 Sep 2025 12:53:24 GMT
Subject: [lworld] RFR: 8367518: TestRedundantLea.java fails in Valhalla
 [v2]
In-Reply-To: <fqQvzhU3vasXNYrV5fOA2jjBhRl4aaR4RDz65eewTBE=.1e05fca9-9bea-46bf-b012-63fe89d24047@github.com>
References: <TesTvna9Hnac4nqILX5rFxHSgHMlXgbC62oEqWd4-rE=.1f8b82f9-d2a6-4755-b893-ca1aedc104f4@github.com>
 <fqQvzhU3vasXNYrV5fOA2jjBhRl4aaR4RDz65eewTBE=.1e05fca9-9bea-46bf-b012-63fe89d24047@github.com>
Message-ID: <05SrHtxjrYbDuM9V79beSKP7jD8z8y80XyiodXZj7Hk=.f21f7c2a-368a-4bff-b880-a4baf0d59abf@github.com>

On Mon, 22 Sep 2025 11:42:25 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from Christian
>>   
>>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>
> test/hotspot/jtreg/compiler/codegen/TestRedundantLea.java line 369:
> 
>> 367: 
>> 368:     @Test
>> 369:     // TODO: Make tests more precise
> 
> I guess that was already there for mainline but I'm wondering, is there a tracking issue for that?

Yes, there is JDK-8361089

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1605#discussion_r2368213704

From mhaessig at openjdk.org  Mon Sep 22 12:53:22 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 22 Sep 2025 12:53:22 GMT
Subject: [lworld] RFR: 8367518: TestRedundantLea.java fails in Valhalla
 [v2]
In-Reply-To: <TesTvna9Hnac4nqILX5rFxHSgHMlXgbC62oEqWd4-rE=.1f8b82f9-d2a6-4755-b893-ca1aedc104f4@github.com>
References: <TesTvna9Hnac4nqILX5rFxHSgHMlXgbC62oEqWd4-rE=.1f8b82f9-d2a6-4755-b893-ca1aedc104f4@github.com>
Message-ID: <oWqShP2O2xHI5T-kf6gWOj0Z_rK72iwrOypmH590_Bk=.a3a013aa-e97a-44e6-b378-b046bfd64099@github.com>

> After merging `TestRedundantLea.java` into valhalla it turned out that the `StringInflate` and `StoreN*` subtests fail. This PR fixes that by bringing over two commits from mainline that fix problems with this test, which already fixes `StringInflate`.
> 
> The problem with the `StoreN` cases is that with valhalla C2 does not generate spills that the peephole can remove. To still test removing spills I came up with a new test case specifically for spills.
> 
> Testing:
>  - [x] tier1,tier2 plus some stress testing

Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from Christian
  
  Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1605/files
  - new: https://git.openjdk.org/valhalla/pull/1605/files/6119e5e7..10670b68

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

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

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

From dsimms at openjdk.org  Mon Sep 22 13:06:21 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 22 Sep 2025 13:06:21 GMT
Subject: [lworld] Integrated: Missing include
In-Reply-To: <QpjSONddqZWtYEDEc11Rs6tk0sqdye_R2yomP1QLYqo=.7e45a5bc-1790-49d5-afe1-ca4d7a8110dd@github.com>
References: <QpjSONddqZWtYEDEc11Rs6tk0sqdye_R2yomP1QLYqo=.7e45a5bc-1790-49d5-afe1-ca4d7a8110dd@github.com>
Message-ID: <ZE2ROmZhYgHN6onnR5bnQ7wJlVF8QNlF7VTKEF1NYfs=.84a00454-0b0b-4029-a231-490627f135c1@github.com>

On Mon, 22 Sep 2025 12:58:46 GMT, David Simms <dsimms at openjdk.org> wrote:

> Post merge won't compile without precompiled headers

This pull request has now been integrated.

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

Missing include

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

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

From dsimms at openjdk.org  Mon Sep 22 13:06:20 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 22 Sep 2025 13:06:20 GMT
Subject: [lworld] Integrated: Missing include
Message-ID: <QpjSONddqZWtYEDEc11Rs6tk0sqdye_R2yomP1QLYqo=.7e45a5bc-1790-49d5-afe1-ca4d7a8110dd@github.com>

Post merge won't compile without precompiled headers

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

Commit messages:
 - Missing include

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

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

From dsimms at openjdk.org  Mon Sep 22 13:17:40 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 22 Sep 2025 13:17:40 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <uTA7YIIp60KLSm9LcIzgdKTVKcklAv_523Vtb4OX0Og=.debf3e02-e513-413b-9e6d-3d40fab54ed0@github.com>

Merge jdk-26+9

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

Commit messages:
 - Merge branch 'lworld' into lworld_merge_jdk_26_9
 - Sorted includes
 - Merge tag 'jdk-26+9' into lworld_merge_jdk_26_9
 - 8364282: ZGC: Improve ZPageAllocation JFR event sending
 - 8364111: InstanceMirrorKlass iterators should handle CDS and hidden classes consistently
 - 8361524: [XWayland] possible JavaFX interop hang
 - 8362501: Update test/hotspot/jtreg/applications/jcstress/README
 - 8357682: sun.security.provider.certpath.Builder#getMatchingPolicies always returns null
 - 8361212: Remove AffirmTrust root CAs
 - 8362279: [vectorapi] VECTOR_OP_SUADD needs reduction support
 - ... and 73 more: https://git.openjdk.org/valhalla/compare/d15b325d...0f7fe3ba

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

Changes: https://git.openjdk.org/valhalla/pull/1608/files
  Stats: 13191 lines in 372 files changed: 5247 ins; 6804 del; 1140 mod
  Patch: https://git.openjdk.org/valhalla/pull/1608.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1608/head:pull/1608

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

From liach at openjdk.org  Mon Sep 22 13:51:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 Sep 2025 13:51:28 GMT
Subject: [lworld] RFR: 8362181: [lworld] Include verification for strict
 fields in ClassFile API [v2]
In-Reply-To: <1m2vQXzXlB-TFt7yS4KfmuM1V1Bzyy8hMxlCG3xVAs8=.959e319f-002f-4c7f-b2cf-1102ed3bb37f@github.com>
References: <1m2vQXzXlB-TFt7yS4KfmuM1V1Bzyy8hMxlCG3xVAs8=.959e319f-002f-4c7f-b2cf-1102ed3bb37f@github.com>
Message-ID: <knsVqJZRK2rkaU4oB3HuVY--RZ6tAnJvdM0XPnIevGY=.510833eb-eaf4-45ec-853e-c20f4665e726@github.com>

> The lack of classfile verifier recognition of strict fields is the only part of class file API support left for strict fields.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Include strict field stuff in classfile verifier

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

Changes: https://git.openjdk.org/valhalla/pull/1506/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1506&range=01
  Stats: 225 lines in 9 files changed: 191 ins; 4 del; 30 mod
  Patch: https://git.openjdk.org/valhalla/pull/1506.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1506/head:pull/1506

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

From liach at openjdk.org  Mon Sep 22 15:30:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 Sep 2025 15:30:26 GMT
Subject: [lworld] RFR: 8362181: [lworld] Include verification for strict
 fields in ClassFile API [v3]
In-Reply-To: <1m2vQXzXlB-TFt7yS4KfmuM1V1Bzyy8hMxlCG3xVAs8=.959e319f-002f-4c7f-b2cf-1102ed3bb37f@github.com>
References: <1m2vQXzXlB-TFt7yS4KfmuM1V1Bzyy8hMxlCG3xVAs8=.959e319f-002f-4c7f-b2cf-1102ed3bb37f@github.com>
Message-ID: <wcQLjWPcGqibnPXf8R9p787noP4CF_SSAlo_cGtDLa0=.522d324e-acc9-4d19-b196-9c351d455608@github.com>

> The lack of classfile verifier recognition of strict fields is the only part of class file API support left for strict fields.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Only process strict fields by class file version

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1506/files
  - new: https://git.openjdk.org/valhalla/pull/1506/files/63e0257e..fef0bd84

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

  Stats: 52 lines in 5 files changed: 50 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1506.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1506/head:pull/1506

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

From dsimms at openjdk.org  Mon Sep 22 17:08:55 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 22 Sep 2025 17:08:55 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <uTA7YIIp60KLSm9LcIzgdKTVKcklAv_523Vtb4OX0Og=.debf3e02-e513-413b-9e6d-3d40fab54ed0@github.com>
References: <uTA7YIIp60KLSm9LcIzgdKTVKcklAv_523Vtb4OX0Og=.debf3e02-e513-413b-9e6d-3d40fab54ed0@github.com>
Message-ID: <beeycRK2iufL32sy_DOUJnKZm7KPjZObB4W7Xnw_rC8=.06579cd7-49bd-4be3-ac64-608569c5481c@github.com>

On Mon, 22 Sep 2025 13:10:28 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+9

This pull request has now been integrated.

Changeset: ee7ff9bb
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ee7ff9bb5b4e99c266f61329a87ad49e02106a5d
Stats:     13191 lines in 372 files changed: 5247 ins; 6804 del; 1140 mod

Merge jdk

Merge jdk-26+9

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

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

From pchilanomate at openjdk.org  Mon Sep 22 17:22:51 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 22 Sep 2025 17:22:51 GMT
Subject: [lworld] RFR: 8368002: [lworld] Crash in
 ThawBase::remove_top_compiled_frame_from_chunk [v2]
In-Reply-To: <pAAcGc6oBxrqsLJZ4zaLWiH5RGujraGkWBEHdGkKuvs=.45604758-72f8-4b59-a1b1-5a3d19ba55e1@github.com>
References: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
 <pAAcGc6oBxrqsLJZ4zaLWiH5RGujraGkWBEHdGkKuvs=.45604758-72f8-4b59-a1b1-5a3d19ba55e1@github.com>
Message-ID: <5qWZLCxLMei8OtubWP2hwgQJvfd9DgPp3xkOZBHKveg=.ce0723cb-1577-4dc6-bc8f-6ee064bebc50@github.com>

On Sat, 20 Sep 2025 14:31:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove frames_size parameter and code duplication from remove_scalarized_frames
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2075:
> 
>> 2073: }
>> 2074: 
>> 2075: int ThawBase::remove_scalarized_frames(StackChunkFrameStream<ChunkFrames::CompiledOnly>& f, stackChunkOop chunk, int frames_size, int &argsize) {
> 
> Thanks for explaining this change to me.  I think this parameter is confusing.  It's the incoming frame_size from the stub frame, and this adds in all the frame sizes from the frames that need a stack repair.
> It might make more sense to me to distinguish these things, have the parameter be "stub_frame_size" or "top_frame_size" and to have a local to accumulate the visited frames sizes like:
> int frames_size = stub_frame_size;

I removed that parameter altogether. I realized we can remove all the duplicated code in `remove_scalarized_frames()`, so that the method just returns the size of all the frames removed. Then for the stub case, we add this value to the size of the stub frame. For the non-stub case, this returned value is the final size.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1603#discussion_r2369517735

From pchilanomate at openjdk.org  Mon Sep 22 17:22:48 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 22 Sep 2025 17:22:48 GMT
Subject: [lworld] RFR: 8368002: [lworld] Crash in
 ThawBase::remove_top_compiled_frame_from_chunk [v2]
In-Reply-To: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
References: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
Message-ID: <kdzuNB-omx6a5YYnXLrnyMNe7WeEKnwRXjDSHDVqKh0=.73b2c12a-84d4-4294-b059-a22b5c803d08@github.com>

> Please review this small fix. When thawing in the fast path, the top frame could be a runtime stub due to preempting on monitorenter. In the changes for JDK-8336845 I missed this, leading to a crash when dereferencing the nullptr returned by `f.cb()->as_nmethod_or_null()` in `ThawBase::remove_top_compiled_frame_from_chunk`.
> 
> I was able to reproduce the failure locally and verified it is now fixed. I did run into a pre-existing crash with Jetty (filed JDK-8368099). I also run all tests in java/lang/Thread/virtual stressing this path, tests Fuzz.java and TestVirtualThreads.java, plus extra mach5 tier testing.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  remove frames_size parameter and code duplication from remove_scalarized_frames

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1603/files
  - new: https://git.openjdk.org/valhalla/pull/1603/files/69eb45da..4e2aed1f

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

  Stats: 31 lines in 1 file changed: 0 ins; 26 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/1603.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1603/head:pull/1603

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

From coleenp at openjdk.org  Mon Sep 22 18:11:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 22 Sep 2025 18:11:30 GMT
Subject: [lworld] RFR: 8368002: [lworld] Crash in
 ThawBase::remove_top_compiled_frame_from_chunk [v2]
In-Reply-To: <kdzuNB-omx6a5YYnXLrnyMNe7WeEKnwRXjDSHDVqKh0=.73b2c12a-84d4-4294-b059-a22b5c803d08@github.com>
References: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
 <kdzuNB-omx6a5YYnXLrnyMNe7WeEKnwRXjDSHDVqKh0=.73b2c12a-84d4-4294-b059-a22b5c803d08@github.com>
Message-ID: <Si0N5YMWmti0P2JzF8B1dX9K1HTZ7PuOGXJogU_4jr8=.efd34232-4765-4fa9-bc52-a21bbcf301a4@github.com>

On Mon, 22 Sep 2025 17:22:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small fix. When thawing in the fast path, the top frame could be a runtime stub due to preempting on monitorenter. In the changes for JDK-8336845 I missed this, leading to a crash when dereferencing the nullptr returned by `f.cb()->as_nmethod_or_null()` in `ThawBase::remove_top_compiled_frame_from_chunk`.
>> 
>> I was able to reproduce the failure locally and verified it is now fixed. I did run into a pre-existing crash with Jetty (filed JDK-8368099). I also run all tests in java/lang/Thread/virtual stressing this path, tests Fuzz.java and TestVirtualThreads.java, plus extra mach5 tier testing.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove frames_size parameter and code duplication from remove_scalarized_frames

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2076:

> 2074: 
> 2075: int ThawBase::remove_scalarized_frames(StackChunkFrameStream<ChunkFrames::CompiledOnly>& f, stackChunkOop chunk, int &argsize) {
> 2076:   DEBUG_ONLY(intptr_t* const chunk_sp = chunk->start_address() + chunk->sp();)

Can you remove the 'chunk' parameter too?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1603#discussion_r2369700392

From pchilanomate at openjdk.org  Mon Sep 22 18:26:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 22 Sep 2025 18:26:55 GMT
Subject: [lworld] RFR: 8368002: [lworld] Crash in
 ThawBase::remove_top_compiled_frame_from_chunk [v3]
In-Reply-To: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
References: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
Message-ID: <YC1ySdMeaCkyd1EdarFIHLbAYiyXdsJ5tXcm0-jEqDc=.be45bd0d-978f-4da8-9bc8-c07495f04209@github.com>

> Please review this small fix. When thawing in the fast path, the top frame could be a runtime stub due to preempting on monitorenter. In the changes for JDK-8336845 I missed this, leading to a crash when dereferencing the nullptr returned by `f.cb()->as_nmethod_or_null()` in `ThawBase::remove_top_compiled_frame_from_chunk`.
> 
> I was able to reproduce the failure locally and verified it is now fixed. I did run into a pre-existing crash with Jetty (filed JDK-8368099). I also run all tests in java/lang/Thread/virtual stressing this path, tests Fuzz.java and TestVirtualThreads.java, plus extra mach5 tier testing.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  remove chunk parameter from remove_scalarized_frames

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1603/files
  - new: https://git.openjdk.org/valhalla/pull/1603/files/4e2aed1f..15b254f5

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

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

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

From pchilanomate at openjdk.org  Mon Sep 22 18:26:57 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 22 Sep 2025 18:26:57 GMT
Subject: [lworld] RFR: 8368002: [lworld] Crash in
 ThawBase::remove_top_compiled_frame_from_chunk [v2]
In-Reply-To: <Si0N5YMWmti0P2JzF8B1dX9K1HTZ7PuOGXJogU_4jr8=.efd34232-4765-4fa9-bc52-a21bbcf301a4@github.com>
References: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
 <kdzuNB-omx6a5YYnXLrnyMNe7WeEKnwRXjDSHDVqKh0=.73b2c12a-84d4-4294-b059-a22b5c803d08@github.com>
 <Si0N5YMWmti0P2JzF8B1dX9K1HTZ7PuOGXJogU_4jr8=.efd34232-4765-4fa9-bc52-a21bbcf301a4@github.com>
Message-ID: <qzvdc98U_hWohoy9A-BETEibwXPxRPD18D1P2MhDWtM=.1fa796e6-12a4-4809-9839-b325815f90a7@github.com>

On Mon, 22 Sep 2025 18:08:16 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove frames_size parameter and code duplication from remove_scalarized_frames
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2076:
> 
>> 2074: 
>> 2075: int ThawBase::remove_scalarized_frames(StackChunkFrameStream<ChunkFrames::CompiledOnly>& f, stackChunkOop chunk, int &argsize) {
>> 2076:   DEBUG_ONLY(intptr_t* const chunk_sp = chunk->start_address() + chunk->sp();)
> 
> Can you remove the 'chunk' parameter too?

Right, also not needed. Removed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1603#discussion_r2369765073

From liach at openjdk.org  Mon Sep 22 18:47:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 Sep 2025 18:47:52 GMT
Subject: [lworld] RFR: 8362181: [lworld] Include verification for strict
 fields in ClassFile API [v3]
In-Reply-To: <wcQLjWPcGqibnPXf8R9p787noP4CF_SSAlo_cGtDLa0=.522d324e-acc9-4d19-b196-9c351d455608@github.com>
References: <1m2vQXzXlB-TFt7yS4KfmuM1V1Bzyy8hMxlCG3xVAs8=.959e319f-002f-4c7f-b2cf-1102ed3bb37f@github.com>
 <wcQLjWPcGqibnPXf8R9p787noP4CF_SSAlo_cGtDLa0=.522d324e-acc9-4d19-b196-9c351d455608@github.com>
Message-ID: <zZiQJgumujKhh7yL_0idp2I-l4wh1J40aGIWWzVEnXI=.fe9d1f58-3ce5-483b-a130-0962d3cd388a@github.com>

On Mon, 22 Sep 2025 15:30:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The lack of classfile verifier recognition of strict fields is the only part of class file API support left for strict fields.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only process strict fields by class file version

Only 2 unrelated failures in tier 1-3. Integrating.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1506#issuecomment-3320780457

From liach at openjdk.org  Mon Sep 22 18:47:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 Sep 2025 18:47:54 GMT
Subject: [lworld] Integrated: 8362181: [lworld] Include verification for strict
 fields in ClassFile API
In-Reply-To: <1m2vQXzXlB-TFt7yS4KfmuM1V1Bzyy8hMxlCG3xVAs8=.959e319f-002f-4c7f-b2cf-1102ed3bb37f@github.com>
References: <1m2vQXzXlB-TFt7yS4KfmuM1V1Bzyy8hMxlCG3xVAs8=.959e319f-002f-4c7f-b2cf-1102ed3bb37f@github.com>
Message-ID: <EjNHwz7fuadrAXGRx3liZkwTaWrU9jLSIqbB9F-vfr0=.5fd2dea3-662d-426a-96ae-345762e377a8@github.com>

On Wed, 9 Jul 2025 16:36:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> The lack of classfile verifier recognition of strict fields is the only part of class file API support left for strict fields.

This pull request has now been integrated.

Changeset: 2c2f4b2b
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2c2f4b2b98be4e9be4bae1aa0db94ccc08b743e0
Stats:     276 lines in 12 files changed: 241 ins; 4 del; 31 mod

8362181: [lworld] Include verification for strict fields in ClassFile API

Reviewed-by: vromero

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

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

From fparain at openjdk.org  Mon Sep 22 19:20:44 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 22 Sep 2025 19:20:44 GMT
Subject: [lworld] RFR: 8367415: Fully encapsulate array allocation in
 oopFactory
In-Reply-To: <R4wxCPs3ElS4neWmCx3E6xMzSHudAFn7zt24JUXn608=.6d3327b9-3a35-4ed4-b7e3-867bd8a39afd@github.com>
References: <R4wxCPs3ElS4neWmCx3E6xMzSHudAFn7zt24JUXn608=.6d3327b9-3a35-4ed4-b7e3-867bd8a39afd@github.com>
Message-ID: <-XQUQN9R2pCSe4cEEYB87SpLPeliXZz7gLSdGP9NSRs=.9bd4b056-ab35-4e04-92df-2d1a5894f494@github.com>

On Fri, 19 Sep 2025 14:32:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This makes oopFactory and deoptimization the only friends of private ArrayKlass::allocate_instance.  This is similar to the PR https://github.com/openjdk/jdk/pull/27372 in mainline with some extra handling for new_refArray (rather than calling RefArrayKlass::allocate_instance() directly.
> Tested with tier1-4.

src/hotspot/share/oops/objArrayKlass.hpp line 95:

> 93:                                                 int n, Klass* element_klass, TRAPS);
> 94: 
> 95:  public:

Is this needed? There's already one at line 60.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1602#discussion_r2369978678

From coleenp at openjdk.org  Mon Sep 22 19:54:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 22 Sep 2025 19:54:11 GMT
Subject: [lworld] RFR: 8367415: Fully encapsulate array allocation in
 oopFactory [v2]
In-Reply-To: <R4wxCPs3ElS4neWmCx3E6xMzSHudAFn7zt24JUXn608=.6d3327b9-3a35-4ed4-b7e3-867bd8a39afd@github.com>
References: <R4wxCPs3ElS4neWmCx3E6xMzSHudAFn7zt24JUXn608=.6d3327b9-3a35-4ed4-b7e3-867bd8a39afd@github.com>
Message-ID: <ELCSaQIE6JN4wMw9WQxSOXkhzrby9_bej7DlmfASTqM=.9b49f25a-4e5d-466d-a070-f6591fcefc5e@github.com>

> This makes oopFactory and deoptimization the only friends of private ArrayKlass::allocate_instance.  This is similar to the PR https://github.com/openjdk/jdk/pull/27372 in mainline with some extra handling for new_refArray (rather than calling RefArrayKlass::allocate_instance() directly.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Remove rogue public

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1602/files
  - new: https://git.openjdk.org/valhalla/pull/1602/files/5712324e..990cf11f

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

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

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

From coleenp at openjdk.org  Mon Sep 22 19:54:14 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 22 Sep 2025 19:54:14 GMT
Subject: [lworld] RFR: 8367415: Fully encapsulate array allocation in
 oopFactory [v2]
In-Reply-To: <-XQUQN9R2pCSe4cEEYB87SpLPeliXZz7gLSdGP9NSRs=.9bd4b056-ab35-4e04-92df-2d1a5894f494@github.com>
References: <R4wxCPs3ElS4neWmCx3E6xMzSHudAFn7zt24JUXn608=.6d3327b9-3a35-4ed4-b7e3-867bd8a39afd@github.com>
 <-XQUQN9R2pCSe4cEEYB87SpLPeliXZz7gLSdGP9NSRs=.9bd4b056-ab35-4e04-92df-2d1a5894f494@github.com>
Message-ID: <lVBvH6EyrOW5n4nFaxHKxFTexbOUXYxlvnZnq2Vy_kc=.64271cfa-e0e0-4c0d-9889-d033640df464@github.com>

On Mon, 22 Sep 2025 19:18:01 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 rogue public
>
> src/hotspot/share/oops/objArrayKlass.hpp line 95:
> 
>> 93:                                                 int n, Klass* element_klass, TRAPS);
>> 94: 
>> 95:  public:
> 
> Is this needed? There's already one at line 60.

It's not.  I moved the methods to be where they are in mainline.  Thanks for noticing this.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1602#discussion_r2370114307

From coleenp at openjdk.org  Mon Sep 22 20:22:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 22 Sep 2025 20:22:28 GMT
Subject: [lworld] RFR: 8367415: Fully encapsulate array allocation in
 oopFactory [v3]
In-Reply-To: <R4wxCPs3ElS4neWmCx3E6xMzSHudAFn7zt24JUXn608=.6d3327b9-3a35-4ed4-b7e3-867bd8a39afd@github.com>
References: <R4wxCPs3ElS4neWmCx3E6xMzSHudAFn7zt24JUXn608=.6d3327b9-3a35-4ed4-b7e3-867bd8a39afd@github.com>
Message-ID: <sWG77SDS09Ep8gMULOiPjNlH7AlUPuORIA3QxTqw68A=.5ff89010-f5e9-4653-bea9-637a07279ff0@github.com>

> This makes oopFactory and deoptimization the only friends of private ArrayKlass::allocate_instance.  This is similar to the PR https://github.com/openjdk/jdk/pull/27372 in mainline with some extra handling for new_refArray (rather than calling RefArrayKlass::allocate_instance() directly.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'lworld' into oopFactory
 - Remove rogue public
 - 8367415: Fully encapsulate array allocation in oopFactory

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

Changes: https://git.openjdk.org/valhalla/pull/1602/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1602&range=02
  Stats: 54 lines in 10 files changed: 18 ins; 26 del; 10 mod
  Patch: https://git.openjdk.org/valhalla/pull/1602.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1602/head:pull/1602

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

From duke at openjdk.org  Mon Sep 22 22:26:23 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 22 Sep 2025 22:26:23 GMT
Subject: [lworld] RFR: C++ preparation for preview mode
Message-ID: <RLZhZqNVU7eQCErLwoedsIKpdWfFLnNHE0_n9HY2ePk=.76ef953f-7ce6-4be5-b0d5-fb7149179c02@github.com>

C++ changes for supporting preview mode *when* preview mode resources (with new location flags) are available.

At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

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

Commit messages:
 - C++ preparation for preview mode

Changes: https://git.openjdk.org/valhalla/pull/1609/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1609&range=00
  Stats: 326 lines in 8 files changed: 215 ins; 60 del; 51 mod
  Patch: https://git.openjdk.org/valhalla/pull/1609.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1609/head:pull/1609

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

From duke at openjdk.org  Mon Sep 22 22:28:31 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 22 Sep 2025 22:28:31 GMT
Subject: [lworld] RFR: C++ preparation for preview mode
In-Reply-To: <RLZhZqNVU7eQCErLwoedsIKpdWfFLnNHE0_n9HY2ePk=.76ef953f-7ce6-4be5-b0d5-fb7149179c02@github.com>
References: <RLZhZqNVU7eQCErLwoedsIKpdWfFLnNHE0_n9HY2ePk=.76ef953f-7ce6-4be5-b0d5-fb7149179c02@github.com>
Message-ID: <L3bhYrKDM6G1ng184t5UdwPbDK6SJNaTpyTkpfP-wtI=.33fc80bd-0cf9-447d-b0ab-1a608f06c893@github.com>

On Mon, 22 Sep 2025 22:21:25 GMT, David Beaumont <duke at openjdk.org> wrote:

> C++ changes for supporting preview mode *when* preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

src/java.base/share/native/libjimage/imageFile.hpp line 248:

> 246:     };
> 247: 
> 248:     // Flag masks for the ATTRIBUTE_PREVIEW_FLAGS attribute. Defined so

As discussed offline, there might be a neater expression for these flags with:


bit: 1 0
    [0,0] 0 = normal_entry (only)
    [0,1] 1 = normal_entry_with_preview_version
    [1,0] 2 = preview_entry (only)
    [1,1] 3 = preview_entry_with_normal_version
       ^-- has other version bit
     ^---- is preview version bit

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1609#discussion_r2370441339

From pchilanomate at openjdk.org  Mon Sep 22 23:24:29 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 22 Sep 2025 23:24:29 GMT
Subject: [lworld] RFR: 8368099: [lworld] Crash in
 frame::sender_for_compiled_frame while processing JFR sampling request
Message-ID: <5f_oWiY8AeMb7ctAvBmVuE6R182bNGEJhghDQX1U0aY=.f73f5376-2a48-40bb-9f32-814671e47891@github.com>

Reconstructing a synthetic compiled frame when processing a sample request at a poll on return doesn?t work for frames that need stack repair. The stack walking code will read the frame size from the stack, but the memory has already been overwritten by the SafepointBlob frame. See comments in JBS issue for full details.

This patch skips the attempt to create this synthetic frame in case the frame needs stack repair. This fixes the crash but doesn't handle the safepoint bias issue. A more permanent solution will be required for that.

I tested the patch along the fix for 8368002 and verified that Jetty.java doesn?t crash anymore.

Thanks,
Patricio

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

Commit messages:
 - skip frames that need stack repair

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

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

From duke at openjdk.org  Tue Sep 23 01:54:35 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 01:54:35 GMT
Subject: [lworld] RFR: C++ preparation for preview mode
In-Reply-To: <L3bhYrKDM6G1ng184t5UdwPbDK6SJNaTpyTkpfP-wtI=.33fc80bd-0cf9-447d-b0ab-1a608f06c893@github.com>
References: <RLZhZqNVU7eQCErLwoedsIKpdWfFLnNHE0_n9HY2ePk=.76ef953f-7ce6-4be5-b0d5-fb7149179c02@github.com>
 <L3bhYrKDM6G1ng184t5UdwPbDK6SJNaTpyTkpfP-wtI=.33fc80bd-0cf9-447d-b0ab-1a608f06c893@github.com>
Message-ID: <ERxvJk2GLHoh_uanxuqAZUnWvkOk6rMUZGSFiczUBRM=.4f3c5fe8-4cbc-4119-99ed-e8c9eec6fe4a@github.com>

On Mon, 22 Sep 2025 22:26:15 GMT, David Beaumont <duke at openjdk.org> wrote:

>> C++ changes for supporting preview mode *when* preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).
>
> src/java.base/share/native/libjimage/imageFile.hpp line 248:
> 
>> 246:     };
>> 247: 
>> 248:     // Flag masks for the ATTRIBUTE_PREVIEW_FLAGS attribute. Defined so
> 
> As discussed offline, there might be a neater expression for these flags with:
> 
> 
> bit: 1 0
>     [0,0] 0 = normal_entry (only)
>     [0,1] 1 = normal_entry_with_preview_version
>     [1,0] 2 = preview_entry (only)
>     [1,1] 3 = preview_entry_with_normal_version
>        ^-- has other version bit
>      ^---- is preview version bit

After remembering that these flags are also used in packages/xxx locations, where "is this a preview version" makes no conceptual sense, I no longer think it would be a good idea to change the flag definitions.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1609#discussion_r2370800106

From duke at openjdk.org  Tue Sep 23 01:54:37 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 01:54:37 GMT
Subject: [lworld] RFR: C++ preparation for preview mode
In-Reply-To: <RLZhZqNVU7eQCErLwoedsIKpdWfFLnNHE0_n9HY2ePk=.76ef953f-7ce6-4be5-b0d5-fb7149179c02@github.com>
References: <RLZhZqNVU7eQCErLwoedsIKpdWfFLnNHE0_n9HY2ePk=.76ef953f-7ce6-4be5-b0d5-fb7149179c02@github.com>
Message-ID: <OEE31O-J1346NTNzwedXkDn0wpsja5CxLN6uHGASX9g=.e51e8cd4-b739-43c3-b058-4ac1db96e0a5@github.com>

On Mon, 22 Sep 2025 22:21:25 GMT, David Beaumont <duke at openjdk.org> wrote:

> C++ changes for supporting preview mode *when* preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

src/java.base/share/native/libjimage/imageFile.hpp line 253:

> 251:         // Set on a "normal" (non-preview) location if a preview version of
> 252:         // it exists in the same module.
> 253:         FLAGS_HAS_PREVIEW_VERSION = 0x1,

Also set on package directories if any of its entries have preview content.

src/java.base/share/native/libjimage/imageFile.hpp line 256:

> 254:         // Set on all preview locations in "/modules/xxx/META-INF/preview/..."
> 255:         FLAGS_IS_PREVIEW_VERSION = 0x2,
> 256:         // Set on a preview location if no normal (non-preview) version of

Also set on package directories if all its entries are preview only, but the C++ code doesn't need to know that because it's never dealing with those entries.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1609#discussion_r2370805859
PR Review Comment: https://git.openjdk.org/valhalla/pull/1609#discussion_r2370800884

From phubner at openjdk.org  Tue Sep 23 08:23:57 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 23 Sep 2025 08:23:57 GMT
Subject: [lworld] Integrated: 8368371:
 runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java
 timeouts
Message-ID: <M3HlngztnQWuHAQ0l9OdfczSl2CjRNsPO76KW2rdwAo=.b58f220a-8f71-4047-a01e-7f35324da406@github.com>

Hi all,

There's been quite a lot of noise regarding timeout failures in the ConcurrentClassLoadingTest. This patch reduces the iterations.

Tests: 25 repetitions of the test on all platforms.

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

Commit messages:
 - Half iterations.

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

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

From dsimms at openjdk.org  Tue Sep 23 08:23:58 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 23 Sep 2025 08:23:58 GMT
Subject: [lworld] Integrated: 8368371:
 runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java
 timeouts
In-Reply-To: <M3HlngztnQWuHAQ0l9OdfczSl2CjRNsPO76KW2rdwAo=.b58f220a-8f71-4047-a01e-7f35324da406@github.com>
References: <M3HlngztnQWuHAQ0l9OdfczSl2CjRNsPO76KW2rdwAo=.b58f220a-8f71-4047-a01e-7f35324da406@github.com>
Message-ID: <mS3XA8UN272X0k8ILBpAS85pr3bhXQiUva7qWSHTWro=.8865c464-e9ea-410b-bb70-94c2cafc9043@github.com>

On Tue, 23 Sep 2025 07:17:13 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> There's been quite a lot of noise regarding timeout failures in the ConcurrentClassLoadingTest. This patch reduces the iterations.
> 
> Tests: 25 repetitions of the test on all platforms.

LGTM;

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

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1611#pullrequestreview-3256798288

From phubner at openjdk.org  Tue Sep 23 08:23:59 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 23 Sep 2025 08:23:59 GMT
Subject: [lworld] Integrated: 8368371:
 runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java
 timeouts
In-Reply-To: <M3HlngztnQWuHAQ0l9OdfczSl2CjRNsPO76KW2rdwAo=.b58f220a-8f71-4047-a01e-7f35324da406@github.com>
References: <M3HlngztnQWuHAQ0l9OdfczSl2CjRNsPO76KW2rdwAo=.b58f220a-8f71-4047-a01e-7f35324da406@github.com>
Message-ID: <sPdMlSZm17YLVxFgNVDa8uXy2l85sZPYNmKQ2QnvjOs=.5d597e50-a52b-4c25-93fc-e4882d44ec6f@github.com>

On Tue, 23 Sep 2025 07:17:13 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> There's been quite a lot of noise regarding timeout failures in the ConcurrentClassLoadingTest. This patch reduces the iterations.
> 
> Tests: 25 repetitions of the test on all platforms.

This pull request has now been integrated.

Changeset: cb4da36c
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/cb4da36cc95e0448683b6038f9481cc7f030ea40
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8368371: runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java timeouts

Reviewed-by: dsimms

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

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

From dsimms at openjdk.org  Tue Sep 23 09:57:04 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 23 Sep 2025 09:57:04 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <guEtQ3YzHwxl8zjOVl8dRmnc-Np8_oUKzoqgNZpFC0s=.357e8d51-8c1f-4dca-bc29-7b1ee7f5ba54@github.com>

Merge tag 'jdk-26+10' into lworld_merge_jdk_26_10
Added tag jdk-26+10 for changeset 8d73fe91

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

Commit messages:
 - Merge tag 'jdk-26+10' into lworld_merge_jdk_26_10
 - 8358813: JPasswordField identifies spaces in password via delete shortcuts
 - 8364503: gc/g1/TestCodeCacheUnloadDuringConcCycle.java fails because of race printing to stdout
 - 8359690: New test TestCPUTimeSampleThrottling still fails intermittently
 - 8364235: Fix for JDK-8361447 breaks the alignment requirements for GuardedMemory
 - 8334238: Enhance AddLShortcutTest jpackage test
 - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
 - 8364722: Parallel: Move CLDG mark clearing to the end of full GC
 - 8356645: Javac should utilize new ZIP file system read-only access mode
 - 8364540: Apply @Stable to Shared Secrets
 - ... and 76 more: https://git.openjdk.org/valhalla/compare/2c2f4b2b...179c67af

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

Changes: https://git.openjdk.org/valhalla/pull/1612/files
  Stats: 14081 lines in 304 files changed: 9438 ins; 3611 del; 1032 mod
  Patch: https://git.openjdk.org/valhalla/pull/1612.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1612/head:pull/1612

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

From duke at openjdk.org  Tue Sep 23 10:02:26 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 10:02:26 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to ImageReader and
 JRT file-system
Message-ID: <2cUM6ozADNBPjs5mhYVDdo5sSUdV24FP6Gb3sY_Psfk=.e49a8559-8724-4b5c-8826-8fd4d0f01fd8@github.com>

Java changes for supporting preview mode when preview mode resources (with new location flags) are available.

At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).

Compare and review this against https://github.com/openjdk/valhalla/pull/1609.

https://github.com/openjdk/valhalla/pull/1613/files/4e21d5e00ac05d4197e8c617dbabec84ce8748f9..c23b8f25e943000b1aebeaf0755599a9c17b4a91

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

Commit messages:
 - Clarifying flag docs for /packages/xxx case
 - Java ImageReader changes for preview mode
 - C++ preparation for preview mode

Changes: https://git.openjdk.org/valhalla/pull/1613/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1613&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366093
  Stats: 1691 lines in 25 files changed: 1328 ins; 167 del; 196 mod
  Patch: https://git.openjdk.org/valhalla/pull/1613.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1613/head:pull/1613

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

From duke at openjdk.org  Tue Sep 23 10:31:46 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 10:31:46 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to ImageReader
 and JRT file-system [v2]
In-Reply-To: <2cUM6ozADNBPjs5mhYVDdo5sSUdV24FP6Gb3sY_Psfk=.e49a8559-8724-4b5c-8826-8fd4d0f01fd8@github.com>
References: <2cUM6ozADNBPjs5mhYVDdo5sSUdV24FP6Gb3sY_Psfk=.e49a8559-8724-4b5c-8826-8fd4d0f01fd8@github.com>
Message-ID: <jQZCvkr-PovP4Jn1v4cT0_zfXlhD5M2qQCal6kOh_CU=.7b800794-1f8a-4174-93cd-cdeb2ab4cbb0@github.com>

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1609.
> 
> https://github.com/openjdk/valhalla/pull/1613/files/4e21d5e00ac05d4197e8c617dbabec84ce8748f9..c23b8f25e943000b1aebeaf0755599a9c17b4a91

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Add workaround until new image writing code is in

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1613/files
  - new: https://git.openjdk.org/valhalla/pull/1613/files/c23b8f25..41ba71bf

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

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

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

From mgronlun at openjdk.org  Tue Sep 23 11:03:13 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 23 Sep 2025 11:03:13 GMT
Subject: [lworld] RFR: 8368099: [lworld] Crash in
 frame::sender_for_compiled_frame while processing JFR sampling request
In-Reply-To: <5f_oWiY8AeMb7ctAvBmVuE6R182bNGEJhghDQX1U0aY=.f73f5376-2a48-40bb-9f32-814671e47891@github.com>
References: <5f_oWiY8AeMb7ctAvBmVuE6R182bNGEJhghDQX1U0aY=.f73f5376-2a48-40bb-9f32-814671e47891@github.com>
Message-ID: <msOBhDX3Lk0NQW0ev8uGRqajvrXsvivRJlww45MZ_74=.dac77f63-05d4-4d50-ba00-f1d5b855e547@github.com>

On Mon, 22 Sep 2025 22:37:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Reconstructing a synthetic compiled frame when processing a sample request at a poll on return doesn?t work for frames that need stack repair. The stack walking code will read the frame size from the stack, but the memory has already been overwritten by the SafepointBlob frame. See comments in JBS issue for full details.
> 
> This patch skips the attempt to create this synthetic frame in case the frame needs stack repair. This fixes the crash but doesn't handle the safepoint bias issue. A more permanent solution will be required for that.
> 
> I tested the patch along the fix for 8368002 and verified that Jetty.java doesn?t crash anymore.
> 
> Thanks,
> Patricio

Looks good, but we need to revisit this properly.

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

Marked as reviewed by mgronlun (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1610#pullrequestreview-3257390949

From duke at openjdk.org  Tue Sep 23 11:09:20 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 11:09:20 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to ImageReader
 and JRT file-system [v3]
In-Reply-To: <2cUM6ozADNBPjs5mhYVDdo5sSUdV24FP6Gb3sY_Psfk=.e49a8559-8724-4b5c-8826-8fd4d0f01fd8@github.com>
References: <2cUM6ozADNBPjs5mhYVDdo5sSUdV24FP6Gb3sY_Psfk=.e49a8559-8724-4b5c-8826-8fd4d0f01fd8@github.com>
Message-ID: <2-kD2rrliFHes9osTe4hB0yB-ckhssBGRw4ytQ-5QjQ=.f159a93f-8e27-4eaa-8a2f-9a758349d5fa@github.com>

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1609.
> 
> https://github.com/openjdk/valhalla/pull/1613/files/4e21d5e00ac05d4197e8c617dbabec84ce8748f9..c23b8f25e943000b1aebeaf0755599a9c17b4a91

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Word smithing flags definitions.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1613/files
  - new: https://git.openjdk.org/valhalla/pull/1613/files/41ba71bf..a55450f0

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

  Stats: 18 lines in 1 file changed: 9 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/1613.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1613/head:pull/1613

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

From vromero at openjdk.org  Tue Sep 23 11:12:14 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 11:12:14 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue [v2]
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: <4BDBAU4qVxR5X2rzVAmu2LkZs9z5qw3DGrLzGwIkXgA=.0e7da638-879c-42b5-bbf8-cd4900487aa6@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

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/1595/files
  - new: https://git.openjdk.org/valhalla/pull/1595/files/83d2f6ab..59e97476

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

  Stats: 561 lines in 27 files changed: 434 ins; 59 del; 68 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 chagedorn at openjdk.org  Tue Sep 23 11:49:10 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 23 Sep 2025 11:49:10 GMT
Subject: [lworld] RFR: 8367518: TestRedundantLea.java fails in Valhalla
 [v2]
In-Reply-To: <oWqShP2O2xHI5T-kf6gWOj0Z_rK72iwrOypmH590_Bk=.a3a013aa-e97a-44e6-b378-b046bfd64099@github.com>
References: <TesTvna9Hnac4nqILX5rFxHSgHMlXgbC62oEqWd4-rE=.1f8b82f9-d2a6-4755-b893-ca1aedc104f4@github.com>
 <oWqShP2O2xHI5T-kf6gWOj0Z_rK72iwrOypmH590_Bk=.a3a013aa-e97a-44e6-b378-b046bfd64099@github.com>
Message-ID: <TPlmTOuxcpO0rRaegBJOHPs78h69FJVRX6kD2zYeWRo=.211a9c85-db0c-4001-aa5f-5a860cd12c7e@github.com>

On Mon, 22 Sep 2025 12:53:22 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> After merging `TestRedundantLea.java` into valhalla it turned out that the `StringInflate` and `StoreN*` subtests fail. This PR fixes that by bringing over two commits from mainline that fix problems with this test, which already fixes `StringInflate`.
>> 
>> The problem with the `StoreN` cases is that with valhalla C2 does not generate spills that the peephole can remove. To still test removing spills I came up with a new test case specifically for spills.
>> 
>> Testing:
>>  - [x] tier1,tier2 plus some stress testing
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from Christian
>   
>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

Marked as reviewed by chagedorn (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1605#pullrequestreview-3257571762

From dsimms at openjdk.org  Tue Sep 23 11:49:21 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 23 Sep 2025 11:49:21 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <guEtQ3YzHwxl8zjOVl8dRmnc-Np8_oUKzoqgNZpFC0s=.357e8d51-8c1f-4dca-bc29-7b1ee7f5ba54@github.com>
References: <guEtQ3YzHwxl8zjOVl8dRmnc-Np8_oUKzoqgNZpFC0s=.357e8d51-8c1f-4dca-bc29-7b1ee7f5ba54@github.com>
Message-ID: <aBSHDwsirKA0g5RYFgjhvljfk8FCAZXajrfVYP4rtNM=.b1a9bc88-d936-4063-afe6-49b46e2e3c38@github.com>

On Tue, 23 Sep 2025 09:48:27 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-26+10' into lworld_merge_jdk_26_10
> Added tag jdk-26+10 for changeset 8d73fe91

This pull request has now been integrated.

Changeset: 1c40d09b
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1c40d09bf043de1a254810c04ce99c52abc02ff9
Stats:     14081 lines in 304 files changed: 9438 ins; 3611 del; 1032 mod

Merge jdk

Merge jdk-26+10

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

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

From davidalayachew at gmail.com  Tue Sep 23 12:19:40 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 23 Sep 2025 08:19:40 -0400
Subject: Question about Value Classes and inheritance
Message-ID: <CAA9v-_NCpK1016xTJ9KGkSa0RHeG53XaLHK8gLMieFfZmowpGQ@mail.gmail.com>

Hello @valhalla-dev <valhalla-dev at openjdk.java.net>,

I read through JEP 401, and the subsection about subtyping surprised me.

It appears that Abstract Value Classes can permit both Value child classes
and Identity child classes. The example of BigInteger helps explain why.

Ok, but there doesn't seem to be any way to say "only value classes can
extend me!"

Why is that?

And to be clear, I am not bothered by Abstract Value Classes permitting
Identity children, that's fine. I'm moreso confused by lack of ability to
say "only value children".

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250923/0e0b5da0/attachment.htm>

From mcimadamore at openjdk.org  Tue Sep 23 12:28:42 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 23 Sep 2025 12:28:42 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue [v2]
In-Reply-To: <4BDBAU4qVxR5X2rzVAmu2LkZs9z5qw3DGrLzGwIkXgA=.0e7da638-879c-42b5-bbf8-cd4900487aa6@github.com>
References: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
 <4BDBAU4qVxR5X2rzVAmu2LkZs9z5qw3DGrLzGwIkXgA=.0e7da638-879c-42b5-bbf8-cd4900487aa6@github.com>
Message-ID: <7WMulWmaYObXpVMwLjnUNn_pFJxaDcUgGF3KJ_OjJyY=.d4b93d4a-05b5-4ad5-b158-4e83b2ada713@github.com>

On Tue, 23 Sep 2025 11:12:14 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
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

test/langtools/tools/javac/SuperInit/EarlyAssignments.out line 22:

> 20: EarlyAssignments.java:170:18: compiler.err.cant.ref.before.ctor.called: EarlyAssignments.Inner8
> 21: EarlyAssignments.java:179:17: compiler.err.cant.ref.before.ctor.called: x
> 22: 21 errors

Why the difference here? The missing error seems to be this:

EarlyAssignments.java:157:13: compiler.err.cant.assign.val.to.var: final, x

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2372147786

From mcimadamore at openjdk.org  Tue Sep 23 12:28:42 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 23 Sep 2025 12:28:42 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue [v2]
In-Reply-To: <7WMulWmaYObXpVMwLjnUNn_pFJxaDcUgGF3KJ_OjJyY=.d4b93d4a-05b5-4ad5-b158-4e83b2ada713@github.com>
References: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
 <4BDBAU4qVxR5X2rzVAmu2LkZs9z5qw3DGrLzGwIkXgA=.0e7da638-879c-42b5-bbf8-cd4900487aa6@github.com>
 <7WMulWmaYObXpVMwLjnUNn_pFJxaDcUgGF3KJ_OjJyY=.d4b93d4a-05b5-4ad5-b158-4e83b2ada713@github.com>
Message-ID: <7cuvDlpnrp75yor2jtMHru3i0rUxXBKPBfao6zWJ4BA=.9fa996d1-f759-4f97-a1c9-036d368c5cf3@github.com>

On Tue, 23 Sep 2025 12:25:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> test/langtools/tools/javac/SuperInit/EarlyAssignments.out line 22:
> 
>> 20: EarlyAssignments.java:170:18: compiler.err.cant.ref.before.ctor.called: EarlyAssignments.Inner8
>> 21: EarlyAssignments.java:179:17: compiler.err.cant.ref.before.ctor.called: x
>> 22: 21 errors
> 
> Why the difference here? The missing error seems to be this:
> 
> EarlyAssignments.java:157:13: compiler.err.cant.assign.val.to.var: final, x

Ok, I see the test case has been removed -- is that deliberate?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2372149330

From forax at univ-mlv.fr  Tue Sep 23 12:31:24 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 23 Sep 2025 14:31:24 +0200 (CEST)
Subject: Question about Value Classes and inheritance
In-Reply-To: <CAA9v-_NCpK1016xTJ9KGkSa0RHeG53XaLHK8gLMieFfZmowpGQ@mail.gmail.com>
References: <CAA9v-_NCpK1016xTJ9KGkSa0RHeG53XaLHK8gLMieFfZmowpGQ@mail.gmail.com>
Message-ID: <511933718.34976748.1758630684356.JavaMail.zimbra@univ-eiffel.fr>

> From: "David Alayachew" <davidalayachew at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Sent: Tuesday, September 23, 2025 2:19:40 PM
> Subject: Question about Value Classes and inheritance

> Hello [ mailto:valhalla-dev at openjdk.java.net | @valhalla-dev ] ,

> I read through JEP 401, and the subsection about subtyping surprised me.

> It appears that Abstract Value Classes can permit both Value child classes and
> Identity child classes. The example of BigInteger helps explain why.

> Ok, but there doesn't seem to be any way to say "only value classes can extend
> me!"

> Why is that?

> And to be clear, I am not bothered by Abstract Value Classes permitting Identity
> children, that's fine.

I'm glad this is fine by you because it's important for backward compatibility, it means that you can declare an existing abstract class has "value enable", without requiring sub-classes to be changed. 

> I'm moreso confused by lack of ability to say "only value children".

Declaring a class has a value class is really close to be an implementation detail (it mainly depends on if your code abuse of == or not), 
so why do you want such ability ? 

> Thank you for your time and consideration.
> David Alayachew

regards, 
R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250923/a9a77fce/attachment.htm>

From mcimadamore at openjdk.org  Tue Sep 23 12:46:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 23 Sep 2025 12:46:01 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue [v2]
In-Reply-To: <4BDBAU4qVxR5X2rzVAmu2LkZs9z5qw3DGrLzGwIkXgA=.0e7da638-879c-42b5-bbf8-cd4900487aa6@github.com>
References: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
 <4BDBAU4qVxR5X2rzVAmu2LkZs9z5qw3DGrLzGwIkXgA=.0e7da638-879c-42b5-bbf8-cd4900487aa6@github.com>
Message-ID: <DXaV0lKXtsfJbGRFclKc11rnhv6CqUwp7bHuyIgPGOE=.36e186a1-4cb5-41f4-a14c-cc1e4432178c@github.com>

On Tue, 23 Sep 2025 11:12:14 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
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

New test looks good -- thanks.
Using a custom attr to always move the `super` call is a clever testing approach ;-)

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

Marked as reviewed by mcimadamore (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1595#pullrequestreview-3257821118

From chagedorn at openjdk.org  Tue Sep 23 13:05:55 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 23 Sep 2025 13:05:55 GMT
Subject: [lworld] Integrated: ProblemList MemoryAccessProviderTest.java and
 TestHotSpotResolvedJavaField.java
In-Reply-To: <OTZ_St_QtmZlJcjcHmEfUF8jJs6CZUb_7h_dfGV27w4=.2a043bbc-3cb1-438c-a7fa-885e76bd8446@github.com>
References: <OTZ_St_QtmZlJcjcHmEfUF8jJs6CZUb_7h_dfGV27w4=.2a043bbc-3cb1-438c-a7fa-885e76bd8446@github.com>
Message-ID: <74qebdZDR_BUVRpn8p41EJ5nTnsTugyw3RY2_7y9BtQ=.972ee07a-9217-4d0b-b955-957fedd48b85@github.com>

On Tue, 23 Sep 2025 12:43:51 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> [JDK-8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution"](https://bugs.openjdk.org/browse/JDK-8350208)
> 
> First done in #1532 but it seems it was reverted by accident during the merge of jdk-26+5, probably during conflict resolution:
> 
> https://github.com/openjdk/valhalla/commit/09637e0e5970fc79f8edf7c458cd1a8e66f30463#diff-5dd1b912c2b1268bbd9aba3669bdda0abd4bcdcad523470959238b02bb1bcfd7
> 
> The valhalla side of it is tracked here: [JDK-8365989: [lworld] Un-ProblemList MemoryAccessProviderTest.java and TestHotSpotResolvedJavaField.java once JDK-8350208 is solved in mainline](https://bugs.openjdk.org/browse/JDK-8365989)

Looks good!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1614#pullrequestreview-3257886506

From mchevalier at openjdk.org  Tue Sep 23 13:05:54 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 23 Sep 2025 13:05:54 GMT
Subject: [lworld] Integrated: ProblemList MemoryAccessProviderTest.java and
 TestHotSpotResolvedJavaField.java
Message-ID: <OTZ_St_QtmZlJcjcHmEfUF8jJs6CZUb_7h_dfGV27w4=.2a043bbc-3cb1-438c-a7fa-885e76bd8446@github.com>

[JDK-8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution"](https://bugs.openjdk.org/browse/JDK-8350208)

First done in #1532 but it seems it was reverted by accident during the merge of jdk-26+5, probably during conflict resolution:

https://github.com/openjdk/valhalla/commit/09637e0e5970fc79f8edf7c458cd1a8e66f30463#diff-5dd1b912c2b1268bbd9aba3669bdda0abd4bcdcad523470959238b02bb1bcfd7

The valhalla side of it is tracked here: [JDK-8365989: [lworld] Un-ProblemList MemoryAccessProviderTest.java and TestHotSpotResolvedJavaField.java once JDK-8350208 is solved in mainline](https://bugs.openjdk.org/browse/JDK-8365989)

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

Commit messages:
 - ProblemList-8350208

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

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

From mchevalier at openjdk.org  Tue Sep 23 13:05:55 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 23 Sep 2025 13:05:55 GMT
Subject: [lworld] Integrated: ProblemList MemoryAccessProviderTest.java and
 TestHotSpotResolvedJavaField.java
In-Reply-To: <OTZ_St_QtmZlJcjcHmEfUF8jJs6CZUb_7h_dfGV27w4=.2a043bbc-3cb1-438c-a7fa-885e76bd8446@github.com>
References: <OTZ_St_QtmZlJcjcHmEfUF8jJs6CZUb_7h_dfGV27w4=.2a043bbc-3cb1-438c-a7fa-885e76bd8446@github.com>
Message-ID: <vT1USgTzyyr0CpkEhYLgJRkHfCo20XrXgiy4EnOYZzc=.da1db13b-cf48-4ba6-ab14-f00cc0e9151e@github.com>

On Tue, 23 Sep 2025 12:43:51 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> [JDK-8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution"](https://bugs.openjdk.org/browse/JDK-8350208)
> 
> First done in #1532 but it seems it was reverted by accident during the merge of jdk-26+5, probably during conflict resolution:
> 
> https://github.com/openjdk/valhalla/commit/09637e0e5970fc79f8edf7c458cd1a8e66f30463#diff-5dd1b912c2b1268bbd9aba3669bdda0abd4bcdcad523470959238b02bb1bcfd7
> 
> The valhalla side of it is tracked here: [JDK-8365989: [lworld] Un-ProblemList MemoryAccessProviderTest.java and TestHotSpotResolvedJavaField.java once JDK-8350208 is solved in mainline](https://bugs.openjdk.org/browse/JDK-8365989)

This pull request has now been integrated.

Changeset: 4248753c
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4248753cd67362b889606de455208a8c6f30b9c5
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

ProblemList MemoryAccessProviderTest.java and TestHotSpotResolvedJavaField.java

Reviewed-by: chagedorn

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

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

From vromero at openjdk.org  Tue Sep 23 13:06:49 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 13:06:49 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue [v2]
In-Reply-To: <7cuvDlpnrp75yor2jtMHru3i0rUxXBKPBfao6zWJ4BA=.9fa996d1-f759-4f97-a1c9-036d368c5cf3@github.com>
References: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
 <4BDBAU4qVxR5X2rzVAmu2LkZs9z5qw3DGrLzGwIkXgA=.0e7da638-879c-42b5-bbf8-cd4900487aa6@github.com>
 <7WMulWmaYObXpVMwLjnUNn_pFJxaDcUgGF3KJ_OjJyY=.d4b93d4a-05b5-4ad5-b158-4e83b2ada713@github.com>
 <7cuvDlpnrp75yor2jtMHru3i0rUxXBKPBfao6zWJ4BA=.9fa996d1-f759-4f97-a1c9-036d368c5cf3@github.com>
Message-ID: <b3cFtjOD2KXLKJeKCO-J1Mc6KfVuJgX4Q0SZK3rnlao=.f0344c83-7395-4510-859c-ea58c0f8c321@github.com>

On Tue, 23 Sep 2025 12:25:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> test/langtools/tools/javac/SuperInit/EarlyAssignments.out line 22:
>> 
>>> 20: EarlyAssignments.java:170:18: compiler.err.cant.ref.before.ctor.called: EarlyAssignments.Inner8
>>> 21: EarlyAssignments.java:179:17: compiler.err.cant.ref.before.ctor.called: x
>>> 22: 21 errors
>> 
>> Why the difference here? The missing error seems to be this:
>> 
>> EarlyAssignments.java:157:13: compiler.err.cant.assign.val.to.var: final, x
>
> Ok, I see the test case has been removed -- is that deliberate?

I think it was generating noise on the warnings side, I will add it back if possible

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2372263035

From mhaessig at openjdk.org  Tue Sep 23 13:33:37 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Tue, 23 Sep 2025 13:33:37 GMT
Subject: [lworld] RFR: 8367518: TestRedundantLea.java fails in Valhalla
 [v2]
In-Reply-To: <oWqShP2O2xHI5T-kf6gWOj0Z_rK72iwrOypmH590_Bk=.a3a013aa-e97a-44e6-b378-b046bfd64099@github.com>
References: <TesTvna9Hnac4nqILX5rFxHSgHMlXgbC62oEqWd4-rE=.1f8b82f9-d2a6-4755-b893-ca1aedc104f4@github.com>
 <oWqShP2O2xHI5T-kf6gWOj0Z_rK72iwrOypmH590_Bk=.a3a013aa-e97a-44e6-b378-b046bfd64099@github.com>
Message-ID: <GnmzfENBukX5jM95-O8Ky3s8N1BTHpcWfcxpIYkbfxo=.7bfb7fee-d838-46e9-a828-1f1538b88b74@github.com>

On Mon, 22 Sep 2025 12:53:22 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> After merging `TestRedundantLea.java` into valhalla it turned out that the `StringInflate` and `StoreN*` subtests fail. This PR fixes that by bringing over two commits from mainline that fix problems with this test, which already fixes `StringInflate`.
>> 
>> The problem with the `StoreN` cases is that with valhalla C2 does not generate spills that the peephole can remove. To still test removing spills I came up with a new test case specifically for spills.
>> 
>> Testing:
>>  - [x] tier1,tier2 plus some stress testing
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from Christian
>   
>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

Thank you for reviewing, Christian!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1605#issuecomment-3324027142

From duke at openjdk.org  Tue Sep 23 13:33:37 2025
From: duke at openjdk.org (duke)
Date: Tue, 23 Sep 2025 13:33:37 GMT
Subject: [lworld] RFR: 8367518: TestRedundantLea.java fails in Valhalla
 [v2]
In-Reply-To: <oWqShP2O2xHI5T-kf6gWOj0Z_rK72iwrOypmH590_Bk=.a3a013aa-e97a-44e6-b378-b046bfd64099@github.com>
References: <TesTvna9Hnac4nqILX5rFxHSgHMlXgbC62oEqWd4-rE=.1f8b82f9-d2a6-4755-b893-ca1aedc104f4@github.com>
 <oWqShP2O2xHI5T-kf6gWOj0Z_rK72iwrOypmH590_Bk=.a3a013aa-e97a-44e6-b378-b046bfd64099@github.com>
Message-ID: <TIdBgqW5zuaobDMfXlveolwNgpfQ-3AAZImh3sdrjFk=.349ecd2b-33e9-43e8-872e-4143cb38481e@github.com>

On Mon, 22 Sep 2025 12:53:22 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> After merging `TestRedundantLea.java` into valhalla it turned out that the `StringInflate` and `StoreN*` subtests fail. This PR fixes that by bringing over two commits from mainline that fix problems with this test, which already fixes `StringInflate`.
>> 
>> The problem with the `StoreN` cases is that with valhalla C2 does not generate spills that the peephole can remove. To still test removing spills I came up with a new test case specifically for spills.
>> 
>> Testing:
>>  - [x] tier1,tier2 plus some stress testing
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from Christian
>   
>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

@mhaessig 
Your change (at version 10670b68d2d45f8c06df4b8a7bf81f1ee52cd610) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1605#issuecomment-3324035445

From brian.goetz at oracle.com  Tue Sep 23 13:33:46 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 23 Sep 2025 13:33:46 +0000
Subject: Question about Value Classes and inheritance
In-Reply-To: <CAA9v-_NCpK1016xTJ9KGkSa0RHeG53XaLHK8gLMieFfZmowpGQ@mail.gmail.com>
References: <CAA9v-_NCpK1016xTJ9KGkSa0RHeG53XaLHK8gLMieFfZmowpGQ@mail.gmail.com>
Message-ID: <BD6BA99E-194F-4205-B4ED-D158D0CFF3EA@oracle.com>

Ok, but there doesn't seem to be any way to say "only value classes can extend me!?

At some level, this is a matter of taste and return-on-complexity.  Obviously this is not _needed_, but some programmers are clearly comforted by the ability to capture this intent.  Of course, adding such restriction adds complexity at every layer; it needs a syntactic expression, it needs a clasfile representation, it needs static type checking, it needs dynamic enforcement, it needs reflection, etc.  So the first question is: does the incremental expressiveness justify the incremental complexity?

But more importantly, as Remi points out, seemingly harmless ?intent capturing? things at the source level can turn into unexpected difficulties for longer term issues such as migration compatibility.  We saw a similar example of this in Java 8, where people asked ?why can?t I make a default method final?, but then when you show them the impossible problems this creates for subclasses, they change the subject.  Foreclosing on possibilities like this, that are often ?over the maintenance horizon?, are often ?shallowly sensible? but make the ecosystem brittle.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250923/51318c07/attachment.htm>

From davidalayachew at gmail.com  Tue Sep 23 13:39:04 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 23 Sep 2025 09:39:04 -0400
Subject: Question about Value Classes and inheritance
In-Reply-To: <BD6BA99E-194F-4205-B4ED-D158D0CFF3EA@oracle.com>
References: <CAA9v-_NCpK1016xTJ9KGkSa0RHeG53XaLHK8gLMieFfZmowpGQ@mail.gmail.com>
 <BD6BA99E-194F-4205-B4ED-D158D0CFF3EA@oracle.com>
Message-ID: <CAA9v-_OjJbu1cXPTNpmAW4agQ+vZGLuA6WsTD0tj48MLYRPmYg@mail.gmail.com>

Thank you both. So the answer boils down to, not enough realized value for
the effort involved. More specifically, it may foreclose on other things
while not really giving us much at all. Makes sense, and that's fair.




On Tue, Sep 23, 2025, 8:31?AM Remi Forax <forax at univ-mlv.fr> wrote:



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

*From: *"David Alayachew" <davidalayachew at gmail.com>
*To: *"valhalla-dev" <valhalla-dev at openjdk.java.net>
*Sent: *Tuesday, September 23, 2025 2:19:40 PM
*Subject: *Question about Value Classes and inheritance

Hello @valhalla-dev <valhalla-dev at openjdk.java.net>,

I read through JEP 401, and the subsection about subtyping surprised me.

It appears that Abstract Value Classes can permit both Value child classes
and Identity child classes. The example of BigInteger helps explain why.

Ok, but there doesn't seem to be any way to say "only value classes can
extend me!"

Why is that?

And to be clear, I am not bothered by Abstract Value Classes permitting
Identity children, that's fine.


I'm glad this is fine by you because it's important for backward
compatibility, it means that you can declare an existing abstract class has
"value enable", without requiring sub-classes to be changed.

I'm moreso confused by lack of ability to say "only value children".


Declaring a class has a value class is really close to be an implementation
detail (it mainly depends on if your code abuse of == or not),
so why do you want such ability ?



Thank you for your time and consideration.
David Alayachew


regards,
R?mi


On Tue, Sep 23, 2025, 9:33?AM Brian Goetz <brian.goetz at oracle.com> wrote:

> Ok, but there doesn't seem to be any way to say "only value classes can
> extend me!?
>
>
> At some level, this is a matter of taste and return-on-complexity.
> Obviously this is not _needed_, but some programmers are clearly comforted
> by the ability to capture this intent.  Of course, adding such restriction
> adds complexity at every layer; it needs a syntactic expression, it needs a
> clasfile representation, it needs static type checking, it needs dynamic
> enforcement, it needs reflection, etc.  So the first question is: does the
> incremental expressiveness justify the incremental complexity?
>
> But more importantly, as Remi points out, seemingly harmless ?intent
> capturing? things at the source level can turn into unexpected difficulties
> for longer term issues such as migration compatibility.  We saw a similar
> example of this in Java 8, where people asked ?why can?t I make a default
> method final?, but then when you show them the impossible problems this
> creates for subclasses, they change the subject.  Foreclosing on
> possibilities like this, that are often ?over the maintenance horizon?, are
> often ?shallowly sensible? but make the ecosystem brittle.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250923/1d85feef/attachment-0001.htm>

From davidalayachew at gmail.com  Tue Sep 23 13:50:04 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 23 Sep 2025 09:50:04 -0400
Subject: Question about Value Classes and inheritance
In-Reply-To: <511933718.34976748.1758630684356.JavaMail.zimbra@univ-eiffel.fr>
References: <CAA9v-_NCpK1016xTJ9KGkSa0RHeG53XaLHK8gLMieFfZmowpGQ@mail.gmail.com>
 <511933718.34976748.1758630684356.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAA9v-_PTZ_=LXrEYTGmqrYYqP7=TCCpsWJJOZWmbtFj_OKWm8w@mail.gmail.com>

To answer your question specifically R?mi, I figured this would be useful
to prevent things like misuse. For example, the JEP shows how BigInteger
can't be a value class due to its internal use of mutability. Well,
something like enforcing value classes might have prevented that. Or maybe
not, I am ignorant about that example specifically.

But hopefully you see my point? It feels like there a lot of validation
opportunities being left on the table. Value classes aren't just faster,
they are safer. So, being able to assert that safety for all child classes
seems nice.

Or maybe I am wrong, and Value classes aren't inherently safer. Finality
feels safe to me, and finality by default feels safer. Idk.

Truthfully, I'm operating more on feelings here than genuine experience.
I'll have something more concrete (or see where I'm wrong) to say once the
new EA comes out.

On Tue, Sep 23, 2025, 8:31?AM Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"David Alayachew" <davidalayachew at gmail.com>
> *To: *"valhalla-dev" <valhalla-dev at openjdk.java.net>
> *Sent: *Tuesday, September 23, 2025 2:19:40 PM
> *Subject: *Question about Value Classes and inheritance
>
> Hello @valhalla-dev <valhalla-dev at openjdk.java.net>,
>
> I read through JEP 401, and the subsection about subtyping surprised me.
>
> It appears that Abstract Value Classes can permit both Value child classes
> and Identity child classes. The example of BigInteger helps explain why.
>
> Ok, but there doesn't seem to be any way to say "only value classes can
> extend me!"
>
> Why is that?
>
> And to be clear, I am not bothered by Abstract Value Classes permitting
> Identity children, that's fine.
>
>
> I'm glad this is fine by you because it's important for backward
> compatibility, it means that you can declare an existing abstract class has
> "value enable", without requiring sub-classes to be changed.
>
> I'm moreso confused by lack of ability to say "only value children".
>
>
> Declaring a class has a value class is really close to be an
> implementation detail (it mainly depends on if your code abuse of == or
> not),
> so why do you want such ability ?
>
>
>
> Thank you for your time and consideration.
> David Alayachew
>
>
> regards,
> R?mi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250923/64a4c18d/attachment.htm>

From duke at openjdk.org  Tue Sep 23 13:54:17 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 13:54:17 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode
Message-ID: <E3ax5W5RuMGcN8UTH4h-GS_gMXKkAlCJQfr8IQmUi2Y=.f4fe9da8-a00d-4d72-8859-b93f1d35ded7@github.com>

Adds support for writing preview related flags into jimage files.

Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".

Specific issues include:
1. Supporting preview-only resources without forcing a double lookup on everything.
2. Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
3. Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).

The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.

To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.

Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.

This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

Compare and review this against https://github.com/openjdk/valhalla/pull/1613.

https://github.com/openjdk/valhalla/pull/1615/commits/28eae40aa9a3f8520519d79d7749b5a4b3511609

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

Commit messages:
 - jimage writer changes to support preview mode.
 - Word smithing flags definitions.
 - [[AUTOMATIC FORMATTING]]
 - Add workaround until new image writing code is in
 - Clarifying flag docs for /packages/xxx case
 - Java ImageReader changes for preview mode
 - C++ preparation for preview mode

Changes: https://git.openjdk.org/valhalla/pull/1615/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1615&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368467
  Stats: 3749 lines in 34 files changed: 2082 ins; 387 del; 1280 mod
  Patch: https://git.openjdk.org/valhalla/pull/1615.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1615/head:pull/1615

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

From vromero at openjdk.org  Tue Sep 23 15:14:42 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 15:14:42 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue [v3]
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: <kbXliW4Tq8YNsICEiHmrpgPY3aNgh8zT2E5hpV8Y0Uo=.b6684e8c-c70a-48a2-a846-3919cd93936f@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

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/1595/files
  - new: https://git.openjdk.org/valhalla/pull/1595/files/59e97476..19031778

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

  Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 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 vromero at openjdk.org  Tue Sep 23 15:14:43 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 15:14:43 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue [v2]
In-Reply-To: <b3cFtjOD2KXLKJeKCO-J1Mc6KfVuJgX4Q0SZK3rnlao=.f0344c83-7395-4510-859c-ea58c0f8c321@github.com>
References: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
 <4BDBAU4qVxR5X2rzVAmu2LkZs9z5qw3DGrLzGwIkXgA=.0e7da638-879c-42b5-bbf8-cd4900487aa6@github.com>
 <7WMulWmaYObXpVMwLjnUNn_pFJxaDcUgGF3KJ_OjJyY=.d4b93d4a-05b5-4ad5-b158-4e83b2ada713@github.com>
 <7cuvDlpnrp75yor2jtMHru3i0rUxXBKPBfao6zWJ4BA=.9fa996d1-f759-4f97-a1c9-036d368c5cf3@github.com>
 <b3cFtjOD2KXLKJeKCO-J1Mc6KfVuJgX4Q0SZK3rnlao=.f0344c83-7395-4510-859c-ea58c0f8c321@github.com>
Message-ID: <fohWgktk8DRVn2ewAtEouxKG_qszd2o35_LXwnrTx0I=.a1d5aa91-49b7-41f2-a663-d7be6730efe3@github.com>

On Tue, 23 Sep 2025 13:04:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Ok, I see the test case has been removed -- is that deliberate?
>
> I think it was generating noise on the warnings side, I will add it back if possible

I added the test case back, but I'm ignoring it in the warnings framework

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1595#discussion_r2372658614

From vromero at openjdk.org  Tue Sep 23 15:20:20 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 15:20:20 GMT
Subject: [lworld] Integrated: 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: <1ys9QzcGNznVcCdAcwVqG9f43gDkAG1S6apvBEZWDlQ=.28189943-ca92-4719-b92f-902db158e98d@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

This pull request has now been integrated.

Changeset: 5d7a2510
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5d7a251023b705754e8845ca52e94c4c45ab983f
Stats:     594 lines in 33 files changed: 507 ins; 9 del; 78 mod

8367698: [lworld] New lint category for code that would not be allowed in the prologue

Reviewed-by: mcimadamore

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

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

From vromero at openjdk.org  Tue Sep 23 15:20:18 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 15:20:18 GMT
Subject: [lworld] RFR: 8367698: [lworld] New lint category for code that
 would not be allowed in the prologue [v3]
In-Reply-To: <kbXliW4Tq8YNsICEiHmrpgPY3aNgh8zT2E5hpV8Y0Uo=.b6684e8c-c70a-48a2-a846-3919cd93936f@github.com>
References: <MW_hi28Apq0XW1VsbxOrWnV9T8OL9g_mHEJxECz7Jvo=.88afae76-0906-428e-b7c9-3f66c0facd5f@github.com>
 <kbXliW4Tq8YNsICEiHmrpgPY3aNgh8zT2E5hpV8Y0Uo=.b6684e8c-c70a-48a2-a846-3919cd93936f@github.com>
Message-ID: <T0-e2zngpuqYTCKCzTyrFQt8X0JHr5jNB9vNTSC0cxU=.2f996231-c8be-4831-9ca1-36d23c1dca02@github.com>

On Tue, 23 Sep 2025 15:14:42 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
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

thanks for the review

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

PR Comment: https://git.openjdk.org/valhalla/pull/1595#issuecomment-3324471669

From chen.l.liang at oracle.com  Tue Sep 23 16:12:45 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Tue, 23 Sep 2025 16:12:45 +0000
Subject: Question about Value Classes and inheritance
In-Reply-To: <CAA9v-_PTZ_=LXrEYTGmqrYYqP7=TCCpsWJJOZWmbtFj_OKWm8w@mail.gmail.com>
References: <CAA9v-_NCpK1016xTJ9KGkSa0RHeG53XaLHK8gLMieFfZmowpGQ@mail.gmail.com>
 <511933718.34976748.1758630684356.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PTZ_=LXrEYTGmqrYYqP7=TCCpsWJJOZWmbtFj_OKWm8w@mail.gmail.com>
Message-ID: <SJ2PR10MB76695519B1E305D29D81AB84A21DA@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi David,
In the value objects world, we can think of identity as an extra field on an object that is distinct for every object creation. Due to the uniqueness of this field, we can have shortcuts for hashCode/== that is still compliant but much simpler.
The proposal to block identity subtypes for abstract value types would be equivalent to blocking subtypes from declaring particular types of fields or implementing particular interfaces (all interfaces are now abstract value, too).

If you want to ensure safety for abstract value classes, sealed modifier is your friend - they ensure an AVC only has particular subtypes and might be optimized to union types by JVM implementations.
Otherwise, if a field allows arbitrary value subtypes, they still must be stored as references just like for identity objects. In this case, allowing identity subtypes has little performance impact.

Regarding the perceived "lack of safety" for identity classes, I would argue it is not associated with identity, but with the mutable fields enabled by identity.
In fact, in the investigations of heap-flattened value objects and var handles, we find that referring to large value objects as reference pointers is the best way to ensure volatility - because pointers are small enough to be updated atomically.

Feel free to ask further if you have more overview questions.

Regards,
Chen
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Tuesday, September 23, 2025 8:50 AM
To: Remi Forax <forax at univ-mlv.fr>
Cc: valhalla-dev <valhalla-dev at openjdk.java.net>
Subject: Re: Question about Value Classes and inheritance

To answer your question specifically R?mi, I figured this would be useful to prevent things like misuse. For example, the JEP shows how BigInteger can't be a value class due to its internal use of mutability. Well, something like enforcing value classes might have prevented that. Or maybe not, I am ignorant about that example specifically.

But hopefully you see my point? It feels like there a lot of validation opportunities being left on the table. Value classes aren't just faster, they are safer. So, being able to assert that safety for all child classes seems nice.

Or maybe I am wrong, and Value classes aren't inherently safer. Finality feels safe to me, and finality by default feels safer. Idk.

Truthfully, I'm operating more on feelings here than genuine experience. I'll have something more concrete (or see where I'm wrong) to say once the new EA comes out.

On Tue, Sep 23, 2025, 8:31?AM Remi Forax <forax at univ-mlv.fr<mailto:forax at univ-mlv.fr>> wrote:


________________________________
From: "David Alayachew" <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
To: "valhalla-dev" <valhalla-dev at openjdk.java.net<mailto:valhalla-dev at openjdk.java.net>>
Sent: Tuesday, September 23, 2025 2:19:40 PM
Subject: Question about Value Classes and inheritance
Hello @valhalla-dev<mailto:valhalla-dev at openjdk.java.net>,

I read through JEP 401, and the subsection about subtyping surprised me.

It appears that Abstract Value Classes can permit both Value child classes and Identity child classes. The example of BigInteger helps explain why.

Ok, but there doesn't seem to be any way to say "only value classes can extend me!"

Why is that?

And to be clear, I am not bothered by Abstract Value Classes permitting Identity children, that's fine.

I'm glad this is fine by you because it's important for backward compatibility, it means that you can declare an existing abstract class has "value enable", without requiring sub-classes to be changed.

I'm moreso confused by lack of ability to say "only value children".

Declaring a class has a value class is really close to be an implementation detail (it mainly depends on if your code abuse of == or not),
so why do you want such ability ?



Thank you for your time and consideration.
David Alayachew

regards,
R?mi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250923/eb75b58c/attachment-0001.htm>

From duke at openjdk.org  Tue Sep 23 16:12:00 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 16:12:00 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at make
 time
Message-ID: <ZHVuptIskS6NxDNaa0_NILZgUXONCPYlQJKvPvG5bTo=.abe7dacd-31c8-4c58-a847-519610bdaef4@github.com>

Copies valuetype classes for each module into corresponding "<module>/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.

There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).

To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".

This PR is stacked on top of https://github.com/openjdk/valhalla/pull/1615 and only contains the single commit:
https://github.com/openjdk/valhalla/commit/d5941080fc1983fd436fc60962630f27b561a9b3

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

Commit messages:
 - Copy value classes into preview directories for inclusion in jimage
 - [[AUTOMATIC FORMATTING]]
 - Remove TODOs now jimage version is bumped
 - jimage writer changes to support preview mode.
 - Word smithing flags definitions.
 - [[AUTOMATIC FORMATTING]]
 - Add workaround until new image writing code is in
 - Clarifying flag docs for /packages/xxx case
 - Java ImageReader changes for preview mode
 - C++ preparation for preview mode

Changes: https://git.openjdk.org/valhalla/pull/1616/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1616&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368475
  Stats: 3822 lines in 35 files changed: 2103 ins; 388 del; 1331 mod
  Patch: https://git.openjdk.org/valhalla/pull/1616.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1616/head:pull/1616

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

From vromero at openjdk.org  Tue Sep 23 18:06:35 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 18:06:35 GMT
Subject: [lworld] Integrated: 8368076: [lworld]
 tools/javac/ObjectEarlyContext/T8361481.java bogus 'before supertype
 constructor' error
Message-ID: <i2UWGZYn83Gwabytt7d-yFhvDrQp2gBCcy8eQ7hLcHI=.2b61d64f-01d9-458e-ba1a-2c171cdc014c@github.com>

fixing bug found during merges. The issue was not provoked by the merge, basically we need to make a check more general, see inlined comment

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

Commit messages:
 - 8368076: [lworld] tools/javac/ObjectEarlyContext/T8361481.java bogus 'before supertype constructor' error

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

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

From vromero at openjdk.org  Tue Sep 23 18:06:37 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 18:06:37 GMT
Subject: [lworld] Integrated: 8368076: [lworld]
 tools/javac/ObjectEarlyContext/T8361481.java bogus 'before supertype
 constructor' error
In-Reply-To: <i2UWGZYn83Gwabytt7d-yFhvDrQp2gBCcy8eQ7hLcHI=.2b61d64f-01d9-458e-ba1a-2c171cdc014c@github.com>
References: <i2UWGZYn83Gwabytt7d-yFhvDrQp2gBCcy8eQ7hLcHI=.2b61d64f-01d9-458e-ba1a-2c171cdc014c@github.com>
Message-ID: <NcdM8p-VRdIvhY8PcIesnhWiE1jvaB9AE6N9MXRmLtw=.73300f24-b13f-4d09-8e1c-d09588b43a26@github.com>

On Tue, 23 Sep 2025 17:56:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> fixing bug found during merges. The issue was not provoked by the merge, basically we need to make a check more general, see inlined comment

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

> 1237:                 // Attribute method body.
> 1238:                 attribStat(tree.body, localEnv);
> 1239:                 if (localEnv.info.ctorPrologue) {

as this check is more general now we should be covered for future conditions set into the `env.info.ctorPrologue` field. In this case we need to check that we are not analyzing Object's constructor

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1617#discussion_r2373080053

From vromero at openjdk.org  Tue Sep 23 18:06:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 18:06:38 GMT
Subject: [lworld] Integrated: 8368076: [lworld]
 tools/javac/ObjectEarlyContext/T8361481.java bogus 'before supertype
 constructor' error
In-Reply-To: <i2UWGZYn83Gwabytt7d-yFhvDrQp2gBCcy8eQ7hLcHI=.2b61d64f-01d9-458e-ba1a-2c171cdc014c@github.com>
References: <i2UWGZYn83Gwabytt7d-yFhvDrQp2gBCcy8eQ7hLcHI=.2b61d64f-01d9-458e-ba1a-2c171cdc014c@github.com>
Message-ID: <tA0_p96EfI16jpAraBxd21TDoUcXn7xPvtqzSMkpSMQ=.a67552bb-d4d5-477b-845e-927b5bcc4618@github.com>

On Tue, 23 Sep 2025 17:56:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> fixing bug found during merges. The issue was not provoked by the merge, basically we need to make a check more general, see inlined comment

This pull request has now been integrated.

Changeset: 478e0b58
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/478e0b586bd4ccd983600c307a6039e510164f4d
Stats:     2 lines in 2 files changed: 0 ins; 1 del; 1 mod

8368076: [lworld] tools/javac/ObjectEarlyContext/T8361481.java bogus 'before supertype constructor' error

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

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

From duke at openjdk.org  Tue Sep 23 18:56:46 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 18:56:46 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v2]
In-Reply-To: <E3ax5W5RuMGcN8UTH4h-GS_gMXKkAlCJQfr8IQmUi2Y=.f4fe9da8-a00d-4d72-8859-b93f1d35ded7@github.com>
References: <E3ax5W5RuMGcN8UTH4h-GS_gMXKkAlCJQfr8IQmUi2Y=.f4fe9da8-a00d-4d72-8859-b93f1d35ded7@github.com>
Message-ID: <tDnrh6HQrq1yUgl4Gf5EV5Z_SBRfjWRHQG9rasTLlRM=.48f434e5-bd94-4689-ac6c-7e050b3c6074@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 1. Supporting preview-only resources without forcing a double lookup on everything.
> 2. Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> 3. Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> 
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1613.
> 
> https://github.com/openjdk/valhalla/pull/1615/commits/28eae40aa9a3f8520519d79d7749b5a4b3511609

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  add system property guard to preview mode

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1615/files
  - new: https://git.openjdk.org/valhalla/pull/1615/files/28eae40a..82f4e671

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

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

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

From duke at openjdk.org  Tue Sep 23 19:12:27 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:12:27 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v3]
In-Reply-To: <E3ax5W5RuMGcN8UTH4h-GS_gMXKkAlCJQfr8IQmUi2Y=.f4fe9da8-a00d-4d72-8859-b93f1d35ded7@github.com>
References: <E3ax5W5RuMGcN8UTH4h-GS_gMXKkAlCJQfr8IQmUi2Y=.f4fe9da8-a00d-4d72-8859-b93f1d35ded7@github.com>
Message-ID: <JEVksz4QMn1A4-fN0tajy2QYTIdXNup4t_v-6LNelgo=.bf092e3a-9be6-4b15-932b-a9c9bd14b330@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 1. Supporting preview-only resources without forcing a double lookup on everything.
> 2. Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> 3. Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> 
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1613.
> 
> https://github.com/openjdk/valhalla/pull/1615/commits/28eae40aa9a3f8520519d79d7749b5a4b3511609

David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains seven new commits since the last revision:

 - add system property guard to preview mode
 - jimage writer changes to support preview mode.
   
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.
 - Word smithing flags definitions.
 - Add workaround until new image writing code is in
 - Clarifying flag docs for /packages/xxx case
 - Java ImageReader changes for preview mode
 - C++ preparation for preview mode

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1615/files
  - new: https://git.openjdk.org/valhalla/pull/1615/files/82f4e671..2d56562f

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

  Stats: 197 lines in 10 files changed: 108 ins; 2 del; 87 mod
  Patch: https://git.openjdk.org/valhalla/pull/1615.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1615/head:pull/1615

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

From duke at openjdk.org  Tue Sep 23 19:12:16 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:12:16 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at
 make time [v2]
In-Reply-To: <ZHVuptIskS6NxDNaa0_NILZgUXONCPYlQJKvPvG5bTo=.abe7dacd-31c8-4c58-a847-519610bdaef4@github.com>
References: <ZHVuptIskS6NxDNaa0_NILZgUXONCPYlQJKvPvG5bTo=.abe7dacd-31c8-4c58-a847-519610bdaef4@github.com>
Message-ID: <LZayFDYD7_Xp9oFBbb8YFq4Vv4ics3PVc1z8Gu38u3Q=.fe0730f6-8812-4b3e-880b-8b90d4f85cb6@github.com>

> Copies valuetype classes for each module into corresponding "<module>/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
> 
> This PR is stacked on top of https://github.com/openjdk/valhalla/pull/1615 and only contains the single commit:
> https://github.com/openjdk/valhalla/commit/d5941080fc1983fd436fc60962630f27b561a9b3

David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains eight new commits since the last revision:

 - Copy value classes into preview directories for inclusion in jimage
 - add system property guard to preview mode
 - jimage writer changes to support preview mode.
   
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.
 - Word smithing flags definitions.
 - Add workaround until new image writing code is in
 - Clarifying flag docs for /packages/xxx case
 - Java ImageReader changes for preview mode
 - C++ preparation for preview mode

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1616/files
  - new: https://git.openjdk.org/valhalla/pull/1616/files/d5941080..5e813e89

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

  Stats: 261 lines in 14 files changed: 121 ins; 3 del; 137 mod
  Patch: https://git.openjdk.org/valhalla/pull/1616.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1616/head:pull/1616

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

From duke at openjdk.org  Tue Sep 23 19:12:38 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:12:38 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v4]
In-Reply-To: <2cUM6ozADNBPjs5mhYVDdo5sSUdV24FP6Gb3sY_Psfk=.e49a8559-8724-4b5c-8826-8fd4d0f01fd8@github.com>
References: <2cUM6ozADNBPjs5mhYVDdo5sSUdV24FP6Gb3sY_Psfk=.e49a8559-8724-4b5c-8826-8fd4d0f01fd8@github.com>
Message-ID: <Ksmh1OPxWVTRnqGNA3kOsaKNZcGYSspFzqNpyqWdwtY=.d5ac629e-ca8b-48a0-b7a7-65da8c7d92ad@github.com>

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1609.
> 
> https://github.com/openjdk/valhalla/pull/1613/files/4e21d5e00ac05d4197e8c617dbabec84ce8748f9..a55450f04523454c489caa67db0fb5d7b6cb80c2

David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains five new commits since the last revision:

 - Word smithing flags definitions.
 - Add workaround until new image writing code is in
 - Clarifying flag docs for /packages/xxx case
 - Java ImageReader changes for preview mode
 - C++ preparation for preview mode

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1613/files
  - new: https://git.openjdk.org/valhalla/pull/1613/files/a55450f0..629ba8cc

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

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

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

From duke at openjdk.org  Tue Sep 23 19:12:40 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:12:40 GMT
Subject: [lworld] Withdrawn: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system
In-Reply-To: <2cUM6ozADNBPjs5mhYVDdo5sSUdV24FP6Gb3sY_Psfk=.e49a8559-8724-4b5c-8826-8fd4d0f01fd8@github.com>
References: <2cUM6ozADNBPjs5mhYVDdo5sSUdV24FP6Gb3sY_Psfk=.e49a8559-8724-4b5c-8826-8fd4d0f01fd8@github.com>
Message-ID: <Ca68iG8M1LN8m9Yvsrh0_5ed0F_z8iKN0yM5-dGPVkc=.ca4e9240-f068-4972-8867-9965ce437ed4@github.com>

On Tue, 23 Sep 2025 09:56:26 GMT, David Beaumont <duke at openjdk.org> wrote:

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1609.
> 
> https://github.com/openjdk/valhalla/pull/1613/files/4e21d5e00ac05d4197e8c617dbabec84ce8748f9..a55450f04523454c489caa67db0fb5d7b6cb80c2

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Sep 23 19:13:23 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:13:23 GMT
Subject: [lworld] Withdrawn: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <RLZhZqNVU7eQCErLwoedsIKpdWfFLnNHE0_n9HY2ePk=.76ef953f-7ce6-4be5-b0d5-fb7149179c02@github.com>
References: <RLZhZqNVU7eQCErLwoedsIKpdWfFLnNHE0_n9HY2ePk=.76ef953f-7ce6-4be5-b0d5-fb7149179c02@github.com>
Message-ID: <fDoThcCyKKhQWlK7TUSS5uLtv9V87BSZbBq_bQVrJHE=.89964bdc-11a5-4d9a-9270-804fd6272755@github.com>

On Mon, 22 Sep 2025 22:21:25 GMT, David Beaumont <duke at openjdk.org> wrote:

> C++ changes for supporting preview mode *when* preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

This pull request has been closed without being integrated.

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

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

From coleenp at openjdk.org  Tue Sep 23 19:16:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 23 Sep 2025 19:16:42 GMT
Subject: [lworld] RFR: 8368002: [lworld] Crash in
 ThawBase::remove_top_compiled_frame_from_chunk [v3]
In-Reply-To: <YC1ySdMeaCkyd1EdarFIHLbAYiyXdsJ5tXcm0-jEqDc=.be45bd0d-978f-4da8-9bc8-c07495f04209@github.com>
References: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
 <YC1ySdMeaCkyd1EdarFIHLbAYiyXdsJ5tXcm0-jEqDc=.be45bd0d-978f-4da8-9bc8-c07495f04209@github.com>
Message-ID: <KWF7aG7kU2IGyA11XZm5ygl29FwcEbeHT-MBTAfA_Pk=.eb50d788-5de5-4415-9595-a8744519b52f@github.com>

On Mon, 22 Sep 2025 18:26:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small fix. When thawing in the fast path, the top frame could be a runtime stub due to preempting on monitorenter. In the changes for JDK-8336845 I missed this, leading to a crash when dereferencing the nullptr returned by `f.cb()->as_nmethod_or_null()` in `ThawBase::remove_top_compiled_frame_from_chunk`.
>> 
>> I was able to reproduce the failure locally and verified it is now fixed. I did run into a pre-existing crash with Jetty (filed JDK-8368099). I also run all tests in java/lang/Thread/virtual stressing this path, tests Fuzz.java and TestVirtualThreads.java, plus extra mach5 tier testing.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove chunk parameter from remove_scalarized_frames

This looks really good.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1603#pullrequestreview-3259292953

From duke at openjdk.org  Tue Sep 23 19:18:39 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:18:39 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++ classloader
Message-ID: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>

C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.

At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

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

Commit messages:
 - C++ preparation for preview mode

Changes: https://git.openjdk.org/valhalla/pull/1618/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1618&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366093
  Stats: 326 lines in 8 files changed: 215 ins; 60 del; 51 mod
  Patch: https://git.openjdk.org/valhalla/pull/1618.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1618/head:pull/1618

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

From duke at openjdk.org  Tue Sep 23 19:23:18 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:23:18 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader and
 JRT file-system
Message-ID: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>

Java changes for supporting preview mode when preview mode resources (with new location flags) are available.

At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).

This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618

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

Commit messages:
 - Word smithing flags definitions.
 - Add workaround until new image writing code is in
 - Clarifying flag docs for /packages/xxx case
 - Java ImageReader changes for preview mode
 - C++ preparation for preview mode

Changes: https://git.openjdk.org/valhalla/pull/1619/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1619&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368333
  Stats: 1705 lines in 25 files changed: 1342 ins; 167 del; 196 mod
  Patch: https://git.openjdk.org/valhalla/pull/1619.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1619/head:pull/1619

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

From duke at openjdk.org  Tue Sep 23 19:23:18 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:23:18 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system
In-Reply-To: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
Message-ID: <T0mFRXziaNQ0mZUHyovRyU8yy35f8fyGAQ41QJCXDW8=.2e615dfa-2ee0-4f4b-b070-c3c2dd2c07db@github.com>

On Tue, 23 Sep 2025 19:15:43 GMT, David Beaumont <duke at openjdk.org> wrote:

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618

This is a new version of https://github.com/openjdk/valhalla/pull/1613, re-created so there's now a pr/xxx branch for use by dependent PRs.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1619#issuecomment-3325242276

From duke at openjdk.org  Tue Sep 23 19:18:40 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:18:40 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
Message-ID: <wYK-DcMXLZ62e_RjyqV40za9M8h9o_BwLYs4j4s_aEg=.91e3db13-89bb-4e33-ab97-f8fd4c079539@github.com>

On Tue, 23 Sep 2025 19:11:41 GMT, David Beaumont <duke at openjdk.org> wrote:

> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

This is a new version of https://github.com/openjdk/valhalla/pull/1609, re-created so there's now a pr/xxx branch for use by dependent PRs.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1618#issuecomment-3325229462

From amenkov at openjdk.org  Tue Sep 23 19:26:28 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Sep 2025 19:26:28 GMT
Subject: [lworld] RFR: 8367589: [lworld] com/sun/jdi/valhalla tests fail with
 JTREG_TEST_THREAD_FACTORY=Virtual
Message-ID: <jtxaTxkJQdUAtSRgIq-H4C4VEq0--Dk8VSBVjgHPRNI=.97af13f2-72e5-4149-978f-bf2dc07abc3e@github.com>

Fixed issue with test class (TestScaffold) when it does not correctly handle "enablePreview" (does not pass "--enable-preview" to child debuggee process)

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

Commit messages:
 - fix

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

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

From duke at openjdk.org  Tue Sep 23 19:27:11 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:27:11 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v3]
In-Reply-To: <JEVksz4QMn1A4-fN0tajy2QYTIdXNup4t_v-6LNelgo=.bf092e3a-9be6-4b15-932b-a9c9bd14b330@github.com>
References: <E3ax5W5RuMGcN8UTH4h-GS_gMXKkAlCJQfr8IQmUi2Y=.f4fe9da8-a00d-4d72-8859-b93f1d35ded7@github.com>
 <JEVksz4QMn1A4-fN0tajy2QYTIdXNup4t_v-6LNelgo=.bf092e3a-9be6-4b15-932b-a9c9bd14b330@github.com>
Message-ID: <o9IugVMGA7NUHzZDpVkO49w3TorSij-7S7bnnhdZU5k=.0d6d9476-74a7-4e3d-8d2d-76a9bc66ebfd@github.com>

On Tue, 23 Sep 2025 19:12:27 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 1. Supporting preview-only resources without forcing a double lookup on everything.
>> 2. Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> 3. Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> 
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>> 
>> Compare and review this against https://github.com/openjdk/valhalla/pull/1613.
>> 
>> https://github.com/openjdk/valhalla/pull/1615/commits/28eae40aa9a3f8520519d79d7749b5a4b3511609
>
> David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains seven new commits since the last revision:
> 
>  - add system property guard to preview mode
>  - jimage writer changes to support preview mode.
>    
>    * Remove TODOs now jimage version is bumped
>    * jimage writer changes to support preview mode.
>  - Word smithing flags definitions.
>  - Add workaround until new image writing code is in
>  - Clarifying flag docs for /packages/xxx case
>  - Java ImageReader changes for preview mode
>  - C++ preparation for preview mode

Regenerating PR so it was a pr/xxx branch available.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1615#issuecomment-3325265682

From duke at openjdk.org  Tue Sep 23 19:27:13 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:27:13 GMT
Subject: [lworld] Withdrawn: 8368467: [lworld] Add new flag generation for
 jimage to support preview mode
In-Reply-To: <E3ax5W5RuMGcN8UTH4h-GS_gMXKkAlCJQfr8IQmUi2Y=.f4fe9da8-a00d-4d72-8859-b93f1d35ded7@github.com>
References: <E3ax5W5RuMGcN8UTH4h-GS_gMXKkAlCJQfr8IQmUi2Y=.f4fe9da8-a00d-4d72-8859-b93f1d35ded7@github.com>
Message-ID: <4KwHqb6gCnuntKckOnVBbaswfHuk2QaKeUIoj5F3SV4=.e2859885-6f94-4bc8-8d2f-892a09d00101@github.com>

On Tue, 23 Sep 2025 13:47:28 GMT, David Beaumont <duke at openjdk.org> wrote:

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 1. Supporting preview-only resources without forcing a double lookup on everything.
> 2. Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> 3. Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> 
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1613.
> 
> https://github.com/openjdk/valhalla/pull/1615/commits/28eae40aa9a3f8520519d79d7749b5a4b3511609

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Sep 23 19:28:09 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:28:09 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v2]
In-Reply-To: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
Message-ID: <yirPWTSrLynAJpbdBOCZDpUL9YUL7plYglTZkTS7aiU=.fe258f59-5676-44a4-b8fb-9b2dbe4442dd@github.com>

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618

David Beaumont 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.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1619/files
  - new: https://git.openjdk.org/valhalla/pull/1619/files/629ba8cc..629ba8cc

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

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

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

From duke at openjdk.org  Tue Sep 23 19:29:07 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:29:07 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at
 make time [v2]
In-Reply-To: <LZayFDYD7_Xp9oFBbb8YFq4Vv4ics3PVc1z8Gu38u3Q=.fe0730f6-8812-4b3e-880b-8b90d4f85cb6@github.com>
References: <ZHVuptIskS6NxDNaa0_NILZgUXONCPYlQJKvPvG5bTo=.abe7dacd-31c8-4c58-a847-519610bdaef4@github.com>
 <LZayFDYD7_Xp9oFBbb8YFq4Vv4ics3PVc1z8Gu38u3Q=.fe0730f6-8812-4b3e-880b-8b90d4f85cb6@github.com>
Message-ID: <SOvjgYVi4Fpb6eYfNJvtdLCl2e6tkNWR9VBzApU54N8=.a94d06af-3bac-4eaf-bd4e-eb3de6cbb1bc@github.com>

On Tue, 23 Sep 2025 19:12:16 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Copies valuetype classes for each module into corresponding "<module>/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
>> 
>> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
>> 
>> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
>> 
>> This PR is stacked on top of https://github.com/openjdk/valhalla/pull/1615 and only contains the single commit:
>> https://github.com/openjdk/valhalla/commit/d5941080fc1983fd436fc60962630f27b561a9b3
>
> David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains eight new commits since the last revision:
> 
>  - Copy value classes into preview directories for inclusion in jimage
>  - add system property guard to preview mode
>  - jimage writer changes to support preview mode.
>    
>    * Remove TODOs now jimage version is bumped
>    * jimage writer changes to support preview mode.
>  - Word smithing flags definitions.
>  - Add workaround until new image writing code is in
>  - Clarifying flag docs for /packages/xxx case
>  - Java ImageReader changes for preview mode
>  - C++ preparation for preview mode

Regenerating PR so it has a base branch to work from.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1616#issuecomment-3325272077

From duke at openjdk.org  Tue Sep 23 19:29:08 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:29:08 GMT
Subject: [lworld] Withdrawn: 8368475: [lworld] Add preview classes to jimage at
 make time
In-Reply-To: <ZHVuptIskS6NxDNaa0_NILZgUXONCPYlQJKvPvG5bTo=.abe7dacd-31c8-4c58-a847-519610bdaef4@github.com>
References: <ZHVuptIskS6NxDNaa0_NILZgUXONCPYlQJKvPvG5bTo=.abe7dacd-31c8-4c58-a847-519610bdaef4@github.com>
Message-ID: <yWAqSAcSpvacdiykcNdYTalpOIiu5Bk-4YVnpmhCvag=.8885f4ff-1f62-470e-a948-e8add9c9035d@github.com>

On Tue, 23 Sep 2025 16:03:26 GMT, David Beaumont <duke at openjdk.org> wrote:

> Copies valuetype classes for each module into corresponding "<module>/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
> 
> This PR is stacked on top of https://github.com/openjdk/valhalla/pull/1615 and only contains the single commit:
> https://github.com/openjdk/valhalla/commit/d5941080fc1983fd436fc60962630f27b561a9b3

This pull request has been closed without being integrated.

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

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

From amenkov at openjdk.org  Tue Sep 23 19:31:05 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Sep 2025 19:31:05 GMT
Subject: [lworld] Integrated: 8367589: [lworld] com/sun/jdi/valhalla tests fail
 with JTREG_TEST_THREAD_FACTORY=Virtual
In-Reply-To: <jtxaTxkJQdUAtSRgIq-H4C4VEq0--Dk8VSBVjgHPRNI=.97af13f2-72e5-4149-978f-bf2dc07abc3e@github.com>
References: <jtxaTxkJQdUAtSRgIq-H4C4VEq0--Dk8VSBVjgHPRNI=.97af13f2-72e5-4149-978f-bf2dc07abc3e@github.com>
Message-ID: <rrRCMGfdEYhmW4wsjfexl3i8C29ZqqHWW8Myy7FNIOQ=.23d5d720-21be-4d9a-a714-59d32519c4a2@github.com>

On Tue, 23 Sep 2025 19:20:19 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Fixed issue with test class (TestScaffold) when it does not correctly handle "enablePreview" (does not pass "--enable-preview" to child debuggee process)

This pull request has now been integrated.

Changeset: 0dd4f427
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0dd4f427ef27c1831ac58a3e0030fbdd1e0d8282
Stats:     6 lines in 2 files changed: 1 ins; 3 del; 2 mod

8367589: [lworld] com/sun/jdi/valhalla tests fail with JTREG_TEST_THREAD_FACTORY=Virtual

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

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

From duke at openjdk.org  Tue Sep 23 19:32:22 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:32:22 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to support
 preview mode
Message-ID: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>

Adds support for writing preview related flags into jimage files.

Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".

Specific issues include:

Supporting preview-only resources without forcing a double lookup on everything.
Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.

To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.

Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.

This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

Compare and review this against https://github.com/openjdk/valhalla/pull/1619.

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

Depends on: https://git.openjdk.org/valhalla/pull/1619

Commit messages:
 - add system property guard to preview mode
 - jimage writer changes to support preview mode.

Changes: https://git.openjdk.org/valhalla/pull/1621/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1621&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368467
  Stats: 1906 lines in 13 files changed: 768 ins; 130 del; 1008 mod
  Patch: https://git.openjdk.org/valhalla/pull/1621.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1621/head:pull/1621

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

From duke at openjdk.org  Tue Sep 23 19:34:29 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:34:29 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at make
 time
Message-ID: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>

Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.

There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).

To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".

This should be review against https://github.com/openjdk/valhalla/pull/1621.

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

Commit messages:
 - Copy value classes into preview directories for inclusion in jimage
 - add system property guard to preview mode
 - jimage writer changes to support preview mode.
 - Word smithing flags definitions.
 - Add workaround until new image writing code is in
 - Clarifying flag docs for /packages/xxx case
 - Java ImageReader changes for preview mode
 - C++ preparation for preview mode

Changes: https://git.openjdk.org/valhalla/pull/1622/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1622&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368475
  Stats: 3586 lines in 34 files changed: 2112 ins; 279 del; 1195 mod
  Patch: https://git.openjdk.org/valhalla/pull/1622.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1622/head:pull/1622

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

From duke at openjdk.org  Tue Sep 23 19:42:03 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 19:42:03 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
 [v2]
In-Reply-To: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
References: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
Message-ID: <IZTKDbrR53z3Fm0vg6fT3qqTC0imzeW2AoM-ERL5jXc=.a9e58647-33d4-4fda-aebc-b1c23d91bc5e@github.com>

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
> 
> This should be review against https://github.com/openjdk/valhalla/pull/1621.

David Beaumont 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.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1622/files
  - new: https://git.openjdk.org/valhalla/pull/1622/files/5e813e89..5e813e89

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

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

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

From vromero at openjdk.org  Tue Sep 23 19:42:43 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 19:42:43 GMT
Subject: [lworld] Integrated: 8368494: [lworld] some tests are failing after
 fix for JDK-8367698 broke some tests
Message-ID: <7q8tAZiKVI1S4v6a3TrmgdB_twkREUrz0vr4KF5TwFw=.9071e3af-d81f-4e50-a580-80b73e533754@github.com>

delta applying JDK-8367698

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

Commit messages:
 - 8368494: [lworld] some tests are failing after fix for JDK-8367698 broke some tests

Changes: https://git.openjdk.org/valhalla/pull/1623/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1623&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368494
  Stats: 640 lines in 33 files changed: 3 ins; 561 del; 76 mod
  Patch: https://git.openjdk.org/valhalla/pull/1623.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1623/head:pull/1623

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

From vromero at openjdk.org  Tue Sep 23 19:42:43 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 19:42:43 GMT
Subject: [lworld] Integrated: 8368494: [lworld] some tests are failing after
 fix for JDK-8367698 broke some tests
In-Reply-To: <7q8tAZiKVI1S4v6a3TrmgdB_twkREUrz0vr4KF5TwFw=.9071e3af-d81f-4e50-a580-80b73e533754@github.com>
References: <7q8tAZiKVI1S4v6a3TrmgdB_twkREUrz0vr4KF5TwFw=.9071e3af-d81f-4e50-a580-80b73e533754@github.com>
Message-ID: <VYMd-uLroT15ovPgkHyA91uo4PD39vrwLpg9QQMH9bA=.42bd06e3-3902-4230-924c-6f24317d995a@github.com>

On Tue, 23 Sep 2025 19:36:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> delta applying JDK-8367698

This pull request has now been integrated.

Changeset: d19c45e4
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d19c45e4db50b134a9897fb03dc5c6b456fa25cf
Stats:     640 lines in 33 files changed: 3 ins; 561 del; 76 mod

8368494: [lworld] some tests are failing after fix for JDK-8367698 broke some tests

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

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

From pchilanomate at openjdk.org  Tue Sep 23 19:45:24 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 23 Sep 2025 19:45:24 GMT
Subject: [lworld] RFR: 8368002: [lworld] Crash in
 ThawBase::remove_top_compiled_frame_from_chunk [v3]
In-Reply-To: <YC1ySdMeaCkyd1EdarFIHLbAYiyXdsJ5tXcm0-jEqDc=.be45bd0d-978f-4da8-9bc8-c07495f04209@github.com>
References: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
 <YC1ySdMeaCkyd1EdarFIHLbAYiyXdsJ5tXcm0-jEqDc=.be45bd0d-978f-4da8-9bc8-c07495f04209@github.com>
Message-ID: <YzEwP9FN-Pf_w3hfhsXE_2ooMoFHYOj-CtHJar6gnlY=.3c36151d-0d25-4f77-9116-55668ced94f9@github.com>

On Mon, 22 Sep 2025 18:26:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small fix. When thawing in the fast path, the top frame could be a runtime stub due to preempting on monitorenter. In the changes for JDK-8336845 I missed this, leading to a crash when dereferencing the nullptr returned by `f.cb()->as_nmethod_or_null()` in `ThawBase::remove_top_compiled_frame_from_chunk`.
>> 
>> I was able to reproduce the failure locally and verified it is now fixed. I did run into a pre-existing crash with Jetty (filed JDK-8368099). I also run all tests in java/lang/Thread/virtual stressing this path, tests Fuzz.java and TestVirtualThreads.java, plus extra mach5 tier testing.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove chunk parameter from remove_scalarized_frames

Thanks Coleen!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1603#issuecomment-3325308382

From duke at openjdk.org  Tue Sep 23 19:45:25 2025
From: duke at openjdk.org (duke)
Date: Tue, 23 Sep 2025 19:45:25 GMT
Subject: [lworld] RFR: 8368002: [lworld] Crash in
 ThawBase::remove_top_compiled_frame_from_chunk [v3]
In-Reply-To: <YC1ySdMeaCkyd1EdarFIHLbAYiyXdsJ5tXcm0-jEqDc=.be45bd0d-978f-4da8-9bc8-c07495f04209@github.com>
References: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
 <YC1ySdMeaCkyd1EdarFIHLbAYiyXdsJ5tXcm0-jEqDc=.be45bd0d-978f-4da8-9bc8-c07495f04209@github.com>
Message-ID: <RF8TnBwZSU36Zl7XhyhhDpB43GHjHlTtjwnuY1w0gnA=.159e44ba-c9cc-4661-aaa8-baeba54aaaa6@github.com>

On Mon, 22 Sep 2025 18:26:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small fix. When thawing in the fast path, the top frame could be a runtime stub due to preempting on monitorenter. In the changes for JDK-8336845 I missed this, leading to a crash when dereferencing the nullptr returned by `f.cb()->as_nmethod_or_null()` in `ThawBase::remove_top_compiled_frame_from_chunk`.
>> 
>> I was able to reproduce the failure locally and verified it is now fixed. I did run into a pre-existing crash with Jetty (filed JDK-8368099). I also run all tests in java/lang/Thread/virtual stressing this path, tests Fuzz.java and TestVirtualThreads.java, plus extra mach5 tier testing.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove chunk parameter from remove_scalarized_frames

@pchilano 
Your change (at version 15b254f52c38b374e906817b376a9d67b216f1d9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1603#issuecomment-3325314204

From vromero at openjdk.org  Tue Sep 23 19:53:07 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 19:53:07 GMT
Subject: [lworld] RFR: 8368078: [lworld]
 tools/javac/flags/ExtendedStandardFlagsOverlayFlagsConflict.java fails with
 Valhalla
Message-ID: <80FowjmoNFPdwU8o-AyNZK8MJYq9rZFBOZ0rDzebt0Y=.ff0ad75c-3c50-42b7-b971-d08a44de2bb3@github.com>

adjusting flags so that flag VALUE_CLASS doesn't class with any other flag

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

Commit messages:
 - 8368078: [lworld] tools/javac/flags/ExtendedStandardFlagsOverlayFlagsConflict.java fails with Valhalla

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

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

From vromero at openjdk.org  Tue Sep 23 20:16:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 23 Sep 2025 20:16:06 GMT
Subject: [lworld] Integrated: 8368078: [lworld]
 tools/javac/flags/ExtendedStandardFlagsOverlayFlagsConflict.java fails with
 Valhalla
In-Reply-To: <80FowjmoNFPdwU8o-AyNZK8MJYq9rZFBOZ0rDzebt0Y=.ff0ad75c-3c50-42b7-b971-d08a44de2bb3@github.com>
References: <80FowjmoNFPdwU8o-AyNZK8MJYq9rZFBOZ0rDzebt0Y=.ff0ad75c-3c50-42b7-b971-d08a44de2bb3@github.com>
Message-ID: <bJ9i7DmlwNW4y1nmwBRUg_0HSJD6WQ40DLWloP9Gg1E=.6fe468c6-bd8c-4d5d-b930-c48c77bd8d1a@github.com>

On Tue, 23 Sep 2025 19:46:03 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adjusting flags so that flag VALUE_CLASS doesn't class with any other flag

This pull request has now been integrated.

Changeset: 6f5dc652
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6f5dc6522feede3948fb460368322a7dcb98c6e8
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8368078: [lworld] tools/javac/flags/ExtendedStandardFlagsOverlayFlagsConflict.java fails with Valhalla

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

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

From duke at openjdk.org  Tue Sep 23 20:36:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 20:36:55 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode
In-Reply-To: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
Message-ID: <RzHB3ASqX5z7tyfhvqWBrg9O-ej4rc-mPAAYLhG82iI=.cfcf843b-abc7-432d-8793-e13b0875d8dc@github.com>

On Tue, 23 Sep 2025 19:25:22 GMT, David Beaumont <duke at openjdk.org> wrote:

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java line 290:

> 288:     }
> 289: 
> 290:     private static ResourcePool getResourcePool(

Pulled out so the variable holding it is effectively final and can be used in a lambda expression.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageLocationWriter.java line 93:

> 91: 
> 92:         return new ImageLocationWriter(strings)
> 93:                 .addAttribute(ATTRIBUTE_MODULE, moduleName)

This got reformatted correctly to 8 indent because of the new entry.

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

> 149:      * occur (e.g. {@code HAS_NORMAL_CONTENT + IS_PREVIEW_ONLY}).
> 150:      *
> 151:      * <p>Package node entries are sorted by name, with the exception that (if

This is out of date (along with the test). It's now sorted "preview first" and then "by name". The reason for the change is that I had made an incorrect assumption that I didn't need to process empty packages from preview resources, but I do (they still appear in /packages/xxx directories).

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

> 250:             packageToModules.forEach((pkgName, modRefs) -> {
> 251:                 // Merge multiple refs for the same module.
> 252:                 List<ModuleReference> pkgModules = modRefs.stream()

This is where module references are merged so each package has the right set of flags according to all the resources visited in the module (empty, non-empty, preview, preview-only...). This replaces the use of the two maps (moduleToPackage and packageToModule) and a bunch of other logic.

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

> 296:             ModuleReference emptyRef = ModuleReference.forEmptyPackage(modName, isPreviewPath);
> 297: 
> 298:             // Work down through empty packages to final resource.

This loop and the section after replaces the logic between L191 and L238 in the original code.

Instead of two maps (which would be 4 if we tried to add preview support that way) with near-duplicated logic, there's now just "walk down the path creating empty package nodes until the last segment is reached, then exit and create the resource node in a non-empty package".

The empty/non-empty/preview nature of these packages is all handled when the module references are merged later, but for now they are independent.

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

> 429:                 ByteBuffer byteBuffer = ByteBuffer.allocate(8 * refs.size());
> 430:                 byteBuffer.order(writer.getByteOrder());
> 431:                 ModuleReference.write(refs, byteBuffer.asIntBuffer(), writer::addString);

Call into the ModuleReference code added in the previous PR to write the package flags and offsets.

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

> 195:     }
> 196: 
> 197:     @Test

This test needs updating. The order of the entries has changed. Sorry for not spotting sooner.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2373352347
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2373354187
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2373387987
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2373377751
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2373371691
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2373380118
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2373357299

From pchilanomate at openjdk.org  Tue Sep 23 21:06:22 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 23 Sep 2025 21:06:22 GMT
Subject: [lworld] Integrated: 8368002: [lworld] Crash in
 ThawBase::remove_top_compiled_frame_from_chunk
In-Reply-To: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
References: <JEo8YMatPVl8rR6_CaYIqDESVExdNrYZvUTjcOxvNfo=.c0bc8175-9e5a-45cd-b417-8f1c3c85b316@github.com>
Message-ID: <nYbPDSw2FA3S1d3bEy7LcBwOw4bxxUkeZqWH0_B-Bs0=.89764022-e220-44ef-ba83-36ac75adab17@github.com>

On Fri, 19 Sep 2025 14:40:20 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small fix. When thawing in the fast path, the top frame could be a runtime stub due to preempting on monitorenter. In the changes for JDK-8336845 I missed this, leading to a crash when dereferencing the nullptr returned by `f.cb()->as_nmethod_or_null()` in `ThawBase::remove_top_compiled_frame_from_chunk`.
> 
> I was able to reproduce the failure locally and verified it is now fixed. I did run into a pre-existing crash with Jetty (filed JDK-8368099). I also run all tests in java/lang/Thread/virtual stressing this path, tests Fuzz.java and TestVirtualThreads.java, plus extra mach5 tier testing.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: feee12a2
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/feee12a2ebb8efa5c549ee99510c84f2877ef530
Stats:     47 lines in 1 file changed: 9 ins; 34 del; 4 mod

8368002: [lworld] Crash in ThawBase::remove_top_compiled_frame_from_chunk

Reviewed-by: coleenp

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

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

From pchilanomate at openjdk.org  Tue Sep 23 21:04:19 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 23 Sep 2025 21:04:19 GMT
Subject: [lworld] RFR: 8368099: [lworld] Crash in
 frame::sender_for_compiled_frame while processing JFR sampling request
In-Reply-To: <5f_oWiY8AeMb7ctAvBmVuE6R182bNGEJhghDQX1U0aY=.f73f5376-2a48-40bb-9f32-814671e47891@github.com>
References: <5f_oWiY8AeMb7ctAvBmVuE6R182bNGEJhghDQX1U0aY=.f73f5376-2a48-40bb-9f32-814671e47891@github.com>
Message-ID: <6b_eeNfwObZw23PTpa_OmU1fvkyOPkOi5w7OWj_6KoI=.5a05da40-f68b-436e-b2c6-7b62fee891a5@github.com>

On Mon, 22 Sep 2025 22:37:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Reconstructing a synthetic compiled frame when processing a sample request at a poll on return doesn?t work for frames that need stack repair. The stack walking code will read the frame size from the stack, but the memory has already been overwritten by the SafepointBlob frame. See comments in JBS issue for full details.
> 
> This patch skips the attempt to create this synthetic frame in case the frame needs stack repair. This fixes the crash but doesn't handle the safepoint bias issue. A more permanent solution will be required for that.
> 
> I tested the patch along the fix for 8368002 and verified that Jetty.java doesn?t crash anymore.
> 
> Thanks,
> Patricio

Thanks for the review Markus.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1610#issuecomment-3325534374

From duke at openjdk.org  Tue Sep 23 21:04:19 2025
From: duke at openjdk.org (duke)
Date: Tue, 23 Sep 2025 21:04:19 GMT
Subject: [lworld] RFR: 8368099: [lworld] Crash in
 frame::sender_for_compiled_frame while processing JFR sampling request
In-Reply-To: <5f_oWiY8AeMb7ctAvBmVuE6R182bNGEJhghDQX1U0aY=.f73f5376-2a48-40bb-9f32-814671e47891@github.com>
References: <5f_oWiY8AeMb7ctAvBmVuE6R182bNGEJhghDQX1U0aY=.f73f5376-2a48-40bb-9f32-814671e47891@github.com>
Message-ID: <yCLr5_lIjaShdsc3TvCfPlWeJw_k4n5SB5_lCKEElQY=.bfa7d9f8-fdad-412d-9ce0-dddb382b3060@github.com>

On Mon, 22 Sep 2025 22:37:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Reconstructing a synthetic compiled frame when processing a sample request at a poll on return doesn?t work for frames that need stack repair. The stack walking code will read the frame size from the stack, but the memory has already been overwritten by the SafepointBlob frame. See comments in JBS issue for full details.
> 
> This patch skips the attempt to create this synthetic frame in case the frame needs stack repair. This fixes the crash but doesn't handle the safepoint bias issue. A more permanent solution will be required for that.
> 
> I tested the patch along the fix for 8368002 and verified that Jetty.java doesn?t crash anymore.
> 
> Thanks,
> Patricio

@pchilano 
Your change (at version b83133e1502de3c689c134e16e835a668b69309c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1610#issuecomment-3325538082

From duke at openjdk.org  Tue Sep 23 22:21:21 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 22:21:21 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v2]
In-Reply-To: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
Message-ID: <BvYqlH_a5PI3ijuZn34YFgG0YWORv0NI5bPKk72BU10=.54592c9a-b94a-438f-a69a-c60e3b77358f@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Restoring lost changes and updating some comments.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1621/files
  - new: https://git.openjdk.org/valhalla/pull/1621/files/2d56562f..0c0ad6a3

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

  Stats: 102 lines in 4 files changed: 9 ins; 48 del; 45 mod
  Patch: https://git.openjdk.org/valhalla/pull/1621.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1621/head:pull/1621

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

From duke at openjdk.org  Tue Sep 23 22:28:58 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 22:28:58 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v2]
In-Reply-To: <RzHB3ASqX5z7tyfhvqWBrg9O-ej4rc-mPAAYLhG82iI=.cfcf843b-abc7-432d-8793-e13b0875d8dc@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
 <RzHB3ASqX5z7tyfhvqWBrg9O-ej4rc-mPAAYLhG82iI=.cfcf843b-abc7-432d-8793-e13b0875d8dc@github.com>
Message-ID: <GXgW_uUa4S2eO8GlOEAhI6klvxaAFGZinRDDeGdI6OI=.6a5cc791-7738-4bb7-8376-a44d189a97e8@github.com>

On Tue, 23 Sep 2025 20:18:48 GMT, David Beaumont <duke at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restoring lost changes and updating some comments.
>
> test/jdk/tools/jlink/whitebox/jdk.jlink/jdk/tools/jlink/internal/ImageResourcesTreeTest.java line 197:
> 
>> 195:     }
>> 196: 
>> 197:     @Test
> 
> This test needs updating. The order of the entries has changed. Sorry for not spotting sooner.

Actually I had fixed this locally and somehow it hadn't got patched into this PR. Updated now and the test compiles and passes.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2373587160

From duke at openjdk.org  Tue Sep 23 22:30:39 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 22:30:39 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
 [v3]
In-Reply-To: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
References: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
Message-ID: <G1ZdVao7za_ge6cd35K8uMrh6X-vu8dNNFeGslhIoLU=.aba21b60-8cab-4a29-bb1d-b121a68665e6@github.com>

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
> 
> This should be review against https://github.com/openjdk/valhalla/pull/1621.

David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Copy value classes into preview directories for inclusion in jimage

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

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

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

From duke at openjdk.org  Tue Sep 23 23:07:18 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 23:07:18 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
 [v4]
In-Reply-To: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
References: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
Message-ID: <Lg_cYHpbac0f-V7dX_6p5sUXnUc2AR1bUnA-_f8qFwM=.a48980ab-c53c-43f8-8b03-f78baac081d8@github.com>

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
> 
> This should be review against https://github.com/openjdk/valhalla/pull/1621.

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

 - Copy value classes into preview directories for inclusion in jimage
 - Restoring lost changes and updating some comments.
 - add system property guard to preview mode
 - jimage writer changes to support preview mode.
   
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.
 - Manually deleting ImageReaderFactory (it returned somehow)

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

Changes: https://git.openjdk.org/valhalla/pull/1622/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1622&range=03
  Stats: 2004 lines in 15 files changed: 753 ins; 240 del; 1011 mod
  Patch: https://git.openjdk.org/valhalla/pull/1622.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1622/head:pull/1622

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

From duke at openjdk.org  Tue Sep 23 23:06:28 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 23:06:28 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
Message-ID: <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Manually deleting ImageReaderFactory (it returned somehow)

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1619/files
  - new: https://git.openjdk.org/valhalla/pull/1619/files/629ba8cc..936b22d1

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

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

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

From duke at openjdk.org  Tue Sep 23 23:07:47 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 23 Sep 2025 23:07:47 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v3]
In-Reply-To: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
Message-ID: <GXRcWlgy-5WY0DM560h8AHexiI9CLGFUNyG_ogpczRs=.03766e7d-d426-490e-9908-7c5daca4ac51@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.

David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains four new commits since the last revision:

 - Restoring lost changes and updating some comments.
 - add system property guard to preview mode
 - jimage writer changes to support preview mode.
   
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.
 - Manually deleting ImageReaderFactory (it returned somehow)

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1621/files
  - new: https://git.openjdk.org/valhalla/pull/1621/files/0c0ad6a3..b192c84f

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

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

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

From davidalayachew at gmail.com  Tue Sep 23 23:10:04 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 23 Sep 2025 19:10:04 -0400
Subject: Question about Value Classes and inheritance
In-Reply-To: <SJ2PR10MB76695519B1E305D29D81AB84A21DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CAA9v-_NCpK1016xTJ9KGkSa0RHeG53XaLHK8gLMieFfZmowpGQ@mail.gmail.com>
 <511933718.34976748.1758630684356.JavaMail.zimbra@univ-eiffel.fr>
 <CAA9v-_PTZ_=LXrEYTGmqrYYqP7=TCCpsWJJOZWmbtFj_OKWm8w@mail.gmail.com>
 <SJ2PR10MB76695519B1E305D29D81AB84A21DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_NOGm_n6GctMjmZASwx0Qo8ku0_=itnOdFaSYGG3Oj7wg@mail.gmail.com>

What an excellent explanation, ty vm Chen. No, this clarifies everything
for me, ty again.

On Tue, Sep 23, 2025, 12:13?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hi David,
> In the value objects world, we can think of identity as an extra field on
> an object that is distinct for every object creation. Due to the uniqueness
> of this field, we can have shortcuts for hashCode/== that is still
> compliant but much simpler.
> The proposal to block identity subtypes for abstract value types would be
> equivalent to blocking subtypes from declaring particular types of fields
> or implementing particular interfaces (all interfaces are now abstract
> value, too).
>
> If you want to ensure safety for abstract value classes, sealed modifier
> is your friend - they ensure an AVC only has particular subtypes and might
> be optimized to union types by JVM implementations.
> Otherwise, if a field allows arbitrary value subtypes, they still must be
> stored as references just like for identity objects. In this case, allowing
> identity subtypes has little performance impact.
>
> Regarding the perceived "lack of safety" for identity classes, I would
> argue it is not associated with identity, but with the mutable fields
> enabled by identity.
> In fact, in the investigations of heap-flattened value objects and var
> handles, we find that referring to large value objects as reference
> pointers is the best way to ensure volatility - because pointers are small
> enough to be updated atomically.
>
> Feel free to ask further if you have more overview questions.
>
> Regards,
> Chen
> ------------------------------
> *From:* valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Tuesday, September 23, 2025 8:50 AM
> *To:* Remi Forax <forax at univ-mlv.fr>
> *Cc:* valhalla-dev <valhalla-dev at openjdk.java.net>
> *Subject:* Re: Question about Value Classes and inheritance
>
> To answer your question specifically R?mi, I figured this would be useful
> to prevent things like misuse. For example, the JEP shows how BigInteger
> can't be a value class due to its internal use of mutability. Well,
> something like enforcing value classes might have prevented that. Or maybe
> not, I am ignorant about that example specifically.
>
> But hopefully you see my point? It feels like there a lot of validation
> opportunities being left on the table. Value classes aren't just faster,
> they are safer. So, being able to assert that safety for all child classes
> seems nice.
>
> Or maybe I am wrong, and Value classes aren't inherently safer. Finality
> feels safe to me, and finality by default feels safer. Idk.
>
> Truthfully, I'm operating more on feelings here than genuine experience.
> I'll have something more concrete (or see where I'm wrong) to say once the
> new EA comes out.
>
> On Tue, Sep 23, 2025, 8:31?AM Remi Forax <forax at univ-mlv.fr> wrote:
>
>
>
> ------------------------------
>
> *From: *"David Alayachew" <davidalayachew at gmail.com>
> *To: *"valhalla-dev" <valhalla-dev at openjdk.java.net>
> *Sent: *Tuesday, September 23, 2025 2:19:40 PM
> *Subject: *Question about Value Classes and inheritance
>
> Hello @valhalla-dev <valhalla-dev at openjdk.java.net>,
>
> I read through JEP 401, and the subsection about subtyping surprised me.
>
> It appears that Abstract Value Classes can permit both Value child classes
> and Identity child classes. The example of BigInteger helps explain why.
>
> Ok, but there doesn't seem to be any way to say "only value classes can
> extend me!"
>
> Why is that?
>
> And to be clear, I am not bothered by Abstract Value Classes permitting
> Identity children, that's fine.
>
>
> I'm glad this is fine by you because it's important for backward
> compatibility, it means that you can declare an existing abstract class has
> "value enable", without requiring sub-classes to be changed.
>
> I'm moreso confused by lack of ability to say "only value children".
>
>
> Declaring a class has a value class is really close to be an
> implementation detail (it mainly depends on if your code abuse of == or
> not),
> so why do you want such ability ?
>
>
>
> Thank you for your time and consideration.
> David Alayachew
>
>
> regards,
> R?mi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250923/2801406c/attachment-0001.htm>

From amenkov at openjdk.org  Wed Sep 24 01:04:12 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 01:04:12 GMT
Subject: [lworld] Integrated: 8368022:
 serviceability/dcmd/gc/HeapDumpParallelTest.java fails missing output
Message-ID: <qvGr72MO6iIgNMhYr0TcJYeCJ5RQZinOeoXdt4_Jk7k=.c800237e-a850-4548-89f9-6936c2b46fd4@github.com>

Updates test to accept different logging variations

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

Commit messages:
 - fix

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

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

From amenkov at openjdk.org  Wed Sep 24 01:04:13 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 24 Sep 2025 01:04:13 GMT
Subject: [lworld] Integrated: 8368022:
 serviceability/dcmd/gc/HeapDumpParallelTest.java fails missing output
In-Reply-To: <qvGr72MO6iIgNMhYr0TcJYeCJ5RQZinOeoXdt4_Jk7k=.c800237e-a850-4548-89f9-6936c2b46fd4@github.com>
References: <qvGr72MO6iIgNMhYr0TcJYeCJ5RQZinOeoXdt4_Jk7k=.c800237e-a850-4548-89f9-6936c2b46fd4@github.com>
Message-ID: <duAxDX1p6G-1DbvDmAYxtba5GhevVPQtfe-AuT3GraA=.dd635d94-1480-4072-b8c1-02bac5a96f5b@github.com>

On Wed, 24 Sep 2025 00:56:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Updates test to accept different logging variations

This pull request has now been integrated.

Changeset: 0ef9bd48
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0ef9bd4879f40aba9174c2fff1f1f66bb8a2e072
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8368022: serviceability/dcmd/gc/HeapDumpParallelTest.java fails missing output

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

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

From mhaessig at openjdk.org  Wed Sep 24 06:53:11 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 24 Sep 2025 06:53:11 GMT
Subject: [lworld] Integrated: 8367518: TestRedundantLea.java fails in Valhalla
In-Reply-To: <TesTvna9Hnac4nqILX5rFxHSgHMlXgbC62oEqWd4-rE=.1f8b82f9-d2a6-4755-b893-ca1aedc104f4@github.com>
References: <TesTvna9Hnac4nqILX5rFxHSgHMlXgbC62oEqWd4-rE=.1f8b82f9-d2a6-4755-b893-ca1aedc104f4@github.com>
Message-ID: <ZD3iz60OYo4j7mlGPNAH03aFPP9qizQmrJDusMQCh7A=.18d1828f-b898-49ef-9acb-64a3720dfca4@github.com>

On Mon, 22 Sep 2025 10:52:07 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> After merging `TestRedundantLea.java` into valhalla it turned out that the `StringInflate` and `StoreN*` subtests fail. This PR fixes that by bringing over two commits from mainline that fix problems with this test, which already fixes `StringInflate`.
> 
> The problem with the `StoreN` cases is that with valhalla C2 does not generate spills that the peephole can remove. To still test removing spills I came up with a new test case specifically for spills.
> 
> Testing:
>  - [x] tier1,tier2 plus some stress testing

This pull request has now been integrated.

Changeset: 01225ee2
Author:    Manuel H?ssig <mhaessig at openjdk.org>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/01225ee226f8abb82cc27d2ad00a46a37736406b
Stats:     87 lines in 2 files changed: 45 ins; 29 del; 13 mod

8367518: TestRedundantLea.java fails in Valhalla

Reviewed-by: chagedorn

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

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

From fparain at openjdk.org  Wed Sep 24 13:13:26 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 24 Sep 2025 13:13:26 GMT
Subject: [lworld] RFR: 8367415: Fully encapsulate array allocation in
 oopFactory [v3]
In-Reply-To: <sWG77SDS09Ep8gMULOiPjNlH7AlUPuORIA3QxTqw68A=.5ff89010-f5e9-4653-bea9-637a07279ff0@github.com>
References: <R4wxCPs3ElS4neWmCx3E6xMzSHudAFn7zt24JUXn608=.6d3327b9-3a35-4ed4-b7e3-867bd8a39afd@github.com>
 <sWG77SDS09Ep8gMULOiPjNlH7AlUPuORIA3QxTqw68A=.5ff89010-f5e9-4653-bea9-637a07279ff0@github.com>
Message-ID: <SFwVjJSvyJdwrQvQx2v4mgTSincseDYzcanTPpoPpjE=.16f2818f-a2fc-4ab7-a79d-3599c0066148@github.com>

On Mon, 22 Sep 2025 20:22:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This makes oopFactory and deoptimization the only friends of private ArrayKlass::allocate_instance.  This is similar to the PR https://github.com/openjdk/jdk/pull/27372 in mainline with some extra handling for new_refArray (rather than calling RefArrayKlass::allocate_instance() directly.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'lworld' into oopFactory
>  - Remove rogue public
>  - 8367415: Fully encapsulate array allocation in oopFactory

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1602#pullrequestreview-3262821275

From coleenp at openjdk.org  Wed Sep 24 13:13:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 24 Sep 2025 13:13:24 GMT
Subject: git: openjdk/valhalla: lworld: 8367415: Fully encapsulate array
 allocation in oopFactory
Message-ID: <3b887693-eeb7-4f08-8240-8a4b6e99d538@openjdk.org>

Changeset: 77d067c9
Branch: lworld
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2025-09-24 13:09:53 +0000
URL:       https://git.openjdk.org/valhalla/commit/77d067c9472a463c2540d2754489fe4696487a05

8367415: Fully encapsulate array allocation in oopFactory

Reviewed-by: fparain

! src/hotspot/share/memory/oopFactory.cpp
! src/hotspot/share/memory/oopFactory.hpp
! src/hotspot/share/oops/arrayKlass.cpp
! src/hotspot/share/oops/arrayKlass.hpp
! src/hotspot/share/oops/flatArrayKlass.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/objArrayKlass.hpp
! src/hotspot/share/oops/refArrayKlass.hpp
! src/hotspot/share/opto/runtime.cpp


From coleenp at openjdk.org  Wed Sep 24 13:13:27 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 24 Sep 2025 13:13:27 GMT
Subject: [lworld] RFR: 8367415: Fully encapsulate array allocation in
 oopFactory [v3]
In-Reply-To: <sWG77SDS09Ep8gMULOiPjNlH7AlUPuORIA3QxTqw68A=.5ff89010-f5e9-4653-bea9-637a07279ff0@github.com>
References: <R4wxCPs3ElS4neWmCx3E6xMzSHudAFn7zt24JUXn608=.6d3327b9-3a35-4ed4-b7e3-867bd8a39afd@github.com>
 <sWG77SDS09Ep8gMULOiPjNlH7AlUPuORIA3QxTqw68A=.5ff89010-f5e9-4653-bea9-637a07279ff0@github.com>
Message-ID: <4ey652T1J6Txl3sTy_TO7syn5zzPKA2diGvAWuLtXQg=.85623679-cfde-43ac-bc60-3b65dbe4ffc9@github.com>

On Mon, 22 Sep 2025 20:22:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This makes oopFactory and deoptimization the only friends of private ArrayKlass::allocate_instance.  This is similar to the PR https://github.com/openjdk/jdk/pull/27372 in mainline with some extra handling for new_refArray (rather than calling RefArrayKlass::allocate_instance() directly.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'lworld' into oopFactory
>  - Remove rogue public
>  - 8367415: Fully encapsulate array allocation in oopFactory

Thanks Fred.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1602#issuecomment-3328339427

From coleenp at openjdk.org  Wed Sep 24 13:13:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 24 Sep 2025 13:13:29 GMT
Subject: [lworld] Integrated: 8367415: Fully encapsulate array allocation in
 oopFactory
In-Reply-To: <R4wxCPs3ElS4neWmCx3E6xMzSHudAFn7zt24JUXn608=.6d3327b9-3a35-4ed4-b7e3-867bd8a39afd@github.com>
References: <R4wxCPs3ElS4neWmCx3E6xMzSHudAFn7zt24JUXn608=.6d3327b9-3a35-4ed4-b7e3-867bd8a39afd@github.com>
Message-ID: <dE9EgxYq3Gr0tPtJui7DOkcAhlDHFAGWehzjvO9TRA4=.06b32e4d-cd64-41cd-9f0a-1428b7c53e56@github.com>

On Fri, 19 Sep 2025 14:32:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This makes oopFactory and deoptimization the only friends of private ArrayKlass::allocate_instance.  This is similar to the PR https://github.com/openjdk/jdk/pull/27372 in mainline with some extra handling for new_refArray (rather than calling RefArrayKlass::allocate_instance() directly.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: 77d067c9
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/77d067c9472a463c2540d2754489fe4696487a05
Stats:     54 lines in 10 files changed: 18 ins; 26 del; 10 mod

8367415: Fully encapsulate array allocation in oopFactory

Reviewed-by: fparain

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

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

From rriggs at openjdk.org  Wed Sep 24 15:51:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 24 Sep 2025 15:51:35 GMT
Subject: [lworld] RFR: 8368192: Test java/lang/ProcessBuilder/Basic.java#id0
 fails with Exception: Stack trace
Message-ID: <H1TnMc-Qk-lhRjxSe-sKewcEPw2w30otY4YlQYhFmOA=.552e5e2c-4b66-40b6-83bb-e0872499359f@github.com>

Backport of 8368192 to resolve test failures.

The test fix is included, the change to the problem list is unnecessary.

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

Commit messages:
 - 8368192: Test java/lang/ProcessBuilder/Basic.java#id0 fails with Exception: Stack trace

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

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

From liach at openjdk.org  Wed Sep 24 16:09:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 Sep 2025 16:09:26 GMT
Subject: [lworld] RFR: 8368192: Test
 java/lang/ProcessBuilder/Basic.java#id0 fails with Exception: Stack trace
In-Reply-To: <H1TnMc-Qk-lhRjxSe-sKewcEPw2w30otY4YlQYhFmOA=.552e5e2c-4b66-40b6-83bb-e0872499359f@github.com>
References: <H1TnMc-Qk-lhRjxSe-sKewcEPw2w30otY4YlQYhFmOA=.552e5e2c-4b66-40b6-83bb-e0872499359f@github.com>
Message-ID: <yS_y_O9vAXV-ldlYl6lRxiR2I1dnD6I-MWhStIeXocA=.fe1a1fb4-3244-49f1-a54b-dadcf8a6c57c@github.com>

On Wed, 24 Sep 2025 15:38:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Backport of 8368192 to resolve test failures.
> 
> The test fix is included, the change to the problem list is unnecessary.

Appears identical aside from the non applicable problem list entry.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1627#pullrequestreview-3263653400

From liach at openjdk.org  Wed Sep 24 16:11:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 Sep 2025 16:11:37 GMT
Subject: [lworld] RFR: 8368099: [lworld] Crash in
 frame::sender_for_compiled_frame while processing JFR sampling request
In-Reply-To: <5f_oWiY8AeMb7ctAvBmVuE6R182bNGEJhghDQX1U0aY=.f73f5376-2a48-40bb-9f32-814671e47891@github.com>
References: <5f_oWiY8AeMb7ctAvBmVuE6R182bNGEJhghDQX1U0aY=.f73f5376-2a48-40bb-9f32-814671e47891@github.com>
Message-ID: <mzw_JS05lyqYfN5EPZb5SBoPezNmOiQbebZNJ9B-BHc=.12b93bfd-d4b3-4810-b463-a8e67ffff99a@github.com>

On Mon, 22 Sep 2025 22:37:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Reconstructing a synthetic compiled frame when processing a sample request at a poll on return doesn?t work for frames that need stack repair. The stack walking code will read the frame size from the stack, but the memory has already been overwritten by the SafepointBlob frame. See comments in JBS issue for full details.
> 
> This patch skips the attempt to create this synthetic frame in case the frame needs stack repair. This fixes the crash but doesn't handle the safepoint bias issue. A more permanent solution will be required for that.
> 
> I tested the patch along the fix for 8368002 and verified that Jetty.java doesn?t crash anymore.
> 
> Thanks,
> Patricio

Thanks for this fix!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1610#issuecomment-3329698557

From pchilanomate at openjdk.org  Wed Sep 24 16:11:38 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 24 Sep 2025 16:11:38 GMT
Subject: [lworld] Integrated: 8368099: [lworld] Crash in
 frame::sender_for_compiled_frame while processing JFR sampling request
In-Reply-To: <5f_oWiY8AeMb7ctAvBmVuE6R182bNGEJhghDQX1U0aY=.f73f5376-2a48-40bb-9f32-814671e47891@github.com>
References: <5f_oWiY8AeMb7ctAvBmVuE6R182bNGEJhghDQX1U0aY=.f73f5376-2a48-40bb-9f32-814671e47891@github.com>
Message-ID: <QourA6ykaMyHTq5RgPtFjKMir-2JredExwP1gk3Lp6g=.f8c6efb1-197c-421a-8dd9-6d9ee6ca6210@github.com>

On Mon, 22 Sep 2025 22:37:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Reconstructing a synthetic compiled frame when processing a sample request at a poll on return doesn?t work for frames that need stack repair. The stack walking code will read the frame size from the stack, but the memory has already been overwritten by the SafepointBlob frame. See comments in JBS issue for full details.
> 
> This patch skips the attempt to create this synthetic frame in case the frame needs stack repair. This fixes the crash but doesn't handle the safepoint bias issue. A more permanent solution will be required for that.
> 
> I tested the patch along the fix for 8368002 and verified that Jetty.java doesn?t crash anymore.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 52e1a19d
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/52e1a19d117110b0641d28540d8562af6c7134b1
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8368099: [lworld] Crash in frame::sender_for_compiled_frame while processing JFR sampling request

Reviewed-by: mgronlun

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

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

From coleenp at openjdk.org  Wed Sep 24 17:01:07 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 24 Sep 2025 17:01:07 GMT
Subject: [lworld] RFR: 8367415: Fully encapsulate array allocation in
 oopFactory (FIX)
Message-ID: <C3kEvPryqaVGr5TQmbJ4mCLjnMIQHxU9vcNp1n1y5X8=.15fefd77-21eb-400e-b206-730c8cc95d75@github.com>

This should fix the build failure.  Builds locally, but am testing in tier1 on many platforms (in progress).

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

Commit messages:
 - 8367415: Fully encapsulate array allocation in oopFactory (FIX)

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

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

From fparain at openjdk.org  Wed Sep 24 17:12:41 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 24 Sep 2025 17:12:41 GMT
Subject: [lworld] RFR: 8367415: Fully encapsulate array allocation in
 oopFactory
In-Reply-To: <C3kEvPryqaVGr5TQmbJ4mCLjnMIQHxU9vcNp1n1y5X8=.15fefd77-21eb-400e-b206-730c8cc95d75@github.com>
References: <C3kEvPryqaVGr5TQmbJ4mCLjnMIQHxU9vcNp1n1y5X8=.15fefd77-21eb-400e-b206-730c8cc95d75@github.com>
Message-ID: <nrS7HF6RLqHssaQ1SDa-jfCJo76GzKNE_rUPMBTyMGc=.947e7bd8-cbe9-47e4-af46-53dbda966770@github.com>

On Wed, 24 Sep 2025 16:53:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This should fix the build failure.  Builds locally, but am testing in tier1 on many platforms (in progress).

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1628#pullrequestreview-3263866079

From coleenp at openjdk.org  Wed Sep 24 18:09:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 24 Sep 2025 18:09:32 GMT
Subject: [lworld] RFR: 8367415: Fully encapsulate array allocation in
 oopFactory
In-Reply-To: <C3kEvPryqaVGr5TQmbJ4mCLjnMIQHxU9vcNp1n1y5X8=.15fefd77-21eb-400e-b206-730c8cc95d75@github.com>
References: <C3kEvPryqaVGr5TQmbJ4mCLjnMIQHxU9vcNp1n1y5X8=.15fefd77-21eb-400e-b206-730c8cc95d75@github.com>
Message-ID: <myODExwxg9scVdEJNUo67vy3EaOvSJYOjEEuaC2G5Lg=.00b1d059-e5e5-4b0c-b34c-1fb89ca0b149@github.com>

On Wed, 24 Sep 2025 16:53:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This should fix the build failure.  Builds locally, but am testing in tier1 on many platforms (in progress).

Builds are clean now and testing is about to finish.

Thanks Fred.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1628#issuecomment-3330085584
PR Comment: https://git.openjdk.org/valhalla/pull/1628#issuecomment-3330086436

From coleenp at openjdk.org  Wed Sep 24 18:09:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 24 Sep 2025 18:09:33 GMT
Subject: [lworld] Integrated: 8367415: Fully encapsulate array allocation in
 oopFactory
In-Reply-To: <C3kEvPryqaVGr5TQmbJ4mCLjnMIQHxU9vcNp1n1y5X8=.15fefd77-21eb-400e-b206-730c8cc95d75@github.com>
References: <C3kEvPryqaVGr5TQmbJ4mCLjnMIQHxU9vcNp1n1y5X8=.15fefd77-21eb-400e-b206-730c8cc95d75@github.com>
Message-ID: <LP-oddf4TzSZ46_rxE4W8VQpfVgSP_LtHaIagAsnNkU=.59a4897c-faeb-4888-87aa-c8441e810b4b@github.com>

On Wed, 24 Sep 2025 16:53:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This should fix the build failure.  Builds locally, but am testing in tier1 on many platforms (in progress).

This pull request has now been integrated.

Changeset: 18097d41
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/18097d417dd2c3cf0c7006a683fc9bcbf4b9a203
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8367415: Fully encapsulate array allocation in oopFactory

Reviewed-by: fparain

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

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

From coleenp at openjdk.org  Wed Sep 24 18:11:07 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 24 Sep 2025 18:11:07 GMT
Subject: git: openjdk/valhalla: lworld: 8367415: Fully encapsulate array
 allocation in oopFactory
Message-ID: <c783710c-d7e6-4d78-8c65-a8f9053eb3e8@openjdk.org>

Changeset: 18097d41
Branch: lworld
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2025-09-24 18:07:04 +0000
URL:       https://git.openjdk.org/valhalla/commit/18097d417dd2c3cf0c7006a683fc9bcbf4b9a203

8367415: Fully encapsulate array allocation in oopFactory

Reviewed-by: fparain

! src/hotspot/share/memory/oopFactory.cpp
! src/hotspot/share/memory/oopFactory.hpp


From matsaave at openjdk.org  Wed Sep 24 19:46:00 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 24 Sep 2025 19:46:00 GMT
Subject: [lworld] RFR: 8367398: JCmdTestDynamicDump.java crashes on Windows
 with assert(m !=nullptr) failed: nullptr mirror
Message-ID: <Gbd1OcuylbHP8zloxHExACjhtF4Er3n93UWWhtqfLLk=.8d808a7c-e256-4b7a-948c-f7340c135f4b@github.com>

We avoid archiving refined objArrayKlasses in the dynamic archive due to issues mapping different dimensions of an array across the static and dynamic archives. One check was missed leading to a crash on Windows which is fixed in this patch.

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

Commit messages:
 - 8367398: JCmdTestDynamicDump.java crashes on Windows with assert(m != nullptr) failed: nullptr mirror

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

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

From rriggs at openjdk.org  Wed Sep 24 20:36:33 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 24 Sep 2025 20:36:33 GMT
Subject: [lworld] Integrated: 8368192: Test
 java/lang/ProcessBuilder/Basic.java#id0 fails with Exception: Stack trace
In-Reply-To: <H1TnMc-Qk-lhRjxSe-sKewcEPw2w30otY4YlQYhFmOA=.552e5e2c-4b66-40b6-83bb-e0872499359f@github.com>
References: <H1TnMc-Qk-lhRjxSe-sKewcEPw2w30otY4YlQYhFmOA=.552e5e2c-4b66-40b6-83bb-e0872499359f@github.com>
Message-ID: <ddQeV7lRqaI5s6Dxnilqz11rCovTlMxiyu5a9-bTFtI=.6e0d88fc-c34e-4dc2-880d-b641846963dc@github.com>

On Wed, 24 Sep 2025 15:38:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Backport of 8368192 to resolve test failures.
> 
> The test fix is included, the change to the problem list is unnecessary.

This pull request has now been integrated.

Changeset: 140e4e37
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/140e4e37c26c73bd54d484668933447e564e7f39
Stats:     20 lines in 1 file changed: 2 ins; 3 del; 15 mod

8368192: Test java/lang/ProcessBuilder/Basic.java#id0 fails with Exception: Stack trace

Reviewed-by: liach
Backport-of: 218e82c875237f82a649a214c72d925a5ebf188c

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

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

From rriggs at openjdk.org  Wed Sep 24 20:39:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 24 Sep 2025 20:39:11 GMT
Subject: git: openjdk/valhalla: lworld: 8368192: Test
 java/lang/ProcessBuilder/Basic.java#id0 fails with Exception: Stack trace
Message-ID: <28309d54-48c8-485c-9dc7-f85017b6a3fd@openjdk.org>

Changeset: 140e4e37
Branch: lworld
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2025-09-24 20:33:42 +0000
URL:       https://git.openjdk.org/valhalla/commit/140e4e37c26c73bd54d484668933447e564e7f39

8368192: Test java/lang/ProcessBuilder/Basic.java#id0 fails with Exception: Stack trace

Reviewed-by: liach
Backport-of: 218e82c875237f82a649a214c72d925a5ebf188c

! test/jdk/java/lang/ProcessBuilder/Basic.java


From liach at openjdk.org  Wed Sep 24 21:01:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 Sep 2025 21:01:01 GMT
Subject: [lworld] RFR: 8366270: [lworld] Fix ClassFile AccessFlagsTest
Message-ID: <iSEoojzskFvFhyhEq-g3PDSC2ncZuMKpr08JJPk8x2o=.2260166d-6963-4eff-aa60-4df4ac0cbbb5@github.com>

This is the Valhalla version of [JDK-8337220](https://bugs.openjdk.org/browse/JDK-8337220).
We pass the class file version in ClassFile structures for correct access flag validation. Since we are a few tags behind there will be some merge conflict if we pull mainline.

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

Commit messages:
 - Pass class file versions

Changes: https://git.openjdk.org/valhalla/pull/1630/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1630&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366270
  Stats: 270 lines in 32 files changed: 168 ins; 4 del; 98 mod
  Patch: https://git.openjdk.org/valhalla/pull/1630.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1630/head:pull/1630

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

From liach at openjdk.org  Wed Sep 24 22:39:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 Sep 2025 22:39:14 GMT
Subject: [lworld] RFR: 8366270: [lworld] Fix ClassFile AccessFlagsTest [v2]
In-Reply-To: <iSEoojzskFvFhyhEq-g3PDSC2ncZuMKpr08JJPk8x2o=.2260166d-6963-4eff-aa60-4df4ac0cbbb5@github.com>
References: <iSEoojzskFvFhyhEq-g3PDSC2ncZuMKpr08JJPk8x2o=.2260166d-6963-4eff-aa60-4df4ac0cbbb5@github.com>
Message-ID: <LBOMANy-aAjE6ytRCIAIHMTl-ih879Viw1xnJFYTXoY=.7f7b23e6-73c1-4448-b74a-e9a73342e09a@github.com>

> This is the Valhalla version of [JDK-8337220](https://bugs.openjdk.org/browse/JDK-8337220).
> We pass the class file version in ClassFile structures for correct access flag validation. Since we are a few tags behind there will be some merge conflict if we pull mainline.

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 three additional commits since the last revision:

 - Fix existing misuse
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/cf-carry-version
 - Pass class file versions

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1630/files
  - new: https://git.openjdk.org/valhalla/pull/1630/files/265ba2e7..efa73c20

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

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

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

From chagedorn at openjdk.org  Thu Sep 25 10:56:15 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 25 Sep 2025 10:56:15 GMT
Subject: [lworld] RFR: 8348972: [lworld] C1/C2: Update Valhalla with
 UseCompactObjectHeaders for oop->klass load/stores
Message-ID: <i0KvRV-JavSIiNIk4YiI5iL6EUnYJHRyWccKxom0JiM=.9fa9dabf-e135-4b9d-9874-b4a88aa63ef3@github.com>

This patch fixes various issues in C1 and C2 (11 bugs in total) when running with `-XX:+UseCompactObjectHeaders`.

Most of the bugs could either be traced back to:
- Unconditionally assuming old layout with klass pointer following immediately the mark word.
- Small mistakes when merging JEP 450.
- Using the wrong basic type `T_OBJECT` for flat arrays instead of `T_FLAT_ELEMENT`. In Valhalla, we require that the elements of an array are aligned:https://github.com/openjdk/valhalla/blob/04efe5c66b70b9dca1a5c538c9a04e7ad93c107a/src/hotspot/share/oops/arrayOop.hpp#L94-L97
https://github.com/openjdk/valhalla/blob/04efe5c66b70b9dca1a5c538c9a04e7ad93c107a/src/hotspot/share/oops/arrayOop.hpp#L57-L61
When we now wrongly use `T_OBJECT`, it is not a problem with default flags (using compressed klass pointers and no COH): An array has a 12 byte header + 4 byte length which is 16 bytes in total - no alignment required. But with COH, we now have a header of 8 bytes + 4 byte length. We now require alignment but when we pass in `T_OBJECT`, we miss the alignment which leads to crashes down the line. I went through all the uses of `base_offset_in_bytes()` and fixed more such issues.

To review: I made separate commits for each fixed bug, each message summarizing the found issue. To better understand individual changes of the patch, it might help to look at the commits separately.

**Testing:**
- Apart from one bug, I could trigger them with existing tests. So, I have not added new tests for these issues separately.
- One bug only manifested with a new test (`test127a`) which I added with this patch.
- tier1-5 + compiler stress:
  - No additional flags, i.e. (mostly) without COH: Looks good and only known failures
  - With explicitly setting COH:
    - A lot of CDS related failures on which @matias9927 is working ([JDK-8367959](https://bugs.openjdk.org/browse/JDK-8367959))
    - Test timeout with `TestIntrinsics`: Unrelated to COH but only triggering with COH ([JDK-8368274](https://bugs.openjdk.org/browse/JDK-8368274)).
    - Otherwise, looks good with only known failures.

Thanks,
Christian

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

Commit messages:
 - Unproblemlist tests
 - C2: store_inline_type_fields_to_buf() wrongly loads InlineKlassFixedBlock from wrong register on aarch with COH
 - C2: Fix wrong prototype klass word in expand_mh_intrinsic_return with COH
 - C2: Fix wrong header computation in ArrayCopyNode::modifies with COH
 - C2: Fix wrong header computation for System.arraycopy() with COH
 - C2: Fix wrong header computation in ArrayCopyNode::prepare_array_copy() for copyOf() with COH
 - C2: Fix header computation in array_element_address() with COH
 - C2: Wrong header size computation when attaching value object fields to safepoint with COH
 - C2: First element of array was wrongly fetched with T_OBJECT instead of T_FLAT_ELEMENT which ignored forced alignment checked with element_type_should_be_aligned()
 - C2: store_inline_type_fields_to_buf() wrongly loads InlineKlassFixedBlock from markword instead of klass pointer with COH
 - ... and 2 more: https://git.openjdk.org/valhalla/compare/01225ee2...dc06e1e9

Changes: https://git.openjdk.org/valhalla/pull/1632/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348972
  Stats: 157 lines in 12 files changed: 93 ins; 37 del; 27 mod
  Patch: https://git.openjdk.org/valhalla/pull/1632.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1632/head:pull/1632

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

From mhaessig at openjdk.org  Thu Sep 25 12:36:00 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 25 Sep 2025 12:36:00 GMT
Subject: [lworld] RFR: 8368519: [lworld]: TestRedundantLea.java#Spill fails
Message-ID: <v97Sk6uDVnawAsuRy_ahEFsoZG0FxeSvqijylBBp_9k=.63a15099-1056-462d-b9df-e9f7c7140d7c@github.com>

The test case `compiler/codegen/TestRedundantLea.java#Spill`, recently introduced in #1605, fails due to too strict node counts. This PR relaxes those node counts to account for differences in code generation between platforms and machines.

Testing:
 - [x] tier1,tier2 plus stress testing

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

Commit messages:
 - Make node counts more fuzzy

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

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

From fparain at openjdk.org  Thu Sep 25 13:24:44 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 25 Sep 2025 13:24:44 GMT
Subject: [lworld] RFR: 8360656: [lworld] UnsafeTest.java fails with
 -XX:ForceNonTearable=*
Message-ID: <ZGLZG7esXSEhoOi3gUD7qVnF4WDDiKepOyAx0xJtlXM=.f27edc4a-82ac-449c-9512-b6bb0848ef65@github.com>

Some tests expect specific layouts and fail when an additional option is passed to the VM and changes those layouts.
Adding a flagless requirement to these tests to prevent such failures from happening.

Tested of Mach5 tiers 1 to 3 with the -XX:ForceNonTearable=* VM flag.

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

Commit messages:
 - Add flagless requirement to tests expecting specific layouts

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

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

From chagedorn at openjdk.org  Thu Sep 25 15:05:36 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 25 Sep 2025 15:05:36 GMT
Subject: [lworld] RFR: 8367500: [lworld]
 compiler/valhalla/inlinetypes/TestTearing.java times out with C1 only
Message-ID: <ukb53PSUJ_GwZCBoqLr9so-NvgOQ_KJIMi799Rx7ltc=.64816e29-f08e-48ca-a9da-f4c78d6643dd@github.com>

The test `compiler/valhalla/inlinetypes/TestTearing.java` regularly times out in tier5 when run with `-XX:TieredStopAtLevel=3`.

The reason is that we have a long running loop with 1 million iterations - simply too slow for C1 only. I took a measurement with just one of the several `@run` statements on my local machine. While the C2 run was finished within half a minute, it took the run with `-XX:TieredStopAtLevel=3` 20min.

I'm therefore proposing to use a much smaller loop limit for C1 only runs by defining a new jtreg header and an additional argument passed to `main()` to set it up correspondingly.

Thanks,
Christian

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

Commit messages:
 - 8367500: [lworld] compiler/valhalla/inlinetypes/TestTearing.java times out with C1 only

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

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

From chagedorn at openjdk.org  Thu Sep 25 15:53:34 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 25 Sep 2025 15:53:34 GMT
Subject: [lworld] RFR: [lworld] Run
 compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java without
 StressUnstableIfTraps until JDK-8367244 is fixed
Message-ID: <nT2kEa_9jyBXxJa8iYpCFXcuZVOeo-HjjfmiCXgnB60=.03b27502-93f7-4b3e-a7c3-70b7429ed04b@github.com>

`compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java` crashes when run with `StressUnstableIfTraps` in the CI ([JDK-8367244](https://bugs.openjdk.org/browse/JDK-8367244)).

To reduce the noise in the CI, I'm temporarily passing `-XX:-StressUnstableIfTraps` to disable the stress mode.

Thanks,
Christian

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

Commit messages:
 - [lworld] Run TestAcmpWithUnstableIf.java without StressUnstableIfTraps until JDK-8367244 is fixed

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

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

From chagedorn at openjdk.org  Thu Sep 25 16:37:51 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 25 Sep 2025 16:37:51 GMT
Subject: [lworld] RFR: 8368519: [lworld]: TestRedundantLea.java#Spill fails
In-Reply-To: <v97Sk6uDVnawAsuRy_ahEFsoZG0FxeSvqijylBBp_9k=.63a15099-1056-462d-b9df-e9f7c7140d7c@github.com>
References: <v97Sk6uDVnawAsuRy_ahEFsoZG0FxeSvqijylBBp_9k=.63a15099-1056-462d-b9df-e9f7c7140d7c@github.com>
Message-ID: <t9ECtuxOVaUTScCmNq3jvX2HANR8H4UQF1u-aUeU5k8=.77a10100-678e-4837-9d82-fa92999d65c0@github.com>

On Thu, 25 Sep 2025 08:13:42 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> The test case `compiler/codegen/TestRedundantLea.java#Spill`, recently introduced in #1605, fails due to too strict node counts. This PR relaxes those node counts to account for differences in code generation between platforms and machines.
> 
> Testing:
>  - [x] tier1,tier2 plus stress testing

Looks good, thanks for fixing it!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1631#pullrequestreview-3268626424

From jbhateja at openjdk.org  Thu Sep 25 17:44:20 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 25 Sep 2025 17:44:20 GMT
Subject: [lworld] RFR: 8367792: [lworld] Remove the Unsafe remnants of old
 valhalla prototypes
In-Reply-To: <vnLmnwhpHnh7Wfmmo2TD4qJhDa4dnib4HIXhic3Fsyk=.d4be4aba-4914-4a73-8d21-429ae4e680ae@github.com>
References: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
 <vnLmnwhpHnh7Wfmmo2TD4qJhDa4dnib4HIXhic3Fsyk=.d4be4aba-4914-4a73-8d21-429ae4e680ae@github.com>
Message-ID: <25EgSYS2Fq8QBPT7GQ2CE1CrTeoMsSoZI7Alwjla8qw=.95091bfe-b9f6-43e4-9703-f492a1762cff@github.com>

On Wed, 17 Sep 2025 16:52:46 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.

Hi @liach, For now, vectorAPI fallback does make heavy use of unsafe APIs to explicit larval transitions.
There is a whole lot of discussion that went into the usage of the @multifield annotation for contiguous backing storage allocation. Sharing some links for your reference.

https://cr.openjdk.org/~jrose/values/multi-field.html
https://cr.openjdk.org/~jbhateja/Valhalla/Valhalla-VectorAPI-OracleF2F-3-Apr_2024.pptx

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

PR Comment: https://git.openjdk.org/valhalla/pull/1593#issuecomment-3335219756

From amenkov at openjdk.org  Thu Sep 25 18:51:09 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 18:51:09 GMT
Subject: [lworld] RFR: 8366806: [lworld] JDI test failures
Message-ID: <L1ID4yV8xhQy9DFMyeq8VAIrQton6N1NB0PENuAxxgI=.768deeda-2563-4e33-9af9-79d096ac995e@github.com>

Fixed JVMTI GetLoadedClasses/GetClassLoaderClasses functions after array rework - RefArrayKlass/FlatArrayKlass are not reported by the functions.

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

Commit messages:
 - fix

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

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

From amenkov at openjdk.org  Thu Sep 25 19:43:41 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Sep 2025 19:43:41 GMT
Subject: [lworld] Integrated: 8366806: [lworld] JDI test failures
In-Reply-To: <L1ID4yV8xhQy9DFMyeq8VAIrQton6N1NB0PENuAxxgI=.768deeda-2563-4e33-9af9-79d096ac995e@github.com>
References: <L1ID4yV8xhQy9DFMyeq8VAIrQton6N1NB0PENuAxxgI=.768deeda-2563-4e33-9af9-79d096ac995e@github.com>
Message-ID: <dBUOei25v82gaS1spAJSxopipUMdz5vJf8aqCFZFd7A=.aaa3330d-b1fc-4201-9ca6-bca268ef12b0@github.com>

On Thu, 25 Sep 2025 18:44:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Fixed JVMTI GetLoadedClasses/GetClassLoaderClasses functions after array rework - RefArrayKlass/FlatArrayKlass are not reported by the functions.

This pull request has now been integrated.

Changeset: f909731b
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f909731beca3c2bbec56b438603962bb406f7ff9
Stats:     38 lines in 2 files changed: 14 ins; 21 del; 3 mod

8366806: [lworld] JDI test failures

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

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

From fparain at openjdk.org  Thu Sep 25 19:52:19 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 25 Sep 2025 19:52:19 GMT
Subject: [lworld] Integrated: 8360656: [lworld] UnsafeTest.java fails with
 -XX:ForceNonTearable=*
In-Reply-To: <ZGLZG7esXSEhoOi3gUD7qVnF4WDDiKepOyAx0xJtlXM=.f27edc4a-82ac-449c-9512-b6bb0848ef65@github.com>
References: <ZGLZG7esXSEhoOi3gUD7qVnF4WDDiKepOyAx0xJtlXM=.f27edc4a-82ac-449c-9512-b6bb0848ef65@github.com>
Message-ID: <4w74f7iMlHE6mGmURdgaHcOspUiWJn3ij45lT-Cp0DM=.6d4b4673-e79e-440d-81cb-62748dacce65@github.com>

On Thu, 25 Sep 2025 13:19:44 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Some tests expect specific layouts and fail when an additional option is passed to the VM and changes those layouts.
> Adding a flagless requirement to these tests to prevent such failures from happening.
> 
> Tested of Mach5 tiers 1 to 3 with the -XX:ForceNonTearable=* VM flag.

This pull request has now been integrated.

Changeset: 0b205d66
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0b205d6690bfe19486467a15f73d57338306a804
Stats:     7 lines in 3 files changed: 7 ins; 0 del; 0 mod

8360656: [lworld] UnsafeTest.java fails with -XX:ForceNonTearable=*

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

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

From liach at openjdk.org  Thu Sep 25 19:57:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 25 Sep 2025 19:57:14 GMT
Subject: [lworld] RFR: 8366270: [lworld] Fix ClassFile AccessFlagsTest [v3]
In-Reply-To: <iSEoojzskFvFhyhEq-g3PDSC2ncZuMKpr08JJPk8x2o=.2260166d-6963-4eff-aa60-4df4ac0cbbb5@github.com>
References: <iSEoojzskFvFhyhEq-g3PDSC2ncZuMKpr08JJPk8x2o=.2260166d-6963-4eff-aa60-4df4ac0cbbb5@github.com>
Message-ID: <3V7mN6hqyfOGeG93jzXSF4S5trAKQHuMS_9n0IXitUI=.1fcf83ba-5d41-4084-b923-858e72d89aed@github.com>

> This is the Valhalla version of [JDK-8337220](https://bugs.openjdk.org/browse/JDK-8337220).
> We pass the class file version in ClassFile structures for correct access flag validation. Since we are a few tags behind there will be some merge conflict if we pull mainline.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fixes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1630/files
  - new: https://git.openjdk.org/valhalla/pull/1630/files/efa73c20..fc52cd9e

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

  Stats: 45 lines in 8 files changed: 8 ins; 6 del; 31 mod
  Patch: https://git.openjdk.org/valhalla/pull/1630.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1630/head:pull/1630

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

From mchevalier at openjdk.org  Thu Sep 25 21:48:05 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 25 Sep 2025 21:48:05 GMT
Subject: [lworld] RFR: [lworld] Run
 compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java without
 StressUnstableIfTraps until JDK-8367244 is fixed
In-Reply-To: <nT2kEa_9jyBXxJa8iYpCFXcuZVOeo-HjjfmiCXgnB60=.03b27502-93f7-4b3e-a7c3-70b7429ed04b@github.com>
References: <nT2kEa_9jyBXxJa8iYpCFXcuZVOeo-HjjfmiCXgnB60=.03b27502-93f7-4b3e-a7c3-70b7429ed04b@github.com>
Message-ID: <-LC8aXY9nrLg34kDI7XDgqZ-l-wuICZnHvOOPUTBIsM=.f382e57c-8cf7-4cb6-83a3-db5ff590f9d7@github.com>

On Thu, 25 Sep 2025 15:48:15 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java` crashes when run with `StressUnstableIfTraps` in the CI ([JDK-8367244](https://bugs.openjdk.org/browse/JDK-8367244)).
> 
> To reduce the noise in the CI, I'm temporarily passing `-XX:-StressUnstableIfTraps` to disable the stress mode.
> 
> Thanks,
> Christian

Should we update the copyright year for such a change?

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

Marked as reviewed by mchevalier (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1635#pullrequestreview-3269556543

From amenkov at openjdk.org  Fri Sep 26 00:21:23 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Sep 2025 00:21:23 GMT
Subject: [lworld] Integrated: Fix ProblemList entries
In-Reply-To: <icDqhUoRH9XscdDWj5ehgvAUIESu9-DNbkQpF18e4Gw=.273f3e6c-97ca-45bc-9ab6-fe97242448f3@github.com>
References: <icDqhUoRH9XscdDWj5ehgvAUIESu9-DNbkQpF18e4Gw=.273f3e6c-97ca-45bc-9ab6-fe97242448f3@github.com>
Message-ID: <jXOl2mJNeOROi6n5EOPHxLMgY64Hziwg-NDY2EhWSjw=.4b560486-5ca8-4e9a-9976-bc6225a86532@github.com>

On Fri, 26 Sep 2025 00:09:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Fix ProblemList entries

This pull request has now been integrated.

Changeset: 18a0f39e
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/18a0f39ea156d4512fd83fc14c1b17b566db1790
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

Fix ProblemList entries

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

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

From amenkov at openjdk.org  Fri Sep 26 00:21:22 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Sep 2025 00:21:22 GMT
Subject: [lworld] Integrated: Fix ProblemList entries
Message-ID: <icDqhUoRH9XscdDWj5ehgvAUIESu9-DNbkQpF18e4Gw=.273f3e6c-97ca-45bc-9ab6-fe97242448f3@github.com>

Fix ProblemList entries

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

Commit messages:
 - Fix ProblemList entries

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

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

From chagedorn at openjdk.org  Fri Sep 26 06:17:06 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 26 Sep 2025 06:17:06 GMT
Subject: [lworld] RFR: [lworld] Run
 compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java without
 StressUnstableIfTraps until JDK-8367244 is fixed [v2]
In-Reply-To: <nT2kEa_9jyBXxJa8iYpCFXcuZVOeo-HjjfmiCXgnB60=.03b27502-93f7-4b3e-a7c3-70b7429ed04b@github.com>
References: <nT2kEa_9jyBXxJa8iYpCFXcuZVOeo-HjjfmiCXgnB60=.03b27502-93f7-4b3e-a7c3-70b7429ed04b@github.com>
Message-ID: <TShlxBYrhmRn9tH9o1JJR12XsbNDiikNtkQW23i9iO0=.de5fec32-51ce-418d-b939-d199b9b13bb5@github.com>

> `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java` crashes when run with `StressUnstableIfTraps` in the CI ([JDK-8367244](https://bugs.openjdk.org/browse/JDK-8367244)).
> 
> To reduce the noise in the CI, I'm temporarily passing `-XX:-StressUnstableIfTraps` to disable the stress mode.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:

  [lworld] Run TestAcmpWithUnstableIf.java without StressUnstableIfTraps until JDK-8367244 is fixed

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1635/files
  - new: https://git.openjdk.org/valhalla/pull/1635/files/7d33fbd1..1ab1c62f

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

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

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

From chagedorn at openjdk.org  Fri Sep 26 06:17:08 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 26 Sep 2025 06:17:08 GMT
Subject: [lworld] RFR: [lworld] Run
 compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java without
 StressUnstableIfTraps until JDK-8367244 is fixed
In-Reply-To: <nT2kEa_9jyBXxJa8iYpCFXcuZVOeo-HjjfmiCXgnB60=.03b27502-93f7-4b3e-a7c3-70b7429ed04b@github.com>
References: <nT2kEa_9jyBXxJa8iYpCFXcuZVOeo-HjjfmiCXgnB60=.03b27502-93f7-4b3e-a7c3-70b7429ed04b@github.com>
Message-ID: <iyOVmfQfjJzVVyIgx-tlZUYVBACucqWyWX-thEjts8w=.c127db3a-1463-4073-8d84-d54013dfdabd@github.com>

On Thu, 25 Sep 2025 15:48:15 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java` crashes when run with `StressUnstableIfTraps` in the CI ([JDK-8367244](https://bugs.openjdk.org/browse/JDK-8367244)).
> 
> To reduce the noise in the CI, I'm temporarily passing `-XX:-StressUnstableIfTraps` to disable the stress mode.
> 
> Thanks,
> Christian

I'm not sure but I think it does not hurt, either - updated, thanks for your review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1635#issuecomment-3336917537

From chagedorn at openjdk.org  Fri Sep 26 06:19:08 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 26 Sep 2025 06:19:08 GMT
Subject: [lworld] Integrated: 8367500: [lworld]
 compiler/valhalla/inlinetypes/TestTearing.java times out with C1 only
In-Reply-To: <ukb53PSUJ_GwZCBoqLr9so-NvgOQ_KJIMi799Rx7ltc=.64816e29-f08e-48ca-a9da-f4c78d6643dd@github.com>
References: <ukb53PSUJ_GwZCBoqLr9so-NvgOQ_KJIMi799Rx7ltc=.64816e29-f08e-48ca-a9da-f4c78d6643dd@github.com>
Message-ID: <Kreb_iOwQxu7MO86PAGrMaYAMyVT0zL5rrOP1-1NBy4=.bed96df8-edd5-42a3-9aae-c68578b5e305@github.com>

On Thu, 25 Sep 2025 14:58:19 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The test `compiler/valhalla/inlinetypes/TestTearing.java` regularly times out in tier5 when run with `-XX:TieredStopAtLevel=3`.
> 
> The reason is that we have a long running loop with 1 million iterations - simply too slow for C1 only. I took a measurement with just one of the several `@run` statements on my local machine. While the C2 run was finished within half a minute, it took the run with `-XX:TieredStopAtLevel=3` 20min.
> 
> I'm therefore proposing to use a much smaller loop limit for C1 only runs by defining a new jtreg header and an additional argument passed to `main()` to set it up correspondingly.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 2ea952ee
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2ea952ee176202a0ab08734d44579734673f6441
Stats:     56 lines in 1 file changed: 51 ins; 0 del; 5 mod

8367500: [lworld] compiler/valhalla/inlinetypes/TestTearing.java times out with C1 only

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

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

From chagedorn at openjdk.org  Fri Sep 26 06:19:45 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 26 Sep 2025 06:19:45 GMT
Subject: [lworld] Integrated: [lworld] Run
 compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java without
 StressUnstableIfTraps until JDK-8367244 is fixed
In-Reply-To: <nT2kEa_9jyBXxJa8iYpCFXcuZVOeo-HjjfmiCXgnB60=.03b27502-93f7-4b3e-a7c3-70b7429ed04b@github.com>
References: <nT2kEa_9jyBXxJa8iYpCFXcuZVOeo-HjjfmiCXgnB60=.03b27502-93f7-4b3e-a7c3-70b7429ed04b@github.com>
Message-ID: <xxDrW1WQ2R7ELuIOQURanPjoDXnn9FHsj0TMy8ybj6Q=.0c464ab9-5378-416c-9780-e3d7bf2ef535@github.com>

On Thu, 25 Sep 2025 15:48:15 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java` crashes when run with `StressUnstableIfTraps` in the CI ([JDK-8367244](https://bugs.openjdk.org/browse/JDK-8367244)).
> 
> To reduce the noise in the CI, I'm temporarily passing `-XX:-StressUnstableIfTraps` to disable the stress mode.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: f774a337
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f774a3374f959a2a2c7ff295bf2b08af7d10d458
Stats:     6 lines in 1 file changed: 3 ins; 0 del; 3 mod

[lworld] Run compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java without StressUnstableIfTraps until JDK-8367244 is fixed

Reviewed-by: mchevalier

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

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

From chagedorn at openjdk.org  Fri Sep 26 06:19:46 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 26 Sep 2025 06:19:46 GMT
Subject: [lworld] Integrated: 8348972: [lworld] C1/C2: Update Valhalla with
 UseCompactObjectHeaders for oop->klass load/stores
In-Reply-To: <i0KvRV-JavSIiNIk4YiI5iL6EUnYJHRyWccKxom0JiM=.9fa9dabf-e135-4b9d-9874-b4a88aa63ef3@github.com>
References: <i0KvRV-JavSIiNIk4YiI5iL6EUnYJHRyWccKxom0JiM=.9fa9dabf-e135-4b9d-9874-b4a88aa63ef3@github.com>
Message-ID: <IzcDZ2AX1z3rul7_No34kQJF0VAsHTosC5JvMZjcQYA=.70389fbd-296b-49b7-9a7b-5c5217594bbb@github.com>

On Thu, 25 Sep 2025 10:47:39 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch fixes various issues in C1 and C2 (11 bugs in total) when running with `-XX:+UseCompactObjectHeaders`.
> 
> Most of the bugs could either be traced back to:
> - Unconditionally assuming old layout with klass pointer following immediately the mark word.
> - Small mistakes when merging JEP 450.
> - Using the wrong basic type `T_OBJECT` for flat arrays instead of `T_FLAT_ELEMENT`. In Valhalla, we require that the elements of an array are aligned:https://github.com/openjdk/valhalla/blob/04efe5c66b70b9dca1a5c538c9a04e7ad93c107a/src/hotspot/share/oops/arrayOop.hpp#L94-L97
> https://github.com/openjdk/valhalla/blob/04efe5c66b70b9dca1a5c538c9a04e7ad93c107a/src/hotspot/share/oops/arrayOop.hpp#L57-L61
> When we now wrongly use `T_OBJECT`, it is not a problem with default flags (using compressed klass pointers and no COH): An array has a 12 byte header + 4 byte length which is 16 bytes in total - no alignment required. But with COH, we now have a header of 8 bytes + 4 byte length. We now require alignment but when we pass in `T_OBJECT`, we miss the alignment which leads to crashes down the line. I went through all the uses of `base_offset_in_bytes()` and fixed more such issues.
> 
> To review: I made separate commits for each fixed bug, each message summarizing the found issue. To better understand individual changes of the patch, it might help to look at the commits separately.
> 
> **Testing:**
> - Apart from one bug, I could trigger them with existing tests. So, I have not added new tests for these issues separately.
> - One bug only manifested with a new test (`test127a`) which I added with this patch.
> - tier1-5 + compiler stress:
>   - No additional flags, i.e. (mostly) without COH: Looks good and only known failures
>   - With explicitly setting COH:
>     - A lot of CDS related failures on which @matias9927 is working ([JDK-8367959](https://bugs.openjdk.org/browse/JDK-8367959))
>     - Test timeout with `TestIntrinsics`: Unrelated to COH but only triggering with COH ([JDK-8368274](https://bugs.openjdk.org/browse/JDK-8368274)).
>     - Otherwise, looks good with only known failures.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: df4b1cf3
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/df4b1cf335e238ba2e54de9065056bc97df0d7a8
Stats:     157 lines in 12 files changed: 93 ins; 37 del; 27 mod

8348972: [lworld] C1/C2: Update Valhalla with UseCompactObjectHeaders for oop->klass load/stores

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

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

From mhaessig at openjdk.org  Fri Sep 26 06:27:49 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 26 Sep 2025 06:27:49 GMT
Subject: [lworld] RFR: 8368519: [lworld]: TestRedundantLea.java#Spill fails
In-Reply-To: <v97Sk6uDVnawAsuRy_ahEFsoZG0FxeSvqijylBBp_9k=.63a15099-1056-462d-b9df-e9f7c7140d7c@github.com>
References: <v97Sk6uDVnawAsuRy_ahEFsoZG0FxeSvqijylBBp_9k=.63a15099-1056-462d-b9df-e9f7c7140d7c@github.com>
Message-ID: <1SeQGhAtAAk7SB51YDGtLteqtc8t4t77f21xzYl4dBg=.93de65ae-b8a5-41d5-85fb-eb2c682138c4@github.com>

On Thu, 25 Sep 2025 08:13:42 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> The test case `compiler/codegen/TestRedundantLea.java#Spill`, recently introduced in #1605, fails due to too strict node counts. This PR relaxes those node counts to account for differences in code generation between platforms and machines.
> 
> Testing:
>  - [x] tier1,tier2 plus stress testing

Thank you for reviewing, Christian!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1631#issuecomment-3336970615

From duke at openjdk.org  Fri Sep 26 06:27:50 2025
From: duke at openjdk.org (duke)
Date: Fri, 26 Sep 2025 06:27:50 GMT
Subject: [lworld] RFR: 8368519: [lworld]: TestRedundantLea.java#Spill fails
In-Reply-To: <v97Sk6uDVnawAsuRy_ahEFsoZG0FxeSvqijylBBp_9k=.63a15099-1056-462d-b9df-e9f7c7140d7c@github.com>
References: <v97Sk6uDVnawAsuRy_ahEFsoZG0FxeSvqijylBBp_9k=.63a15099-1056-462d-b9df-e9f7c7140d7c@github.com>
Message-ID: <SJpkpy3WOh0kbmEjBmpVMKJCZpn2lI_xfjHk3SIQJOA=.d40036f8-50ab-4b9e-a392-708bee87df25@github.com>

On Thu, 25 Sep 2025 08:13:42 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> The test case `compiler/codegen/TestRedundantLea.java#Spill`, recently introduced in #1605, fails due to too strict node counts. This PR relaxes those node counts to account for differences in code generation between platforms and machines.
> 
> Testing:
>  - [x] tier1,tier2 plus stress testing

@mhaessig 
Your change (at version 727734dc8b67545e2210d1c01b15fb41c6d039fa) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1631#issuecomment-3336972423

From mchevalier at openjdk.org  Fri Sep 26 08:37:38 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 26 Sep 2025 08:37:38 GMT
Subject: [lworld] RFR: 8368523: [lworld] fix
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java after jdk-26+7
 merge
Message-ID: <LHieoWtLuHCdRZo7HaxBYXDYIfx7HHHfMAOVwZDZmk0=.d7e0011c-ff12-4cc3-89b5-6df5a45c1724@github.com>

Details of how we ended up there are in the JBS issue.

Let's take the mainline version and put it in valhalla... Except that the mainline version doesn't need (and doesn't have) the `loadee` and `storee` parameters, but have the value `IS_REPLACED` for those. It's unfortunate since conflicts may happen again. Should be less bad.

It now passes the tests of `testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` again.

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

Commit messages:
 - Better load/store regexes

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

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

From chagedorn at openjdk.org  Fri Sep 26 14:09:20 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 26 Sep 2025 14:09:20 GMT
Subject: [lworld] RFR: 8368523: [lworld] fix
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java after jdk-26+7
 merge
In-Reply-To: <LHieoWtLuHCdRZo7HaxBYXDYIfx7HHHfMAOVwZDZmk0=.d7e0011c-ff12-4cc3-89b5-6df5a45c1724@github.com>
References: <LHieoWtLuHCdRZo7HaxBYXDYIfx7HHHfMAOVwZDZmk0=.d7e0011c-ff12-4cc3-89b5-6df5a45c1724@github.com>
Message-ID: <JeQztNCWAdhM_KumKmnEIy9tcXqwoaMxG8YdAwX4v6U=.c96a33af-ed3a-48d2-8f56-b64ea528da37@github.com>

On Fri, 26 Sep 2025 08:27:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Details of how we ended up there are in the JBS issue.
> 
> Let's take the mainline version and put it in valhalla... Except that the mainline version doesn't need (and doesn't have) the `loadee` and `storee` parameters, but have the value `IS_REPLACED` for those. It's unfortunate since conflicts may happen again. Should be less bad.
> 
> It now passes the tests of `testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` again.

Looks good! Thanks for taking care of that test!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1639#pullrequestreview-3272461698

From mhaessig at openjdk.org  Fri Sep 26 14:12:53 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 26 Sep 2025 14:12:53 GMT
Subject: [lworld] Integrated: 8368519: [lworld]: TestRedundantLea.java#Spill
 fails
In-Reply-To: <v97Sk6uDVnawAsuRy_ahEFsoZG0FxeSvqijylBBp_9k=.63a15099-1056-462d-b9df-e9f7c7140d7c@github.com>
References: <v97Sk6uDVnawAsuRy_ahEFsoZG0FxeSvqijylBBp_9k=.63a15099-1056-462d-b9df-e9f7c7140d7c@github.com>
Message-ID: <N8R42eNfsoi7vrPESPTUET6BuXKtgxIP8AGbmmELEKE=.ea5c26a9-a325-4a45-967d-ab7f62a63a43@github.com>

On Thu, 25 Sep 2025 08:13:42 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> The test case `compiler/codegen/TestRedundantLea.java#Spill`, recently introduced in #1605, fails due to too strict node counts. This PR relaxes those node counts to account for differences in code generation between platforms and machines.
> 
> Testing:
>  - [x] tier1,tier2 plus stress testing

This pull request has now been integrated.

Changeset: a0690dab
Author:    Manuel H?ssig <mhaessig at openjdk.org>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a0690dabcfc705b8352bb2f3aa6b69349e96f51b
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8368519: [lworld]: TestRedundantLea.java#Spill fails

Reviewed-by: chagedorn

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

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

From mchevalier at openjdk.org  Fri Sep 26 14:13:35 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 26 Sep 2025 14:13:35 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected"
Message-ID: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>

## Act I: dead loops

[JDK-8336003: [lworld] TestLWorld::test151 triggers "Should have been buffered" assert](https://bugs.openjdk.org/browse/JDK-8336003), allows to replace a Phi node by a single input recursively through phis. This change was only added to Valhalla. In mainline, a Phi can be simplified to its single direct input, not through other phis. The valhalla version will work on loops, while the mainline version will reduce all the phis into a single input only if the blob of Phis is acyclic.

When a loop is dead, it is possible that the said single input is also an output of the phi. After applying the identity, the phi's unique input becomes its own output (or input). For most nodes, that is not allowed. This is probably relatively harmless as the whole code around is dead and will be removed, but it makes some verification fail. It is also possible that some other idealization are not protected against data loops without phis on the way, and would not terminate. It is interesting to notice that applying [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to mainline is enough to reproduce the bug there too.

We could detect when it's about to happen, and handle the situation differently if we are about to create a very small loop that would be caught by the dead loop detection. It would be possible to make big dead data loop. How annoying that is? Immediately, there is the non-termination problem mentioned above. But also, maybe some nodes can be optimized away by IGVN and end up with a small loop and then the assert would strike again. Is the dead loop check too weak then? It depends what we think is the purpose of this check. During IGVN, we cannot clean up eagerly every dead loop since it would be too expensive to traverse everything. Avoiding dead data loop would also need a lot of traversal. My understanding is that it's rather a sanity check, to make sure that one doesn't mess up the graph surgery and create dead loops accidentally, when something else was meant, and detecting as soon as possible is helpful. So I'm not sure it's worth strengthening the check.

A way to avoid the creation of dead data loop is to simply limit the simplification allowed by [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to constant nodes: since they don't have input, they can't make a cycle! And it seems enough for the bug initially reported.

Yet, that makes `test151` in `compiler/valhalla/inlinetypes/TestLWorld.java` fail in another way: CCP does not reach a fixpoint.

## Act II: soundness, precision and monotony

The situation is a bit more messy, and doesn't make a great screenshot, but it boils down to:

`SomeNode` type:`MyValue2:NotNull` -> [... a lot of `PhiNode`s, with loops ...] -> `InlineTypeNode`

During IGVN, all the `PhiNode`s have type `MyValue2` (maybe null), since they always have at least one input that is a `PhiNode` of this maybe null type, and so does the `InlineTypeNode`. During CCP, because of

https://github.com/openjdk/valhalla/blob/7afbf295143dae458213513c30fb52245d75d7b4/src/hotspot/share/opto/inlinetypenode.cpp#L1640-L1643

when the inputs are all top at the beginning, the returned value for the `InlineTypeNode` is `MyValue2` (maybe null), which is the bottom type of this node. Yet, later the types of all the `PhiNode`s are increased from top to `MyValue2:NotNull`, which would allow to find a better type for the `InlineTypeNode`, but it is too late! `MyValue2` cannot be increased into `MyValue2:NotNull`. Replacing all the `PhiNode`s with the `SomeNode` obviously fixes it (but it introduces the dead loop that we are trying to solve here). The lack of monotonicity of `InlineTypeNode::Value` is dooming CCP.

Since starting CCP with the wrong `_type` in `InlineTypeNode` leads to the overapproximation, a solution could be to be more precise before CPP and rather refine during IGVN. It is possible to refine in many ways, inspired by [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) but they all come to more and more complicated failures, all similar to the original one. This really seems not to be a way to follow.

What I propose is to allow `InlineTypeNode` to give a top value, but no other constant. Indeed, if top, everything is dead anyway and on its way of dying, it is not the same as having a concrete, existing, constant value like having a constant buffer. Yet some care need to be taken in `InlineTypeNode* PhiNode::push_inline_types_down(PhaseGVN* phase, bool can_reshape, ciInlineKlass* inline_klass)`. This function changes a `Phi(InlineType(a, b, c), InlineType(d, e, f))` into `InlineType(Phi(a, d), Phi(b, e), Phi(c, f))`. This assumes that all the input of the original `Phi` are all `InlineTypeNode`, which is not the case after IGVN if `InlineTypeNode::Value` can return top. Thus, I extend `push_inline_types_down` to also accept top inputs to the phi, changing `Phi(InlineType(a, b, c), top)` into `InlineType(Phi(a, top), Phi(b, top), Phi(c, top))`, which is then cleaned up by IGVN. This is exercised by `test103` in `compiler/valhalla/inlinetypes/TestNullableInlineTypes.java`.

It is interesting to notice that does not prevent the same situation to happen again. Before, the scenario was:
1. input to the `InlineTypeNode` has type top
2. `InlineTypeNode::Value` is keeping itself from returning top, returns `MyValue` (from `_type`)
3. input is updated to `MyValue:NotNull`
4. `InlineTypeNode::Value` could return `MyValue:NotNull` but it's already bottom, too late.

Now, at step 2, `InlineTypeNode::Value` would return top, avoiding this to happen. But the slightly different scenario is still possible:
1. input to the `InlineTypeNode` has type top
2. `InlineTypeNode::Value` returns top
3. input is updated to some non-top constant
4. `InlineTypeNode::Value` is keeping itself from returning a constant, returns `MyValue` (from `_type`)
5. input is updated to `MyValue:NotNull`
6. `InlineTypeNode::Value` could return `MyValue:NotNull` but it's already bottom, too late.

It is not clear to me how likely this whole thing is, but I don't see how to avoid it without returning constant values from `InlineTypeNode::Value` or treating IGVN and CCP differently. For instance, it would be fine to return constant values for CCP, but not IGVN. It would also be fine, during CPP, to return the next immediately higher abstract value that we are allowed to return. For instance, if we have a lattice such that:
- `top` < all the constants < `MyValue:NotNull` < `MyValue`
we could return `MyValue:NotNull` instead of a non-top constant.

## Act III: ignoring the comment's wisdom

alright, so we get `InlineTypeNode::Value` possibly return top. Then what? The ominous

https://github.com/openjdk/valhalla/blob/7afbf295143dae458213513c30fb52245d75d7b4/src/hotspot/share/opto/inlinetypenode.cpp#L1641

is not there for no reason! It makes a couple of places assert, where they are doing some unprotected `Node::as_InlineType()`. While a constant buffer would be annoying, a constant top is relatively sensible to handle there. 

## Epilogue

I haven't added a special test as `test_004` in TestDeadIrreducibleLoopsMain.java does that very well, and I don't have a better idea of how to reproduce it without just duplicating the test. This case is pretty small already, there isn't much to reduce. All the other problems are also well covered with existing tests. I see little value in just copy pasting `test151` out of `TestLWorld.java` with no significant change or simplification.

Finally, tests seems passing not worse than on `lworld`.

Thanks,
Marc

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

Commit messages:
 - handle top in field_value_by_offset
 - Only simplify loop of phis into a constant + allow top for InlineTypeNode::Value

Changes: https://git.openjdk.org/valhalla/pull/1640/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1640&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367242
  Stats: 73 lines in 5 files changed: 62 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/valhalla/pull/1640.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1640/head:pull/1640

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

From mchevalier at openjdk.org  Fri Sep 26 14:14:57 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 26 Sep 2025 14:14:57 GMT
Subject: [lworld] RFR: 8368523: [lworld] fix
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java after jdk-26+7
 merge
In-Reply-To: <LHieoWtLuHCdRZo7HaxBYXDYIfx7HHHfMAOVwZDZmk0=.d7e0011c-ff12-4cc3-89b5-6df5a45c1724@github.com>
References: <LHieoWtLuHCdRZo7HaxBYXDYIfx7HHHfMAOVwZDZmk0=.d7e0011c-ff12-4cc3-89b5-6df5a45c1724@github.com>
Message-ID: <7f59njaGaSF3L0hEoqZqbrqdClF1Lk5yy_CEkWSER8U=.c6f5228c-4e83-45c6-8630-3d49dfda1248@github.com>

On Fri, 26 Sep 2025 08:27:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Details of how we ended up there are in the JBS issue.
> 
> Let's take the mainline version and put it in valhalla... Except that the mainline version doesn't need (and doesn't have) the `loadee` and `storee` parameters, but have the value `IS_REPLACED` for those. It's unfortunate since conflicts may happen again. Should be less bad.
> 
> It now passes the tests of `testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` again.

Sure! And thanks @chhagedorn for review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1639#issuecomment-3338914386

From duke at openjdk.org  Fri Sep 26 14:14:58 2025
From: duke at openjdk.org (duke)
Date: Fri, 26 Sep 2025 14:14:58 GMT
Subject: [lworld] RFR: 8368523: [lworld] fix
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java after jdk-26+7
 merge
In-Reply-To: <LHieoWtLuHCdRZo7HaxBYXDYIfx7HHHfMAOVwZDZmk0=.d7e0011c-ff12-4cc3-89b5-6df5a45c1724@github.com>
References: <LHieoWtLuHCdRZo7HaxBYXDYIfx7HHHfMAOVwZDZmk0=.d7e0011c-ff12-4cc3-89b5-6df5a45c1724@github.com>
Message-ID: <WuOXcvCvd0_SgiwAXcBoSnnp5L0FvGVZDIhg64jkq3o=.132d51cb-a5fa-431a-8307-1b0877ae661a@github.com>

On Fri, 26 Sep 2025 08:27:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Details of how we ended up there are in the JBS issue.
> 
> Let's take the mainline version and put it in valhalla... Except that the mainline version doesn't need (and doesn't have) the `loadee` and `storee` parameters, but have the value `IS_REPLACED` for those. It's unfortunate since conflicts may happen again. Should be less bad.
> 
> It now passes the tests of `testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` again.

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1639#issuecomment-3338919694

From dfenacci at openjdk.org  Fri Sep 26 15:06:54 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 26 Sep 2025 15:06:54 GMT
Subject: [lworld] RFR: 8367338: [lworld]
 compiler/gcbarriers/TestImplicitNullChecks.java fails
Message-ID: <UeatLbGLybkPfyTLIk2MkcTdnAmE2mMWklrzWblo5Xw=.729c4918-0ee4-45f6-88c9-cb7a4fe5d7b5@github.com>

# Issue
IR checks of `testCompareAndExchange`, `testCompareAndSwap` and `testGetAndSet` of  `compiler/gcbarriers/TestImplicitNullChecks.java` fail because they expect no  `NULL_CHECK` in the final code graph but it encounters a few in each test instead.

# Cause
The tests in question simply call 3 different `VarHandle` functions (one each) but these don't get inlined as intrinsics directly. They instead rely on inline methods (with some conditional statements) that eventually call a method that gets intrinsified. Unfortunately the compilation of some of the inlined code can result in null-checks after being compiled.
For instance `testCompareAndExchange` inlines `Unsafe::compareAndExchangeReference`
https://github.com/openjdk/valhalla/blob/1ecd2e95a158c80186d4334ca3f0673f660d5042/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L1723-L1742
which calls `compareAndSetReference` or `compareAndExchangeReference` but `if (valueType.isValue() || isValueObject(expected))` adds a null-check for `valueType`.
This happens only in Valhalla because of a Valhalla-specific value-type checks (see [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569)).

# Fix
The goal of the tests is to make sure that there are no null-checks with compare-and-exchange operations with ZGC and G1. Instead of relying on `VarHandle` compare-and-exchange-related methods we can use the equivalent `Unsafe` methods that are intrinsified directly.

# Testing
Tier 1-3+

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

Commit messages:
 - Merge branch 'lworld' into JDK-8367338
 - JDK-8367338: add exports to run command
 - JDK-8367338: use Unsafe
 - JDK-8367338: update comment
 - JDK-8367338: [lworld] compiler/gcbarriers/TestImplicitNullChecks.java fails

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

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

From jbhateja at openjdk.org  Fri Sep 26 16:01:36 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 26 Sep 2025 16:01:36 GMT
Subject: [lworld] RFR: 8367792: [lworld] Remove the Unsafe remnants of old
 valhalla prototypes
In-Reply-To: <vnLmnwhpHnh7Wfmmo2TD4qJhDa4dnib4HIXhic3Fsyk=.d4be4aba-4914-4a73-8d21-429ae4e680ae@github.com>
References: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
 <vnLmnwhpHnh7Wfmmo2TD4qJhDa4dnib4HIXhic3Fsyk=.d4be4aba-4914-4a73-8d21-429ae4e680ae@github.com>
Message-ID: <CNKXxqFFrRpuApLzmIjDRUSqKNlpntUbmbQHwPnaqEM=.d9c12557-1b16-4d20-af03-e97b5fec8d16@github.com>

On Wed, 17 Sep 2025 16:52:46 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.

Hi @liach , 

Currently, Unsafe.put* APIs expect to operate on a mutable value, without Unsafe.makePrivateBuffer, there is no way to transition a value object to larval state.

<img width="800" height="400" alt="image" src="https://github.com/user-attachments/assets/af826cda-55e1-4b0c-a2ea-62592f7623d6" />


Here is a typical update kernel for the nary operation fallback implementation. 

<img width="500" height="200" alt="image" src="https://github.com/user-attachments/assets/4a31baa7-52b8-4e0b-8c42-924407bb5665" />



**Here are some relevant FAQs on the need for multifield annotation.**

Q. Why do we need @multifield annotated field in VectorPayloads and not just retain the array-backed backing storage?
A.  Even currently, Vector instances are immutable, with each modification or application of an operation, a new vector is generated. 
      Each new vector has a distinct backing storage in the form of an array; thus, no two vector ever share their backing storage, which makes vectors an immutable quantity. 
      
     Vector<Float>  newVector  =  Vec1.lanewise(VectorOperators.ADD, Vec2);
     
Since arrays are always allocated over the heap, they carry an identity, which is the distinctive heap address for each new backing storage array.

This contradicts the philosophy of value type instances, which are identity-free; the compiler treats two values with the same contents as equivalent entities and is free to substitute one with another. 

By replacing existing array-backed storage with a @multifield annotated storage, we ensure that payload adheres to true value semantics, a @multifiled is seen as a bundle of fields, encapsulating payload is a value class, unlike an array, a multifield is never allocated an explicit heap storage. 

Here is an example code

 
<img width="388" height="503" alt="image" src="https://github.com/user-attachments/assets/8f6b5a07-a8e0-4912-b909-9d892f40d92a" />


Even though Payload is a value class, its two instances with the same backing storage are not equal, because arrays have identity.
By treating vectors as value objects, we expect that two vectors with the same contents should be equal.

Q.  Is there any alternative to @multifield?
A.  All we need to ensure is that the backing storage has no identity.  Thus, we could have multiple primitive type fields in the payload, one for each lane of the vector. 

 
<img width="450" height="310" alt="image" src="https://github.com/user-attachments/assets/af977c64-6373-4533-aceb-6d283cecd094" />

Consider the above modified payload class ?TrueValuePayload?, here we create a separate primitive type field for each lane of the vector, thus two vector values with the same contents are treated as equivalent entities. 

With @multifield we intend to create identity-free backing storage. 


Q.  What are the complications with explicit fields for each lane in the container payload?
A.  First, at load time, build_layout randomizes the fields' layout,  but that is not a major concern since fields can always be updated using their effective offsets.
A bigger concern is that the C2 compiler will see scalar fields as different inputs to InlineTypeNode. The compiler creates an InlineTypeNode for each instance of a value class and scalarizes the fields, with different scalar field we may observe multiple inputs to IR, one for each lane. Each scalar field will be of primitive Type, while the type of Type of InlineTypeNode will be PayloadType, since an inline type node corresponds to a value object. We expect to deal in vector-type field, i.e., the one that carry an ideal type TypeVect. 

Vector IR  is forwarded to its user every time we perform a vector_unbox operation over VectorPayload, this way, vector IR inputs are directly forwarded to the vector operation nodes.

Keeping multiple scalar fields, one for each lane type in the VectorPayload class, while creating a vector IR for a bundle of lanes, will result in adding kludges in the code.  Consider the following case

     var  v1 = FloatVector.fromArray(SP, arr1, index)
     var  v2 = FloatVector.fromArray(SP, arr2, index)
     res =  v1.lanewise(VectorOperators.ADD, v2)

    v1 and v2 are concrete vector class instances, where the vector class is a valuetype, with stock Valhalla, IR corresponding to fromArray API will look like the following

                                           
<img width="374" height="224" alt="image" src="https://github.com/user-attachments/assets/5f923efe-5b42-4e47-b04f-13abd4cfeee8" />


While the expected IR pallet should look like the following 

 
<img width="354" height="313" alt="image" src="https://github.com/user-attachments/assets/26d1ce93-f4d4-48fd-afaf-1b32a0904d2d" />

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

PR Comment: https://git.openjdk.org/valhalla/pull/1593#issuecomment-3339344741

From coleenp at openjdk.org  Fri Sep 26 19:20:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 26 Sep 2025 19:20:56 GMT
Subject: [lworld] RFR: 8367398: JCmdTestDynamicDump.java crashes on Windows
 with assert(m != nullptr) failed: nullptr mirror
In-Reply-To: <Gbd1OcuylbHP8zloxHExACjhtF4Er3n93UWWhtqfLLk=.8d808a7c-e256-4b7a-948c-f7340c135f4b@github.com>
References: <Gbd1OcuylbHP8zloxHExACjhtF4Er3n93UWWhtqfLLk=.8d808a7c-e256-4b7a-948c-f7340c135f4b@github.com>
Message-ID: <gzfww-3-bw954LGXCjA_J4OTjbPhhEAEyqwbH4MlzbU=.abf8e109-3f18-49b0-ad06-05c44b5cce9d@github.com>

On Wed, 24 Sep 2025 19:37:05 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> We avoid archiving refined objArrayKlasses in the dynamic archive due to issues mapping different dimensions of an array across the static and dynamic archives. One check was missed leading to a crash on Windows which is fixed in this patch.

Nice.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1629#pullrequestreview-3273604089

From fparain at openjdk.org  Fri Sep 26 19:20:55 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 26 Sep 2025 19:20:55 GMT
Subject: [lworld] RFR: 8367398: JCmdTestDynamicDump.java crashes on Windows
 with assert(m != nullptr) failed: nullptr mirror
In-Reply-To: <Gbd1OcuylbHP8zloxHExACjhtF4Er3n93UWWhtqfLLk=.8d808a7c-e256-4b7a-948c-f7340c135f4b@github.com>
References: <Gbd1OcuylbHP8zloxHExACjhtF4Er3n93UWWhtqfLLk=.8d808a7c-e256-4b7a-948c-f7340c135f4b@github.com>
Message-ID: <eU7dSo-gtqdkyQFB5dRMKVPY2j5qMiP5rgAB-VPZ8mw=.1b18b176-e94d-409d-8ce3-7229887a4c2d@github.com>

On Wed, 24 Sep 2025 19:37:05 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> We avoid archiving refined objArrayKlasses in the dynamic archive due to issues mapping different dimensions of an array across the static and dynamic archives. One check was missed leading to a crash on Windows which is fixed in this patch.

By curiosity, why dit it fail only on Windows?

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1629#pullrequestreview-3273598993

From matsaave at openjdk.org  Fri Sep 26 19:34:54 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 26 Sep 2025 19:34:54 GMT
Subject: [lworld] RFR: 8367398: JCmdTestDynamicDump.java crashes on Windows
 with assert(m != nullptr) failed: nullptr mirror
In-Reply-To: <eU7dSo-gtqdkyQFB5dRMKVPY2j5qMiP5rgAB-VPZ8mw=.1b18b176-e94d-409d-8ce3-7229887a4c2d@github.com>
References: <Gbd1OcuylbHP8zloxHExACjhtF4Er3n93UWWhtqfLLk=.8d808a7c-e256-4b7a-948c-f7340c135f4b@github.com>
 <eU7dSo-gtqdkyQFB5dRMKVPY2j5qMiP5rgAB-VPZ8mw=.1b18b176-e94d-409d-8ce3-7229887a4c2d@github.com>
Message-ID: <SuodTfMR3sMmFmuiQC_HelRKL8oAwAI3L_wewwP0qGg=.fc97d6af-f365-48b5-b4be-ac19d1ef4f43@github.com>

On Fri, 26 Sep 2025 19:15:42 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> By curiosity, why dit it fail only on Windows?

I couldn't figure out a good reason why it only failed on Windows and nowhere else since it seems to me that this should have failed across all platforms. I wasn't able to debug the issue directly so I found a solution analytically.

Thanks for the reviews @fparain and @coleenp!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1629#issuecomment-3340181599
PR Comment: https://git.openjdk.org/valhalla/pull/1629#issuecomment-3340185009

From matsaave at openjdk.org  Fri Sep 26 19:34:55 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 26 Sep 2025 19:34:55 GMT
Subject: [lworld] Integrated: 8367398: JCmdTestDynamicDump.java crashes on
 Windows with assert(m != nullptr) failed: nullptr mirror
In-Reply-To: <Gbd1OcuylbHP8zloxHExACjhtF4Er3n93UWWhtqfLLk=.8d808a7c-e256-4b7a-948c-f7340c135f4b@github.com>
References: <Gbd1OcuylbHP8zloxHExACjhtF4Er3n93UWWhtqfLLk=.8d808a7c-e256-4b7a-948c-f7340c135f4b@github.com>
Message-ID: <-k-pzoolL8SD9bzGv51Ul7tRY6qUSq9T058MNkvnjjs=.ac5baaa3-14ce-40e9-9d73-ad87db0c8ccd@github.com>

On Wed, 24 Sep 2025 19:37:05 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> We avoid archiving refined objArrayKlasses in the dynamic archive due to issues mapping different dimensions of an array across the static and dynamic archives. One check was missed leading to a crash on Windows which is fixed in this patch.

This pull request has now been integrated.

Changeset: a92246bf
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a92246bf144e6bbf40bc7c2e6feaa950183da8ac
Stats:     2 lines in 2 files changed: 0 ins; 1 del; 1 mod

8367398: JCmdTestDynamicDump.java crashes on Windows with assert(m != nullptr) failed: nullptr mirror

Reviewed-by: fparain, coleenp

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

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

From matsaave at openjdk.org  Fri Sep 26 19:35:15 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 26 Sep 2025 19:35:15 GMT
Subject: git: openjdk/valhalla: lworld: 8367398: JCmdTestDynamicDump.java
 crashes on Windows with assert(m != nullptr) failed: nullptr mirror
Message-ID: <504b4a70-696e-446c-b297-6e3c61723dcc@openjdk.org>

Changeset: a92246bf
Branch: lworld
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2025-09-26 19:31:53 +0000
URL:       https://git.openjdk.org/valhalla/commit/a92246bf144e6bbf40bc7c2e6feaa950183da8ac

8367398: JCmdTestDynamicDump.java crashes on Windows with assert(m != nullptr) failed: nullptr mirror

Reviewed-by: fparain, coleenp

! src/hotspot/share/oops/objArrayKlass.cpp
! test/hotspot/jtreg/ProblemList.txt


From liach at openjdk.org  Fri Sep 26 20:33:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Sep 2025 20:33:25 GMT
Subject: [lworld] RFR: Early larval frame should be toggled by preview
Message-ID: <UbHGKsuFqn4xhuLwM040SKptp5pWCj6VyinizmNHGa0=.76c4ec7f-a9b0-48e6-95d4-c3f91b8ac8a3@github.com>

Early larval frame should be generated by the value classes preview settings. To prevent strict presence without early larvals, add a preview check to block strict without value objects preview enabled.

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

Commit messages:
 - Early larval frame should be toggled by preview

Changes: https://git.openjdk.org/valhalla/pull/1637/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1637&range=00
  Stats: 12 lines in 5 files changed: 4 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/1637.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1637/head:pull/1637

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

From vromero at openjdk.org  Fri Sep 26 20:40:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Sep 2025 20:40:52 GMT
Subject: [lworld] RFR: 8368800: [lworld] Early larval frame and strict
 should be guarded by preview
In-Reply-To: <UbHGKsuFqn4xhuLwM040SKptp5pWCj6VyinizmNHGa0=.76c4ec7f-a9b0-48e6-95d4-c3f91b8ac8a3@github.com>
References: <UbHGKsuFqn4xhuLwM040SKptp5pWCj6VyinizmNHGa0=.76c4ec7f-a9b0-48e6-95d4-c3f91b8ac8a3@github.com>
Message-ID: <EEISOck8AFwoUwZjKbEbLKPVES-qGnEJ4wwR9emAbFk=.a52f0473-0adc-4c33-90b7-c12b18844d12@github.com>

On Thu, 25 Sep 2025 23:35:25 GMT, Chen Liang <liach at openjdk.org> wrote:

> Early larval frame should be generated by the value classes preview settings. To prevent strict presence without early larvals, add a preview check to block strict without value objects preview enabled.

Marked as reviewed by vromero (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1637#pullrequestreview-3273891015

From liach at openjdk.org  Fri Sep 26 22:01:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Sep 2025 22:01:53 GMT
Subject: [lworld] RFR: 8368800: [lworld] Early larval frame and strict
 should be guarded by preview
In-Reply-To: <UbHGKsuFqn4xhuLwM040SKptp5pWCj6VyinizmNHGa0=.76c4ec7f-a9b0-48e6-95d4-c3f91b8ac8a3@github.com>
References: <UbHGKsuFqn4xhuLwM040SKptp5pWCj6VyinizmNHGa0=.76c4ec7f-a9b0-48e6-95d4-c3f91b8ac8a3@github.com>
Message-ID: <fIM_J8AsOfevn4kM4QFTfBIBxLRwPyvH4OluX9GHD9M=.5752c381-e83f-4cc8-88a9-ed82a1ec87ab@github.com>

On Thu, 25 Sep 2025 23:35:25 GMT, Chen Liang <liach at openjdk.org> wrote:

> Early larval frame should be generated by the value classes preview settings. To prevent strict presence without early larvals, add a preview check to block strict without value objects preview enabled.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1637#issuecomment-3340634120

From liach at openjdk.org  Fri Sep 26 22:01:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Sep 2025 22:01:53 GMT
Subject: [lworld] Integrated: 8368800: [lworld] Early larval frame and strict
 should be guarded by preview
In-Reply-To: <UbHGKsuFqn4xhuLwM040SKptp5pWCj6VyinizmNHGa0=.76c4ec7f-a9b0-48e6-95d4-c3f91b8ac8a3@github.com>
References: <UbHGKsuFqn4xhuLwM040SKptp5pWCj6VyinizmNHGa0=.76c4ec7f-a9b0-48e6-95d4-c3f91b8ac8a3@github.com>
Message-ID: <eBG8V1h2JU1nGso9CDdeCWDxwmQFTVdo7oPdWlYXt-A=.5a11605a-1b8a-48dd-9bdc-938691da9b71@github.com>

On Thu, 25 Sep 2025 23:35:25 GMT, Chen Liang <liach at openjdk.org> wrote:

> Early larval frame should be generated by the value classes preview settings. To prevent strict presence without early larvals, add a preview check to block strict without value objects preview enabled.

This pull request has now been integrated.

Changeset: 855a2089
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/855a2089b7d844fc8b95ceecc2df699323ce9a96
Stats:     12 lines in 5 files changed: 4 ins; 4 del; 4 mod

8368800: [lworld] Early larval frame and strict should be guarded by preview

Reviewed-by: vromero

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

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

From liach at openjdk.org  Fri Sep 26 22:36:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 Sep 2025 22:36:40 GMT
Subject: [lworld] RFR: 8367792: [lworld] Remove the Unsafe remnants of old
 valhalla prototypes
In-Reply-To: <CNKXxqFFrRpuApLzmIjDRUSqKNlpntUbmbQHwPnaqEM=.d9c12557-1b16-4d20-af03-e97b5fec8d16@github.com>
References: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
 <vnLmnwhpHnh7Wfmmo2TD4qJhDa4dnib4HIXhic3Fsyk=.d4be4aba-4914-4a73-8d21-429ae4e680ae@github.com>
 <CNKXxqFFrRpuApLzmIjDRUSqKNlpntUbmbQHwPnaqEM=.d9c12557-1b16-4d20-af03-e97b5fec8d16@github.com>
Message-ID: <rcxiIhT-6gFMB_vBrh1t03Vwn8xJ_xC30-nc2dBvxck=.4d9f2802-388a-4dc1-8cdb-af240f1140c9@github.com>

On Fri, 26 Sep 2025 15:58:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> 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.
>
> Hi @liach , 
> 
> Currently, Unsafe.put* APIs expect to operate on a mutable value, without Unsafe.makePrivateBuffer, there is no way to transition a value object to larval state.
> 
> <img width="800" height="400" alt="image" src="https://github.com/user-attachments/assets/af826cda-55e1-4b0c-a2ea-62592f7623d6" />
> 
> 
> Here is a typical update kernel for the nary operation fallback implementation. 
> 
> <img width="500" height="200" alt="image" src="https://github.com/user-attachments/assets/4a31baa7-52b8-4e0b-8c42-924407bb5665" />
> 
> 
> 
> **Here are some relevant FAQs on the need for multifield annotation.**
> 
> Q. Why do we need @multifield annotated field in VectorPayloads and not just retain the array-backed backing storage?
> A.  Even currently, Vector instances are immutable, with each modification or application of an operation, a new vector is generated. 
>       Each new vector has a distinct backing storage in the form of an array; thus, no two vector ever share their backing storage, which makes vectors an immutable quantity. 
>       
>      Vector<Float>  newVector  =  Vec1.lanewise(VectorOperators.ADD, Vec2);
>      
> Since arrays are always allocated over the heap, they carry an identity, which is the distinctive heap address for each new backing storage array.
> 
> This contradicts the philosophy of value type instances, which are identity-free; the compiler treats two values with the same contents as equivalent entities and is free to substitute one with another. 
> 
> By replacing existing array-backed storage with a @multifield annotated storage, we ensure that payload adheres to true value semantics, a @multifiled is seen as a bundle of fields, encapsulating payload is a value class, unlike an array, a multifield is never allocated an explicit heap storage. 
> 
> Here is an example code
> 
>  
> <img width="388" height="503" alt="image" src="https://github.com/user-attachments/assets/8f6b5a07-a8e0-4912-b909-9d892f40d92a" />
> 
> 
> Even though Payload is a value class, its two instances with the same backing storage are not equal, because arrays have identity.
> By treating vectors as value objects, we expect that two vectors with the same contents should be equal.
> 
> Q.  Is there any alternative to @multifield?
> A.  All we need to ensure is that the backing storage has no identity.  Thus, we could have multiple primitive type fields in the payload, one for each lane of the vector. 
> 
>  
> <img width="450" height="310" alt="image" src="https://github.com/user-attachments/assets/af977c64-6373-4533-aceb-...

Hi @jatin-bhateja, as I know, the larval bit is completely unused in current Valhalla - I believe what we should do with that assert is to simply remove it. I am thinking of some internal API that accepts a Consumer that handles the "early larval" API via unsafe before returning it.

I thought the merge of lworld into vector would be trivial, but it turned out troublesome - can you push the merge as soon as it is ready? I am more than happy to help you migrate off makePrivateBuffer and this to-be-removed larval bit.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1593#issuecomment-3340696212

From vromero at openjdk.org  Sun Sep 28 00:42:01 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 28 Sep 2025 00:42:01 GMT
Subject: [lworld] Integrated: 8368812: [lworld] remove test
 ExtendedStandardFlagsOverlayFlagsConflict.java from problem list
Message-ID: <RuTmYnYBi3PvphKF7WFCei6FeDuk1T90kPuyj_9vGRA=.eedff1e8-b31f-43c2-801b-776f639ba71c@github.com>

simple PR removing one test from the problem list

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

Commit messages:
 - 8368812: [lworld] remove test ExtendedStandardFlagsOverlayFlagsConflict.java from problem list

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

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

From vromero at openjdk.org  Sun Sep 28 00:42:02 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 28 Sep 2025 00:42:02 GMT
Subject: [lworld] Integrated: 8368812: [lworld] remove test
 ExtendedStandardFlagsOverlayFlagsConflict.java from problem list
In-Reply-To: <RuTmYnYBi3PvphKF7WFCei6FeDuk1T90kPuyj_9vGRA=.eedff1e8-b31f-43c2-801b-776f639ba71c@github.com>
References: <RuTmYnYBi3PvphKF7WFCei6FeDuk1T90kPuyj_9vGRA=.eedff1e8-b31f-43c2-801b-776f639ba71c@github.com>
Message-ID: <Hmsze5oDIXaE3tc7b6nNhIKPpZ5UgwSk1T7iWCo1pcw=.e8608261-c56d-47a3-a8c7-1605ab0abd38@github.com>

On Sun, 28 Sep 2025 00:37:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> simple PR removing one test from the problem list

This pull request has now been integrated.

Changeset: f8fde230
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f8fde230a08c5d99b7c8e8c1ef6350807bf8eaf1
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8368812: [lworld] remove test ExtendedStandardFlagsOverlayFlagsConflict.java from problem list

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

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

From vromero at openjdk.org  Sun Sep 28 01:19:30 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 28 Sep 2025 01:19:30 GMT
Subject: [lworld] Integrated: 8368081: [lworld]
 tools/javac/processing/model/element/TestValueClasses.java `failing at line 8`
Message-ID: <WVj9kUqdy2SMm3basK9g9ngaAsbWD907K0hl2RIAils=.533259b2-4680-4022-b89a-c9d81b868e93@github.com>

simple PR, fixing test failing after merge

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

Commit messages:
 - 8368081: [lworld] tools/javac/processing/model/element/TestValueClasses.java

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

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

From vromero at openjdk.org  Sun Sep 28 01:19:30 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 28 Sep 2025 01:19:30 GMT
Subject: [lworld] Integrated: 8368081: [lworld]
 tools/javac/processing/model/element/TestValueClasses.java `failing at line 8`
In-Reply-To: <WVj9kUqdy2SMm3basK9g9ngaAsbWD907K0hl2RIAils=.533259b2-4680-4022-b89a-c9d81b868e93@github.com>
References: <WVj9kUqdy2SMm3basK9g9ngaAsbWD907K0hl2RIAils=.533259b2-4680-4022-b89a-c9d81b868e93@github.com>
Message-ID: <xJQIxc_cqMdwc4FrtrkK-AIDWj96CKJadzsBDkWKxqo=.e77addc8-4d59-45b1-a43c-e6dcdc345854@github.com>

On Sun, 28 Sep 2025 01:13:44 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> simple PR, fixing test failing after merge

This pull request has now been integrated.

Changeset: 85a05d28
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/85a05d28ba38801f82debc6c8ca2694682fd48e1
Stats:     4 lines in 2 files changed: 0 ins; 3 del; 1 mod

8368081: [lworld] tools/javac/processing/model/element/TestValueClasses.java `failing at line 8`

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

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

From rriggs at openjdk.org  Mon Sep 29 01:52:48 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 29 Sep 2025 01:52:48 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
Message-ID: <STcHR1GN0xmHp6VdRSx8z6N8GSslssb2TXqU9jr73Z8=.665dfa6d-a006-45ca-a226-1dc54d95bbf2@github.com>

On Tue, 23 Sep 2025 19:11:41 GMT, David Beaumont <duke at openjdk.org> wrote:

> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

src/java.base/share/native/libjimage/imageFile.hpp line 253:

> 251:         // Set on a "normal" (non-preview) location if a preview version of
> 252:         // it exists in the same module.
> 253:         FLAGS_HAS_PREVIEW_VERSION = 0x1,

To avoid confusion, the value and spelling of the flag should agree across all modules.
In ImageLocation and jimage/ModulesReference.

src/java.base/share/native/libjimage/imageFile.hpp line 259:

> 257:         // it exists in the same module.
> 258:         FLAGS_IS_PREVIEW_ONLY = 0x4
> 259:     };

A refactoring of the flags can avoid conflicting states.
FLAGS_IS_PREVIEW_VERSION = 2;   // set for preview version
FLAGS_NO_NORMAL_VERSION = 1;    // preserving the zero value for normal and no preview.

Create static methods in ImageLocation to perform the desired tests on flags.
The utility methods make the code easier to read.
Also define macros/function in the native code in ImageFile and jimage.

isPreviewVersion(flags) { return (flags & FLAGS_IS_PREVIEW_VERSION) != 0)}
isPreviewOnly(flags) { return (flags & FLAGS_IS_REVIEW_VERSION | FLAGS_NO_NORMAL_VERSION) == FLAGS_NO_NORMAL_VERSION}

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2386501648
PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2386508298

From rriggs at openjdk.org  Mon Sep 29 01:53:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 29 Sep 2025 01:53:52 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
 [v4]
In-Reply-To: <Lg_cYHpbac0f-V7dX_6p5sUXnUc2AR1bUnA-_f8qFwM=.a48980ab-c53c-43f8-8b03-f78baac081d8@github.com>
References: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
 <Lg_cYHpbac0f-V7dX_6p5sUXnUc2AR1bUnA-_f8qFwM=.a48980ab-c53c-43f8-8b03-f78baac081d8@github.com>
Message-ID: <SYN2_yQHgXuNhT1f96CPzo8EBgD-9VQIO87uEf41Idc=.7cf11a5e-f1c9-4090-b67c-63121b23ad06@github.com>

On Tue, 23 Sep 2025 23:07:18 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
>> 
>> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
>> 
>> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
>> 
>> This should be review against https://github.com/openjdk/valhalla/pull/1621.
>
> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Copy value classes into preview directories for inclusion in jimage
>  - Restoring lost changes and updating some comments.
>  - add system property guard to preview mode
>  - jimage writer changes to support preview mode.
>    
>    * Remove TODOs now jimage version is bumped
>    * jimage writer changes to support preview mode.
>  - Manually deleting ImageReaderFactory (it returned somehow)

make/CompileJavaModules.gmk line 184:

> 182: 
> 183:     TARGETS += $(PREVIEW_OUTPUTDIR)/_copy_valueclasses.marker
> 184: 

I expect build reviewer will suggest using the SetupCopyFiles mechanism to copy files.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1622#discussion_r2383475070

From rriggs at openjdk.org  Mon Sep 29 01:53:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 29 Sep 2025 01:53:57 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v3]
In-Reply-To: <GXRcWlgy-5WY0DM560h8AHexiI9CLGFUNyG_ogpczRs=.03766e7d-d426-490e-9908-7c5daca4ac51@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
 <GXRcWlgy-5WY0DM560h8AHexiI9CLGFUNyG_ogpczRs=.03766e7d-d426-490e-9908-7c5daca4ac51@github.com>
Message-ID: <w-7Ab6qD3FDRW7XY9D-on6p7GeG0ZDrTEGUYnYNZcWg=.fe294df5-d4e4-48f3-a725-26c8485e83b2@github.com>

On Tue, 23 Sep 2025 23:07:47 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>> 
>> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.
>
> David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains four new commits since the last revision:
> 
>  - Restoring lost changes and updating some comments.
>  - add system property guard to preview mode
>  - jimage writer changes to support preview mode.
>    
>    * Remove TODOs now jimage version is bumped
>    * jimage writer changes to support preview mode.
>  - Manually deleting ImageReaderFactory (it returned somehow)

src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 445:

> 443:                 // Only 2 choices, either the "/modules" or "/packages" root.
> 444:                 assert isRootDir() : "Invalid root directory: " + getFullName();
> 445:                 return (getFlags() & FLAGS_IS_PACKAGE_ROOT) != 0

Introducing a flag bit that is carried around in lots of entries but applies to only one is overkill.
The simple test above for the first letter is cleaner and very localized.

src/java.base/share/classes/jdk/internal/jimage/PreviewMode.java line 68:

> 66:             if (!ENABLE_PREVIEW_MODE) {
> 67:                 return false;
> 68:             }

As commented in the 1618 PR, the extra subclasses caused by the overrides can be replaced by the resolve method switching on `ordinal()`.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageLocationWriter.java line 58:

> 56:     static ImageLocationWriter newLocation(String fullName,
> 57:                                            ImageStringsWriter strings,
> 58:                                            long contentOffset, long compressedSize, long uncompressedSize, int previewFlags) {

Wrap or untab to avoid long lines.

test/jdk/jdk/internal/jimage/ImageReaderTest.java line 107:

> 105:             "/modules/modfoo/com/foo/bar"})
> 106:     public void testModuleDirectories_expected(String name) throws IOException {
> 107:         try (ImageReader reader = ImageReader.open(image, PreviewMode.DISABLED)) {

The `image` variable might be better documented in upper case to make it easier to see its a pre-computed value.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2380657663
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2383305695
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2383319595
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2383427549

From rriggs at openjdk.org  Mon Sep 29 01:54:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 29 Sep 2025 01:54:00 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
Message-ID: <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>

On Tue, 23 Sep 2025 23:06:28 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
>> 
>> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Manually deleting ImageReaderFactory (it returned somehow)

src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java line 42:

> 40:  * <ul>
> 41:  *     <li>src/java.base/share/native/libjimage/imageFile.hpp
> 42:  * </ul>

Are there any java source files that have to be updated on a version change?

src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 56:

> 54:     /**
> 55:      * Indicates that a non-preview location is associated with preview
> 56:      * resources.

This comment would read better saying that preview resources exist related to this location.
More like FLAGS_HAS_PREVIEW_VERSION.

src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 72:

> 70:      * <p>This flag is mutually exclusive with {@link #FLAGS_HAS_PREVIEW_VERSION}.
> 71:      */
> 72:     public static final int FLAGS_IS_PREVIEW_VERSION = 0x2;

Seems to be redundant with HAS_PREVIEW_VERSION when seen in a preview location.

src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 87:

> 85:      * for {@code /packages/xxx} directories).
> 86:      */
> 87:     public static final int FLAGS_IS_PREVIEW_ONLY = 0x4;

The preview-only case is expected to be the empty set. There seems to be a lot of code dedicated to it.

src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 104:

> 102:     /**
> 103:      * Helper function to calculate preview flags (ATTRIBUTE_PREVIEW_FLAGS).
> 104:      *

A summary of what gets what flags might be easier to read than the code.
Or list the flags and refer to their descriptions (that would describe the paths where the flags would be found)

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 52:

> 50: 
> 51: import static jdk.internal.jimage.ImageLocation.FLAGS_HAS_PREVIEW_VERSION;
> 52: import static jdk.internal.jimage.ImageLocation.FLAGS_IS_PREVIEW_ONLY;

Import utility methods not flags.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 333:

> 331:                 // it references have that package marked as preview only.
> 332:                 // Skipping these entries avoids empty package subdirectories.
> 333:                 if (previewMode || (flags & FLAGS_IS_PREVIEW_ONLY) == 0) {

Add utility methods for FLAGS_IS_PREVIEW_ONLY == 0

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 336:

> 334:                     pkgDirs.add(ensureCached(newDirectory(pkgDir.getFullName())));
> 335:                 }
> 336:                 if (!previewMode || (flags & FLAGS_HAS_PREVIEW_VERSION) == 0) {

Add utility methods for FLAGS_HAS_PREVIEW_VERSION == 0

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 559:

> 557:             loc = findLocation(name.substring(MODULES_PREFIX.length()));
> 558:             return ensureCachedIfNonNull(
> 559:                     loc != null && loc.getType() == RESOURCE ? newResource(name, loc) : null);

It seems odd to test loc and type to produce a null and them pass it to a method that will do nothing.
The non-productive test can be done and return immediately.

src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 66:

> 64:     private static final int FLAGS_HAS_NORMAL_VERSION = 0x2;
> 65:     /** If set, this package exists in preview mode. */
> 66:     private static final int FLAGS_HAS_PREVIEW_VERSION = 0x4;

The flags should be aligned with ImageLocation to avoid confusion. Even if in different contexts the meaning (and bits) should be the same to carry-over the concepts.

The encapsulation of tests for flags helps. It might help in ImageLocation too.

src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 86:

> 84:         return new ModuleReference(moduleName, FLAGS_HAS_CONTENT | previewFlag(isPreview));
> 85:     }
> 86: 

Using "of" as the prefix for the method name instead of "for" would align better with many other APIs.

src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 122:

> 120:     public boolean hasContent() {
> 121:         return ((flags & FLAGS_HAS_CONTENT) != 0);
> 122:     }

isEmpty could avoid introducing "content" as a loosely defined term.
It would be more similar to directories being empty or lists being empty.

src/java.base/share/classes/jdk/internal/jimage/PreviewMode.java line 65:

> 63:     FOR_RUNTIME() {
> 64:         @Override
> 65:         boolean resolve() {

Each of these overrides creates an extra subclass.
The alternative is for the resolve method use a switch on the ordinal to return or compute the boolean.

src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java line 125:

> 123:         } else if (envValue instanceof String && Boolean.parseBoolean((String) envValue)) {
> 124:             return PreviewMode.ENABLED;
> 125:         }

This kind of ambiguous type for the environment variable should not be supported. 
Pick a type and stick to it.  
Whereever the jrt: file system is specified will need a description for enablePreview to be added to the spec.

src/java.base/share/classes/jdk/internal/jrtfs/SystemImage.java line 79:

> 77: 
> 78:         // TODO: Maybe throw if enablePreview attempted for exploded image?
> 79: 

Exploded image is useful for debugging, it could support preview mode using the same META-INF directory structure.

test/jdk/jdk/internal/jimage/ModuleReferenceTest.java line 228:

> 226: 
> 227:     // Encodes strings sequentially starting from index 100.
> 228:     private static Function<String, Integer> testEncoder() {

The method name `testEncoder` gives the impression of being a test, but it is just a utility function used by a test.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2376687644
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2376698440
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2376691515
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2376692449
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2376695695
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2376763692
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2376761704
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2376762324
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2377060646
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2376721829
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2376723293
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2376727666
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2376736057
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2377095899
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2377110493
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2380652378

From mchevalier at openjdk.org  Mon Sep 29 06:45:46 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 29 Sep 2025 06:45:46 GMT
Subject: [lworld] Integrated: 8368523: [lworld] fix
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java after jdk-26+7
 merge
In-Reply-To: <LHieoWtLuHCdRZo7HaxBYXDYIfx7HHHfMAOVwZDZmk0=.d7e0011c-ff12-4cc3-89b5-6df5a45c1724@github.com>
References: <LHieoWtLuHCdRZo7HaxBYXDYIfx7HHHfMAOVwZDZmk0=.d7e0011c-ff12-4cc3-89b5-6df5a45c1724@github.com>
Message-ID: <AIgOONYco7YIHwdhDpZ7jTzYrFDaSSNpxrifoI4m554=.a92d63f6-1581-4e8c-87ec-0c17d7e0169b@github.com>

On Fri, 26 Sep 2025 08:27:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Details of how we ended up there are in the JBS issue.
> 
> Let's take the mainline version and put it in valhalla... Except that the mainline version doesn't need (and doesn't have) the `loadee` and `storee` parameters, but have the value `IS_REPLACED` for those. It's unfortunate since conflicts may happen again. Should be less bad.
> 
> It now passes the tests of `testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` again.

This pull request has now been integrated.

Changeset: 708b4f92
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/708b4f92431df90c115dac840fb8194ec3aac3fe
Stats:     16 lines in 1 file changed: 12 ins; 2 del; 2 mod

8368523: [lworld] fix testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java after jdk-26+7 merge

Reviewed-by: chagedorn

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

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

From thartmann at openjdk.org  Mon Sep 29 06:53:07 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 29 Sep 2025 06:53:07 GMT
Subject: [lworld] RFR: 8348972: [lworld] C1/C2: Update Valhalla with
 UseCompactObjectHeaders for oop->klass load/stores
In-Reply-To: <i0KvRV-JavSIiNIk4YiI5iL6EUnYJHRyWccKxom0JiM=.9fa9dabf-e135-4b9d-9874-b4a88aa63ef3@github.com>
References: <i0KvRV-JavSIiNIk4YiI5iL6EUnYJHRyWccKxom0JiM=.9fa9dabf-e135-4b9d-9874-b4a88aa63ef3@github.com>
Message-ID: <N7KjkI76jy5LAxonfnsfUmCIW5RzRsmSp603Y4jDjmM=.f6e66f85-9fae-4533-858d-17db04c1ba19@github.com>

On Thu, 25 Sep 2025 10:47:39 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch fixes various issues in C1 and C2 (11 bugs in total) when running with `-XX:+UseCompactObjectHeaders`.
> 
> Most of the bugs could either be traced back to:
> - Unconditionally assuming old layout with klass pointer following immediately the mark word.
> - Small mistakes when merging JEP 450.
> - Using the wrong basic type `T_OBJECT` for flat arrays instead of `T_FLAT_ELEMENT`. In Valhalla, we require that the elements of an array are aligned:https://github.com/openjdk/valhalla/blob/04efe5c66b70b9dca1a5c538c9a04e7ad93c107a/src/hotspot/share/oops/arrayOop.hpp#L94-L97
> https://github.com/openjdk/valhalla/blob/04efe5c66b70b9dca1a5c538c9a04e7ad93c107a/src/hotspot/share/oops/arrayOop.hpp#L57-L61
> When we now wrongly use `T_OBJECT`, it is not a problem with default flags (using compressed klass pointers and no COH): An array has a 12 byte header + 4 byte length which is 16 bytes in total - no alignment required. But with COH, we now have a header of 8 bytes + 4 byte length. We now require alignment but when we pass in `T_OBJECT`, we miss the alignment which leads to crashes down the line. I went through all the uses of `base_offset_in_bytes()` and fixed more such issues.
> 
> To review: I made separate commits for each fixed bug, each message summarizing the found issue. To better understand individual changes of the patch, it might help to look at the commits separately.
> 
> **Testing:**
> - Apart from one bug, I could trigger them with existing tests. So, I have not added new tests for these issues separately.
> - One bug only manifested with a new test (`test127a`) which I added with this patch.
> - tier1-5 + compiler stress:
>   - No additional flags, i.e. (mostly) without COH: Looks good and only known failures
>   - With explicitly setting COH:
>     - A lot of CDS related failures on which @matias9927 is working ([JDK-8367959](https://bugs.openjdk.org/browse/JDK-8367959))
>     - Test timeout with `TestIntrinsics`: Unrelated to COH but only triggering with COH ([JDK-8368274](https://bugs.openjdk.org/browse/JDK-8368274)).
>     - Otherwise, looks good with only known failures.
> 
> Thanks,
> Christian

Post mortem reviewing this:
Looks good to me. Thanks a lot for all your effort Christian!

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

PR Review: https://git.openjdk.org/valhalla/pull/1632#pullrequestreview-3278156583

From rcastanedalo at openjdk.org  Mon Sep 29 08:15:40 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 29 Sep 2025 08:15:40 GMT
Subject: [lworld] RFR: 8367338: [lworld]
 compiler/gcbarriers/TestImplicitNullChecks.java fails
In-Reply-To: <UeatLbGLybkPfyTLIk2MkcTdnAmE2mMWklrzWblo5Xw=.729c4918-0ee4-45f6-88c9-cb7a4fe5d7b5@github.com>
References: <UeatLbGLybkPfyTLIk2MkcTdnAmE2mMWklrzWblo5Xw=.729c4918-0ee4-45f6-88c9-cb7a4fe5d7b5@github.com>
Message-ID: <bIkA7aMJY8cxAGkSGg86dreUejwX5RCA5mEtigXbtQM=.67a172ed-70a8-4655-bb37-448117d1fd62@github.com>

On Wed, 24 Sep 2025 15:36:04 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> # Issue
> IR checks of `testCompareAndExchange`, `testCompareAndSwap` and `testGetAndSet` of  `compiler/gcbarriers/TestImplicitNullChecks.java` fail because they expect no  `NULL_CHECK` in the final code graph but it encounters a few in each test instead.
> 
> # Cause
> The tests in question simply call 3 different `VarHandle` functions (one each) but these don't get inlined as intrinsics directly. They instead rely on inline methods (with some conditional statements) that eventually call a method that gets intrinsified. Unfortunately the compilation of some of the inlined code can result in null-checks after being compiled.
> For instance `testCompareAndExchange` inlines `Unsafe::compareAndExchangeReference`
> https://github.com/openjdk/valhalla/blob/1ecd2e95a158c80186d4334ca3f0673f660d5042/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L1723-L1742
> which calls `compareAndSetReference` or `compareAndExchangeReference` but `if (valueType.isValue() || isValueObject(expected))` adds a null-check for `valueType`.
> This happens only in Valhalla because of a Valhalla-specific value-type checks (see [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569)).
> 
> # Fix
> The goal of the tests is to make sure that there are no null-checks with compare-and-exchange operations with ZGC and G1. Instead of relying on `VarHandle` compare-and-exchange-related methods we can use the equivalent `Unsafe` methods that are intrinsified directly.
> 
> # Testing
> Tier 1-3+

`fVarHandle` is unused now and can be removed (together with all the code and imports around it).

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

PR Review: https://git.openjdk.org/valhalla/pull/1626#pullrequestreview-3278458832

From dfenacci at openjdk.org  Mon Sep 29 08:54:32 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 29 Sep 2025 08:54:32 GMT
Subject: [lworld] RFR: 8367338: [lworld]
 compiler/gcbarriers/TestImplicitNullChecks.java fails [v2]
In-Reply-To: <UeatLbGLybkPfyTLIk2MkcTdnAmE2mMWklrzWblo5Xw=.729c4918-0ee4-45f6-88c9-cb7a4fe5d7b5@github.com>
References: <UeatLbGLybkPfyTLIk2MkcTdnAmE2mMWklrzWblo5Xw=.729c4918-0ee4-45f6-88c9-cb7a4fe5d7b5@github.com>
Message-ID: <6h0zf9CD-y0SHn4dDbxBlsBLM2He6TvJ9wVC73oKH_0=.d34ae4b2-59a6-4924-b008-9af4fef43c5e@github.com>

> # Issue
> IR checks of `testCompareAndExchange`, `testCompareAndSwap` and `testGetAndSet` of  `compiler/gcbarriers/TestImplicitNullChecks.java` fail because they expect no  `NULL_CHECK` in the final code graph but it encounters a few in each test instead.
> 
> # Cause
> The tests in question simply call 3 different `VarHandle` functions (one each) but these don't get inlined as intrinsics directly. They instead rely on inline methods (with some conditional statements) that eventually call a method that gets intrinsified. Unfortunately the compilation of some of the inlined code can result in null-checks after being compiled.
> For instance `testCompareAndExchange` inlines `Unsafe::compareAndExchangeReference`
> https://github.com/openjdk/valhalla/blob/1ecd2e95a158c80186d4334ca3f0673f660d5042/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L1723-L1742
> which calls `compareAndSetReference` or `compareAndExchangeReference` but `if (valueType.isValue() || isValueObject(expected))` adds a null-check for `valueType`.
> This happens only in Valhalla because of a Valhalla-specific value-type checks (see [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569)).
> 
> # Fix
> The goal of the tests is to make sure that there are no null-checks with compare-and-exchange operations with ZGC and G1. Instead of relying on `VarHandle` compare-and-exchange-related methods we can use the equivalent `Unsafe` methods that are intrinsified directly.
> 
> # Testing
> Tier 1-3+

Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8367338: remove unused VarHandle

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1626/files
  - new: https://git.openjdk.org/valhalla/pull/1626/files/41c0733f..cb9e02c9

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

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

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

From dfenacci at openjdk.org  Mon Sep 29 08:54:33 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 29 Sep 2025 08:54:33 GMT
Subject: [lworld] RFR: 8367338: [lworld]
 compiler/gcbarriers/TestImplicitNullChecks.java fails [v2]
In-Reply-To: <bIkA7aMJY8cxAGkSGg86dreUejwX5RCA5mEtigXbtQM=.67a172ed-70a8-4655-bb37-448117d1fd62@github.com>
References: <UeatLbGLybkPfyTLIk2MkcTdnAmE2mMWklrzWblo5Xw=.729c4918-0ee4-45f6-88c9-cb7a4fe5d7b5@github.com>
 <bIkA7aMJY8cxAGkSGg86dreUejwX5RCA5mEtigXbtQM=.67a172ed-70a8-4655-bb37-448117d1fd62@github.com>
Message-ID: <XKy6Ud4q8TMIWMP_vA3yazzwLUwthottRlqM4sV_x9U=.04dae21e-5c0f-46bc-a44c-c9d4a18f7f7c@github.com>

On Mon, 29 Sep 2025 08:13:05 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> `fVarHandle` is unused now and can be removed (together with all the code and imports around it).

Right! Removed. Thanks @robcasloz.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1626#issuecomment-3345763325

From rcastanedalo at openjdk.org  Mon Sep 29 11:11:44 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 29 Sep 2025 11:11:44 GMT
Subject: [lworld] RFR: 8367338: [lworld]
 compiler/gcbarriers/TestImplicitNullChecks.java fails [v2]
In-Reply-To: <6h0zf9CD-y0SHn4dDbxBlsBLM2He6TvJ9wVC73oKH_0=.d34ae4b2-59a6-4924-b008-9af4fef43c5e@github.com>
References: <UeatLbGLybkPfyTLIk2MkcTdnAmE2mMWklrzWblo5Xw=.729c4918-0ee4-45f6-88c9-cb7a4fe5d7b5@github.com>
 <6h0zf9CD-y0SHn4dDbxBlsBLM2He6TvJ9wVC73oKH_0=.d34ae4b2-59a6-4924-b008-9af4fef43c5e@github.com>
Message-ID: <zalKnBQiFAUGCSXFp-7x29J_1QfZiq-93BvSjZTDbAU=.1e26f300-24f6-472a-91aa-521ca66b2051@github.com>

On Mon, 29 Sep 2025 08:54:32 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> # Issue
>> IR checks of `testCompareAndExchange`, `testCompareAndSwap` and `testGetAndSet` of  `compiler/gcbarriers/TestImplicitNullChecks.java` fail because they expect no  `NULL_CHECK` in the final code graph but it encounters a few in each test instead.
>> 
>> # Cause
>> The tests in question simply call 3 different `VarHandle` functions (one each) but these don't get inlined as intrinsics directly. They instead rely on inline methods (with some conditional statements) that eventually call a method that gets intrinsified. Unfortunately the compilation of some of the inlined code can result in null-checks after being compiled.
>> For instance `testCompareAndExchange` inlines `Unsafe::compareAndExchangeReference`
>> https://github.com/openjdk/valhalla/blob/1ecd2e95a158c80186d4334ca3f0673f660d5042/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L1723-L1742
>> which calls `compareAndSetReference` or `compareAndExchangeReference` but `if (valueType.isValue() || isValueObject(expected))` adds a null-check for `valueType`.
>> This happens only in Valhalla because of a Valhalla-specific value-type checks (see [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569)).
>> 
>> # Fix
>> The goal of the tests is to make sure that there are no null-checks with compare-and-exchange operations with ZGC and G1. Instead of relying on `VarHandle` compare-and-exchange-related methods we can use the equivalent `Unsafe` methods that are intrinsified directly.
>> 
>> # Testing
>> Tier 1-3+
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8367338: remove unused VarHandle

Marked as reviewed by rcastanedalo (no project role).

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

PR Review: https://git.openjdk.org/valhalla/pull/1626#pullrequestreview-3279153831

From rriggs at openjdk.org  Mon Sep 29 14:46:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 29 Sep 2025 14:46:00 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <STcHR1GN0xmHp6VdRSx8z6N8GSslssb2TXqU9jr73Z8=.665dfa6d-a006-45ca-a226-1dc54d95bbf2@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <STcHR1GN0xmHp6VdRSx8z6N8GSslssb2TXqU9jr73Z8=.665dfa6d-a006-45ca-a226-1dc54d95bbf2@github.com>
Message-ID: <GvXtJ7RzLojuwFahtA9YkiCvxXzM46Myxet2SdvGSTs=.009f7f21-eff7-4ecc-8ab7-0c26bf4d5cf3@github.com>

On Mon, 29 Sep 2025 01:50:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).
>
> src/java.base/share/native/libjimage/imageFile.hpp line 259:
> 
>> 257:         // it exists in the same module.
>> 258:         FLAGS_IS_PREVIEW_ONLY = 0x4
>> 259:     };
> 
> A refactoring of the flags can avoid conflicting states.
> FLAGS_IS_PREVIEW_VERSION = 2;   // set for preview version
> FLAGS_NO_NORMAL_VERSION = 1;    // preserving the zero value for normal and no preview.
> 
> Create static methods in ImageLocation to perform the desired tests on flags.
> The utility methods make the code easier to read.
> Also define macros/function in the native code in ImageFile and jimage.
> 
> isPreviewVersion(flags) { return (flags & FLAGS_IS_PREVIEW_VERSION) != 0)}
> isPreviewOnly(flags) { return (flags & FLAGS_IS_REVIEW_VERSION | FLAGS_NO_NORMAL_VERSION) == FLAGS_NO_NORMAL_VERSION}

Reprise:

Your name FLAGS_IS_PREVIEW_ONLY probably better than FLAGS_NO_NORMAL_VERSION and has the same semantics.

FLAGS_HAS_PREVIEW_VERSION means that there is a preview version and it will be found in the <META-INF/Preview> hierarchy. if the flag is in the preview node then this is it. If found in the normal hierarchy, the preview class is found in the <META-INF/Preview> hierarchy.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2388252261

From thartmann at openjdk.org  Mon Sep 29 15:00:32 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 29 Sep 2025 15:00:32 GMT
Subject: [lworld] RFR: 8367338: [lworld]
 compiler/gcbarriers/TestImplicitNullChecks.java fails [v2]
In-Reply-To: <6h0zf9CD-y0SHn4dDbxBlsBLM2He6TvJ9wVC73oKH_0=.d34ae4b2-59a6-4924-b008-9af4fef43c5e@github.com>
References: <UeatLbGLybkPfyTLIk2MkcTdnAmE2mMWklrzWblo5Xw=.729c4918-0ee4-45f6-88c9-cb7a4fe5d7b5@github.com>
 <6h0zf9CD-y0SHn4dDbxBlsBLM2He6TvJ9wVC73oKH_0=.d34ae4b2-59a6-4924-b008-9af4fef43c5e@github.com>
Message-ID: <Myza0UGEy_UXYQKSHEen3SVw4b_yhdmXOQzzYo9CzA0=.8a28180d-ec20-4c33-b3d4-2bf0ecb5f326@github.com>

On Mon, 29 Sep 2025 08:54:32 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> # Issue
>> IR checks of `testCompareAndExchange`, `testCompareAndSwap` and `testGetAndSet` of  `compiler/gcbarriers/TestImplicitNullChecks.java` fail because they expect no  `NULL_CHECK` in the final code graph but it encounters a few in each test instead.
>> 
>> # Cause
>> The tests in question simply call 3 different `VarHandle` functions (one each) but these don't get inlined as intrinsics directly. They instead rely on inline methods (with some conditional statements) that eventually call a method that gets intrinsified. Unfortunately the compilation of some of the inlined code can result in null-checks after being compiled.
>> For instance `testCompareAndExchange` inlines `Unsafe::compareAndExchangeReference`
>> https://github.com/openjdk/valhalla/blob/1ecd2e95a158c80186d4334ca3f0673f660d5042/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L1723-L1742
>> which calls `compareAndSetReference` or `compareAndExchangeReference` but `if (valueType.isValue() || isValueObject(expected))` adds a null-check for `valueType`.
>> This happens only in Valhalla because of a Valhalla-specific value-type checks (see [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569)).
>> 
>> # Fix
>> The goal of the tests is to make sure that there are no null-checks with compare-and-exchange operations with ZGC and G1. Instead of relying on `VarHandle` compare-and-exchange-related methods we can use the equivalent `Unsafe` methods that are intrinsified directly.
>> 
>> # Testing
>> Tier 1-3+
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8367338: remove unused VarHandle

Looks good to me too. Thanks for fixing Damon!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1626#pullrequestreview-3280327214

From rriggs at openjdk.org  Mon Sep 29 21:04:24 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 29 Sep 2025 21:04:24 GMT
Subject: [lworld] RFR: 8368884: [lworld] java.util.Objects.equals should be
 inlined
Message-ID: <UholDsIPhuzFXytc8_b0MbtsastGLE-yf_KbzAlBEBc=.0740a9c7-f15b-4c10-ba88-b0d6df98a024@github.com>

Add @ForceInline to java.util.Objects.equals

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

Commit messages:
 - 8368884

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

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

From liach at openjdk.org  Mon Sep 29 21:08:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 29 Sep 2025 21:08:40 GMT
Subject: [lworld] RFR: 8368884: [lworld] java.util.Objects.equals should be
 inlined
In-Reply-To: <UholDsIPhuzFXytc8_b0MbtsastGLE-yf_KbzAlBEBc=.0740a9c7-f15b-4c10-ba88-b0d6df98a024@github.com>
References: <UholDsIPhuzFXytc8_b0MbtsastGLE-yf_KbzAlBEBc=.0740a9c7-f15b-4c10-ba88-b0d6df98a024@github.com>
Message-ID: <CLdXUIwuz14lse7CrCcQA7Z3Wx42EGD0sZQ1I7ZmGjs=.acc5fe06-6ce7-4a62-9737-07aac121785e@github.com>

On Mon, 29 Sep 2025 20:55:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Add @ForceInline to java.util.Objects.equals

Trivial.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1643#pullrequestreview-3281789662

From thartmann at openjdk.org  Tue Sep 30 06:32:24 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 Sep 2025 06:32:24 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected"
In-Reply-To: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
Message-ID: <6fj_6i-m-YsivIerjV65yKGCm8AJ0kg7PL6Dgz3-wkA=.5080da40-e309-4410-832f-ea1d094c9efa@github.com>

On Fri, 26 Sep 2025 14:02:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> ## Act I: dead loops
> 
> [JDK-8336003: [lworld] TestLWorld::test151 triggers "Should have been buffered" assert](https://bugs.openjdk.org/browse/JDK-8336003), allows to replace a Phi node by a single input recursively through phis. This change was only added to Valhalla. In mainline, a Phi can be simplified to its single direct input, not through other phis. The valhalla version will work on loops, while the mainline version will reduce all the phis into a single input only if the blob of Phis is acyclic.
> 
> When a loop is dead, it is possible that the said single input is also an output of the phi. After applying the identity, the phi's unique input becomes its own output (or input). For most nodes, that is not allowed. This is probably relatively harmless as the whole code around is dead and will be removed, but it makes some verification fail. It is also possible that some other idealization are not protected against data loops without phis on the way, and would not terminate. It is interesting to notice that applying [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to mainline is enough to reproduce the bug there too.
> 
> We could detect when it's about to happen, and handle the situation differently if we are about to create a very small loop that would be caught by the dead loop detection. It would be possible to make big dead data loop. How annoying that is? Immediately, there is the non-termination problem mentioned above. But also, maybe some nodes can be optimized away by IGVN and end up with a small loop and then the assert would strike again. Is the dead loop check too weak then? It depends what we think is the purpose of this check. During IGVN, we cannot clean up eagerly every dead loop since it would be too expensive to traverse everything. Avoiding dead data loop would also need a lot of traversal. My understanding is that it's rather a sanity check, to make sure that one doesn't mess up the graph surgery and create dead loops accidentally, when something else was meant, and detecting as soon as possible is helpful. So I'm not sure it's worth strengthening the check.
> 
> A way to avoid the creation of dead data loop is to simply limit the simplification allowed by [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to constant nodes: since they don't have input, they can't make a cycle! And it seems enough for the bug initially reported.
> 
> Yet, that makes `test151` in `compiler/valhalla/inlinetypes/TestLWorld.java` fail in another way:...

Nice analysis Marc! Let's see if the current solution is sufficient :) I just have a few style comments.

src/hotspot/share/opto/cfgnode.cpp line 1482:

> 1480:   }
> 1481:   {
> 1482:     Node* uin = unique_constant_input_recursive(phase);

I think the original format was fine but I have no strong opinion.

src/hotspot/share/opto/inlinetypenode.cpp line 171:

> 169: 
> 170: // Merges 'this' with 'top' by updating the input PhiNodes added by 'clone_with_phis'
> 171: InlineTypeNode* InlineTypeNode::merge_with_top(PhaseGVN* gvn, int pnum, bool transform) {

I don't like the code duplication with `InlineTypeNode::merge_with` here. Would it be feasible to merge the two and have `InlineTypeNode::merge_with` handle `top` for `other`? Maybe the `PhiNode` inputs and `val2`can be initialized to `top` by default (maybe already in `clone_with_phis`) such that we only need to guard the `set_req` calls by `!other->is_top()`?

src/hotspot/share/opto/phaseX.cpp line 783:

> 781:       }
> 782:     }
> 783:     if (!no_dead_loop) n->dump_bfs(100,nullptr,"");

This was fixed upstream by https://github.com/openjdk/jdk/commit/2826d1702534783023802ac5c8d8ea575558f09f, no need to cherry pick.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1640#pullrequestreview-3282769618
PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2389990154
PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2389984465
PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2389989039

From dfenacci at openjdk.org  Tue Sep 30 07:07:26 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 30 Sep 2025 07:07:26 GMT
Subject: [lworld] RFR: 8367338: [lworld]
 compiler/gcbarriers/TestImplicitNullChecks.java fails [v2]
In-Reply-To: <zalKnBQiFAUGCSXFp-7x29J_1QfZiq-93BvSjZTDbAU=.1e26f300-24f6-472a-91aa-521ca66b2051@github.com>
References: <UeatLbGLybkPfyTLIk2MkcTdnAmE2mMWklrzWblo5Xw=.729c4918-0ee4-45f6-88c9-cb7a4fe5d7b5@github.com>
 <6h0zf9CD-y0SHn4dDbxBlsBLM2He6TvJ9wVC73oKH_0=.d34ae4b2-59a6-4924-b008-9af4fef43c5e@github.com>
 <zalKnBQiFAUGCSXFp-7x29J_1QfZiq-93BvSjZTDbAU=.1e26f300-24f6-472a-91aa-521ca66b2051@github.com>
Message-ID: <ICGd3OFB50yz8DB6YKfS5rwyokiE0H4U-vFTPvBpDPc=.62eac29a-e721-48c0-8719-f483a8942b1c@github.com>

On Mon, 29 Sep 2025 11:08:56 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8367338: remove unused VarHandle
>
> Marked as reviewed by rcastanedalo (no project role).

Thanks for reviewing @robcasloz @TobiHartmann!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1626#issuecomment-3350285747

From duke at openjdk.org  Tue Sep 30 07:07:27 2025
From: duke at openjdk.org (duke)
Date: Tue, 30 Sep 2025 07:07:27 GMT
Subject: [lworld] RFR: 8367338: [lworld]
 compiler/gcbarriers/TestImplicitNullChecks.java fails [v2]
In-Reply-To: <6h0zf9CD-y0SHn4dDbxBlsBLM2He6TvJ9wVC73oKH_0=.d34ae4b2-59a6-4924-b008-9af4fef43c5e@github.com>
References: <UeatLbGLybkPfyTLIk2MkcTdnAmE2mMWklrzWblo5Xw=.729c4918-0ee4-45f6-88c9-cb7a4fe5d7b5@github.com>
 <6h0zf9CD-y0SHn4dDbxBlsBLM2He6TvJ9wVC73oKH_0=.d34ae4b2-59a6-4924-b008-9af4fef43c5e@github.com>
Message-ID: <Ddf9Ex0X9oBJpQGAkaeQiF7PjjUok1uGg0FgyEGzzGs=.36675465-f0af-4280-bcfa-f5c85ae38e8a@github.com>

On Mon, 29 Sep 2025 08:54:32 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> # Issue
>> IR checks of `testCompareAndExchange`, `testCompareAndSwap` and `testGetAndSet` of  `compiler/gcbarriers/TestImplicitNullChecks.java` fail because they expect no  `NULL_CHECK` in the final code graph but it encounters a few in each test instead.
>> 
>> # Cause
>> The tests in question simply call 3 different `VarHandle` functions (one each) but these don't get inlined as intrinsics directly. They instead rely on inline methods (with some conditional statements) that eventually call a method that gets intrinsified. Unfortunately the compilation of some of the inlined code can result in null-checks after being compiled.
>> For instance `testCompareAndExchange` inlines `Unsafe::compareAndExchangeReference`
>> https://github.com/openjdk/valhalla/blob/1ecd2e95a158c80186d4334ca3f0673f660d5042/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L1723-L1742
>> which calls `compareAndSetReference` or `compareAndExchangeReference` but `if (valueType.isValue() || isValueObject(expected))` adds a null-check for `valueType`.
>> This happens only in Valhalla because of a Valhalla-specific value-type checks (see [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569)).
>> 
>> # Fix
>> The goal of the tests is to make sure that there are no null-checks with compare-and-exchange operations with ZGC and G1. Instead of relying on `VarHandle` compare-and-exchange-related methods we can use the equivalent `Unsafe` methods that are intrinsified directly.
>> 
>> # Testing
>> Tier 1-3+
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8367338: remove unused VarHandle

@dafedafe 
Your change (at version cb9e02c9ccae9ad1bab8f77010171d92957d90f5) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1626#issuecomment-3350292569

From dfenacci at openjdk.org  Tue Sep 30 07:29:48 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 30 Sep 2025 07:29:48 GMT
Subject: [lworld] Integrated: 8367338: [lworld]
 compiler/gcbarriers/TestImplicitNullChecks.java fails
In-Reply-To: <UeatLbGLybkPfyTLIk2MkcTdnAmE2mMWklrzWblo5Xw=.729c4918-0ee4-45f6-88c9-cb7a4fe5d7b5@github.com>
References: <UeatLbGLybkPfyTLIk2MkcTdnAmE2mMWklrzWblo5Xw=.729c4918-0ee4-45f6-88c9-cb7a4fe5d7b5@github.com>
Message-ID: <u3W0Ar0pucqhC6TemYpLZio4UwLn8OUCx83_6hnPJlw=.8068b000-acb4-4991-a44b-d696b85730f8@github.com>

On Wed, 24 Sep 2025 15:36:04 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> # Issue
> IR checks of `testCompareAndExchange`, `testCompareAndSwap` and `testGetAndSet` of  `compiler/gcbarriers/TestImplicitNullChecks.java` fail because they expect no  `NULL_CHECK` in the final code graph but it encounters a few in each test instead.
> 
> # Cause
> The tests in question simply call 3 different `VarHandle` functions (one each) but these don't get inlined as intrinsics directly. They instead rely on inline methods (with some conditional statements) that eventually call a method that gets intrinsified. Unfortunately the compilation of some of the inlined code can result in null-checks after being compiled.
> For instance `testCompareAndExchange` inlines `Unsafe::compareAndExchangeReference`
> https://github.com/openjdk/valhalla/blob/1ecd2e95a158c80186d4334ca3f0673f660d5042/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L1723-L1742
> which calls `compareAndSetReference` or `compareAndExchangeReference` but `if (valueType.isValue() || isValueObject(expected))` adds a null-check for `valueType`.
> This happens only in Valhalla because of a Valhalla-specific value-type checks (see [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569)).
> 
> # Fix
> The goal of the tests is to make sure that there are no null-checks with compare-and-exchange operations with ZGC and G1. Instead of relying on `VarHandle` compare-and-exchange-related methods we can use the equivalent `Unsafe` methods that are intrinsified directly.
> 
> # Testing
> Tier 1-3+

This pull request has now been integrated.

Changeset: b4017185
Author:    Damon Fenacci <dfenacci at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b4017185d2f9b177660f46cf61a22792cef2e3bb
Stats:     16 lines in 2 files changed: 4 ins; 6 del; 6 mod

8367338: [lworld] compiler/gcbarriers/TestImplicitNullChecks.java fails

Reviewed-by: rcastanedalo, thartmann

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

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

From tobias.hartmann at oracle.com  Tue Sep 30 08:00:53 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 30 Sep 2025 10:00:53 +0200
Subject: CFV: New Valhalla Committer: Marc Chevalier
Message-ID: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>

I hereby nominate Marc Chevalier [1] to Valhalla Committer.

Marc is a member of the JVM Compiler Team at Oracle. He contributed 37 changes to the JDK project [2] and 12 changes to the Valhalla project [3].

Votes are due by October 14, 2025, 08:00 UTC.

Only current Valhalla Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

Best regards,
Tobias

[1] https://openjdk.org/census#mchevalier
[2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1
[3] https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20mchevalier%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
[4] https://openjdk.java.net/census
[5] https://openjdk.org/projects/#committer-vote

From tobias.hartmann at oracle.com  Tue Sep 30 08:04:58 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 30 Sep 2025 10:04:58 +0200
Subject: CFV: New Valhalla Committer: Damon Fenacci
Message-ID: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>

I hereby nominate Damon Fenacci [1] to Valhalla Committer.

Marc is a member of the JVM Compiler Team at Oracle. He contributed 36 changes to the JDK project [2] and 7 changes to the Valhalla project [3].

Votes are due by October 14, 2025, 08:00 UTC.

Only current Valhalla Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

Best regards,
Tobias

[1] https://openjdk.org/census#dfenacci
[2] https://github.com/search?q=author-name%3A%22Damon+Fenacci%22+repo%3Aopenjdk%2Fjdk&type=commits
[3] https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20dfenacci%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
[4] https://openjdk.java.net/census
[5] https://openjdk.org/projects/#committer-vote

From tobias.hartmann at oracle.com  Tue Sep 30 08:05:18 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 30 Sep 2025 10:05:18 +0200
Subject: CFV: New Valhalla Committer: Marc Chevalier
In-Reply-To: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
References: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
Message-ID: <8c5a1bda-abf5-4c7f-a7b5-d182759f4141@oracle.com>

Vote: yes

Best regards,
Tobias

On 9/30/25 10:00, Tobias Hartmann wrote:
> I hereby nominate Marc Chevalier [1] to Valhalla Committer.
> 
> Marc is a member of the JVM Compiler Team at Oracle. He contributed 37 changes to the JDK project [2] and 12 changes to the Valhalla project [3].
> 
> Votes are due by October 14, 2025, 08:00 UTC.
> 
> Only current Valhalla Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [5].
> 
> Best regards,
> Tobias
> 
> [1] https://openjdk.org/census#mchevalier
> [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1
> [3] https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20mchevalier%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
> [4] https://openjdk.java.net/census
> [5] https://openjdk.org/projects/#committer-vote


From tobias.hartmann at oracle.com  Tue Sep 30 08:05:42 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 30 Sep 2025 10:05:42 +0200
Subject: CFV: New Valhalla Committer: Damon Fenacci
In-Reply-To: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
References: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
Message-ID: <e73700fe-70bf-4a31-bd4c-e7a8735e9207@oracle.com>

Vote: yes

Best regards,
Tobias


On 9/30/25 10:04, Tobias Hartmann wrote:
> I hereby nominate Damon Fenacci [1] to Valhalla Committer.
> 
> Marc is a member of the JVM Compiler Team at Oracle. He contributed 36 changes to the JDK project [2] and 7 changes to the Valhalla project [3].
> 
> Votes are due by October 14, 2025, 08:00 UTC.
> 
> Only current Valhalla Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [5].
> 
> Best regards,
> Tobias
> 
> [1] https://openjdk.org/census#dfenacci
> [2] https://github.com/search?q=author-name%3A%22Damon+Fenacci%22+repo%3Aopenjdk%2Fjdk&type=commits
> [3] https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20dfenacci%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
> [4] https://openjdk.java.net/census
> [5] https://openjdk.org/projects/#committer-vote


From mchevalier at openjdk.org  Tue Sep 30 08:06:32 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 30 Sep 2025 08:06:32 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected"
In-Reply-To: <6fj_6i-m-YsivIerjV65yKGCm8AJ0kg7PL6Dgz3-wkA=.5080da40-e309-4410-832f-ea1d094c9efa@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
 <6fj_6i-m-YsivIerjV65yKGCm8AJ0kg7PL6Dgz3-wkA=.5080da40-e309-4410-832f-ea1d094c9efa@github.com>
Message-ID: <Q5YGR7GOP505Wn9nYkOn37yyaV8wdZD8n_IBQ_ejqQo=.611d9e4a-6fc9-491e-804e-0133bc64ae84@github.com>

On Tue, 30 Sep 2025 06:19:40 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> ## Act I: dead loops
>> 
>> [JDK-8336003: [lworld] TestLWorld::test151 triggers "Should have been buffered" assert](https://bugs.openjdk.org/browse/JDK-8336003), allows to replace a Phi node by a single input recursively through phis. This change was only added to Valhalla. In mainline, a Phi can be simplified to its single direct input, not through other phis. The valhalla version will work on loops, while the mainline version will reduce all the phis into a single input only if the blob of Phis is acyclic.
>> 
>> When a loop is dead, it is possible that the said single input is also an output of the phi. After applying the identity, the phi's unique input becomes its own output (or input). For most nodes, that is not allowed. This is probably relatively harmless as the whole code around is dead and will be removed, but it makes some verification fail. It is also possible that some other idealization are not protected against data loops without phis on the way, and would not terminate. It is interesting to notice that applying [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to mainline is enough to reproduce the bug there too.
>> 
>> We could detect when it's about to happen, and handle the situation differently if we are about to create a very small loop that would be caught by the dead loop detection. It would be possible to make big dead data loop. How annoying that is? Immediately, there is the non-termination problem mentioned above. But also, maybe some nodes can be optimized away by IGVN and end up with a small loop and then the assert would strike again. Is the dead loop check too weak then? It depends what we think is the purpose of this check. During IGVN, we cannot clean up eagerly every dead loop since it would be too expensive to traverse everything. Avoiding dead data loop would also need a lot of traversal. My understanding is that it's rather a sanity check, to make sure that one doesn't mess up the graph surgery and create dead loops accidentally, when something else was meant, and detecting as soon as possible is helpful. So I'm not sure it's worth strengthening the check.
>> 
>> A way to avoid the creation of dead data loop is to simply limit the simplification allowed by [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to constant nodes: since they don't have input, they can't make a cycle! And it seems enough for the bug initially reported.
>> 
>> Yet, that makes `test151` in `compiler/valhalla/inlinetypes/TestLWorld.java...
>
> src/hotspot/share/opto/inlinetypenode.cpp line 171:
> 
>> 169: 
>> 170: // Merges 'this' with 'top' by updating the input PhiNodes added by 'clone_with_phis'
>> 171: InlineTypeNode* InlineTypeNode::merge_with_top(PhaseGVN* gvn, int pnum, bool transform) {
> 
> I don't like the code duplication with `InlineTypeNode::merge_with` here. Would it be feasible to merge the two and have `InlineTypeNode::merge_with` handle `top` for `other`? Maybe the `PhiNode` inputs and `val2`can be initialized to `top` by default (maybe already in `clone_with_phis`) such that we only need to guard the `set_req` calls by `!other->is_top()`?

If we initialize the inputs of the `PhiNodes` above `this` to top, we don't even need to merge with anything. We can just skip the call to `merge_with`, no? It seems mostly harmless to change `clone_with_phis` this way, except for the callsite in `Parse::ensure_phi` where I'm not sure of the consequences.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2390241738

From tobias.hartmann at oracle.com  Tue Sep 30 08:20:36 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 30 Sep 2025 10:20:36 +0200
Subject: CFV: New Valhalla Committer: Damon Fenacci
In-Reply-To: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
References: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
Message-ID: <609c5d86-c913-427e-a806-86aabd065c65@oracle.com>


On 9/30/25 10:04, Tobias Hartmann wrote:
> Marc?is?a?member?of?the?JVM?Compiler?Team?at?Oracle.?He?contributed?36?changes?to?the?JDK?project?[2]?and?7?changes?to?the?Valhalla?project?[3].

Copy-paste error: this should of course read "Damon is a member of the JVM Compiler Team [...]". Sorry for that.

Best regards,
Tobias


From thartmann at openjdk.org  Tue Sep 30 08:27:50 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 Sep 2025 08:27:50 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected"
In-Reply-To: <Q5YGR7GOP505Wn9nYkOn37yyaV8wdZD8n_IBQ_ejqQo=.611d9e4a-6fc9-491e-804e-0133bc64ae84@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
 <6fj_6i-m-YsivIerjV65yKGCm8AJ0kg7PL6Dgz3-wkA=.5080da40-e309-4410-832f-ea1d094c9efa@github.com>
 <Q5YGR7GOP505Wn9nYkOn37yyaV8wdZD8n_IBQ_ejqQo=.611d9e4a-6fc9-491e-804e-0133bc64ae84@github.com>
Message-ID: <502Y1FL7CYU7czxswnBm_Z9dz6gsEdg5R3YUJLQiOEI=.30213c5a-d857-470e-9a4c-5441f59a0239@github.com>

On Tue, 30 Sep 2025 08:03:27 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/opto/inlinetypenode.cpp line 171:
>> 
>>> 169: 
>>> 170: // Merges 'this' with 'top' by updating the input PhiNodes added by 'clone_with_phis'
>>> 171: InlineTypeNode* InlineTypeNode::merge_with_top(PhaseGVN* gvn, int pnum, bool transform) {
>> 
>> I don't like the code duplication with `InlineTypeNode::merge_with` here. Would it be feasible to merge the two and have `InlineTypeNode::merge_with` handle `top` for `other`? Maybe the `PhiNode` inputs and `val2`can be initialized to `top` by default (maybe already in `clone_with_phis`) such that we only need to guard the `set_req` calls by `!other->is_top()`?
>
> If we initialize the inputs of the `PhiNodes` above `this` to top, we don't even need to merge with anything. We can just skip the call to `merge_with`, no? It seems mostly harmless to change `clone_with_phis` this way, except for the callsite in `Parse::ensure_phi` where I'm not sure of the consequences.

Right, skipping the call would be even better. I think the `ensure_phi` callsite should be fine as well as all the branches that the phi inputs correspond to should either be initialized afterwards or are dead (in which case `top` seems appropriate). But only testing will tell :D

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2390314232

From mchevalier at openjdk.org  Tue Sep 30 08:56:38 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 30 Sep 2025 08:56:38 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected"
In-Reply-To: <6fj_6i-m-YsivIerjV65yKGCm8AJ0kg7PL6Dgz3-wkA=.5080da40-e309-4410-832f-ea1d094c9efa@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
 <6fj_6i-m-YsivIerjV65yKGCm8AJ0kg7PL6Dgz3-wkA=.5080da40-e309-4410-832f-ea1d094c9efa@github.com>
Message-ID: <MfAwJeJsbkOnDV4U9w3ObtTxuVWy-wZgMITWMU0GUf4=.d3d3c1e6-a796-490c-9bcc-7272f39532fd@github.com>

On Tue, 30 Sep 2025 06:22:52 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> ## Act I: dead loops
>> 
>> [JDK-8336003: [lworld] TestLWorld::test151 triggers "Should have been buffered" assert](https://bugs.openjdk.org/browse/JDK-8336003), allows to replace a Phi node by a single input recursively through phis. This change was only added to Valhalla. In mainline, a Phi can be simplified to its single direct input, not through other phis. The valhalla version will work on loops, while the mainline version will reduce all the phis into a single input only if the blob of Phis is acyclic.
>> 
>> When a loop is dead, it is possible that the said single input is also an output of the phi. After applying the identity, the phi's unique input becomes its own output (or input). For most nodes, that is not allowed. This is probably relatively harmless as the whole code around is dead and will be removed, but it makes some verification fail. It is also possible that some other idealization are not protected against data loops without phis on the way, and would not terminate. It is interesting to notice that applying [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to mainline is enough to reproduce the bug there too.
>> 
>> We could detect when it's about to happen, and handle the situation differently if we are about to create a very small loop that would be caught by the dead loop detection. It would be possible to make big dead data loop. How annoying that is? Immediately, there is the non-termination problem mentioned above. But also, maybe some nodes can be optimized away by IGVN and end up with a small loop and then the assert would strike again. Is the dead loop check too weak then? It depends what we think is the purpose of this check. During IGVN, we cannot clean up eagerly every dead loop since it would be too expensive to traverse everything. Avoiding dead data loop would also need a lot of traversal. My understanding is that it's rather a sanity check, to make sure that one doesn't mess up the graph surgery and create dead loops accidentally, when something else was meant, and detecting as soon as possible is helpful. So I'm not sure it's worth strengthening the check.
>> 
>> A way to avoid the creation of dead data loop is to simply limit the simplification allowed by [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to constant nodes: since they don't have input, they can't make a cycle! And it seems enough for the bug initially reported.
>> 
>> Yet, that makes `test151` in `compiler/valhalla/inlinetypes/TestLWorld.java...
>
> src/hotspot/share/opto/cfgnode.cpp line 1482:
> 
>> 1480:   }
>> 1481:   {
>> 1482:     Node* uin = unique_constant_input_recursive(phase);
> 
> I think the original format was fine but I have no strong opinion.

I wouldn't fight too hard for it, but when trying things, it was necessary (since I wanted different types for `uin`), but I also think it helps to see that it is not useful too long, and I can mess with it without having to look at what comes after. In this case, indeed, it feels a bit coming out of nowhere at the end...

In C++17, I'd do:
```c++
 if (Node* uin = unique_constant_input_recursive(phase); uin != nullptr) {
  return uin;
}

one could also do
```c++
 if (Node* uin = unique_constant_input_recursive(phase)) {
  return uin;
}

if we are not afraid of implicit conditions (but we are, and I'm fine with it!).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2390390461

From dsimms at openjdk.org  Tue Sep 30 09:05:44 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 30 Sep 2025 09:05:44 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <CCRWLMhRSOG59k4lJ14CTZrtHfCbUWA-KmG9I0BwS9I=.6eb418b9-43ab-48df-bfd2-4962db6610cf@github.com>

Merge jdk-26+11

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

Commit messages:
 - Merge branch 'lworld' into lworld_merge_jdk_26_11
 - Adjust testing
 - Vicente patch merge issues
 - Merge branch 'lworld' into lworld_merge_jdk_26_11
 - Merge tag 'jdk-26+11' into lworld_merge_jdk_26_11
 - 8365317: ZGC: Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash
 - 8365314: javac fails with an exception for erroneous source
 - 8341342: Elements.getAllModuleElements() does not work properly before JavacTask.analyze()
 - 8365375: Method SU3.setAcceleratorSelectionForeground assigns to acceleratorForeground
 - 8365229: ARM32: c2i_no_clinit_check_entry assert failed after JDK-8364269
 - ... and 77 more: https://git.openjdk.org/valhalla/compare/b4017185...ac8b3305

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

Changes: https://git.openjdk.org/valhalla/pull/1644/files
  Stats: 10702 lines in 376 files changed: 5178 ins; 4250 del; 1274 mod
  Patch: https://git.openjdk.org/valhalla/pull/1644.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1644/head:pull/1644

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

From dsimms at openjdk.org  Tue Sep 30 12:21:20 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 30 Sep 2025 12:21:20 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <CCRWLMhRSOG59k4lJ14CTZrtHfCbUWA-KmG9I0BwS9I=.6eb418b9-43ab-48df-bfd2-4962db6610cf@github.com>
References: <CCRWLMhRSOG59k4lJ14CTZrtHfCbUWA-KmG9I0BwS9I=.6eb418b9-43ab-48df-bfd2-4962db6610cf@github.com>
Message-ID: <PRWQeIrHPTvFiN7jENY5EU1kHCfTSM2PpB-zzGlwZyY=.3b414de8-6fec-418c-a4bc-6caf02c0d2f3@github.com>

On Tue, 30 Sep 2025 08:58:03 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+11

This pull request has now been integrated.

Changeset: 7c210c11
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7c210c11d26c541e72fd8c0401293a82016d2789
Stats:     10702 lines in 376 files changed: 5178 ins; 4250 del; 1274 mod

Merge jdk

Merge jdk-26+11

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

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

From thartmann at openjdk.org  Tue Sep 30 12:53:37 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 Sep 2025 12:53:37 GMT
Subject: [lworld] RFR: 8367729: [lworld] Handle OOME in code cache when
 generating inline type adapters
Message-ID: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>

Similar to when creating c2i and i2c adapters, we should gracefully handle OOMEs in the code cache when generating Valhalla specific adapters required for the scalarized calling convention.

Thanks,
Tobias

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

Commit messages:
 - 8367729: [lworld] Handle OOME in code cache when generating inline type adapters

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

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

From jbhateja at openjdk.org  Tue Sep 30 13:01:40 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 30 Sep 2025 13:01:40 GMT
Subject: [lworld] RFR: 8367792: [lworld] Remove the Unsafe remnants of old
 valhalla prototypes
In-Reply-To: <rcxiIhT-6gFMB_vBrh1t03Vwn8xJ_xC30-nc2dBvxck=.4d9f2802-388a-4dc1-8cdb-af240f1140c9@github.com>
References: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
 <vnLmnwhpHnh7Wfmmo2TD4qJhDa4dnib4HIXhic3Fsyk=.d4be4aba-4914-4a73-8d21-429ae4e680ae@github.com>
 <CNKXxqFFrRpuApLzmIjDRUSqKNlpntUbmbQHwPnaqEM=.d9c12557-1b16-4d20-af03-e97b5fec8d16@github.com>
 <rcxiIhT-6gFMB_vBrh1t03Vwn8xJ_xC30-nc2dBvxck=.4d9f2802-388a-4dc1-8cdb-af240f1140c9@github.com>
Message-ID: <i3QdnvF4Ec37CMZl1VlyLz8cHM0LlmjACw8egwKixis=.63fda8a0-b1cf-431c-b02a-e1b77dd225ed@github.com>

On Fri, 26 Sep 2025 22:34:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hi @liach , 
>> 
>> Currently, Unsafe.put* APIs expect to operate on a mutable value, without Unsafe.makePrivateBuffer, there is no way to transition a value object to larval state.
>> 
>> <img width="800" height="400" alt="image" src="https://github.com/user-attachments/assets/af826cda-55e1-4b0c-a2ea-62592f7623d6" />
>> 
>> 
>> Here is a typical update kernel for the nary operation fallback implementation. 
>> 
>> <img width="500" height="200" alt="image" src="https://github.com/user-attachments/assets/4a31baa7-52b8-4e0b-8c42-924407bb5665" />
>> 
>> 
>> 
>> **Here are some relevant FAQs on the need for multifield annotation.**
>> 
>> Q. Why do we need @multifield annotated field in VectorPayloads and not just retain the array-backed backing storage?
>> A.  Even currently, Vector instances are immutable, with each modification or application of an operation, a new vector is generated. 
>>       Each new vector has a distinct backing storage in the form of an array; thus, no two vector ever share their backing storage, which makes vectors an immutable quantity. 
>>       
>>      Vector<Float>  newVector  =  Vec1.lanewise(VectorOperators.ADD, Vec2);
>>      
>> Since arrays are always allocated over the heap, they carry an identity, which is the distinctive heap address for each new backing storage array.
>> 
>> This contradicts the philosophy of value type instances, which are identity-free; the compiler treats two values with the same contents as equivalent entities and is free to substitute one with another. 
>> 
>> By replacing existing array-backed storage with a @multifield annotated storage, we ensure that payload adheres to true value semantics, a @multifiled is seen as a bundle of fields, encapsulating payload is a value class, unlike an array, a multifield is never allocated an explicit heap storage. 
>> 
>> Here is an example code
>> 
>>  
>> <img width="388" height="503" alt="image" src="https://github.com/user-attachments/assets/8f6b5a07-a8e0-4912-b909-9d892f40d92a" />
>> 
>> 
>> Even though Payload is a value class, its two instances with the same backing storage are not equal, because arrays have identity.
>> By treating vectors as value objects, we expect that two vectors with the same contents should be equal.
>> 
>> Q.  Is there any alternative to @multifield?
>> A.  All we need to ensure is that the backing storage has no identity.  Thus, we could have multiple primitive type fields in the payload, one for each lane of the vector. 
>> 
>>  
>> <img width="450" height="310" al...
>
> Hi @jatin-bhateja, as I know, the larval bit is completely unused in current Valhalla - I believe what we should do with that assert is to simply remove it. I am thinking of some internal API that accepts a Consumer that handles the "early larval" API via unsafe before returning it.
> 
> I thought the merge of lworld into vector would be trivial, but it turned out troublesome - can you push the merge as soon as it is ready? I am more than happy to help you migrate off makePrivateBuffer and this to-be-removed larval bit.

Hi @liach ,

Here is a quick sync-up on the merge status.

I started the merge yesterday, but it may take a few more days as there have been lots of changes in the code over the last 4 months. I am studying the code changes and documenting the new code model, in crystalline form. Following is our new model for larval objects.

Core concept (New model):-
  - A value object can be updated when it's in the larval state, either explicitly through makePrivateBuffer or implicitly during new object creation.
  - A value in a larval state must be in a non-scalarized form, i.e., it should exist as an oop.
  - Updates to a larval value field are done by emitting an explicit store operation/IR, This mandates an OOP form of larval object; this is a major change from the earlier model, where puffield could directly update the incoming edge of scalarized InlineTypeNode IR. Given that a value object is an immutable quantity, any update is only possible by way of creating a new value, thereby going through a temporary larval state.
  - Value object is transitioned to a non-larval state after the constructor call or after finishPrivateBuffer.
  - For vector API, backing storage is in the form of a @Multifield payload, since only the base field can be exposed in Java code, and the rest of the synthetic fields are internally generated based on the annotation processing during class file parsing; hence, we definitely need an Unsafe API to update all the synthetic fields.
  - New flexible constructor does allow updates to fields before the super call, but we still cannot pass uninitializedThis to an external initialization routine (like an unsafe API) from a constructor. As a result of this, currently the VectorPayalod*MF constructors only initialize the base multifield through a putfield bytecode. [JDK-8368810](https://bugs.openjdk.org/browse/JDK-8368810) tracks this issue.

In the current context, we have the following options to perform vector updates in the fallback implementation:-

Premise: Value objects are immutable, and two vector values with the same lane contents must be treated as equals.


  **a/ Current update loop:-**
      

                          res = Unsafe.makePrivateBuffer(arg1);
                          for (int i = 0; i < laneCount; i++) {
                                 larg1 =  Unsafe.getFloat(arg1, offset[i]);
                                 larg2 =  Unsafe.getFloat(arg2, offset[i]);
	                         Unsafe.putFloat(res, larg1 + larg2);                // res is in oop form since its in a mutable state.         
                          }
                          res = Unsafe.finishPrivateBuffer(res);                   // re-create scalarized representation from larval state. 

         
The lifetime of a larval is very restricted today, and by Java application compilation, we don't emit any bytecode b/w the new and its subsequent initializing constructor. However, using handcrafted bytecode, we can have a gap b/w a new ininitialized allocation and its initializing constructor, but the JVM runtime rules for bytecode verification catch any undefined behavior. Unsafe operations are outside the purview of JVM bytecode verification.

Problem arises when we make the lifetime of the larval object being acted upon by an unsafe API span across a block or even loop of bytecode; in such cases, we may need to handle larval and non-larval merges OR emit an undefined behavior error.

  Q. How performant is the unsafe get / put operation?
  A. There are intrinsic and native implementations of get/put APIs, given that it's an unsafe operation compiler does not care about emitting any out-of-bound checks, as it's the responsibility of the user. In such a case, an unsafe get simply computes an effective address (base + offset) and emits load / store instructions. Does the loop involving unsafe operation auto-vectorized ? Yes, since the auto-vectorizer looks for contiguity in the address across iterations.

Consider the impact of long-lived larval res in the above update loop on intrinsicfication


               <statistics type='intrinsic'>
                      Compiler intrinsic usage:
                         2 (50.0%) _getFloat (worked)
                         1 (25.0%) _putFloat (worked)
                         1 (25.0%) _makePrivateBuffer (worked)
                         0 ( 0.0%) _finishPrivateBuffer (failed)
                         4 (100.0%) total (worked,failed)
                    </statistics> 



res, was made a larval quantity using makePrivateBuffer, but scalarization triggered at gen_checkcast, which observed a value type oop, which by the way is in larval state. As a result, finishPrivateBuffer receives an InlineTypeNode while it always expects to receive a larval value oop, and hence intrinsification fails, it has a side effect on auto-vectorization, which does not observe an IR expression for store and its associated address computation since we take the native implementation route. Hence, the performance of fall fallback implementation degrades.

Q. What are the possible solutions here? 
A. Compiler should never try to scalarize the larval oop at checkcast bytecode; this handling exists because type profiling sharpens the oop's type to a value type, thus facilitating scalarization.  Another solution is to make finishPrivateBuffer intrinsic more robust; it should simply return the InlineTypeNode by setting the Allocation->_larval to false. This is attempted by an unmerged patch[1]
All in all, there are loopholes if we increase the life span of the larval object; in this case, it spans across the loop.

  **b/ Other larval lifetime limiting options:-**

In the fallback implementation, we intend to operate at the lane level; it may turn out that the generated IR is auto-vectorizable, but it's purely a performance optimization by the Compiler, and was not the intent of the user in the first place. So we read the input lanes using Unsafe API, we need an Unsafe get here, since synthetic multifields are not part of user visible Java code and have no symbol or type information in the constant pool. Thus, with multi-field, we ought to use unsafe APIs. Unsafe. get does not mandate larval transitions of the input value vector. What needs to change, well, to limit the larval life time, we need to allocate a temporary buffer before the loop for storing the result of the computation loop.

We need a new Unsafe API that accepts the temporary buffer and the result value object. This API will internally buffer the scalarized value, update its field from the temporary result storage, and then re-materialize the scalarized representation from the updated buffer. 

  Q. Will this API again have both native and intrinsic implementation?
  A.  Yes, it will definitely have native implementation, and the intrinsic implementation should make use of vector IR if the target supports the required vector size, OR it will need to emit scalar load / store IR, We can be intelligent in the intrinsic implementation to optimize this copy operation using a narrower vector. 

  Q. Will this be performant over the existing solution? 
  A. Additional allocation of a temporary buffer is costly; we can bank on escape analysis and loop unrolling to eliminate this allocation, but given that the temporary storage is passed to a native routine, it escapes the scope. With a Vector IR-based intrinsic implementation, we do need a contiguous memory view of temporary storage; otherwise, we may need to emit multiple scalar inserts into a vector, which is very costly. Overall, we don't expect the new implementation to be performant, mainly due to the additional allocation penalty. BTW, even today, vectors are immutable and vector factory routines are used in the fallback implementation to allocate memory for backing storage, thus we not only allocate a new concrete vector but also its backing storage, with current Valhalla and flat payloads we only need one allocation for vector and its backing storage, with new approach we may have to give away that benefit for reduced larval lifetime. It may turn out that the new approach is
  inferior in terms of performance with respect to the existing VectorAPI-Valhalla solution, but eventually may be at par with mainline support.

So it's tempting to try out the new solution to limit the complexity due to long-lifespan larval objects.

   **c/ Alternative approach : Create a new immutable value with each iteration of the update loop**.


                          res = __default_value__
                          for (int i = 0; i < laneCount; i++) {
                                 larg1 =  Unsafe.getFloat(arg1, offset[i]);
                                 larg2 =  Unsafe.getFloat(arg2, offset[i]);
	                         res =     Unsafe.updateLane(res, larg1 + larg2);     // res is in oop form since its in a mutable state.         
                          }


This also limits the lifetime of the larval value object, but on the hind side performs a buffering and scalarization with each iteration. When we buffer, we not only allocate a new temporary storage, but also emit field-level stores to dump the contents into temporary storage; this is very expensive if done for each lane update, given that we are only updating one lane of vector but are still paying the penalty to save and restore all unmodified lanes per iteration.

While this does limit the larval life span, it has a huge performance penalty in comparison to both the existing approaches of larval life time across loop and single update with temporary storage allocation. 

In the vector API, the fallback implementation is wrapped within the intrinsic entry point. As long as intrinsification is successful, we are not hit by a fallback; a poor fallback may delay the warmup stage, but for long-running SIMD kernels, warmups are never an issue as long as intrinsifications are successful.

I have created a prototype application [2] mimicking the vector API use case for you. Please give it a try with the existing lworld+vector branch after integrating the patch[1]

**While I am merging and understanding the implications of the new code mode, it will help if you can share your plan/test sample for the latest API to limit the scope of larval transition, keeping in view the above context.**

**Some notes on the implications of patch[1]**
Currently, the compiler does not handle vector calling convention emitting out of scalarization; this is a concern with the generic handling of multifield, where the return value was a container of a multifield and the multifield value was held by a vector register, in such a case, the caller will expect to receive the value in a vector register, with the vector API we deal in abstract vectors across method boundaries, which are never scalarized, anyway, extending the calling convention is on our list of items for Valhalla.

To circumvent this issue seen with the test case, we can disable scalarization of return values using -XX:-InlineTypeReturnedAsFields

[1] https://github.com/jatin-bhateja/external_staging/blob/main/Backup/lworld_vector_performance_uplift_patch_30_9_2025.diff

[2] https://github.com/jatin-bhateja/external_staging/blob/main/Code/java/valhalla/valhalla_401/valhalla_vector_api_mf_proto.java

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

PR Comment: https://git.openjdk.org/valhalla/pull/1593#issuecomment-3351995503

From mchevalier at openjdk.org  Tue Sep 30 13:07:10 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 30 Sep 2025 13:07:10 GMT
Subject: [lworld] RFR: 8367729: [lworld] Handle OOME in code cache when
 generating inline type adapters
In-Reply-To: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>
References: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>
Message-ID: <_3nJrJv8cFRq7nXZzXi8dsUgfItT5pQDnIoSFaCDDKI=.f41e900b-eba1-417c-898d-aab06d275b70@github.com>

On Tue, 30 Sep 2025 12:46:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Similar to when creating c2i and i2c adapters, we should gracefully handle OOMEs in the code cache when generating Valhalla specific adapters required for the scalarized calling convention.
> 
> Thanks,
> Tobias

That seems nice.

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

Marked as reviewed by mchevalier (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1645#pullrequestreview-3284665594

From chen.l.liang at oracle.com  Tue Sep 30 13:13:46 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Tue, 30 Sep 2025 13:13:46 +0000
Subject: CFV: New Valhalla Committer: Marc Chevalier
In-Reply-To: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
References: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
Message-ID: <SJ2PR10MB7669D74D1AFA7A1BE69C1790A21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>

Vote: yes

Chen Liang
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Tobias Hartmann <tobias.hartmann at oracle.com>
Sent: Tuesday, September 30, 2025 3:00 AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Cc: Marc Chevalier <marc.chevalier at oracle.com>
Subject: CFV: New Valhalla Committer: Marc Chevalier

I hereby nominate Marc Chevalier [1] to Valhalla Committer.

Marc is a member of the JVM Compiler Team at Oracle. He contributed 37 changes to the JDK project [2] and 12 changes to the Valhalla project [3].

Votes are due by October 14, 2025, 08:00 UTC.

Only current Valhalla Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

Best regards,
Tobias

[1] https://openjdk.org/census#mchevalier
[2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1
[3] https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20mchevalier%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
[4] https://openjdk.java.net/census
[5] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250930/2192b935/attachment.htm>

From chen.l.liang at oracle.com  Tue Sep 30 13:14:05 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Tue, 30 Sep 2025 13:14:05 +0000
Subject: CFV: New Valhalla Committer: Damon Fenacci
In-Reply-To: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
References: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
Message-ID: <SJ2PR10MB76698C19345A05B625BF2658A21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>

Vote: yes

Chen Liang
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Tobias Hartmann <tobias.hartmann at oracle.com>
Sent: Tuesday, September 30, 2025 3:04 AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Cc: Damon Fenacci <damon.fenacci at oracle.com>
Subject: CFV: New Valhalla Committer: Damon Fenacci

I hereby nominate Damon Fenacci [1] to Valhalla Committer.

Marc is a member of the JVM Compiler Team at Oracle. He contributed 36 changes to the JDK project [2] and 7 changes to the Valhalla project [3].

Votes are due by October 14, 2025, 08:00 UTC.

Only current Valhalla Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

Best regards,
Tobias

[1] https://openjdk.org/census#dfenacci
[2] https://github.com/search?q=author-name%3A%22Damon+Fenacci%22+repo%3Aopenjdk%2Fjdk&type=commits
[3] https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20dfenacci%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
[4] https://openjdk.java.net/census
[5] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250930/e45aecad/attachment-0001.htm>

From thartmann at openjdk.org  Tue Sep 30 13:26:30 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 Sep 2025 13:26:30 GMT
Subject: [lworld] RFR: 8367729: [lworld] Handle OOME in code cache when
 generating inline type adapters
In-Reply-To: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>
References: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>
Message-ID: <b_aHy-VcLVvzWnsm6gg0R6yXdVXqSqXl54NchL7me7g=.d4f0f5e8-82b5-4b76-8b38-0c35cd2fffe0@github.com>

On Tue, 30 Sep 2025 12:46:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Similar to when creating c2i and i2c adapters, we should gracefully handle OOMEs in the code cache when generating Valhalla specific adapters required for the scalarized calling convention.
> 
> Thanks,
> Tobias

Thanks Marc!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1645#issuecomment-3352147684

From phubner at openjdk.org  Tue Sep 30 13:44:42 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 30 Sep 2025 13:44:42 GMT
Subject: [lworld] RFR: 8367729: [lworld] Handle OOME in code cache when
 generating inline type adapters
In-Reply-To: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>
References: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>
Message-ID: <zDLfDoHgxlJxDoDVZUgbWBgjQGU2yJ2IB3wuyz7SeZY=.28e10d9b-0869-4c5b-b371-12607daf2cf5@github.com>

On Tue, 30 Sep 2025 12:46:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Similar to when creating c2i and i2c adapters, we should gracefully handle OOMEs in the code cache when generating Valhalla specific adapters required for the scalarized calling convention.
> 
> Thanks,
> Tobias

Looks good, thank you for fixing this!

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1645#pullrequestreview-3284901734

From dfenacci at openjdk.org  Tue Sep 30 13:48:07 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 30 Sep 2025 13:48:07 GMT
Subject: [lworld] RFR: 8367729: [lworld] Handle OOME in code cache when
 generating inline type adapters
In-Reply-To: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>
References: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>
Message-ID: <wwT677aqizqgnG627zCPb7-InLiKykLN-SH6yGaBAOE=.6eac65fc-3c2c-4804-8f97-2687a217a547@github.com>

On Tue, 30 Sep 2025 12:46:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Similar to when creating c2i and i2c adapters, we should gracefully handle OOMEs in the code cache when generating Valhalla specific adapters required for the scalarized calling convention.
> 
> Thanks,
> Tobias

Looks good to me too (and familiar ?). Thanks Tobias!

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

Marked as reviewed by dfenacci (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1645#pullrequestreview-3284926667

From thartmann at openjdk.org  Tue Sep 30 13:54:37 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 Sep 2025 13:54:37 GMT
Subject: [lworld] RFR: 8367729: [lworld] Handle OOME in code cache when
 generating inline type adapters
In-Reply-To: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>
References: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>
Message-ID: <6iegNFWRdSEY--N8c4aOrs3GOS-VsRdMbMgc9xTZ9OA=.ce04058e-2dca-4832-92d0-95344ae9cb0f@github.com>

On Tue, 30 Sep 2025 12:46:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Similar to when creating c2i and i2c adapters, we should gracefully handle OOMEs in the code cache when generating Valhalla specific adapters required for the scalarized calling convention.
> 
> Thanks,
> Tobias

Thanks Paul and Damon! :)

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

PR Comment: https://git.openjdk.org/valhalla/pull/1645#issuecomment-3352277557

From thartmann at openjdk.org  Tue Sep 30 13:54:37 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 Sep 2025 13:54:37 GMT
Subject: [lworld] Integrated: 8367729: [lworld] Handle OOME in code cache when
 generating inline type adapters
In-Reply-To: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>
References: <_5LO5PYEZmaVUPIk0dUTgAJmewi2w_PmX8M80-YYdEY=.c05551d4-9aec-4426-a0bc-782b204e6e06@github.com>
Message-ID: <nkloFFkuiOfZN0zeO7VgxyVcSlkSVppxVRh-vd1rNYw=.41c25df0-c236-4738-b097-df7e2e71d8d4@github.com>

On Tue, 30 Sep 2025 12:46:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Similar to when creating c2i and i2c adapters, we should gracefully handle OOMEs in the code cache when generating Valhalla specific adapters required for the scalarized calling convention.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 81f41417
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/81f414172c658e240d215e6051c39a007dfe8e73
Stats:     11 lines in 4 files changed: 9 ins; 0 del; 2 mod

8367729: [lworld] Handle OOME in code cache when generating inline type adapters

Reviewed-by: mchevalier, phubner, dfenacci

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

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

From thartmann at openjdk.org  Tue Sep 30 14:01:54 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 Sep 2025 14:01:54 GMT
Subject: [lworld] RFR: 8367412: [lworld] Adapter creation fails with
 guarantee(chk == -1 || chk == 0) failed: Field too big for insn
Message-ID: <uwt5opnioxDMWKBDZHGaHICbxB-T3_tvqo4o5JiK3u8=.0c05ebd3-b86c-457a-a57d-09a82f5b7b1a@github.com>

We hit a guarantee failure because the immediate of the branch instruction is too large. We should use a `far_jump` instead, like we do for all other jumps to `StubRoutines::forward_exception_entry()`.

I can reproduce this reliably with `test/hotspot/jtreg/runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java` and therefore did not add another regression test.

Thanks,
Tobias

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

Commit messages:
 - 8367412: [lworld] Adapter creation fails with guarantee(chk == -1 || chk == 0) failed: Field too big for insn

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

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

From roger.riggs at oracle.com  Tue Sep 30 14:15:06 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 30 Sep 2025 10:15:06 -0400
Subject: CFV: New Valhalla Committer: Damon Fenacci
In-Reply-To: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
References: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
Message-ID: <527ee399-6755-4d45-8f2d-96ca3dd9c760@oracle.com>

Vote: Yes

On 9/30/25 4:04 AM, Tobias Hartmann wrote:
> I hereby nominate Damon Fenacci [1] to Valhalla Committer. 


From roger.riggs at oracle.com  Tue Sep 30 14:15:23 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 30 Sep 2025 10:15:23 -0400
Subject: CFV: New Valhalla Committer: Marc Chevalier
In-Reply-To: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
References: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
Message-ID: <0e2cd208-d586-42f8-9fda-26f9842bdd19@oracle.com>

Vote: Yes

On 9/30/25 4:00 AM, Tobias Hartmann wrote:
> I hereby nominate Marc Chevalier [1] to Valhalla Committer. 


From rriggs at openjdk.org  Tue Sep 30 14:18:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 30 Sep 2025 14:18:59 GMT
Subject: [lworld] Integrated: 8368884: [lworld] java.util.Objects.equals should
 be inlined
In-Reply-To: <UholDsIPhuzFXytc8_b0MbtsastGLE-yf_KbzAlBEBc=.0740a9c7-f15b-4c10-ba88-b0d6df98a024@github.com>
References: <UholDsIPhuzFXytc8_b0MbtsastGLE-yf_KbzAlBEBc=.0740a9c7-f15b-4c10-ba88-b0d6df98a024@github.com>
Message-ID: <IQ4Z7Qtfs1XX95C7LHs9Tg42NyO30gNh6P7KFOalo7E=.eb385841-a227-476b-a288-425f18b96d43@github.com>

On Mon, 29 Sep 2025 20:55:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Add @ForceInline to java.util.Objects.equals

This pull request has now been integrated.

Changeset: 10e72b98
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/10e72b98e2a230eb04393b65b3d712581ba195f1
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8368884: [lworld] java.util.Objects.equals should be inlined

Reviewed-by: liach

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

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

From thartmann at openjdk.org  Tue Sep 30 14:47:03 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 Sep 2025 14:47:03 GMT
Subject: [lworld] RFR: 8367412: [lworld] Adapter creation fails with
 guarantee(chk == -1 || chk == 0) failed: Field too big for insn [v2]
In-Reply-To: <uwt5opnioxDMWKBDZHGaHICbxB-T3_tvqo4o5JiK3u8=.0c05ebd3-b86c-457a-a57d-09a82f5b7b1a@github.com>
References: <uwt5opnioxDMWKBDZHGaHICbxB-T3_tvqo4o5JiK3u8=.0c05ebd3-b86c-457a-a57d-09a82f5b7b1a@github.com>
Message-ID: <5sWuGcpydoU-acFKvBAJ70RLC236zFfJUlidgfLOwuI=.489d34cd-d727-4bbb-baa9-eab066930efb@github.com>

> We hit a guarantee failure because the immediate of the branch instruction is too large. We should use a `far_jump` instead, like we do for all other jumps to `StubRoutines::forward_exception_entry()`.
> 
> I can reproduce this reliably with `test/hotspot/jtreg/runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java` and therefore did not add another regression test.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Increased timeout

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1646/files
  - new: https://git.openjdk.org/valhalla/pull/1646/files/03570123..5fc9070b

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

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

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

From thartmann at openjdk.org  Tue Sep 30 14:47:05 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 Sep 2025 14:47:05 GMT
Subject: [lworld] RFR: 8367412: [lworld] Adapter creation fails with
 guarantee(chk == -1 || chk == 0) failed: Field too big for insn
In-Reply-To: <uwt5opnioxDMWKBDZHGaHICbxB-T3_tvqo4o5JiK3u8=.0c05ebd3-b86c-457a-a57d-09a82f5b7b1a@github.com>
References: <uwt5opnioxDMWKBDZHGaHICbxB-T3_tvqo4o5JiK3u8=.0c05ebd3-b86c-457a-a57d-09a82f5b7b1a@github.com>
Message-ID: <5dENIVMiPIWdhKxx07N0aa-wmDFC3BvkSKYCU3DmKBI=.f0abc76b-e01f-43b9-8067-b8c16334ae81@github.com>

On Tue, 30 Sep 2025 13:55:10 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We hit a guarantee failure because the immediate of the branch instruction is too large. We should use a `far_jump` instead, like we do for all other jumps to `StubRoutines::forward_exception_entry()`.
> 
> I can reproduce this reliably with `test/hotspot/jtreg/runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java` and therefore did not add another regression test.
> 
> Thanks,
> Tobias

I had to increase the timeout of the test as well.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1646#issuecomment-3352541153

From mhaessig at openjdk.org  Tue Sep 30 15:04:52 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Tue, 30 Sep 2025 15:04:52 GMT
Subject: [lworld] RFR: 8367412: [lworld] Adapter creation fails with
 guarantee(chk == -1 || chk == 0) failed: Field too big for insn [v2]
In-Reply-To: <5sWuGcpydoU-acFKvBAJ70RLC236zFfJUlidgfLOwuI=.489d34cd-d727-4bbb-baa9-eab066930efb@github.com>
References: <uwt5opnioxDMWKBDZHGaHICbxB-T3_tvqo4o5JiK3u8=.0c05ebd3-b86c-457a-a57d-09a82f5b7b1a@github.com>
 <5sWuGcpydoU-acFKvBAJ70RLC236zFfJUlidgfLOwuI=.489d34cd-d727-4bbb-baa9-eab066930efb@github.com>
Message-ID: <JI4hKsM91h_9I3d19xMpR7ffy6k7Bl4pXhpd-gxug68=.3c54bb4d-1d15-4dd2-87a2-3419e08c18a2@github.com>

On Tue, 30 Sep 2025 14:47:03 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> We hit a guarantee failure because the immediate of the branch instruction is too large. We should use a `far_jump` instead, like we do for all other jumps to `StubRoutines::forward_exception_entry()`.
>> 
>> I can reproduce this reliably with `test/hotspot/jtreg/runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java` and therefore did not add another regression test.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increased timeout

Thank you for fixing this, @TobiHartmann. Looks good to me.

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

Marked as reviewed by mhaessig (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1646#pullrequestreview-3285470722

From thartmann at openjdk.org  Tue Sep 30 15:33:42 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 Sep 2025 15:33:42 GMT
Subject: [lworld] RFR: 8367412: [lworld] Adapter creation fails with
 guarantee(chk == -1 || chk == 0) failed: Field too big for insn [v2]
In-Reply-To: <5sWuGcpydoU-acFKvBAJ70RLC236zFfJUlidgfLOwuI=.489d34cd-d727-4bbb-baa9-eab066930efb@github.com>
References: <uwt5opnioxDMWKBDZHGaHICbxB-T3_tvqo4o5JiK3u8=.0c05ebd3-b86c-457a-a57d-09a82f5b7b1a@github.com>
 <5sWuGcpydoU-acFKvBAJ70RLC236zFfJUlidgfLOwuI=.489d34cd-d727-4bbb-baa9-eab066930efb@github.com>
Message-ID: <3pI2xA-bOWMZyU-N_vQbUXzfOeb-o3MsCsWfSVqGIQE=.fd68ba8c-0818-4496-97d1-ce2250ee7286@github.com>

On Tue, 30 Sep 2025 14:47:03 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> We hit a guarantee failure because the immediate of the branch instruction is too large. We should use a `far_jump` instead, like we do for all other jumps to `StubRoutines::forward_exception_entry()`.
>> 
>> I can reproduce this reliably with `test/hotspot/jtreg/runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java` and therefore did not add another regression test.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increased timeout

Thanks for the review Manuel!

All testing passed.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1646#issuecomment-3352755267
PR Comment: https://git.openjdk.org/valhalla/pull/1646#issuecomment-3352756336

From thartmann at openjdk.org  Tue Sep 30 15:33:44 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 Sep 2025 15:33:44 GMT
Subject: [lworld] Integrated: 8367412: [lworld] Adapter creation fails with
 guarantee(chk == -1 || chk == 0) failed: Field too big for insn
In-Reply-To: <uwt5opnioxDMWKBDZHGaHICbxB-T3_tvqo4o5JiK3u8=.0c05ebd3-b86c-457a-a57d-09a82f5b7b1a@github.com>
References: <uwt5opnioxDMWKBDZHGaHICbxB-T3_tvqo4o5JiK3u8=.0c05ebd3-b86c-457a-a57d-09a82f5b7b1a@github.com>
Message-ID: <Fnc-jt7FilCc9YL8lmi1pc9GSIBF4TW0AAWM5Dwptzs=.4c38dc6e-aa87-489d-8367-d4ad5cea712a@github.com>

On Tue, 30 Sep 2025 13:55:10 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We hit a guarantee failure because the immediate of the branch instruction is too large. We should use a `far_jump` instead, like we do for all other jumps to `StubRoutines::forward_exception_entry()`.
> 
> I can reproduce this reliably with `test/hotspot/jtreg/runtime/valhalla/inlinetypes/classloading/ConcurrentClassLoadingTest.java` and therefore did not add another regression test.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: b298ae08
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b298ae0850fc0d6a1df1e0a802824795d75b1026
Stats:     3 lines in 3 files changed: 0 ins; 1 del; 2 mod

8367412: [lworld] Adapter creation fails with guarantee(chk == -1 || chk == 0) failed: Field too big for insn

Reviewed-by: mhaessig

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

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

From frederic.parain at oracle.com  Tue Sep 30 18:17:48 2025
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 30 Sep 2025 14:17:48 -0400
Subject: CFV: New Valhalla Committer: Marc Chevalier
In-Reply-To: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
References: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
Message-ID: <4088d79a-af9b-4a74-8095-d5e253927f0a@oracle.com>

Vote: Yes

Fred

On 9/30/25 04:00, Tobias Hartmann wrote:
> I hereby nominate Marc Chevalier [1] to Valhalla Committer.
>
> Marc is a member of the JVM Compiler Team at Oracle. He contributed 37 
> changes to the JDK project [2] and 12 changes to the Valhalla project 
> [3].
>
> Votes are due by October 14, 2025, 08:00 UTC.
>
> Only current Valhalla Committers [4] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Lazy Consensus voting instructions, see [5].
>
> Best regards,
> Tobias
>
> [1] https://openjdk.org/census#mchevalier
> [2] 
> https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1
> [3] 
> https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20mchevalier%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
> [4] https://openjdk.java.net/census
> [5] https://openjdk.org/projects/#committer-vote

From frederic.parain at oracle.com  Tue Sep 30 18:18:21 2025
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 30 Sep 2025 14:18:21 -0400
Subject: CFV: New Valhalla Committer: Damon Fenacci
In-Reply-To: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
References: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
Message-ID: <2ab6bed0-d7a4-4a39-b8c8-5b44408fdcd7@oracle.com>

Vote: Yes

Fred

On 9/30/25 04:04, Tobias Hartmann wrote:
> I hereby nominate Damon Fenacci [1] to Valhalla Committer.
>
> Marc is a member of the JVM Compiler Team at Oracle. He contributed 36 
> changes to the JDK project [2] and 7 changes to the Valhalla project [3].
>
> Votes are due by October 14, 2025, 08:00 UTC.
>
> Only current Valhalla Committers [4] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Lazy Consensus voting instructions, see [5].
>
> Best regards,
> Tobias
>
> [1] https://openjdk.org/census#dfenacci
> [2] 
> https://github.com/search?q=author-name%3A%22Damon+Fenacci%22+repo%3Aopenjdk%2Fjdk&type=commits
> [3] 
> https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20dfenacci%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
> [4] https://openjdk.java.net/census
> [5] https://openjdk.org/projects/#committer-vote

From coleen.phillimore at oracle.com  Tue Sep 30 18:41:16 2025
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 30 Sep 2025 14:41:16 -0400
Subject: CFV: New Valhalla Committer: Marc Chevalier
In-Reply-To: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
References: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
Message-ID: <03217447-ef7f-4638-bac7-9c321fd26199@oracle.com>

Vote: yes

On 9/30/25 4:00 AM, Tobias Hartmann wrote:
> I hereby nominate Marc Chevalier [1] to Valhalla Committer.
>
> Marc is a member of the JVM Compiler Team at Oracle. He contributed 37 
> changes to the JDK project [2] and 12 changes to the Valhalla project 
> [3].
>
> Votes are due by October 14, 2025, 08:00 UTC.
>
> Only current Valhalla Committers [4] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Lazy Consensus voting instructions, see [5].
>
> Best regards,
> Tobias
>
> [1] https://openjdk.org/census#mchevalier
> [2] 
> https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1
> [3] 
> https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20mchevalier%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
> [4] https://openjdk.java.net/census
> [5] https://openjdk.org/projects/#committer-vote


From coleen.phillimore at oracle.com  Tue Sep 30 18:41:32 2025
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 30 Sep 2025 14:41:32 -0400
Subject: CFV: New Valhalla Committer: Damon Fenacci
In-Reply-To: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
References: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
Message-ID: <fe9283ee-0834-46c3-876d-48e44b1dd167@oracle.com>

Vote: yes

On 9/30/25 4:04 AM, Tobias Hartmann wrote:
> I hereby nominate Damon Fenacci [1] to Valhalla Committer.
>
> Marc is a member of the JVM Compiler Team at Oracle. He contributed 36 
> changes to the JDK project [2] and 7 changes to the Valhalla project [3].
>
> Votes are due by October 14, 2025, 08:00 UTC.
>
> Only current Valhalla Committers [4] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Lazy Consensus voting instructions, see [5].
>
> Best regards,
> Tobias
>
> [1] https://openjdk.org/census#dfenacci
> [2] 
> https://github.com/search?q=author-name%3A%22Damon+Fenacci%22+repo%3Aopenjdk%2Fjdk&type=commits
> [3] 
> https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20dfenacci%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
> [4] https://openjdk.java.net/census
> [5] https://openjdk.org/projects/#committer-vote


From lois.foltan at oracle.com  Tue Sep 30 19:30:48 2025
From: lois.foltan at oracle.com (Lois Foltan)
Date: Tue, 30 Sep 2025 19:30:48 +0000
Subject: CFV: New Valhalla Committer: Marc Chevalier
In-Reply-To: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
References: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
Message-ID: <BLAPR10MB5156D2FCE746F44F891DD63E8A1AA@BLAPR10MB5156.namprd10.prod.outlook.com>

Vote: yes

Lois

From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Tobias Hartmann <tobias.hartmann at oracle.com>
Date: Tuesday, September 30, 2025 at 4:01?AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Cc: Marc Chevalier <marc.chevalier at oracle.com>
Subject: CFV: New Valhalla Committer: Marc Chevalier
I hereby nominate Marc Chevalier [1] to Valhalla Committer.

Marc is a member of the JVM Compiler Team at Oracle. He contributed 37 changes to the JDK project [2] and 12 changes to the Valhalla project [3].

Votes are due by October 14, 2025, 08:00 UTC.

Only current Valhalla Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

Best regards,
Tobias

[1] https://openjdk.org/census#mchevalier
[2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1
[3] https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20mchevalier%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
[4] https://openjdk.java.net/census
[5] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250930/a9d769ad/attachment-0001.htm>

From lois.foltan at oracle.com  Tue Sep 30 19:31:11 2025
From: lois.foltan at oracle.com (Lois Foltan)
Date: Tue, 30 Sep 2025 19:31:11 +0000
Subject: CFV: New Valhalla Committer: Damon Fenacci
In-Reply-To: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
References: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
Message-ID: <BLAPR10MB5156A47C90B20B30F10FBBCE8A1AA@BLAPR10MB5156.namprd10.prod.outlook.com>

Vote: yes

Lois

From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Tobias Hartmann <tobias.hartmann at oracle.com>
Date: Tuesday, September 30, 2025 at 4:05?AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Cc: Damon Fenacci <damon.fenacci at oracle.com>
Subject: CFV: New Valhalla Committer: Damon Fenacci
I hereby nominate Damon Fenacci [1] to Valhalla Committer.

Marc is a member of the JVM Compiler Team at Oracle. He contributed 36 changes to the JDK project [2] and 7 changes to the Valhalla project [3].

Votes are due by October 14, 2025, 08:00 UTC.

Only current Valhalla Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

Best regards,
Tobias

[1] https://openjdk.org/census#dfenacci
[2] https://github.com/search?q=author-name%3A%22Damon+Fenacci%22+repo%3Aopenjdk%2Fjdk&type=commits
[3] https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20dfenacci%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
[4] https://openjdk.java.net/census
[5] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250930/ce623b37/attachment.htm>

From scolebourne at joda.org  Tue Sep 30 21:04:41 2025
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 30 Sep 2025 22:04:41 +0100
Subject: Value class for ZoneOffset?
Message-ID: <CACzrW9AUztzOMy=BbFh6pCmwUpHBqSy8WCaarnbae-r4uqZEag@mail.gmail.com>

I notice from the updated JEP https://openjdk.org/jeps/401 that
ZoneOffset is not intended to become a value class. I assume this is
because of the id and rules cache variables?

It seems to me that ZoneOffset is very much applicable to be a value,
as it's state is fundamentally an int. Performance tests would be
needed, but it might be possible to create the id and rules on the fly
rather than caching them.

thanks
Stephen

From brian.goetz at oracle.com  Tue Sep 30 21:10:13 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 30 Sep 2025 17:10:13 -0400
Subject: Value class for ZoneOffset?
In-Reply-To: <CACzrW9AUztzOMy=BbFh6pCmwUpHBqSy8WCaarnbae-r4uqZEag@mail.gmail.com>
References: <CACzrW9AUztzOMy=BbFh6pCmwUpHBqSy8WCaarnbae-r4uqZEag@mail.gmail.com>
Message-ID: <48550302-9fae-42d8-a78e-cb8e9eb2ddd7@oracle.com>

Dan can fill in the details on this specific case, but by way of 
background, for JEP 401 we're not trying to migrate _every_ candidate 
value class in the JDK -- just a good set of the most common ones.? So 
any list we came up with is surely going to be just an approximation, 
not the last word.

On 9/30/2025 5:04 PM, Stephen Colebourne wrote:
> I notice from the updated JEPhttps://openjdk.org/jeps/401 that
> ZoneOffset is not intended to become a value class. I assume this is
> because of the id and rules cache variables?
>
> It seems to me that ZoneOffset is very much applicable to be a value,
> as it's state is fundamentally an int. Performance tests would be
> needed, but it might be possible to create the id and rules on the fly
> rather than caching them.
>
> thanks
> Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250930/89562d39/attachment-0001.htm>

From amenkov at openjdk.org  Tue Sep 30 23:35:26 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 30 Sep 2025 23:35:26 GMT
Subject: [lworld] RFR: 8367588: [lworld]
 serviceability/jvmti/valhalla/GetSetLocal/ValueGetSetLocal.java fails with
 JTREG_TEST_THREAD_FACTORY=Virtual
Message-ID: <UbVqzl9L-9UZYtpz4Lcs0MMvK5kWNEg1tx0JGEM7w9U=.25c23bb0-e906-4c00-9d6a-e5f4767f0732@github.com>

Fixed the test

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

Commit messages:
 - fixed test

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

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

From mchevalier at openjdk.org  Tue Sep 30 23:37:01 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 30 Sep 2025 23:37:01 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected" [v2]
In-Reply-To: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
Message-ID: <ldjuHEQsxNxKu9SyWGPJgmzXeNwDVnduZOSRpf3EoVk=.aa4bdfa6-d3ab-4bd6-9374-050310643e92@github.com>

> ## Act I: dead loops
> 
> [JDK-8336003: [lworld] TestLWorld::test151 triggers "Should have been buffered" assert](https://bugs.openjdk.org/browse/JDK-8336003), allows to replace a Phi node by a single input recursively through phis. This change was only added to Valhalla. In mainline, a Phi can be simplified to its single direct input, not through other phis. The valhalla version will work on loops, while the mainline version will reduce all the phis into a single input only if the blob of Phis is acyclic.
> 
> When a loop is dead, it is possible that the said single input is also an output of the phi. After applying the identity, the phi's unique input becomes its own output (or input). For most nodes, that is not allowed. This is probably relatively harmless as the whole code around is dead and will be removed, but it makes some verification fail. It is also possible that some other idealization are not protected against data loops without phis on the way, and would not terminate. It is interesting to notice that applying [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to mainline is enough to reproduce the bug there too.
> 
> We could detect when it's about to happen, and handle the situation differently if we are about to create a very small loop that would be caught by the dead loop detection. It would be possible to make big dead data loop. How annoying that is? Immediately, there is the non-termination problem mentioned above. But also, maybe some nodes can be optimized away by IGVN and end up with a small loop and then the assert would strike again. Is the dead loop check too weak then? It depends what we think is the purpose of this check. During IGVN, we cannot clean up eagerly every dead loop since it would be too expensive to traverse everything. Avoiding dead data loop would also need a lot of traversal. My understanding is that it's rather a sanity check, to make sure that one doesn't mess up the graph surgery and create dead loops accidentally, when something else was meant, and detecting as soon as possible is helpful. So I'm not sure it's worth strengthening the check.
> 
> A way to avoid the creation of dead data loop is to simply limit the simplification allowed by [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to constant nodes: since they don't have input, they can't make a cycle! And it seems enough for the bug initially reported.
> 
> Yet, that makes `test151` in `compiler/valhalla/inlinetypes/TestLWorld.java` fail in another way:...

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

  Set phis input to top initially, not merge with top.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1640/files
  - new: https://git.openjdk.org/valhalla/pull/1640/files/9f2a0de4..7af6110a

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

  Stats: 78 lines in 4 files changed: 21 ins; 46 del; 11 mod
  Patch: https://git.openjdk.org/valhalla/pull/1640.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1640/head:pull/1640

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

From amenkov at openjdk.org  Tue Sep 30 23:39:35 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 30 Sep 2025 23:39:35 GMT
Subject: [lworld] Integrated: 8367588: [lworld]
 serviceability/jvmti/valhalla/GetSetLocal/ValueGetSetLocal.java fails with
 JTREG_TEST_THREAD_FACTORY=Virtual
In-Reply-To: <UbVqzl9L-9UZYtpz4Lcs0MMvK5kWNEg1tx0JGEM7w9U=.25c23bb0-e906-4c00-9d6a-e5f4767f0732@github.com>
References: <UbVqzl9L-9UZYtpz4Lcs0MMvK5kWNEg1tx0JGEM7w9U=.25c23bb0-e906-4c00-9d6a-e5f4767f0732@github.com>
Message-ID: <_rHJd1KKE-o9wSK3qfbRiAEUDC_OQC6CzOnHrtxn-LE=.044f69de-7823-46f4-b5e7-b94032425c25@github.com>

On Tue, 30 Sep 2025 23:27:44 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Fixed the test

This pull request has now been integrated.

Changeset: 29df705a
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/29df705a20fda55047869e4e01a087afbc61adcc
Stats:     11 lines in 3 files changed: 4 ins; 1 del; 6 mod

8367588: [lworld] serviceability/jvmti/valhalla/GetSetLocal/ValueGetSetLocal.java fails with JTREG_TEST_THREAD_FACTORY=Virtual

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

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

From mchevalier at openjdk.org  Tue Sep 30 23:40:31 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 30 Sep 2025 23:40:31 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected" [v2]
In-Reply-To: <502Y1FL7CYU7czxswnBm_Z9dz6gsEdg5R3YUJLQiOEI=.30213c5a-d857-470e-9a4c-5441f59a0239@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
 <6fj_6i-m-YsivIerjV65yKGCm8AJ0kg7PL6Dgz3-wkA=.5080da40-e309-4410-832f-ea1d094c9efa@github.com>
 <Q5YGR7GOP505Wn9nYkOn37yyaV8wdZD8n_IBQ_ejqQo=.611d9e4a-6fc9-491e-804e-0133bc64ae84@github.com>
 <502Y1FL7CYU7czxswnBm_Z9dz6gsEdg5R3YUJLQiOEI=.30213c5a-d857-470e-9a4c-5441f59a0239@github.com>
Message-ID: <rPxVM8ARo8-xrHrnpLcj1GZ1TAMRB7YHd7bqybqLd8g=.274bf5a5-4c7b-4d15-9141-42a671aa1921@github.com>

On Tue, 30 Sep 2025 08:24:37 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> If we initialize the inputs of the `PhiNodes` above `this` to top, we don't even need to merge with anything. We can just skip the call to `merge_with`, no? It seems mostly harmless to change `clone_with_phis` this way, except for the callsite in `Parse::ensure_phi` where I'm not sure of the consequences.
>
> Right, skipping the call would be even better. I think the `ensure_phi` callsite should be fine as well as all the branches that the phi inputs correspond to should either be initialized afterwards or are dead (in which case `top` seems appropriate). But only testing will tell :D

I didn't dig too much, but it seems that if one put top everywhere in `clone_with_phis`, between a quarter and a third of all the tests are broken. Anyway, it doesn't seem good. But making this callsite init the inputs of the phi with top seems to simplify our life and seems to work.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2393064006