From dsimms at openjdk.java.net  Mon Nov  1 17:41:26 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 1 Nov 2021 17:41:26 GMT
Subject: [lworld] RFR: 8276187: [lworld] [lw3] Handling of pre-loaded
 fields is inefficient
In-Reply-To: <Gld3oCQJD8StnGlmqy5t5ho-FtHD-vZn_uwapktLc3U=.13df964e-89ac-43d6-a607-f4165073c3ce@github.com>
References: <Gld3oCQJD8StnGlmqy5t5ho-FtHD-vZn_uwapktLc3U=.13df964e-89ac-43d6-a607-f4165073c3ce@github.com>
Message-ID: <RIjBrLwswerU_-rlAyWZnWGvYLwpA8JcuEYTvsB6ea4=.bc6d1d0f-f570-4fbd-9deb-3d2fdf39a436@github.com>

On Fri, 29 Oct 2021 19:02:05 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes reducing the number of time pre-loaded fields are fetched from the system dictionary.
> The changes would also help supporting field circularity in the future if needed.
> Tested with Mach5, tier 1 to 3.
> 
> Thank you,
> 
> Fred

Looks good !

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

Marked as reviewed by dsimms (Committer).

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

From fparain at openjdk.java.net  Mon Nov  1 18:02:22 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 1 Nov 2021 18:02:22 GMT
Subject: [lworld] RFR: 8276187: [lworld] [lw3] Handling of pre-loaded
 fields is inefficient
In-Reply-To: <Gld3oCQJD8StnGlmqy5t5ho-FtHD-vZn_uwapktLc3U=.13df964e-89ac-43d6-a607-f4165073c3ce@github.com>
References: <Gld3oCQJD8StnGlmqy5t5ho-FtHD-vZn_uwapktLc3U=.13df964e-89ac-43d6-a607-f4165073c3ce@github.com>
Message-ID: <UNUveYkhr8osI4hyMRkGxAmehEcihso4g2DcLpEJW4c=.80e04e4e-c67e-4bc6-a7ab-4e08975d0b84@github.com>

On Fri, 29 Oct 2021 19:02:05 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes reducing the number of time pre-loaded fields are fetched from the system dictionary.
> The changes would also help supporting field circularity in the future if needed.
> Tested with Mach5, tier 1 to 3.
> 
> Thank you,
> 
> Fred

David,

Thanks for the review.

Fred

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

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

From fparain at openjdk.java.net  Mon Nov  1 18:02:22 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 1 Nov 2021 18:02:22 GMT
Subject: [lworld] Integrated: 8276187: [lworld] [lw3] Handling of pre-loaded
 fields is inefficient
In-Reply-To: <Gld3oCQJD8StnGlmqy5t5ho-FtHD-vZn_uwapktLc3U=.13df964e-89ac-43d6-a607-f4165073c3ce@github.com>
References: <Gld3oCQJD8StnGlmqy5t5ho-FtHD-vZn_uwapktLc3U=.13df964e-89ac-43d6-a607-f4165073c3ce@github.com>
Message-ID: <P0E2cReffzQyC0XRjvONC678iFbg0kdJbmDC098G2b8=.eeb4c2e7-6aa1-4ffa-b684-d2dd537cea66@github.com>

On Fri, 29 Oct 2021 19:02:05 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes reducing the number of time pre-loaded fields are fetched from the system dictionary.
> The changes would also help supporting field circularity in the future if needed.
> Tested with Mach5, tier 1 to 3.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 01e9411f
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/01e9411ff7dc8baf00a982e543997be3b7474ed3
Stats:     48 lines in 4 files changed: 13 ins; 21 del; 14 mod

8276187: [lworld] [lw3] Handling of pre-loaded fields is inefficient

Reviewed-by: dsimms

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

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

From ngasson at openjdk.java.net  Thu Nov  4 08:41:38 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 4 Nov 2021 08:41:38 GMT
Subject: [lworld] RFR: 8276538: [lworld] [AArch64]
 LIR_Assembler::emit_profile_inline_type temporary register conflict
Message-ID: <Y2JvT9mHpYAvUS5iSXji4ngtDnuZmp_fPIzxJmGxGes=.39ab8c3b-771e-44d4-a64c-325f50fa3fed@github.com>

LIR_Assembler::as_Address() may use rscratch1 as a temporary register
for the address offset if it's too large to fit in an immediate, but
rscratch1 is also used at the same time to hold the updated MDO value.
See the discussion on JDK-8276108.

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

Commit messages:
 - 8276538: [lworld] [AArch64] LIR_Assembler::emit_profile_inline_type temporary register conflict

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

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

From dsimms at openjdk.java.net  Thu Nov  4 09:57:44 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 4 Nov 2021 09:57:44 GMT
Subject: [lworld] RFR: 8276612: [lworld]
 runtime/valhalla/inlinetypes/InlineTypeArray.java crashes with
 " memory leak: allocating without ResourceMark"
Message-ID: <_z9hUhAFU13aPfwTU64PlP9wJGJwJU_BABy9_7zPpwI=.66422c40-99cf-4983-a721-0ea59f6fae57@github.com>

Missing ResourceMark

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

Commit messages:
 - 8276612: [lworld] runtime/valhalla/inlinetypes/InlineTypeArray.java crashes with " memory leak: allocating without ResourceMark"

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

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

From dsimms at openjdk.java.net  Thu Nov  4 11:20:25 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 4 Nov 2021 11:20:25 GMT
Subject: [lworld] Integrated: 8276612: [lworld]
 runtime/valhalla/inlinetypes/InlineTypeArray.java crashes with
 " memory leak: allocating without ResourceMark"
In-Reply-To: <_z9hUhAFU13aPfwTU64PlP9wJGJwJU_BABy9_7zPpwI=.66422c40-99cf-4983-a721-0ea59f6fae57@github.com>
References: <_z9hUhAFU13aPfwTU64PlP9wJGJwJU_BABy9_7zPpwI=.66422c40-99cf-4983-a721-0ea59f6fae57@github.com>
Message-ID: <r8Y2Z-bgZaBXFlAeLE6dfY720J1ywf5nLRc8FLbqHLk=.b10bdc26-71d9-44d4-b1c0-237d5ca5e8f3@github.com>

On Thu, 4 Nov 2021 09:51:33 GMT, David Simms <dsimms at openjdk.org> wrote:

> Missing ResourceMark

This pull request has now been integrated.

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

8276612: [lworld] runtime/valhalla/inlinetypes/InlineTypeArray.java crashes with " memory leak: allocating without ResourceMark"

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

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

From brian.goetz at oracle.com  Thu Nov  4 13:33:21 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 4 Nov 2021 09:33:21 -0400
Subject: Fwd: Nullability of primitive types
In-Reply-To: <CAG6MGLcaJwOGt3KaYHavAjhwQ3aJT0EKFH72uOKbf3P=2s7x=A@mail.gmail.com>
References: <CAG6MGLcaJwOGt3KaYHavAjhwQ3aJT0EKFH72uOKbf3P=2s7x=A@mail.gmail.com>
Message-ID: <d2714808-8bc9-b924-0318-06da4ca7e380@oracle.com>

The following was received on the spec-comments list.? I'll answer here, 
because there are common misunderstandings of how the JVM works here, 
but I'd rather not get into an extended back-and-forth.

The questioner asks: why not (just) make nullability a use-site 
property, rather than a declaration-site property.

One serious issue that this question ignores is that there are many 
classes for which not only is the all-zeroes value not a good default, 
but *there is no good default*.? As a simplified illustrative example, 
take Rational:

 ??? primitive class Rational {
 ??????? int n, d;

 ??????? Rational(int n, int d) {
 ??????????? if (d == 0)
 ??????????????? throw new IAE();
 ??????????? this.n = n;
 ??????????? this.d = d;
 ??????? }

 ??????? float toFloat() {
 ??????????? // HERE
 ??????????? return (float) n / (float) d;
 ??????? }
 ??? }

 ??? Rational r;
 ??? float f = r.toFloat(); // DBZE

You might decide this is harmless in the case of Rational (after all, 
you pretty quickly get an informative exception when an uninitialized 
value is used), but let's zoom in on what is happening at HERE; an 
instance method was invoke with a receiver that does not respect the 
class invariants, because the instance *did not even come from a 
constructor*.? (Can you think of another situation where potentially 
invalid objects are produced outside the constructor?? Serialization, 
perhaps?? How did that go?)

For classes where the default (zero) value is valid, we can argue over 
whether this is safe enough.? But for classes where the default value is 
*demonstrably outside the domain*, some degree of protection from 
uninitialized values (which are unavoidable; arrays are always 
initialized to the default value of the component) is required.? When 
you pull on that string, you find yourself down one of two paths: either 
you are inventing a new null with similar but slightly different 
properties (maybe you call it undefined, but it's a new null), or you 
accept that "the natural default for this class is null."? We tried the 
former path for a while, but realized that it was an exercise in wishful 
thinking.? So what you come to is: nullability is a declaration-site 
property of this class.

This example might not be too compelling, because Rational is so simple, 
but think about how it undermines a basic principle of encapsulation.? 
The representation is supposed to be an implementation detail, and under 
the control of the author, and users shouldn't have to think about 
representation.? But to code this class safely, you'd need "null" checks 
on the entry of each method.? No one will want to do that, and people 
will forget. Now, all we need is one class that performs a security 
check based on the object state, and accidentally interprets zeroes as 
"no restrictions".? If people are going to "code like a class", they 
need a safe way for it to behave like objects we are used to, and this 
pulls in all the affordances of references -- nullability, non-tearing, 
etc.? This is a declaration-site property.

The suggestions on reflection violate an important invariant: that each 
descriptor corresponds to a unique mirror.? (How would you differentiate 
between them in a MethodHandle lookup?)? While I am sure it is possible 
to concoct a scheme to make this appear to work, at best this pushes 
complexity somewhere else, but most likely, increases it dramatically.


For the "true" primitives, you get almost exactly what you're asking 
for: Point is non-nullable, Point.ref is nullable (because its a 
reference, and references are nullable.)? Is this just a really 
roundabout way to say "I would like a different syntax"?




-------- Forwarded Message --------
Subject: 	Nullability of primitive types
Date: 	Thu, 4 Nov 2021 09:03:23 +0100
From: 	Gernot Neppert <mcnepp02 at googlemail.com>
To: 	valhalla-spec-comments at openjdk.java.net



Dear experts,

regarding the ongoing debate about nullability of primitive classes:

even though we are talking about nullable vs. non-nullable _types_,
wouldn't it help to focus on null-permitting _usecases_?
There are class-members, method arguments and return-values of
primitive-class types.
IMHO, it would make real sense to defer the decision of permitting nulls to
each of these use-sites.

The "nullability" would be represented at each _use-site_ by the
corresponding Descriptor (L vs. Q) in the class-file,
and the _default_ would (obviously) be "L" for normal classes, and "Q" for
primitive classes.

Given a primitve class java.util.Complex,

the descriptor for a class-member declared "Complex number;" would be
"Qjava.util.Complex;"

wheras the descriptor for a class-member declared "@Nullable Complex
number;" would be "Ljava.util.Complex;"

Likeweise for method-signatures.

That way, there'd be no need to have two different class-mirrors for a
primitive class.
Of course, you would be able to query the "nullability" of a
java.lang.reflect.Field or a java.lang.reflect.Parameter via Core
reflection.
However, the API for obtaining java.lang.reflect.Methods would not need to
be changed at all!
Two methods whose signature only differed by "nullability" (aka L vs Q
signature) would be considered the same, thus the following would not be
allowed:

class ComplexCalculator {
Complex add(Complex one, Complex two);

@Nullable Complex add(@Nullable Complex one, @Nullable Complex two);
}

As for migration of existing none-primitive classes to primitive ones, it
would be possible to make @Nullable the default _usecase_ for a primitive
class:

@Nullable primitive class Optional<T> {
}

Then, for orthogonality, there'd be a means of specifying "Use this
primitive type as a non-nullable value here", maybe something like

@ByValue Optional<String> getName();

(As a sidenote, maybe a good name instead of @Nullable would be @ByRef).

And yes, with this proposal the Java primitive types (int, long...) would
remain special cases, and they would continue to have their "companion"
reference-types.

From fparain at openjdk.java.net  Thu Nov  4 16:07:27 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 4 Nov 2021 16:07:27 GMT
Subject: [lworld] RFR: 8276538: [lworld] [AArch64]
 LIR_Assembler::emit_profile_inline_type temporary register conflict
In-Reply-To: <Y2JvT9mHpYAvUS5iSXji4ngtDnuZmp_fPIzxJmGxGes=.39ab8c3b-771e-44d4-a64c-325f50fa3fed@github.com>
References: <Y2JvT9mHpYAvUS5iSXji4ngtDnuZmp_fPIzxJmGxGes=.39ab8c3b-771e-44d4-a64c-325f50fa3fed@github.com>
Message-ID: <x6YXRF1vnC-EJ0bTur0d5lVynl0mQZASx2lVk3-_r6c=.335de4fa-b8ed-4af2-9d79-518578f3d460@github.com>

On Thu, 4 Nov 2021 08:35:55 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> LIR_Assembler::as_Address() may use rscratch1 as a temporary register
> for the address offset if it's too large to fit in an immediate, but
> rscratch1 is also used at the same time to hold the updated MDO value.
> See the discussion on JDK-8276108.

I've tested this patch with the current patch proposed for JDK-8276108 and got several crashes due to SIGSEGV in ciObjectFactory::create_new_metadata(Metadata*), from both C1 and C2 code.

For instance, with compiler/valhalla/inlinetypes/TestArrays.java:

Current CompileTask:
C1:   8816 1128    b  3       compiler.valhalla.inlinetypes.TestArrays::verify (36 bytes)

Stack: [0x0000fffbf8380000,0x0000fffbf8580000],  sp=0x0000fffbf857cb20,  free space=2034k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x921f14]  ciObjectFactory::create_new_metadata(Metadata*)+0x70
V  [libjvm.so+0x922d08]  ciObjectFactory::get_metadata(Metadata*)+0x1f8
V  [libjvm.so+0x8f3d10]  ciMethod::ensure_method_data(methodHandle const&)+0x180
V  [libjvm.so+0x8fb8e0]  ciMethod::ensure_method_data()+0x110
V  [libjvm.so+0x73ff5c]  GraphBuilder::try_inline_full(ciMethod*, bool, bool, Bytecodes::Code, Instruction*)+0x28c
V  [libjvm.so+0x7410a8]  GraphBuilder::try_inline(ciMethod*, bool, bool, Bytecodes::Code, Instruction*)+0x194
V  [libjvm.so+0x741bfc]  GraphBuilder::invoke(Bytecodes::Code)+0xa8c
V  [libjvm.so+0x742850]  GraphBuilder::iterate_bytecodes_for_block(int)+0x640
V  [libjvm.so+0x744518]  GraphBuilder::iterate_all_blocks(bool)+0xa8
V  [libjvm.so+0x740518]  GraphBuilder::try_inline_full(ciMethod*, bool, bool, Bytecodes::Code, Instruction*)+0x848
V  [libjvm.so+0x7410a8]  GraphBuilder::try_inline(ciMethod*, bool, bool, Bytecodes::Code, Instruction*)+0x194
V  [libjvm.so+0x741bfc]  GraphBuilder::invoke(Bytecodes::Code)+0xa8c
V  [libjvm.so+0x742850]  GraphBuilder::iterate_bytecodes_for_block(int)+0x640
V  [libjvm.so+0x744518]  GraphBuilder::iterate_all_blocks(bool)+0xa8
V  [libjvm.so+0x740518]  GraphBuilder::try_inline_full(ciMethod*, bool, bool, Bytecodes::Code, Instruction*)+0x848
V  [libjvm.so+0x7410a8]  GraphBuilder::try_inline(ciMethod*, bool, bool, Bytecodes::Code, Instruction*)+0x194
V  [libjvm.so+0x741bfc]  GraphBuilder::invoke(Bytecodes::Code)+0xa8c
V  [libjvm.so+0x742850]  GraphBuilder::iterate_bytecodes_for_block(int)+0x640
V  [libjvm.so+0x744504]  GraphBuilder::iterate_all_blocks(bool)+0x94
V  [libjvm.so+0x7456b4]  GraphBuilder::GraphBuilder(Compilation*, IRScope*)+0x504
V  [libjvm.so+0x7550c0]  IRScope::IRScope(Compilation*, IRScope*, int, ciMethod*, int, bool)+0x3c0
V  [libjvm.so+0x7552d4]  IR::IR(Compilation*, ciMethod*, int)+0xd0
V  [libjvm.so+0x71adfc]  Compilation::build_hir() [clone .part.0]+0x22c
V  [libjvm.so+0x71f574]  Compilation::compile_java_method()+0x1b0
V  [libjvm.so+0x7203c8]  Compilation::compile_method()+0x1d8
V  [libjvm.so+0x720da4]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x324
V  [libjvm.so+0x722348]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x158
V  [libjvm.so+0xa2b798]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8b8
V  [libjvm.so+0xa2c1fc]  CompileBroker::compiler_thread_loop()+0x2dc
V  [libjvm.so+0x1826384]  JavaThread::thread_main_inner()+0x284
V  [libjvm.so+0x182c928]  Thread::call_run()+0xf8
V  [libjvm.so+0x1533394]  thread_native_entry(Thread*)+0x104
C  [libpthread.so.0+0x7738]  start_thread+0x198


or with compiler/valhalla/inlinetypes/TestLWorld.java:

Current CompileTask:
C2:   9975 1071    b  4       compiler.valhalla.inlinetypes.TestLWorld::test136 (30 bytes)

Stack: [0x0000fffd15000000,0x0000fffd15200000],  sp=0x0000fffd151fc440,  free space=2033k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x00400f61f940f260
V  [libjvm.so+0x922d08]  ciObjectFactory::get_metadata(Metadata*)+0x1f8
V  [libjvm.so+0x8f3d10]  ciMethod::ensure_method_data(methodHandle const&)+0x180
V  [libjvm.so+0x8fb8e0]  ciMethod::ensure_method_data()+0x110
V  [libjvm.so+0xa1c1f4]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, bool, DirectiveSet*)+0x10d4
V  [libjvm.so+0x83509c]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1a8
V  [libjvm.so+0xa2b798]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8b8
V  [libjvm.so+0xa2c1fc]  CompileBroker::compiler_thread_loop()+0x2dc
V  [libjvm.so+0x1826384]  JavaThread::thread_main_inner()+0x284
V  [libjvm.so+0x182c928]  Thread::call_run()+0xf8
V  [libjvm.so+0x1533394]  thread_native_entry(Thread*)+0x104
C  [libpthread.so.0+0x7738]  start_thread+0x198

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

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

From mchung at openjdk.java.net  Thu Nov  4 17:27:34 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 4 Nov 2021 17:27:34 GMT
Subject: [lworld] Integrated: JDK-8276656: [lworld] merge JEP 416: reimplement
 core reflection with method handles
Message-ID: <mQpEbPEOd70ZtFzjPiKEOLEhhXs_hoMYoiuKXaxhpjg=.a5f48835-164b-463b-a4b4-c9f22c4c9b0d@github.com>

JEP 416 will be in jdk-18+22 promoted build.   This PR makes lworld merge with jdk-18+22 easier.

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

Commit messages:
 - fixup the merge with JEP 416

Changes: https://git.openjdk.java.net/valhalla/pull/579/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=579&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276656
  Stats: 6429 lines in 79 files changed: 5875 ins; 316 del; 238 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/579.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/579/head:pull/579

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

From mchung at openjdk.java.net  Thu Nov  4 17:27:35 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 4 Nov 2021 17:27:35 GMT
Subject: [lworld] Integrated: JDK-8276656: [lworld] merge JEP 416: reimplement
 core reflection with method handles
In-Reply-To: <mQpEbPEOd70ZtFzjPiKEOLEhhXs_hoMYoiuKXaxhpjg=.a5f48835-164b-463b-a4b4-c9f22c4c9b0d@github.com>
References: <mQpEbPEOd70ZtFzjPiKEOLEhhXs_hoMYoiuKXaxhpjg=.a5f48835-164b-463b-a4b4-c9f22c4c9b0d@github.com>
Message-ID: <PdAcnw44Jdxsmc03Q3Ds5ppzI1eSYhFpQ8k8Ve3wSMc=.89b614bf-7d2a-4de7-8b8b-acbeb47c5c94@github.com>

On Thu, 4 Nov 2021 17:16:51 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> JEP 416 will be in jdk-18+22 promoted build.   This PR makes lworld merge with jdk-18+22 easier.

This pull request has now been integrated.

Changeset: 37f00969
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/37f0096919a3417e2d94b12e5823f598c86282a0
Stats:     6429 lines in 79 files changed: 5875 ins; 316 del; 238 mod

8276656: [lworld] merge JEP 416: reimplement core reflection with method handles

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

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

From ngasson at openjdk.java.net  Fri Nov  5 05:20:22 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 5 Nov 2021 05:20:22 GMT
Subject: [lworld] RFR: 8276538: [lworld] [AArch64]
 LIR_Assembler::emit_profile_inline_type temporary register conflict
In-Reply-To: <x6YXRF1vnC-EJ0bTur0d5lVynl0mQZASx2lVk3-_r6c=.335de4fa-b8ed-4af2-9d79-518578f3d460@github.com>
References: <Y2JvT9mHpYAvUS5iSXji4ngtDnuZmp_fPIzxJmGxGes=.39ab8c3b-771e-44d4-a64c-325f50fa3fed@github.com>
 <x6YXRF1vnC-EJ0bTur0d5lVynl0mQZASx2lVk3-_r6c=.335de4fa-b8ed-4af2-9d79-518578f3d460@github.com>
Message-ID: <90cKq2TmFkoD2O7a3jjIxqR4WEB5-AxFIOMexIc088g=.7a92100d-6d39-41de-bcf0-19422df18889@github.com>

On Thu, 4 Nov 2021 16:04:33 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> LIR_Assembler::as_Address() may use rscratch1 as a temporary register
>> for the address offset if it's too large to fit in an immediate, but
>> rscratch1 is also used at the same time to hold the updated MDO value.
>> See the discussion on JDK-8276108.
>
> I've tested this patch with the current patch proposed for JDK-8276108 and got several crashes due to SIGSEGV in ciObjectFactory::create_new_metadata(Metadata*), from both C1 and C2 code.
> 
> For instance, with compiler/valhalla/inlinetypes/TestArrays.java:
> 
> Current CompileTask:
> C1:   8816 1128    b  3       compiler.valhalla.inlinetypes.TestArrays::verify (36 bytes)
> 
> Stack: [0x0000fffbf8380000,0x0000fffbf8580000],  sp=0x0000fffbf857cb20,  free space=2034k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x921f14]  ciObjectFactory::create_new_metadata(Metadata*)+0x70
> V  [libjvm.so+0x922d08]  ciObjectFactory::get_metadata(Metadata*)+0x1f8
> V  [libjvm.so+0x8f3d10]  ciMethod::ensure_method_data(methodHandle const&)+0x180
> V  [libjvm.so+0x8fb8e0]  ciMethod::ensure_method_data()+0x110
> V  [libjvm.so+0x73ff5c]  GraphBuilder::try_inline_full(ciMethod*, bool, bool, Bytecodes::Code, Instruction*)+0x28c
> V  [libjvm.so+0x7410a8]  GraphBuilder::try_inline(ciMethod*, bool, bool, Bytecodes::Code, Instruction*)+0x194
> V  [libjvm.so+0x741bfc]  GraphBuilder::invoke(Bytecodes::Code)+0xa8c
> V  [libjvm.so+0x742850]  GraphBuilder::iterate_bytecodes_for_block(int)+0x640
> V  [libjvm.so+0x744518]  GraphBuilder::iterate_all_blocks(bool)+0xa8
> V  [libjvm.so+0x740518]  GraphBuilder::try_inline_full(ciMethod*, bool, bool, Bytecodes::Code, Instruction*)+0x848
> V  [libjvm.so+0x7410a8]  GraphBuilder::try_inline(ciMethod*, bool, bool, Bytecodes::Code, Instruction*)+0x194
> V  [libjvm.so+0x741bfc]  GraphBuilder::invoke(Bytecodes::Code)+0xa8c
> V  [libjvm.so+0x742850]  GraphBuilder::iterate_bytecodes_for_block(int)+0x640
> V  [libjvm.so+0x744518]  GraphBuilder::iterate_all_blocks(bool)+0xa8
> V  [libjvm.so+0x740518]  GraphBuilder::try_inline_full(ciMethod*, bool, bool, Bytecodes::Code, Instruction*)+0x848
> V  [libjvm.so+0x7410a8]  GraphBuilder::try_inline(ciMethod*, bool, bool, Bytecodes::Code, Instruction*)+0x194
> V  [libjvm.so+0x741bfc]  GraphBuilder::invoke(Bytecodes::Code)+0xa8c
> V  [libjvm.so+0x742850]  GraphBuilder::iterate_bytecodes_for_block(int)+0x640
> V  [libjvm.so+0x744504]  GraphBuilder::iterate_all_blocks(bool)+0x94
> V  [libjvm.so+0x7456b4]  GraphBuilder::GraphBuilder(Compilation*, IRScope*)+0x504
> V  [libjvm.so+0x7550c0]  IRScope::IRScope(Compilation*, IRScope*, int, ciMethod*, int, bool)+0x3c0
> V  [libjvm.so+0x7552d4]  IR::IR(Compilation*, ciMethod*, int)+0xd0
> V  [libjvm.so+0x71adfc]  Compilation::build_hir() [clone .part.0]+0x22c
> V  [libjvm.so+0x71f574]  Compilation::compile_java_method()+0x1b0
> V  [libjvm.so+0x7203c8]  Compilation::compile_method()+0x1d8
> V  [libjvm.so+0x720da4]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x324
> V  [libjvm.so+0x722348]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x158
> V  [libjvm.so+0xa2b798]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8b8
> V  [libjvm.so+0xa2c1fc]  CompileBroker::compiler_thread_loop()+0x2dc
> V  [libjvm.so+0x1826384]  JavaThread::thread_main_inner()+0x284
> V  [libjvm.so+0x182c928]  Thread::call_run()+0xf8
> V  [libjvm.so+0x1533394]  thread_native_entry(Thread*)+0x104
> C  [libpthread.so.0+0x7738]  start_thread+0x198
> 
> 
> or with compiler/valhalla/inlinetypes/TestLWorld.java:
> 
> Current CompileTask:
> C2:   9975 1071    b  4       compiler.valhalla.inlinetypes.TestLWorld::test136 (30 bytes)
> 
> Stack: [0x0000fffd15000000,0x0000fffd15200000],  sp=0x0000fffd151fc440,  free space=2033k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  0x00400f61f940f260
> V  [libjvm.so+0x922d08]  ciObjectFactory::get_metadata(Metadata*)+0x1f8
> V  [libjvm.so+0x8f3d10]  ciMethod::ensure_method_data(methodHandle const&)+0x180
> V  [libjvm.so+0x8fb8e0]  ciMethod::ensure_method_data()+0x110
> V  [libjvm.so+0xa1c1f4]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, bool, DirectiveSet*)+0x10d4
> V  [libjvm.so+0x83509c]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1a8
> V  [libjvm.so+0xa2b798]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8b8
> V  [libjvm.so+0xa2c1fc]  CompileBroker::compiler_thread_loop()+0x2dc
> V  [libjvm.so+0x1826384]  JavaThread::thread_main_inner()+0x284
> V  [libjvm.so+0x182c928]  Thread::call_run()+0xf8
> V  [libjvm.so+0x1533394]  thread_native_entry(Thread*)+0x104
> C  [libpthread.so.0+0x7738]  start_thread+0x198

@fparain how can I reproduce that? I tried:

1. Latest lworld branch + this patch + openjdk/jdk#6212 
2. Your c1_cleanup branch + this patch + openjdk/jdk#6212 

But both are passing all the hotspot_valhalla tests.

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

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

From fparain at openjdk.java.net  Fri Nov  5 16:40:22 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 5 Nov 2021 16:40:22 GMT
Subject: [lworld] RFR: 8276538: [lworld] [AArch64]
 LIR_Assembler::emit_profile_inline_type temporary register conflict
In-Reply-To: <Y2JvT9mHpYAvUS5iSXji4ngtDnuZmp_fPIzxJmGxGes=.39ab8c3b-771e-44d4-a64c-325f50fa3fed@github.com>
References: <Y2JvT9mHpYAvUS5iSXji4ngtDnuZmp_fPIzxJmGxGes=.39ab8c3b-771e-44d4-a64c-325f50fa3fed@github.com>
Message-ID: <_dsjjh2UHZQAmZ4Czbb0HKyGkighWEPhXPs-kqb4ljI=.b51f77b2-ad77-4a07-8a82-5056c6b195e6@github.com>

On Thu, 4 Nov 2021 08:35:55 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> LIR_Assembler::as_Address() may use rscratch1 as a temporary register
> for the address offset if it's too large to fit in an immediate, but
> rscratch1 is also used at the same time to hold the updated MDO value.
> See the discussion on JDK-8276108.

Marked as reviewed by fparain (Committer).

This was a false alarm.
I've re-tested your patch on top of the 8276108 patch, using fresh repos this time, and got no failure.
I probably managed to corrupt my repos somehow yesterday.
Sorry for the disturbance.
The patch looks good to me.

Fred

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

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

From ngasson at openjdk.java.net  Mon Nov  8 06:44:06 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 8 Nov 2021 06:44:06 GMT
Subject: [lworld] RFR: 8276538: [lworld] [AArch64]
 LIR_Assembler::emit_profile_inline_type temporary register conflict
In-Reply-To: <Y2JvT9mHpYAvUS5iSXji4ngtDnuZmp_fPIzxJmGxGes=.39ab8c3b-771e-44d4-a64c-325f50fa3fed@github.com>
References: <Y2JvT9mHpYAvUS5iSXji4ngtDnuZmp_fPIzxJmGxGes=.39ab8c3b-771e-44d4-a64c-325f50fa3fed@github.com>
Message-ID: <3A06xufdkVdh5mE6s7ETNYaZ_tnQzvtNSfB-mJLLsEo=.5fcd897c-a782-4525-a334-9655ddf10e9d@github.com>

On Thu, 4 Nov 2021 08:35:55 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> LIR_Assembler::as_Address() may use rscratch1 as a temporary register
> for the address offset if it's too large to fit in an immediate, but
> rscratch1 is also used at the same time to hold the updated MDO value.
> See the discussion on JDK-8276108.

OK, thanks for the review!

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

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

From thartmann at openjdk.java.net  Mon Nov  8 09:51:01 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 8 Nov 2021 09:51:01 GMT
Subject: [lworld] RFR: 8276538: [lworld] [AArch64]
 LIR_Assembler::emit_profile_inline_type temporary register conflict
In-Reply-To: <Y2JvT9mHpYAvUS5iSXji4ngtDnuZmp_fPIzxJmGxGes=.39ab8c3b-771e-44d4-a64c-325f50fa3fed@github.com>
References: <Y2JvT9mHpYAvUS5iSXji4ngtDnuZmp_fPIzxJmGxGes=.39ab8c3b-771e-44d4-a64c-325f50fa3fed@github.com>
Message-ID: <Fkq_1megv84-tzgKEXgNtdPf6FUYrWkh5W4Jo0mdQsY=.693fdffe-9f10-43a9-aa9a-857d7cb096aa@github.com>

On Thu, 4 Nov 2021 08:35:55 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> LIR_Assembler::as_Address() may use rscratch1 as a temporary register
> for the address offset if it's too large to fit in an immediate, but
> rscratch1 is also used at the same time to hold the updated MDO value.
> See the discussion on JDK-8276108.

Marked as reviewed by thartmann (Committer).

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

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

From ngasson at openjdk.java.net  Mon Nov  8 09:55:08 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 8 Nov 2021 09:55:08 GMT
Subject: [lworld] Integrated: 8276538: [lworld] [AArch64]
 LIR_Assembler::emit_profile_inline_type temporary register conflict
In-Reply-To: <Y2JvT9mHpYAvUS5iSXji4ngtDnuZmp_fPIzxJmGxGes=.39ab8c3b-771e-44d4-a64c-325f50fa3fed@github.com>
References: <Y2JvT9mHpYAvUS5iSXji4ngtDnuZmp_fPIzxJmGxGes=.39ab8c3b-771e-44d4-a64c-325f50fa3fed@github.com>
Message-ID: <0zKwBzyGLSPQJmT7eRKJDmvPDnl_zMznqjUzKh1vQMk=.c1a728cb-748e-4b1c-b870-375326247db4@github.com>

On Thu, 4 Nov 2021 08:35:55 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> LIR_Assembler::as_Address() may use rscratch1 as a temporary register
> for the address offset if it's too large to fit in an immediate, but
> rscratch1 is also used at the same time to hold the updated MDO value.
> See the discussion on JDK-8276108.

This pull request has now been integrated.

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

8276538: [lworld] [AArch64] LIR_Assembler::emit_profile_inline_type temporary register conflict

Reviewed-by: fparain, thartmann

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

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

From fparain at openjdk.java.net  Wed Nov 10 20:03:18 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 10 Nov 2021 20:03:18 GMT
Subject: [lworld] RFR: 8276812: [lworld] [lw3] JVM_ACC_FIELD_INLINED flag
 creates a conflict with an existing flag
Message-ID: <cC-NUb63igJxuQa1qGYapsfjZ-cVYrhg8sbfcERgWHI=.62d9b152-bb63-41c9-993c-4337f829abd7@github.com>

Please review this changeset removing the JVM_ACC_FIELD_INLINED flag from AccessFlags which was conflicting with an existing JVMTI flag.
The flag was use by Unsafe and reflection.
Thanks to Mandy for her fix to the MemberName code.

Tested locally with hotspot_valhalla and jdk_valhalla test suites on x86.
Testing in progress with Mach5 tiers 1 to 3 (no failure related to these changes yet).

Thank you,

Fred

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

Commit messages:
 - Remove JVM_ACC_FIELD_INLINED from MemberName code
 - Removing JVM_ACC_FIELD_INLINED step one

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

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

From mchung at openjdk.java.net  Thu Nov 11 01:45:58 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 11 Nov 2021 01:45:58 GMT
Subject: [lworld] RFR: 8276812: [lworld] [lw3] JVM_ACC_FIELD_INLINED flag
 creates a conflict with an existing flag
In-Reply-To: <cC-NUb63igJxuQa1qGYapsfjZ-cVYrhg8sbfcERgWHI=.62d9b152-bb63-41c9-993c-4337f829abd7@github.com>
References: <cC-NUb63igJxuQa1qGYapsfjZ-cVYrhg8sbfcERgWHI=.62d9b152-bb63-41c9-993c-4337f829abd7@github.com>
Message-ID: <RlTX78_MFuB9Y5c_TggX4L9kKXk9BJWVhtUP3ItTk1s=.e1542cad-513a-4f5c-b49c-2af56af66fd1@github.com>

On Wed, 10 Nov 2021 19:57:42 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this changeset removing the JVM_ACC_FIELD_INLINED flag from AccessFlags which was conflicting with an existing JVMTI flag.
> The flag was use by Unsafe and reflection.
> Thanks to Mandy for her fix to the MemberName code.
> 
> Tested locally with hotspot_valhalla and jdk_valhalla test suites on x86.
> Testing in progress with Mach5 tiers 1 to 3 (no failure related to these changes yet).
> 
> Thank you,
> 
> Fred

Other than the null check needed in `Unsafe::isFlattened`, it looks good.

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 185:

> 183:      */
> 184:     public boolean isFlattened(Field f) {
> 185:         return isFlattenedField0(f);

It should do a null check before calling the native entry:


    if (f == null) {
         throw new NullPointerException();
    }

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

Marked as reviewed by mchung (Committer).

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

From thartmann at openjdk.java.net  Fri Nov 12 12:37:10 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 12 Nov 2021 12:37:10 GMT
Subject: [lworld] Integrated: 8273715: [lworld] C2 compilation fails with
 "missed optimization opportunity"
Message-ID: <xmI_kzX7YOi1qBJqpkXangWg6puMB1jdoiOdQ8s8ECs=.0f994628-1d4b-4fcd-88a3-ccda47ba0140@github.com>

The assert is too strong and triggers due to class loading that happens in parallel to the compilation and changes the output of `Compile::optimize_virtual_call` -> `Compile::optimize_inlining` -> `callee->find_monomorphic_target` which leads to a call being added to the late inline worklist.

Thanks,
Tobias

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

Commit messages:
 - 8273715: [lworld] C2 compilation fails with "missed optimization opportunity"

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

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

From thartmann at openjdk.java.net  Fri Nov 12 12:37:12 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 12 Nov 2021 12:37:12 GMT
Subject: [lworld] Integrated: 8273715: [lworld] C2 compilation fails with
 "missed optimization opportunity"
In-Reply-To: <xmI_kzX7YOi1qBJqpkXangWg6puMB1jdoiOdQ8s8ECs=.0f994628-1d4b-4fcd-88a3-ccda47ba0140@github.com>
References: <xmI_kzX7YOi1qBJqpkXangWg6puMB1jdoiOdQ8s8ECs=.0f994628-1d4b-4fcd-88a3-ccda47ba0140@github.com>
Message-ID: <LaeCGHfxhHkH7YnMslmzi9tt-eoxvoYUDOlHZgyYI_c=.777b5b66-2256-463c-86ab-b87ed2d98878@github.com>

On Fri, 12 Nov 2021 12:28:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The assert is too strong and triggers due to class loading that happens in parallel to the compilation and changes the output of `Compile::optimize_virtual_call` -> `Compile::optimize_inlining` -> `callee->find_monomorphic_target` which leads to a call being added to the late inline worklist.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 62c36b35
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/62c36b3541fe52fcffce20905970b49b62064053
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8273715: [lworld] C2 compilation fails with "missed optimization opportunity"

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

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

From fparain at openjdk.java.net  Fri Nov 12 14:05:18 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 12 Nov 2021 14:05:18 GMT
Subject: [lworld] RFR: 8276812: [lworld] [lw3] JVM_ACC_FIELD_INLINED flag
 creates a conflict with an existing flag [v2]
In-Reply-To: <cC-NUb63igJxuQa1qGYapsfjZ-cVYrhg8sbfcERgWHI=.62d9b152-bb63-41c9-993c-4337f829abd7@github.com>
References: <cC-NUb63igJxuQa1qGYapsfjZ-cVYrhg8sbfcERgWHI=.62d9b152-bb63-41c9-993c-4337f829abd7@github.com>
Message-ID: <Jwf3-QtrszW90ImthgXj7HUV_vVhIO4n8C5gzLETMoA=.33e9d45d-f827-4e65-aedf-36d75939568e@github.com>

> Please review this changeset removing the JVM_ACC_FIELD_INLINED flag from AccessFlags which was conflicting with an existing JVMTI flag.
> The flag was use by Unsafe and reflection.
> Thanks to Mandy for her fix to the MemberName code.
> 
> Tested locally with hotspot_valhalla and jdk_valhalla test suites on x86.
> Testing in progress with Mach5 tiers 1 to 3 (no failure related to these changes yet).
> 
> Thank you,
> 
> Fred

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

  Add null pointer check

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/580/files
  - new: https://git.openjdk.java.net/valhalla/pull/580/files/e6a9ac4a..293e854d

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

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

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

From fparain at openjdk.java.net  Fri Nov 12 14:05:23 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 12 Nov 2021 14:05:23 GMT
Subject: [lworld] RFR: 8276812: [lworld] [lw3] JVM_ACC_FIELD_INLINED flag
 creates a conflict with an existing flag [v2]
In-Reply-To: <RlTX78_MFuB9Y5c_TggX4L9kKXk9BJWVhtUP3ItTk1s=.e1542cad-513a-4f5c-b49c-2af56af66fd1@github.com>
References: <cC-NUb63igJxuQa1qGYapsfjZ-cVYrhg8sbfcERgWHI=.62d9b152-bb63-41c9-993c-4337f829abd7@github.com>
 <RlTX78_MFuB9Y5c_TggX4L9kKXk9BJWVhtUP3ItTk1s=.e1542cad-513a-4f5c-b49c-2af56af66fd1@github.com>
Message-ID: <wh9HdljQPQv5gfsyaBzBQcbuaJptz2e5Nkvg-zcakl8=.c84477cf-ffb3-4a5b-9c52-3ce2ebce1091@github.com>

On Thu, 11 Nov 2021 01:41:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add null pointer check
>
> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 185:
> 
>> 183:      */
>> 184:     public boolean isFlattened(Field f) {
>> 185:         return isFlattenedField0(f);
> 
> It should do a null check before calling the native entry:
> 
> 
>     if (f == null) {
>          throw new NullPointerException();
>     }

Mandy,

Thank you for the review.
I've integrated the null check before pushing the changeset.

Fred

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

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

From fparain at openjdk.java.net  Fri Nov 12 14:05:25 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 12 Nov 2021 14:05:25 GMT
Subject: [lworld] Integrated: 8276812: [lworld] [lw3] JVM_ACC_FIELD_INLINED
 flag creates a conflict with an existing flag
In-Reply-To: <cC-NUb63igJxuQa1qGYapsfjZ-cVYrhg8sbfcERgWHI=.62d9b152-bb63-41c9-993c-4337f829abd7@github.com>
References: <cC-NUb63igJxuQa1qGYapsfjZ-cVYrhg8sbfcERgWHI=.62d9b152-bb63-41c9-993c-4337f829abd7@github.com>
Message-ID: <vafbgrQtYQ5UYp_P_-XprQe_Pjrji3dmSooo9_ie4JM=.ff91ea14-d810-4bff-aa01-f2197997394b@github.com>

On Wed, 10 Nov 2021 19:57:42 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this changeset removing the JVM_ACC_FIELD_INLINED flag from AccessFlags which was conflicting with an existing JVMTI flag.
> The flag was use by Unsafe and reflection.
> Thanks to Mandy for her fix to the MemberName code.
> 
> Tested locally with hotspot_valhalla and jdk_valhalla test suites on x86.
> Testing in progress with Mach5 tiers 1 to 3 (no failure related to these changes yet).
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 935c40ec
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/935c40ece1cc15083ac55f4472dcb6834c9017fa
Stats:     34 lines in 9 files changed: 19 ins; 11 del; 4 mod

8276812: [lworld] [lw3] JVM_ACC_FIELD_INLINED flag creates a conflict with an existing flag

Reviewed-by: mchung

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

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

From fparain at openjdk.java.net  Fri Nov 12 14:53:24 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 12 Nov 2021 14:53:24 GMT
Subject: [lworld] RFR: 8277057: [lworld] array code needs some name cleanup
Message-ID: <eveD-RCzrVNtWOgkO4gXivHVEiYk_KxrDIMoOT75unk=.a26d2631-c194-46db-a940-fff09f8e2a01@github.com>

Please review this changeset which renames some flags and methods to align them with the current semantics and behavior. Clearer names would help introducing nullable inline types later.

Thank you,

Fred

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

Commit messages:
 - Renaming of flags and methods

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

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

From thartmann at openjdk.java.net  Fri Nov 12 15:37:09 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 12 Nov 2021 15:37:09 GMT
Subject: [lworld] RFR: 8277062: [lworld] C2 compilation fails with
 "not drained yet" assert
Message-ID: <4uMv4H9xy1tk7m6ewJvb3bM_7-mr0pDS22JHLvf_MAU=.a4ac4c48-4864-4642-acf7-64494a06c7c7@github.com>

Trivial follow-up fix after [JDK-8273715](https://bugs.openjdk.java.net/browse/JDK-8273715). We need to clear the late inlines worklist to make the assert happy.

Thanks,
Tobias

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

Commit messages:
 - 8277062: [lworld] C2 compilation fails with "not drained yet" assert

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

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

From thartmann at openjdk.java.net  Fri Nov 12 16:05:50 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 12 Nov 2021 16:05:50 GMT
Subject: [lworld] Integrated: 8277062: [lworld] C2 compilation fails with
 "not drained yet" assert
In-Reply-To: <4uMv4H9xy1tk7m6ewJvb3bM_7-mr0pDS22JHLvf_MAU=.a4ac4c48-4864-4642-acf7-64494a06c7c7@github.com>
References: <4uMv4H9xy1tk7m6ewJvb3bM_7-mr0pDS22JHLvf_MAU=.a4ac4c48-4864-4642-acf7-64494a06c7c7@github.com>
Message-ID: <62_BC7WEXhpEEUYRJHZwR8MNGcOZ4WxcP0IaKeoIODI=.2c852cb4-a8c5-45ad-8a56-61f7e4fa1c2a@github.com>

On Fri, 12 Nov 2021 15:30:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Trivial follow-up fix after [JDK-8273715](https://bugs.openjdk.java.net/browse/JDK-8273715). We need to clear the late inlines worklist to make the assert happy.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8277062: [lworld] C2 compilation fails with "not drained yet" assert

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

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

From ngasson at openjdk.java.net  Mon Nov 15 03:59:06 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 15 Nov 2021 03:59:06 GMT
Subject: [lworld] RFR: 8277057: [lworld] array code needs some name cleanup
In-Reply-To: <eveD-RCzrVNtWOgkO4gXivHVEiYk_KxrDIMoOT75unk=.a26d2631-c194-46db-a940-fff09f8e2a01@github.com>
References: <eveD-RCzrVNtWOgkO4gXivHVEiYk_KxrDIMoOT75unk=.a26d2631-c194-46db-a940-fff09f8e2a01@github.com>
Message-ID: <S-yXt5_2jnc6CjGr0tbQ4sgdV5CEi6l5jVHkKO0CX2c=.cc28347c-15c7-4110-aca1-610ad58959e5@github.com>

On Fri, 12 Nov 2021 14:47:05 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this changeset which renames some flags and methods to align them with the current semantics and behavior. Clearer names would help introducing nullable inline types later.
> 
> Thank you,
> 
> Fred

I think `c1_LIRAssembler_aarch64.cpp` needs these replacements too.

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

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

From dsimms at openjdk.java.net  Mon Nov 15 13:12:57 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 15 Nov 2021 13:12:57 GMT
Subject: [lworld] RFR: 8277057: [lworld] array code needs some name cleanup
In-Reply-To: <eveD-RCzrVNtWOgkO4gXivHVEiYk_KxrDIMoOT75unk=.a26d2631-c194-46db-a940-fff09f8e2a01@github.com>
References: <eveD-RCzrVNtWOgkO4gXivHVEiYk_KxrDIMoOT75unk=.a26d2631-c194-46db-a940-fff09f8e2a01@github.com>
Message-ID: <thc0nG_w44Df4SSUrj1LrxzW6NWitvQ15ijCzuQ8hRc=.2234e5ab-241f-4273-ae54-ac9367559c7f@github.com>

On Fri, 12 Nov 2021 14:47:05 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this changeset which renames some flags and methods to align them with the current semantics and behavior. Clearer names would help introducing nullable inline types later.
> 
> Thank you,
> 
> Fred

With the addition of c1_LIRAssembler_aarch64.cpp, renaming looks good

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

Marked as reviewed by dsimms (Committer).

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

From fparain at openjdk.java.net  Mon Nov 15 15:39:31 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 15 Nov 2021 15:39:31 GMT
Subject: [lworld] RFR: 8277057: [lworld] array code needs some name cleanup
 [v2]
In-Reply-To: <eveD-RCzrVNtWOgkO4gXivHVEiYk_KxrDIMoOT75unk=.a26d2631-c194-46db-a940-fff09f8e2a01@github.com>
References: <eveD-RCzrVNtWOgkO4gXivHVEiYk_KxrDIMoOT75unk=.a26d2631-c194-46db-a940-fff09f8e2a01@github.com>
Message-ID: <-qIO9KYWxqoIxIOKaBbZMTGBNeKn5nGf974XkTeYMHs=.899834cd-a3e3-4dfa-8a69-e9c9637217d6@github.com>

> Please review this changeset which renames some flags and methods to align them with the current semantics and behavior. Clearer names would help introducing nullable inline types later.
> 
> Thank you,
> 
> Fred

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

  Apply renaming to aarch64 file

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/582/files
  - new: https://git.openjdk.java.net/valhalla/pull/582/files/b1e6140a..5958fad3

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

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

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

From fparain at openjdk.java.net  Mon Nov 15 15:39:32 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 15 Nov 2021 15:39:32 GMT
Subject: [lworld] RFR: 8277057: [lworld] array code needs some name cleanup
In-Reply-To: <eveD-RCzrVNtWOgkO4gXivHVEiYk_KxrDIMoOT75unk=.a26d2631-c194-46db-a940-fff09f8e2a01@github.com>
References: <eveD-RCzrVNtWOgkO4gXivHVEiYk_KxrDIMoOT75unk=.a26d2631-c194-46db-a940-fff09f8e2a01@github.com>
Message-ID: <-iw4NZU5me8INpQS_lD0rXfxwSrCJadUZ0iiFfGiiuE=.541164bf-ef85-4bbc-942e-95db2627a699@github.com>

On Fri, 12 Nov 2021 14:47:05 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this changeset which renames some flags and methods to align them with the current semantics and behavior. Clearer names would help introducing nullable inline types later.
> 
> Thank you,
> 
> Fred

Nick, David,

Thank you for your reviews.
I've applied the renaming to c1_LIRAssembler_aarch64.cpp and checked the build aarch64 with Mach5.

Fred

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

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

From fparain at openjdk.java.net  Mon Nov 15 16:01:01 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 15 Nov 2021 16:01:01 GMT
Subject: [lworld] Integrated: 8277057: [lworld] array code needs some name
 cleanup
In-Reply-To: <eveD-RCzrVNtWOgkO4gXivHVEiYk_KxrDIMoOT75unk=.a26d2631-c194-46db-a940-fff09f8e2a01@github.com>
References: <eveD-RCzrVNtWOgkO4gXivHVEiYk_KxrDIMoOT75unk=.a26d2631-c194-46db-a940-fff09f8e2a01@github.com>
Message-ID: <1dqtSxBp1uHHKKeRmr-Kju2BnY4tKKizNwxiG_jpTm4=.88bc824f-ef1c-40e2-ba52-530e99c90e1b@github.com>

On Fri, 12 Nov 2021 14:47:05 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this changeset which renames some flags and methods to align them with the current semantics and behavior. Clearer names would help introducing nullable inline types later.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 3b8813c7
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/3b8813c796cf92f6d400a7146404a28a8d8beab0
Stats:     80 lines in 25 files changed: 0 ins; 0 del; 80 mod

8277057: [lworld] array code needs some name cleanup

Reviewed-by: dsimms

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

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

From roland at openjdk.java.net  Fri Nov 19 10:43:12 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 19 Nov 2021 10:43:12 GMT
Subject: [lworld] RFR: 8274973: [lworld]
 compiler/c2/irTests/TestPostParseCallDevirtualization.java fails with valhalla
Message-ID: <Na_FZacvrFsaCqm0dD4eoq5u3-wncFNrCz2VGCFiq1U=.b8fbcaa9-1029-4289-b219-e7f5a863c3be@github.com>

This fixes a difference with upstream. It must be something that got dropped in a merge.

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

Commit messages:
 - fix

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

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

From thartmann at openjdk.java.net  Fri Nov 19 11:53:58 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 19 Nov 2021 11:53:58 GMT
Subject: [lworld] RFR: 8274973: [lworld]
 compiler/c2/irTests/TestPostParseCallDevirtualization.java fails with valhalla
In-Reply-To: <Na_FZacvrFsaCqm0dD4eoq5u3-wncFNrCz2VGCFiq1U=.b8fbcaa9-1029-4289-b219-e7f5a863c3be@github.com>
References: <Na_FZacvrFsaCqm0dD4eoq5u3-wncFNrCz2VGCFiq1U=.b8fbcaa9-1029-4289-b219-e7f5a863c3be@github.com>
Message-ID: <WUL9oAFA12mhDk-yO2oChGwqTBly5fox1KXXFhBGDwQ=.5b8df1e0-f1af-4edd-b451-defe8389d21a@github.com>

On Fri, 19 Nov 2021 10:36:51 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> This fixes a difference with upstream. It must be something that got dropped in a merge.

Looks good, thanks for fixing!

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

Marked as reviewed by thartmann (Committer).

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

From roland at openjdk.java.net  Fri Nov 19 12:49:33 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 19 Nov 2021 12:49:33 GMT
Subject: git: openjdk/valhalla: lworld: 8274973: [lworld]
 compiler/c2/irTests/TestPostParseCallDevirtualization.java fails with valhalla
Message-ID: <32321b40-e9a4-4e1e-be84-61442a0d446e@openjdk.org>

Changeset: d7f31ef2
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2021-11-19 12:49:04 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/d7f31ef2ef8fc0903e0e9c422d4b71de0db099fc

8274973: [lworld] compiler/c2/irTests/TestPostParseCallDevirtualization.java fails with valhalla

Reviewed-by: thartmann

! src/hotspot/share/opto/callGenerator.cpp
! test/hotspot/jtreg/ProblemList.txt


From roland at openjdk.java.net  Fri Nov 19 12:53:58 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 19 Nov 2021 12:53:58 GMT
Subject: [lworld] Integrated: 8274973: [lworld]
 compiler/c2/irTests/TestPostParseCallDevirtualization.java fails with valhalla
In-Reply-To: <Na_FZacvrFsaCqm0dD4eoq5u3-wncFNrCz2VGCFiq1U=.b8fbcaa9-1029-4289-b219-e7f5a863c3be@github.com>
References: <Na_FZacvrFsaCqm0dD4eoq5u3-wncFNrCz2VGCFiq1U=.b8fbcaa9-1029-4289-b219-e7f5a863c3be@github.com>
Message-ID: <vK48u-w5fZKuhX7qKewYOF9ETpBmWphlnFa5nch4iDo=.147526c8-5a42-4dc0-bc4a-eff2fba359e3@github.com>

On Fri, 19 Nov 2021 10:36:51 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> This fixes a difference with upstream. It must be something that got dropped in a merge.

This pull request has now been integrated.

Changeset: d7f31ef2
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/d7f31ef2ef8fc0903e0e9c422d4b71de0db099fc
Stats:     2 lines in 2 files changed: 0 ins; 1 del; 1 mod

8274973: [lworld] compiler/c2/irTests/TestPostParseCallDevirtualization.java fails with valhalla

Reviewed-by: thartmann

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

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

From fparain at openjdk.java.net  Mon Nov 22 16:56:51 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 22 Nov 2021 16:56:51 GMT
Subject: [lworld] RFR: 8277570: [lworld] Pre-allocated instance should be
 created during class initialization
Message-ID: <Me9Px2SwL1rwH-bXaT9yK5vB6EptwKjuKkym05sF7Cc=.c9b068cc-6309-4ab0-b96a-a619a54cde9f@github.com>

Please review those changes moving the creation of the pre-allocated default instance from the loading phase to the class initialization phase. The changes also include fixes in C1 to ensure the class is initialized before optimizing empty classes.

Thank you,

Fred

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

Commit messages:
 - Move pre-allocation of default instance to initialization

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

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

From amenkov at openjdk.java.net  Tue Nov 23 04:47:23 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 23 Nov 2021 04:47:23 GMT
Subject: [lworld] RFR: 8277570: [lworld] Pre-allocated instance should be
 created during class initialization
In-Reply-To: <Me9Px2SwL1rwH-bXaT9yK5vB6EptwKjuKkym05sF7Cc=.c9b068cc-6309-4ab0-b96a-a619a54cde9f@github.com>
References: <Me9Px2SwL1rwH-bXaT9yK5vB6EptwKjuKkym05sF7Cc=.c9b068cc-6309-4ab0-b96a-a619a54cde9f@github.com>
Message-ID: <w0_QjcJpacxordGX8TEjIqjxpOlqlI6h-FAxy-n0n_o=.209dc714-149d-47cc-82a1-529beebf1158@github.com>

On Mon, 22 Nov 2021 16:50:29 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes moving the creation of the pre-allocated default instance from the loading phase to the class initialization phase. The changes also include fixes in C1 to ensure the class is initialized before optimizing empty classes.
> 
> Thank you,
> 
> Fred

What about loading classes from CDS archive?
SystemDictionary::load_shared_class also contains code to allocate default value.
I suppose classes from CDS need initialization anyway.

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

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

From fparain at openjdk.java.net  Tue Nov 23 15:08:19 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 23 Nov 2021 15:08:19 GMT
Subject: [lworld] RFR: 8277570: [lworld] Pre-allocated instance should be
 created during class initialization [v2]
In-Reply-To: <Me9Px2SwL1rwH-bXaT9yK5vB6EptwKjuKkym05sF7Cc=.c9b068cc-6309-4ab0-b96a-a619a54cde9f@github.com>
References: <Me9Px2SwL1rwH-bXaT9yK5vB6EptwKjuKkym05sF7Cc=.c9b068cc-6309-4ab0-b96a-a619a54cde9f@github.com>
Message-ID: <iT3vtg_MH4LkWBW9Mm2pAjmwQ2sN6kGcO2vxm6G9HUM=.0df11942-1f6b-4b0b-8f95-3242dbad86e2@github.com>

> Please review those changes moving the creation of the pre-allocated default instance from the loading phase to the class initialization phase. The changes also include fixes in C1 to ensure the class is initialized before optimizing empty classes.
> 
> Thank you,
> 
> Fred

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

  Fix default value allocation in CDS, more asserts

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/585/files
  - new: https://git.openjdk.java.net/valhalla/pull/585/files/97dacab2..ceca1e67

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

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

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

From dsimms at openjdk.java.net  Tue Nov 23 15:21:43 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 23 Nov 2021 15:21:43 GMT
Subject: [lworld] RFR: 8277570: [lworld] Pre-allocated instance should be
 created during class initialization [v2]
In-Reply-To: <iT3vtg_MH4LkWBW9Mm2pAjmwQ2sN6kGcO2vxm6G9HUM=.0df11942-1f6b-4b0b-8f95-3242dbad86e2@github.com>
References: <Me9Px2SwL1rwH-bXaT9yK5vB6EptwKjuKkym05sF7Cc=.c9b068cc-6309-4ab0-b96a-a619a54cde9f@github.com>
 <iT3vtg_MH4LkWBW9Mm2pAjmwQ2sN6kGcO2vxm6G9HUM=.0df11942-1f6b-4b0b-8f95-3242dbad86e2@github.com>
Message-ID: <gOZhYBeV_EefoMXYzxg3O-nitvBu3dUqAfXKxYVSGEk=.71237153-8df6-4e02-bee9-2dca84ed8f85@github.com>

On Tue, 23 Nov 2021 15:08:19 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review those changes moving the creation of the pre-allocated default instance from the loading phase to the class initialization phase. The changes also include fixes in C1 to ensure the class is initialized before optimizing empty classes.
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix default value allocation in CDS, more asserts

Looks good

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

Marked as reviewed by dsimms (Committer).

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

From fparain at openjdk.java.net  Tue Nov 23 17:31:29 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 23 Nov 2021 17:31:29 GMT
Subject: [lworld] RFR: 8277570: [lworld] Pre-allocated instance should be
 created during class initialization [v2]
In-Reply-To: <iT3vtg_MH4LkWBW9Mm2pAjmwQ2sN6kGcO2vxm6G9HUM=.0df11942-1f6b-4b0b-8f95-3242dbad86e2@github.com>
References: <Me9Px2SwL1rwH-bXaT9yK5vB6EptwKjuKkym05sF7Cc=.c9b068cc-6309-4ab0-b96a-a619a54cde9f@github.com>
 <iT3vtg_MH4LkWBW9Mm2pAjmwQ2sN6kGcO2vxm6G9HUM=.0df11942-1f6b-4b0b-8f95-3242dbad86e2@github.com>
Message-ID: <uKaEvQhLmPSNaxI5nJ7gYKuWjtPgJaB6K5ChV9M66b0=.cd8fdc95-b223-4a93-9916-e96d837a6a19@github.com>

On Tue, 23 Nov 2021 15:08:19 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review those changes moving the creation of the pre-allocated default instance from the loading phase to the class initialization phase. The changes also include fixes in C1 to ensure the class is initialized before optimizing empty classes.
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix default value allocation in CDS, more asserts

Alex,

Thank you for spotting the missing fix in CDS, this has been addressed with the latest commit.

Fred

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

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

From amenkov at openjdk.java.net  Tue Nov 23 18:44:17 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 23 Nov 2021 18:44:17 GMT
Subject: [lworld] RFR: 8277570: [lworld] Pre-allocated instance should be
 created during class initialization [v2]
In-Reply-To: <iT3vtg_MH4LkWBW9Mm2pAjmwQ2sN6kGcO2vxm6G9HUM=.0df11942-1f6b-4b0b-8f95-3242dbad86e2@github.com>
References: <Me9Px2SwL1rwH-bXaT9yK5vB6EptwKjuKkym05sF7Cc=.c9b068cc-6309-4ab0-b96a-a619a54cde9f@github.com>
 <iT3vtg_MH4LkWBW9Mm2pAjmwQ2sN6kGcO2vxm6G9HUM=.0df11942-1f6b-4b0b-8f95-3242dbad86e2@github.com>
Message-ID: <6nO0Tzsyf-IPcaPUtJIye4e2oJNwlr3PtDr3x3Iylkw=.619874fe-6577-4490-b945-3f8335c46c29@github.com>

On Tue, 23 Nov 2021 15:08:19 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review those changes moving the creation of the pre-allocated default instance from the loading phase to the class initialization phase. The changes also include fixes in C1 to ensure the class is initialized before optimizing empty classes.
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix default value allocation in CDS, more asserts

Marked as reviewed by amenkov (Committer).

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

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

From fparain at openjdk.java.net  Tue Nov 23 19:59:23 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 23 Nov 2021 19:59:23 GMT
Subject: [lworld] RFR: 8277570: [lworld] Pre-allocated instance should be
 created during class initialization [v2]
In-Reply-To: <iT3vtg_MH4LkWBW9Mm2pAjmwQ2sN6kGcO2vxm6G9HUM=.0df11942-1f6b-4b0b-8f95-3242dbad86e2@github.com>
References: <Me9Px2SwL1rwH-bXaT9yK5vB6EptwKjuKkym05sF7Cc=.c9b068cc-6309-4ab0-b96a-a619a54cde9f@github.com>
 <iT3vtg_MH4LkWBW9Mm2pAjmwQ2sN6kGcO2vxm6G9HUM=.0df11942-1f6b-4b0b-8f95-3242dbad86e2@github.com>
Message-ID: <1GqryOO1_bLYZPiyeiTN4aW8ZKHAWqyXb-6ybQ6rPLY=.b5488adf-2208-471c-89d1-d9061e727d4f@github.com>

On Tue, 23 Nov 2021 15:08:19 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review those changes moving the creation of the pre-allocated default instance from the loading phase to the class initialization phase. The changes also include fixes in C1 to ensure the class is initialized before optimizing empty classes.
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix default value allocation in CDS, more asserts

Alex. David,

Thank you for your reviews.

Fred

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

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

From fparain at openjdk.java.net  Tue Nov 23 19:59:24 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 23 Nov 2021 19:59:24 GMT
Subject: [lworld] Integrated: 8277570: [lworld] Pre-allocated instance should
 be created during class initialization
In-Reply-To: <Me9Px2SwL1rwH-bXaT9yK5vB6EptwKjuKkym05sF7Cc=.c9b068cc-6309-4ab0-b96a-a619a54cde9f@github.com>
References: <Me9Px2SwL1rwH-bXaT9yK5vB6EptwKjuKkym05sF7Cc=.c9b068cc-6309-4ab0-b96a-a619a54cde9f@github.com>
Message-ID: <rqB7BWQh9SJjZnbT8Pmb8750D7QSpmECEe2ogFzFGpQ=.3b692e75-a545-4cb1-91d3-14de91c54c17@github.com>

On Mon, 22 Nov 2021 16:50:29 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes moving the creation of the pre-allocated default instance from the loading phase to the class initialization phase. The changes also include fixes in C1 to ensure the class is initialized before optimizing empty classes.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: b9afd2a0
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/b9afd2a05794e747e664bf7b8a0e97573289b96c
Stats:     44 lines in 7 files changed: 27 ins; 14 del; 3 mod

8277570: [lworld] Pre-allocated instance should be created during class initialization

Reviewed-by: dsimms, amenkov

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

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