From ngasson at openjdk.java.net  Mon Aug  2 06:52:27 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 2 Aug 2021 06:52:27 GMT
Subject: [lworld] RFR: 8271528: [lworld] [TESTBUG] Several C2 IR tests
 fail on AArch64
In-Reply-To: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
References: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
Message-ID: <X5wl3bu0pimoIOvbf4aT43gXcFA_bhtInnCTGQ9XLFc=.5ab71d5a-7999-452f-a85f-6a4762b36c55@github.com>

On Mon, 2 Aug 2021 06:45:48 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The regexes just need to be adjusted slightly for the different opto assembly output.  Also removed an unnecessary extra black line after some loadConP instructions which caused match failures.
> 
> Test hotspot_valhalla on x86 and AArch64.

@chhagedorn I tried to align this with the changes you made in openjdk/jdk at 9856ace

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

PR: https://git.openjdk.java.net/valhalla/pull/515


From ngasson at openjdk.java.net  Mon Aug  2 06:52:27 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 2 Aug 2021 06:52:27 GMT
Subject: [lworld] RFR: 8271528: [lworld] [TESTBUG] Several C2 IR tests fail on
 AArch64
Message-ID: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>

The regexes just need to be adjusted slightly for the different opto assembly output.  Also removed an unnecessary extra black line after some loadConP instructions which caused match failures.

Test hotspot_valhalla on x86 and AArch64.

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

Commit messages:
 - 8271528: [lworld] [TESTBUG] Several C2 IR tests fail on AArch64

Changes: https://git.openjdk.java.net/valhalla/pull/515/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=515&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271528
  Stats: 15 lines in 2 files changed: 3 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/515.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/515/head:pull/515

PR: https://git.openjdk.java.net/valhalla/pull/515


From sadayapalam at openjdk.java.net  Mon Aug  2 11:44:49 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 2 Aug 2021 11:44:49 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v5]
In-Reply-To: <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
 <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
Message-ID: <1QkKpCo-4Mrwyyle5yqsDXfvS9fBwpBtPvRMpkQtKBM=.80e6df58-c81f-49c8-a712-990c5017696d@github.com>

On Sun, 25 Jul 2021 21:14:57 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> Make .default a separate node type in the parser.
>> 
>> ## Issue
>> [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation
>> 
>> Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes.
>
> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

Changes requested by sadayapalam (Committer).

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 284:

> 282:         if (applyTree != null) {
> 283:             return applyTree.arguments.isEmpty();
> 284:         } else {

The return statement is not reachable and so the block is not useful. This is because, Foo<>.default is a syntax error. Given a primitive class Foo<T> we will only support Foo.default involving implicit diamond like inference and will not support Foo<>.default which is what this code is handling.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 287:

> 285:             // No type arguments before .default - Consider if the type is generic or not
> 286:             return clazztype == null || clazztype.tsym.type.isParameterized();
> 287:         }

This method is problematic - This will always treat Foo.default as a poly expression in an invocation context even when the concerned primitive type is not a generic class.  For instance the Foo.default expression in the following snippet becomes a poly expression when it is a standalone expression in reality:


primitive class X {

    static void foo(Object o) {
    }

    public static void main(String [] args) {
        foo(X.default);    
    }

}

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 295:

> 293:             case TYPEAPPLY: return (JCTypeApply)tree;
> 294:             case NEWCLASS: return getTypeApplication(((JCNewClass)tree).clazz);
> 295:             case ANNOTATED_TYPE: return getTypeApplication(((JCAnnotatedType)tree).underlyingType);

I think there is a copy + paste problem. We can never see a NEWCLASS here.  The LHS of .default is just a type node and cannot be an rvalue expression ==>  new X().default is illegal.

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

PR: https://git.openjdk.java.net/valhalla/pull/369


From sadayapalam at openjdk.java.net  Mon Aug  2 11:44:50 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 2 Aug 2021 11:44:50 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v5]
In-Reply-To: <1QkKpCo-4Mrwyyle5yqsDXfvS9fBwpBtPvRMpkQtKBM=.80e6df58-c81f-49c8-a712-990c5017696d@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
 <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
 <1QkKpCo-4Mrwyyle5yqsDXfvS9fBwpBtPvRMpkQtKBM=.80e6df58-c81f-49c8-a712-990c5017696d@github.com>
Message-ID: <5K_6wq3L6PgfVBX-5NDwNzQoP-7L0MOW8jkpBQ_eKvI=.7889d090-822e-48d6-b925-eca64ebb168d@github.com>

On Mon, 2 Aug 2021 11:07:20 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 295:
> 
>> 293:             case TYPEAPPLY: return (JCTypeApply)tree;
>> 294:             case NEWCLASS: return getTypeApplication(((JCNewClass)tree).clazz);
>> 295:             case ANNOTATED_TYPE: return getTypeApplication(((JCAnnotatedType)tree).underlyingType);
> 
> I think there is a copy + paste problem. We can never see a NEWCLASS here.  The LHS of .default is just a type node and cannot be an rvalue expression ==>  new X().default is illegal.

I think perhaps what we really need to do here is to attribute the clazz node of JCDefaultValue first - perhaps by first making a copy of the node and then see if it is a generic class but lacks type arguments. Such as this: 


@Override
    public void visitDefaultValue(JCDefaultValue that) {
        JCExpression copy = new TreeCopier<Void>(attr.make).copy(that.clazz);
        attr.attribType(copy, env);
        if (copy.type.getTypeArguments().isEmpty() && copy.type.tsym.type.isParameterized()) {
            processArg(that, speculativeTree -> new ResolvedDefaultType(that, env, speculativeTree));
        } else {
            //not a poly expression, just call Attr
            setResult(that, attr.attribTree(that, env, attr.unknownExprInfo));
        }
    }

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

PR: https://git.openjdk.java.net/valhalla/pull/369


From sadayapalam at openjdk.java.net  Mon Aug  2 14:47:45 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 2 Aug 2021 14:47:45 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v5]
In-Reply-To: <1QkKpCo-4Mrwyyle5yqsDXfvS9fBwpBtPvRMpkQtKBM=.80e6df58-c81f-49c8-a712-990c5017696d@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
 <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
 <1QkKpCo-4Mrwyyle5yqsDXfvS9fBwpBtPvRMpkQtKBM=.80e6df58-c81f-49c8-a712-990c5017696d@github.com>
Message-ID: <wR5356j0afnA51eCRzF4Dxog85hNBo38iK7egFmSlkY=.a85f3b2c-a72a-4f98-8e16-c4082967e9a4@github.com>

On Mon, 2 Aug 2021 11:01:01 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 284:
> 
>> 282:         if (applyTree != null) {
>> 283:             return applyTree.arguments.isEmpty();
>> 284:         } else {
> 
> The return statement is not reachable and so the block is not useful. This is because, Foo<>.default is a syntax error. Given a primitive class Foo<T> we will only support Foo.default involving implicit diamond like inference and will not support Foo<>.default which is what this code is handling.

(I think I meant to say return applyTree.arguments.isEmpty(); will never be true.)

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

PR: https://git.openjdk.java.net/valhalla/pull/369


From mchung at openjdk.java.net  Mon Aug  2 23:15:49 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 2 Aug 2021 23:15:49 GMT
Subject: [lworld] RFR: JDK-8271405: [lworld] Redo
 test/jdk/java/lang/invoke/VarHandles changes for JDK-8269956
Message-ID: <bQz3LinpZLt0xnr2NK9xcmULihEvzDo8qRttdJJtpGI=.fa418c76-a582-43b6-a8c0-0b371faa0ca3@github.com>

test/jdk/java/lang/invoke/VarHandles are generated from the template files.   Redo the fix for JDK-8269956 and update the template files.

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

Commit messages:
 - JDK-8271405: [lworld] Redo test/jdk/java/lang/invoke/VarHandles changes for JDK-8269956

Changes: https://git.openjdk.java.net/valhalla/pull/516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=516&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271405
  Stats: 1633 lines in 33 files changed: 78 ins; 16 del; 1539 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/516/head:pull/516

PR: https://git.openjdk.java.net/valhalla/pull/516


From mchung at openjdk.java.net  Tue Aug  3 00:06:34 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 3 Aug 2021 00:06:34 GMT
Subject: [lworld] RFR: JDK-8271405: [lworld] Redo
 test/jdk/java/lang/invoke/VarHandles changes for JDK-8269956 [v2]
In-Reply-To: <bQz3LinpZLt0xnr2NK9xcmULihEvzDo8qRttdJJtpGI=.fa418c76-a582-43b6-a8c0-0b371faa0ca3@github.com>
References: <bQz3LinpZLt0xnr2NK9xcmULihEvzDo8qRttdJJtpGI=.fa418c76-a582-43b6-a8c0-0b371faa0ca3@github.com>
Message-ID: <HQFOOaPlwlU4VH67KqVwyxITjDMSyT0t5w9N-9ywnP8=.47d58405-85d4-43a6-a80b-4156f5d2e75d@github.com>

> test/jdk/java/lang/invoke/VarHandles are generated from the template files.   Redo the fix for JDK-8269956 and update the template files.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Fix valhalla/jdk merge issue

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/516/files
  - new: https://git.openjdk.java.net/valhalla/pull/516/files/10b7fe37..afc8914c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=516&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=516&range=00-01

  Stats: 36 lines in 10 files changed: 18 ins; 9 del; 9 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/516/head:pull/516

PR: https://git.openjdk.java.net/valhalla/pull/516


From mchung at openjdk.java.net  Tue Aug  3 00:49:27 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 3 Aug 2021 00:49:27 GMT
Subject: [lworld] RFR: JDK-8271405: [lworld] Redo
 test/jdk/java/lang/invoke/VarHandles changes for JDK-8269956 [v3]
In-Reply-To: <bQz3LinpZLt0xnr2NK9xcmULihEvzDo8qRttdJJtpGI=.fa418c76-a582-43b6-a8c0-0b371faa0ca3@github.com>
References: <bQz3LinpZLt0xnr2NK9xcmULihEvzDo8qRttdJJtpGI=.fa418c76-a582-43b6-a8c0-0b371faa0ca3@github.com>
Message-ID: <qnXh11fOBOdr0l9OudR5Xz3qSfptATDBdNqbtfhSzfo=.a2d97129-a435-4962-a8c2-8da82e450b69@github.com>

> test/jdk/java/lang/invoke/VarHandles are generated from the template files.   Redo the fix for JDK-8269956 and update the template files.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  more merge cleanup

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/516/files
  - new: https://git.openjdk.java.net/valhalla/pull/516/files/afc8914c..c81614b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=516&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=516&range=01-02

  Stats: 22 lines in 10 files changed: 0 ins; 14 del; 8 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/516/head:pull/516

PR: https://git.openjdk.java.net/valhalla/pull/516


From mchung at openjdk.java.net  Tue Aug  3 01:32:47 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 3 Aug 2021 01:32:47 GMT
Subject: [lworld] Integrated: JDK-8271405: [lworld] Redo
 test/jdk/java/lang/invoke/VarHandles changes for JDK-8269956
In-Reply-To: <bQz3LinpZLt0xnr2NK9xcmULihEvzDo8qRttdJJtpGI=.fa418c76-a582-43b6-a8c0-0b371faa0ca3@github.com>
References: <bQz3LinpZLt0xnr2NK9xcmULihEvzDo8qRttdJJtpGI=.fa418c76-a582-43b6-a8c0-0b371faa0ca3@github.com>
Message-ID: <kh06X_9hYEvHzlyYhrGro4wuaJXSdDgyf7IfWvx7xWU=.9d7eb857-ebb2-428a-9286-cc715776c4a3@github.com>

On Mon, 2 Aug 2021 23:09:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> test/jdk/java/lang/invoke/VarHandles are generated from the template files.   Redo the fix for JDK-8269956 and update the template files.

This pull request has now been integrated.

Changeset: 9fe23045
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/9fe230452505ad7a49da8216f06c0196426eeada
Stats:     1643 lines in 33 files changed: 80 ins; 23 del; 1540 mod

8271405: [lworld] Redo test/jdk/java/lang/invoke/VarHandles changes for JDK-8269956

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

PR: https://git.openjdk.java.net/valhalla/pull/516


From thartmann at openjdk.java.net  Tue Aug  3 08:02:08 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 3 Aug 2021 08:02:08 GMT
Subject: [lworld] RFR: 8264340: [lworld] [AArch64] TestLWorld.java
 assertion failure in OopFlow::build_oop_map
In-Reply-To: <ffbEIYmZdjh7eJcjQN8_CUJJEEG5L4HPBbyDn9_AZw0=.14575205-141b-439c-9653-a6a56d716d51@github.com>
References: <ffbEIYmZdjh7eJcjQN8_CUJJEEG5L4HPBbyDn9_AZw0=.14575205-141b-439c-9653-a6a56d716d51@github.com>
Message-ID: <0jnPZ8mzsPCTlEplRv17AuSoERrVX1ehbjPmiTsqW-w=.203cb91a-e184-4b11-9718-eeae56c173cb@github.com>

On Tue, 13 Jul 2021 11:08:47 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This happens reliably in TestLWorld::test9() scenario 0 on AArch64:
> 
> 
>   # A fatal error has been detected by the Java Runtime Environment:
>   #
>   # Internal Error (/mnt/nicgas01-pc/valhalla/src/hotspot/share/opto/buildOopMap.cpp:360), pid=8866, tid=8882
>   # assert(false) failed: there should be a oop in OopMap instead of a live raw oop at safepoint
>   #
> 
> 
> The crash can also be reproduced on x86 by running with -XX:+OptoScheduling (this is the default on AArch64).
> 
> The problem seems to be caused by a CheckCastPP node whose input is a raw pointer being scheduled after a SafePoint node such that the raw pointer is live in a register over the safepoint.
> 
> Before scheduling we have a basic block like:
> 
> 
>   R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>   ...
>   R0      84  checkCastPP  ===  11  73  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>   ...
>           6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
> 
> 
> But after scheduling this is transformed into:
> 
> 
>   R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>   ...
>           6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  | 164  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
>   ...
>   R0      84  checkCastPP  ===  11  73  | 67  68  69  70  71  72  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
> 
> 
> Where R0 is holding the live raw pointer over the safepoint, which triggers the assertion failure.
> 
> The fix here is to add a precedence edge from any CheckCastPP with a raw pointer input to the following safepoint, which prevents them being rearranged. I'm not very familiar with this code so I can't be sure this is the correct solution, but the same logic exists in GCM's PhaseCFG::schedule_late().

I finally got a chance to debug this. Here's what I think is going on that makes this specific to Valhalla / inline types (based on `TestLWorld::test9`):
1. We buffer the inline type returned by `MyValue1.setX` in the loop right before the safepoint (for example, because `-XX:+AlwaysIncrementalInline -XX:-InlineTypeReturnedAsFields` are set). The corresponding `CheckCastPP` is connected to the safepoint.
2. On return, we re-use the `CheckCastPP` from that allocation instead of allocating again.
3. Scalarization replaces the `CheckCastPP` safepoint usage, allowing it to flow below the safepoint during scheduling.

Therefore, I think your fix is correct. Maybe add a comment explaining the details of how this can happen.

Of course, it's unfortunate that the return keeps the allocation(s) in the loop alive when it would be sufficient to allocate only on return. However, I don't think we can easily fix this and it's hopefully an edge case.

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

PR: https://git.openjdk.java.net/valhalla/pull/479


From chagedorn at openjdk.java.net  Tue Aug  3 08:36:44 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 3 Aug 2021 08:36:44 GMT
Subject: [lworld] RFR: 8271528: [lworld] [TESTBUG] Several C2 IR tests
 fail on AArch64
In-Reply-To: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
References: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
Message-ID: <J7eaaCo9mYwTDELnXSAMi9ig4ZCZy9HDTzNRdROynjY=.3a54eb98-0573-46a6-82c8-582dc2e5c121@github.com>

On Mon, 2 Aug 2021 06:45:48 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The regexes just need to be adjusted slightly for the different opto assembly output.  Also removed an unnecessary extra black line after some loadConP instructions which caused match failures.
> 
> Test hotspot_valhalla on x86 and AArch64.

The adaptations look good! @TobiHartmann additionally submitted some testing.

I've just seen that [TestUnloadedInlineTypeField](https://github.com/openjdk/valhalla/blob/lworld/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestUnloadedInlineTypeField.java) is not enabled for aarch64. Was that one missed?

test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypes.java line 117:

> 115:         protected static final String ALLOCA_G = "(.*call,static.*wrapper for: _new_array_Java" + END;
> 116:         // Inline type allocation
> 117:         protected static final String MYVALUE_KLASS = "precise klass \\[(L|Q)compiler/valhalla/inlinetypes/MyValue";

Just about the variable name: Shouldn't this be `MYVALUE_ARRAY_KLASS`?

test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypes.java line 146:

> 144:         protected static final String PREDICATE_TRAP = START + "CallStaticJava" + MID + "uncommon_trap.*predicate" + END;
> 145:         protected static final String MEMBAR = START + "MemBar" + MID + END;
> 146:         protected static final String CHECKCAST_ARRAY = "(((?i:cmp|CLFI|CLR).*" + MYVALUE_KLASS + ".*;:|.*(?i:mov|or).*" + MYVALUE_KLASS + ".*;:.*\\R.*(cmp|CMP|CLR))" + END;

`CLFI` and `CLR` is only used for s390 and PPC, respectively. But I guess it does not hurt to keep it that way.

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

Marked as reviewed by chagedorn (no project role).

PR: https://git.openjdk.java.net/valhalla/pull/515


From thartmann at openjdk.java.net  Tue Aug  3 09:05:03 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 3 Aug 2021 09:05:03 GMT
Subject: [lworld] RFR: 8271528: [lworld] [TESTBUG] Several C2 IR tests
 fail on AArch64
In-Reply-To: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
References: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
Message-ID: <w689j2L_7Rc6f_MIhP42zwtfTaaNEGltGtEPi0TTnLc=.09c457be-a524-4087-878b-cd46dd6caa96@github.com>

On Mon, 2 Aug 2021 06:45:48 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The regexes just need to be adjusted slightly for the different opto assembly output.  Also removed an unnecessary extra black line after some loadConP instructions which caused match failures.
> 
> Test hotspot_valhalla on x86 and AArch64.

Marked as reviewed by thartmann (Committer).

Testing looks good.

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

PR: https://git.openjdk.java.net/valhalla/pull/515


From sadayapalam at openjdk.java.net  Tue Aug  3 09:23:48 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 3 Aug 2021 09:23:48 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v5]
In-Reply-To: <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
 <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
Message-ID: <ufKizDE9MLy56nRuAP5k_J9EOvq998pyDIImd_NlqTI=.c88649b8-d84c-421a-91dd-d4eb2499fb53@github.com>

On Sun, 25 Jul 2021 21:14:57 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> Make .default a separate node type in the parser.
>> 
>> ## Issue
>> [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation
>> 
>> Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes.
>
> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 736:

> 734:      */
> 735:     class ResolvedDefaultType extends ResolvedMemberType<JCDefaultValue> {
> 736: 

I am surprised that ResolvedDefaultType extends ResolvedMemberType rather than ArgumentType directly. While the Inference behavior could be indirectly modelled it as if the class has a generic factory method named 'default':

<T> static Foo<T> default() { ... }

this implementation detail could be pushed deep down and not manifest here and in  elsewhere (setPolyKind())

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

PR: https://git.openjdk.java.net/valhalla/pull/369


From sadayapalam at openjdk.java.net  Tue Aug  3 09:27:48 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 3 Aug 2021 09:27:48 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v5]
In-Reply-To: <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
 <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
Message-ID: <GEsbO3lnXNm8cGu8sXQCHO0f2JFlv-1PzOoH0gMLX4I=.91dd33e6-21f0-414a-bcc8-8e5661cb2643@github.com>

On Sun, 25 Jul 2021 21:14:57 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> Make .default a separate node type in the parser.
>> 
>> ## Issue
>> [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation
>> 
>> Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes.
>
> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

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

> 5077:                         diags.fragment(Fragments.CantApplyDiamond1(Fragments.Diamond(tsym), details)));
> 5078:             }
> 5079:         };

I don't see a test that triggers this diagnostic.

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

PR: https://git.openjdk.java.net/valhalla/pull/369


From sadayapalam at openjdk.java.net  Tue Aug  3 09:32:57 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 3 Aug 2021 09:32:57 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v5]
In-Reply-To: <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
 <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
Message-ID: <GT-v6LfSsG5zwBsyrHBCibrM51xeYBMe7AvY0IKdZWw=.cb25b6e7-a6c7-49b0-aa64-96328751df17@github.com>

On Sun, 25 Jul 2021 21:14:57 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> Make .default a separate node type in the parser.
>> 
>> ## Issue
>> [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation
>> 
>> Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes.
>
> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 321:

> 319:                 ((JCDefaultValue)tree).polyKind = pkind;
> 320:                 break;
> 321:             case REFERENCE:

This is surprising. I would expected polyKind to be set in a similar fashion to switch and conditional expressions.

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

PR: https://git.openjdk.java.net/valhalla/pull/369


From sadayapalam at openjdk.java.net  Tue Aug  3 09:38:14 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 3 Aug 2021 09:38:14 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v5]
In-Reply-To: <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
 <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
Message-ID: <I5U6lONHR354nDNcsjxW5VxClaHY1tal7N9sk6cb5-8=.05ff7f61-bfc5-424e-a44e-7e02399eb0be@github.com>

On Sun, 25 Jul 2021 21:14:57 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> Make .default a separate node type in the parser.
>> 
>> ## Issue
>> [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation
>> 
>> Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes.
>
> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

Hi Jesper, I have left some comments - but I will need to make a couple of more passes to fully understand the implementation as this is a fairly involved and complex task. I will actually have to tinker with the version you have posted to comprehend it - Could you give me some time - I will play around with it and propose a version that addresses the problems I have outlined and also includes further tweaks that could simplify the implementation more ? Then we can study it, finalize it and then ask Maurizio for a final review once both of us are satisfied.

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

PR: https://git.openjdk.java.net/valhalla/pull/369


From ngasson at openjdk.java.net  Tue Aug  3 10:34:22 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 3 Aug 2021 10:34:22 GMT
Subject: [lworld] RFR: 8264340: [lworld] [AArch64] TestLWorld.java
 assertion failure in OopFlow::build_oop_map [v2]
In-Reply-To: <ffbEIYmZdjh7eJcjQN8_CUJJEEG5L4HPBbyDn9_AZw0=.14575205-141b-439c-9653-a6a56d716d51@github.com>
References: <ffbEIYmZdjh7eJcjQN8_CUJJEEG5L4HPBbyDn9_AZw0=.14575205-141b-439c-9653-a6a56d716d51@github.com>
Message-ID: <Hmt3Rmz77l33nusjZ0_75je8YNPntY0hpgGA3WwdRaw=.1f735beb-791d-4adc-96f5-262f11186aaf@github.com>

> This happens reliably in TestLWorld::test9() scenario 0 on AArch64:
> 
> 
>   # A fatal error has been detected by the Java Runtime Environment:
>   #
>   # Internal Error (/mnt/nicgas01-pc/valhalla/src/hotspot/share/opto/buildOopMap.cpp:360), pid=8866, tid=8882
>   # assert(false) failed: there should be a oop in OopMap instead of a live raw oop at safepoint
>   #
> 
> 
> The crash can also be reproduced on x86 by running with -XX:+OptoScheduling (this is the default on AArch64).
> 
> The problem seems to be caused by a CheckCastPP node whose input is a raw pointer being scheduled after a SafePoint node such that the raw pointer is live in a register over the safepoint.
> 
> Before scheduling we have a basic block like:
> 
> 
>   R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>   ...
>   R0      84  checkCastPP  ===  11  73  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>   ...
>           6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
> 
> 
> But after scheduling this is transformed into:
> 
> 
>   R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>   ...
>           6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  | 164  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
>   ...
>   R0      84  checkCastPP  ===  11  73  | 67  68  69  70  71  72  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
> 
> 
> Where R0 is holding the live raw pointer over the safepoint, which triggers the assertion failure.
> 
> The fix here is to add a precedence edge from any CheckCastPP with a raw pointer input to the following safepoint, which prevents them being rearranged. I'm not very familiar with this code so I can't be sure this is the correct solution, but the same logic exists in GCM's PhaseCFG::schedule_late().

Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:

  Add more detailed comment

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/479/files
  - new: https://git.openjdk.java.net/valhalla/pull/479/files/08df0964..a31c3eca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=479&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=479&range=00-01

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

PR: https://git.openjdk.java.net/valhalla/pull/479


From ngasson at openjdk.java.net  Tue Aug  3 10:34:22 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 3 Aug 2021 10:34:22 GMT
Subject: [lworld] RFR: 8264340: [lworld] [AArch64] TestLWorld.java
 assertion failure in OopFlow::build_oop_map
In-Reply-To: <0jnPZ8mzsPCTlEplRv17AuSoERrVX1ehbjPmiTsqW-w=.203cb91a-e184-4b11-9718-eeae56c173cb@github.com>
References: <ffbEIYmZdjh7eJcjQN8_CUJJEEG5L4HPBbyDn9_AZw0=.14575205-141b-439c-9653-a6a56d716d51@github.com>
 <0jnPZ8mzsPCTlEplRv17AuSoERrVX1ehbjPmiTsqW-w=.203cb91a-e184-4b11-9718-eeae56c173cb@github.com>
Message-ID: <Sl3YkN7rQmGkXXtIW8T-mfGbrD4hQdrNQLUP7YYrKfI=.26fdb87f-674e-4288-b10b-2c28a3f57eb5@github.com>

On Tue, 3 Aug 2021 07:57:59 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> This happens reliably in TestLWorld::test9() scenario 0 on AArch64:
>> 
>> 
>>   # A fatal error has been detected by the Java Runtime Environment:
>>   #
>>   # Internal Error (/mnt/nicgas01-pc/valhalla/src/hotspot/share/opto/buildOopMap.cpp:360), pid=8866, tid=8882
>>   # assert(false) failed: there should be a oop in OopMap instead of a live raw oop at safepoint
>>   #
>> 
>> 
>> The crash can also be reproduced on x86 by running with -XX:+OptoScheduling (this is the default on AArch64).
>> 
>> The problem seems to be caused by a CheckCastPP node whose input is a raw pointer being scheduled after a SafePoint node such that the raw pointer is live in a register over the safepoint.
>> 
>> Before scheduling we have a basic block like:
>> 
>> 
>>   R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>>   ...
>>   R0      84  checkCastPP  ===  11  73  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>>   ...
>>           6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
>> 
>> 
>> But after scheduling this is transformed into:
>> 
>> 
>>   R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>>   ...
>>           6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  | 164  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
>>   ...
>>   R0      84  checkCastPP  ===  11  73  | 67  68  69  70  71  72  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>> 
>> 
>> Where R0 is holding the live raw pointer over the safepoint, which triggers the assertion failure.
>> 
>> The fix here is to add a precedence edge from any CheckCastPP with a raw pointer input to the following safepoint, which prevents them being rearranged. I'm not very familiar with this code so I can't be sure this is the correct solution, but the same logic exists in GCM's PhaseCFG::schedule_late().
>
> I finally got a chance to debug this. Here's what I think is going on that makes this specific to Valhalla / inline types (based on `TestLWorld::test9`):
> 1. We buffer the inline type returned by `MyValue1.setX` in the loop right before the safepoint (for example, because `-XX:+AlwaysIncrementalInline -XX:-InlineTypeReturnedAsFields` are set). The corresponding `CheckCastPP` is connected to the safepoint.
> 2. On return, we re-use the `CheckCastPP` from that allocation instead of allocating again.
> 3. Scalarization replaces the `CheckCastPP` safepoint usage, allowing it to flow below the safepoint during scheduling.
> 
> Therefore, I think your fix is correct. Maybe add a comment explaining the details of how this can happen.
> 
> Of course, it's unfortunate that the return keeps the allocation(s) in the loop alive when it would be sufficient to allocate only on return. However, I don't think we can easily fix this and it's hopefully an edge case.

Thanks for looking into this @TobiHartmann. I've added some more explanation to the comment.

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

PR: https://git.openjdk.java.net/valhalla/pull/479


From thartmann at openjdk.java.net  Tue Aug  3 10:50:47 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 3 Aug 2021 10:50:47 GMT
Subject: [lworld] RFR: 8264340: [lworld] [AArch64] TestLWorld.java
 assertion failure in OopFlow::build_oop_map [v2]
In-Reply-To: <Hmt3Rmz77l33nusjZ0_75je8YNPntY0hpgGA3WwdRaw=.1f735beb-791d-4adc-96f5-262f11186aaf@github.com>
References: <ffbEIYmZdjh7eJcjQN8_CUJJEEG5L4HPBbyDn9_AZw0=.14575205-141b-439c-9653-a6a56d716d51@github.com>
 <Hmt3Rmz77l33nusjZ0_75je8YNPntY0hpgGA3WwdRaw=.1f735beb-791d-4adc-96f5-262f11186aaf@github.com>
Message-ID: <xRuXnu6PvQM1KGJlTxuyU55WWTvUN8YVYg6o4g6o39g=.f2e52687-2619-4a71-b065-ec03a11873df@github.com>

On Tue, 3 Aug 2021 10:34:22 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> This happens reliably in TestLWorld::test9() scenario 0 on AArch64:
>> 
>> 
>>   # A fatal error has been detected by the Java Runtime Environment:
>>   #
>>   # Internal Error (/mnt/nicgas01-pc/valhalla/src/hotspot/share/opto/buildOopMap.cpp:360), pid=8866, tid=8882
>>   # assert(false) failed: there should be a oop in OopMap instead of a live raw oop at safepoint
>>   #
>> 
>> 
>> The crash can also be reproduced on x86 by running with -XX:+OptoScheduling (this is the default on AArch64).
>> 
>> The problem seems to be caused by a CheckCastPP node whose input is a raw pointer being scheduled after a SafePoint node such that the raw pointer is live in a register over the safepoint.
>> 
>> Before scheduling we have a basic block like:
>> 
>> 
>>   R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>>   ...
>>   R0      84  checkCastPP  ===  11  73  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>>   ...
>>           6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
>> 
>> 
>> But after scheduling this is transformed into:
>> 
>> 
>>   R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>>   ...
>>           6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  | 164  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
>>   ...
>>   R0      84  checkCastPP  ===  11  73  | 67  68  69  70  71  72  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>> 
>> 
>> Where R0 is holding the live raw pointer over the safepoint, which triggers the assertion failure.
>> 
>> The fix here is to add a precedence edge from any CheckCastPP with a raw pointer input to the following safepoint, which prevents them being rearranged. I'm not very familiar with this code so I can't be sure this is the correct solution, but the same logic exists in GCM's PhaseCFG::schedule_late().
>
> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more detailed comment

Looks good.

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

Marked as reviewed by thartmann (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/479


From ngasson at openjdk.java.net  Tue Aug  3 10:53:12 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 3 Aug 2021 10:53:12 GMT
Subject: [lworld] RFR: 8271528: [lworld] [TESTBUG] Several C2 IR tests
 fail on AArch64 [v2]
In-Reply-To: <J7eaaCo9mYwTDELnXSAMi9ig4ZCZy9HDTzNRdROynjY=.3a54eb98-0573-46a6-82c8-582dc2e5c121@github.com>
References: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
 <J7eaaCo9mYwTDELnXSAMi9ig4ZCZy9HDTzNRdROynjY=.3a54eb98-0573-46a6-82c8-582dc2e5c121@github.com>
Message-ID: <_SLftLdYM2092tWwOhp-u9ui_uApHKv6df_7KN5i6gY=.e39df293-e3e0-4851-bfd5-95115c571609@github.com>

On Tue, 3 Aug 2021 08:34:04 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> 
> I've just seen that [TestUnloadedInlineTypeField](https://github.com/openjdk/valhalla/blob/lworld/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestUnloadedInlineTypeField.java) is not enabled for aarch64. Was that one missed?

Thanks, I missed that one. I've enabled too now (passes on AArch64).

> test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypes.java line 117:
> 
>> 115:         protected static final String ALLOCA_G = "(.*call,static.*wrapper for: _new_array_Java" + END;
>> 116:         // Inline type allocation
>> 117:         protected static final String MYVALUE_KLASS = "precise klass \\[(L|Q)compiler/valhalla/inlinetypes/MyValue";
> 
> Just about the variable name: Shouldn't this be `MYVALUE_ARRAY_KLASS`?

Yes, I've changed it.

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

PR: https://git.openjdk.java.net/valhalla/pull/515


From ngasson at openjdk.java.net  Tue Aug  3 10:53:08 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 3 Aug 2021 10:53:08 GMT
Subject: [lworld] RFR: 8271528: [lworld] [TESTBUG] Several C2 IR tests
 fail on AArch64 [v2]
In-Reply-To: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
References: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
Message-ID: <2kandBIFZ4hNeVpsbks_uh_nsuzMUJKLJoogSRd2eNI=.98a00b85-55c2-47b7-a12d-74faedb53f1c@github.com>

> The regexes just need to be adjusted slightly for the different opto assembly output.  Also removed an unnecessary extra black line after some loadConP instructions which caused match failures.
> 
> Test hotspot_valhalla on x86 and AArch64.

Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:

  Rename variable and add missing test

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/515/files
  - new: https://git.openjdk.java.net/valhalla/pull/515/files/2d646c1e..6e3412e3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=515&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=515&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/515.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/515/head:pull/515

PR: https://git.openjdk.java.net/valhalla/pull/515


From chagedorn at openjdk.java.net  Tue Aug  3 11:34:45 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 3 Aug 2021 11:34:45 GMT
Subject: [lworld] RFR: 8271528: [lworld] [TESTBUG] Several C2 IR tests
 fail on AArch64 [v2]
In-Reply-To: <2kandBIFZ4hNeVpsbks_uh_nsuzMUJKLJoogSRd2eNI=.98a00b85-55c2-47b7-a12d-74faedb53f1c@github.com>
References: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
 <2kandBIFZ4hNeVpsbks_uh_nsuzMUJKLJoogSRd2eNI=.98a00b85-55c2-47b7-a12d-74faedb53f1c@github.com>
Message-ID: <RuIh1n_bbeY7Nm8-NVSKeVpMxdl8pCG2fWpPUWcS2QQ=.5a059391-4621-4765-80c0-99b0db4f139b@github.com>

On Tue, 3 Aug 2021 10:53:08 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> The regexes just need to be adjusted slightly for the different opto assembly output.  Also removed an unnecessary extra black line after some loadConP instructions which caused match failures.
>> 
>> Test hotspot_valhalla on x86 and AArch64.
>
> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename variable and add missing test

Marked as reviewed by chagedorn (no project role).

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

PR: https://git.openjdk.java.net/valhalla/pull/515


From thartmann at openjdk.java.net  Tue Aug  3 12:00:52 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 3 Aug 2021 12:00:52 GMT
Subject: [lworld] RFR: 8271528: [lworld] [TESTBUG] Several C2 IR tests
 fail on AArch64 [v2]
In-Reply-To: <2kandBIFZ4hNeVpsbks_uh_nsuzMUJKLJoogSRd2eNI=.98a00b85-55c2-47b7-a12d-74faedb53f1c@github.com>
References: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
 <2kandBIFZ4hNeVpsbks_uh_nsuzMUJKLJoogSRd2eNI=.98a00b85-55c2-47b7-a12d-74faedb53f1c@github.com>
Message-ID: <O9sYC1Y4fTtMzwsO2-o03cRPl6tKR_JoGXdMwaxNdl4=.3d584184-4f6d-4bc2-a28c-83e6fb8124fb@github.com>

On Tue, 3 Aug 2021 10:53:08 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> The regexes just need to be adjusted slightly for the different opto assembly output.  Also removed an unnecessary extra black line after some loadConP instructions which caused match failures.
>> 
>> Test hotspot_valhalla on x86 and AArch64.
>
> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename variable and add missing test

Marked as reviewed by thartmann (Committer).

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

PR: https://git.openjdk.java.net/valhalla/pull/515


From ngasson at openjdk.java.net  Tue Aug  3 14:31:52 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 3 Aug 2021 14:31:52 GMT
Subject: [lworld] Integrated: 8264340: [lworld] [AArch64] TestLWorld.java
 assertion failure in OopFlow::build_oop_map
In-Reply-To: <ffbEIYmZdjh7eJcjQN8_CUJJEEG5L4HPBbyDn9_AZw0=.14575205-141b-439c-9653-a6a56d716d51@github.com>
References: <ffbEIYmZdjh7eJcjQN8_CUJJEEG5L4HPBbyDn9_AZw0=.14575205-141b-439c-9653-a6a56d716d51@github.com>
Message-ID: <ki65oiFEuWd07uwuo0aFeFnoXgNFk-Y_ahjiPksZx-k=.70692dde-6ae8-48c9-81d5-68d64b8b06f8@github.com>

On Tue, 13 Jul 2021 11:08:47 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This happens reliably in TestLWorld::test9() scenario 0 on AArch64:
> 
> 
>   # A fatal error has been detected by the Java Runtime Environment:
>   #
>   # Internal Error (/mnt/nicgas01-pc/valhalla/src/hotspot/share/opto/buildOopMap.cpp:360), pid=8866, tid=8882
>   # assert(false) failed: there should be a oop in OopMap instead of a live raw oop at safepoint
>   #
> 
> 
> The crash can also be reproduced on x86 by running with -XX:+OptoScheduling (this is the default on AArch64).
> 
> The problem seems to be caused by a CheckCastPP node whose input is a raw pointer being scheduled after a SafePoint node such that the raw pointer is live in a register over the safepoint.
> 
> Before scheduling we have a basic block like:
> 
> 
>   R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>   ...
>   R0      84  checkCastPP  ===  11  73  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>   ...
>           6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
> 
> 
> But after scheduling this is transformed into:
> 
> 
>   R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>   ...
>           6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  | 164  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
>   ...
>   R0      84  checkCastPP  ===  11  73  | 67  68  69  70  71  72  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
> 
> 
> Where R0 is holding the live raw pointer over the safepoint, which triggers the assertion failure.
> 
> The fix here is to add a precedence edge from any CheckCastPP with a raw pointer input to the following safepoint, which prevents them being rearranged. I'm not very familiar with this code so I can't be sure this is the correct solution, but the same logic exists in GCM's PhaseCFG::schedule_late().

This pull request has now been integrated.

Changeset: ca9a0bcd
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ca9a0bcd9dbc9024fd632180adce00aa91c45637
Stats:     13 lines in 1 file changed: 13 ins; 0 del; 0 mod

8264340: [lworld] [AArch64] TestLWorld.java assertion failure in OopFlow::build_oop_map

Reviewed-by: thartmann

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

PR: https://git.openjdk.java.net/valhalla/pull/479


From thartmann at openjdk.java.net  Tue Aug  3 14:32:02 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 3 Aug 2021 14:32:02 GMT
Subject: [lworld] RFR: 8271234: [lworld] InlineTypeBaseNode::merge_with fails
 with assert(i < _cnt)
Message-ID: <3T1FZdsSkbK7yiXIhF_sfqCXZIvn5qf-fqxmlRWph5A=.46d85e46-f95d-422d-89c0-b4f2509fd800@github.com>

Transformation of phis in `InlineTypeBaseNode::merge_with` during IGVN can lead to other, not yet processed, phi nodes to be transformed as well, before their inputs are adjusted. In the failing case, a phi input is removed. The fix is to delay transformation of the phis during IGVN by adding them to the worklist.

Thanks,
Tobias

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

Commit messages:
 - Typo in comment
 - 8271234: [lworld] InlineTypeBaseNode::merge_with fails with assert(i < _cnt)

Changes: https://git.openjdk.java.net/valhalla/pull/517/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=517&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271234
  Stats: 27 lines in 3 files changed: 23 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/517.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/517/head:pull/517

PR: https://git.openjdk.java.net/valhalla/pull/517


From thartmann at openjdk.java.net  Tue Aug  3 15:13:45 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 3 Aug 2021 15:13:45 GMT
Subject: [lworld] Integrated: 8271234: [lworld] InlineTypeBaseNode::merge_with
 fails with assert(i < _cnt)
In-Reply-To: <3T1FZdsSkbK7yiXIhF_sfqCXZIvn5qf-fqxmlRWph5A=.46d85e46-f95d-422d-89c0-b4f2509fd800@github.com>
References: <3T1FZdsSkbK7yiXIhF_sfqCXZIvn5qf-fqxmlRWph5A=.46d85e46-f95d-422d-89c0-b4f2509fd800@github.com>
Message-ID: <YVuqH2TTLBHE9FuM_fqADPKTJ0I690Vwdk8QRBbqO_U=.e9251533-1ce5-4142-b6ff-54b5b1c030d0@github.com>

On Tue, 3 Aug 2021 14:25:46 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Transformation of phis in `InlineTypeBaseNode::merge_with` during IGVN can lead to other, not yet processed, phi nodes to be transformed as well, before their inputs are adjusted. In the failing case, a phi input is removed. The fix is to delay transformation of the phis during IGVN by adding them to the worklist.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 709cb06f
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/709cb06ff55eda70dd941e7f7f7d48c5900277fd
Stats:     27 lines in 3 files changed: 23 ins; 2 del; 2 mod

8271234: [lworld] InlineTypeBaseNode::merge_with fails with assert(i < _cnt)

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

PR: https://git.openjdk.java.net/valhalla/pull/517


From vromero at openjdk.java.net  Tue Aug  3 20:50:57 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 3 Aug 2021 20:50:57 GMT
Subject: RFR: Merge lworld
Message-ID: <U4tJbvG1hKhttukqsDewL0VeJJPy5PFelLk27RV_cts=.cccec8bc-d003-4281-9fcc-82174b11c907@github.com>

PR to merge lword into universal-tvars

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

Commit messages:
 - Merge branch 'lworld' into universal-tvars_merge_lworld
 - 8271234: [lworld] InlineTypeBaseNode::merge_with fails with assert(i < _cnt)
 - 8264340: [lworld] [AArch64] TestLWorld.java assertion failure in OopFlow::build_oop_map
 - 8271405: [lworld] Redo test/jdk/java/lang/invoke/VarHandles changes for JDK-8269956
 - 8271536: [lworld] VerifyError in hotspot/jtreg/runtime/classFileParserBug/NameAndTypeSig.java
 - 8271508: [lworld] disallow primitive classes with super_class of 0
 - 8271544: [lworld] GraphBuilder::withfield should handle identity class holder
 - Merge jdk
 - 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter
 - 8270901: Typo PHASE_CPP in CompilerPhaseType
 - ... and 594 more: https://git.openjdk.java.net/valhalla/compare/9458f792...2a6849eb

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/valhalla/pull/518/files
  Stats: 99726 lines in 1953 files changed: 49414 ins; 36739 del; 13573 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/518.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/518/head:pull/518

PR: https://git.openjdk.java.net/valhalla/pull/518


From vromero at openjdk.java.net  Wed Aug  4 00:53:46 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 4 Aug 2021 00:53:46 GMT
Subject: Withdrawn: Merge lworld
In-Reply-To: <U4tJbvG1hKhttukqsDewL0VeJJPy5PFelLk27RV_cts=.cccec8bc-d003-4281-9fcc-82174b11c907@github.com>
References: <U4tJbvG1hKhttukqsDewL0VeJJPy5PFelLk27RV_cts=.cccec8bc-d003-4281-9fcc-82174b11c907@github.com>
Message-ID: <7hB4quSx04_sUIVKXp14em6sJ3eeAvXDWgvzow1xaZw=.7f073903-937e-429b-9a69-4c7381f70217@github.com>

On Tue, 3 Aug 2021 20:45:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> PR to merge lword into universal-tvars

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/valhalla/pull/518


From vromero at openjdk.java.net  Wed Aug  4 01:20:45 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 4 Aug 2021 01:20:45 GMT
Subject: RFR: Merge lworld
Message-ID: <Tqjmse1-a-LZqG_tuPqx57m3Nn636kjdQQVqYkyVlC8=.e83cee75-ed56-4b7a-98b8-0398bd06da37@github.com>

Merge

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

Commit messages:
 - Merge lworld
 - 8271234: [lworld] InlineTypeBaseNode::merge_with fails with assert(i < _cnt)
 - 8264340: [lworld] [AArch64] TestLWorld.java assertion failure in OopFlow::build_oop_map
 - 8271405: [lworld] Redo test/jdk/java/lang/invoke/VarHandles changes for JDK-8269956
 - 8271536: [lworld] VerifyError in hotspot/jtreg/runtime/classFileParserBug/NameAndTypeSig.java
 - 8271508: [lworld] disallow primitive classes with super_class of 0
 - 8271544: [lworld] GraphBuilder::withfield should handle identity class holder
 - Merge jdk
 - 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter
 - 8270901: Typo PHASE_CPP in CompilerPhaseType
 - ... and 594 more: https://git.openjdk.java.net/valhalla/compare/9458f792...79489ac8

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/valhalla/pull/520/files
  Stats: 99726 lines in 1953 files changed: 49414 ins; 36739 del; 13573 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/520.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/520/head:pull/520

PR: https://git.openjdk.java.net/valhalla/pull/520


From vromero at openjdk.java.net  Wed Aug  4 01:27:19 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 4 Aug 2021 01:27:19 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <Tqjmse1-a-LZqG_tuPqx57m3Nn636kjdQQVqYkyVlC8=.e83cee75-ed56-4b7a-98b8-0398bd06da37@github.com>
References: <Tqjmse1-a-LZqG_tuPqx57m3Nn636kjdQQVqYkyVlC8=.e83cee75-ed56-4b7a-98b8-0398bd06da37@github.com>
Message-ID: <R4fC47D5ddwyczv878WzooQhHiu39ShOBcJptgLI7FA=.59074d85-27c6-4133-9bc7-6af8577bbd2b@github.com>

> Merging lworld into universal-tvars

Vicente Romero 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:

 - Merge lworld
 - Merge lworld
 - Merge lworld

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/520/files
  - new: https://git.openjdk.java.net/valhalla/pull/520/files/79489ac8..79489ac8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=520&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=520&range=00-01

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

PR: https://git.openjdk.java.net/valhalla/pull/520


From vromero at openjdk.java.net  Wed Aug  4 01:27:24 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 4 Aug 2021 01:27:24 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <Tqjmse1-a-LZqG_tuPqx57m3Nn636kjdQQVqYkyVlC8=.e83cee75-ed56-4b7a-98b8-0398bd06da37@github.com>
References: <Tqjmse1-a-LZqG_tuPqx57m3Nn636kjdQQVqYkyVlC8=.e83cee75-ed56-4b7a-98b8-0398bd06da37@github.com>
Message-ID: <51ZLU-LIQbvF0T-Yvj4EpVLz39nb0Cc6k0E3xgS0byo=.0f187a0e-eba2-4933-b7e5-96b287a2db16@github.com>

On Wed, 4 Aug 2021 01:14:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merging lworld into universal-tvars

This pull request has now been integrated.

Changeset: f1a651ea
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f1a651eaeb89d765eea71fb6b9c1713846e5c18d
Stats:     99726 lines in 1953 files changed: 49414 ins; 36739 del; 13573 mod

Merge lworld

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

PR: https://git.openjdk.java.net/valhalla/pull/520


From vromero at openjdk.java.net  Wed Aug  4 03:57:07 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 4 Aug 2021 03:57:07 GMT
Subject: RFR: universal type variables: initial prototype
Message-ID: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>

First iteration of the protype for universal type variables

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

Commit messages:
 - universal type variables: initial prototype

Changes: https://git.openjdk.java.net/valhalla/pull/521/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=521&range=00
  Stats: 854 lines in 24 files changed: 816 ins; 1 del; 37 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/521.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/521/head:pull/521

PR: https://git.openjdk.java.net/valhalla/pull/521


From ngasson at openjdk.java.net  Wed Aug  4 05:56:53 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 4 Aug 2021 05:56:53 GMT
Subject: [lworld] Integrated: 8271528: [lworld] [TESTBUG] Several C2 IR tests
 fail on AArch64
In-Reply-To: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
References: <tdGeMOL1yrCUzAoyRfgtnkMPt9HyrXDx_447cwo3ut4=.0764b712-d901-4f19-8164-4ffa22d62825@github.com>
Message-ID: <XN4L3nDk0LkoioUnB-T5_DZKddSdiWNmGkphBTwuSnI=.dedd6028-226b-4552-b52f-6c0da93a41c3@github.com>

On Mon, 2 Aug 2021 06:45:48 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The regexes just need to be adjusted slightly for the different opto assembly output.  Also removed an unnecessary extra black line after some loadConP instructions which caused match failures.
> 
> Test hotspot_valhalla on x86 and AArch64.

This pull request has now been integrated.

Changeset: e13315ab
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e13315abf6f7dc0f5172798762b9ea7eb203d8a2
Stats:     16 lines in 3 files changed: 3 ins; 0 del; 13 mod

8271528: [lworld] [TESTBUG] Several C2 IR tests fail on AArch64

Reviewed-by: chagedorn, thartmann

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

PR: https://git.openjdk.java.net/valhalla/pull/515


From thartmann at openjdk.java.net  Wed Aug  4 09:12:05 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 4 Aug 2021 09:12:05 GMT
Subject: [lworld] RFR: 8271710: [lworld] Unsafe compareAndSet/Exchange C2
 intrinsics should support inline types
Message-ID: <MANeyfuRji4YzVsxTIzI3T0mrcls2XkbN-7CD24Dv2c=.0c5c17c7-c9f8-4439-9671-b8af8f070fca@github.com>

The C2 intrinsics for `Unsafe::compareAndSetReference` and `Unsafe::compareAndExchangeReference` need to handle scalarized inline type arguments by buffering. 

Best regards,
Tobias

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

Commit messages:
 - 8271710: [lworld] Unsafe compareAndSet/Exchange C2 intrinsics should support inline types

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

PR: https://git.openjdk.java.net/valhalla/pull/522


From thartmann at openjdk.java.net  Wed Aug  4 10:34:54 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 4 Aug 2021 10:34:54 GMT
Subject: [lworld] Integrated: 8271710: [lworld] Unsafe compareAndSet/Exchange
 C2 intrinsics should support inline types
In-Reply-To: <MANeyfuRji4YzVsxTIzI3T0mrcls2XkbN-7CD24Dv2c=.0c5c17c7-c9f8-4439-9671-b8af8f070fca@github.com>
References: <MANeyfuRji4YzVsxTIzI3T0mrcls2XkbN-7CD24Dv2c=.0c5c17c7-c9f8-4439-9671-b8af8f070fca@github.com>
Message-ID: <6FV_bdIIBahm6Qk4xEqYB9cjeLJCIE0qGqkkrDJsHWw=.a0f7707e-71ac-4bc1-afe7-b4115b49439f@github.com>

On Wed, 4 Aug 2021 09:05:41 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The C2 intrinsics for `Unsafe::compareAndSetReference` and `Unsafe::compareAndExchangeReference` need to handle scalarized inline type arguments by buffering. 
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: dcfafdb4
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/dcfafdb4c88fdc8e55679a9ea86459be182c31e1
Stats:     232 lines in 2 files changed: 232 ins; 0 del; 0 mod

8271710: [lworld] Unsafe compareAndSet/Exchange C2 intrinsics should support inline types

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

PR: https://git.openjdk.java.net/valhalla/pull/522


From mcimadamore at openjdk.java.net  Wed Aug  4 10:49:51 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 Aug 2021 10:49:51 GMT
Subject: RFR: universal type variables: initial prototype
In-Reply-To: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
Message-ID: <7eXbqtnSzOFP9ekxuPjveV384Nfq6XxzuVUbKQi93qs=.1a1d8cf4-5120-4075-b846-2f3642b3a552@github.com>

On Wed, 4 Aug 2021 03:51:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> First iteration of the protype for universal type variables

Overall looks like a solid first attempt. I think we should spend some cycles making sure we get the TypeVar model right, and that we put info (e.g. universality) where it belongs (e.g. symbol), because that can affect how clients interact with these variables quite a lot.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 64:

> 62:     public enum Feature {
> 63:         SWITCH_PATTERN_MATCHING,
> 64:         UNIVERSAL_TVARS,

As Dan noted yesterday, for other Valhalla features we do not generally use preview mechanisms (this code needs to be pushed in the valhalla repo). We can postpone the preview dance for later. In fact, to ease experiments in JDK code it would be better to just make universal type variable syntax available by default.

There are some other places where this UNIVERSAL_TVARS constant is used which should be cleaned up for now (e.g. Preview.java).

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1946:

> 1944:         public Type lower;
> 1945: 
> 1946:         public boolean universal = false;

Can we use a flag on the tsym for this? After all, being "universal" is a declaration (symbol) not a use (type) property?

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 2058:

> 2056: 
> 2057:         @Override
> 2058:         public Type withTypeVar(Type t) {

Uhm - isn't this method used on wildcard types, and it all other types is supposed to just return `this` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 2091:

> 2089:             this.setUpperBound(upper);
> 2090:             this.wildcard = wildcard;
> 2091:             this.universal = upper.hasTag(TYPEVAR) && ((TypeVar)upper).universal ||

This probably requires tweaking - I see two issues:
* right now it detects cases where upper/lower are type variables themselves - but doesn't detect cases originating from e.g. `List<? extends Point>` - where you just have a captured variable whose bound is `Point`.
* the logic does not recurse - but maybe that's ok if `universal` is always set on creation

I think another approach could be to look at the wildcard type associated with the captured type. The wildcard type keeps track of the declared type variable it comes from, which means you can then look at the type symbol in there and decide if it's an universal variable or not. E.g.


captured.isUniversal() == captured.wildcard.bound.isUniversal()

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1089:

> 1087:             } else if (isSubtype(t, s, capture)) {
> 1088:                 return true;
> 1089:             } else if (allowUniversalTVars && t.hasTag(TYPEVAR) && s.hasTag(TYPEVAR) && t.tsym == s.tsym) {

Are you sure the check does what the comment says?

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3615:

> 3613:                     return to.head.withTypeVar(t);
> 3614:                 }
> 3615:                 if (allowUniversalTVars &&

Not sure about this - the main issue here seems that `t.equalsIgnoreMetadata` is too weak and would return `false` for `ref` vs.`val` mismatches. But again I'm uncertain about the need of overriding `withTypeVar` (see comment above).

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

> 823:     }
> 824: 
> 825:     List<Type> attribTypes(List<JCExpression> trees, Env<AttrContext> env, Predicate<JCExpression> valueOK) {

Do you really need a predicate here? Wouldn't a boolean be ok? Or perhaps a flag in env, or some other means?

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

> 5158: 
> 5159:         // Attribute type parameters
> 5160:         List<Type> actuals = !allowUniversalTVars ?

If you are doing this, you might be better off just attributing types one at a time inside the loop above, and avoid using a set to collect the ones which need special treatment?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 707:

> 705:          } else if (!a.hasTag(WILDCARD)) {
> 706:              a = types.cvarUpperBound(a);
> 707:              return types.isBoundedBy(a, bound, (t, s, w) -> types.isSubtype(t, s));

This is a good change - I'm a bit scared about the other calls in this routine, to `isCastable` and `notSoftSubtype`. These type relations are mostly doing things outside the spec, and we probably need to sprinkle `isBounded` in there as well.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 1056:

> 1054:             InferenceContext inferenceContext = deferredAttrContext.inferenceContext;
> 1055:             return strict ?
> 1056:                     types.isBoundedBy(inferenceContext.asUndetVar(found), inferenceContext.asUndetVar(req), warn,

I'm not 100% sure on this. I think step one should use just plain subtyping, while step 2 is allowed to use the more powerful relationship. My mental model is `int -> Object` which is only allowed on step 2 - so I think we want to do something similar for `Point -> Object` ? Of course `Point.ref -> Object` would be allowed on step 1.

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From vromero at openjdk.java.net  Wed Aug  4 15:49:46 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 4 Aug 2021 15:49:46 GMT
Subject: RFR: universal type variables: initial prototype
In-Reply-To: <7eXbqtnSzOFP9ekxuPjveV384Nfq6XxzuVUbKQi93qs=.1a1d8cf4-5120-4075-b846-2f3642b3a552@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <7eXbqtnSzOFP9ekxuPjveV384Nfq6XxzuVUbKQi93qs=.1a1d8cf4-5120-4075-b846-2f3642b3a552@github.com>
Message-ID: <nx6qGg3kp_0H8MBeXhvmQBbiBOvOGxZjEYo5Hqes0UY=.f51aae22-7540-47e7-be85-0f3b78e0b487@github.com>

On Wed, 4 Aug 2021 10:07:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> First iteration of the protype for universal type variables
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 64:
> 
>> 62:     public enum Feature {
>> 63:         SWITCH_PATTERN_MATCHING,
>> 64:         UNIVERSAL_TVARS,
> 
> As Dan noted yesterday, for other Valhalla features we do not generally use preview mechanisms (this code needs to be pushed in the valhalla repo). We can postpone the preview dance for later. In fact, to ease experiments in JDK code it would be better to just make universal type variable syntax available by default.
> 
> There are some other places where this UNIVERSAL_TVARS constant is used which should be cleaned up for now (e.g. Preview.java).

then I guess we will need to update the text in the JEP as the it is explicitly saying that this one is a preview feature

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1946:
> 
>> 1944:         public Type lower;
>> 1945: 
>> 1946:         public boolean universal = false;
> 
> Can we use a flag on the tsym for this? After all, being "universal" is a declaration (symbol) not a use (type) property?

well yes and no, if we have:

class C<__universal T> {
    T.ref t;
}

T and T.ref share the same symbol but they have different types that's why the universal field has been set to the type

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 825:
> 
>> 823:     }
>> 824: 
>> 825:     List<Type> attribTypes(List<JCExpression> trees, Env<AttrContext> env, Predicate<JCExpression> valueOK) {
> 
> Do you really need a predicate here? Wouldn't a boolean be ok? Or perhaps a flag in env, or some other means?

the thing is that one value only doesn't apply to all cases, what if some type variables are universal but others aren't?

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5160:
> 
>> 5158: 
>> 5159:         // Attribute type parameters
>> 5160:         List<Type> actuals = !allowUniversalTVars ?
> 
> If you are doing this, you might be better off just attributing types one at a time inside the loop above, and avoid using a set to collect the ones which need special treatment?

I will try that out

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 707:
> 
>> 705:          } else if (!a.hasTag(WILDCARD)) {
>> 706:              a = types.cvarUpperBound(a);
>> 707:              return types.isBoundedBy(a, bound, (t, s, w) -> types.isSubtype(t, s));
> 
> This is a good change - I'm a bit scared about the other calls in this routine, to `isCastable` and `notSoftSubtype`. These type relations are mostly doing things outside the spec, and we probably need to sprinkle `isBounded` in there as well.

ok

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From vromero at openjdk.java.net  Thu Aug  5 04:26:49 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 5 Aug 2021 04:26:49 GMT
Subject: RFR: universal type variables: initial prototype
In-Reply-To: <7eXbqtnSzOFP9ekxuPjveV384Nfq6XxzuVUbKQi93qs=.1a1d8cf4-5120-4075-b846-2f3642b3a552@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <7eXbqtnSzOFP9ekxuPjveV384Nfq6XxzuVUbKQi93qs=.1a1d8cf4-5120-4075-b846-2f3642b3a552@github.com>
Message-ID: <9kdEMZHhTbVwR62XzI2UcOGGqb1mXU5ZcMsnVb5tK34=.0a2a8e42-18d9-4a0c-944d-7bd7f8da917d@github.com>

On Wed, 4 Aug 2021 10:20:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> First iteration of the protype for universal type variables
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1089:
> 
>> 1087:             } else if (isSubtype(t, s, capture)) {
>> 1088:                 return true;
>> 1089:             } else if (allowUniversalTVars && t.hasTag(TYPEVAR) && s.hasTag(TYPEVAR) && t.tsym == s.tsym) {
> 
> Are you sure the check does what the comment says?

will remove the comment, probably a self comment I guess

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3615:
> 
>> 3613:                     return to.head.withTypeVar(t);
>> 3614:                 }
>> 3615:                 if (allowUniversalTVars &&
> 
> Not sure about this - the main issue here seems that `t.equalsIgnoreMetadata` is too weak and would return `false` for `ref` vs.`val` mismatches. But again I'm uncertain about the need of overriding `withTypeVar` (see comment above).

not sure I follow you here, `t.equalsIgnoreMetadata` is already being used in the method, not sure I see in what case it can give an incorrect answer

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From thartmann at openjdk.java.net  Thu Aug  5 07:42:56 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 5 Aug 2021 07:42:56 GMT
Subject: [lworld] RFR: 8271924: [lworld] Crashes in
 ZBarrierSetRuntime::load_barrier_on_oop_array
Message-ID: <mkh6lUqsDpxIVUrsgxAeHQ5fI_BEZUOZQbM0WeS5kis=.03c0dbca-0c97-436e-8d92-2159e40f5710@github.com>

- Cherry picking the fix for [JDK-8271925](https://bugs.openjdk.java.net/browse/JDK-8271925) (mainline issue) to give it some more testing in Valhalla and to get the CI clean (it currently only reproduces in Valhalla).
- Moved TestNativeClone.java to the ZGC problem list because no other GCs are affected. I'll remove it from the problem list once [JDK-8271925](https://bugs.openjdk.java.net/browse/JDK-8271925) got fixed in mainline.
- Fixed the missing merge of [JDK-8269828](https://bugs.openjdk.java.net/browse/JDK-8269828).
- Fixed an intermittent crash/assert in `ciKlass::is_subtype_of` because `this` is not loaded.

Best regards,
Tobias

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

Commit messages:
 - Fixed merge of JDK-8269828
 - 8271924: [lworld] Crashes in ZBarrierSetRuntime::load_barrier_on_oop_array

Changes: https://git.openjdk.java.net/valhalla/pull/523/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=523&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271924
  Stats: 24 lines in 6 files changed: 8 ins; 1 del; 15 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/523.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/523/head:pull/523

PR: https://git.openjdk.java.net/valhalla/pull/523


From dsimms at openjdk.java.net  Thu Aug  5 09:41:26 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 5 Aug 2021 09:41:26 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <1taVPmXtgopg8PdmIICbDEnGgrWiPZZprn8pgCbt5ZQ=.73248b3c-29b1-4f6b-b8a1-3a47d5f55d06@github.com>

Merge tag 'jdk-18+9'

# Conflicts:
#	src/hotspot/cpu/aarch64/aarch64.ad
#	src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp
#	src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.hpp
#	src/hotspot/share/opto/compile.cpp
#	src/java.base/share/classes/java/lang/Class.java
#	test/hotspot/jtreg/ProblemList.txt

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

Commit messages:
 - Merge tag 'jdk-18+9' into lworld_merge_jdk_18_9
 - 8265057: G1: Investigate removal of maintenance of two BOT thresholds
 - 8256844: Make NMT late-initializable
 - 6350025: API documentation for JOptionPane using deprecated methods.
 - 8270893: IndexOutOfBoundsException while reading large TIFF file
 - 8271836: runtime/ErrorHandling/ClassPathEnvVar.java fails with release VMs
 - 8264543: Cross modify fence optimization for x86
 - 8271824: mark hotspot runtime/CompressedOops tests which ignore external VM flags
 - 8271828: mark hotspot runtime/classFileParserBug tests which ignore external VM flags
 - 8271825: mark hotspot runtime/LoadClass tests which ignore external VM flags
 - ... and 70 more: https://git.openjdk.java.net/valhalla/compare/dcfafdb4...2d7d45f7

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

Changes: https://git.openjdk.java.net/valhalla/pull/524/files
  Stats: 36032 lines in 277 files changed: 33259 ins; 1620 del; 1153 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/524.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/524/head:pull/524

PR: https://git.openjdk.java.net/valhalla/pull/524


From thartmann at openjdk.java.net  Thu Aug  5 10:03:06 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 5 Aug 2021 10:03:06 GMT
Subject: [lworld] RFR: 8271924: [lworld] Crashes in
 ZBarrierSetRuntime::load_barrier_on_oop_array [v2]
In-Reply-To: <mkh6lUqsDpxIVUrsgxAeHQ5fI_BEZUOZQbM0WeS5kis=.03c0dbca-0c97-436e-8d92-2159e40f5710@github.com>
References: <mkh6lUqsDpxIVUrsgxAeHQ5fI_BEZUOZQbM0WeS5kis=.03c0dbca-0c97-436e-8d92-2159e40f5710@github.com>
Message-ID: <H-Nb0LoSnM6B0fV5KjVRK5Gc8IFF8khIVmYMlTQTXvw=.d695cd35-a223-43d0-b9ff-8d3bed91574a@github.com>

> - Cherry picking the fix for [JDK-8271925](https://bugs.openjdk.java.net/browse/JDK-8271925) (mainline issue) to give it some more testing in Valhalla and to get the CI clean (it currently only reproduces in Valhalla).
> - Moved TestNativeClone.java to the ZGC problem list because no other GCs are affected. I'll remove it from the problem list once [JDK-8271925](https://bugs.openjdk.java.net/browse/JDK-8271925) got fixed in mainline.
> - Fixed the missing merge of [JDK-8269828](https://bugs.openjdk.java.net/browse/JDK-8269828).
> - Fixed an intermittent crash/assert in `ciKlass::is_subtype_of` because `this` is not loaded.
> 
> Best regards,
> Tobias

Tobias Hartmann 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 JDK-8271924
 - Fixed merge of JDK-8269828
 - 8271924: [lworld] Crashes in ZBarrierSetRuntime::load_barrier_on_oop_array

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

Changes: https://git.openjdk.java.net/valhalla/pull/523/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=523&range=01
  Stats: 24 lines in 6 files changed: 8 ins; 1 del; 15 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/523.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/523/head:pull/523

PR: https://git.openjdk.java.net/valhalla/pull/523


From dsimms at openjdk.java.net  Thu Aug  5 10:08:24 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 5 Aug 2021 10:08:24 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <1taVPmXtgopg8PdmIICbDEnGgrWiPZZprn8pgCbt5ZQ=.73248b3c-29b1-4f6b-b8a1-3a47d5f55d06@github.com>
References: <1taVPmXtgopg8PdmIICbDEnGgrWiPZZprn8pgCbt5ZQ=.73248b3c-29b1-4f6b-b8a1-3a47d5f55d06@github.com>
Message-ID: <DFD-X3JfrLk82i3gp0sdE-4TdcWDhLNiGRr6RYxEgmk=.1326c103-72c6-4237-b87d-cb6730cdcf9a@github.com>

> Merge tag 'jdk-18+9'
> 
> # Conflicts:
> #	src/hotspot/cpu/aarch64/aarch64.ad
> #	src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp
> #	src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.hpp
> #	src/hotspot/share/opto/compile.cpp
> #	src/java.base/share/classes/java/lang/Class.java
> #	test/hotspot/jtreg/ProblemList.txt

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

 - Merge tag 'jdk-18+9' into lworld_merge_jdk_18_9
   
   Added tag jdk-18+9 for changeset 0a27f264
   
   # Conflicts:
   #	src/hotspot/cpu/aarch64/aarch64.ad
   #	src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp
   #	src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.hpp
   #	src/hotspot/share/opto/compile.cpp
   #	src/java.base/share/classes/java/lang/Class.java
   #	test/hotspot/jtreg/ProblemList.txt
 - 8271710: [lworld] Unsafe compareAndSet/Exchange C2 intrinsics should support inline types
 - 8271528: [lworld] [TESTBUG] Several C2 IR tests fail on AArch64
   
   Reviewed-by: chagedorn, thartmann
 - 8271234: [lworld] InlineTypeBaseNode::merge_with fails with assert(i < _cnt)
 - 8264340: [lworld] [AArch64] TestLWorld.java assertion failure in OopFlow::build_oop_map
   
   Reviewed-by: thartmann
 - 8271405: [lworld] Redo test/jdk/java/lang/invoke/VarHandles changes for JDK-8269956
 - 8271536: [lworld] VerifyError in hotspot/jtreg/runtime/classFileParserBug/NameAndTypeSig.java
   
   Reviewed-by: fparain
 - 8271508: [lworld] disallow primitive classes with super_class of 0
   
   Reviewed-by: dsimms
 - 8271544: [lworld] GraphBuilder::withfield should handle identity class holder
 - Merge jdk
   
   Merge tag 'jdk-18+8'
 - ... and 1221 more: https://git.openjdk.java.net/valhalla/compare/0a27f264...2d7d45f7

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

Changes: https://git.openjdk.java.net/valhalla/pull/524/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=524&range=01
  Stats: 153763 lines in 1493 files changed: 145646 ins; 1716 del; 6401 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/524.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/524/head:pull/524

PR: https://git.openjdk.java.net/valhalla/pull/524


From dsimms at openjdk.java.net  Thu Aug  5 10:08:27 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 5 Aug 2021 10:08:27 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <1taVPmXtgopg8PdmIICbDEnGgrWiPZZprn8pgCbt5ZQ=.73248b3c-29b1-4f6b-b8a1-3a47d5f55d06@github.com>
References: <1taVPmXtgopg8PdmIICbDEnGgrWiPZZprn8pgCbt5ZQ=.73248b3c-29b1-4f6b-b8a1-3a47d5f55d06@github.com>
Message-ID: <q3UiPRHVXEmUycheA4tfsTs5OOQO_Ip1Tux5TtnD4Ec=.5c9ca54a-10a5-4e27-82e7-ecf7e97b123c@github.com>

On Thu, 5 Aug 2021 09:33:50 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-18+9'
> 
> # Conflicts:
> #	src/hotspot/cpu/aarch64/aarch64.ad
> #	src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp
> #	src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.hpp
> #	src/hotspot/share/opto/compile.cpp
> #	src/java.base/share/classes/java/lang/Class.java
> #	test/hotspot/jtreg/ProblemList.txt

This pull request has now been integrated.

Changeset: bdaa4af0
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/bdaa4af02bccfd527bd19fbc3049685be4fdfc6d
Stats:     36032 lines in 277 files changed: 33259 ins; 1620 del; 1153 mod

Merge jdk

Merge tag 'jdk-18+9'

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

PR: https://git.openjdk.java.net/valhalla/pull/524


From thartmann at openjdk.java.net  Thu Aug  5 10:15:51 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 5 Aug 2021 10:15:51 GMT
Subject: [lworld] Integrated: 8271924: [lworld] Crashes in
 ZBarrierSetRuntime::load_barrier_on_oop_array
In-Reply-To: <mkh6lUqsDpxIVUrsgxAeHQ5fI_BEZUOZQbM0WeS5kis=.03c0dbca-0c97-436e-8d92-2159e40f5710@github.com>
References: <mkh6lUqsDpxIVUrsgxAeHQ5fI_BEZUOZQbM0WeS5kis=.03c0dbca-0c97-436e-8d92-2159e40f5710@github.com>
Message-ID: <0tUDRCw_8_hYIlKsz9Irp3R1FFLbMMHBIKfbPdzFGWw=.9878710a-03a4-4c49-97e7-3c1e330a2c18@github.com>

On Thu, 5 Aug 2021 07:37:05 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> - Cherry picking the fix for [JDK-8271925](https://bugs.openjdk.java.net/browse/JDK-8271925) (mainline issue) to give it some more testing in Valhalla and to get the CI clean (it currently only reproduces in Valhalla).
> - Moved TestNativeClone.java to the ZGC problem list because no other GCs are affected. I'll remove it from the problem list once [JDK-8271925](https://bugs.openjdk.java.net/browse/JDK-8271925) got fixed in mainline.
> - Fixed the missing merge of [JDK-8269828](https://bugs.openjdk.java.net/browse/JDK-8269828).
> - Fixed an intermittent crash/assert in `ciKlass::is_subtype_of` because `this` is not loaded.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 14723f91
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/14723f912ca0d9f6a27e7db8851061cb115359d0
Stats:     24 lines in 6 files changed: 8 ins; 1 del; 15 mod

8271924: [lworld] Crashes in ZBarrierSetRuntime::load_barrier_on_oop_array

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

PR: https://git.openjdk.java.net/valhalla/pull/523


From mcimadamore at openjdk.java.net  Thu Aug  5 13:12:46 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 Aug 2021 13:12:46 GMT
Subject: RFR: universal type variables: initial prototype
In-Reply-To: <nx6qGg3kp_0H8MBeXhvmQBbiBOvOGxZjEYo5Hqes0UY=.f51aae22-7540-47e7-be85-0f3b78e0b487@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <7eXbqtnSzOFP9ekxuPjveV384Nfq6XxzuVUbKQi93qs=.1a1d8cf4-5120-4075-b846-2f3642b3a552@github.com>
 <nx6qGg3kp_0H8MBeXhvmQBbiBOvOGxZjEYo5Hqes0UY=.f51aae22-7540-47e7-be85-0f3b78e0b487@github.com>
Message-ID: <nIYHFr0qtY_ZVn-2_XvkoCjxRU70ANkkN5Zk4FagcMc=.778008b6-1883-4613-8470-a48b28f647b1@github.com>

On Wed, 4 Aug 2021 15:29:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1946:
>> 
>>> 1944:         public Type lower;
>>> 1945: 
>>> 1946:         public boolean universal = false;
>> 
>> Can we use a flag on the tsym for this? After all, being "universal" is a declaration (symbol) not a use (type) property?
>
> well yes and no, if we have:
> 
> class C<__universal T> {
>     T.ref t;
> }
> 
> T and T.ref share the same symbol but they have different types that's why the universal field has been set to the type

yes, but `universal` is a property of the declaration, while `ref-ness` is a property of the use-site (hence type). Note that the underlying Valhalla compiler already has machinery to talk about reference projections, so perhaps we should use that to speak about `T` vs. `T.ref`, rather than inventing a new one. But we still need a flag somewhere to say whether the variable was declared as universal or not (as that affects what's compatible with that var).

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From mcimadamore at openjdk.java.net  Thu Aug  5 13:18:45 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 Aug 2021 13:18:45 GMT
Subject: RFR: universal type variables: initial prototype
In-Reply-To: <9kdEMZHhTbVwR62XzI2UcOGGqb1mXU5ZcMsnVb5tK34=.0a2a8e42-18d9-4a0c-944d-7bd7f8da917d@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <7eXbqtnSzOFP9ekxuPjveV384Nfq6XxzuVUbKQi93qs=.1a1d8cf4-5120-4075-b846-2f3642b3a552@github.com>
 <9kdEMZHhTbVwR62XzI2UcOGGqb1mXU5ZcMsnVb5tK34=.0a2a8e42-18d9-4a0c-944d-7bd7f8da917d@github.com>
Message-ID: <p53YQ_AHORI_ia1I9yBqm5l48V-XsloUVp447LIckGk=.f987eef5-5f77-4ae4-b97d-619fce697bc8@github.com>

On Thu, 5 Aug 2021 04:23:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3615:
>> 
>>> 3613:                     return to.head.withTypeVar(t);
>>> 3614:                 }
>>> 3615:                 if (allowUniversalTVars &&
>> 
>> Not sure about this - the main issue here seems that `t.equalsIgnoreMetadata` is too weak and would return `false` for `ref` vs.`val` mismatches. But again I'm uncertain about the need of overriding `withTypeVar` (see comment above).
>
> not sure I follow you here, `t.equalsIgnoreMetadata` is already being used in the method, not sure I see in what case it can give an incorrect answer

What I mean is that the newly added code seems to workaround the fact that in some cases we do not call `withTypeVar`. I'm saying that because you added another test which, if satisfied, ends up calling `to.head.withTypeVar(t);` again, which seems to suggest that you found cases where this call was needed, but was not triggered - probably because of a mismatch between T and T.ref?

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 825:
>> 
>>> 823:     }
>>> 824: 
>>> 825:     List<Type> attribTypes(List<JCExpression> trees, Env<AttrContext> env, Predicate<JCExpression> valueOK) {
>> 
>> Do you really need a predicate here? Wouldn't a boolean be ok? Or perhaps a flag in env, or some other means?
>
> the thing is that one value only doesn't apply to all cases, what if some type variables are universal but others aren't?

But you have only one predicate? Anyway - see the other related comment - you really need this predicate when you call this later on:


attribTypes(tree.arguments, env, arg -> valueOKSet.contains(arg));


But it feels like the code in there can be simplified so that you use a single `attribType` inside a loop, by passing the right boolean flag for that parameter.

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From vromero at openjdk.java.net  Fri Aug  6 02:08:44 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 6 Aug 2021 02:08:44 GMT
Subject: RFR: universal type variables: initial prototype
In-Reply-To: <p53YQ_AHORI_ia1I9yBqm5l48V-XsloUVp447LIckGk=.f987eef5-5f77-4ae4-b97d-619fce697bc8@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <7eXbqtnSzOFP9ekxuPjveV384Nfq6XxzuVUbKQi93qs=.1a1d8cf4-5120-4075-b846-2f3642b3a552@github.com>
 <9kdEMZHhTbVwR62XzI2UcOGGqb1mXU5ZcMsnVb5tK34=.0a2a8e42-18d9-4a0c-944d-7bd7f8da917d@github.com>
 <p53YQ_AHORI_ia1I9yBqm5l48V-XsloUVp447LIckGk=.f987eef5-5f77-4ae4-b97d-619fce697bc8@github.com>
Message-ID: <_Xv-u5aYLa0i4Jv7HOx1NVoVPfh2ssp6Bf8umzFCwZI=.21469c9a-f726-4499-b4d7-27d349b45bc5@github.com>

On Thu, 5 Aug 2021 13:15:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> the thing is that one value only doesn't apply to all cases, what if some type variables are universal but others aren't?
>
> But you have only one predicate? Anyway - see the other related comment - you really need this predicate when you call this later on:
> 
> 
> attribTypes(tree.arguments, env, arg -> valueOKSet.contains(arg));
> 
> 
> But it feels like the code in there can be simplified so that you use a single `attribType` inside a loop, by passing the right boolean flag for that parameter.

it wont be that simple, see that the method invoked, `Attr.attribTypes`, is doing:

    List<Type> types = attribAnyTypes(trees, env);
    return chk.checkRefTypes(trees, types, valueOK);


and Check.checkRefTypes is doing:

        List<JCExpression> tl = trees;
        for (List<Type> l = types; l.nonEmpty(); l = l.tail) {
            l.head = checkRefType(tl.head.pos(), l.head, valueOK.test(tl.head));
            tl = tl.tail;
        }
        return types;

and Check.checkRefType is the one using the flag, so in order to do all this at the level of `Attr.visitTypeApply` I will have to unfold all this code, popping up code that belongs in `Check`, and then the code in `Attr.visitTypeApply` will lose readability. This is why I opted for the current solution.

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From iklam at openjdk.java.net  Fri Aug  6 04:52:51 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 6 Aug 2021 04:52:51 GMT
Subject: [lworld] RFR: 8272041: [lworld] CDS heap dump fails with primitive
 objects
Message-ID: <P3zSTpmASmtr9i-RCzN4iYzde4xXdNjSi0MuK0aF5yg=.77eee039-3db2-458e-a992-7b4007bf8a94@github.com>

Two simple fixes to handle primitive objects when dumping the CDS heap:

- When dumping the objects, we enter them into a hashtable. Do not use `oopDesc::identity_hash()` as the hashcode for this table.
- When resetting the header of archived objects, do not call `oopDesc::identity_hash()` on primitive objects.

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

Commit messages:
 - 8272041: [lworld] -Xshare:dump fails when classlist contains primitive classes

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

PR: https://git.openjdk.java.net/valhalla/pull/525


From mcimadamore at openjdk.java.net  Fri Aug  6 10:42:49 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 Aug 2021 10:42:49 GMT
Subject: RFR: universal type variables: initial prototype
In-Reply-To: <_Xv-u5aYLa0i4Jv7HOx1NVoVPfh2ssp6Bf8umzFCwZI=.21469c9a-f726-4499-b4d7-27d349b45bc5@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <7eXbqtnSzOFP9ekxuPjveV384Nfq6XxzuVUbKQi93qs=.1a1d8cf4-5120-4075-b846-2f3642b3a552@github.com>
 <9kdEMZHhTbVwR62XzI2UcOGGqb1mXU5ZcMsnVb5tK34=.0a2a8e42-18d9-4a0c-944d-7bd7f8da917d@github.com>
 <p53YQ_AHORI_ia1I9yBqm5l48V-XsloUVp447LIckGk=.f987eef5-5f77-4ae4-b97d-619fce697bc8@github.com>
 <_Xv-u5aYLa0i4Jv7HOx1NVoVPfh2ssp6Bf8umzFCwZI=.21469c9a-f726-4499-b4d7-27d349b45bc5@github.com>
Message-ID: <pLl0s_wItEzOgumHjwQTPwUvCYxnVg9_E59KqpAB-fk=.376fcb1e-718c-4826-9dd9-fa56191fbeb8@github.com>

On Fri, 6 Aug 2021 02:02:47 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> But you have only one predicate? Anyway - see the other related comment - you really need this predicate when you call this later on:
>> 
>> 
>> attribTypes(tree.arguments, env, arg -> valueOKSet.contains(arg));
>> 
>> 
>> But it feels like the code in there can be simplified so that you use a single `attribType` inside a loop, by passing the right boolean flag for that parameter.
>
> it wont be that simple, see that the method invoked, `Attr.attribTypes`, is doing:
> 
>     List<Type> types = attribAnyTypes(trees, env);
>     return chk.checkRefTypes(trees, types, valueOK);
> 
> 
> and Check.checkRefTypes is doing:
> 
>         List<JCExpression> tl = trees;
>         for (List<Type> l = types; l.nonEmpty(); l = l.tail) {
>             l.head = checkRefType(tl.head.pos(), l.head, valueOK.test(tl.head));
>             tl = tl.tail;
>         }
>         return types;
> 
> and `Check.checkRefType` is the one using the flag, so in order to do all this at the level of `Attr.visitTypeApply` I will have to gather all the code, popping up code that belongs in `Check`, and then the code in `Attr.visitTypeApply` will lose readability. This is why I opted for the current solution.

I see what you mean - it seems like the current code is working against us here. In fact, attribAnyTypes specifically says that clients are expected to check for reference types after the fact...

Here's an idea... you could maybe call attribAnyTypes yourself, to attribute all the types, and then, in the loop you already have, only call checkRefTypes on the types you really need? (e.g. avoid attribTypes)

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From fparain at openjdk.java.net  Fri Aug  6 12:53:46 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 6 Aug 2021 12:53:46 GMT
Subject: [lworld] RFR: 8272041: [lworld] CDS heap dump fails with
 primitive objects
In-Reply-To: <P3zSTpmASmtr9i-RCzN4iYzde4xXdNjSi0MuK0aF5yg=.77eee039-3db2-458e-a992-7b4007bf8a94@github.com>
References: <P3zSTpmASmtr9i-RCzN4iYzde4xXdNjSi0MuK0aF5yg=.77eee039-3db2-458e-a992-7b4007bf8a94@github.com>
Message-ID: <mk4lxVNu0IYosJqNM2pat2-TZufkki8w0iDD3MtO3Xw=.39929fad-67d6-41ac-b172-aad80000e5d3@github.com>

On Fri, 6 Aug 2021 04:47:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Two simple fixes to handle primitive objects when dumping the CDS heap:
> 
> - When dumping the objects, we enter them into a hashtable. Do not use `oopDesc::identity_hash()` as the hashcode for this table.
> - When resetting the header of archived objects, do not call `oopDesc::identity_hash()` on primitive objects.

Looks good to me.

Just a question by curiosity, using object addresses instead of the identity hash code is likely to change the distribution of keys for the hashtable (all objects being in the same memory area and being aligned on heap words, some bits in their addresses are the same for all objects). Is it going to have a significant impact of the performance of the hashtable or is it negligeable?

Thank you,

Fred

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

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/525


From vromero at openjdk.java.net  Fri Aug  6 13:28:45 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 6 Aug 2021 13:28:45 GMT
Subject: RFR: universal type variables: initial prototype
In-Reply-To: <pLl0s_wItEzOgumHjwQTPwUvCYxnVg9_E59KqpAB-fk=.376fcb1e-718c-4826-9dd9-fa56191fbeb8@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <7eXbqtnSzOFP9ekxuPjveV384Nfq6XxzuVUbKQi93qs=.1a1d8cf4-5120-4075-b846-2f3642b3a552@github.com>
 <9kdEMZHhTbVwR62XzI2UcOGGqb1mXU5ZcMsnVb5tK34=.0a2a8e42-18d9-4a0c-944d-7bd7f8da917d@github.com>
 <p53YQ_AHORI_ia1I9yBqm5l48V-XsloUVp447LIckGk=.f987eef5-5f77-4ae4-b97d-619fce697bc8@github.com>
 <_Xv-u5aYLa0i4Jv7HOx1NVoVPfh2ssp6Bf8umzFCwZI=.21469c9a-f726-4499-b4d7-27d349b45bc5@github.com>
 <pLl0s_wItEzOgumHjwQTPwUvCYxnVg9_E59KqpAB-fk=.376fcb1e-718c-4826-9dd9-fa56191fbeb8@github.com>
Message-ID: <sdFnSCMHR2HusQ8gABnSxksx0GF_td71LGeWDMwgnO0=.6c6a9bb2-a553-4d1a-a145-b13c0f0f759b@github.com>

On Fri, 6 Aug 2021 10:39:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> it wont be that simple, see that the method invoked, `Attr.attribTypes`, is doing:
>> 
>>     List<Type> types = attribAnyTypes(trees, env);
>>     return chk.checkRefTypes(trees, types, valueOK);
>> 
>> 
>> and Check.checkRefTypes is doing:
>> 
>>         List<JCExpression> tl = trees;
>>         for (List<Type> l = types; l.nonEmpty(); l = l.tail) {
>>             l.head = checkRefType(tl.head.pos(), l.head, valueOK.test(tl.head));
>>             tl = tl.tail;
>>         }
>>         return types;
>> 
>> and `Check.checkRefType` is the one using the flag, so in order to do all this at the level of `Attr.visitTypeApply` I will have to gather all the code, popping up code that belongs in `Check`, and then the code in `Attr.visitTypeApply` will lose readability. This is why I opted for the current solution.
>
> I see what you mean - it seems like the current code is working against us here. In fact, attribAnyTypes specifically says that clients are expected to check for reference types after the fact...
> 
> Here's an idea... you could maybe call attribAnyTypes yourself, to attribute all the types, and then, in the loop you already have, only call checkRefTypes on the types you really need? (e.g. avoid attribTypes)

OK

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From mchung at openjdk.java.net  Fri Aug  6 17:09:46 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 6 Aug 2021 17:09:46 GMT
Subject: [lworld] RFR: 8272041: [lworld] CDS heap dump fails with
 primitive objects
In-Reply-To: <P3zSTpmASmtr9i-RCzN4iYzde4xXdNjSi0MuK0aF5yg=.77eee039-3db2-458e-a992-7b4007bf8a94@github.com>
References: <P3zSTpmASmtr9i-RCzN4iYzde4xXdNjSi0MuK0aF5yg=.77eee039-3db2-458e-a992-7b4007bf8a94@github.com>
Message-ID: <lusyaL_SNpiVBcpDRY2HzVcS50BN-Z1N9HBEYXcaMIs=.7bb27fdc-509d-4302-898f-7b2231484261@github.com>

On Fri, 6 Aug 2021 04:47:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Two simple fixes to handle primitive objects when dumping the CDS heap:
> 
> - When dumping the objects, we enter them into a hashtable. Do not use `oopDesc::identity_hash()` as the hashcode for this table.
> - When resetting the header of archived objects, do not call `oopDesc::identity_hash()` on primitive objects.

Looks good.  I verified with the patch that converts some JDK classes to ref-default primitive class.

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

Marked as reviewed by mchung (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/525


From iklam at openjdk.java.net  Fri Aug  6 20:15:59 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 6 Aug 2021 20:15:59 GMT
Subject: [lworld] RFR: 8272041: [lworld] CDS heap dump fails with
 primitive objects
In-Reply-To: <mk4lxVNu0IYosJqNM2pat2-TZufkki8w0iDD3MtO3Xw=.39929fad-67d6-41ac-b172-aad80000e5d3@github.com>
References: <P3zSTpmASmtr9i-RCzN4iYzde4xXdNjSi0MuK0aF5yg=.77eee039-3db2-458e-a992-7b4007bf8a94@github.com>
 <mk4lxVNu0IYosJqNM2pat2-TZufkki8w0iDD3MtO3Xw=.39929fad-67d6-41ac-b172-aad80000e5d3@github.com>
Message-ID: <9nPSFuFhy_Q-jZAbSNRHd1h7Srk2QXJaHr3T-zLCXMk=.4726e853-b38d-49ba-b3b2-91f7ab59b434@github.com>

On Fri, 6 Aug 2021 12:51:08 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Looks good to me.
> 
> Just a question by curiosity, using object addresses instead of the identity hash code is likely to change the distribution of keys for the hashtable (all objects being in the same memory area and being aligned on heap words, some bits in their addresses are the same for all objects). Is it going to have a significant impact of the performance of the hashtable or is it negligeable?

Hi Fred,

Thanks for the review. I've added code to calculate the stats of the hashtable. The max number of entries per bucket is no more than 3, so I think the distribution is acceptable.

Also, the hash function already shifts down by `LogBytesPerWord`, so it will get rid of the lower 3 zero bits.

My stats code is in https://github.com/iklam/valhalla/commits/heap-shared-seen-obj-table-stats, but it's not part of this PR. I will clean it up and integrate into jdk/jdk.

Thanks @fparain and @mlchung for the review.

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

PR: https://git.openjdk.java.net/valhalla/pull/525


From iklam at openjdk.java.net  Fri Aug  6 20:15:59 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 6 Aug 2021 20:15:59 GMT
Subject: [lworld] Integrated: 8272041: [lworld] CDS heap dump fails with
 primitive objects
In-Reply-To: <P3zSTpmASmtr9i-RCzN4iYzde4xXdNjSi0MuK0aF5yg=.77eee039-3db2-458e-a992-7b4007bf8a94@github.com>
References: <P3zSTpmASmtr9i-RCzN4iYzde4xXdNjSi0MuK0aF5yg=.77eee039-3db2-458e-a992-7b4007bf8a94@github.com>
Message-ID: <ArD1drY9YK7e1wv3cf-kLscfS8MRnhiXMpZqkv8TLXs=.96e6c08d-0028-4e7c-a98b-29a1cf974647@github.com>

On Fri, 6 Aug 2021 04:47:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Two simple fixes to handle primitive objects when dumping the CDS heap:
> 
> - When dumping the objects, we enter them into a hashtable. Do not use `oopDesc::identity_hash()` as the hashcode for this table.
> - When resetting the header of archived objects, do not call `oopDesc::identity_hash()` on primitive objects.

This pull request has now been integrated.

Changeset: a8994ba4
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a8994ba4ef126ce92311b340b82a112d276decb3
Stats:     12 lines in 1 file changed: 3 ins; 0 del; 9 mod

8272041: [lworld] CDS heap dump fails with primitive objects

Reviewed-by: fparain, mchung

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

PR: https://git.openjdk.java.net/valhalla/pull/525


From fparain at openjdk.java.net  Fri Aug  6 20:24:58 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 6 Aug 2021 20:24:58 GMT
Subject: [lworld] RFR: 8272041: [lworld] CDS heap dump fails with
 primitive objects
In-Reply-To: <P3zSTpmASmtr9i-RCzN4iYzde4xXdNjSi0MuK0aF5yg=.77eee039-3db2-458e-a992-7b4007bf8a94@github.com>
References: <P3zSTpmASmtr9i-RCzN4iYzde4xXdNjSi0MuK0aF5yg=.77eee039-3db2-458e-a992-7b4007bf8a94@github.com>
Message-ID: <orBLWg_xFmZWoWtE2SLJWqQOhX2C3rEHJSMOfQ_GeQA=.3bb0c69d-def2-4bb5-a42d-8b5eb0ecd1fb@github.com>

On Fri, 6 Aug 2021 04:47:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Two simple fixes to handle primitive objects when dumping the CDS heap:
> 
> - When dumping the objects, we enter them into a hashtable. Do not use `oopDesc::identity_hash()` as the hashcode for this table.
> - When resetting the header of archived objects, do not call `oopDesc::identity_hash()` on primitive objects.

Ioi,

Thank you for the additional effort to measure statistics of the hashtable.

Fred

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

PR: https://git.openjdk.java.net/valhalla/pull/525


From vromero at openjdk.java.net  Mon Aug  9 19:53:34 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 9 Aug 2021 19:53:34 GMT
Subject: RFR: universal type variables: initial prototype [v2]
In-Reply-To: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
Message-ID: <5gkpiodxomS2YP4md-YnhBu25HyfkK9xp-3maRvueXM=.1e55d75c-e5bd-4a18-ab06-ebed88d0497c@github.com>

> First iteration of the protype for universal type variables

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/521/files
  - new: https://git.openjdk.java.net/valhalla/pull/521/files/e28bdb6a..39e77759

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=521&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=521&range=00-01

  Stats: 195 lines in 17 files changed: 19 ins; 109 del; 67 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/521.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/521/head:pull/521

PR: https://git.openjdk.java.net/valhalla/pull/521


From vromero at openjdk.java.net  Tue Aug 10 16:25:38 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 10 Aug 2021 16:25:38 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <U4tJbvG1hKhttukqsDewL0VeJJPy5PFelLk27RV_cts=.cccec8bc-d003-4281-9fcc-82174b11c907@github.com>
References: <U4tJbvG1hKhttukqsDewL0VeJJPy5PFelLk27RV_cts=.cccec8bc-d003-4281-9fcc-82174b11c907@github.com>
Message-ID: <LR7vNSgQhbF2Yu-ewD17y-Eht08R8H88Rb1m-JXQcsE=.2bcc9821-9fe0-4211-bf5c-fab6c725ff90@github.com>

> PR to merge lword into universal-tvars

Vicente Romero 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:

 - Merge branch 'lworld' into universal-tvars_merge_lworld
 - Merge lworld
 - Merge lworld

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/518/files
  - new: https://git.openjdk.java.net/valhalla/pull/518/files/2a6849eb..2a6849eb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=518&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=518&range=00-01

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

PR: https://git.openjdk.java.net/valhalla/pull/518


From vromero at openjdk.java.net  Tue Aug 10 19:10:14 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 10 Aug 2021 19:10:14 GMT
Subject: RFR: universal type variables: initial prototype [v3]
In-Reply-To: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
Message-ID: <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>

> First iteration of the protype for universal type variables

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

  second iteration of review comments

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/521/files
  - new: https://git.openjdk.java.net/valhalla/pull/521/files/39e77759..3b300830

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=521&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=521&range=01-02

  Stats: 56 lines in 6 files changed: 14 ins; 11 del; 31 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/521.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/521/head:pull/521

PR: https://git.openjdk.java.net/valhalla/pull/521


From mcimadamore at openjdk.java.net  Tue Aug 10 21:27:40 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 10 Aug 2021 21:27:40 GMT
Subject: RFR: universal type variables: initial prototype [v3]
In-Reply-To: <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>
Message-ID: <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>

On Tue, 10 Aug 2021 19:10:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> First iteration of the protype for universal type variables
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   second iteration of review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1186:

> 1184:                      return isSubtypeNoCapture(t.getUpperBound(), s);
> 1185:                  case BOT:
> 1186:                      if (allowUniversalTVars && s.hasTag(TYPEVAR) && ((TypeVar)s).isValueProjection()) {

I agree that here you need `isValueProjection`

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3614:

> 3612:                 }
> 3613:                 if (allowUniversalTVars &&
> 3614:                         !t.isValueProjection() &&

Not sure about this here - "not value projection might also mean it's a regular tvar". Doesn't this test want to check for `T.ref` (in which case you should check for `isReferenceProjection`

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3616:

> 3614:                         !t.isValueProjection() &&
> 3615:                         from.head.hasTag(TYPEVAR) &&
> 3616:                         ((TypeVar)from.head).projection != null &&

Shouldn't this test be `isUniversal()` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3617:

> 3615:                         from.head.hasTag(TYPEVAR) &&
> 3616:                         ((TypeVar)from.head).projection != null &&
> 3617:                         t.equalsIgnoreMetadata(((TypeVar)from.head).projection)) {

and here, we should call `referencceProjection()` ?

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

> 2661:                         && ((JCFieldAccess)tree.meth).selected.hasTag(IDENT)
> 2662:                         && TreeInfo.name(((JCFieldAccess)tree.meth).selected) == names._super;
> 2663:                 boolean qualifierIsUniversal = allowUniversalTVars && qualifier.hasTag(TYPEVAR) && ((TypeVar)qualifier).isValueProjection();

This should be `isUniversal()` I think - `wait` and friends should warn, even on `.ref` stuff.

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

> 4598:                 throw new AssertionError(tree);
> 4599:             case TYPEVAR:
> 4600:                 if (allowUniversalTVars && name == names.ref && ((TypeVar)site).isValueProjection()) {

This should be `isUniversal()` ?

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

> 5147:             argTypes2 = argTypes = attribAnyTypes(args, env);
> 5148:             for (Type t : ((ClassType) clazztype.tsym.type).typarams_field) {
> 5149:                 argTypes.head = chk.checkRefType(args.head.pos(), argTypes.head, ((TypeVar) t).isValueProjection());

this should be `isUniversal()`, no?

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From mcimadamore at openjdk.java.net  Tue Aug 10 21:31:43 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 10 Aug 2021 21:31:43 GMT
Subject: RFR: universal type variables: initial prototype [v3]
In-Reply-To: <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>
Message-ID: <F8v1gaaVcN0LbsZw9KlbWb8SN5kvBEjMF8c-bPSz0zE=.123de1b9-d836-4e0a-bf42-cb8d49fe21aa@github.com>

On Tue, 10 Aug 2021 19:10:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> First iteration of the protype for universal type variables
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   second iteration of review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1962:

> 1960:         }
> 1961: 
> 1962:         public TypeVar(Name name, Symbol owner, Type lower, boolean isUniversal, boolean isReferenceProjection) {

This constructor probably should not take the `isReferenceProjection` as this one creates a new tsym and you want the reference projection to share the same symbol - so you probably are always passing `false` here.

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From iklam at openjdk.java.net  Tue Aug 10 23:56:47 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 10 Aug 2021 23:56:47 GMT
Subject: [lworld] RFR: 8272290: [lworld] Disable CDS if
 InlineTypePassFieldsAsArgs has changed
Message-ID: <bMRRR47iWL7mGY4likTuYCC9AnAjbkjP0B3H5O7u6zU=.f49e5013-1292-4eb9-86bb-720218f714c4@github.com>

If any of the following VM options have different values between CDS dump time and runtime, we cannot load the CDS archive:

- `FlatArrayElementMaxOops`
- `FlatArrayElementMaxSize`
- `InlineFieldMaxFlatSize`
- `InlineTypePassFieldsAsArgs`
- `InlineTypeReturnedAsFields`

Testing with mach5 tiers 1-2

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

Commit messages:
 - fixed whitespaces
 - 8272290: [lworld] Disable CDS if InlineTypePassFieldsAsArgs has changed

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

PR: https://git.openjdk.java.net/valhalla/pull/526


From vromero at openjdk.java.net  Wed Aug 11 04:20:36 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 11 Aug 2021 04:20:36 GMT
Subject: RFR: universal type variables: initial prototype [v3]
In-Reply-To: <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>
 <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
Message-ID: <Ta4w3YkoYjWfSs9lJtkBn93sEwtXtW1QY4hceOkREQ0=.57539d72-43d3-4544-a023-6e67104b0a24@github.com>

On Tue, 10 Aug 2021 21:12:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   second iteration of review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5149:
> 
>> 5147:             argTypes2 = argTypes = attribAnyTypes(args, env);
>> 5148:             for (Type t : ((ClassType) clazztype.tsym.type).typarams_field) {
>> 5149:                 argTypes.head = chk.checkRefType(args.head.pos(), argTypes.head, ((TypeVar) t).isValueProjection());
> 
> this should be `isUniversal()`, no?

yep will change it

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From vromero at openjdk.java.net  Wed Aug 11 04:29:41 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 11 Aug 2021 04:29:41 GMT
Subject: RFR: universal type variables: initial prototype [v3]
In-Reply-To: <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>
 <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
Message-ID: <0lv0V6A3-o23R6DtMIDCa00p9ngA9B7SyAc8Ypf7e44=.f449763f-3cf6-4180-8b3a-cb767903171e@github.com>

On Tue, 10 Aug 2021 21:13:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   second iteration of review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4600:
> 
>> 4598:                 throw new AssertionError(tree);
>> 4599:             case TYPEVAR:
>> 4600:                 if (allowUniversalTVars && name == names.ref && ((TypeVar)site).isValueProjection()) {
> 
> This should be `isUniversal()` ?

yep u are right

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From iklam at openjdk.java.net  Wed Aug 11 04:38:00 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 Aug 2021 04:38:00 GMT
Subject: [lworld] RFR: 8272290: [lworld] Disable CDS if
 InlineTypePassFieldsAsArgs has changed [v2]
In-Reply-To: <bMRRR47iWL7mGY4likTuYCC9AnAjbkjP0B3H5O7u6zU=.f49e5013-1292-4eb9-86bb-720218f714c4@github.com>
References: <bMRRR47iWL7mGY4likTuYCC9AnAjbkjP0B3H5O7u6zU=.f49e5013-1292-4eb9-86bb-720218f714c4@github.com>
Message-ID: <mnKZ137ez6hRGHZDxBG48ZEuE6ZS9gkqeJiOjEAL4j0=.3e6f53aa-adac-4308-9253-03e512cf03a3@github.com>

> If any of the following VM options have different values between CDS dump time and runtime, we cannot load the CDS archive:
> 
> - `FlatArrayElementMaxOops`
> - `FlatArrayElementMaxSize`
> - `InlineFieldMaxFlatSize`
> - `InlineTypePassFieldsAsArgs`
> - `InlineTypeReturnedAsFields`
> 
> Testing with mach5 tiers 1-2

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  fixed test failures; improved error message

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/526/files
  - new: https://git.openjdk.java.net/valhalla/pull/526/files/72490207..69d8e5df

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=526&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=526&range=00-01

  Stats: 13 lines in 3 files changed: 9 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/526.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/526/head:pull/526

PR: https://git.openjdk.java.net/valhalla/pull/526


From vromero at openjdk.java.net  Wed Aug 11 04:48:36 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 11 Aug 2021 04:48:36 GMT
Subject: RFR: universal type variables: initial prototype [v3]
In-Reply-To: <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>
 <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
Message-ID: <d6oEimA6zEPJ-iWdrPXJnZcXL0rIDEQh2JsQTbIv5xc=.955720ee-1c39-4480-8501-f84f76c6c0a4@github.com>

On Tue, 10 Aug 2021 21:16:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   second iteration of review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 2663:
> 
>> 2661:                         && ((JCFieldAccess)tree.meth).selected.hasTag(IDENT)
>> 2662:                         && TreeInfo.name(((JCFieldAccess)tree.meth).selected) == names._super;
>> 2663:                 boolean qualifierIsUniversal = allowUniversalTVars && qualifier.hasTag(TYPEVAR) && ((TypeVar)qualifier).isValueProjection();
> 
> This should be `isUniversal()` I think - `wait` and friends should warn, even on `.ref` stuff.

not sure to be honest, although there is no reference in the JEP to these warnings so we can do either now

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From vromero at openjdk.java.net  Wed Aug 11 05:08:42 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 11 Aug 2021 05:08:42 GMT
Subject: RFR: universal type variables: initial prototype [v3]
In-Reply-To: <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>
 <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
Message-ID: <6xhQ1cjaQ5toNOhhHUjxlR7ZXcMXsGhWNahZ_nUWGKU=.b24e735d-84df-4532-a861-eca1cddb1999@github.com>

On Tue, 10 Aug 2021 21:22:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   second iteration of review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3617:
> 
>> 3615:                         from.head.hasTag(TYPEVAR) &&
>> 3616:                         ((TypeVar)from.head).projection != null &&
>> 3617:                         t.equalsIgnoreMetadata(((TypeVar)from.head).projection)) {
> 
> and here, we should call `referencceProjection()` ?

yep I agree

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From vromero at openjdk.java.net  Wed Aug 11 05:13:40 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 11 Aug 2021 05:13:40 GMT
Subject: RFR: universal type variables: initial prototype [v3]
In-Reply-To: <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>
 <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
Message-ID: <13fmuspUT3BbVfvxS9tW96jvkb49P3IQ-i2xyGW61MU=.35d10ef3-a4e1-4980-ace7-9f5827267a74@github.com>

On Tue, 10 Aug 2021 21:22:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   second iteration of review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3616:
> 
>> 3614:                         !t.isValueProjection() &&
>> 3615:                         from.head.hasTag(TYPEVAR) &&
>> 3616:                         ((TypeVar)from.head).projection != null &&
> 
> Shouldn't this test be `isUniversal()` ?

doing this change right now breaks the build, I think it is because we generate reference projections for universal type vars in a lazy way, so some universal type variables could have its projection field set to null

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From mcimadamore at openjdk.java.net  Wed Aug 11 15:01:53 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 11 Aug 2021 15:01:53 GMT
Subject: RFR: universal type variables: initial prototype [v3]
In-Reply-To: <13fmuspUT3BbVfvxS9tW96jvkb49P3IQ-i2xyGW61MU=.35d10ef3-a4e1-4980-ace7-9f5827267a74@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>
 <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
 <13fmuspUT3BbVfvxS9tW96jvkb49P3IQ-i2xyGW61MU=.35d10ef3-a4e1-4980-ace7-9f5827267a74@github.com>
Message-ID: <dNjaT73aZ7bV0VOGjShteLPy766GWzQSRW8h78vzOZk=.d27e8819-0cbe-4c92-9690-21ac0e70820d@github.com>

On Wed, 11 Aug 2021 05:10:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3616:
>> 
>>> 3614:                         !t.isValueProjection() &&
>>> 3615:                         from.head.hasTag(TYPEVAR) &&
>>> 3616:                         ((TypeVar)from.head).projection != null &&
>> 
>> Shouldn't this test be `isUniversal()` ?
>
> doing this change right now breaks the build, I think it is because we generate reference projections for universal type vars in a lazy way, so some universal type variables could have its projection field set to null

ugh - I understand - moving forward it'd be nice not to depend on tricky init semantics.

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 2663:
>> 
>>> 2661:                         && ((JCFieldAccess)tree.meth).selected.hasTag(IDENT)
>>> 2662:                         && TreeInfo.name(((JCFieldAccess)tree.meth).selected) == names._super;
>>> 2663:                 boolean qualifierIsUniversal = allowUniversalTVars && qualifier.hasTag(TYPEVAR) && ((TypeVar)qualifier).isValueProjection();
>> 
>> This should be `isUniversal()` I think - `wait` and friends should warn, even on `.ref` stuff.
>
> not sure to be honest, although there is no reference in the JEP to these warnings so we can do either now

I double checked with Brian yesterday - he confirmed that both `T` and `T.ref` should not support identity operation (well, given warning when attempting to).

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From vromero at openjdk.java.net  Wed Aug 11 16:26:38 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 11 Aug 2021 16:26:38 GMT
Subject: RFR: universal type variables: initial prototype [v3]
In-Reply-To: <dNjaT73aZ7bV0VOGjShteLPy766GWzQSRW8h78vzOZk=.d27e8819-0cbe-4c92-9690-21ac0e70820d@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>
 <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
 <13fmuspUT3BbVfvxS9tW96jvkb49P3IQ-i2xyGW61MU=.35d10ef3-a4e1-4980-ace7-9f5827267a74@github.com>
 <dNjaT73aZ7bV0VOGjShteLPy766GWzQSRW8h78vzOZk=.d27e8819-0cbe-4c92-9690-21ac0e70820d@github.com>
Message-ID: <EXSsdzoDM8PRU0NMQOpPfgu4USy5xYPA9ER_OrGaDs0=.e0d22250-6853-404a-8269-cd53e092a713@github.com>

On Wed, 11 Aug 2021 14:58:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> doing this change right now breaks the build, I think it is because we generate reference projections for universal type vars in a lazy way, so some universal type variables could have its projection field set to null
>
> ugh - I understand - moving forward it'd be nice not to depend on tricky init semantics.

yep, will fix this

>> not sure to be honest, although there is no reference in the JEP to these warnings so we can do either now
>
> I double checked with Brian yesterday - he confirmed that both `T` and `T.ref` should not support identity operation (well, given warning when attempting to).

ok, thanks for double checking, will fix this

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From forax at openjdk.java.net  Wed Aug 11 17:39:52 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 11 Aug 2021 17:39:52 GMT
Subject: RFR: universal type variables: initial prototype [v3]
In-Reply-To: <EXSsdzoDM8PRU0NMQOpPfgu4USy5xYPA9ER_OrGaDs0=.e0d22250-6853-404a-8269-cd53e092a713@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <lqMD_T4j_zlKL1nZRDdL_U_lfng3F7qR5bkAtvrgn7Q=.d2efd635-ab13-4e52-b83c-4fe846e68513@github.com>
 <hrm0AvocrxTUJpE3CLwz8vgZptOxV2ts3muAPga-400=.d49c7838-83ef-4b78-b38f-ddb6aa5a7b59@github.com>
 <13fmuspUT3BbVfvxS9tW96jvkb49P3IQ-i2xyGW61MU=.35d10ef3-a4e1-4980-ace7-9f5827267a74@github.com>
 <dNjaT73aZ7bV0VOGjShteLPy766GWzQSRW8h78vzOZk=.d27e8819-0cbe-4c92-9690-21ac0e70820d@github.com>
 <EXSsdzoDM8PRU0NMQOpPfgu4USy5xYPA9ER_OrGaDs0=.e0d22250-6853-404a-8269-cd53e092a713@github.com>
Message-ID: <KIcIk2bbDIpE2XRdBpnOcoaCK--Blv3kDmk-JEnfKMQ=.9e791c26-b6c4-4369-8383-ce7a4dcf0668@github.com>

On Wed, 11 Aug 2021 16:23:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> I double checked with Brian yesterday - he confirmed that both `T` and `T.ref` should not support identity operation (well, given warning when attempting to).
>
> ok, thanks for double checking, will fix this

T.ref still support == null, but it's a corner case

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From ngasson at openjdk.java.net  Thu Aug 12 09:11:03 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 12 Aug 2021 09:11:03 GMT
Subject: [lworld] RFR: 8272307: [lworld] [AArch64] TestCallingConventionC1
 test63 and test64 get incorrect result
Message-ID: <kZyjA3xvWfZMxycrUlNzFROCr9_kjrXe0URI_tipnb8=.1396923f-0922-4cf4-8cf6-166649efcfae@github.com>

These two were hidden by the earlier IR test failures.  The errors look like:


  Caused by: java.lang.RuntimeException: assertEquals: expected -1163019586 to equal 777
  at jdk.test.lib.Asserts.fail(Asserts.java:594)
  at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
  at jdk.test.lib.Asserts.assertEquals(Asserts.java:189)
  at jdk.test.lib.Asserts.assertEQ(Asserts.java:166)
  at compiler.valhalla.inlinetypes.TestCallingConventionC1.test64_verifier(TestCallingConventionC1.java:1518)
  ... 9 more


In the C1 scalarised entry point we call a runtime stub to allocate objects for buffering the incoming inline types.  The runtime stub returns its result in r0 which is also j_rarg7 and might be holding a live argument value.  To work around this we temporarily move j_rarg7 into r21 which is known to be free at this point and then move it back after the call.  However if a GC occurs during the runtime call and an object held in j_rarg7 is moved, r21 will still be pointing at the old from-space copy after the call returns because it's not recorded in the oop map.  Fix that by having the stub return the object array in r20 and leave r0-r7 untouched.

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

Commit messages:
 - 8272307: [lworld] [AArch64] TestCallingConventionC1 test63 and test64 get incorrect result

Changes: https://git.openjdk.java.net/valhalla/pull/527/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=527&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272307
  Stats: 20 lines in 2 files changed: 7 ins; 8 del; 5 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/527.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/527/head:pull/527

PR: https://git.openjdk.java.net/valhalla/pull/527


From thartmann at openjdk.java.net  Thu Aug 12 12:39:48 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 12 Aug 2021 12:39:48 GMT
Subject: [lworld] RFR: 8272307: [lworld] [AArch64] TestCallingConventionC1
 test63 and test64 get incorrect result
In-Reply-To: <kZyjA3xvWfZMxycrUlNzFROCr9_kjrXe0URI_tipnb8=.1396923f-0922-4cf4-8cf6-166649efcfae@github.com>
References: <kZyjA3xvWfZMxycrUlNzFROCr9_kjrXe0URI_tipnb8=.1396923f-0922-4cf4-8cf6-166649efcfae@github.com>
Message-ID: <NfN0eOjv1bxsDG6jm3xRCHHnSe3IznpJEp_SS4joECc=.4280d79d-4611-4f9a-8928-f5e6cf661046@github.com>

On Thu, 12 Aug 2021 09:04:43 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> These two were hidden by the earlier IR test failures.  The errors look like:
> 
> 
>   Caused by: java.lang.RuntimeException: assertEquals: expected -1163019586 to equal 777
>   at jdk.test.lib.Asserts.fail(Asserts.java:594)
>   at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
>   at jdk.test.lib.Asserts.assertEquals(Asserts.java:189)
>   at jdk.test.lib.Asserts.assertEQ(Asserts.java:166)
>   at compiler.valhalla.inlinetypes.TestCallingConventionC1.test64_verifier(TestCallingConventionC1.java:1518)
>   ... 9 more
> 
> 
> In the C1 scalarised entry point we call a runtime stub to allocate objects for buffering the incoming inline types.  The runtime stub returns its result in r0 which is also j_rarg7 and might be holding a live argument value.  To work around this we temporarily move j_rarg7 into r21 which is known to be free at this point and then move it back after the call.  However if a GC occurs during the runtime call and an object held in j_rarg7 is moved, r21 will still be pointing at the old from-space copy after the call returns because it's not recorded in the oop map.  Fix that by having the stub return the object array in r20 and leave r0-r7 untouched.

Looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/527


From mchung at openjdk.java.net  Thu Aug 12 17:40:55 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 12 Aug 2021 17:40:55 GMT
Subject: [lworld] RFR: 8272290: [lworld] Disable CDS if
 InlineTypePassFieldsAsArgs has changed [v2]
In-Reply-To: <mnKZ137ez6hRGHZDxBG48ZEuE6ZS9gkqeJiOjEAL4j0=.3e6f53aa-adac-4308-9253-03e512cf03a3@github.com>
References: <bMRRR47iWL7mGY4likTuYCC9AnAjbkjP0B3H5O7u6zU=.f49e5013-1292-4eb9-86bb-720218f714c4@github.com>
 <mnKZ137ez6hRGHZDxBG48ZEuE6ZS9gkqeJiOjEAL4j0=.3e6f53aa-adac-4308-9253-03e512cf03a3@github.com>
Message-ID: <PMfOlXLhIi7P2lU7AX5Hgyi8g01YOeJEMkMs-P4d2oA=.b1ce47b9-7b43-46ad-ae8b-c93682b8081a@github.com>

On Wed, 11 Aug 2021 04:38:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> If any of the following VM options have different values between CDS dump time and runtime, we cannot load the CDS archive:
>> 
>> - `FlatArrayElementMaxOops`
>> - `FlatArrayElementMaxSize`
>> - `InlineFieldMaxFlatSize`
>> - `InlineTypePassFieldsAsArgs`
>> - `InlineTypeReturnedAsFields`
>> 
>> Testing with mach5 tiers 1-2
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed test failures; improved error message

Marked as reviewed by mchung (Committer).

@ioilam Thanks for fixing this.  To give more context, this issue was uncovered when the CDS archive includes primitive classes such as `Optional` which is converted to a ref-default primitive class.   The tests fail when running with CDS sharing enabled but pass when running with -Xshare:off.

This looks fine to me.  It'd be good to have someone from the runtime to review it.

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

PR: https://git.openjdk.java.net/valhalla/pull/526


From vromero at openjdk.java.net  Thu Aug 12 17:53:14 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 12 Aug 2021 17:53:14 GMT
Subject: RFR: universal type variables: initial prototype [v4]
In-Reply-To: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
Message-ID: <INxg5gfOpSDDZFi46aT-0Du7Ldovx7dsMNiNLmvTAxU=.25be9b7a-369b-4504-b9f3-8304d48cc256@github.com>

> First iteration of the protype for universal type variables

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

  review comments, another iteration

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/521/files
  - new: https://git.openjdk.java.net/valhalla/pull/521/files/3b300830..fe1a449a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=521&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=521&range=02-03

  Stats: 48 lines in 4 files changed: 10 ins; 22 del; 16 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/521.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/521/head:pull/521

PR: https://git.openjdk.java.net/valhalla/pull/521


From mchung at openjdk.java.net  Thu Aug 12 18:11:54 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 12 Aug 2021 18:11:54 GMT
Subject: [lworld] RFR: JDK-8271556: [lworld] java.lang.BootstrapMethodError in
 .equals() for primitive record
Message-ID: <9T937KE4lJRgsv4PrTIIijMob-wrwGMs9s3qcAS-lt0=.c41fb480-f427-4d4c-94b2-a616739601aa@github.com>

We want the default choice is to use the primary L-type mirror and only
when there is a contextual need to make a distinction, the Q-type mirror will be an option.

The proposal is to always pass the primary mirror to the `recordClass` argument
and adjust the bootstrap code to drive method handle creation off of the primitive
value type of the record class instead of `recordClass`, using `recordClass` only
for getting the class name for `toString`.

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

Commit messages:
 - JDK-8271556: [lworld] java.lang.BootstrapMethodError in .equals() for primitive record

Changes: https://git.openjdk.java.net/valhalla/pull/528/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=528&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271556
  Stats: 222 lines in 4 files changed: 211 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/528.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/528/head:pull/528

PR: https://git.openjdk.java.net/valhalla/pull/528


From mcimadamore at openjdk.java.net  Thu Aug 12 18:38:40 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 Aug 2021 18:38:40 GMT
Subject: RFR: universal type variables: initial prototype [v4]
In-Reply-To: <INxg5gfOpSDDZFi46aT-0Du7Ldovx7dsMNiNLmvTAxU=.25be9b7a-369b-4504-b9f3-8304d48cc256@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <INxg5gfOpSDDZFi46aT-0Du7Ldovx7dsMNiNLmvTAxU=.25be9b7a-369b-4504-b9f3-8304d48cc256@github.com>
Message-ID: <pPayJv8N_9prwzL1vC7Ku_3EMcCvir3QWVPXuODxmHA=.e86e84b4-859d-447e-babe-640e371ceb09@github.com>

On Thu, 12 Aug 2021 17:53:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> First iteration of the protype for universal type variables
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments, another iteration

Looks good - just one nitpick

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1991:

> 1989:             this.isReferenceProjection = isReferenceProjection;
> 1990:             this.isUniversal = (tsym.flags_field & UNIVERSAL) != 0;
> 1991:             if (isUniversal && !isReferenceProjection) {

isn't `isReferenceProjection` always `false` here (you have just created the class)

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

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/521


From vromero at openjdk.java.net  Thu Aug 12 19:16:49 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 12 Aug 2021 19:16:49 GMT
Subject: RFR: universal type variables: initial prototype [v4]
In-Reply-To: <pPayJv8N_9prwzL1vC7Ku_3EMcCvir3QWVPXuODxmHA=.e86e84b4-859d-447e-babe-640e371ceb09@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <INxg5gfOpSDDZFi46aT-0Du7Ldovx7dsMNiNLmvTAxU=.25be9b7a-369b-4504-b9f3-8304d48cc256@github.com>
 <pPayJv8N_9prwzL1vC7Ku_3EMcCvir3QWVPXuODxmHA=.e86e84b4-859d-447e-babe-640e371ceb09@github.com>
Message-ID: <wGv0zyF6e4PlROsTqt0GB8ibIKjLIAWEltRLxpOm_uU=.a3d57205-5dc2-4140-97e8-87901c8110dc@github.com>

On Thu, 12 Aug 2021 18:34:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments, another iteration
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1991:
> 
>> 1989:             this.isReferenceProjection = isReferenceProjection;
>> 1990:             this.isUniversal = (tsym.flags_field & UNIVERSAL) != 0;
>> 1991:             if (isUniversal && !isReferenceProjection) {
> 
> isn't `isReferenceProjection` always `false` here (you have just created the class)

not really, because this constructor is used again to build the reference, so I have to add it to the condition to avoid stackoverflow errors

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From vromero at openjdk.java.net  Thu Aug 12 20:06:46 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 12 Aug 2021 20:06:46 GMT
Subject: Integrated: universal type variables: initial prototype
In-Reply-To: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
Message-ID: <4Nts5FIUb0UE8yyhYZvKpsPUiGHpe-nMluQI_FQsqzs=.21532b66-2fef-4b41-8af0-d3a8e7fbc7df@github.com>

On Wed, 4 Aug 2021 03:51:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> First iteration of the protype for universal type variables

This pull request has now been integrated.

Changeset: 3e896faf
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/3e896fafc69ce6b769ad9685d5de0212951224af
Stats:     756 lines in 22 files changed: 717 ins; 1 del; 38 mod

universal type variables: initial prototype

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From vromero at openjdk.java.net  Thu Aug 12 20:25:45 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 12 Aug 2021 20:25:45 GMT
Subject: RFR: universal type variables: initial prototype [v4]
In-Reply-To: <INxg5gfOpSDDZFi46aT-0Du7Ldovx7dsMNiNLmvTAxU=.25be9b7a-369b-4504-b9f3-8304d48cc256@github.com>
References: <OWF73PCQJu0Ztm45iQZ7Zc2bBJjLyS7Rh3vOJ9nd2vU=.3d6cae59-c7c6-4154-bd08-4380bafc7ccb@github.com>
 <INxg5gfOpSDDZFi46aT-0Du7Ldovx7dsMNiNLmvTAxU=.25be9b7a-369b-4504-b9f3-8304d48cc256@github.com>
Message-ID: <lzXl0ovD0j6xOEt2OOALLIFeGVbA6qGoNnYaUQFEiZ8=.1a384e32-cabe-4190-a634-cd3025cc42ef@github.com>

On Thu, 12 Aug 2021 17:53:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> First iteration of the protype for universal type variables
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments, another iteration

thanks for the review

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

PR: https://git.openjdk.java.net/valhalla/pull/521


From mchung at openjdk.java.net  Thu Aug 12 21:43:55 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 12 Aug 2021 21:43:55 GMT
Subject: [lworld] RFR: JDK-8272397: [lworld] Move ValueBootstrapMethods to
 java.lang.runtime
Message-ID: <6iafBwqgwjoWYlu4VmWJ-c1T7tZHi4Q6eiz99Oyj3Rw=.e3299ea7-d2b6-4caf-98f5-f337f6ba5432@github.com>

`ValueBootstrapMethods` is the default implementation of `Object::equals` and `Object::hashCode`
for primitive class. It does not belong to java.lang.invoke. java.lang.runtime is a more
appropriate home.  It can also share the code in `ObjectMethods`.

The methods are now renamed to `java.lang.runtime.PrimitiveObjectMethods::isSubtitutable`
and `primitiveObjectHashCode`.

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

Commit messages:
 - JDK-8272397: [world] Move ValueBootstrapMethods to java.lang.runtime

Changes: https://git.openjdk.java.net/valhalla/pull/529/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=529&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272397
  Stats: 1231 lines in 18 files changed: 495 ins; 702 del; 34 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/529.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/529/head:pull/529

PR: https://git.openjdk.java.net/valhalla/pull/529


From ngasson at openjdk.java.net  Fri Aug 13 01:50:38 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 13 Aug 2021 01:50:38 GMT
Subject: [lworld] RFR: 8272307: [lworld] [AArch64] TestCallingConventionC1
 test63 and test64 get incorrect result
In-Reply-To: <NfN0eOjv1bxsDG6jm3xRCHHnSe3IznpJEp_SS4joECc=.4280d79d-4611-4f9a-8928-f5e6cf661046@github.com>
References: <kZyjA3xvWfZMxycrUlNzFROCr9_kjrXe0URI_tipnb8=.1396923f-0922-4cf4-8cf6-166649efcfae@github.com>
 <NfN0eOjv1bxsDG6jm3xRCHHnSe3IznpJEp_SS4joECc=.4280d79d-4611-4f9a-8928-f5e6cf661046@github.com>
Message-ID: <iCLyfrxS67nIT5HSY_FFXhHQpvQLeo1zpGCEB21SKWs=.7e647cca-6854-4d2d-8ab3-cc49d4b74c4a@github.com>

On Thu, 12 Aug 2021 12:36:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> These two were hidden by the earlier IR test failures.  The errors look like:
>> 
>> 
>>   Caused by: java.lang.RuntimeException: assertEquals: expected -1163019586 to equal 777
>>   at jdk.test.lib.Asserts.fail(Asserts.java:594)
>>   at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
>>   at jdk.test.lib.Asserts.assertEquals(Asserts.java:189)
>>   at jdk.test.lib.Asserts.assertEQ(Asserts.java:166)
>>   at compiler.valhalla.inlinetypes.TestCallingConventionC1.test64_verifier(TestCallingConventionC1.java:1518)
>>   ... 9 more
>> 
>> 
>> In the C1 scalarised entry point we call a runtime stub to allocate objects for buffering the incoming inline types.  The runtime stub returns its result in r0 which is also j_rarg7 and might be holding a live argument value.  To work around this we temporarily move j_rarg7 into r21 which is known to be free at this point and then move it back after the call.  However if a GC occurs during the runtime call and an object held in j_rarg7 is moved, r21 will still be pointing at the old from-space copy after the call returns because it's not recorded in the oop map.  Fix that by having the stub return the object array in r20 and leave r0-r7 untouched.
>
> Looks good to me.

Thanks @TobiHartmann!

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

PR: https://git.openjdk.java.net/valhalla/pull/527


From vromero at openjdk.java.net  Fri Aug 13 01:58:16 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 13 Aug 2021 01:58:16 GMT
Subject: RFR: Merge lworld
Message-ID: <WAVWbdoK2kSPNzY5ZwbQLnX6bXz2DnWyzRMb4XqdPnM=.a20029e9-f169-4c68-aaf1-126467323e3f@github.com>

Merging lworld into universal-tvars

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

Commit messages:
 - Merge lworld
 - 8272041: [lworld] CDS heap dump fails with primitive objects
 - 8271924: [lworld] Crashes in ZBarrierSetRuntime::load_barrier_on_oop_array
 - Merge jdk
 - 8265057: G1: Investigate removal of maintenance of two BOT thresholds
 - 8256844: Make NMT late-initializable
 - 6350025: API documentation for JOptionPane using deprecated methods.
 - 8270893: IndexOutOfBoundsException while reading large TIFF file
 - 8271836: runtime/ErrorHandling/ClassPathEnvVar.java fails with release VMs
 - 8264543: Cross modify fence optimization for x86
 - ... and 75 more: https://git.openjdk.java.net/valhalla/compare/3e896faf...d775b1c3

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - universal-tvars: https://webrevs.openjdk.java.net/?repo=valhalla&pr=530&range=00.0
 - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=530&range=00.1

Changes: https://git.openjdk.java.net/valhalla/pull/530/files
  Stats: 36316 lines in 284 files changed: 33505 ins; 1621 del; 1190 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/530.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/530/head:pull/530

PR: https://git.openjdk.java.net/valhalla/pull/530


From vromero at openjdk.java.net  Fri Aug 13 02:03:45 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 13 Aug 2021 02:03:45 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <WAVWbdoK2kSPNzY5ZwbQLnX6bXz2DnWyzRMb4XqdPnM=.a20029e9-f169-4c68-aaf1-126467323e3f@github.com>
References: <WAVWbdoK2kSPNzY5ZwbQLnX6bXz2DnWyzRMb4XqdPnM=.a20029e9-f169-4c68-aaf1-126467323e3f@github.com>
Message-ID: <8DorCMkIw0meb5oYEBR6rC-Op0txWPP-WYGyBRrkNJE=.89e82886-9300-413f-aabc-84b1d276e1ce@github.com>

On Fri, 13 Aug 2021 01:51:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merging lworld into universal-tvars

This pull request has now been integrated.

Changeset: cdc1eca5
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/cdc1eca549271d750db2e08b20d99187c8b1856b
Stats:     36316 lines in 284 files changed: 33505 ins; 1621 del; 1190 mod

Merge lworld

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

PR: https://git.openjdk.java.net/valhalla/pull/530


From ngasson at openjdk.java.net  Fri Aug 13 10:18:46 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 13 Aug 2021 10:18:46 GMT
Subject: [lworld] Integrated: 8272307: [lworld] [AArch64]
 TestCallingConventionC1 test63 and test64 get incorrect result
In-Reply-To: <kZyjA3xvWfZMxycrUlNzFROCr9_kjrXe0URI_tipnb8=.1396923f-0922-4cf4-8cf6-166649efcfae@github.com>
References: <kZyjA3xvWfZMxycrUlNzFROCr9_kjrXe0URI_tipnb8=.1396923f-0922-4cf4-8cf6-166649efcfae@github.com>
Message-ID: <VwTVr18Fk-koOr_H4fkzRDuNvOTteVkLDcyfCXKYyvo=.234a7a74-02c7-45f7-999f-e226b5b38010@github.com>

On Thu, 12 Aug 2021 09:04:43 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> These two were hidden by the earlier IR test failures.  The errors look like:
> 
> 
>   Caused by: java.lang.RuntimeException: assertEquals: expected -1163019586 to equal 777
>   at jdk.test.lib.Asserts.fail(Asserts.java:594)
>   at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
>   at jdk.test.lib.Asserts.assertEquals(Asserts.java:189)
>   at jdk.test.lib.Asserts.assertEQ(Asserts.java:166)
>   at compiler.valhalla.inlinetypes.TestCallingConventionC1.test64_verifier(TestCallingConventionC1.java:1518)
>   ... 9 more
> 
> 
> In the C1 scalarised entry point we call a runtime stub to allocate objects for buffering the incoming inline types.  The runtime stub returns its result in r0 which is also j_rarg7 and might be holding a live argument value.  To work around this we temporarily move j_rarg7 into r21 which is known to be free at this point and then move it back after the call.  However if a GC occurs during the runtime call and an object held in j_rarg7 is moved, r21 will still be pointing at the old from-space copy after the call returns because it's not recorded in the oop map.  Fix that by having the stub return the object array in r20 and leave r0-r7 untouched.

This pull request has now been integrated.

Changeset: f85b10be
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f85b10beff2404c370b175b1cd01bf209b5f3388
Stats:     20 lines in 2 files changed: 7 ins; 8 del; 5 mod

8272307: [lworld] [AArch64] TestCallingConventionC1 test63 and test64 get incorrect result

Reviewed-by: thartmann

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

PR: https://git.openjdk.java.net/valhalla/pull/527


From fparain at openjdk.java.net  Fri Aug 13 13:13:35 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 13 Aug 2021 13:13:35 GMT
Subject: [lworld] RFR: 8272290: [lworld] Disable CDS if
 InlineTypePassFieldsAsArgs has changed [v2]
In-Reply-To: <mnKZ137ez6hRGHZDxBG48ZEuE6ZS9gkqeJiOjEAL4j0=.3e6f53aa-adac-4308-9253-03e512cf03a3@github.com>
References: <bMRRR47iWL7mGY4likTuYCC9AnAjbkjP0B3H5O7u6zU=.f49e5013-1292-4eb9-86bb-720218f714c4@github.com>
 <mnKZ137ez6hRGHZDxBG48ZEuE6ZS9gkqeJiOjEAL4j0=.3e6f53aa-adac-4308-9253-03e512cf03a3@github.com>
Message-ID: <CJjvV-b3_5BRpTb6xNKBMrOCjsAkHdP4b0AOQqVsz8M=.1347adf7-0ee9-4226-8598-9126b2ff8299@github.com>

On Wed, 11 Aug 2021 04:38:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> If any of the following VM options have different values between CDS dump time and runtime, we cannot load the CDS archive:
>> 
>> - `FlatArrayElementMaxOops`
>> - `FlatArrayElementMaxSize`
>> - `InlineFieldMaxFlatSize`
>> - `InlineTypePassFieldsAsArgs`
>> - `InlineTypeReturnedAsFields`
>> 
>> Testing with mach5 tiers 1-2
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed test failures; improved error message

Looks good to me.

Fred

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

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/526


From jespersm at openjdk.java.net  Sun Aug 15 11:32:53 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Sun, 15 Aug 2021 11:32:53 GMT
Subject: [lworld] RFR: JDK-8271556: [lworld]
 java.lang.BootstrapMethodError in .equals() for primitive record
In-Reply-To: <9T937KE4lJRgsv4PrTIIijMob-wrwGMs9s3qcAS-lt0=.c41fb480-f427-4d4c-94b2-a616739601aa@github.com>
References: <9T937KE4lJRgsv4PrTIIijMob-wrwGMs9s3qcAS-lt0=.c41fb480-f427-4d4c-94b2-a616739601aa@github.com>
Message-ID: <mhpykcby6g9AKjb4GvXvIoA049DkA2t13qleQpvpG4A=.ba2251d8-0b4d-47cb-b062-be8b348c4b20@github.com>

On Thu, 12 Aug 2021 18:05:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> We want the default choice is to use the primary L-type mirror and only
> when there is a contextual need to make a distinction, the Q-type mirror will be an option.
> 
> The proposal is to always pass the primary mirror to the `recordClass` argument
> and adjust the bootstrap code to drive method handle creation off of the primitive
> value type of the record class instead of `recordClass`, using `recordClass` only
> for getting the class name for `toString`.

The patch also works here. Just a minor stylistic suggestion where a pattern could save a few casts.

src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 340:

> 338:         Class<?> receiverType = recordClass.isPrimitiveClass() ? recordClass.asValueType() : recordClass;
> 339: 
> 340:         if (type instanceof MethodType) {

Nitpicking: Perhaps

if (type instanceof MethodType mType) {
    methodType = mType;
    if (mType.parameterType(0) != receiverType) {

?

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

PR: https://git.openjdk.java.net/valhalla/pull/528


From iklam at openjdk.java.net  Mon Aug 16 00:57:08 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 16 Aug 2021 00:57:08 GMT
Subject: [lworld] RFR: 8272290: [lworld] Disable CDS if
 InlineTypePassFieldsAsArgs has changed [v2]
In-Reply-To: <PMfOlXLhIi7P2lU7AX5Hgyi8g01YOeJEMkMs-P4d2oA=.b1ce47b9-7b43-46ad-ae8b-c93682b8081a@github.com>
References: <bMRRR47iWL7mGY4likTuYCC9AnAjbkjP0B3H5O7u6zU=.f49e5013-1292-4eb9-86bb-720218f714c4@github.com>
 <mnKZ137ez6hRGHZDxBG48ZEuE6ZS9gkqeJiOjEAL4j0=.3e6f53aa-adac-4308-9253-03e512cf03a3@github.com>
 <PMfOlXLhIi7P2lU7AX5Hgyi8g01YOeJEMkMs-P4d2oA=.b1ce47b9-7b43-46ad-ae8b-c93682b8081a@github.com>
Message-ID: <FEjSdPugBTLu8Tzld5T8tKbywEO7Nqzr1miBl1skxI8=.aa0414ff-5feb-428e-b3c5-9b5443c172fc@github.com>

On Thu, 12 Aug 2021 17:37:42 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed test failures; improved error message
>
> @ioilam Thanks for fixing this.  To give more context, this issue was uncovered when the CDS archive includes primitive classes such as `Optional` which is converted to a ref-default primitive class.   The tests fail when running with CDS sharing enabled but pass when running with -Xshare:off.
> 
> This looks fine to me.  It'd be good to have someone from the runtime to review it.

Thanks @mlchung and @fparain for the review.

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

PR: https://git.openjdk.java.net/valhalla/pull/526


From iklam at openjdk.java.net  Mon Aug 16 00:57:09 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 16 Aug 2021 00:57:09 GMT
Subject: [lworld] Integrated: 8272290: [lworld] Disable CDS if
 InlineTypePassFieldsAsArgs has changed
In-Reply-To: <bMRRR47iWL7mGY4likTuYCC9AnAjbkjP0B3H5O7u6zU=.f49e5013-1292-4eb9-86bb-720218f714c4@github.com>
References: <bMRRR47iWL7mGY4likTuYCC9AnAjbkjP0B3H5O7u6zU=.f49e5013-1292-4eb9-86bb-720218f714c4@github.com>
Message-ID: <LZVfie8XYp6mO_L1NKn8JT3KglE2huE0aGndcm12m6k=.f439c114-d751-43ef-91f6-6820bc2725fd@github.com>

On Tue, 10 Aug 2021 23:48:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> If any of the following VM options have different values between CDS dump time and runtime, we cannot load the CDS archive:
> 
> - `FlatArrayElementMaxOops`
> - `FlatArrayElementMaxSize`
> - `InlineFieldMaxFlatSize`
> - `InlineTypePassFieldsAsArgs`
> - `InlineTypeReturnedAsFields`
> 
> Testing with mach5 tiers 1-2

This pull request has now been integrated.

Changeset: a5516c19
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a5516c19ad4973eebc1f0c38a6b48d067413a0a4
Stats:     109 lines in 3 files changed: 107 ins; 0 del; 2 mod

8272290: [lworld] Disable CDS if InlineTypePassFieldsAsArgs has changed

Reviewed-by: mchung, fparain

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

PR: https://git.openjdk.java.net/valhalla/pull/526


From thartmann at openjdk.java.net  Mon Aug 16 08:07:16 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 16 Aug 2021 08:07:16 GMT
Subject: [lworld] Integrated: 8272511: [lworld] Disable
 PhaseIdealLoop::try_sink_out_of_loop until optimization is stable in mainline
Message-ID: <o2UM7iE2SqvybKP6EmK7sJdr6MhaZjhO-oVIhpDTlIY=.1c788cb1-b142-49e3-a1cc-9309d0a4f7d5@github.com>

There are known (mainline) issues with JDK-8252372 (see JDK-8271954) that seem to manifest in Valhalla. Disable the optimization until it's stable in mainline.

Best regards,
Tobias

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

Commit messages:
 - 8272511: [lworld] Disable PhaseIdealLoop::try_sink_out_of_loop until optimization is stable in mainline

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

PR: https://git.openjdk.java.net/valhalla/pull/531


From thartmann at openjdk.java.net  Mon Aug 16 08:07:17 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 16 Aug 2021 08:07:17 GMT
Subject: [lworld] Integrated: 8272511: [lworld] Disable
 PhaseIdealLoop::try_sink_out_of_loop until optimization is stable in mainline
In-Reply-To: <o2UM7iE2SqvybKP6EmK7sJdr6MhaZjhO-oVIhpDTlIY=.1c788cb1-b142-49e3-a1cc-9309d0a4f7d5@github.com>
References: <o2UM7iE2SqvybKP6EmK7sJdr6MhaZjhO-oVIhpDTlIY=.1c788cb1-b142-49e3-a1cc-9309d0a4f7d5@github.com>
Message-ID: <3qF4ANmzBWejhd7KQT6bhXCpfojBlngVXx44vTrcj6U=.8c8ecc61-0b0e-4803-b3db-10b7e9f187ec@github.com>

On Mon, 16 Aug 2021 07:58:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> There are known (mainline) issues with JDK-8252372 (see JDK-8271954) that seem to manifest in Valhalla. Disable the optimization until it's stable in mainline.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 96f20529
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/96f20529e9a0f9e16a5ba54d571a073b81b9aae6
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8272511: [lworld] Disable PhaseIdealLoop::try_sink_out_of_loop until optimization is stable in mainline

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

PR: https://git.openjdk.java.net/valhalla/pull/531


From david.simms at oracle.com  Mon Aug 16 12:04:30 2021
From: david.simms at oracle.com (David Simms)
Date: Mon, 16 Aug 2021 14:04:30 +0200
Subject: Result: New Valhalla Committer: Alex Menkov
Message-ID: <cb80eb52-7dca-89f2-92f6-01dc80962777@oracle.com>

Voting for Alex Menkov [1] is now closed.

Yes: 6
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

David Simms

[1] 
https://mail.openjdk.java.net/pipermail/valhalla-dev/2021-July/009367.html



From mchung at openjdk.java.net  Mon Aug 16 16:34:07 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 16 Aug 2021 16:34:07 GMT
Subject: [lworld] RFR: JDK-8271556: [lworld]
 java.lang.BootstrapMethodError in .equals() for primitive record
In-Reply-To: <mhpykcby6g9AKjb4GvXvIoA049DkA2t13qleQpvpG4A=.ba2251d8-0b4d-47cb-b062-be8b348c4b20@github.com>
References: <9T937KE4lJRgsv4PrTIIijMob-wrwGMs9s3qcAS-lt0=.c41fb480-f427-4d4c-94b2-a616739601aa@github.com>
 <mhpykcby6g9AKjb4GvXvIoA049DkA2t13qleQpvpG4A=.ba2251d8-0b4d-47cb-b062-be8b348c4b20@github.com>
Message-ID: <lVaaeswTPDtpGB8eJpWWajVzpy4jbJIRItr9bpQWo_Y=.5b6d8e97-0ce3-4b06-9694-8e17d8ec5b28@github.com>

On Thu, 12 Aug 2021 21:35:13 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> We want the default choice is to use the primary L-type mirror and only
>> when there is a contextual need to make a distinction, the Q-type mirror will be an option.
>> 
>> The proposal is to always pass the primary mirror to the `recordClass` argument
>> and adjust the bootstrap code to drive method handle creation off of the primitive
>> value type of the record class instead of `recordClass`, using `recordClass` only
>> for getting the class name for `toString`.
>
> src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 340:
> 
>> 338:         Class<?> receiverType = recordClass.isPrimitiveClass() ? recordClass.asValueType() : recordClass;
>> 339: 
>> 340:         if (type instanceof MethodType) {
> 
> Nitpicking: Perhaps
> 
> if (type instanceof MethodType mType) {
>     methodType = mType;
>     if (mType.parameterType(0) != receiverType) {
> 
> ?

sure.  I may fix it in jdk repo directly.

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

PR: https://git.openjdk.java.net/valhalla/pull/528


From iklam at openjdk.java.net  Tue Aug 17 04:21:36 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 17 Aug 2021 04:21:36 GMT
Subject: [lworld] RFR: 8272400: [lworld] serviceability/sa/CDSJMapClstats.java
 fails: No suitable match for type of address
Message-ID: <pA5j_idVE3oVl8IS0UI9J4qY23V4q3hxEvnnjob8bRE=.4474be7d-cfdd-4f66-9b43-e0649325e2de@github.com>

This is a fix in CDS and SA to get CDSJMapClstats.java (and a bunch of other SA tests) to pass:

- Implement skeletal `FlatArrayKlass` and `InlineKlass` types in SA
- Implement the CDS C++ vtable lookup of these two types.

After this fix, only 2 out of 191 tests in test/hotspot/jtreg/serviceability/ are still failing.

However, support of these two types are incomplete in SA, so programs that try to use the SA APIs to access VM internals will not work. The full SA support of inlined types will be done separately in https://bugs.openjdk.java.net/browse/JDK-8205036

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

Commit messages:
 - 8272400: [lworld] serviceability/sa/CDSJMapClstats.java fails: No suitable match for type of address

Changes: https://git.openjdk.java.net/valhalla/pull/532/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=532&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272400
  Stats: 126 lines in 6 files changed: 124 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/532.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/532/head:pull/532

PR: https://git.openjdk.java.net/valhalla/pull/532


From fparain at openjdk.java.net  Tue Aug 17 12:07:56 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 17 Aug 2021 12:07:56 GMT
Subject: [lworld] RFR: 8272400: [lworld]
 serviceability/sa/CDSJMapClstats.java fails: No suitable match for type of
 address
In-Reply-To: <pA5j_idVE3oVl8IS0UI9J4qY23V4q3hxEvnnjob8bRE=.4474be7d-cfdd-4f66-9b43-e0649325e2de@github.com>
References: <pA5j_idVE3oVl8IS0UI9J4qY23V4q3hxEvnnjob8bRE=.4474be7d-cfdd-4f66-9b43-e0649325e2de@github.com>
Message-ID: <FfHxcbRN46jlLxF-2UblZKevY5saN5SgbURUmQ7zG8c=.3f32e8b0-9ade-4ec2-bef1-88f0e6063104@github.com>

On Tue, 17 Aug 2021 04:15:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a fix in CDS and SA to get CDSJMapClstats.java (and a bunch of other SA tests) to pass:
> 
> - Implement skeletal `FlatArrayKlass` and `InlineKlass` types in SA
> - Implement the CDS C++ vtable lookup of these two types.
> 
> After this fix, only 2 out of 191 tests in test/hotspot/jtreg/serviceability/ are still failing.
> 
> However, support of these two types are incomplete in SA, so programs that try to use the SA APIs to access VM internals will not work. The full SA support of inlined types will be done separately in https://bugs.openjdk.java.net/browse/JDK-8205036

Looks like a good start to fix the SA.
Thank you for doing it.

Fred

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

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/532


From fparain at openjdk.java.net  Tue Aug 17 17:36:41 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 17 Aug 2021 17:36:41 GMT
Subject: [lworld] RFR: JDK-8272397: [lworld] Move ValueBootstrapMethods to
 java.lang.runtime
In-Reply-To: <6iafBwqgwjoWYlu4VmWJ-c1T7tZHi4Q6eiz99Oyj3Rw=.e3299ea7-d2b6-4caf-98f5-f337f6ba5432@github.com>
References: <6iafBwqgwjoWYlu4VmWJ-c1T7tZHi4Q6eiz99Oyj3Rw=.e3299ea7-d2b6-4caf-98f5-f337f6ba5432@github.com>
Message-ID: <ZWpy6CeIkqXEhs3OZGCL6Nk8_2SPsA7l9YhbeZf7qWM=.516bf661-7a30-435a-8ac2-ef049af1a6e4@github.com>

On Thu, 12 Aug 2021 21:36:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `ValueBootstrapMethods` is the default implementation of `Object::equals` and `Object::hashCode`
> for primitive class. It does not belong to java.lang.invoke. java.lang.runtime is a more
> appropriate home.  It can also share the code in `ObjectMethods`.
> 
> The methods are now renamed to `java.lang.runtime.PrimitiveObjectMethods::isSubtitutable`
> and `primitiveObjectHashCode`.

HotSpot changes look good.

Fred

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

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/529


From rriggs at openjdk.java.net  Tue Aug 17 18:34:36 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 17 Aug 2021 18:34:36 GMT
Subject: [lworld] RFR: JDK-8272397: [lworld] Move ValueBootstrapMethods to
 java.lang.runtime
In-Reply-To: <6iafBwqgwjoWYlu4VmWJ-c1T7tZHi4Q6eiz99Oyj3Rw=.e3299ea7-d2b6-4caf-98f5-f337f6ba5432@github.com>
References: <6iafBwqgwjoWYlu4VmWJ-c1T7tZHi4Q6eiz99Oyj3Rw=.e3299ea7-d2b6-4caf-98f5-f337f6ba5432@github.com>
Message-ID: <M-KXgqN8Al-Ki7ddh2NsIBJEtqU6JGK9qhEBcQvFpQo=.9ebf52a4-a24a-43a4-a1e8-b9c40bb53e0f@github.com>

On Thu, 12 Aug 2021 21:36:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `ValueBootstrapMethods` is the default implementation of `Object::equals` and `Object::hashCode`
> for primitive class. It does not belong to java.lang.invoke. java.lang.runtime is a more
> appropriate home.  It can also share the code in `ObjectMethods`.
> 
> The methods are now renamed to `java.lang.runtime.PrimitiveObjectMethods::isSubtitutable`
> and `primitiveObjectHashCode`.

LGTM

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

Marked as reviewed by rriggs (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/529


From rriggs at openjdk.java.net  Tue Aug 17 18:45:39 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 17 Aug 2021 18:45:39 GMT
Subject: [lworld] RFR: JDK-8271556: [lworld]
 java.lang.BootstrapMethodError in .equals() for primitive record
In-Reply-To: <9T937KE4lJRgsv4PrTIIijMob-wrwGMs9s3qcAS-lt0=.c41fb480-f427-4d4c-94b2-a616739601aa@github.com>
References: <9T937KE4lJRgsv4PrTIIijMob-wrwGMs9s3qcAS-lt0=.c41fb480-f427-4d4c-94b2-a616739601aa@github.com>
Message-ID: <EQebUTrrm-aYovgOZcLB5yBKuHhAJiEcbhWNuxaKQTg=.c64ef9e9-842a-4870-9430-a167da8172f1@github.com>

On Thu, 12 Aug 2021 18:05:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> We want the default choice is to use the primary L-type mirror and only
> when there is a contextual need to make a distinction, the Q-type mirror will be an option.
> 
> The proposal is to always pass the primary mirror to the `recordClass` argument
> and adjust the bootstrap code to drive method handle creation off of the primitive
> value type of the record class instead of `recordClass`, using `recordClass` only
> for getting the class name for `toString`.

LGTM

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

Marked as reviewed by rriggs (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/528


From iklam at openjdk.java.net  Tue Aug 17 19:06:52 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 17 Aug 2021 19:06:52 GMT
Subject: [lworld] RFR: 8272400: [lworld]
 serviceability/sa/CDSJMapClstats.java fails: No suitable match for type of
 address
In-Reply-To: <FfHxcbRN46jlLxF-2UblZKevY5saN5SgbURUmQ7zG8c=.3f32e8b0-9ade-4ec2-bef1-88f0e6063104@github.com>
References: <pA5j_idVE3oVl8IS0UI9J4qY23V4q3hxEvnnjob8bRE=.4474be7d-cfdd-4f66-9b43-e0649325e2de@github.com>
 <FfHxcbRN46jlLxF-2UblZKevY5saN5SgbURUmQ7zG8c=.3f32e8b0-9ade-4ec2-bef1-88f0e6063104@github.com>
Message-ID: <L3gz2md6FPeoV41XiaRGvHvFPfeFqo_3tzASmiGAGVY=.f7de1d5f-98dd-467a-ab09-1250c6259edb@github.com>

On Tue, 17 Aug 2021 12:04:37 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is a fix in CDS and SA to get CDSJMapClstats.java (and a bunch of other SA tests) to pass:
>> 
>> - Implement skeletal `FlatArrayKlass` and `InlineKlass` types in SA
>> - Implement the CDS C++ vtable lookup of these two types.
>> 
>> After this fix, only 2 out of 191 tests in test/hotspot/jtreg/serviceability/ are still failing.
>> 
>> However, support of these two types are incomplete in SA, so programs that try to use the SA APIs to access VM internals will not work. The full SA support of inlined types will be done separately in https://bugs.openjdk.java.net/browse/JDK-8205036
>
> Looks like a good start to fix the SA.
> Thank you for doing it.
> 
> Fred

Thanks @fparain for the review. Mach5 tier1-2 clean.

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

PR: https://git.openjdk.java.net/valhalla/pull/532


From iklam at openjdk.java.net  Tue Aug 17 19:06:55 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 17 Aug 2021 19:06:55 GMT
Subject: [lworld] Integrated: 8272400: [lworld]
 serviceability/sa/CDSJMapClstats.java fails: No suitable match for type of
 address
In-Reply-To: <pA5j_idVE3oVl8IS0UI9J4qY23V4q3hxEvnnjob8bRE=.4474be7d-cfdd-4f66-9b43-e0649325e2de@github.com>
References: <pA5j_idVE3oVl8IS0UI9J4qY23V4q3hxEvnnjob8bRE=.4474be7d-cfdd-4f66-9b43-e0649325e2de@github.com>
Message-ID: <GlB3jsMzlkZ5vo4Kb7KlZ87lOswXBol8KP8LlIJwfKM=.70a2d07d-f9d8-462a-ab38-daf3de8d7e8c@github.com>

On Tue, 17 Aug 2021 04:15:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a fix in CDS and SA to get CDSJMapClstats.java (and a bunch of other SA tests) to pass:
> 
> - Implement skeletal `FlatArrayKlass` and `InlineKlass` types in SA
> - Implement the CDS C++ vtable lookup of these two types.
> 
> After this fix, only 2 out of 191 tests in test/hotspot/jtreg/serviceability/ are still failing.
> 
> However, support of these two types are incomplete in SA, so programs that try to use the SA APIs to access VM internals will not work. The full SA support of inlined types will be done separately in https://bugs.openjdk.java.net/browse/JDK-8205036

This pull request has now been integrated.

Changeset: 9d054840
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/9d05484027b9d1c525c194f40c22fb8d0eac07ff
Stats:     126 lines in 6 files changed: 124 ins; 0 del; 2 mod

8272400: [lworld] serviceability/sa/CDSJMapClstats.java fails: No suitable match for type of address

Reviewed-by: fparain

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

PR: https://git.openjdk.java.net/valhalla/pull/532


From mchung at openjdk.java.net  Tue Aug 17 20:33:48 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 17 Aug 2021 20:33:48 GMT
Subject: [lworld] Integrated: JDK-8271556: [lworld]
 java.lang.BootstrapMethodError in .equals() for primitive record
In-Reply-To: <9T937KE4lJRgsv4PrTIIijMob-wrwGMs9s3qcAS-lt0=.c41fb480-f427-4d4c-94b2-a616739601aa@github.com>
References: <9T937KE4lJRgsv4PrTIIijMob-wrwGMs9s3qcAS-lt0=.c41fb480-f427-4d4c-94b2-a616739601aa@github.com>
Message-ID: <ddM3TNPrkWUozvHveRh89t4sfGVXQGrKugBQrLn47Tk=.1d79b5f8-3b61-4d50-a733-e4ead50de1ac@github.com>

On Thu, 12 Aug 2021 18:05:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> We want the default choice is to use the primary L-type mirror and only
> when there is a contextual need to make a distinction, the Q-type mirror will be an option.
> 
> The proposal is to always pass the primary mirror to the `recordClass` argument
> and adjust the bootstrap code to drive method handle creation off of the primitive
> value type of the record class instead of `recordClass`, using `recordClass` only
> for getting the class name for `toString`.

This pull request has now been integrated.

Changeset: ad20c66f
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ad20c66f6664b89a0bf0ef2177d91739fdb0d014
Stats:     222 lines in 4 files changed: 211 ins; 0 del; 11 mod

8271556: [lworld] java.lang.BootstrapMethodError in .equals() for primitive record

Reviewed-by: rriggs

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

PR: https://git.openjdk.java.net/valhalla/pull/528


From mchung at openjdk.java.net  Tue Aug 17 22:30:47 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 17 Aug 2021 22:30:47 GMT
Subject: [lworld] Integrated: JDK-8272397: [lworld] Move ValueBootstrapMethods
 to java.lang.runtime
In-Reply-To: <6iafBwqgwjoWYlu4VmWJ-c1T7tZHi4Q6eiz99Oyj3Rw=.e3299ea7-d2b6-4caf-98f5-f337f6ba5432@github.com>
References: <6iafBwqgwjoWYlu4VmWJ-c1T7tZHi4Q6eiz99Oyj3Rw=.e3299ea7-d2b6-4caf-98f5-f337f6ba5432@github.com>
Message-ID: <Uy9K_711JskuJePmsWtbjHFC6aBCvaeuQ04W2nVze_Y=.345104fd-0a01-46a7-bd71-533171dedac3@github.com>

On Thu, 12 Aug 2021 21:36:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `ValueBootstrapMethods` is the default implementation of `Object::equals` and `Object::hashCode`
> for primitive class. It does not belong to java.lang.invoke. java.lang.runtime is a more
> appropriate home.  It can also share the code in `ObjectMethods`.
> 
> The methods are now renamed to `java.lang.runtime.PrimitiveObjectMethods::isSubtitutable`
> and `primitiveObjectHashCode`.

This pull request has now been integrated.

Changeset: 9c2af854
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/9c2af854deb759d4b7879191d7ff5807bf679e32
Stats:     1231 lines in 18 files changed: 495 ins; 702 del; 34 mod

8272397: [lworld] Move ValueBootstrapMethods to java.lang.runtime

Reviewed-by: fparain, rriggs

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

PR: https://git.openjdk.java.net/valhalla/pull/529


From jespersm at openjdk.java.net  Tue Aug 17 23:54:35 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Tue, 17 Aug 2021 23:54:35 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v5]
In-Reply-To: <I5U6lONHR354nDNcsjxW5VxClaHY1tal7N9sk6cb5-8=.05ff7f61-bfc5-424e-a44e-7e02399eb0be@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
 <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
 <I5U6lONHR354nDNcsjxW5VxClaHY1tal7N9sk6cb5-8=.05ff7f61-bfc5-424e-a44e-7e02399eb0be@github.com>
Message-ID: <qPvpGUzy-QUFjRDXGu20xYBKHFHMzAzR0WUSJEHgWRI=.a6a7d758-4b31-48f2-b598-ed4b6192d0c2@github.com>

On Tue, 3 Aug 2021 09:34:48 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace
>
> Hi Jesper, I have left some comments - but I will need to make a couple of more passes to fully understand the implementation as this is a fairly involved and complex task. I will actually have to tinker with the version you have posted to comprehend it - Could you give me some time - I will play around with it and propose a version that addresses the problems I have outlined and also includes further tweaks that could simplify the implementation more ? Then we can study it, finalize it and then ask Maurizio for a final review once both of us are satisfied.

@sadayapalam : I can take another go at this one to adress the review comments above, which may make a second review pass easier.

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

PR: https://git.openjdk.java.net/valhalla/pull/369


From jespersm at openjdk.java.net  Tue Aug 17 23:59:51 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Tue, 17 Aug 2021 23:59:51 GMT
Subject: [lworld] RFR: 8271583: [lworld] primitive records can't be reference
 favoring
Message-ID: <N2zYZpkR_Ypuf0f-Ciqlx0Q-bEzZb0U1FU92SZa6VMI=.6dff239f-2c01-4897-b72c-9f4fe2035109@github.com>

This patch lets the compiler pick up a record which can be primitive records and reference favoring, such as

primitive record Point.val(int x, int y) {}


The lowering had to be adjusted so that the correct receiver type is generated.

See https://bugs.openjdk.java.net/browse/JDK-8271583

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

Commit messages:
 - 8271583: [lworld] primitive records can't be reference favoring
 - 8271583: [lworld] primitive records can't be reference favoring

Changes: https://git.openjdk.java.net/valhalla/pull/533/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=533&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271583
  Stats: 57 lines in 3 files changed: 55 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/533.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/533/head:pull/533

PR: https://git.openjdk.java.net/valhalla/pull/533


From ngasson at openjdk.java.net  Wed Aug 18 06:45:58 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 18 Aug 2021 06:45:58 GMT
Subject: [lworld] RFR: 8272566: [lworld] [AArch64] G1 write barrier slow path
 needs to save more registers
Message-ID: <JrwzYiEUbPmaNSBs-bvDdXaYTgoN7I8LHdumscBgFVs=.a88ee6b1-f664-470d-b3aa-5c0fc89a3e17@github.com>

We call MacroAssembler::store_heap_oop() when packing inline type
arguments in C1's scalarised entry point and that in turn uses the
interpreter's barrier set assembler for the write barrier.  With G1GC
this can call into the runtime on the slow path, but it doesn't preserve
the call-clobbered registers, which include the Java argument registers.

This was fixed on x86 in JDK-8242210 and JDK-8251398 but I missed that
when I updated the AArch64 port earlier in the year.  I haven't actually
seen any failures caused by this, but from looking at the generated
assembly it's certainly possible.

This patch saves only the argument registers, and only if Valhalla is
enabled (unlike x86 which saves all registers unconditionally).  There
are 32 caller-saved registers on AArch64 so I wanted to avoid generating
many additional store/load instructions.

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

Commit messages:
 - 8272566: [lworld] [AArch64] G1 write barrier slow path needs to save more registers

Changes: https://git.openjdk.java.net/valhalla/pull/534/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=534&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272566
  Stats: 44 lines in 2 files changed: 35 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/534.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/534/head:pull/534

PR: https://git.openjdk.java.net/valhalla/pull/534


From thartmann at openjdk.java.net  Wed Aug 18 08:38:39 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 18 Aug 2021 08:38:39 GMT
Subject: [lworld] RFR: 8272566: [lworld] [AArch64] G1 write barrier slow
 path needs to save more registers
In-Reply-To: <JrwzYiEUbPmaNSBs-bvDdXaYTgoN7I8LHdumscBgFVs=.a88ee6b1-f664-470d-b3aa-5c0fc89a3e17@github.com>
References: <JrwzYiEUbPmaNSBs-bvDdXaYTgoN7I8LHdumscBgFVs=.a88ee6b1-f664-470d-b3aa-5c0fc89a3e17@github.com>
Message-ID: <G9CXANbNSpg0u9sl0b5ai1jz6hsvENlq6jstA6Copvs=.f9e06ce8-99d8-4bb0-acf5-5c136f53defa@github.com>

On Wed, 18 Aug 2021 06:39:34 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> We call MacroAssembler::store_heap_oop() when packing inline type
> arguments in C1's scalarised entry point and that in turn uses the
> interpreter's barrier set assembler for the write barrier.  With G1GC
> this can call into the runtime on the slow path, but it doesn't preserve
> the call-clobbered registers, which include the Java argument registers.
> 
> This was fixed on x86 in JDK-8242210 and JDK-8251398 but I missed that
> when I updated the AArch64 port earlier in the year.  I haven't actually
> seen any failures caused by this, but from looking at the generated
> assembly it's certainly possible.
> 
> This patch saves only the argument registers, and only if Valhalla is
> enabled (unlike x86 which saves all registers unconditionally).  There
> are 32 caller-saved registers on AArch64 so I wanted to avoid generating
> many additional store/load instructions.

Looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/534


From ngasson at openjdk.java.net  Wed Aug 18 15:28:48 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 18 Aug 2021 15:28:48 GMT
Subject: [lworld] Integrated: 8272566: [lworld] [AArch64] G1 write barrier
 slow path needs to save more registers
In-Reply-To: <JrwzYiEUbPmaNSBs-bvDdXaYTgoN7I8LHdumscBgFVs=.a88ee6b1-f664-470d-b3aa-5c0fc89a3e17@github.com>
References: <JrwzYiEUbPmaNSBs-bvDdXaYTgoN7I8LHdumscBgFVs=.a88ee6b1-f664-470d-b3aa-5c0fc89a3e17@github.com>
Message-ID: <1df5sqH-88tX7f-PHmayn3fG6JuWAqjVfIDQwDp3V8c=.b2f8030b-cc1d-4f80-b24f-3bb6168fc110@github.com>

On Wed, 18 Aug 2021 06:39:34 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> We call MacroAssembler::store_heap_oop() when packing inline type
> arguments in C1's scalarised entry point and that in turn uses the
> interpreter's barrier set assembler for the write barrier.  With G1GC
> this can call into the runtime on the slow path, but it doesn't preserve
> the call-clobbered registers, which include the Java argument registers.
> 
> This was fixed on x86 in JDK-8242210 and JDK-8251398 but I missed that
> when I updated the AArch64 port earlier in the year.  I haven't actually
> seen any failures caused by this, but from looking at the generated
> assembly it's certainly possible.
> 
> This patch saves only the argument registers, and only if Valhalla is
> enabled (unlike x86 which saves all registers unconditionally).  There
> are 32 caller-saved registers on AArch64 so I wanted to avoid generating
> many additional store/load instructions.

This pull request has now been integrated.

Changeset: b0219dc8
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/b0219dc830456e44c1dece77c98661a72e80e8d9
Stats:     44 lines in 2 files changed: 35 ins; 0 del; 9 mod

8272566: [lworld] [AArch64] G1 write barrier slow path needs to save more registers

Reviewed-by: thartmann

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

PR: https://git.openjdk.java.net/valhalla/pull/534


From dsimms at openjdk.java.net  Thu Aug 19 09:10:57 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 19 Aug 2021 09:10:57 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <omJoDaygk_XOE0c4tgiYXr7voB8iulwvgawMXZWk_Pg=.e24001b5-7fb0-4841-9dd2-5e178c1ad638@github.com>

Merge tag 'jdk-18+11'
# Conflicts:
#	src/hotspot/share/classfile/javaClasses.inline.hpp
#	src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
#	src/hotspot/share/opto/macroArrayCopy.cpp
#	src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java

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

Commit messages:
 - Merge tag 'jdk-18+11' into lworld_merge_jdk_18_11
 - 8272573: Redundant unique_concrete_method_4 dependencies
 - 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon
 - 8272626: Avoid C-style array declarations in java.*
 - 8271276: C2: Wrong JVM state used for receiver null check
 - 8272567: [IR Framework] Make AbstractInfo.getRandom() static
 - 8269951: [macos] Focus not painted in JButton when  setBorderPainted(false) is invoked
 - 8272558: IR Test Framework README misses some flags
 - 8272398: Update DockerTestUtils.buildJdkDockerImage()
 - 8270835: regression after JDK-8261006
 - ... and 142 more: https://git.openjdk.java.net/valhalla/compare/b0219dc8...60ff8b64

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

Changes: https://git.openjdk.java.net/valhalla/pull/535/files
  Stats: 20617 lines in 750 files changed: 15764 ins; 2564 del; 2289 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/535.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/535/head:pull/535

PR: https://git.openjdk.java.net/valhalla/pull/535


From dsimms at openjdk.java.net  Thu Aug 19 09:54:16 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 19 Aug 2021 09:54:16 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <omJoDaygk_XOE0c4tgiYXr7voB8iulwvgawMXZWk_Pg=.e24001b5-7fb0-4841-9dd2-5e178c1ad638@github.com>
References: <omJoDaygk_XOE0c4tgiYXr7voB8iulwvgawMXZWk_Pg=.e24001b5-7fb0-4841-9dd2-5e178c1ad638@github.com>
Message-ID: <b_2QmUs55y-EGBbG78Nish6ZsCkInsig9WU-SgHdQJs=.01be4521-dfa6-446b-88ac-3f7bd9b48dd6@github.com>

On Thu, 19 Aug 2021 09:03:04 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-18+11'
> # Conflicts:
> #	src/hotspot/share/classfile/javaClasses.inline.hpp
> #	src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
> #	src/hotspot/share/opto/macroArrayCopy.cpp
> #	src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java

This pull request has now been integrated.

Changeset: 55f8d9eb
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/55f8d9eb5d182a9104e7d133d03f93b94cfd5b28
Stats:     20617 lines in 750 files changed: 15764 ins; 2564 del; 2289 mod

Merge jdk

Merge tag 'jdk-18+11'

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

PR: https://git.openjdk.java.net/valhalla/pull/535


From dsimms at openjdk.java.net  Thu Aug 19 09:54:13 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 19 Aug 2021 09:54:13 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <omJoDaygk_XOE0c4tgiYXr7voB8iulwvgawMXZWk_Pg=.e24001b5-7fb0-4841-9dd2-5e178c1ad638@github.com>
References: <omJoDaygk_XOE0c4tgiYXr7voB8iulwvgawMXZWk_Pg=.e24001b5-7fb0-4841-9dd2-5e178c1ad638@github.com>
Message-ID: <BGZkgTxrpBajKeboya6BJiFG7PGzs5uP1jv6ZyRfWDo=.cdae3f4b-6c3f-4cb1-aff5-46e2babdb023@github.com>

> Merge tag 'jdk-18+11'
> # Conflicts:
> #	src/hotspot/share/classfile/javaClasses.inline.hpp
> #	src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
> #	src/hotspot/share/opto/macroArrayCopy.cpp
> #	src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java

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

 - Merge tag 'jdk-18+11' into lworld_merge_jdk_18_11
   
   Added tag jdk-18+11 for changeset 96107e31
   
   # Conflicts:
   #	src/hotspot/share/classfile/javaClasses.inline.hpp
   #	src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
   #	src/hotspot/share/opto/macroArrayCopy.cpp
   #	src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java
 - 8272566: [lworld] [AArch64] G1 write barrier slow path needs to save more registers
   
   Reviewed-by: thartmann
 - 8272397: [lworld] Move ValueBootstrapMethods to java.lang.runtime
   
   Reviewed-by: fparain, rriggs
 - 8271556: [lworld] java.lang.BootstrapMethodError in .equals() for primitive record
   
   Reviewed-by: rriggs
 - 8272400: [lworld] serviceability/sa/CDSJMapClstats.java fails: No suitable match for type of address
   
   Reviewed-by: fparain
 - 8272511: [lworld] Disable PhaseIdealLoop::try_sink_out_of_loop until optimization is stable in mainline
 - 8272290: [lworld] Disable CDS if InlineTypePassFieldsAsArgs has changed
   
   Reviewed-by: mchung, fparain
 - 8272307: [lworld] [AArch64] TestCallingConventionC1 test63 and test64 get incorrect result
   
   Reviewed-by: thartmann
 - 8272041: [lworld] CDS heap dump fails with primitive objects
   
   Reviewed-by: fparain, mchung
 - 8271924: [lworld] Crashes in ZBarrierSetRuntime::load_barrier_on_oop_array
 - ... and 1231 more: https://git.openjdk.java.net/valhalla/compare/96107e31...60ff8b64

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

Changes: https://git.openjdk.java.net/valhalla/pull/535/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=535&range=01
  Stats: 154066 lines in 1504 files changed: 145921 ins; 1716 del; 6429 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/535.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/535/head:pull/535

PR: https://git.openjdk.java.net/valhalla/pull/535


From thartmann at openjdk.java.net  Fri Aug 20 11:02:06 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 20 Aug 2021 11:02:06 GMT
Subject: [lworld] RFR: 8272753: [lworld] "Invalid frame size" assert in
 frame::repair_sender_sp
Message-ID: <yAqDVBwx3AqRLPvxAbgP9IuJOm1mqYgJIN5Lq8kytWA=.f23df730-eb98-4e4f-8bb7-17ee1ce6daf0@github.com>

Verification code asserts during stack walking when trying to repair the stack of a C2 compiled method with scalarized arguments because the stack increment is invalid. The problem is that `C->output()->sp_inc_offset()` used by `MacroAssembler::verified_entry` does not account for alignment of the frame size and therefore points to the wrong slot. Like we already do in C1, we should simply hard code the slot to right below where `rbp` was saved.

This patch only fixes x86, I've filed [JDK-8272760](https://bugs.openjdk.java.net/browse/JDK-8272760) for Aarch64.

Thanks,
Tobias

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

Commit messages:
 - 8272753: [lworld] "Invalid frame size" assert in frame::repair_sender_sp

Changes: https://git.openjdk.java.net/valhalla/pull/536/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=536&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272753
  Stats: 70 lines in 5 files changed: 60 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/536.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/536/head:pull/536

PR: https://git.openjdk.java.net/valhalla/pull/536


From thartmann at openjdk.java.net  Fri Aug 20 12:51:49 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 20 Aug 2021 12:51:49 GMT
Subject: [lworld] Integrated: 8272753: [lworld] "Invalid frame size" assert in
 frame::repair_sender_sp
In-Reply-To: <yAqDVBwx3AqRLPvxAbgP9IuJOm1mqYgJIN5Lq8kytWA=.f23df730-eb98-4e4f-8bb7-17ee1ce6daf0@github.com>
References: <yAqDVBwx3AqRLPvxAbgP9IuJOm1mqYgJIN5Lq8kytWA=.f23df730-eb98-4e4f-8bb7-17ee1ce6daf0@github.com>
Message-ID: <AxPQdupNfSOQrCR1DYtQ2rFH298QGl5xsB5ZTRGy3EI=.d470a336-76a4-454d-9af7-b30888425792@github.com>

On Fri, 20 Aug 2021 10:56:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Verification code asserts during stack walking when trying to repair the stack of a C2 compiled method with scalarized arguments because the stack increment is invalid. The problem is that `C->output()->sp_inc_offset()` used by `MacroAssembler::verified_entry` does not account for alignment of the frame size and therefore points to the wrong slot. Like we already do in C1, we should simply hard code the slot to right below where `rbp` was saved.
> 
> This patch only fixes x86, I've filed [JDK-8272760](https://bugs.openjdk.java.net/browse/JDK-8272760) for Aarch64.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: aaa7401c
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/aaa7401c49e87f9790c2ebf21e72198b2dafcd9d
Stats:     70 lines in 5 files changed: 60 ins; 2 del; 8 mod

8272753: [lworld] "Invalid frame size" assert in frame::repair_sender_sp

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

PR: https://git.openjdk.java.net/valhalla/pull/536


From fparain at openjdk.java.net  Fri Aug 20 20:11:14 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 20 Aug 2021 20:11:14 GMT
Subject: [lworld] Integrated: 8272793: [lworld] Test CustomClassListDump.java
 fails with Pattern "CustomLoadee id: [0-9]+ super: [0-9]+ source:
 .*/custom.jar" not found in classlist
Message-ID: <rq24XjbythH9zO72jIK2n8DI0QSfzrkT4r_bBoYr9EY=.5cc30956-2e94-4206-a32d-ae2a8127e463@github.com>

Fixing test by taking into account the injected IdentityObject interface in patterns used to analyze the output.

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

Commit messages:
 - Fix test to handle injected IdentityObject interface

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

PR: https://git.openjdk.java.net/valhalla/pull/537


From fparain at openjdk.java.net  Fri Aug 20 20:11:15 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 20 Aug 2021 20:11:15 GMT
Subject: [lworld] Integrated: 8272793: [lworld] Test CustomClassListDump.java
 fails with Pattern "CustomLoadee id: [0-9]+ super: [0-9]+ source:
 .*/custom.jar" not found in classlist
In-Reply-To: <rq24XjbythH9zO72jIK2n8DI0QSfzrkT4r_bBoYr9EY=.5cc30956-2e94-4206-a32d-ae2a8127e463@github.com>
References: <rq24XjbythH9zO72jIK2n8DI0QSfzrkT4r_bBoYr9EY=.5cc30956-2e94-4206-a32d-ae2a8127e463@github.com>
Message-ID: <-fF9Rvjl75p4blNm6Sq4fnRwLGlqIXzjPzvFerUXlp8=.fc1e9ec6-9548-4626-ab64-e6f5c9945b64@github.com>

On Fri, 20 Aug 2021 20:01:51 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fixing test by taking into account the injected IdentityObject interface in patterns used to analyze the output.

This pull request has now been integrated.

Changeset: 75537937
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/7553793769d50844a89b1607c623435f5a713944
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8272793: [lworld] Test CustomClassListDump.java fails with Pattern "CustomLoadee id: [0-9]+ super: [0-9]+ source: .*/custom.jar" not found in classlist

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

PR: https://git.openjdk.java.net/valhalla/pull/537


From iklam at openjdk.java.net  Mon Aug 23 06:02:22 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 23 Aug 2021 06:02:22 GMT
Subject: [lworld] RFR: 8272306: [lworld] Fix incorrectly merged code in
 classListParser.cpp
Message-ID: <BketuPuR6IXhmXGBI1FtQc8PRjKE9_kkfUCjylEv2wc=.6e33d436-9ed2-4594-9d2c-824b141f9fe8@github.com>

Please review this simple fix (and small clean up) for incorrectly merged code in classListParser.cpp.

This following shows the difference between valhalla and the JDK mainline after this PR:


$ wget https://raw.githubusercontent.com/iklam/valhalla/4da52eaf53e531e96e1e6eac460d6209916d6f2f/src/hotspot/share/cds/classListParser.cpp
$ wget https://raw.githubusercontent.com/iklam/valhalla/a977e73076022958f9da874d029b1bfdba92f7af/src/hotspot/share/cds/classListParser.cpp
$ diff classListParser.cpp classListParser.cpp.1

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

Commit messages:
 - 8272306: [lworld] Fix incorrectly merged code in classListParser.cpp

Changes: https://git.openjdk.java.net/valhalla/pull/538/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=538&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272306
  Stats: 29 lines in 1 file changed: 3 ins; 14 del; 12 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/538.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/538/head:pull/538

PR: https://git.openjdk.java.net/valhalla/pull/538


From sadayapalam at openjdk.java.net  Mon Aug 23 08:44:00 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 23 Aug 2021 08:44:00 GMT
Subject: [lworld] RFR: 8271583: [lworld] primitive records can't be
 reference favoring
In-Reply-To: <N2zYZpkR_Ypuf0f-Ciqlx0Q-bEzZb0U1FU92SZa6VMI=.6dff239f-2c01-4897-b72c-9f4fe2035109@github.com>
References: <N2zYZpkR_Ypuf0f-Ciqlx0Q-bEzZb0U1FU92SZa6VMI=.6dff239f-2c01-4897-b72c-9f4fe2035109@github.com>
Message-ID: <w9oD-wfRk26jdA4W8typoZsqH0OWIxYrGJM9euWcjfc=.42b80be6-3855-4d36-9ea2-d71a597583a3@github.com>

On Tue, 17 Aug 2021 23:49:41 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> This patch lets the compiler pick up a record which can be primitive records and reference favoring, such as
> 
> primitive record Point.val(int x, int y) {}
> 
> 
> The lowering had to be adjusted so that the correct receiver type is generated.
> 
> See https://bugs.openjdk.java.net/browse/JDK-8271583

Other than the test changes requested, this looks good.

test/langtools/tools/javac/valhalla/lworld-values/records/RefFlavoredRecord.java line 30:

> 28:  * @compile -XDallowWithFieldOperator RefFlavoredRecord.java
> 29:  * @run main/othervm RefFlavoredRecord
> 30:  */

I think this test should not require XDallowWithFieldOperator and also likely "othervm" in the run tag.

And you should also be able to condense the @compile and @run into just @run ??

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

Marked as reviewed by sadayapalam (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/533


From sadayapalam at openjdk.java.net  Mon Aug 23 08:51:59 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 23 Aug 2021 08:51:59 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v5]
In-Reply-To: <I5U6lONHR354nDNcsjxW5VxClaHY1tal7N9sk6cb5-8=.05ff7f61-bfc5-424e-a44e-7e02399eb0be@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
 <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>
 <I5U6lONHR354nDNcsjxW5VxClaHY1tal7N9sk6cb5-8=.05ff7f61-bfc5-424e-a44e-7e02399eb0be@github.com>
Message-ID: <bic9OsMIJarvLhrNrBThabmLLe8Tdzmu2TPpICTyZ_8=.7a1daf8b-4b22-4fc1-a1e2-914b76594454@github.com>

On Tue, 3 Aug 2021 09:34:48 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace
>
> Hi Jesper, I have left some comments - but I will need to make a couple of more passes to fully understand the implementation as this is a fairly involved and complex task. I will actually have to tinker with the version you have posted to comprehend it - Could you give me some time - I will play around with it and propose a version that addresses the problems I have outlined and also includes further tweaks that could simplify the implementation more ? Then we can study it, finalize it and then ask Maurizio for a final review once both of us are satisfied.

> @sadayapalam : I can take another go at this one to adress the review comments above, which may make a second review pass easier.

Sure, this is recognized to be a tricky area, so it is normal to have iterate over it multiple times incrementally improving it. As long as this is had in mind, by all means it helps to have the comments made so far addressed. Thanks!

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

PR: https://git.openjdk.java.net/valhalla/pull/369


From dsimms at openjdk.java.net  Mon Aug 23 12:20:57 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 23 Aug 2021 12:20:57 GMT
Subject: [lworld] RFR: 8272306: [lworld] Fix incorrectly merged code in
 classListParser.cpp
In-Reply-To: <BketuPuR6IXhmXGBI1FtQc8PRjKE9_kkfUCjylEv2wc=.6e33d436-9ed2-4594-9d2c-824b141f9fe8@github.com>
References: <BketuPuR6IXhmXGBI1FtQc8PRjKE9_kkfUCjylEv2wc=.6e33d436-9ed2-4594-9d2c-824b141f9fe8@github.com>
Message-ID: <4CR1ERn6c8hKOMWygckiJhMbEtFpf_nJrzkaxnZ30zM=.f5f26627-c948-49df-9b67-e89debb09779@github.com>

On Mon, 23 Aug 2021 05:55:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this simple fix (and small clean up) for incorrectly merged code in classListParser.cpp.
> 
> This following shows the difference between valhalla and the JDK mainline after this PR:
> 
> 
> $ wget https://raw.githubusercontent.com/iklam/valhalla/4da52eaf53e531e96e1e6eac460d6209916d6f2f/src/hotspot/share/cds/classListParser.cpp
> $ wget https://raw.githubusercontent.com/iklam/valhalla/a977e73076022958f9da874d029b1bfdba92f7af/src/hotspot/share/cds/classListParser.cpp
> $ diff classListParser.cpp classListParser.cpp.1

Thanks Ioi, this would be my mess you cleaned up here, much appreciated. Changes look good

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

Marked as reviewed by dsimms (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/538


From iklam at openjdk.java.net  Mon Aug 23 21:09:02 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 23 Aug 2021 21:09:02 GMT
Subject: git: openjdk/valhalla: lworld: 8272306: [lworld] Fix incorrectly
 merged code in classListParser.cpp
Message-ID: <635e19c6-c499-4d71-bd3a-ba121c528b07@openjdk.org>

Changeset: dd0a9ebe
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2021-08-23 21:08:38 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/dd0a9ebed9b42b6649f628a6c9b63dac28ffc876

8272306: [lworld] Fix incorrectly merged code in classListParser.cpp

Reviewed-by: dsimms

! src/hotspot/share/cds/classListParser.cpp



From iklam at openjdk.java.net  Mon Aug 23 21:12:00 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 23 Aug 2021 21:12:00 GMT
Subject: [lworld] Integrated: 8272306: [lworld] Fix incorrectly merged code in
 classListParser.cpp
In-Reply-To: <BketuPuR6IXhmXGBI1FtQc8PRjKE9_kkfUCjylEv2wc=.6e33d436-9ed2-4594-9d2c-824b141f9fe8@github.com>
References: <BketuPuR6IXhmXGBI1FtQc8PRjKE9_kkfUCjylEv2wc=.6e33d436-9ed2-4594-9d2c-824b141f9fe8@github.com>
Message-ID: <ttpooVZcw8qTNIG9dpZ1meEix2sFAY_r-Yi38AlnQqQ=.eca450ac-8984-43ee-a382-6f41b709ba6b@github.com>

On Mon, 23 Aug 2021 05:55:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this simple fix (and small clean up) for incorrectly merged code in classListParser.cpp.
> 
> This following shows the difference between valhalla and the JDK mainline after this PR:
> 
> 
> $ wget https://raw.githubusercontent.com/iklam/valhalla/4da52eaf53e531e96e1e6eac460d6209916d6f2f/src/hotspot/share/cds/classListParser.cpp
> $ wget https://raw.githubusercontent.com/iklam/valhalla/a977e73076022958f9da874d029b1bfdba92f7af/src/hotspot/share/cds/classListParser.cpp
> $ diff classListParser.cpp classListParser.cpp.1

This pull request has now been integrated.

Changeset: dd0a9ebe
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/dd0a9ebed9b42b6649f628a6c9b63dac28ffc876
Stats:     29 lines in 1 file changed: 3 ins; 14 del; 12 mod

8272306: [lworld] Fix incorrectly merged code in classListParser.cpp

Reviewed-by: dsimms

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

PR: https://git.openjdk.java.net/valhalla/pull/538


From iklam at openjdk.java.net  Mon Aug 23 21:11:59 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 23 Aug 2021 21:11:59 GMT
Subject: [lworld] RFR: 8272306: [lworld] Fix incorrectly merged code in
 classListParser.cpp
In-Reply-To: <4CR1ERn6c8hKOMWygckiJhMbEtFpf_nJrzkaxnZ30zM=.f5f26627-c948-49df-9b67-e89debb09779@github.com>
References: <BketuPuR6IXhmXGBI1FtQc8PRjKE9_kkfUCjylEv2wc=.6e33d436-9ed2-4594-9d2c-824b141f9fe8@github.com>
 <4CR1ERn6c8hKOMWygckiJhMbEtFpf_nJrzkaxnZ30zM=.f5f26627-c948-49df-9b67-e89debb09779@github.com>
Message-ID: <6jaoO8BeCypmIDrUeFrfEvgb1GQ22UFYpGu1ofOqPlw=.6d4864c1-39e7-47f0-8fef-29afad5494d9@github.com>

On Mon, 23 Aug 2021 12:18:10 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Please review this simple fix (and small clean up) for incorrectly merged code in classListParser.cpp.
>> 
>> This following shows the difference between valhalla and the JDK mainline after this PR:
>> 
>> 
>> $ wget https://raw.githubusercontent.com/iklam/valhalla/4da52eaf53e531e96e1e6eac460d6209916d6f2f/src/hotspot/share/cds/classListParser.cpp
>> $ wget https://raw.githubusercontent.com/iklam/valhalla/a977e73076022958f9da874d029b1bfdba92f7af/src/hotspot/share/cds/classListParser.cpp
>> $ diff classListParser.cpp classListParser.cpp.1
>
> Thanks Ioi, this would be my mess you cleaned up here, much appreciated. Changes look good

@MrSimms thanks for the review.

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

PR: https://git.openjdk.java.net/valhalla/pull/538


From jespersm at openjdk.java.net  Mon Aug 23 22:17:18 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Mon, 23 Aug 2021 22:17:18 GMT
Subject: [lworld] RFR: 8271583: [lworld] primitive records can't be
 reference favoring [v2]
In-Reply-To: <N2zYZpkR_Ypuf0f-Ciqlx0Q-bEzZb0U1FU92SZa6VMI=.6dff239f-2c01-4897-b72c-9f4fe2035109@github.com>
References: <N2zYZpkR_Ypuf0f-Ciqlx0Q-bEzZb0U1FU92SZa6VMI=.6dff239f-2c01-4897-b72c-9f4fe2035109@github.com>
Message-ID: <eczZAAo-IfuU86fM2eg5RC4dKye7J1gQIrda8Uq1HeE=.ff7ab2eb-8c7c-49e3-aea6-2cb902ea75d7@github.com>

> This patch lets the compiler pick up a record which can be primitive records and reference favoring, such as
> 
> primitive record Point.val(int x, int y) {}
> 
> 
> The lowering had to be adjusted so that the correct receiver type is generated.
> 
> See https://bugs.openjdk.java.net/browse/JDK-8271583

Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:

  Removed unnecessary @compile test tag

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/533/files
  - new: https://git.openjdk.java.net/valhalla/pull/533/files/d9f744b0..c0ce2552

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=533&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=533&range=00-01

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

PR: https://git.openjdk.java.net/valhalla/pull/533


From jespersm at openjdk.java.net  Mon Aug 23 22:53:53 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Mon, 23 Aug 2021 22:53:53 GMT
Subject: [lworld] RFR: 8271583: [lworld] primitive records can't be
 reference favoring [v2]
In-Reply-To: <eczZAAo-IfuU86fM2eg5RC4dKye7J1gQIrda8Uq1HeE=.ff7ab2eb-8c7c-49e3-aea6-2cb902ea75d7@github.com>
References: <N2zYZpkR_Ypuf0f-Ciqlx0Q-bEzZb0U1FU92SZa6VMI=.6dff239f-2c01-4897-b72c-9f4fe2035109@github.com>
 <eczZAAo-IfuU86fM2eg5RC4dKye7J1gQIrda8Uq1HeE=.ff7ab2eb-8c7c-49e3-aea6-2cb902ea75d7@github.com>
Message-ID: <McfRv2qNc6ZthsxznwVXrjOeiqIWYHCUSDpIIRpHB10=.66a24cd2-fdfa-48a0-980f-6964bcbfbe53@github.com>

On Mon, 23 Aug 2021 22:17:18 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> This patch lets the compiler pick up a record which can be primitive records and reference favoring, such as
>> 
>> primitive record Point.val(int x, int y) {}
>> 
>> 
>> The lowering had to be adjusted so that the correct receiver type is generated.
>> 
>> See https://bugs.openjdk.java.net/browse/JDK-8271583
>
> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary @compile test tag

I fixed the unneeded @compile line, but I'm not sure about changing the main/othervm. Most tests in Valhalla use 'main/othervm', but perhaps that's just coincidence, or a misunderstanding that's been copy/paste's around?

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

PR: https://git.openjdk.java.net/valhalla/pull/533


From sadayapalam at openjdk.java.net  Tue Aug 24 04:50:55 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 24 Aug 2021 04:50:55 GMT
Subject: [lworld] RFR: 8271583: [lworld] primitive records can't be
 reference favoring [v2]
In-Reply-To: <McfRv2qNc6ZthsxznwVXrjOeiqIWYHCUSDpIIRpHB10=.66a24cd2-fdfa-48a0-980f-6964bcbfbe53@github.com>
References: <N2zYZpkR_Ypuf0f-Ciqlx0Q-bEzZb0U1FU92SZa6VMI=.6dff239f-2c01-4897-b72c-9f4fe2035109@github.com>
 <eczZAAo-IfuU86fM2eg5RC4dKye7J1gQIrda8Uq1HeE=.ff7ab2eb-8c7c-49e3-aea6-2cb902ea75d7@github.com>
 <McfRv2qNc6ZthsxznwVXrjOeiqIWYHCUSDpIIRpHB10=.66a24cd2-fdfa-48a0-980f-6964bcbfbe53@github.com>
Message-ID: <t2XnLxZ06QwAnc_d5BNvUN6GDgZhYucbXYGqcEvYm1k=.ef720d06-1cb9-4102-8587-a01b92f31351@github.com>

On Mon, 23 Aug 2021 22:50:54 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> I fixed the unneeded @compile line, but I'm not sure about changing the main/othervm. Most tests in Valhalla use 'main/othervm', but perhaps that's just coincidence, or a misunderstanding that's been copy/paste's around?

As per jtreg tag spec:

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

PR: https://git.openjdk.java.net/valhalla/pull/533


From jespersm at openjdk.java.net  Tue Aug 24 04:50:58 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Tue, 24 Aug 2021 04:50:58 GMT
Subject: [lworld] Integrated: 8271583: [lworld] primitive records can't be
 reference favoring
In-Reply-To: <N2zYZpkR_Ypuf0f-Ciqlx0Q-bEzZb0U1FU92SZa6VMI=.6dff239f-2c01-4897-b72c-9f4fe2035109@github.com>
References: <N2zYZpkR_Ypuf0f-Ciqlx0Q-bEzZb0U1FU92SZa6VMI=.6dff239f-2c01-4897-b72c-9f4fe2035109@github.com>
Message-ID: <puf9_f33ylD31AzJ_9UVpp0g3M1ZE3GbD43MM3G9UWg=.824966ea-fc45-498c-a152-24807ee07f4d@github.com>

On Tue, 17 Aug 2021 23:49:41 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> This patch lets the compiler pick up a record which can be primitive records and reference favoring, such as
> 
> primitive record Point.val(int x, int y) {}
> 
> 
> The lowering had to be adjusted so that the correct receiver type is generated.
> 
> See https://bugs.openjdk.java.net/browse/JDK-8271583

This pull request has now been integrated.

Changeset: a74a1cee
Author:    Jesper Steen M?ller <jespersm at openjdk.org>
Committer: Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a74a1ceeff957e3832f9104790aee9f566c15dad
Stats:     56 lines in 3 files changed: 54 ins; 0 del; 2 mod

8271583: [lworld] primitive records can't be reference favoring

Reviewed-by: sadayapalam

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

PR: https://git.openjdk.java.net/valhalla/pull/533


From ngasson at openjdk.java.net  Tue Aug 24 09:34:50 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 24 Aug 2021 09:34:50 GMT
Subject: [lworld] RFR: 8272760: [lworld] Aarch64 part of JDK-8272753
Message-ID: <tHHwfLiR8nJYNtzRY_lvt7b5ykHR89QfHn2uwlPxi4I=.ed254d17-3b60-403c-8221-bfee1e9cd0cc@github.com>

Remove the explicit sp_inc_offset argument to build/remove frame functions to match x86: it's always the word beneath the saved FP.

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

Commit messages:
 - 8272760: [lworld] Aarch64 part of JDK-8272753

Changes: https://git.openjdk.java.net/valhalla/pull/539/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=539&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272760
  Stats: 32 lines in 8 files changed: 4 ins; 19 del; 9 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/539.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/539/head:pull/539

PR: https://git.openjdk.java.net/valhalla/pull/539


From thartmann at openjdk.java.net  Wed Aug 25 08:14:49 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 25 Aug 2021 08:14:49 GMT
Subject: [lworld] RFR: 8272760: [lworld] Aarch64 part of JDK-8272753
In-Reply-To: <tHHwfLiR8nJYNtzRY_lvt7b5ykHR89QfHn2uwlPxi4I=.ed254d17-3b60-403c-8221-bfee1e9cd0cc@github.com>
References: <tHHwfLiR8nJYNtzRY_lvt7b5ykHR89QfHn2uwlPxi4I=.ed254d17-3b60-403c-8221-bfee1e9cd0cc@github.com>
Message-ID: <3nVZmWyzP_QTcGpUNMe-424wV-ZHANRVtEAa6z_dJuU=.e196aada-6026-4b86-811d-0742835c1591@github.com>

On Tue, 24 Aug 2021 09:29:17 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Remove the explicit sp_inc_offset argument to build/remove frame functions to match x86: it's always the word beneath the saved FP.

Looks good to me. Thanks for fixing!

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

Marked as reviewed by thartmann (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/539


From ngasson at openjdk.java.net  Wed Aug 25 08:50:55 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 25 Aug 2021 08:50:55 GMT
Subject: [lworld] Integrated: 8272760: [lworld] Aarch64 part of JDK-8272753
In-Reply-To: <tHHwfLiR8nJYNtzRY_lvt7b5ykHR89QfHn2uwlPxi4I=.ed254d17-3b60-403c-8221-bfee1e9cd0cc@github.com>
References: <tHHwfLiR8nJYNtzRY_lvt7b5ykHR89QfHn2uwlPxi4I=.ed254d17-3b60-403c-8221-bfee1e9cd0cc@github.com>
Message-ID: <KbFomr5pmkKVfiPadjY1zdsrxqTFu2M2zCD_0AQGEEQ=.f455684c-b4df-4864-8569-9571c4eab026@github.com>

On Tue, 24 Aug 2021 09:29:17 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Remove the explicit sp_inc_offset argument to build/remove frame functions to match x86: it's always the word beneath the saved FP.

This pull request has now been integrated.

Changeset: 0bfc6205
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/0bfc6205480c52ca8edff01ef6e3483857aee349
Stats:     32 lines in 8 files changed: 4 ins; 19 del; 9 mod

8272760: [lworld] Aarch64 part of JDK-8272753

Reviewed-by: thartmann

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

PR: https://git.openjdk.java.net/valhalla/pull/539


From dsimms at openjdk.java.net  Thu Aug 26 08:45:48 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 26 Aug 2021 08:45:48 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <f4Hzl4Q_h2mlNvTM_ecchGo3BkX2g1f9CAJ2Ay8vG1U=.d72beb44-1c99-4e13-9f36-f0f7e98d70a2@github.com>

Merge tag 'jdk-18+12'

# Conflicts:
#	src/hotspot/share/gc/shared/barrierSet.hpp
#	src/hotspot/share/oops/access.hpp
#	src/hotspot/share/oops/access.inline.hpp
#	src/hotspot/share/oops/accessBackend.hpp
#	src/hotspot/share/oops/markWord.hpp

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

Commit messages:
 - Merge tag 'jdk-18+12' into lworld_merge_jdk_18_12
 - 8272447: Remove 'native' ranked Mutex
 - 8236176: Parallel GC SplitInfo comment should be updated for shadow regions
 - 8272850: Drop zapping values in the Zap* option descriptions
 - 8272884: Make VoidClosure::do_void pure virtual
 - 8272570: C2: crash in PhaseCFG::global_code_motion
 - 8272639: jpackaged applications using microphone on mac
 - 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions
 - 8272856: DoubleFlagWithIntegerValue uses G1GC-only flag
 - 8272916: Copyright year was modified unintentionally in jlink.properties and ImagePluginStack.java
 - ... and 48 more: https://git.openjdk.java.net/valhalla/compare/0bfc6205...17d46414

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

Changes: https://git.openjdk.java.net/valhalla/pull/540/files
  Stats: 5897 lines in 214 files changed: 4151 ins; 1028 del; 718 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/540.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/540/head:pull/540

PR: https://git.openjdk.java.net/valhalla/pull/540


From dsimms at openjdk.java.net  Thu Aug 26 10:04:18 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 26 Aug 2021 10:04:18 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <f4Hzl4Q_h2mlNvTM_ecchGo3BkX2g1f9CAJ2Ay8vG1U=.d72beb44-1c99-4e13-9f36-f0f7e98d70a2@github.com>
References: <f4Hzl4Q_h2mlNvTM_ecchGo3BkX2g1f9CAJ2Ay8vG1U=.d72beb44-1c99-4e13-9f36-f0f7e98d70a2@github.com>
Message-ID: <FlbJW6sjCkoVi37UB6m4KpekRcAEXsNWL5YuYqfSEZQ=.9362bf1e-5b45-42fd-9d21-3a3e53e4618f@github.com>

> Merge tag 'jdk-18+12'
> 
> # Conflicts:
> #	src/hotspot/share/gc/shared/barrierSet.hpp
> #	src/hotspot/share/oops/access.hpp
> #	src/hotspot/share/oops/access.inline.hpp
> #	src/hotspot/share/oops/accessBackend.hpp
> #	src/hotspot/share/oops/markWord.hpp

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

 - Merge tag 'jdk-18+12' into lworld_merge_jdk_18_12
   
   Added tag jdk-18+12 for changeset 2ef68711
   
   # Conflicts:
   #	src/hotspot/share/gc/shared/barrierSet.hpp
   #	src/hotspot/share/oops/access.hpp
   #	src/hotspot/share/oops/access.inline.hpp
   #	src/hotspot/share/oops/accessBackend.hpp
   #	src/hotspot/share/oops/markWord.hpp
 - 8272760: [lworld] Aarch64 part of JDK-8272753
   
   Reviewed-by: thartmann
 - 8271583: [lworld] primitive records can't be reference favoring
   
   Reviewed-by: sadayapalam
 - 8272306: [lworld] Fix incorrectly merged code in classListParser.cpp
   
   Reviewed-by: dsimms
 - 8272793: [lworld] Test CustomClassListDump.java fails with Pattern "CustomLoadee id: [0-9]+ super: [0-9]+ source: .*/custom.jar" not found in classlist
 - 8272753: [lworld] "Invalid frame size" assert in frame::repair_sender_sp
 - Merge jdk
   
   Merge tag 'jdk-18+11'
 - 8272566: [lworld] [AArch64] G1 write barrier slow path needs to save more registers
   
   Reviewed-by: thartmann
 - 8272397: [lworld] Move ValueBootstrapMethods to java.lang.runtime
   
   Reviewed-by: fparain, rriggs
 - 8271556: [lworld] java.lang.BootstrapMethodError in .equals() for primitive record
   
   Reviewed-by: rriggs
 - ... and 1237 more: https://git.openjdk.java.net/valhalla/compare/2ef68711...17d46414

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

Changes: https://git.openjdk.java.net/valhalla/pull/540/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=540&range=01
  Stats: 154159 lines in 1505 files changed: 146009 ins; 1717 del; 6433 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/540.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/540/head:pull/540

PR: https://git.openjdk.java.net/valhalla/pull/540


From dsimms at openjdk.java.net  Thu Aug 26 10:04:20 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 26 Aug 2021 10:04:20 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <f4Hzl4Q_h2mlNvTM_ecchGo3BkX2g1f9CAJ2Ay8vG1U=.d72beb44-1c99-4e13-9f36-f0f7e98d70a2@github.com>
References: <f4Hzl4Q_h2mlNvTM_ecchGo3BkX2g1f9CAJ2Ay8vG1U=.d72beb44-1c99-4e13-9f36-f0f7e98d70a2@github.com>
Message-ID: <PF63ja8ijxFh73Z-gVuAJr-ZPyWQ5e8PLZP_hC-aFI4=.eee1d3ba-a7ce-4135-a205-21dbea9acacb@github.com>

On Thu, 26 Aug 2021 08:38:44 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-18+12'
> 
> # Conflicts:
> #	src/hotspot/share/gc/shared/barrierSet.hpp
> #	src/hotspot/share/oops/access.hpp
> #	src/hotspot/share/oops/access.inline.hpp
> #	src/hotspot/share/oops/accessBackend.hpp
> #	src/hotspot/share/oops/markWord.hpp

This pull request has now been integrated.

Changeset: 994f6cfe
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/994f6cfe5a81873adc13c52cabc335da42647d5d
Stats:     5897 lines in 214 files changed: 4151 ins; 1028 del; 718 mod

Merge jdk

Merge tag 'jdk-18+12'

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

PR: https://git.openjdk.java.net/valhalla/pull/540


From nlisker at gmail.com  Tue Aug 31 01:45:06 2021
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 31 Aug 2021 04:45:06 +0300
Subject: Specialized primitive implementations after generics specialization
Message-ID: <CA+0ynh9p_YkuPf=922dx+JfJdd0xF0sfBYqsnh7RMZRhnLD45Q@mail.gmail.com>

Hi,

I have a question(s) about the need for primitive specialized
implementations when type parameters will accept primitives.
Today we need various specializations like IntFunction and IntStream.
However, the difference between them is that IntStream brings with it
methods that make sense on int, like sum(), while IntFunction does not.
Does this mean that some specializations will still be needed, or will
there be another way of doing it?
(I'm not advocating to do anything with IntFunction or IntStream, just
using them as examples.)

- Nir


From john.r.rose at oracle.com  Tue Aug 31 02:26:42 2021
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 31 Aug 2021 02:26:42 +0000
Subject: Specialized primitive implementations after generics
 specialization
In-Reply-To: <CA+0ynh9p_YkuPf=922dx+JfJdd0xF0sfBYqsnh7RMZRhnLD45Q@mail.gmail.com>
References: <CA+0ynh9p_YkuPf=922dx+JfJdd0xF0sfBYqsnh7RMZRhnLD45Q@mail.gmail.com>
Message-ID: <CD8B31CF-BBB2-4DF8-82F2-85D1BDF4D7CF@oracle.com>

We expect to upgrade the existing generics so that the
JVM can access enough information about types to
perform various customizations.  The details are hazy,
but we fully expect to be able to supply ad hoc methods
like sum.  Maybe even ad hoc protocols like Summable,
if we are lucky.  Hopefully also ad hoc fields, like an
?Optional::isPresent? field that is elided (typed as ?void?
or some other unit or empty type) when the isPresent
logic can be derived from the main field of the Optional,
as today.

The basic insight here is that, if there is enough runtime
information to guide the customization of data structures
(as today?s primitive arrays and fields have layouts
customized to the primitives), then there is also enough
runtime information to perform the coordinated task
of customizing algorithms (think Arrays.sort, on flat
monomorphic inputs).

Then, given those two firm requirements, the JVM
surely also has enough information to drive the creation
of optional methods, especially if (as we hope) the
optional methods can be modeled as always-present
but sometimes-degenerate methods.

To take your example, List<X>::sum would do what
you want if X has a ?summable? type.  (Where the
condition of ?summability? is encoded by a type bound
or perhaps a type class; details to be worked out.)

Meanwhile, if X has some other random type, then
List::sum would still link but throw a suitable error
when called.  (The static compiler javac might report
a static error when it can prove that this is bound to
happen, for some static type X.)

This scheme, of degenerate methods and fields, plays
well with raw types and wildcards, where the decision
to throw that error would depend on the type of the
receiver object.

For our current thought on how to rewire the JVM
to pass around sufficient information about generics,
please see the Parametric VM manifesto:

https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/parametric-vm/parametric-vm.md

HTH

? John

On Aug 30, 2021, at 6:45 PM, Nir Lisker <nlisker at gmail.com> wrote:
> 
> Hi,
> 
> I have a question(s) about the need for primitive specialized
> implementations when type parameters will accept primitives.
> Today we need various specializations like IntFunction and IntStream.
> However, the difference between them is that IntStream brings with it
> methods that make sense on int, like sum(), while IntFunction does not.
> Does this mean that some specializations will still be needed, or will
> there be another way of doing it?
> (I'm not advocating to do anything with IntFunction or IntStream, just
> using them as examples.)
> 
> - Nir


From brian.goetz at oracle.com  Tue Aug 31 14:26:06 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 31 Aug 2021 10:26:06 -0400
Subject: Specialized primitive implementations after generics
 specialization
In-Reply-To: <CD8B31CF-BBB2-4DF8-82F2-85D1BDF4D7CF@oracle.com>
References: <CA+0ynh9p_YkuPf=922dx+JfJdd0xF0sfBYqsnh7RMZRhnLD45Q@mail.gmail.com>
 <CD8B31CF-BBB2-4DF8-82F2-85D1BDF4D7CF@oracle.com>
Message-ID: <67d3254a-e42f-f77c-a982-512f2bc344f5@oracle.com>

We surely would like for all the hand-specifications to retreat to the 
dustbin of past expediences.? For some, we can fairly easily coopt them 
by retroactively giving them supertypes:

 ??? interface IntPredicate extends Predicate<int> { }

 ??? interface Predicate<T> extends Function<T, boolean> {
 ??????? boolean apply(T t) { return test(t); }
 ??? }

and guiding future usage towards the more general `Function` type.

For others, like IntStream, we're not going to be able to make IntStream 
extends Stream<int> (try it, you'll run into the fact that the dual of 
covariant overrides is not present) but we can eventually deprecate 
IntStream in favor of Stream<int> (the "cut off the head of the snake" 
strategy.)? As you suggest, this leaves the question of what to do with 
methods that are not total (e.g., sum(), max(), sorted()), but this is 
merely an extension of a more general need to express behavior that is 
conditioned on the properties of a particular type parameter. Stream is 
not special here; if the elements of a List are "comparable", it would 
be nice if List had a sort() method, etc.

In Haskell, we'd express this as follows:

 ??? Ord t => sort :: List t -> List t

which says roughly "given the precondition that t is orderable, List 
supports a sort operation".? We almost have something like that today: 
generic type bounds.? But we don't yet have the ability to express 
something like:

 ??? <where T has Comparator<T>>
 ??? void sort()

which would constrain the sort() method on List to instantiations where 
the type parameter can provide a witness to ordering.? This requires a 
lot of things to pull off, including the ability to associate behaviors 
with types, not just instances (e.g., something more like type classes), 
and either specialization (so that the witness to `Ord t` can be derived 
from `t`) or something like Scala's implicits to access the witness at 
runtime, etc.

Rest assured we're exploring these areas as well, since they are 
essential to creating expressive libraries.? (But, let's not discuss it 
further here; let's wait for a more complete story first.)



On 8/30/2021 10:26 PM, John Rose wrote:
> We expect to upgrade the existing generics so that the
> JVM can access enough information about types to
> perform various customizations.  The details are hazy,
> but we fully expect to be able to supply ad hoc methods
> like sum.  Maybe even ad hoc protocols like Summable,
> if we are lucky.  Hopefully also ad hoc fields, like an
> ?Optional::isPresent? field that is elided (typed as ?void?
> or some other unit or empty type) when the isPresent
> logic can be derived from the main field of the Optional,
> as today.
>
> The basic insight here is that, if there is enough runtime
> information to guide the customization of data structures
> (as today?s primitive arrays and fields have layouts
> customized to the primitives), then there is also enough
> runtime information to perform the coordinated task
> of customizing algorithms (think Arrays.sort, on flat
> monomorphic inputs).
>
> Then, given those two firm requirements, the JVM
> surely also has enough information to drive the creation
> of optional methods, especially if (as we hope) the
> optional methods can be modeled as always-present
> but sometimes-degenerate methods.
>
> To take your example, List<X>::sum would do what
> you want if X has a ?summable? type.  (Where the
> condition of ?summability? is encoded by a type bound
> or perhaps a type class; details to be worked out.)
>
> Meanwhile, if X has some other random type, then
> List::sum would still link but throw a suitable error
> when called.  (The static compiler javac might report
> a static error when it can prove that this is bound to
> happen, for some static type X.)
>
> This scheme, of degenerate methods and fields, plays
> well with raw types and wildcards, where the decision
> to throw that error would depend on the type of the
> receiver object.
>
> For our current thought on how to rewire the JVM
> to pass around sufficient information about generics,
> please see the Parametric VM manifesto:
>
> https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/parametric-vm/parametric-vm.md
>
> HTH
>
> ? John
>
> On Aug 30, 2021, at 6:45 PM, Nir Lisker <nlisker at gmail.com> wrote:
>> Hi,
>>
>> I have a question(s) about the need for primitive specialized
>> implementations when type parameters will accept primitives.
>> Today we need various specializations like IntFunction and IntStream.
>> However, the difference between them is that IntStream brings with it
>> methods that make sense on int, like sum(), while IntFunction does not.
>> Does this mean that some specializations will still be needed, or will
>> there be another way of doing it?
>> (I'm not advocating to do anything with IntFunction or IntStream, just
>> using them as examples.)
>>
>> - Nir



From jespersm at openjdk.java.net  Tue Aug 31 21:17:42 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Tue, 31 Aug 2021 21:17:42 GMT
Subject: [lworld] RFR: 8273018: Emit parameter annotations on primitive record
 factories
Message-ID: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>

This fix copies parameter names and annotations from constructor into primitive class factory.

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

Commit messages:
 - 8273018: Emit parameter annotations on primitive record factories

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

PR: https://git.openjdk.java.net/valhalla/pull/541


From jespersm at openjdk.java.net  Tue Aug 31 22:06:44 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Tue, 31 Aug 2021 22:06:44 GMT
Subject: [lworld] RFR: 8273202: Emit parameter names for primitive record
 factories
Message-ID: <kHfL-J-U_0FQDAAEkD4syJi31o_IAYW5HW11Ra-cdJ4=.be0a3036-d534-4d55-bf0f-3cc31d96770b@github.com>

8273202: Ensure that parameter primitive record factories are generated.

Note that this fix requires JDK-8273018 (PR #541).

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

Commit messages:
 - 8273202: Test which tests reflection of parameter names and ability to construct primitive records.
 - 8273018: Emit parameter annotations on primitive record factories

Changes: https://git.openjdk.java.net/valhalla/pull/542/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=542&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273202
  Stats: 169 lines in 4 files changed: 168 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/542.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/542/head:pull/542

PR: https://git.openjdk.java.net/valhalla/pull/542