From sadayapalam at openjdk.java.net  Wed Sep  1 09:56:56 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 1 Sep 2021 09:56:56 GMT
Subject: [lworld] RFR: 8273018: Emit parameter annotations on primitive
 record factories
In-Reply-To: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
References: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
Message-ID: <w1C0LW9RVMcBQ3oJWqR6db5krcs2X5XgmW9-MyzPalA=.f8cf83a8-0f63-405d-a660-b2987e28e33e@github.com>

On Tue, 31 Aug 2021 21:02:55 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> This fix copies parameter names and annotations from constructor into primitive class factory.

The title of the PR seems to be incorrect ??

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

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


From stigdoessing at gmail.com  Wed Sep  1 10:43:46 2021
From: stigdoessing at gmail.com (=?UTF-8?Q?Stig_Rohde_D=C3=B8ssing?=)
Date: Wed, 1 Sep 2021 12:43:46 +0200
Subject: Reference favoring primitive class heap allocations
Message-ID: <CAG09ER3UZiNVaTfHEbvtQmwaroton9hrKP2t6BfCOLJN+ZdLpA@mail.gmail.com>

Hi,

JEP 401 describes that current value-based classes will be made reference
favoring to avoid breaking existing code. Optional is one of these. I'm
trying to understand the impact this will have on existing APIs with
respect to heap allocation.

Please assume for the following code snippets that ordinary scalar
replacement does not apply.

As I understand it, code like

Optional.val of(T item) { new Optional.val(item) }
Optional.val<String> s = of("Hello")

would tell the JVM that the Optional does not necessarily have to go on the
heap, but could maybe go on the stack or in registers instead.

When "of" is instead defined with the reference type, as in

Optional of(T item) { new Optional(item) }
Optional.val<String> s = of("Hello")

will the Optional always go on the heap?

Also is the plan to be able to avoid the heap for return values, or will
the return value of

Optional.val of(T item)

always go on the heap unless "of" happens to be inlined?

Thanks for reading.


From jespersm at openjdk.java.net  Wed Sep  1 10:49:59 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Wed, 1 Sep 2021 10:49:59 GMT
Subject: [lworld] RFR: 8273018: [lworld] Property annotation propagation
 to <init> lacks in primitive records
In-Reply-To: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
References: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
Message-ID: <5G43vqC-ts1PUC63uAhQoO6s44gsXw7DI93VCvLAUuk=.a0829581-0598-4df5-b5f0-bcbd8865ab51@github.com>

On Tue, 31 Aug 2021 21:02:55 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> This fix copies parameter names and annotations from constructor into primitive class factory.

Fixed name of PR. The name of the issue is slightly off, I guess it should be ?parameter annotation?, really.

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

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


From forax at univ-mlv.fr  Wed Sep  1 21:06:50 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 1 Sep 2021 23:06:50 +0200 (CEST)
Subject: Reference favoring primitive class heap allocations
In-Reply-To: <CAG09ER3UZiNVaTfHEbvtQmwaroton9hrKP2t6BfCOLJN+ZdLpA@mail.gmail.com>
References: <CAG09ER3UZiNVaTfHEbvtQmwaroton9hrKP2t6BfCOLJN+ZdLpA@mail.gmail.com>
Message-ID: <688953473.1645373.1630530410186.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Stig Rohde D?ssing" <stigdoessing at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Sent: Mercredi 1 Septembre 2021 12:43:46
> Subject: Reference favoring primitive class heap allocations

> Hi,
> 

Hi,

> JEP 401 describes that current value-based classes will be made reference
> favoring to avoid breaking existing code. Optional is one of these. I'm
> trying to understand the impact this will have on existing APIs with
> respect to heap allocation.
> 
> Please assume for the following code snippets that ordinary scalar
> replacement does not apply.
> 
> As I understand it, code like
> 
> Optional.val of(T item) { new Optional.val(item) }
> Optional.val<String> s = of("Hello")
> 
> would tell the JVM that the Optional does not necessarily have to go on the
> heap, but could maybe go on the stack or in registers instead.
> 
> When "of" is instead defined with the reference type, as in
> 
> Optional of(T item) { new Optional(item) }
> Optional.val<String> s = of("Hello")
> 
> will the Optional always go on the heap?
> 
> Also is the plan to be able to avoid the heap for return values, or will
> the return value of
> 
> Optional.val of(T item)
> 
> always go on the heap unless "of" happens to be inlined?
> 
> Thanks for reading.

Nope, there is only one way to create an object which is a primitive class.

Let's use an analogy, an ArrayList<String> at runtime can be typed as List<?> or as List<String>, but it's the same ArrayList at runtime.

With primitive classes, it works the same way, a primitive class is always a primitive class at runtime,
there is no two different ways to create a primitive class, there is only one way (to call the factory method named <new> of Optional).
What is different, is that a primitive class can be typed in two different ways, as an Optional.val or as an Optional.ref,
those two types mean different things in term of storage for a field, an array element or a local variable.

T.val:
  For fields and array elements, all the fields (if there are not too many) of T.val are stored in the container of the T.val (the class or the array containing the T.val)
  For a local variable, T.val means that the VM will use registers (or spill the values on stack due to the register allocator) independently of the inlining algorithm.  

T.ref:
  For fields and array elements, a T.ref is stored as a reference (on heap).
  For a local variable, T.ref means that inside the inlining horizon, the VM can optimize the code using escape inlining with late rematerialization, so better than a classical reference because a primitive class has no identity (in practice it's a little more complicated because you don't want to inflate/deflate the same object inside the inlining horizon).

I hope it answers to your questions.

regards,
R?mi


From stigdoessing at gmail.com  Wed Sep  1 22:23:29 2021
From: stigdoessing at gmail.com (=?UTF-8?Q?Stig_Rohde_D=C3=B8ssing?=)
Date: Thu, 2 Sep 2021 00:23:29 +0200
Subject: Reference favoring primitive class heap allocations
In-Reply-To: <688953473.1645373.1630530410186.JavaMail.zimbra@u-pem.fr>
References: <CAG09ER3UZiNVaTfHEbvtQmwaroton9hrKP2t6BfCOLJN+ZdLpA@mail.gmail.com>
 <688953473.1645373.1630530410186.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAG09ER3YH4kv+m1MO9rAawCOZ=C-tv0+PQYpVQZPdAWeibhUHg@mail.gmail.com>

Thanks R?mi, I think it mostly does. I'll admit that the bit about
optimizing local T.ref goes a bit over my head.

What about method return values? If I declare a method as

T.val someMethod()
vs
T.ref someMethod()

and do

T.val someLocal = someMethod()

would the two methods have different behavior for how the value is returned
from the call (Return the value in registers/put it on the caller's stack
vs.put the object on heap and return a pointer to that), or is this
determined by whether "someLocal" is a val or a ref and doesn't have
anything to do with the return type of "someMethod"?

Den ons. 1. sep. 2021 kl. 23.06 skrev Remi Forax <forax at univ-mlv.fr>:

> ----- Original Message -----
> > From: "Stig Rohde D?ssing" <stigdoessing at gmail.com>
> > To: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> > Sent: Mercredi 1 Septembre 2021 12:43:46
> > Subject: Reference favoring primitive class heap allocations
>
> > Hi,
> >
>
> Hi,
>
> > JEP 401 describes that current value-based classes will be made reference
> > favoring to avoid breaking existing code. Optional is one of these. I'm
> > trying to understand the impact this will have on existing APIs with
> > respect to heap allocation.
> >
> > Please assume for the following code snippets that ordinary scalar
> > replacement does not apply.
> >
> > As I understand it, code like
> >
> > Optional.val of(T item) { new Optional.val(item) }
> > Optional.val<String> s = of("Hello")
> >
> > would tell the JVM that the Optional does not necessarily have to go on
> the
> > heap, but could maybe go on the stack or in registers instead.
> >
> > When "of" is instead defined with the reference type, as in
> >
> > Optional of(T item) { new Optional(item) }
> > Optional.val<String> s = of("Hello")
> >
> > will the Optional always go on the heap?
> >
> > Also is the plan to be able to avoid the heap for return values, or will
> > the return value of
> >
> > Optional.val of(T item)
> >
> > always go on the heap unless "of" happens to be inlined?
> >
> > Thanks for reading.
>
> Nope, there is only one way to create an object which is a primitive class.
>
> Let's use an analogy, an ArrayList<String> at runtime can be typed as
> List<?> or as List<String>, but it's the same ArrayList at runtime.
>
> With primitive classes, it works the same way, a primitive class is always
> a primitive class at runtime,
> there is no two different ways to create a primitive class, there is only
> one way (to call the factory method named <new> of Optional).
> What is different, is that a primitive class can be typed in two different
> ways, as an Optional.val or as an Optional.ref,
> those two types mean different things in term of storage for a field, an
> array element or a local variable.
>
> T.val:
>   For fields and array elements, all the fields (if there are not too
> many) of T.val are stored in the container of the T.val (the class or the
> array containing the T.val)
>   For a local variable, T.val means that the VM will use registers (or
> spill the values on stack due to the register allocator) independently of
> the inlining algorithm.
>
> T.ref:
>   For fields and array elements, a T.ref is stored as a reference (on
> heap).
>   For a local variable, T.ref means that inside the inlining horizon, the
> VM can optimize the code using escape inlining with late rematerialization,
> so better than a classical reference because a primitive class has no
> identity (in practice it's a little more complicated because you don't want
> to inflate/deflate the same object inside the inlining horizon).
>
> I hope it answers to your questions.
>
> regards,
> R?mi
>


From thartmann at openjdk.java.net  Thu Sep  2 07:54:55 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 2 Sep 2021 07:54:55 GMT
Subject: [lworld] RFR: 8267665: [lworld] Scalarization of nullable inline types
Message-ID: <B4yLj10VMKVx_PbbRZweMXoeHRAGXkSSoEIy28kWNtM=.829dbba4-7f23-45fa-a2a9-3df8f4d80010@github.com>

This patch implements support for scalarizing nullable inline types (`.ref`) in C2 compiled code. This enables full scalarization whenever C2 is able to prove that a local, argument, return, field or array element is an inline type, even when mixing with constant `null` or object/interface types. As a result, buffer allocations are avoided and field loads are folded. For example, in the following method, no allocation or store remains:


int test(boolean b, int x, Object arg) {
  Object val = new Point(x, x);
  if (b) {
    val = (Point.ref)arg;
  }
  method(); // Not inlined
  if (val == null) {
    return 42;
  }
  return ((Point.ref)val).x;
}

C2 compiles this to (pseudocode):

int test(boolean b, int x, Object arg) {
  bool isInit = true;
  if (b) {
    isInit = (arg != null);
    x = isInit ? ((Point.ref)arg).x : 0;
  }
  method(); // Keep x and isInit in the safepoint debug info for re-allocation on deopt
  return isInit ? x : 42;
}


For more examples, see the new tests added to `TestNullableInlineTypes.java` that would fail without this patch. The `failOn = {ALLOC ...` IR verification rules ensure that scalarization works and no allocation remains in the generated code. 

To achieve this,  a new `is_init` input is propagated with the inline type nodes in addition to the optional buffer oop input and the field values. Before accessing the field values, a null check is required (for example, see `Parse::do_field_access`). Such null checks are then rewired to check the `is_init` input instead (see `GraphKit::null_check_common`, `GraphKit::cast_not_null` and `CmpPNode::Ideal`). The `is_init` input is also propagated through safepoint debug info to use it  on deoptimization to decide if re-allocation is required or null should be passed to the interpreter.

Here is a high level overview of the changes:
- All places where we would previously just load an inline type ptr now apply scalarization.
- Support for `null` in the safepoint debug info and in deoptimization code. The `is_init` information is propagated through the safepoint debug info and checked before re-allocation during deoptimization.
- Fixed checkcast to properly replace a scalarized inline type in the parsing map.
- Greatly improved the `PhiNode::Ideal` transformation that pushed inline type nodes through phis. The code can now handle complex shapes like other phi inputs and data loops. See `PhiNode::push_inline_types_through`. This is required to reliably optimize complex loops.
- Removed the `ScalarizeInlineTypes` debug flag because all the logic just became too complex and hard to maintain. For the same reason, I decided to not introduce a new flag to disable scalarization of nullable inline types.
- Fixed and improved unsafe access and getClass intrinsics.
- Strengthened array store checks and replaced the corresponding runtime checks by asserts.
- Fixed several unrelated bugs that showed up during extensive testing and removed dead code.
- Applied test-driven-development by adding a new (IR verification) test for each new code path and optimization.
- Strengthened IR verification rules. `LOAD` and `STORE` rules are now matching all accesses. Added lots of additional rules to existing tests.

There are still some rough edges though, that I'll address with follow-up changes:
- For simplicity, the `is_init` input is currently an oop that needs to be null checked.
- We should get rid of the weird `InlineTypeNode`/`InlineTypePtrNode` duality. With the current code, they are only needed to differentiate between always-buffered and maybe-buffered. There is lots of code that can be removed/simplified with that.
- When an inline type is always buffered, it's better to use the oop for safepoint debug info instead of scalarizing to avoid keeping field loads alive. The corresponding logic in `InlineTypeBaseNode::make_scalar_in_safepoints` needs to be improved.
- Scalarization in the calling convention is not (yet) supported.

Tested with tier1-5 and valhalla specific compiler stress testing.

Thanks,
Tobias

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

Commit messages:
 - Final refactoring
 - More refactoring
 - More bug fixes after running stress testing. Tier1-5 and valhalla stress testing now pass
 - Merge branch 'lworld' into JDK-8267665
 - Removed ScalarizeInlineTypes flag, refactoring
 - Adjusted comments
 - Fixed unsafe accesses and lots of other bugs. Refactoring, cleanups. Finally, all tests (even mach5 tier1-3) pass
 - GraphKit cleanups - all tests pass
 - Match rules fix - all tests pass
 - Fixed unsafe accesses, properly replace casts in map
 - ... and 16 more: https://git.openjdk.java.net/valhalla/compare/994f6cfe...45258fbc

Changes: https://git.openjdk.java.net/valhalla/pull/543/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=543&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267665
  Stats: 2995 lines in 44 files changed: 2438 ins; 199 del; 358 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/543.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/543/head:pull/543

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


From forax at univ-mlv.fr  Thu Sep  2 08:52:49 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 2 Sep 2021 10:52:49 +0200 (CEST)
Subject: Reference favoring primitive class heap allocations
In-Reply-To: <CAG09ER3YH4kv+m1MO9rAawCOZ=C-tv0+PQYpVQZPdAWeibhUHg@mail.gmail.com>
References: <CAG09ER3UZiNVaTfHEbvtQmwaroton9hrKP2t6BfCOLJN+ZdLpA@mail.gmail.com>
 <688953473.1645373.1630530410186.JavaMail.zimbra@u-pem.fr>
 <CAG09ER3YH4kv+m1MO9rAawCOZ=C-tv0+PQYpVQZPdAWeibhUHg@mail.gmail.com>
Message-ID: <1307659127.2092421.1630572769306.JavaMail.zimbra@u-pem.fr>

> From: "Stig Rohde D?ssing" <stigdoessing at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Sent: Jeudi 2 Septembre 2021 00:23:29
> Subject: Re: Reference favoring primitive class heap allocations

> Thanks R?mi, I think it mostly does. I'll admit that the bit about optimizing
> local T.ref goes a bit over my head.

My point was that T.ref declared as a local variable can be optimized by the JIT avoiding heap allocation. 

Just today Tobias submit a PR that shows how c2 try to avoid T.ref allocation on heap for local variables even when there is no inlining 
[ https://github.com/openjdk/valhalla/pull/543 | https://github.com/openjdk/valhalla/pull/543 ] 

> What about method return values? If I declare a method as

> T.val someMethod()
> vs
> T.ref someMethod()

> and do

> T.val someLocal = someMethod()

> would the two methods have different behavior for how the value is returned from
> the call (Return the value in registers/put it on the caller's stack vs.put the
> object on heap and return a pointer to that), or is this determined by whether
> "someLocal" is a val or a ref and doesn't have anything to do with the return
> type of "someMethod"?

The two methods have almost the same behavior, apart from the fact that T.ref allows null while T.val does not. 
But they do not have the same "performance model". If you return T.val you ask to flatten T so it works even without inlining while if you return T.ref, the performance depend on the JIT being able to inline/optimize (so you may get the same performance or not). 

R?mi 

> Den ons. 1. sep. 2021 kl. 23.06 skrev Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] >:

>> ----- Original Message -----
>>> From: "Stig Rohde D?ssing" < [ mailto:stigdoessing at gmail.com |
>> > stigdoessing at gmail.com ] >
>>> To: "valhalla-dev" < [ mailto:valhalla-dev at openjdk.java.net |
>> > valhalla-dev at openjdk.java.net ] >
>> > Sent: Mercredi 1 Septembre 2021 12:43:46
>> > Subject: Reference favoring primitive class heap allocations

>> > Hi,


>> Hi,

>> > JEP 401 describes that current value-based classes will be made reference
>> > favoring to avoid breaking existing code. Optional is one of these. I'm
>> > trying to understand the impact this will have on existing APIs with
>> > respect to heap allocation.

>> > Please assume for the following code snippets that ordinary scalar
>> > replacement does not apply.

>> > As I understand it, code like

>> > Optional.val of(T item) { new Optional.val(item) }
>> > Optional.val<String> s = of("Hello")

>> > would tell the JVM that the Optional does not necessarily have to go on the
>> > heap, but could maybe go on the stack or in registers instead.

>> > When "of" is instead defined with the reference type, as in

>> > Optional of(T item) { new Optional(item) }
>> > Optional.val<String> s = of("Hello")

>> > will the Optional always go on the heap?

>> > Also is the plan to be able to avoid the heap for return values, or will
>> > the return value of

>> > Optional.val of(T item)

>> > always go on the heap unless "of" happens to be inlined?

>> > Thanks for reading.

>> Nope, there is only one way to create an object which is a primitive class.

>> Let's use an analogy, an ArrayList<String> at runtime can be typed as List<?> or
>> as List<String>, but it's the same ArrayList at runtime.

>> With primitive classes, it works the same way, a primitive class is always a
>> primitive class at runtime,
>> there is no two different ways to create a primitive class, there is only one
>> way (to call the factory method named <new> of Optional).
>> What is different, is that a primitive class can be typed in two different ways,
>> as an Optional.val or as an Optional.ref,
>> those two types mean different things in term of storage for a field, an array
>> element or a local variable.

>> T.val:
>> For fields and array elements, all the fields (if there are not too many) of
>> T.val are stored in the container of the T.val (the class or the array
>> containing the T.val)
>> For a local variable, T.val means that the VM will use registers (or spill the
>> values on stack due to the register allocator) independently of the inlining
>> algorithm.

>> T.ref:
>> For fields and array elements, a T.ref is stored as a reference (on heap).
>> For a local variable, T.ref means that inside the inlining horizon, the VM can
>> optimize the code using escape inlining with late rematerialization, so better
>> than a classical reference because a primitive class has no identity (in
>> practice it's a little more complicated because you don't want to
>> inflate/deflate the same object inside the inlining horizon).

>> I hope it answers to your questions.

>> regards,
>> R?mi


From stigdoessing at gmail.com  Thu Sep  2 09:25:56 2021
From: stigdoessing at gmail.com (=?UTF-8?Q?Stig_Rohde_D=C3=B8ssing?=)
Date: Thu, 2 Sep 2021 11:25:56 +0200
Subject: Reference favoring primitive class heap allocations
In-Reply-To: <1307659127.2092421.1630572769306.JavaMail.zimbra@u-pem.fr>
References: <CAG09ER3UZiNVaTfHEbvtQmwaroton9hrKP2t6BfCOLJN+ZdLpA@mail.gmail.com>
 <688953473.1645373.1630530410186.JavaMail.zimbra@u-pem.fr>
 <CAG09ER3YH4kv+m1MO9rAawCOZ=C-tv0+PQYpVQZPdAWeibhUHg@mail.gmail.com>
 <1307659127.2092421.1630572769306.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAG09ER2ryfKnS9dkaNgVXdzQsxswXyvy8KzW=8xeNQHWXVBkwg@mail.gmail.com>

Thank you, that makes sense.

Den tor. 2. sep. 2021 kl. 10.52 skrev <forax at univ-mlv.fr>:

>
>
> ------------------------------
>
> *From: *"Stig Rohde D?ssing" <stigdoessing at gmail.com>
> *To: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"valhalla-dev" <valhalla-dev at openjdk.java.net>
> *Sent: *Jeudi 2 Septembre 2021 00:23:29
> *Subject: *Re: Reference favoring primitive class heap allocations
>
> Thanks R?mi, I think it mostly does. I'll admit that the bit about
> optimizing local T.ref goes a bit over my head.
>
>
> My point was that T.ref declared as a local variable can be optimized by
> the JIT avoiding heap allocation.
>
> Just today Tobias submit a PR that shows how c2 try to avoid T.ref
> allocation on heap for local variables even when there is no inlining
> https://github.com/openjdk/valhalla/pull/543
>
>
> What about method return values? If I declare a method as
>
> T.val someMethod()
> vs
> T.ref someMethod()
>
> and do
>
> T.val someLocal = someMethod()
>
> would the two methods have different behavior for how the value is
> returned from the call (Return the value in registers/put it on the
> caller's stack vs.put the object on heap and return a pointer to that), or
> is this determined by whether "someLocal" is a val or a ref and doesn't
> have anything to do with the return type of "someMethod"?
>
>
> The two methods have almost the same behavior, apart from the fact that
> T.ref allows null while T.val does not.
> But they do not have the same "performance model". If you return T.val you
> ask to flatten T so it works even without inlining while if you return
> T.ref, the performance depend on the JIT being able to inline/optimize (so
> you may get the same performance or not).
>
> R?mi
>
>
>
> Den ons. 1. sep. 2021 kl. 23.06 skrev Remi Forax <forax at univ-mlv.fr>:
>
>> ----- Original Message -----
>> > From: "Stig Rohde D?ssing" <stigdoessing at gmail.com>
>> > To: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>> > Sent: Mercredi 1 Septembre 2021 12:43:46
>> > Subject: Reference favoring primitive class heap allocations
>>
>> > Hi,
>> >
>>
>> Hi,
>>
>> > JEP 401 describes that current value-based classes will be made
>> reference
>> > favoring to avoid breaking existing code. Optional is one of these. I'm
>> > trying to understand the impact this will have on existing APIs with
>> > respect to heap allocation.
>> >
>> > Please assume for the following code snippets that ordinary scalar
>> > replacement does not apply.
>> >
>> > As I understand it, code like
>> >
>> > Optional.val of(T item) { new Optional.val(item) }
>> > Optional.val<String> s = of("Hello")
>> >
>> > would tell the JVM that the Optional does not necessarily have to go on
>> the
>> > heap, but could maybe go on the stack or in registers instead.
>> >
>> > When "of" is instead defined with the reference type, as in
>> >
>> > Optional of(T item) { new Optional(item) }
>> > Optional.val<String> s = of("Hello")
>> >
>> > will the Optional always go on the heap?
>> >
>> > Also is the plan to be able to avoid the heap for return values, or will
>> > the return value of
>> >
>> > Optional.val of(T item)
>> >
>> > always go on the heap unless "of" happens to be inlined?
>> >
>> > Thanks for reading.
>>
>> Nope, there is only one way to create an object which is a primitive
>> class.
>>
>> Let's use an analogy, an ArrayList<String> at runtime can be typed as
>> List<?> or as List<String>, but it's the same ArrayList at runtime.
>>
>> With primitive classes, it works the same way, a primitive class is
>> always a primitive class at runtime,
>> there is no two different ways to create a primitive class, there is only
>> one way (to call the factory method named <new> of Optional).
>> What is different, is that a primitive class can be typed in two
>> different ways, as an Optional.val or as an Optional.ref,
>> those two types mean different things in term of storage for a field, an
>> array element or a local variable.
>>
>> T.val:
>>   For fields and array elements, all the fields (if there are not too
>> many) of T.val are stored in the container of the T.val (the class or the
>> array containing the T.val)
>>   For a local variable, T.val means that the VM will use registers (or
>> spill the values on stack due to the register allocator) independently of
>> the inlining algorithm.
>>
>> T.ref:
>>   For fields and array elements, a T.ref is stored as a reference (on
>> heap).
>>   For a local variable, T.ref means that inside the inlining horizon, the
>> VM can optimize the code using escape inlining with late rematerialization,
>> so better than a classical reference because a primitive class has no
>> identity (in practice it's a little more complicated because you don't want
>> to inflate/deflate the same object inside the inlining horizon).
>>
>> I hope it answers to your questions.
>>
>> regards,
>> R?mi
>>
>
>


From thartmann at openjdk.java.net  Thu Sep  2 10:19:04 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 2 Sep 2021 10:19:04 GMT
Subject: [lworld] Integrated: [lworld] Removed TestNativeClone.java from
 ProblemList now that 8270098 is fixed
In-Reply-To: <GD6LokLXCIF52H89e1S_AbCGMFe5aUGws0fB7Wy6uds=.7009292e-b339-4559-a40e-b791cef02604@github.com>
References: <GD6LokLXCIF52H89e1S_AbCGMFe5aUGws0fB7Wy6uds=.7009292e-b339-4559-a40e-b791cef02604@github.com>
Message-ID: <FWCBiXIbXuFfttpR_BWphW-3vDNb2T4f9uTMOp_7dOk=.4a413a0a-dbbf-4fd0-afb3-5e88af607abe@github.com>

On Thu, 2 Sep 2021 10:11:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Mainline bug [JDK-8270098](https://bugs.openjdk.java.net/browse/JDK-8270098) is fixed in Valhalla. We can remove the test from the problem list.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

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

[lworld] Removed TestNativeClone.java from ProblemList now that 8270098 is fixed

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

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


From thartmann at openjdk.java.net  Thu Sep  2 10:19:03 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 2 Sep 2021 10:19:03 GMT
Subject: [lworld] Integrated: [lworld] Removed TestNativeClone.java from
 ProblemList now that 8270098 is fixed
Message-ID: <GD6LokLXCIF52H89e1S_AbCGMFe5aUGws0fB7Wy6uds=.7009292e-b339-4559-a40e-b791cef02604@github.com>

Mainline bug [JDK-8270098](https://bugs.openjdk.java.net/browse/JDK-8270098) is fixed in Valhalla. We can remove the test from the problem list.

Best regards,
Tobias

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

Commit messages:
 - [lworld] Removed TestNativeClone.java from ProblemList now that 8270098 is fixed

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

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


From nlisker at gmail.com  Thu Sep  2 13:32:20 2021
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 2 Sep 2021 16:32:20 +0300
Subject: Specialized primitive implementations after generics
 specialization
In-Reply-To: <67d3254a-e42f-f77c-a982-512f2bc344f5@oracle.com>
References: <CA+0ynh9p_YkuPf=922dx+JfJdd0xF0sfBYqsnh7RMZRhnLD45Q@mail.gmail.com>
 <CD8B31CF-BBB2-4DF8-82F2-85D1BDF4D7CF@oracle.com>
 <67d3254a-e42f-f77c-a982-512f2bc344f5@oracle.com>
Message-ID: <CA+0ynh-D4xEs49hoBHvDG9PsMKRFPO8eauq3q69b+EHM5FsNog@mail.gmail.com>

Thanks for the replies, this is very interesting and encouraging.

On Tue, Aug 31, 2021 at 5:26 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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> <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  Thu Sep  2 20:18:06 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 2 Sep 2021 20:18:06 GMT
Subject: [lworld] RFR: 8273301: Bootstrap of instance-capturing lambda fails
 for reference favoring primitive types.
Message-ID: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>

Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.

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

Commit messages:
 - Stray whitespace
 - 8273301: Bootstrap of instance-capturing lambda fails for reference favoring primitive types.

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

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


From thartmann at openjdk.java.net  Fri Sep  3 09:26:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 3 Sep 2021 09:26:42 GMT
Subject: [lworld] Integrated: 8267665: [lworld] Scalarization of nullable
 inline types
In-Reply-To: <B4yLj10VMKVx_PbbRZweMXoeHRAGXkSSoEIy28kWNtM=.829dbba4-7f23-45fa-a2a9-3df8f4d80010@github.com>
References: <B4yLj10VMKVx_PbbRZweMXoeHRAGXkSSoEIy28kWNtM=.829dbba4-7f23-45fa-a2a9-3df8f4d80010@github.com>
Message-ID: <7i5QI9YHX4tuF2oELIRu1Akw06bLWpe3S-EWhHnRUmc=.91343eb2-fb93-4924-8a2c-c47146ef6c4b@github.com>

On Thu, 2 Sep 2021 07:49:36 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This patch implements support for scalarizing nullable inline types (`.ref`) in C2 compiled code. This enables full scalarization whenever C2 is able to prove that a local, argument, return, field or array element is an inline type, even when mixing with constant `null` or object/interface types. As a result, buffer allocations are avoided and field loads are folded. For example, in the following method, no allocation or store remains:
> 
> 
> int test(boolean b, int x, Object arg) {
>   Object val = new Point(x, x);
>   if (b) {
>     val = (Point.ref)arg;
>   }
>   method(); // Not inlined
>   if (val == null) {
>     return 42;
>   }
>   return ((Point.ref)val).x;
> }
> 
> C2 compiles this to (pseudocode):
> 
> int test(boolean b, int x, Object arg) {
>   bool isInit = true;
>   if (b) {
>     isInit = (arg != null);
>     x = isInit ? ((Point.ref)arg).x : 0;
>   }
>   method(); // Keep x and isInit in the safepoint debug info for re-allocation on deopt
>   return isInit ? x : 42;
> }
> 
> 
> For more examples, see the new tests added to `TestNullableInlineTypes.java` that would fail without this patch. The `failOn = {ALLOC ...` IR verification rules ensure that scalarization works and no allocation remains in the generated code. 
> 
> To achieve this,  a new `is_init` input is propagated with the inline type nodes in addition to the optional buffer oop input and the field values. Before accessing the field values, a null check is required (for example, see `Parse::do_field_access`). Such null checks are then rewired to check the `is_init` input instead (see `GraphKit::null_check_common`, `GraphKit::cast_not_null` and `CmpPNode::Ideal`). The `is_init` input is also propagated through safepoint debug info to use it  on deoptimization to decide if re-allocation is required or null should be passed to the interpreter.
> 
> Here is a high level overview of the changes:
> - All places where we would previously just load an inline type ptr now apply scalarization.
> - Support for `null` in the safepoint debug info and in deoptimization code. The `is_init` information is propagated through the safepoint debug info and checked before re-allocation during deoptimization.
> - Fixed checkcast to properly replace a scalarized inline type in the parsing map.
> - Greatly improved the `PhiNode::Ideal` transformation that pushed inline type nodes through phis. The code can now handle complex shapes like other phi inputs and data loops. See `PhiNode::push_inline_types_through`. This is required to reliably optimize complex loops.
> - Removed the `ScalarizeInlineTypes` debug flag because all the logic just became too complex and hard to maintain. For the same reason, I decided to not introduce a new flag to disable scalarization of nullable inline types.
> - Fixed and improved unsafe access and getClass intrinsics.
> - Strengthened array store checks and replaced the corresponding runtime checks by asserts.
> - Fixed several unrelated bugs that showed up during extensive testing and removed dead code.
> - Applied test-driven-development by adding a new (IR verification) test for each new code path and optimization.
> - Strengthened IR verification rules. `LOAD` and `STORE` rules are now matching all accesses. Added lots of additional rules to existing tests.
> 
> There are still some rough edges though, that I'll address with follow-up changes:
> - For simplicity, the `is_init` input is currently an oop that needs to be null checked.
> - We should get rid of the weird `InlineTypeNode`/`InlineTypePtrNode` duality. With the current code, they are only needed to differentiate between always-buffered and maybe-buffered. There is lots of code that can be removed/simplified with that.
> - When an inline type is always buffered, it's better to use the oop for safepoint debug info instead of scalarizing to avoid keeping field loads alive. The corresponding logic in `InlineTypeBaseNode::make_scalar_in_safepoints` needs to be improved.
> - Scalarization in the calling convention is not (yet) supported.
> 
> Tested with tier1-5 and valhalla specific compiler stress testing.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 59fc2db4
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/59fc2db496a0ba7fe3e737f7a998c28f2715efb3
Stats:     2995 lines in 44 files changed: 2438 ins; 199 del; 358 mod

8267665: [lworld] Scalarization of nullable inline types

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

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


From stigdoessing at gmail.com  Fri Sep  3 18:01:51 2021
From: stigdoessing at gmail.com (=?UTF-8?Q?Stig_Rohde_D=C3=B8ssing?=)
Date: Fri, 3 Sep 2021 20:01:51 +0200
Subject: Reference favoring primitive class heap allocations
In-Reply-To: <CAG09ER2ryfKnS9dkaNgVXdzQsxswXyvy8KzW=8xeNQHWXVBkwg@mail.gmail.com>
References: <CAG09ER3UZiNVaTfHEbvtQmwaroton9hrKP2t6BfCOLJN+ZdLpA@mail.gmail.com>
 <688953473.1645373.1630530410186.JavaMail.zimbra@u-pem.fr>
 <CAG09ER3YH4kv+m1MO9rAawCOZ=C-tv0+PQYpVQZPdAWeibhUHg@mail.gmail.com>
 <1307659127.2092421.1630572769306.JavaMail.zimbra@u-pem.fr>
 <CAG09ER2ryfKnS9dkaNgVXdzQsxswXyvy8KzW=8xeNQHWXVBkwg@mail.gmail.com>
Message-ID: <CAG09ER1smc-3JEA+ubBh6uhWbG-OAcsJBEhLakg6OTWNd5pC8Q@mail.gmail.com>

When Optional becomes a reference-favoring primitive class, my
understanding is that calling methods like
static Optional<T> of(T item)
will cause heap allocations unless the call gets inlined/optimized, right?
So even completely new code that uses Optional.val consistently, e.g.
Optional.val<String> opt = Optional.of("hello")
can't be trusted not to heap allocate, since it is hard to know up front
whether the "of" call will be optimized at runtime. I am concerned that
this would make it hard to trust Optional not to end up in the heap when
used in allocation-sensitive code, which seems unfortunate.

I'm wondering if you are intending to switch the return types of existing
APIs that can't return null, so methods like "of" return Optional.val
instead, while still having Optional be reference-favoring? If "of" were
declared as
static Optional.val<T> of(T item)
then developers writing new code can be reasonably sure that Optional
instances will be flattened when calling "of" (and other such methods), as
long as they remember to use Optional.val and not Optional in their own
code.

Den tor. 2. sep. 2021 kl. 11.25 skrev Stig Rohde D?ssing <
stigdoessing at gmail.com>:

> Thank you, that makes sense.
>
> Den tor. 2. sep. 2021 kl. 10.52 skrev <forax at univ-mlv.fr>:
>
>>
>>
>> ------------------------------
>>
>> *From: *"Stig Rohde D?ssing" <stigdoessing at gmail.com>
>> *To: *"Remi Forax" <forax at univ-mlv.fr>
>> *Cc: *"valhalla-dev" <valhalla-dev at openjdk.java.net>
>> *Sent: *Jeudi 2 Septembre 2021 00:23:29
>> *Subject: *Re: Reference favoring primitive class heap allocations
>>
>> Thanks R?mi, I think it mostly does. I'll admit that the bit about
>> optimizing local T.ref goes a bit over my head.
>>
>>
>> My point was that T.ref declared as a local variable can be optimized by
>> the JIT avoiding heap allocation.
>>
>> Just today Tobias submit a PR that shows how c2 try to avoid T.ref
>> allocation on heap for local variables even when there is no inlining
>> https://github.com/openjdk/valhalla/pull/543
>>
>>
>> What about method return values? If I declare a method as
>>
>> T.val someMethod()
>> vs
>> T.ref someMethod()
>>
>> and do
>>
>> T.val someLocal = someMethod()
>>
>> would the two methods have different behavior for how the value is
>> returned from the call (Return the value in registers/put it on the
>> caller's stack vs.put the object on heap and return a pointer to that), or
>> is this determined by whether "someLocal" is a val or a ref and doesn't
>> have anything to do with the return type of "someMethod"?
>>
>>
>> The two methods have almost the same behavior, apart from the fact that
>> T.ref allows null while T.val does not.
>> But they do not have the same "performance model". If you return T.val
>> you ask to flatten T so it works even without inlining while if you return
>> T.ref, the performance depend on the JIT being able to inline/optimize (so
>> you may get the same performance or not).
>>
>> R?mi
>>
>>
>>
>> Den ons. 1. sep. 2021 kl. 23.06 skrev Remi Forax <forax at univ-mlv.fr>:
>>
>>> ----- Original Message -----
>>> > From: "Stig Rohde D?ssing" <stigdoessing at gmail.com>
>>> > To: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>>> > Sent: Mercredi 1 Septembre 2021 12:43:46
>>> > Subject: Reference favoring primitive class heap allocations
>>>
>>> > Hi,
>>> >
>>>
>>> Hi,
>>>
>>> > JEP 401 describes that current value-based classes will be made
>>> reference
>>> > favoring to avoid breaking existing code. Optional is one of these. I'm
>>> > trying to understand the impact this will have on existing APIs with
>>> > respect to heap allocation.
>>> >
>>> > Please assume for the following code snippets that ordinary scalar
>>> > replacement does not apply.
>>> >
>>> > As I understand it, code like
>>> >
>>> > Optional.val of(T item) { new Optional.val(item) }
>>> > Optional.val<String> s = of("Hello")
>>> >
>>> > would tell the JVM that the Optional does not necessarily have to go
>>> on the
>>> > heap, but could maybe go on the stack or in registers instead.
>>> >
>>> > When "of" is instead defined with the reference type, as in
>>> >
>>> > Optional of(T item) { new Optional(item) }
>>> > Optional.val<String> s = of("Hello")
>>> >
>>> > will the Optional always go on the heap?
>>> >
>>> > Also is the plan to be able to avoid the heap for return values, or
>>> will
>>> > the return value of
>>> >
>>> > Optional.val of(T item)
>>> >
>>> > always go on the heap unless "of" happens to be inlined?
>>> >
>>> > Thanks for reading.
>>>
>>> Nope, there is only one way to create an object which is a primitive
>>> class.
>>>
>>> Let's use an analogy, an ArrayList<String> at runtime can be typed as
>>> List<?> or as List<String>, but it's the same ArrayList at runtime.
>>>
>>> With primitive classes, it works the same way, a primitive class is
>>> always a primitive class at runtime,
>>> there is no two different ways to create a primitive class, there is
>>> only one way (to call the factory method named <new> of Optional).
>>> What is different, is that a primitive class can be typed in two
>>> different ways, as an Optional.val or as an Optional.ref,
>>> those two types mean different things in term of storage for a field, an
>>> array element or a local variable.
>>>
>>> T.val:
>>>   For fields and array elements, all the fields (if there are not too
>>> many) of T.val are stored in the container of the T.val (the class or the
>>> array containing the T.val)
>>>   For a local variable, T.val means that the VM will use registers (or
>>> spill the values on stack due to the register allocator) independently of
>>> the inlining algorithm.
>>>
>>> T.ref:
>>>   For fields and array elements, a T.ref is stored as a reference (on
>>> heap).
>>>   For a local variable, T.ref means that inside the inlining horizon,
>>> the VM can optimize the code using escape inlining with late
>>> rematerialization, so better than a classical reference because a primitive
>>> class has no identity (in practice it's a little more complicated because
>>> you don't want to inflate/deflate the same object inside the inlining
>>> horizon).
>>>
>>> I hope it answers to your questions.
>>>
>>> regards,
>>> R?mi
>>>
>>
>>


From jespersm at openjdk.java.net  Sun Sep  5 13:38:14 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Sun, 5 Sep 2021 13:38:14 GMT
Subject: [lworld] RFR: [lworld] Invoking a reflection-generated constructor
 for primitive class gives InstantiationError
Message-ID: <E2vE7HSdk0GxjjbFLMUd78nPQkDFIUApxLD8dOAKFOg=.6c54a052-33a5-4bcd-8870-54888bc69981@github.com>

Update constructor accessor code generation to invoke static factory method.

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

Commit messages:
 - [lworld] Invoking a reflection-generated constructor for primitive class gives InstantiationError

Changes: https://git.openjdk.java.net/valhalla/pull/546/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=546&range=00
  Stats: 13 lines in 3 files changed: 8 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/546.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/546/head:pull/546

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


From dsimms at openjdk.java.net  Tue Sep  7 13:22:27 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 7 Sep 2021 13:22:27 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <yr_XRE08JelnOLTQWkLuA-Wy3dzKHWAw3YLLGHgnT4g=.3dc07715-0da5-439d-ba99-9400c0179cd8@github.com>

Merge tag 'jdk-18+13'

# Conflicts:
#	src/hotspot/share/opto/escape.cpp
#	src/hotspot/share/opto/library_call.cpp
#	src/java.base/share/classes/java/lang/runtime/ObjectMethods.java
#	test/jdk/java/lang/runtime/ObjectMethodsTest.java

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

Commit messages:
 - Merge tag 'jdk-18+13' into lworld_merge_jdk_18_13
 - 8272377: assert preconditions that are ensured when created in add_final_edges
 - 8272563: assert(is_double_stack() && !is_virtual()) failed: type check
 - 8273176: handle latest VS2019 in abstract_vm_version
 - 8273206: jdk/jfr/event/gc/collection/TestG1ParallelPhases.java fails after JDK-8159979
 - 8272618: Unnecessary Attr.visitIdent.noOuterThisPath
 - 8272963: Update the java manpage markdown source
 - 8269770: nsk tests should start IOPipe channel before launch debuggee - Debugee.prepareDebugee
 - 8273197: ProblemList 2 jtools tests due to JDK-8273187
 - 8262186: Call X509KeyManager.chooseClientAlias once for all key types
 - ... and 56 more: https://git.openjdk.java.net/valhalla/compare/59fc2db4...525e0d5d

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

Changes: https://git.openjdk.java.net/valhalla/pull/547/files
  Stats: 6069 lines in 213 files changed: 2650 ins; 1579 del; 1840 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/547.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/547/head:pull/547

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


From jespersm at openjdk.java.net  Tue Sep  7 23:37:52 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Tue, 7 Sep 2021 23:37:52 GMT
Subject: [lworld] RFR: 8273018: [lworld] Property annotation propagation
 to <init> lacks in primitive records [v2]
In-Reply-To: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
References: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
Message-ID: <Fjs2j_0gkEFj55ocHSSf3LB96RH3z3WYBqzof9FTieU=.ce6f8948-e848-46cf-b051-f37ffa7509a0@github.com>

> This fix copies parameter names and annotations from constructor into primitive class factory.

Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:

  - Emit parameter names (described JDK-8273202)
  - Keep type parameters
  - Provide useful test for primitive records in "RecordReading"

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/541/files
  - new: https://git.openjdk.java.net/valhalla/pull/541/files/caab164d..122a8b10

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

  Stats: 73 lines in 3 files changed: 71 ins; 0 del; 2 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 Sep  7 23:38:21 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Tue, 7 Sep 2021 23:38:21 GMT
Subject: [lworld] RFR: 8273202: [lworld] MethodParameters are not
 generated for factories for primitive records
In-Reply-To: <kHfL-J-U_0FQDAAEkD4syJi31o_IAYW5HW11Ra-cdJ4=.be0a3036-d534-4d55-bf0f-3cc31d96770b@github.com>
References: <kHfL-J-U_0FQDAAEkD4syJi31o_IAYW5HW11Ra-cdJ4=.be0a3036-d534-4d55-bf0f-3cc31d96770b@github.com>
Message-ID: <onWkZdMp7M37w7txc947fFNvH1jV216f7iZMLZXZvJQ=.c6cc5748-87ab-403c-afea-0deba48bf980@github.com>

On Tue, 31 Aug 2021 22:00:34 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> 8273202: Ensure that parameter primitive record factories are generated.
> 
> Note that this fix requires JDK-8273018 (PR #541).

I'm folding this change into PR #541, closing this one.

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

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


From jespersm at openjdk.java.net  Tue Sep  7 23:38:22 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Tue, 7 Sep 2021 23:38:22 GMT
Subject: [lworld] Withdrawn: 8273202: [lworld] MethodParameters are not
 generated for factories for primitive records
In-Reply-To: <kHfL-J-U_0FQDAAEkD4syJi31o_IAYW5HW11Ra-cdJ4=.be0a3036-d534-4d55-bf0f-3cc31d96770b@github.com>
References: <kHfL-J-U_0FQDAAEkD4syJi31o_IAYW5HW11Ra-cdJ4=.be0a3036-d534-4d55-bf0f-3cc31d96770b@github.com>
Message-ID: <ElLz36oCQpLjKdILpi5oj1QwoLV5DP5ipkf_32ScJbc=.2155f998-614b-4885-855e-31140adffc13@github.com>

On Tue, 31 Aug 2021 22:00:34 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> 8273202: Ensure that parameter primitive record factories are generated.
> 
> Note that this fix requires JDK-8273018 (PR #541).

This pull request has been closed without being integrated.

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

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


From jespersm at openjdk.java.net  Tue Sep  7 23:45:18 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Tue, 7 Sep 2021 23:45:18 GMT
Subject: [lworld] RFR: 8273018: [lworld] Property annotation propagation
 to <init> lacks in primitive records [v2]
In-Reply-To: <Fjs2j_0gkEFj55ocHSSf3LB96RH3z3WYBqzof9FTieU=.ce6f8948-e848-46cf-b051-f37ffa7509a0@github.com>
References: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
 <Fjs2j_0gkEFj55ocHSSf3LB96RH3z3WYBqzof9FTieU=.ce6f8948-e848-46cf-b051-f37ffa7509a0@github.com>
Message-ID: <PZH8JcRGTYSTpZWb2WcDcA9NPzfA9GDIneiE8M70ONE=.5e7bcd3e-dada-4c0f-b5f7-3b7626f1b7f8@github.com>

On Tue, 7 Sep 2021 23:37:52 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> This fix copies parameter names and annotations from constructor into primitive class factory.
>
> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Emit parameter names (described JDK-8273202)
>   - Keep type parameters
>   - Provide useful test for primitive records in "RecordReading"

I combined this fix (which was incomplete, since it "de-erased" the method types incorrectly) with the fix for the problem in JDK-8273202, and a more useful example of incorrect compilation of primitive records.

I don't like hacking the erasure_field of the MethodSymbol, but I don't see another option, since the other lowering passes do similar nasty tricks when recording outer instances and capturing locals for inner classes.

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

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


From amenkov at openjdk.java.net  Wed Sep  8 23:23:39 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 8 Sep 2021 23:23:39 GMT
Subject: [lworld] RFR: 8267697: [lworld] [lw3] VM crashes during heap dump if
 Java heap contains flat arrays
Message-ID: <7KGcrQTSUVaJN4vVxFp_CaQd-ROFRtTnnyoSRKoak9U=.331c128c-5c38-40f3-b364-e0632c35377c@github.com>

Updated HeapDumper to generate HPROF_GC_INSTANCE_DUMP records for inlined objects (flattened fields and flattened arrays).
Field values of the inlined objects are read directly from container object/array

HPROF_GC_INSTANCE_DUMP record requires unique object ID (for identity objects address of the oop is used).
To generate it InlinedObjectSupport class is implemented which generates ID as 1,2,3,...
The idea is to write inlined objects in 2 pass:
- save state of DumpWriter::inlined_object_support;
- 1st pass (dumping parent object instance fields or array elements): write inlined object ids (generated by DumpWriter::inlined_object_support);
- 2nd pass: generate HPROF_GC_INSTANCE_DUMP record for inlined objects using ids from saved inlined_object_support.

2nd pass works the same way as dumping of parent object, so if inlined objects contain inlined fields HPROF_GC_INSTANCE_DUMP records will be generated for them after dumping of parent object is completed. The process is repeated recursively for all levels of inlined fields nesting.

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

Commit messages:
 - Updated heapDumper to support inlined objects

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

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


From thartmann at openjdk.java.net  Thu Sep  9 08:38:24 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Sep 2021 08:38:24 GMT
Subject: [lworld] RFR: 8273323: [lworld] Fix post-parse call devirtualization
 with inline type receiver
Message-ID: <ozdtQg3EDFOg5HVl0VDW8DoKxyoz3Ou50nnvk9HUEjg=.8254c160-615d-44f6-8e3e-77dfc45ed948@github.com>

Post-parse call devirtualization ([JDK-8257211](https://bugs.openjdk.java.net/browse/JDK-8257211)) converts virtual calls to static calls which allows an inline type receiver to be passed as fields and the corresponding buffer allocation to become useless.

Currently, new inline type nodes created during that optimization and also such useless buffer allocations are not removed, leading to missed optimization opportunities and asserts. The problem is that call devirtualization is only executed after macro expansion which removes useless buffer allocations. I've moved the optimization to before macro expansion and added an assert to ensure that we are not missing any optimization opportunities.

I had to cherry-pick the mainline fix for [JDK-8273409](https://bugs.openjdk.java.net/browse/JDK-8273409).

Best regards,
Tobias

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

Commit messages:
 - Added missing record_for_igvn calls, new test and cherry-picked JDK-8273409
 - 8273323: [lworld] Fix post-parse call devirtualization with inline type receiver

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

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


From dsimms at openjdk.java.net  Thu Sep  9 09:18:17 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 9 Sep 2021 09:18:17 GMT
Subject: [lworld] Withdrawn: Merge jdk
In-Reply-To: <yr_XRE08JelnOLTQWkLuA-Wy3dzKHWAw3YLLGHgnT4g=.3dc07715-0da5-439d-ba99-9400c0179cd8@github.com>
References: <yr_XRE08JelnOLTQWkLuA-Wy3dzKHWAw3YLLGHgnT4g=.3dc07715-0da5-439d-ba99-9400c0179cd8@github.com>
Message-ID: <9SO3bq5HprIKNMVesxzyE0CAZ1nOrRdoiwZZclLWIkk=.192439c7-86b6-48de-898f-898a02b2e93a@github.com>

On Tue, 7 Sep 2021 13:17:21 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-18+13'
> 
> # Conflicts:
> #	src/hotspot/share/opto/escape.cpp
> #	src/hotspot/share/opto/library_call.cpp
> #	src/java.base/share/classes/java/lang/runtime/ObjectMethods.java
> #	test/jdk/java/lang/runtime/ObjectMethodsTest.java

This pull request has been closed without being integrated.

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

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


From vlivanov at openjdk.java.net  Thu Sep  9 09:59:14 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 9 Sep 2021 09:59:14 GMT
Subject: [lworld] RFR: 8273323: [lworld] Fix post-parse call
 devirtualization with inline type receiver
In-Reply-To: <ozdtQg3EDFOg5HVl0VDW8DoKxyoz3Ou50nnvk9HUEjg=.8254c160-615d-44f6-8e3e-77dfc45ed948@github.com>
References: <ozdtQg3EDFOg5HVl0VDW8DoKxyoz3Ou50nnvk9HUEjg=.8254c160-615d-44f6-8e3e-77dfc45ed948@github.com>
Message-ID: <JXI0jBeZrzg27saeNE_SkxWSFVuu_0Q7VpxGhdr5kCM=.95c866c9-9a3d-422d-990c-c3c34d6afb6c@github.com>

On Thu, 9 Sep 2021 08:31:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Post-parse call devirtualization ([JDK-8257211](https://bugs.openjdk.java.net/browse/JDK-8257211)) converts virtual calls to static calls which allows an inline type receiver to be passed as fields and the corresponding buffer allocation to become useless.
> 
> Currently, new inline type nodes created during that optimization and also such useless buffer allocations are not removed, leading to missed optimization opportunities and asserts. The problem is that call devirtualization is only executed after macro expansion which removes useless buffer allocations. I've moved the optimization to before macro expansion and added an assert to ensure that we are not missing any optimization opportunities.
> 
> I had to cherry-pick the mainline fix for [JDK-8273409](https://bugs.openjdk.java.net/browse/JDK-8273409).
> 
> Best regards,
> Tobias

Looks good.

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

Marked as reviewed by vlivanov (Committer).

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


From thartmann at openjdk.java.net  Thu Sep  9 13:02:16 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Sep 2021 13:02:16 GMT
Subject: [lworld] RFR: 8273323: [lworld] Fix post-parse call
 devirtualization with inline type receiver
In-Reply-To: <ozdtQg3EDFOg5HVl0VDW8DoKxyoz3Ou50nnvk9HUEjg=.8254c160-615d-44f6-8e3e-77dfc45ed948@github.com>
References: <ozdtQg3EDFOg5HVl0VDW8DoKxyoz3Ou50nnvk9HUEjg=.8254c160-615d-44f6-8e3e-77dfc45ed948@github.com>
Message-ID: <feQP1kQIsGfItEFGn4BFO-RonLWH3MDO7HDmsONRQrw=.6094cf89-ffe0-465f-b327-c7d0de059de0@github.com>

On Thu, 9 Sep 2021 08:31:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Post-parse call devirtualization ([JDK-8257211](https://bugs.openjdk.java.net/browse/JDK-8257211)) converts virtual calls to static calls which allows an inline type receiver to be passed as fields and the corresponding buffer allocation to become useless.
> 
> Currently, new inline type nodes created during that optimization and also such useless buffer allocations are not removed, leading to missed optimization opportunities and asserts. The problem is that call devirtualization is only executed after macro expansion which removes useless buffer allocations. I've moved the optimization to before macro expansion and added an assert to ensure that we are not missing any optimization opportunities.
> 
> I had to cherry-pick the mainline fix for [JDK-8273409](https://bugs.openjdk.java.net/browse/JDK-8273409).
> 
> Best regards,
> Tobias

Thanks for the review, Vladimir!

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

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


From thartmann at openjdk.java.net  Thu Sep  9 13:45:29 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Sep 2021 13:45:29 GMT
Subject: [lworld] RFR: 8273554: [lworld] Runtime tests should not explicitly
 set -Xint/-Xcomp
Message-ID: <dUTou4rmHJQXlZSWX2JORhqLWLgRTnKSqrWlpqXT96Y=.d2a6311f-9147-4169-9f4f-525e78682aac@github.com>

Many of the runtime tests still specify multiple runs with `-Xint`/`-Xcomp`. Setting these flags explicitly reduces coverage because flag combinations set by the CI test jobs are overridden. We should simply not set them in the tests.

Thanks,
Tobias

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

Commit messages:
 - 8273554: [lworld] Runtime tests should not explicitly set -Xint/-Xcomp

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

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


From thartmann at openjdk.java.net  Thu Sep  9 13:47:15 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 9 Sep 2021 13:47:15 GMT
Subject: [lworld] Integrated: 8273323: [lworld] Fix post-parse call
 devirtualization with inline type receiver
In-Reply-To: <ozdtQg3EDFOg5HVl0VDW8DoKxyoz3Ou50nnvk9HUEjg=.8254c160-615d-44f6-8e3e-77dfc45ed948@github.com>
References: <ozdtQg3EDFOg5HVl0VDW8DoKxyoz3Ou50nnvk9HUEjg=.8254c160-615d-44f6-8e3e-77dfc45ed948@github.com>
Message-ID: <n_NCm5dumzEUbbJKMxWPq9zCGfJwGPMPwVk_xKz8Oig=.dcecfb5f-a659-4c25-b8ab-9889ec056e2f@github.com>

On Thu, 9 Sep 2021 08:31:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Post-parse call devirtualization ([JDK-8257211](https://bugs.openjdk.java.net/browse/JDK-8257211)) converts virtual calls to static calls which allows an inline type receiver to be passed as fields and the corresponding buffer allocation to become useless.
> 
> Currently, new inline type nodes created during that optimization and also such useless buffer allocations are not removed, leading to missed optimization opportunities and asserts. The problem is that call devirtualization is only executed after macro expansion which removes useless buffer allocations. I've moved the optimization to before macro expansion and added an assert to ensure that we are not missing any optimization opportunities.
> 
> I had to cherry-pick the mainline fix for [JDK-8273409](https://bugs.openjdk.java.net/browse/JDK-8273409).
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 252b04bf
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/252b04bf128e982b7d620952a6373bfae2170093
Stats:     83 lines in 5 files changed: 69 ins; 7 del; 7 mod

8273323: [lworld] Fix post-parse call devirtualization with inline type receiver

Reviewed-by: vlivanov

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

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


From fparain at openjdk.java.net  Thu Sep  9 16:01:18 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 9 Sep 2021 16:01:18 GMT
Subject: [lworld] RFR: 8273554: [lworld] Runtime tests should not
 explicitly set -Xint/-Xcomp
In-Reply-To: <dUTou4rmHJQXlZSWX2JORhqLWLgRTnKSqrWlpqXT96Y=.d2a6311f-9147-4169-9f4f-525e78682aac@github.com>
References: <dUTou4rmHJQXlZSWX2JORhqLWLgRTnKSqrWlpqXT96Y=.d2a6311f-9147-4169-9f4f-525e78682aac@github.com>
Message-ID: <f6hAD07oRz6rULzszvWowZLDRM3PYKB4klREYc_RcRY=.6c2bf2d0-d66c-44e7-86d4-45588e814c0a@github.com>

On Thu, 9 Sep 2021 13:40:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Many of the runtime tests still specify multiple runs with `-Xint`/`-Xcomp`. Setting these flags explicitly reduces coverage because flag combinations set by the CI test jobs are overridden. We should simply not set them in the tests.
> 
> Thanks,
> Tobias

Thank you for fixing those tests.

Fred

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

Marked as reviewed by fparain (Committer).

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


From thartmann at openjdk.java.net  Fri Sep 10 11:23:34 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 10 Sep 2021 11:23:34 GMT
Subject: [lworld] RFR: 8273554: [lworld] Runtime tests should not
 explicitly set -Xint/-Xcomp
In-Reply-To: <dUTou4rmHJQXlZSWX2JORhqLWLgRTnKSqrWlpqXT96Y=.d2a6311f-9147-4169-9f4f-525e78682aac@github.com>
References: <dUTou4rmHJQXlZSWX2JORhqLWLgRTnKSqrWlpqXT96Y=.d2a6311f-9147-4169-9f4f-525e78682aac@github.com>
Message-ID: <1nA6vw-vWNHpouH4na5IIbseWKrD5HZPrRMz_6sfyws=.7e4b6700-77d0-4aa2-ab51-0b537ecdeec9@github.com>

On Thu, 9 Sep 2021 13:40:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Many of the runtime tests still specify multiple runs with `-Xint`/`-Xcomp`. Setting these flags explicitly reduces coverage because flag combinations set by the CI test jobs are overridden. We should simply not set them in the tests.
> 
> Thanks,
> Tobias

Thanks, Frederic. I found [JDK-8273594](https://bugs.openjdk.java.net/browse/JDK-8273594) while testing and will fix that before integrating this change.

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

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


From thartmann at openjdk.java.net  Fri Sep 10 11:26:54 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 10 Sep 2021 11:26:54 GMT
Subject: [lworld] RFR: 8273594: [lworld] JITs need to properly handle static
 inline type field with unloaded type
Message-ID: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>

Both C1 and C2 do not properly handle loads from static inline type fields with an unloaded type. For C1, the fix is to simply remove two asserts that are too strong. For C2, we need to trap during typeflow analysis.

I've added a corresponding test to `TestUnloadedInlineTypeField.java` and noticed that the new IR Test Framework often triggers class loading while the test was carefully designed to avoid that. As a workaround, I slightly modified the framework and run the test with `-DIgnoreCompilerControls=true`. I filed [JDK-8273591](https://bugs.openjdk.java.net/browse/JDK-8273591) to fix this upstream.

I also fixed a `-XX:-XX:+PatchALot` typo in the test that went unnoticed because `-XX:+IgnoreUnrecognizedVMOptions` is set.

Thanks,
Tobias

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

Commit messages:
 - Don't modify do_Deoptimize
 - 8273594: [lworld] JITs need to properly handle static inline type field with unloaded type

Changes: https://git.openjdk.java.net/valhalla/pull/551/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=551&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273594
  Stats: 73 lines in 7 files changed: 52 ins; 7 del; 14 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/551.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/551/head:pull/551

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


From thartmann at openjdk.java.net  Fri Sep 10 12:43:40 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 10 Sep 2021 12:43:40 GMT
Subject: [lworld] RFR: 8273594: [lworld] JITs need to properly handle
 static inline type field with unloaded type [v2]
In-Reply-To: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
References: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
Message-ID: <kZjlYQJItrfWOq8tzUTo61tLDx1pQtmPZGGo-AW-Ju8=.5d840939-042a-4302-a83a-a589f7088ed8@github.com>

> Both C1 and C2 do not properly handle loads from static inline type fields with an unloaded type. For C1, the fix is to simply remove two asserts that are too strong. For C2, we need to trap during typeflow analysis.
> 
> I've added a corresponding test to `TestUnloadedInlineTypeField.java` and noticed that the new IR Test Framework often triggers class loading while the test was carefully designed to avoid that. As a workaround, I slightly modified the framework and run the test with `-DIgnoreCompilerControls=true`. I filed [JDK-8273591](https://bugs.openjdk.java.net/browse/JDK-8273591) to fix this upstream.
> 
> I also fixed a `-XX:-XX:+PatchALot` typo in the test that went unnoticed because `-XX:+IgnoreUnrecognizedVMOptions` is set.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Deoptimization does no longer support symbolic names for the class index, use a simple trap instead

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/551/files
  - new: https://git.openjdk.java.net/valhalla/pull/551/files/67815278..835a9005

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

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

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


From mchung at openjdk.java.net  Fri Sep 10 18:29:05 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 10 Sep 2021 18:29:05 GMT
Subject: [lworld] RFR: 8273360: [lworld] Invoking a reflection-generated
 constructor for primitive class gives InstantiationError
In-Reply-To: <E2vE7HSdk0GxjjbFLMUd78nPQkDFIUApxLD8dOAKFOg=.6c54a052-33a5-4bcd-8870-54888bc69981@github.com>
References: <E2vE7HSdk0GxjjbFLMUd78nPQkDFIUApxLD8dOAKFOg=.6c54a052-33a5-4bcd-8870-54888bc69981@github.com>
Message-ID: <N1SOimLvcMmQCGIKDnawV1viYNDde2iBWhbmBOuL3SQ=.0b099507-ec69-4a11-b6d2-d6448cd51ba1@github.com>

On Sun, 5 Sep 2021 13:33:26 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Update constructor accessor code generation to invoke static factory method.

@jespersm Thanks for fixing this.  A couple comments.

src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 52:

> 50:         emitInt(0xCAFEBABE);
> 51:         emitShort((short) 0);
> 52:         emitShort((short) 62);

This old bytecode generator does not support stack map and so these reflection classes would need to stay in version 49.   JEP 416 changes the core reflection implementation to build on top of method handles and no longer depends on this old bytecode generator.

src/java.base/share/classes/jdk/internal/reflect/MethodAccessorGenerator.java line 141:

> 139:         if (this.isConstructingPrimitive ) {
> 140:             returnType = declaringClass.asValueType();
> 141:         }

Alternatively, this method can take an additional `isStaticFactory` parameter.  `generateConstructor` will determine if the declaring class is a primitive class and then call the static factory with the return type argument rather than `Void.TYPE`.

test/jdk/valhalla/valuetypes/StaticFactoryTest.java line 74:

> 72:             Object o = ctor.newInstance();
> 73:             assertTrue(o.getClass() == PRIMITIVE_TYPE.asPrimaryType());
> 74:         }

I suggest to replace this change with `@run testng/othervm -Dsun.reflect.noInflation=true StaticFactoryTest` so that other test cases will also verify when it's run with the generated bytecode.

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

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


From thartmann at openjdk.java.net  Mon Sep 13 09:14:17 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 13 Sep 2021 09:14:17 GMT
Subject: git: openjdk/valhalla: lworld: 8273554: [lworld] Runtime tests should
 not explicitly set -Xint/-Xcomp
Message-ID: <2980ef5e-2567-4fef-9a0c-e92be30045b9@openjdk.org>

Changeset: 31111249
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2021-09-13 09:13:54 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/3111124930c34bab1bd38907ecc32c82557bc019

8273554: [lworld] Runtime tests should not explicitly set -Xint/-Xcomp

Reviewed-by: fparain

! test/hotspot/jtreg/runtime/valhalla/inlinetypes/CheckcastTest.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/CircularityTest.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/CreationErrorTest.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/FlattenableSemanticTest.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/Ifacmp.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineOops.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineTypeArray.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineTypeCreation.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineTypeDensity.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineTypeGetField.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineTypesTest.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineWithJni.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/ObjectMethods.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/QuickeningTest.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/StaticFieldsTest.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/Test8186715.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/TestFieldNullability.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/UninitializedInlineFieldsTest.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/UnsafeTest.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/VDefaultTest.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/VWithFieldTest.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/ValueTearing.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/VarArgsArray.java
! test/jdk/valhalla/valuetypes/ObjectMethods.java
! test/jdk/valhalla/valuetypes/SubstitutabilityTest.java



From thartmann at openjdk.java.net  Mon Sep 13 09:17:30 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 13 Sep 2021 09:17:30 GMT
Subject: [lworld] RFR: 8273554: [lworld] Runtime tests should not
 explicitly set -Xint/-Xcomp [v2]
In-Reply-To: <dUTou4rmHJQXlZSWX2JORhqLWLgRTnKSqrWlpqXT96Y=.d2a6311f-9147-4169-9f4f-525e78682aac@github.com>
References: <dUTou4rmHJQXlZSWX2JORhqLWLgRTnKSqrWlpqXT96Y=.d2a6311f-9147-4169-9f4f-525e78682aac@github.com>
Message-ID: <f1V_RkaDkUmkZzV0cO45Jqr81KnxwxoSRACJLNPyL78=.7030c87e-4409-4403-9297-904123c03189@github.com>

> Many of the runtime tests still specify multiple runs with `-Xint`/`-Xcomp`. Setting these flags explicitly reduces coverage because flag combinations set by the CI test jobs are overridden. We should simply not set them in the tests.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Run CircularityTest with -Xint until JDK-8273594 is fixed

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/550/files
  - new: https://git.openjdk.java.net/valhalla/pull/550/files/9c8dbed6..14c04a4b

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

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

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


From thartmann at openjdk.java.net  Mon Sep 13 09:17:33 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 13 Sep 2021 09:17:33 GMT
Subject: [lworld] RFR: 8273554: [lworld] Runtime tests should not
 explicitly set -Xint/-Xcomp
In-Reply-To: <dUTou4rmHJQXlZSWX2JORhqLWLgRTnKSqrWlpqXT96Y=.d2a6311f-9147-4169-9f4f-525e78682aac@github.com>
References: <dUTou4rmHJQXlZSWX2JORhqLWLgRTnKSqrWlpqXT96Y=.d2a6311f-9147-4169-9f4f-525e78682aac@github.com>
Message-ID: <7KEE_AIOZco6xhfh4NraoPZrHHuD7jFkfbklF_fbSbE=.23d10d74-60a2-46e8-950c-8ae1fa0b99e0@github.com>

On Thu, 9 Sep 2021 13:40:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Many of the runtime tests still specify multiple runs with `-Xint`/`-Xcomp`. Setting these flags explicitly reduces coverage because flag combinations set by the CI test jobs are overridden. We should simply not set them in the tests.
> 
> Thanks,
> Tobias

I found more issues with CircularityTest that I need to fix with JDK-8273594. I re-added `-Xint` for now. Will remove it once JDK-8273594 is in.

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

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


From thartmann at openjdk.java.net  Mon Sep 13 09:17:33 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 13 Sep 2021 09:17:33 GMT
Subject: [lworld] Integrated: 8273554: [lworld] Runtime tests should not
 explicitly set -Xint/-Xcomp
In-Reply-To: <dUTou4rmHJQXlZSWX2JORhqLWLgRTnKSqrWlpqXT96Y=.d2a6311f-9147-4169-9f4f-525e78682aac@github.com>
References: <dUTou4rmHJQXlZSWX2JORhqLWLgRTnKSqrWlpqXT96Y=.d2a6311f-9147-4169-9f4f-525e78682aac@github.com>
Message-ID: <mGeApza-6SlP5qDry4KDr_bp6C7_V9qa2bPTbJqoUU0=.dcfe42ec-cf95-4986-91fd-58e73e6c349d@github.com>

On Thu, 9 Sep 2021 13:40:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Many of the runtime tests still specify multiple runs with `-Xint`/`-Xcomp`. Setting these flags explicitly reduces coverage because flag combinations set by the CI test jobs are overridden. We should simply not set them in the tests.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 31111249
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/3111124930c34bab1bd38907ecc32c82557bc019
Stats:     155 lines in 25 files changed: 0 ins; 91 del; 64 mod

8273554: [lworld] Runtime tests should not explicitly set -Xint/-Xcomp

Reviewed-by: fparain

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

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


From thartmann at openjdk.java.net  Mon Sep 13 12:28:34 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 13 Sep 2021 12:28:34 GMT
Subject: [lworld] RFR: 8273594: [lworld] JITs need to properly handle
 static inline type field with unloaded type [v3]
In-Reply-To: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
References: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
Message-ID: <6Jg4iTlkwnZv7xM06aj3V0T_fPDQTf_dkSWlr0ZhEjw=.1f4ecd34-8ca1-418a-a5d8-2b9284dfb804@github.com>

> Both C1 and C2 do not properly handle loads from static inline type fields with an unloaded type. For C1, the fix is to simply remove two asserts that are too strong. For C2, we need to trap during typeflow analysis.
> 
> I've added a corresponding test to `TestUnloadedInlineTypeField.java` and noticed that the new IR Test Framework often triggers class loading while the test was carefully designed to avoid that. As a workaround, I slightly modified the framework and run the test with `-DIgnoreCompilerControls=true`. I filed [JDK-8273591](https://bugs.openjdk.java.net/browse/JDK-8273591) to fix this upstream.
> 
> I also fixed a `-XX:-XX:+PatchALot` typo in the test that went unnoticed because `-XX:+IgnoreUnrecognizedVMOptions` is set.
> 
> Thanks,
> Tobias

Tobias Hartmann 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 six additional commits since the last revision:

 - Remove -Xint from CircularityTest
 - Merge branch 'lworld' into JDK-8273594
 - Check for uninitialized class
 - Deoptimization does no longer support symbolic names for the class index, use a simple trap instead
 - Don't modify do_Deoptimize
 - 8273594: [lworld] JITs need to properly handle static inline type field with unloaded type

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/551/files
  - new: https://git.openjdk.java.net/valhalla/pull/551/files/835a9005..4444d91f

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

  Stats: 367 lines in 29 files changed: 194 ins; 95 del; 78 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/551.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/551/head:pull/551

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


From thartmann at openjdk.java.net  Mon Sep 13 12:46:29 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 13 Sep 2021 12:46:29 GMT
Subject: [lworld] RFR: 8273594: [lworld] JITs need to properly handle
 static inline type field with unloaded type [v4]
In-Reply-To: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
References: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
Message-ID: <jE7NA3t4y21RFjkbHOeAx0AdtySrzM2SfO7qV3jgXxc=.e8b3eddf-e8a7-44ea-937b-eccac2faaed8@github.com>

> Both C1 and C2 do not properly handle loads from static inline type fields with an unloaded type. For C1, the fix is to simply remove two asserts that are too strong. For C2, we need to trap during typeflow analysis.
> 
> I've added a corresponding test to `TestUnloadedInlineTypeField.java` and noticed that the new IR Test Framework often triggers class loading while the test was carefully designed to avoid that. As a workaround, I slightly modified the framework and run the test with `-DIgnoreCompilerControls=true`. I filed [JDK-8273591](https://bugs.openjdk.java.net/browse/JDK-8273591) to fix this upstream.
> 
> I also fixed a `-XX:-XX:+PatchALot` typo in the test that went unnoticed because `-XX:+IgnoreUnrecognizedVMOptions` is set.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Fix

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/551/files
  - new: https://git.openjdk.java.net/valhalla/pull/551/files/4444d91f..35a1c2a7

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

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

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


From thartmann at openjdk.java.net  Mon Sep 13 12:46:34 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 13 Sep 2021 12:46:34 GMT
Subject: [lworld] RFR: 8273594: [lworld] JITs need to properly handle
 static inline type field with unloaded type [v3]
In-Reply-To: <6Jg4iTlkwnZv7xM06aj3V0T_fPDQTf_dkSWlr0ZhEjw=.1f4ecd34-8ca1-418a-a5d8-2b9284dfb804@github.com>
References: <uPweAoF22kAWQm9HkrVzjfMKFVX5oPKSebzfZxM3T0c=.fd587868-4259-4943-9780-3dd5cd17c795@github.com>
 <6Jg4iTlkwnZv7xM06aj3V0T_fPDQTf_dkSWlr0ZhEjw=.1f4ecd34-8ca1-418a-a5d8-2b9284dfb804@github.com>
Message-ID: <NTbrpb3bJBQdN-0x3S7gBIuG9T4uLdDb7fFynAtAhDY=.fdcded26-bbb1-45e3-935c-e38690365f47@github.com>

On Mon, 13 Sep 2021 12:28:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Both C1 and C2 do not properly handle loads from static inline type fields with an unloaded type. For C1, the fix is to simply remove two asserts that are too strong. For C2, we need to trap during typeflow analysis.
>> 
>> I've added a corresponding test to `TestUnloadedInlineTypeField.java` and noticed that the new IR Test Framework often triggers class loading while the test was carefully designed to avoid that. As a workaround, I slightly modified the framework and run the test with `-DIgnoreCompilerControls=true`. I filed [JDK-8273591](https://bugs.openjdk.java.net/browse/JDK-8273591) to fix this upstream.
>> 
>> I also fixed a `-XX:-XX:+PatchALot` typo in the test that went unnoticed because `-XX:+IgnoreUnrecognizedVMOptions` is set.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann 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 six additional commits since the last revision:
> 
>  - Remove -Xint from CircularityTest
>  - Merge branch 'lworld' into JDK-8273594
>  - Check for uninitialized class
>  - Deoptimization does no longer support symbolic names for the class index, use a simple trap instead
>  - Don't modify do_Deoptimize
>  - 8273594: [lworld] JITs need to properly handle static inline type field with unloaded type

I found more issues with uninitialized classes and fixed them. The new tests currently trigger [JDK-8273650](https://bugs.openjdk.java.net/browse/JDK-8273650), so I'll wait with integration until that is fixed.

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

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


From dsimms at openjdk.java.net  Mon Sep 13 12:46:52 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 13 Sep 2021 12:46:52 GMT
Subject: [lworld] RFR: 8270477: [lworld] bytecode testing API does not emit Q
 type descriptors
Message-ID: <0ldIwIU2zQKTs1ZrFT03f3GZrkBrYDx_E0m2GyokGHE=.025f4614-dac5-4613-a78a-7091bec93488@github.com>

Fixed bytecodes that need to emit full type descriptors (with their "envelopes") for Q-types

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

Commit messages:
 - 8270477: [lworld] bytecode testing API does not emit Q type descriptors

Changes: https://git.openjdk.java.net/valhalla/pull/552/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=552&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270477
  Stats: 413 lines in 4 files changed: 203 ins; 202 del; 8 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/552.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/552/head:pull/552

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


From amenkov at openjdk.java.net  Mon Sep 13 19:43:27 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 13 Sep 2021 19:43:27 GMT
Subject: [lworld] Integrated: 8267697: [lworld] [lw3] VM crashes during heap
 dump if Java heap contains flat arrays
In-Reply-To: <7KGcrQTSUVaJN4vVxFp_CaQd-ROFRtTnnyoSRKoak9U=.331c128c-5c38-40f3-b364-e0632c35377c@github.com>
References: <7KGcrQTSUVaJN4vVxFp_CaQd-ROFRtTnnyoSRKoak9U=.331c128c-5c38-40f3-b364-e0632c35377c@github.com>
Message-ID: <5heOHjojpZq183mDnNByVxCNcK3rMQ4FcmKBpEIMjpw=.de30034e-e0cc-4e9e-9306-451e1e3fcd67@github.com>

On Wed, 8 Sep 2021 23:18:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Updated HeapDumper to generate HPROF_GC_INSTANCE_DUMP records for inlined objects (flattened fields and flattened arrays).
> Field values of the inlined objects are read directly from container object/array
> 
> HPROF_GC_INSTANCE_DUMP record requires unique object ID (for identity objects address of the oop is used).
> To generate it InlinedObjectSupport class is implemented which generates ID as 1,2,3,...
> The idea is to write inlined objects in 2 pass:
> - save state of DumpWriter::inlined_object_support;
> - 1st pass (dumping parent object instance fields or array elements): write inlined object ids (generated by DumpWriter::inlined_object_support);
> - 2nd pass: generate HPROF_GC_INSTANCE_DUMP record for inlined objects using ids from saved inlined_object_support.
> 
> 2nd pass works the same way as dumping of parent object, so if inlined objects contain inlined fields HPROF_GC_INSTANCE_DUMP records will be generated for them after dumping of parent object is completed. The process is repeated recursively for all levels of inlined fields nesting.

This pull request has now been integrated.

Changeset: 0c0c9e17
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/0c0c9e176e3be05ae46a0f8f1722aff879c8d197
Stats:     671 lines in 3 files changed: 631 ins; 3 del; 37 mod

8267697: [lworld] [lw3] VM crashes during heap dump if Java heap contains flat arrays

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

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


From mchung at openjdk.java.net  Mon Sep 13 21:06:38 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 13 Sep 2021 21:06:38 GMT
Subject: [lworld] RFR: 8270477: [lworld] bytecode testing API does not
 emit Q type descriptors
In-Reply-To: <0ldIwIU2zQKTs1ZrFT03f3GZrkBrYDx_E0m2GyokGHE=.025f4614-dac5-4613-a78a-7091bec93488@github.com>
References: <0ldIwIU2zQKTs1ZrFT03f3GZrkBrYDx_E0m2GyokGHE=.025f4614-dac5-4613-a78a-7091bec93488@github.com>
Message-ID: <NSkTOH_4PmOkS3ZMtKJLlqGHjHSgSx_pCRwhbGPz6jI=.b4d09ce9-f96c-47d1-94d6-7f82c60e61e7@github.com>

On Mon, 13 Sep 2021 12:39:02 GMT, David Simms <dsimms at openjdk.org> wrote:

> Fixed bytecodes that need to emit full type descriptors (with their "envelopes") for Q-types

Looks okay to me.

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

Marked as reviewed by mchung (Committer).

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


From dsimms at openjdk.java.net  Tue Sep 14 08:17:42 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 14 Sep 2021 08:17:42 GMT
Subject: [lworld] Integrated: 8270477: [lworld] bytecode testing API does not
 emit Q type descriptors
In-Reply-To: <0ldIwIU2zQKTs1ZrFT03f3GZrkBrYDx_E0m2GyokGHE=.025f4614-dac5-4613-a78a-7091bec93488@github.com>
References: <0ldIwIU2zQKTs1ZrFT03f3GZrkBrYDx_E0m2GyokGHE=.025f4614-dac5-4613-a78a-7091bec93488@github.com>
Message-ID: <u-gwDtU3b0VPxcQCemjrEHrRGCRlRBqh8CBPjeoLYnE=.d9080eef-0eb3-46bf-984a-97f7e96cc903@github.com>

On Mon, 13 Sep 2021 12:39:02 GMT, David Simms <dsimms at openjdk.org> wrote:

> Fixed bytecodes that need to emit full type descriptors (with their "envelopes") for Q-types

This pull request has now been integrated.

Changeset: e075eaf3
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e075eaf3078a95904eaab48d5600be76ddde7816
Stats:     413 lines in 4 files changed: 203 ins; 202 del; 8 mod

8270477: [lworld] bytecode testing API does not emit Q type descriptors

Reviewed-by: mchung

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

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


From sadayapalam at openjdk.java.net  Tue Sep 14 09:17:31 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 14 Sep 2021 09:17:31 GMT
Subject: [lworld] RFR: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
Message-ID: <8qgBfoeeX_LysOa4Kjfa6NPwP8paqELJXKnlQQxxqR0=.84174928-bf67-4009-961a-5874e45ff84c@github.com>

On Thu, 2 Sep 2021 20:10:36 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.

Looks good to me - However, I would like to ask Mandy whether we are working around a problem in the runtime that should really be fixed there. @mlchung Could you please take a look at the code generated with and without fix and see if the change in javac emitted code is the proper way for this to be fixed ? 

The failure mode is

Caused by: java.lang.invoke.LambdaConversionException: Invalid receiver type primitive X; not a subtype of implementation type primitive X


The failing code being:

public java.util.function.Supplier<X> makeCopier();
    descriptor: ()Ljava/util/function/Supplier;
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokedynamic #7,  0              // InvokeDynamic #0:get:(LX;)Ljava/util/function/Supplier;
         6: areturn
      LineNumberTable:
        line 12: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       7     0  this   QX;


and the patch here alters the generated code to be:

 public java.util.function.Supplier<X> makeCopier();
    descriptor: ()Ljava/util/function/Supplier;
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokedynamic #7,  0              // InvokeDynamic #0:get:(QX;)Ljava/util/function/Supplier;
         6: areturn
      LineNumberTable:
        line 12: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       7     0  this   QX;

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

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


From sadayapalam at openjdk.java.net  Tue Sep 14 09:24:49 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 14 Sep 2021 09:24:49 GMT
Subject: [lworld] RFR: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
Message-ID: <fvW-3_QHYzPdulnLVZcoyzIhECiM4vInKRZM2ITjk4A=.def84b9c-77b8-4f33-8794-43520b3c9fcf@github.com>

On Thu, 2 Sep 2021 20:10:36 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.

Still says title mismatch - Not sure why

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

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


From sadayapalam at openjdk.java.net  Wed Sep 15 09:30:56 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 15 Sep 2021 09:30:56 GMT
Subject: [lworld] RFR: 8273018: [lworld] Property annotation propagation
 to <init> lacks in primitive records [v2]
In-Reply-To: <Fjs2j_0gkEFj55ocHSSf3LB96RH3z3WYBqzof9FTieU=.ce6f8948-e848-46cf-b051-f37ffa7509a0@github.com>
References: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
 <Fjs2j_0gkEFj55ocHSSf3LB96RH3z3WYBqzof9FTieU=.ce6f8948-e848-46cf-b051-f37ffa7509a0@github.com>
Message-ID: <FyB3b0Nc3xYGhl3Iuin_oBDMzrU7X_PYbjPtZYKDp9k=.3799baec-d6c4-456e-bec8-bb7e8eff7629@github.com>

On Tue, 7 Sep 2021 23:37:52 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> This fix copies parameter names and annotations from constructor into primitive class factory.
>
> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Emit parameter names (described JDK-8273202)
>   - Keep type parameters
>   - Provide useful test for primitive records in "RecordReading"

Changes requested by sadayapalam (Committer).

If you want to close more than issue with the same PR, I think you need to add the other issue here with /issue 

Also please mention what tests have been run. Thanks

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

> 1020:                 || m.isConstructor() && (m.flags_field & RECORD) != 0
> 1021:                 || m.isPrimitiveObjectFactory() && (m.flags_field & RECORD) != 0)) {
> 1022:             if (!m.isLambdaMethod()) // Per JDK-8138729, do not emit parameters table for lambda bodies.

Can you fold the two checks for (m.flags_field & RECORD) != 0 into one here ??

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/TransPrimitiveClass.java line 394:

> 392:         MethodType factoryType = new MethodType(init.type.getParameterTypes(),
> 393:                                                 init.owner.type.asValueType(),
> 394:                                                 init.type.getThrownTypes(),

I am lost and need a bit of help here. What exactly is the change and why is it needed ?

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/TransPrimitiveClass.java line 406:

> 404:                 init.type.getThrownTypes(),
> 405:                 init.owner.type.tsym);
> 406:         factory.setAttributes(init);

Again, I need some help with this change. I understand the part of parameters being carried over, but the dance around recomputation of erasure field - what exactly is the material change there ?? I can see the RecordReading test failing if I backout the changes here (except for factory.params = init.params) but need some explanation - TIA

test/langtools/tools/javac/records/RecordReading.java line 131:

> 129:     @Test
> 130:     public void testPrimitiveRecordClassFileReading(Path base) throws Exception {
> 131:         Path src = base.resolve("src");

Could you please update the copyright to 2021 and also add a @bug id line to the test spec ? Thanks

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

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


From fparain at openjdk.java.net  Wed Sep 15 19:47:59 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 15 Sep 2021 19:47:59 GMT
Subject: [lworld] RFR: 8273650: [lworld] Interpreter fails with fatal error:
 DEBUG MESSAGE: klass not initialized
Message-ID: <5OmiHCp8Lx3gQGU1QR2Ws7Qj4Ab8D9gm5d82d36EzGA=.e7dec0dd-00be-4423-8059-58d3d5362cf2@github.com>

Please review those changes fixing handling of class initialization failures and adding unit tests to cover several failure scenarios and some corner cases (handling of instances from a failed initialization class).

Thank you,

Fred

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

Commit messages:
 - Fixing handling of class initialization failures

Changes: https://git.openjdk.java.net/valhalla/pull/553/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=553&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273650
  Stats: 251 lines in 4 files changed: 228 ins; 16 del; 7 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/553.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/553/head:pull/553

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


From mchung at openjdk.java.net  Thu Sep 16 01:06:25 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 16 Sep 2021 01:06:25 GMT
Subject: [lworld] RFR: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
Message-ID: <-CspCmmrUaaQ-eOg73mgLrUqfhpiqelGcl8xt7ogkeY=.8284fb7c-27ef-4c56-b56c-b42d319d77bd@github.com>

On Thu, 2 Sep 2021 20:10:36 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.

A reference to a primitive object can be converted to a primitive value and vice versa.  So I think the runtime should allow the receiver type of `factoryType` is a primitive reference type whereas the implementation type is a primitive value type of the same primitive class.

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

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


From mchung at openjdk.java.net  Thu Sep 16 16:26:56 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 16 Sep 2021 16:26:56 GMT
Subject: [lworld] RFR: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
Message-ID: <KNXqNAVE5G0ei11SnJg0pvwc4nmqBN_7l-93i2lsm5k=.5f997508-af0f-48b0-8a61-e488aa3806fa@github.com>

On Thu, 2 Sep 2021 20:10:36 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.

I'm not sure if the javac fix is needed.   The `factoryType` describes the `CallSite` signature.   @dansmithcode can you confirm if `(LX;)Ljava/util/function/Supplier;` is considered as a valid signature where `X` is primitive class?  If valid, this issue does not require javac fix.

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

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


From dlsmith at openjdk.java.net  Thu Sep 16 20:39:54 2021
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Thu, 16 Sep 2021 20:39:54 GMT
Subject: [lworld] RFR: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
Message-ID: <YlJfgr1mpkR43f7t5HFccsxOror9L8OS7Uj-x1fE4i0=.4bf5b037-9700-4e57-b525-8beb278f5bfa@github.com>

On Thu, 2 Sep 2021 20:10:36 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.

The Java 17 version of LambdaMetafactory requires that the parameter types of `factoryType` exactly match the implementation types.

I'm not sure whether there have been modifications in Valhalla. We could conceivably make some changes if it's useful.

Eventually, we'd like to align the conversions supported by LambdaMetafactory for all parameters/returns with those supported by `asType` (JDK-8174983). But I'm not sure which conversions `asType` would support in the context of Valhalla...

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

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


From jespersm at openjdk.java.net  Thu Sep 16 23:26:56 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 16 Sep 2021 23:26:56 GMT
Subject: [lworld] RFR: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
Message-ID: <07K51xuXjhGoN3hWSKksVc7eP7rnca2GtQmhpqNpiSQ=.624f6d02-1fd6-4f0f-b001-f6e184efefc3@github.com>

On Thu, 2 Sep 2021 20:10:36 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.

The change to the runtime in JDK-8174983 will allow boxing and unboxing: In lworld terms, I suppose this would map to turning a QFoo (primitive class on-stack) into an LFoo (reference to primitive class), and vice versa (although I'm not sure how null references would be handled). There are obvious reasons why this is a useful feature for LambdaMetafactory.

However, I find it odd for javac *not* to generate identical code for a callsite depending on whether or not the enclosing class is "reference-favoring" or not. This should only influence _uses_ of the type, not the type itself. Primitive class instance methods should still "operate on" instances (QFoo), not references to instance (LFoo).

So, I think that the javac should be consistent regarding the emitting of receiver-types, even if for the sake of the conceptual consistency itself.

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

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


From jespersm at openjdk.java.net  Thu Sep 16 23:32:56 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 16 Sep 2021 23:32:56 GMT
Subject: [lworld] RFR: 8273018: [lworld] Property annotation propagation
 to <init> lacks in primitive records [v2]
In-Reply-To: <FyB3b0Nc3xYGhl3Iuin_oBDMzrU7X_PYbjPtZYKDp9k=.3799baec-d6c4-456e-bec8-bb7e8eff7629@github.com>
References: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
 <Fjs2j_0gkEFj55ocHSSf3LB96RH3z3WYBqzof9FTieU=.ce6f8948-e848-46cf-b051-f37ffa7509a0@github.com>
 <FyB3b0Nc3xYGhl3Iuin_oBDMzrU7X_PYbjPtZYKDp9k=.3799baec-d6c4-456e-bec8-bb7e8eff7629@github.com>
Message-ID: <6DDg3Ybo-eLafBZs6dT88unhTw0Ub46g3g-03cDW0wY=.ae529096-244b-4890-b343-b7059fbb83ac@github.com>

On Wed, 15 Sep 2021 09:24:32 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:
>> 
>>   - Emit parameter names (described JDK-8273202)
>>   - Keep type parameters
>>   - Provide useful test for primitive records in "RecordReading"
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/TransPrimitiveClass.java line 394:
> 
>> 392:         MethodType factoryType = new MethodType(init.type.getParameterTypes(),
>> 393:                                                 init.owner.type.asValueType(),
>> 394:                                                 init.type.getThrownTypes(),
> 
> I am lost and need a bit of help here. What exactly is the change and why is it needed ?

This method makes a primitive object factory from the parsed constructor. In the current version, the parameter types are erased and their annotations, and original method signature, are erased from the original. This line preserves this information, so the generated classfile is correct.

See next comment.

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

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


From jespersm at openjdk.java.net  Thu Sep 16 23:45:59 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 16 Sep 2021 23:45:59 GMT
Subject: [lworld] RFR: 8273018: [lworld] Property annotation propagation
 to <init> lacks in primitive records [v2]
In-Reply-To: <FyB3b0Nc3xYGhl3Iuin_oBDMzrU7X_PYbjPtZYKDp9k=.3799baec-d6c4-456e-bec8-bb7e8eff7629@github.com>
References: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
 <Fjs2j_0gkEFj55ocHSSf3LB96RH3z3WYBqzof9FTieU=.ce6f8948-e848-46cf-b051-f37ffa7509a0@github.com>
 <FyB3b0Nc3xYGhl3Iuin_oBDMzrU7X_PYbjPtZYKDp9k=.3799baec-d6c4-456e-bec8-bb7e8eff7629@github.com>
Message-ID: <j6LUhkx_WIj1wNMAE907rP3EFMghzLgJsnLjDn8Zq2M=.d88d92b9-9c65-444d-9ed2-676ee43d43d0@github.com>

On Wed, 15 Sep 2021 09:26:37 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:
>> 
>>   - Emit parameter names (described JDK-8273202)
>>   - Keep type parameters
>>   - Provide useful test for primitive records in "RecordReading"
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/TransPrimitiveClass.java line 406:
> 
>> 404:                 init.type.getThrownTypes(),
>> 405:                 init.owner.type.tsym);
>> 406:         factory.setAttributes(init);
> 
> Again, I need some help with this change. I understand the part of parameters being carried over, but the dance around recomputation of erasure field - what exactly is the material change there ?? I can see the RecordReading test failing if I backout the changes here (except for factory.params = init.params) but need some explanation - TIA

Related to comment above: Since we're now preserving the full type information for `factoryType` and thus `factory`, instead of propagating the erased info, information from the other (preceding) lowerings would get lost. To avoid that, the erasure is explicitly reconstructed, but with a fixed return type (instead of void).

There is a different test which blows up if this isn't reconstructed, it might be `InnerValueNew.java` (I'll check later).

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

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


From mchung at openjdk.java.net  Fri Sep 17 00:14:54 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 17 Sep 2021 00:14:54 GMT
Subject: [lworld] RFR: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
Message-ID: <uyFS39tIEVFQmeocktDeghyLs8O0NNs4TFKr77k8yNg=.899d4852-d40d-4ac9-9d06-83adb03e1c1b@github.com>

On Thu, 2 Sep 2021 20:10:36 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.

I discussed with Dan offline to follow up my question in what cases javac should emit `(LFoo;)LR;` vs `(QFoo;)LR;`.   For the lambda case, having the receiver type as `QFoo;` is a good thing to do as it's an instance method of the enclosing class. 

For a method reference `o::m` where `o` is of primitive reference type, the factory type would be `(LFoo;)LR;`.   I have a test case that verifies the emitted code is:

28: invokedynamic #38,  0             // InvokeDynamic #1:get:(LX;)Ljava/util/function/Supplier;

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

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


From dsimms at openjdk.java.net  Fri Sep 17 06:49:53 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 17 Sep 2021 06:49:53 GMT
Subject: [lworld] RFR: 8273650: [lworld] Interpreter fails with fatal
 error: DEBUG MESSAGE: klass not initialized
In-Reply-To: <5OmiHCp8Lx3gQGU1QR2Ws7Qj4Ab8D9gm5d82d36EzGA=.e7dec0dd-00be-4423-8059-58d3d5362cf2@github.com>
References: <5OmiHCp8Lx3gQGU1QR2Ws7Qj4Ab8D9gm5d82d36EzGA=.e7dec0dd-00be-4423-8059-58d3d5362cf2@github.com>
Message-ID: <XYdQ8pjOT184fTU7n6FWIxg0dGaWNmpOOBK5uA1wVvs=.8b576403-2066-41ec-90af-e07eebf34680@github.com>

On Wed, 15 Sep 2021 19:40:38 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes fixing handling of class initialization failures and adding unit tests to cover several failure scenarios and some corner cases (handling of instances from a failed initialization class).
> 
> Thank you,
> 
> Fred

Looking good !

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

Marked as reviewed by dsimms (Committer).

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


From thartmann at openjdk.java.net  Fri Sep 17 13:35:57 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 17 Sep 2021 13:35:57 GMT
Subject: [lworld] RFR: 8273650: [lworld] Interpreter fails with fatal
 error: DEBUG MESSAGE: klass not initialized
In-Reply-To: <5OmiHCp8Lx3gQGU1QR2Ws7Qj4Ab8D9gm5d82d36EzGA=.e7dec0dd-00be-4423-8059-58d3d5362cf2@github.com>
References: <5OmiHCp8Lx3gQGU1QR2Ws7Qj4Ab8D9gm5d82d36EzGA=.e7dec0dd-00be-4423-8059-58d3d5362cf2@github.com>
Message-ID: <rAg980_AobJe26clgjh7PYaeg3FY_kakZzEx5u0oLwQ=.b29041a5-c37b-42d0-9543-78e1e1003e64@github.com>

On Wed, 15 Sep 2021 19:40:38 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes fixing handling of class initialization failures and adding unit tests to cover several failure scenarios and some corner cases (handling of instances from a failed initialization class).
> 
> Thank you,
> 
> Fred

Test looks good, just noticed some typos. I'll verify that it passes with the JIT before integrating JDK-8273594.

test/hotspot/jtreg/runtime/valhalla/inlinetypes/ClassInitializationFailuresTest.java line 32:

> 30: * @summary Test several scenarios of class initialization failures
> 31: * @library /test/lib
> 32: * @run main/othervm  runtime.valhalla.inlinetypes.ClassInitializationFailuresTest

Just noticed that the `/othervm`  part can be removed because no flags are set. Also, the test should use 4-whitespace indentation.

test/hotspot/jtreg/runtime/valhalla/inlinetypes/ClassInitializationFailuresTest.java line 61:

> 59:   // because an exception has been thrown during the initialization process
> 60:   // Second attempt to instantiate TestClass1 must fail with a NoClassDefFoundError
> 61:   // because TestClass1 must already be in a faile initialization state (so no new

"faile" -> "failed"

test/hotspot/jtreg/runtime/valhalla/inlinetypes/ClassInitializationFailuresTest.java line 153:

> 151:   }
> 152: 
> 153:   // Even if a primitive class fails to initialize property, some instances

"property" -> "properly"

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

Marked as reviewed by thartmann (Committer).

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


From fparain at openjdk.java.net  Fri Sep 17 19:35:47 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 17 Sep 2021 19:35:47 GMT
Subject: [lworld] RFR: 8273650: [lworld] Interpreter fails with fatal
 error: DEBUG MESSAGE: klass not initialized [v2]
In-Reply-To: <5OmiHCp8Lx3gQGU1QR2Ws7Qj4Ab8D9gm5d82d36EzGA=.e7dec0dd-00be-4423-8059-58d3d5362cf2@github.com>
References: <5OmiHCp8Lx3gQGU1QR2Ws7Qj4Ab8D9gm5d82d36EzGA=.e7dec0dd-00be-4423-8059-58d3d5362cf2@github.com>
Message-ID: <_FvHQYRH98WCz1VUHM1jELvIGn6uX_9t4PBD1eUF9io=.2de407d6-0c0d-405a-b840-ef186c775268@github.com>

> Please review those changes fixing handling of class initialization failures and adding unit tests to cover several failure scenarios and some corner cases (handling of instances from a failed initialization class).
> 
> Thank you,
> 
> Fred

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

  Fix typos

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/553/files
  - new: https://git.openjdk.java.net/valhalla/pull/553/files/728aaaba..a5f13d42

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

  Stats: 245 lines in 1 file changed: 87 ins; 90 del; 68 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/553.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/553/head:pull/553

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


From fparain at openjdk.java.net  Fri Sep 17 19:35:50 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 17 Sep 2021 19:35:50 GMT
Subject: [lworld] Integrated: 8273650: [lworld] Interpreter fails with fatal
 error: DEBUG MESSAGE: klass not initialized
In-Reply-To: <5OmiHCp8Lx3gQGU1QR2Ws7Qj4Ab8D9gm5d82d36EzGA=.e7dec0dd-00be-4423-8059-58d3d5362cf2@github.com>
References: <5OmiHCp8Lx3gQGU1QR2Ws7Qj4Ab8D9gm5d82d36EzGA=.e7dec0dd-00be-4423-8059-58d3d5362cf2@github.com>
Message-ID: <ldZu2vxgOd_4OXUWp9haJgSfZDQIz37XLSal7AV0-Os=.9b65546d-dce9-4b2f-9511-df496d2e7803@github.com>

On Wed, 15 Sep 2021 19:40:38 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes fixing handling of class initialization failures and adding unit tests to cover several failure scenarios and some corner cases (handling of instances from a failed initialization class).
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 8bed69aa
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/8bed69aaca316c2646b052a1acc465afc79faf95
Stats:     248 lines in 4 files changed: 225 ins; 16 del; 7 mod

8273650: [lworld] Interpreter fails with fatal error: DEBUG MESSAGE: klass not initialized

Reviewed-by: dsimms, thartmann

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

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


From fparain at openjdk.java.net  Fri Sep 17 19:35:47 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 17 Sep 2021 19:35:47 GMT
Subject: [lworld] RFR: 8273650: [lworld] Interpreter fails with fatal
 error: DEBUG MESSAGE: klass not initialized
In-Reply-To: <5OmiHCp8Lx3gQGU1QR2Ws7Qj4Ab8D9gm5d82d36EzGA=.e7dec0dd-00be-4423-8059-58d3d5362cf2@github.com>
References: <5OmiHCp8Lx3gQGU1QR2Ws7Qj4Ab8D9gm5d82d36EzGA=.e7dec0dd-00be-4423-8059-58d3d5362cf2@github.com>
Message-ID: <yO2x1NsXVv70tU_J9sXHfe-QgKCDDfvW_sJVEwc0z80=.5fe3c536-135c-4671-b122-e042a3c3d71c@github.com>

On Wed, 15 Sep 2021 19:40:38 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes fixing handling of class initialization failures and adding unit tests to cover several failure scenarios and some corner cases (handling of instances from a failed initialization class).
> 
> Thank you,
> 
> Fred

Thank you for the reviews.
All issues mentioned for the test file have been fixed.

Fred

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

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


From sadayapalam at openjdk.java.net  Mon Sep 20 05:47:01 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 20 Sep 2021 05:47:01 GMT
Subject: [lworld] RFR: 8273018: [lworld] Property annotation propagation
 to <init> lacks in primitive records [v2]
In-Reply-To: <Fjs2j_0gkEFj55ocHSSf3LB96RH3z3WYBqzof9FTieU=.ce6f8948-e848-46cf-b051-f37ffa7509a0@github.com>
References: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
 <Fjs2j_0gkEFj55ocHSSf3LB96RH3z3WYBqzof9FTieU=.ce6f8948-e848-46cf-b051-f37ffa7509a0@github.com>
Message-ID: <q1S-zAfinchSibZb0feD6ZXdDAnPxCUvJ4-sWKiNNMM=.5ba3f8c6-a370-4b49-8f76-9cb67eae25f1@github.com>

On Tue, 7 Sep 2021 23:37:52 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> This fix copies parameter names and annotations from constructor into primitive class factory.
>
> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Emit parameter names (described JDK-8273202)
>   - Keep type parameters
>   - Provide useful test for primitive records in "RecordReading"

OK, Thanks for the clarifications. If the suggested changes are made, we can take this forward.

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

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


From dsimms at openjdk.java.net  Wed Sep 22 10:13:34 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 22 Sep 2021 10:13:34 GMT
Subject: [lworld] RFR: Fix header format for build setup
Message-ID: <DbMOvZ-NO-FUqr1BTJeof8IwX7XzWkGFH7wYOQlsgH0=.57ff6325-7109-4ad9-8500-fbd98c18ef03@github.com>

Breaks testing, tests in question don't exist in mainline

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

Commit messages:
 - Fix header format for build setup

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

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


From dsimms at openjdk.java.net  Wed Sep 22 10:17:59 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 22 Sep 2021 10:17:59 GMT
Subject: [lworld] RFR: Adjust problem list for initial aarch64 testing
Message-ID: <nrVF_HbCO7G_MqzpVLBkHwVKlrJy8hRnTGOwcoA-NeM=.eaa3d093-29dd-4d9a-9e96-36e6e4a356be@github.com>

Debug fails: runtime/valhalla/inlinetypes/ClassInitializationFailuresTest.java

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

Commit messages:
 - Adjust problem list for initial aarch64 testing

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

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


From dsimms at openjdk.java.net  Wed Sep 22 10:19:17 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 22 Sep 2021 10:19:17 GMT
Subject: [lworld] Integrated: Fix header format for build setup
In-Reply-To: <DbMOvZ-NO-FUqr1BTJeof8IwX7XzWkGFH7wYOQlsgH0=.57ff6325-7109-4ad9-8500-fbd98c18ef03@github.com>
References: <DbMOvZ-NO-FUqr1BTJeof8IwX7XzWkGFH7wYOQlsgH0=.57ff6325-7109-4ad9-8500-fbd98c18ef03@github.com>
Message-ID: <YmS7ANUotlQ8lhojZVZ2gyRjWNZittVlwzcr14ozd08=.7109d078-d309-458f-94dd-2d63204f9eaf@github.com>

On Wed, 22 Sep 2021 10:06:13 GMT, David Simms <dsimms at openjdk.org> wrote:

> Breaks testing, tests in question don't exist in mainline

This pull request has now been integrated.

Changeset: c64b1608
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c64b1608329276efe5c2823a8347a81317b1509f
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

Fix header format for build setup

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

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


From dsimms at openjdk.java.net  Wed Sep 22 10:21:13 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 22 Sep 2021 10:21:13 GMT
Subject: [lworld] Integrated: Adjust problem list for initial aarch64 testing
In-Reply-To: <nrVF_HbCO7G_MqzpVLBkHwVKlrJy8hRnTGOwcoA-NeM=.eaa3d093-29dd-4d9a-9e96-36e6e4a356be@github.com>
References: <nrVF_HbCO7G_MqzpVLBkHwVKlrJy8hRnTGOwcoA-NeM=.eaa3d093-29dd-4d9a-9e96-36e6e4a356be@github.com>
Message-ID: <lA3r50Zvgf8Ka2J3QWowovIoC6FxFSrShuw7XmOufzQ=.2adbe20e-9305-4788-9c40-0471cb83b9db@github.com>

On Wed, 22 Sep 2021 10:10:59 GMT, David Simms <dsimms at openjdk.org> wrote:

> Debug fails: runtime/valhalla/inlinetypes/ClassInitializationFailuresTest.java

This pull request has now been integrated.

Changeset: a5cf5195
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a5cf51953659f720a2ff79ea1648611ff6a3bd7d
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

Adjust problem list for initial aarch64 testing

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

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


From jespersm at openjdk.java.net  Wed Sep 22 22:10:45 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Wed, 22 Sep 2021 22:10:45 GMT
Subject: [lworld] RFR: 8273018: [lworld] Property annotation propagation
 to <init> lacks in primitive records [v3]
In-Reply-To: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
References: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
Message-ID: <iBNYGs-D3QFXdZ5ybL0jqORlcbGYxmWY4Nf2Xl136XI=.6bca04fe-d62a-4034-b768-357f383cb9ae@github.com>

> This fix copies parameter names and annotations from constructor into primitive class factory.

Jesper Steen M?ller has updated the pull request incrementally with two additional commits since the last revision:

 - Updated test information and copyright.
 - Simplified parameter name condition

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/541/files
  - new: https://git.openjdk.java.net/valhalla/pull/541/files/122a8b10..4c5ef8ee

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

  Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 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  Wed Sep 22 22:10:45 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Wed, 22 Sep 2021 22:10:45 GMT
Subject: [lworld] RFR: 8273018: [lworld] Property annotation propagation
 to <init> lacks in primitive records [v2]
In-Reply-To: <q1S-zAfinchSibZb0feD6ZXdDAnPxCUvJ4-sWKiNNMM=.5ba3f8c6-a370-4b49-8f76-9cb67eae25f1@github.com>
References: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
 <Fjs2j_0gkEFj55ocHSSf3LB96RH3z3WYBqzof9FTieU=.ce6f8948-e848-46cf-b051-f37ffa7509a0@github.com>
 <q1S-zAfinchSibZb0feD6ZXdDAnPxCUvJ4-sWKiNNMM=.5ba3f8c6-a370-4b49-8f76-9cb67eae25f1@github.com>
Message-ID: <E0XW8akbfmLDb0uhPKMLJBEntCsDz0__lYVntv2JcX8=.9e1b8d74-a135-4742-abc1-127f806322c4@github.com>

On Mon, 20 Sep 2021 05:44:10 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:
>> 
>>   - Emit parameter names (described JDK-8273202)
>>   - Keep type parameters
>>   - Provide useful test for primitive records in "RecordReading"
>
> OK, Thanks for the clarifications. If the suggested changes are made, we can take this forward.

@sadayapalam: I've now incorporated the requested review changes.

I've run the tier1 tests, all is green here.

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

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


From sadayapalam at openjdk.java.net  Thu Sep 23 01:31:27 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 23 Sep 2021 01:31:27 GMT
Subject: [lworld] RFR: 8273018: [lworld] Property annotation propagation
 to <init> lacks in primitive records [v3]
In-Reply-To: <iBNYGs-D3QFXdZ5ybL0jqORlcbGYxmWY4Nf2Xl136XI=.6bca04fe-d62a-4034-b768-357f383cb9ae@github.com>
References: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
 <iBNYGs-D3QFXdZ5ybL0jqORlcbGYxmWY4Nf2Xl136XI=.6bca04fe-d62a-4034-b768-357f383cb9ae@github.com>
Message-ID: <zHR_PhO-hipLUtweCpARAyL2Crhufy5t4AVBEU-p0vI=.9cd9d535-6797-452d-af1d-62696504e812@github.com>

On Wed, 22 Sep 2021 22:10:45 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> This fix copies parameter names and annotations from constructor into primitive class factory.
>
> Jesper Steen M?ller has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated test information and copyright.
>  - Simplified parameter name condition

Looks good, please proceed to integrate, Thanks so much Jesper

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

Marked as reviewed by sadayapalam (Committer).

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


From jespersm at openjdk.java.net  Thu Sep 23 07:30:42 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 23 Sep 2021 07:30:42 GMT
Subject: [lworld] RFR: 8273360: [lworld] Invoking a reflection-generated
 constructor for primitive class gives InstantiationError [v2]
In-Reply-To: <E2vE7HSdk0GxjjbFLMUd78nPQkDFIUApxLD8dOAKFOg=.6c54a052-33a5-4bcd-8870-54888bc69981@github.com>
References: <E2vE7HSdk0GxjjbFLMUd78nPQkDFIUApxLD8dOAKFOg=.6c54a052-33a5-4bcd-8870-54888bc69981@github.com>
Message-ID: <Wffdibc9-GxTjALFSKhdfV109rmgmDUXeotHDvyE9HA=.198b93c2-c828-4e0f-858e-308eca7c6abe@github.com>

> Update constructor accessor code generation to invoke static factory method.

Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:

  Fix review issues

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/546/files
  - new: https://git.openjdk.java.net/valhalla/pull/546/files/8097982c..8bdd8570

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

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

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


From jespersm at openjdk.java.net  Thu Sep 23 09:32:14 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 23 Sep 2021 09:32:14 GMT
Subject: [lworld] Integrated: 8273018: [lworld] Property annotation
 propagation to <init> lacks in primitive records
In-Reply-To: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
References: <J0BeNUzgKv2I-R9znUMxbbcqtKaayLWUyJpEHEtLvA0=.0e4aab07-1461-45fb-bec5-c05e6433455a@github.com>
Message-ID: <KNSigEaBgn0KU0JcmIAcII7Ep7UNJMjlYdDgwXGp6ps=.be3290d1-bda1-4b2f-8aa3-8c2134181351@github.com>

On Tue, 31 Aug 2021 21:02:55 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> This fix copies parameter names and annotations from constructor into primitive class factory.

This pull request has now been integrated.

Changeset: 2688bf6e
Author:    Jesper Steen M?ller <jespersm at openjdk.org>
Committer: Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/2688bf6e922eb042b36c4ae6f566f3d3b869fba4
Stats:     159 lines in 4 files changed: 156 ins; 0 del; 3 mod

8273018: [lworld] Property annotation propagation to <init> lacks in primitive records
8273202: [lworld] MethodParameters are not generated for factories for primitive records

Reviewed-by: sadayapalam

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

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


From mchung at openjdk.java.net  Thu Sep 23 17:06:09 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 23 Sep 2021 17:06:09 GMT
Subject: [lworld] RFR: 8273360: [lworld] Invoking a reflection-generated
 constructor for primitive class gives InstantiationError [v2]
In-Reply-To: <Wffdibc9-GxTjALFSKhdfV109rmgmDUXeotHDvyE9HA=.198b93c2-c828-4e0f-858e-308eca7c6abe@github.com>
References: <E2vE7HSdk0GxjjbFLMUd78nPQkDFIUApxLD8dOAKFOg=.6c54a052-33a5-4bcd-8870-54888bc69981@github.com>
 <Wffdibc9-GxTjALFSKhdfV109rmgmDUXeotHDvyE9HA=.198b93c2-c828-4e0f-858e-308eca7c6abe@github.com>
Message-ID: <GijVHR3mI9kU4KUyVe87JsF620370FGdO75frNchvDk=.d3daabe6-b9b7-4554-956c-19a5df551f4c@github.com>

On Thu, 23 Sep 2021 07:30:42 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> Update constructor accessor code generation to invoke static factory method.
>
> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review issues

Looks good.  You can integrate once you update the `StaticFactoryTest.java`.

test/jdk/valhalla/valuetypes/StaticFactoryTest.java line 29:

> 27:  * @bug 8273360
> 28:  * @summary Test reflection of constructors for primitive classes
> 29:  * @run testng/othervm -Dsun.reflect.noInflation=true StaticFactoryTest

Suggestion:

 * @run testng/othervm StaticFactoryTest
 * @run testng/othervm -Dsun.reflect.noInflation=true StaticFactoryTest


This will exercise both code paths (with and without the spinned class).

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

Marked as reviewed by mchung (Committer).

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


From jespersm at openjdk.java.net  Thu Sep 23 21:23:37 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 23 Sep 2021 21:23:37 GMT
Subject: [lworld] RFR: 8273360: [lworld] Invoking a reflection-generated
 constructor for primitive class gives InstantiationError [v3]
In-Reply-To: <E2vE7HSdk0GxjjbFLMUd78nPQkDFIUApxLD8dOAKFOg=.6c54a052-33a5-4bcd-8870-54888bc69981@github.com>
References: <E2vE7HSdk0GxjjbFLMUd78nPQkDFIUApxLD8dOAKFOg=.6c54a052-33a5-4bcd-8870-54888bc69981@github.com>
Message-ID: <HNWcCZr7WaP43Oq9k33TDZek5WoHU71ZJ5qxT8OZprA=.d42af2b4-8c53-41c2-896f-eecc7cfb9d60@github.com>

> Update constructor accessor code generation to invoke static factory method.

Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/valhalla/valuetypes/StaticFactoryTest.java
  
  Run both variations
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/546/files
  - new: https://git.openjdk.java.net/valhalla/pull/546/files/8bdd8570..2afc752f

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

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

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


From jespersm at openjdk.java.net  Thu Sep 23 21:23:39 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 23 Sep 2021 21:23:39 GMT
Subject: [lworld] RFR: 8273360: [lworld] Invoking a reflection-generated
 constructor for primitive class gives InstantiationError [v2]
In-Reply-To: <GijVHR3mI9kU4KUyVe87JsF620370FGdO75frNchvDk=.d3daabe6-b9b7-4554-956c-19a5df551f4c@github.com>
References: <E2vE7HSdk0GxjjbFLMUd78nPQkDFIUApxLD8dOAKFOg=.6c54a052-33a5-4bcd-8870-54888bc69981@github.com>
 <Wffdibc9-GxTjALFSKhdfV109rmgmDUXeotHDvyE9HA=.198b93c2-c828-4e0f-858e-308eca7c6abe@github.com>
 <GijVHR3mI9kU4KUyVe87JsF620370FGdO75frNchvDk=.d3daabe6-b9b7-4554-956c-19a5df551f4c@github.com>
Message-ID: <3VD30G7d6NSFOvs2pAJINcWQPp1c9GUvfVWYRRMQbos=.0a3130bb-b9a4-420b-9fd6-95e6482adb79@github.com>

On Thu, 23 Sep 2021 17:02:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix review issues
>
> Looks good.  You can integrate once you update the `StaticFactoryTest.java`.

Thanks for reviewing, @mlchung !

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

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


From jespersm at openjdk.java.net  Thu Sep 23 21:48:09 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 23 Sep 2021 21:48:09 GMT
Subject: [lworld] Integrated: 8273360: [lworld] Invoking a
 reflection-generated constructor for primitive class gives InstantiationError
In-Reply-To: <E2vE7HSdk0GxjjbFLMUd78nPQkDFIUApxLD8dOAKFOg=.6c54a052-33a5-4bcd-8870-54888bc69981@github.com>
References: <E2vE7HSdk0GxjjbFLMUd78nPQkDFIUApxLD8dOAKFOg=.6c54a052-33a5-4bcd-8870-54888bc69981@github.com>
Message-ID: <7_BjFtrE_vnythX9s8pEgfZB9WKbpxsAuc6AGac-orw=.479c7b8c-6146-4753-81e3-de506b62653a@github.com>

On Sun, 5 Sep 2021 13:33:26 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Update constructor accessor code generation to invoke static factory method.

This pull request has now been integrated.

Changeset: 13035717
Author:    Jesper Steen M?ller <jespersm at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/13035717c97321939a8e152db98ba15f4268a93c
Stats:     12 lines in 2 files changed: 9 ins; 0 del; 3 mod

8273360: [lworld] Invoking a reflection-generated constructor for primitive class gives InstantiationError

Reviewed-by: mchung

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

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


From jespersm at openjdk.java.net  Fri Sep 24 09:10:11 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Fri, 24 Sep 2021 09:10:11 GMT
Subject: [lworld] RFR: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <uyFS39tIEVFQmeocktDeghyLs8O0NNs4TFKr77k8yNg=.899d4852-d40d-4ac9-9d06-83adb03e1c1b@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
 <uyFS39tIEVFQmeocktDeghyLs8O0NNs4TFKr77k8yNg=.899d4852-d40d-4ac9-9d06-83adb03e1c1b@github.com>
Message-ID: <SXZKPCL7WhV0qBm_chJSVGtJ0BtIWiCK9GvSvEN-f98=.93af95ff-8b06-4fa0-b08e-e7fc6500fe63@github.com>

On Fri, 17 Sep 2021 00:12:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.
>
> I discussed with Dan offline to follow up my question in what cases javac should emit `(LFoo;)LR;` vs `(QFoo;)LR;`.   For the lambda case, having the receiver type as `QFoo;` is a good thing to do as it's an instance method of the enclosing class. 
> 
> For a method reference `o::m` where `o` is of primitive reference type, the factory type would be `(LFoo;)LR;`.   I have a test case that verifies the emitted code is:
> 
> 28: invokedynamic #38,  0             // InvokeDynamic #1:get:(LX;)Ljava/util/function/Supplier;
> 
> 
> In short, it's good to fix javac to emit `QFoo;` as the receiver type if it's a primitive class.

Based on @mlchung 's comment from last week, it would be correct to integrate this.

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

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


From jespersm at openjdk.java.net  Wed Sep 29 22:36:56 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Wed, 29 Sep 2021 22:36:56 GMT
Subject: [lworld] RFR: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <uyFS39tIEVFQmeocktDeghyLs8O0NNs4TFKr77k8yNg=.899d4852-d40d-4ac9-9d06-83adb03e1c1b@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
 <uyFS39tIEVFQmeocktDeghyLs8O0NNs4TFKr77k8yNg=.899d4852-d40d-4ac9-9d06-83adb03e1c1b@github.com>
Message-ID: <ROfHDOlb_0hv3W7aRRgUumQ4aoVKil6VDGQ_jBGs32o=.32497ab6-0f36-4bd8-90f1-e46873cc58ef@github.com>

On Fri, 17 Sep 2021 00:12:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.
>
> I discussed with Dan offline to follow up my question in what cases javac should emit `(LFoo;)LR;` vs `(QFoo;)LR;`.   For the lambda case, having the receiver type as `QFoo;` is a good thing to do as it's an instance method of the enclosing class. 
> 
> For a method reference `o::m` where `o` is of primitive reference type, the factory type would be `(LFoo;)LR;`.   I have a test case that verifies the emitted code is:
> 
> 28: invokedynamic #38,  0             // InvokeDynamic #1:get:(LX;)Ljava/util/function/Supplier;
> 
> 
> In short, it's good to fix javac to emit `QFoo;` as the receiver type if it's a primitive class.

@mlchung : I've tested, and can confirm that both [your fix](https://bugs.openjdk.java.net/browse/JDK-8273301?focusedCommentId=14447307&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14447307) on the lambda side of things and my fix on the compiler side (this PR) will make the attached test case pass. 

However, from your comments above, quoting a discussion with Dan, I'm suggesting that javac is tightened up, as the smaller fix, so to speak, i.e. that we integrate this PR.

I then suggest that your fix should be brought under the JDK-8174983 umbrella, since the L->Q and Q->L conversions are conceptually similar, and thus useful for other users of LambdaMetafactory.

If you agree, @sadayapalam can review this bug as it.

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

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


From mchung at openjdk.java.net  Wed Sep 29 23:50:38 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 29 Sep 2021 23:50:38 GMT
Subject: [lworld] RFR: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <uyFS39tIEVFQmeocktDeghyLs8O0NNs4TFKr77k8yNg=.899d4852-d40d-4ac9-9d06-83adb03e1c1b@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
 <uyFS39tIEVFQmeocktDeghyLs8O0NNs4TFKr77k8yNg=.899d4852-d40d-4ac9-9d06-83adb03e1c1b@github.com>
Message-ID: <e2OZ5vH57dcZQ13_QboYFECccdaE5VapnZNQzKct_Ts=.e86768c2-f5a4-406c-8579-d028bab0cbfc@github.com>

On Fri, 17 Sep 2021 00:12:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.
>
> I discussed with Dan offline to follow up my question in what cases javac should emit `(LFoo;)LR;` vs `(QFoo;)LR;`.   For the lambda case, having the receiver type as `QFoo;` is a good thing to do as it's an instance method of the enclosing class. 
> 
> For a method reference `o::m` where `o` is of primitive reference type, the factory type would be `(LFoo;)LR;`.   I have a test case that verifies the emitted code is:
> 
> 28: invokedynamic #38,  0             // InvokeDynamic #1:get:(LX;)Ljava/util/function/Supplier;
> 
> 
> In short, it's good to fix javac to emit `QFoo;` as the receiver type if it's a primitive class.

> @mlchung : I've tested, and can confirm that both [your fix](https://bugs.openjdk.java.net/browse/JDK-8273301?focusedCommentId=14447307&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14447307) on the lambda side of things and my fix on the compiler side (this PR) will make the attached test case pass.

Thanks for confirming it.  I also create JDK-8274399 to fix the runtime.

> However, from your comments above, quoting a discussion with Dan, I'm suggesting that javac is tightened up, as the smaller fix, so to speak, i.e. that we integrate this PR.

Yes, we agree that it's good to fix javac as well.   You need @sadayapalam to review your PR before integration.  I recalled Srikanath was on vacation and I'm not sure whether he's back.
 
> I then suggest that your fix should be brought under the JDK-8174983 umbrella, since the L->Q and Q->L conversions are conceptually similar, and thus useful for other users of LambdaMetafactory.

It's related to JDK-8174983.  We can fix JDK-8274399 in lworld branch while JDK-8174983 can be fixed separately in the main line.

> If you agree, @sadayapalam can review this bug as it.

Yes I agree.

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

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