From dsimms at openjdk.java.net  Tue Sep  1 09:21:18 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 1 Sep 2020 09:21:18 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <MpXC5VLi6eejWboCnx7nuiWw8xiTT8MqJlXOc4t35Tw=.498a1c2d-abe1-4f35-834b-f15907c81fd7@github.com>

Merge tag 'jdk-16+7' into lworld_merge_jdk_16_7
Added tag jdk-16+7 for changeset c3a4a7ea7c30

# Conflicts:
#	src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
#	src/hotspot/share/memory/universe.cpp
#	src/hotspot/share/memory/universe.hpp
#	src/hotspot/share/opto/macro.cpp
#	src/hotspot/share/opto/node.cpp
#	src/hotspot/share/prims/jni.cpp

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

Commit messages:
 - Merge tag 'jdk-16+7' into lworld_merge_jdk_16_7
 - 8249880: JVMCI calling register_nmethod without CodeCache lock
 - 8249884: Shenandoah: Call report_num_dead() from ShParallelWeakRootsCleaningTask destructor
 - 8249768: Move static oops and NullPointerException oops from Universe into OopStorage
 - 8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end
 - 8249877: Shenandoah: Report number of dead weak oops during STW weak roots
 - 8247743: Segmentation fault in debug builds due to stack overflow in find_recur with deep graphs
 - 8248467: C2: compiler/intrinsics/object/TestClone fails with -XX:+VerifyGraphEdges
 - 8249650: Optimize JNIHandle::make_local thread variable usage
 - 8246032: Implementation of JEP 347: Enable C++14 Language Features
 - ... and 66 more: https://git.openjdk.java.net/valhalla/compare/a8215ec3...686d3bc5

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

Changes: https://git.openjdk.java.net/valhalla/pull/168/files
  Stats: 8470 lines in 1321 files changed: 3670 ins; 2293 del; 2507 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/168.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/168/head:pull/168

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


From dsimms at openjdk.java.net  Tue Sep  1 09:21:20 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 1 Sep 2020 09:21:20 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <MpXC5VLi6eejWboCnx7nuiWw8xiTT8MqJlXOc4t35Tw=.498a1c2d-abe1-4f35-834b-f15907c81fd7@github.com>
References: <MpXC5VLi6eejWboCnx7nuiWw8xiTT8MqJlXOc4t35Tw=.498a1c2d-abe1-4f35-834b-f15907c81fd7@github.com>
Message-ID: <1S0GnAn-Opp489sGq5RGlFzCs1OvRcnkVOCBpRAMDw0=.b242f892-1528-40b6-b6e2-eaf6946f385d@github.com>

On Tue, 1 Sep 2020 09:11:15 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+7' into lworld_merge_jdk_16_7
> Added tag jdk-16+7 for changeset c3a4a7ea7c30
> 
> # Conflicts:
> #	src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
> #	src/hotspot/share/memory/universe.cpp
> #	src/hotspot/share/memory/universe.hpp
> #	src/hotspot/share/opto/macro.cpp
> #	src/hotspot/share/opto/node.cpp
> #	src/hotspot/share/prims/jni.cpp

This pull request has now been integrated.

Changeset: 8816727d
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/8816727d
Stats:     8508 lines in 1321 files changed: 2292 ins; 3709 del; 2507 mod

Merge jdk

Merge tag 'jdk-16+7'

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

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


From dsimms at openjdk.java.net  Tue Sep  1 10:29:50 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 1 Sep 2020 10:29:50 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <4rXjStFbagIGuMpkN_TaFuHzVSTMMpiCtUgyHFNbGZI=.4bda03b8-6490-4b1d-a7e2-c3c27c5c5168@github.com>

Merge tag 'jdk-16+8' into lworld_merge_jdk_16_8
Added tag jdk-16+8 for changeset 0a73d6f3aab4

# Conflicts:
#	src/hotspot/share/opto/loopopts.cpp

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

Commit messages:
 - Merge tag 'jdk-16+8' into lworld_merge_jdk_16_8
 - 8248657: Windows: strengthening in ThreadCritical regarding memory model
 - 8250612: jvmciCompilerToVM.cpp declares jio_printf with "void" return type, should be "int"
 - 8249719: MethodHandle performance suffers from bad ResolvedMethodTable hash function
 - Merge
 - 8250688: missed open parenthesis for GTEST_FRAMEWORK_SRC var in Main.gmk
 - 8250588: Shenandoah: LRB needs to save/restore fp registers for runtime call
 - 8250742: ProblemList serviceability/sa/ClhsdbPstack.java #id0 and #id1 for ZGC
 - 8249643: Clarify DOM documentation
 - 8250580: Address reliance on default constructors in java.rmi
 - ... and 137 more: https://git.openjdk.java.net/valhalla/compare/8816727d...3eb98902

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

Changes: https://git.openjdk.java.net/valhalla/pull/169/files
  Stats: 7400 lines in 509 files changed: 5008 ins; 1064 del; 1328 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/169.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/169/head:pull/169

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


From dsimms at openjdk.java.net  Tue Sep  1 10:29:52 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 1 Sep 2020 10:29:52 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <4rXjStFbagIGuMpkN_TaFuHzVSTMMpiCtUgyHFNbGZI=.4bda03b8-6490-4b1d-a7e2-c3c27c5c5168@github.com>
References: <4rXjStFbagIGuMpkN_TaFuHzVSTMMpiCtUgyHFNbGZI=.4bda03b8-6490-4b1d-a7e2-c3c27c5c5168@github.com>
Message-ID: <ccIpkz-NfzP6zWjSFp3sJC-EvNxZPdN8zhcFGaGiAL0=.f83fbaf5-2e31-408e-87e2-c2eba82dc766@github.com>

On Tue, 1 Sep 2020 10:21:26 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+8' into lworld_merge_jdk_16_8
> Added tag jdk-16+8 for changeset 0a73d6f3aab4
> 
> # Conflicts:
> #	src/hotspot/share/opto/loopopts.cpp

This pull request has now been integrated.

Changeset: f543f733
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f543f733
Stats:     7437 lines in 509 files changed: 1101 ins; 5045 del; 1291 mod

Merge jdk

Merge tag 'jdk-16+8'

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

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


From thartmann at openjdk.java.net  Tue Sep  1 11:59:48 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 1 Sep 2020 11:59:48 GMT
Subject: [lworld] RFR: 8252633: [lworld] Multiple compiler test failures after
 merging jdk-16+7
Message-ID: <VTY9DWLjehp3Wvi-CxcPj3ZT0u7gtdEIOuL0HPK03o8=.7b8c7b4f-e163-4f2d-9ba5-48dab313d74b@github.com>

Fixed incorrect merge (skip_fixup label is not bound anymore to code in gen_c2i_adapter).

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

Commit messages:
 - 8252633: [lworld] Multiple compiler test failures after merging jdk-16+7

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

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


From thartmann at openjdk.java.net  Tue Sep  1 12:26:31 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 1 Sep 2020 12:26:31 GMT
Subject: [lworld] Integrated: 8252633: [lworld] Multiple compiler test
 failures after merging jdk-16+7
In-Reply-To: <VTY9DWLjehp3Wvi-CxcPj3ZT0u7gtdEIOuL0HPK03o8=.7b8c7b4f-e163-4f2d-9ba5-48dab313d74b@github.com>
References: <VTY9DWLjehp3Wvi-CxcPj3ZT0u7gtdEIOuL0HPK03o8=.7b8c7b4f-e163-4f2d-9ba5-48dab313d74b@github.com>
Message-ID: <7FHDPjms0cMVtdbPoiOMwYmEUk_J4QhILm8B0mAKr98=.8b97e474-3223-4f6b-b7a9-bc0ce0673b92@github.com>

On Tue, 1 Sep 2020 11:54:47 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Fixed incorrect merge (skip_fixup label is not bound anymore to code in gen_c2i_adapter).

This pull request has now been integrated.

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

8252633: [lworld] Multiple compiler test failures after merging jdk-16+7

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

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


From dsimms at openjdk.java.net  Tue Sep  1 12:37:02 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 1 Sep 2020 12:37:02 GMT
Subject: [lworld] Integrated: 8252651: [lworld] Clear the instance klass
 mirror for inline type
Message-ID: <R11l9-X6boqL2ru8w3g92zRD5sFjxZjJyy7Wwd2hp7k=.bea22612-8ba3-4373-bcc4-d0d36fd207fe@github.com>

clear the mirror, don't set empty handle

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

Commit messages:
 - 8252651: [lworld] Clear the instance klass mirror for inline type

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

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


From dsimms at openjdk.java.net  Tue Sep  1 12:37:04 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 1 Sep 2020 12:37:04 GMT
Subject: [lworld] Integrated: 8252651: [lworld] Clear the instance klass
 mirror for inline type
In-Reply-To: <R11l9-X6boqL2ru8w3g92zRD5sFjxZjJyy7Wwd2hp7k=.bea22612-8ba3-4373-bcc4-d0d36fd207fe@github.com>
References: <R11l9-X6boqL2ru8w3g92zRD5sFjxZjJyy7Wwd2hp7k=.bea22612-8ba3-4373-bcc4-d0d36fd207fe@github.com>
Message-ID: <SawiDunac7wCdeM-whY81b2sPJoWK5frSVlGLvajfTQ=.b3b1ca04-14fd-4be1-9659-048726174b02@github.com>

On Tue, 1 Sep 2020 12:30:52 GMT, David Simms <dsimms at openjdk.org> wrote:

> clear the mirror, don't set empty handle

This pull request has now been integrated.

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

8252651: [lworld] Clear the instance klass mirror for inline type

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

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


From dsimms at openjdk.java.net  Tue Sep  1 12:59:45 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 1 Sep 2020 12:59:45 GMT
Subject: [lworld] RFR: 8252650: [lworld] Merge of jdk-16+8 breaks debug build
 GC gc/TestObjectAlignment.java
Message-ID: <lLmBHAyM88t8XEYD9GQN08JjCcfHRj-zG3_TpuoLy3w=.1706b43c-2db3-4d65-88a0-20ffca11c812@github.com>

Apply in advance: 8251118: BiasedLocking::preserve_marks should not have a HandleMark

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

Commit messages:
 - 8252650: [lworld] Merge of jdk-16+8 breaks debug build GC gc/TestObjectAlignment.java

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

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


From hseigel at openjdk.java.net  Tue Sep  1 13:09:18 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 1 Sep 2020 13:09:18 GMT
Subject: [lworld] RFR: 8252650: [lworld] Merge of jdk-16+8 breaks debug
 build GC gc/TestObjectAlignment.java
In-Reply-To: <lLmBHAyM88t8XEYD9GQN08JjCcfHRj-zG3_TpuoLy3w=.1706b43c-2db3-4d65-88a0-20ffca11c812@github.com>
References: <lLmBHAyM88t8XEYD9GQN08JjCcfHRj-zG3_TpuoLy3w=.1706b43c-2db3-4d65-88a0-20ffca11c812@github.com>
Message-ID: <iOf9HRlyldXMzz3FzWJuSBtiQE3E8ZQ4VS3HxEEflyc=.cc741e42-b773-41f8-bf7e-c51f37fbcef7@github.com>

On Tue, 1 Sep 2020 12:54:54 GMT, David Simms <dsimms at openjdk.org> wrote:

> Apply in advance: 8251118: BiasedLocking::preserve_marks should not have a HandleMark

Marked as reviewed by hseigel (Committer).

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

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


From hseigel at openjdk.java.net  Tue Sep  1 13:09:18 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 1 Sep 2020 13:09:18 GMT
Subject: [lworld] RFR: 8252650: [lworld] Merge of jdk-16+8 breaks debug
 build GC gc/TestObjectAlignment.java
In-Reply-To: <iOf9HRlyldXMzz3FzWJuSBtiQE3E8ZQ4VS3HxEEflyc=.cc741e42-b773-41f8-bf7e-c51f37fbcef7@github.com>
References: <lLmBHAyM88t8XEYD9GQN08JjCcfHRj-zG3_TpuoLy3w=.1706b43c-2db3-4d65-88a0-20ffca11c812@github.com>
 <iOf9HRlyldXMzz3FzWJuSBtiQE3E8ZQ4VS3HxEEflyc=.cc741e42-b773-41f8-bf7e-c51f37fbcef7@github.com>
Message-ID: <LeNSER0vmIVScG4w8lnZMJqoiF5O1hTUm1OT0TrJfjA=.bd7bac52-ac04-4756-80c6-85452093307a@github.com>

On Tue, 1 Sep 2020 13:06:49 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Apply in advance: 8251118: BiasedLocking::preserve_marks should not have a HandleMark
>
> Marked as reviewed by hseigel (Committer).

Changes look good!

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

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


From dsimms at openjdk.java.net  Tue Sep  1 13:48:02 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 1 Sep 2020 13:48:02 GMT
Subject: [lworld] Integrated: 8252650: [lworld] Merge of jdk-16+8 breaks debug
 build GC gc/TestObjectAlignment.java
In-Reply-To: <lLmBHAyM88t8XEYD9GQN08JjCcfHRj-zG3_TpuoLy3w=.1706b43c-2db3-4d65-88a0-20ffca11c812@github.com>
References: <lLmBHAyM88t8XEYD9GQN08JjCcfHRj-zG3_TpuoLy3w=.1706b43c-2db3-4d65-88a0-20ffca11c812@github.com>
Message-ID: <gCm2o3ELvHH0BIo2hv5gqbSUG78IAw65FywBLGi5FU4=.4fb3e6ae-d3c5-4722-be66-7db6d2cebe54@github.com>

On Tue, 1 Sep 2020 12:54:54 GMT, David Simms <dsimms at openjdk.org> wrote:

> Apply in advance: 8251118: BiasedLocking::preserve_marks should not have a HandleMark

This pull request has now been integrated.

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

8252650: [lworld] Merge of jdk-16+8 breaks debug build GC gc/TestObjectAlignment.java

Reviewed-by: hseigel

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

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


From dsimms at openjdk.java.net  Wed Sep  2 05:16:29 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Sep 2020 05:16:29 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <pWaZ0Qu9qxuuw-pxT3VLJ2pF3EtQCtyRYfxkL0M_SDw=.659e630f-d49a-42e8-81d4-def23451d9bc@github.com>

Merge tag 'jdk-16+9' into lworld_merge_jdk_16_9
Added tag jdk-16+9 for changeset c075a286cc7d

# Conflicts:
#	src/hotspot/share/opto/type.cpp
#	src/hotspot/share/prims/jvmtiImpl.cpp
#	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java

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

Commit messages:
 - Merge tag 'jdk-16+9' into lworld_merge_jdk_16_9
 - 8248158: Configure fails with autoconf not found even though it's installed
 - 8235573: Move JFR ObjectSample oop into OopStorage
 - 8139875: [TESTBUG] Improve nsk/stress/stack/* tests
 - 8248445: Use of AbsI/AbsL nodes should be limited to supported platforms
 - 8250920: Increase @jls usage in core reflection
 - 8249030: clean up FileInstaller $test.src $cwd in vmTestbase_nsk_jdi tests
 - 8251128: remove vmTestbase/vm/compiler/jbe/combine
 - 8251031: Some vmTestbase/nsk/monitoring/RuntimeMXBean tests fail with hostnames starting from digits
 - 8248906: runtime/Thread/ThreadObjAccessAtExit.java fails due to OutOfMemoryErrors
 - ... and 67 more: https://git.openjdk.java.net/valhalla/compare/f543f733...35629cc1

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

Changes: https://git.openjdk.java.net/valhalla/pull/173/files
  Stats: 7242 lines in 1368 files changed: 3642 ins; 2802 del; 798 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/173.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/173/head:pull/173

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


From dsimms at openjdk.java.net  Wed Sep  2 05:27:54 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Sep 2020 05:27:54 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <pWaZ0Qu9qxuuw-pxT3VLJ2pF3EtQCtyRYfxkL0M_SDw=.659e630f-d49a-42e8-81d4-def23451d9bc@github.com>
References: <pWaZ0Qu9qxuuw-pxT3VLJ2pF3EtQCtyRYfxkL0M_SDw=.659e630f-d49a-42e8-81d4-def23451d9bc@github.com>
Message-ID: <Fwd78Ixm_PQS4ayAGLbMAjT4cLMQcpNZLtHszzvZQ0o=.143d2db5-d454-4661-a7e1-60534d99928a@github.com>

On Wed, 2 Sep 2020 05:08:48 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+9' into lworld_merge_jdk_16_9
> Added tag jdk-16+9 for changeset c075a286cc7d
> 
> # Conflicts:
> #	src/hotspot/share/opto/type.cpp
> #	src/hotspot/share/prims/jvmtiImpl.cpp
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java

This pull request has now been integrated.

Changeset: 31cc75a5
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/31cc75a5
Stats:     7234 lines in 1368 files changed: 2794 ins; 3634 del; 806 mod

Merge jdk

Merge tag 'jdk-16+9'

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

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


From dsimms at openjdk.java.net  Wed Sep  2 12:50:03 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Sep 2020 12:50:03 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <5k1JftutyYBfMUeZfAwtAgBlUl69xBk3bMkmIcG1bMM=.75a850a0-7b02-4ba6-a27d-1b5cd52eec77@github.com>

Merge tag 'jdk-16+10' into lworld_merge_jdk_16_10
Added tag jdk-16+10 for changeset b01985b4f88f

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

Commit messages:
 - Merge tag 'jdk-16+10' into lworld_merge_jdk_16_10
 - 8249273: Documentation of BigInteger(String) constructor does not mention leading plus
 - 8250912: Recording#copy() doesn't copy the flush interval
 - 8251192: Shenandoah: Shenandoah build failed after JDK-8235573
 - 8250660: Clarify that WildcardType and AnnotatedWildcardType bounds methods return one
 - Added tag jdk-16+9 for changeset c075a286cc7d
 - 8251126: nsk.share.GoldChecker should read golden file from ${test.src}
 - 8251132: make main classes public in vmTestbase/jit tests
 - 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF
 - 8250902: Implement MD5 Intrinsics on x86
 - ... and 2 more: https://git.openjdk.java.net/valhalla/compare/31cc75a5...0acf111f

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

Changes: https://git.openjdk.java.net/valhalla/pull/174/files
  Stats: 3782 lines in 1327 files changed: 1333 ins; 615 del; 1834 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/174.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/174/head:pull/174

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


From dsimms at openjdk.java.net  Wed Sep  2 13:15:52 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Sep 2020 13:15:52 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <5k1JftutyYBfMUeZfAwtAgBlUl69xBk3bMkmIcG1bMM=.75a850a0-7b02-4ba6-a27d-1b5cd52eec77@github.com>
References: <5k1JftutyYBfMUeZfAwtAgBlUl69xBk3bMkmIcG1bMM=.75a850a0-7b02-4ba6-a27d-1b5cd52eec77@github.com>
Message-ID: <3AFOby_OEmOpqUP2jJDqKnAkcSi0pzRNRRWwmzNC1Iw=.31f1980b-476f-4dcc-afc1-eb9631c2ac25@github.com>

On Wed, 2 Sep 2020 12:44:34 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+10' into lworld_merge_jdk_16_10
> Added tag jdk-16+10 for changeset b01985b4f88f

This pull request has now been integrated.

Changeset: c5eda14e
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c5eda14e
Stats:     3767 lines in 1327 files changed: 600 ins; 1318 del; 1849 mod

Merge jdk

Merge tag 'jdk-16+10'

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

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


From dsimms at openjdk.java.net  Wed Sep  2 14:07:34 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Sep 2020 14:07:34 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <dNkqtDP92-gmfb3dKi1TDy2JPOVO__wKCMgAzevDQoE=.c6173729-4192-4c38-a90e-b58ca180538d@github.com>

Merge tag 'jdk-16+11' into lworld_merge_jdk_16_11
Added tag jdk-16+11 for changeset 5c18d696c7ce

# Conflicts:
#	src/hotspot/share/opto/live.cpp
#	src/hotspot/share/runtime/synchronizer.cpp

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

Commit messages:
 - Merge tag 'jdk-16+11' into lworld_merge_jdk_16_11
 - 8232621: L10n issues with msi installers
 - 8241053: Hotspot runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test fails on Alpine Linux with debug build
 - 8251336: OopHandle release can not be called in a safepoint
 - 8246707: (sc) SocketChannel.read/write throws AsynchronousCloseException on closed channel
 - 8251451: Shenandoah: Remark ObjectSynchronizer roots with I-U
 - 8251189: com/sun/jndi/ldap/LdapDnsProviderTest.java failed due to timeout
 - 8250772: Test com/sun/jndi/ldap/NamingExceptionMessageTest.java fails intermittently with javax.naming.ServiceUnavailableException
 - 8249603: C1: assert(has_error == false) failed: register allocation invalid
 - 8249276: CDS archived objects must have "neutral" markwords
 - ... and 65 more: https://git.openjdk.java.net/valhalla/compare/c5eda14e...3da2824c

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

Changes: https://git.openjdk.java.net/valhalla/pull/175/files
  Stats: 7833 lines in 268 files changed: 4674 ins; 1026 del; 2133 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/175.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/175/head:pull/175

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


From dsimms at openjdk.java.net  Wed Sep  2 15:22:00 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Sep 2020 15:22:00 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <dNkqtDP92-gmfb3dKi1TDy2JPOVO__wKCMgAzevDQoE=.c6173729-4192-4c38-a90e-b58ca180538d@github.com>
References: <dNkqtDP92-gmfb3dKi1TDy2JPOVO__wKCMgAzevDQoE=.c6173729-4192-4c38-a90e-b58ca180538d@github.com>
Message-ID: <OSN0da09tFNAFIf4gVHcbVbdRXvLG2Zl3wdvzNJL_xI=.f7e404a9-b016-4f02-be82-d801cdadcbd8@github.com>

On Wed, 2 Sep 2020 14:01:32 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+11' into lworld_merge_jdk_16_11
> Added tag jdk-16+11 for changeset 5c18d696c7ce
> 
> # Conflicts:
> #	src/hotspot/share/opto/live.cpp
> #	src/hotspot/share/runtime/synchronizer.cpp

This pull request has now been integrated.

Changeset: e02fecec
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e02fecec
Stats:     7820 lines in 268 files changed: 1013 ins; 4661 del; 2146 mod

Merge jdk

Merge tag 'jdk-16+11'

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

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


From dsimms at openjdk.java.net  Thu Sep  3 09:27:30 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 3 Sep 2020 09:27:30 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <UtiE-PLBKB8MvahVqQkCVNhxwC4vnqGya10mvlmJSyo=.2a65a85c-e1b5-465b-8413-d02583b656d1@github.com>

Merge tag 'jdk-16+12' into lworld_merge_jdk_16_12
Added tag jdk-16+12 for changeset fc8e62b399bd

# Conflicts:
#	src/hotspot/share/memory/dynamicArchive.cpp
#	src/hotspot/share/memory/heapInspection.cpp
#	src/hotspot/share/memory/metaspaceClosure.hpp
#	src/hotspot/share/memory/metaspaceShared.cpp
#	src/hotspot/share/oops/markWord.hpp
#	src/hotspot/share/opto/memnode.cpp

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

Commit messages:
 - Merge tag 'jdk-16+12' into lworld_merge_jdk_16_12
 - 8251499: no-placeholder compact number patterns throw IllegalArgumentException
 - 8251490: [TESTBUG] The Java thread stack size specified is too small for nsk/stress/stack. Specify at least 448k
 - 8251454: Wrong "self type" in DCTree.DCEndElement
 - 8251357: [DocCommentParser] Infinite loop while looking for the end of a preamble
 - 8246047: Replace LinkedList impl in net.http.websocket.BuilderImpl
 - 8251888: Move HotSpot Style Guide wiki subpages to jdk/jdk/doc
 - 8251715: Throw UncheckedIOException in place of InternalError when HttpClient fails due to unavailability of underlying resources required by SSLContext
 - 8250748: Doc of URL(String, String, int, String, URLStreamHandler) does not use link
 - 8249902: tools/javac/records/mandated_members/read_resolve_method/CheckReadResolveMethodTest.java uses @ignore w/o bug-id
 - ... and 77 more: https://git.openjdk.java.net/valhalla/compare/e02fecec...cd46841e

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

Changes: https://git.openjdk.java.net/valhalla/pull/176/files
  Stats: 9849 lines in 338 files changed: 5203 ins; 2240 del; 2406 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/176.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/176/head:pull/176

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


From dsimms at openjdk.java.net  Thu Sep  3 09:27:31 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 3 Sep 2020 09:27:31 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <UtiE-PLBKB8MvahVqQkCVNhxwC4vnqGya10mvlmJSyo=.2a65a85c-e1b5-465b-8413-d02583b656d1@github.com>
References: <UtiE-PLBKB8MvahVqQkCVNhxwC4vnqGya10mvlmJSyo=.2a65a85c-e1b5-465b-8413-d02583b656d1@github.com>
Message-ID: <JGxrDslyWm70muNIPGVA7ZxF9OKZ0oSUkB_Bp3b3q58=.c4260c2a-eec3-4234-9dd0-c7173f0ff659@github.com>

On Thu, 3 Sep 2020 09:18:17 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+12' into lworld_merge_jdk_16_12
> Added tag jdk-16+12 for changeset fc8e62b399bd
> 
> # Conflicts:
> #	src/hotspot/share/memory/dynamicArchive.cpp
> #	src/hotspot/share/memory/heapInspection.cpp
> #	src/hotspot/share/memory/metaspaceClosure.hpp
> #	src/hotspot/share/memory/metaspaceShared.cpp
> #	src/hotspot/share/oops/markWord.hpp
> #	src/hotspot/share/opto/memnode.cpp

This pull request has now been integrated.

Changeset: 321ea1de
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/321ea1de
Stats:     9834 lines in 338 files changed: 2225 ins; 5188 del; 2421 mod

Merge jdk

Merge tag 'jdk-16+12'

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

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


From dsimms at openjdk.java.net  Thu Sep  3 14:05:45 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 3 Sep 2020 14:05:45 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <7diXOJhKN8gKD_9tyEVtUzAvCqM2syI0l-EFxF8n4L0=.711c2ef8-b6c2-4c31-811f-59c54f697203@github.com>

Merge tag 'jdk-16+13' into lworld_merge_jdk_16_13
Added tag jdk-16+13 for changeset fd07cdb26fc7

# Conflicts:
#	src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
#	src/hotspot/share/oops/instanceKlass.cpp
#	src/hotspot/share/oops/klass.hpp
#	src/hotspot/share/oops/markWord.hpp
#	src/hotspot/share/runtime/synchronizer.cpp

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

Commit messages:
 - Merge tag 'jdk-16+13' into lworld_merge_jdk_16_13
 - 8230918: j.l.NASE in javap
 - 8251093: Improve C1 register allocator logging and debugging support
 - 8252037: Optimized build is broken
 - 8244386: convert runtime/Safepoint/AssertSafepointCheckConsistency tests to gtest
 - 8250598: Hyper-V is detected in spite of running on host OS
 - 8252259: AArch64: Adjust default value of FLOATPRESSURE
 - 8252108: Modify nsk/stress/stack tests to check page size
 - 8252291: C2: Assignment in conditional in loopUnswitch.cpp
 - 8252290: Remove unused enum in CallGenerator
 - ... and 54 more: https://git.openjdk.java.net/valhalla/compare/321ea1de...19ce6a83

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

Changes: https://git.openjdk.java.net/valhalla/pull/177/files
  Stats: 8271 lines in 437 files changed: 6313 ins; 1371 del; 587 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/177.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/177/head:pull/177

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


From dsimms at openjdk.java.net  Thu Sep  3 14:15:07 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 3 Sep 2020 14:15:07 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <7diXOJhKN8gKD_9tyEVtUzAvCqM2syI0l-EFxF8n4L0=.711c2ef8-b6c2-4c31-811f-59c54f697203@github.com>
References: <7diXOJhKN8gKD_9tyEVtUzAvCqM2syI0l-EFxF8n4L0=.711c2ef8-b6c2-4c31-811f-59c54f697203@github.com>
Message-ID: <xthi7Z5TjPKwrYsV7WE0rJuM0u9PW-K8dKlzTvsKPL0=.31c7443c-1a97-41c4-981c-c0c87d05f3cc@github.com>

On Thu, 3 Sep 2020 13:59:15 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+13' into lworld_merge_jdk_16_13
> Added tag jdk-16+13 for changeset fd07cdb26fc7
> 
> # Conflicts:
> #	src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
> #	src/hotspot/share/oops/instanceKlass.cpp
> #	src/hotspot/share/oops/klass.hpp
> #	src/hotspot/share/oops/markWord.hpp
> #	src/hotspot/share/runtime/synchronizer.cpp

This pull request has now been integrated.

Changeset: 40f85683
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/40f85683
Stats:     8289 lines in 437 files changed: 1389 ins; 6331 del; 569 mod

Merge jdk

Merge tag 'jdk-16+13'

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

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


From thartmann at openjdk.java.net  Fri Sep  4 10:08:13 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 4 Sep 2020 10:08:13 GMT
Subject: [lworld] RFR: 8252506: [lworld] Multiple issues with C2's arraycopy
 intrinsic
Message-ID: <PMshE_4djgrY-6fYrZ4pAm6JM-6OwdrrkVnaT2E3WXU=.e27897ef-6a80-4a7f-93a6-806c8e0d21dd@github.com>

This patch fixes multiple issues in C2's arraycopy/copyof/clone intrinsics:
- Flat inline type arrays containing oops might be copied without GC barriers.
- Missing membarrier in copyOf code at macro expansion
- We can often avoid flat/null-free checks by relying on the src <: dst subtype check
- We often know at parse time that a flat array does not contain oops and should make use of that information
- And more.. Hopefully the comments in the code are self-explanatory

Other changes:
- generic_arraycopy stub needs to handle flat/null-free inline type arrays
  - Bail if src is flat or dst is flat/null-free
  - Primitive array verification code is broken because array tag contains more bits
  - The "Load layout helper" comment needs adjustment as well but I'll wait with that until we've moved bits to the mark
    word
- C1 arraycopy intrinsic does not need to check arguments to generic_arraycopy stub (moved checks below)
- Added asserts and runtime verification code to catch issues earlier
- Added lots of test for all issues I've found and new IR matching rules to verify that all arraycopy optimizations work
  as expected
- Some refactoring

I've identified some remaining optimization opportunities and marked them with "TODO 8251971" in code and tests.

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

Commit messages:
 - 8252506: [lworld] Multiple issues with C2's arraycopy intrinsic

Changes: https://git.openjdk.java.net/valhalla/pull/178/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=178&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252506
  Stats: 1052 lines in 11 files changed: 904 ins; 86 del; 62 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/178.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/178/head:pull/178

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


From iklam at openjdk.java.net  Sun Sep  6 06:02:24 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sun, 6 Sep 2020 06:02:24 GMT
Subject: [lworld] RFR: 8252753: [lworld] Merge of jdk-16+12 broke CDS for
 inline types
Message-ID: <qrkhhqvo6tBBE-l1mV6hqq4dPTxj2_J5_NVYFUklELA=.0dc82314-778f-405d-a966-22665c7a2016@github.com>

This fixes handling of inline types by CDS -- implemented handling of MetaspaceClosure::_internal_pointer_ref

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

Commit messages:
 - 8252753: [lworld] Merge of jdk-16+12 broke CDS for inline types

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

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


From dsimms at openjdk.java.net  Sun Sep  6 06:33:20 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Sun, 6 Sep 2020 06:33:20 GMT
Subject: [lworld] RFR: 8252753: [lworld] Merge of jdk-16+12 broke CDS for
 inline types
In-Reply-To: <qrkhhqvo6tBBE-l1mV6hqq4dPTxj2_J5_NVYFUklELA=.0dc82314-778f-405d-a966-22665c7a2016@github.com>
References: <qrkhhqvo6tBBE-l1mV6hqq4dPTxj2_J5_NVYFUklELA=.0dc82314-778f-405d-a966-22665c7a2016@github.com>
Message-ID: <EyW-8tlLTuOiRTsMyTVqlO6gfMngiJbROHe-NkntLDM=.4779465e-25cb-46a3-84be-23553bea8118@github.com>

On Sun, 6 Sep 2020 05:56:26 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This fixes handling of inline types by CDS -- implemented handling of MetaspaceClosure::_internal_pointer_ref

Looks good, assume the commented tty print lines will either disappear later or be debug log ?

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

Marked as reviewed by dsimms (Committer).

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


From iklam at openjdk.java.net  Sun Sep  6 06:44:30 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sun, 6 Sep 2020 06:44:30 GMT
Subject: [lworld] RFR: 8252753: [lworld] Merge of jdk-16+12 broke CDS for
 inline types [v2]
In-Reply-To: <EyW-8tlLTuOiRTsMyTVqlO6gfMngiJbROHe-NkntLDM=.4779465e-25cb-46a3-84be-23553bea8118@github.com>
References: <qrkhhqvo6tBBE-l1mV6hqq4dPTxj2_J5_NVYFUklELA=.0dc82314-778f-405d-a966-22665c7a2016@github.com>
 <EyW-8tlLTuOiRTsMyTVqlO6gfMngiJbROHe-NkntLDM=.4779465e-25cb-46a3-84be-23553bea8118@github.com>
Message-ID: <kjEzJBc48BDjzTzTd2y9d1XoUE0ay8YFX9MqWSULIzs=.7b9bdae4-895e-4a90-b2ab-fe1ee2da4bf2@github.com>

On Sun, 6 Sep 2020 06:30:52 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Ioi Lam has refreshed the contents of this pull request, and previous commits have been removed. The incremental views
>> will show differences compared to the previous content of the PR. The pull request contains one new commit since the
>> last revision:
>>   8252753: [lworld] Merge of jdk-16+12 broke CDS for inline types
>
> Looks good, assume the commented tty print lines will either disappear later or be debug log ?

Oops, I amended the commit and removed the print_cr.

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

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


From iklam at openjdk.java.net  Sun Sep  6 06:44:28 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sun, 6 Sep 2020 06:44:28 GMT
Subject: [lworld] RFR: 8252753: [lworld] Merge of jdk-16+12 broke CDS for
 inline types [v2]
In-Reply-To: <qrkhhqvo6tBBE-l1mV6hqq4dPTxj2_J5_NVYFUklELA=.0dc82314-778f-405d-a966-22665c7a2016@github.com>
References: <qrkhhqvo6tBBE-l1mV6hqq4dPTxj2_J5_NVYFUklELA=.0dc82314-778f-405d-a966-22665c7a2016@github.com>
Message-ID: <YEjuySckEtm1qS_gNQQ_1A8U3AGy1wRf4KY9KpOwR3o=.8052bd17-92be-435f-9a9d-6ff8332057d7@github.com>

> This fixes handling of inline types by CDS -- implemented handling of MetaspaceClosure::_internal_pointer_ref

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

  8252753: [lworld] Merge of jdk-16+12 broke CDS for inline types

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/179/files
  - new: https://git.openjdk.java.net/valhalla/pull/179/files/3405b212..f1eda0ad

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

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

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


From iklam at openjdk.java.net  Sun Sep  6 17:08:30 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sun, 6 Sep 2020 17:08:30 GMT
Subject: [lworld] Integrated: 8252753: [lworld] Merge of jdk-16+12 broke CDS
 for inline types
In-Reply-To: <qrkhhqvo6tBBE-l1mV6hqq4dPTxj2_J5_NVYFUklELA=.0dc82314-778f-405d-a966-22665c7a2016@github.com>
References: <qrkhhqvo6tBBE-l1mV6hqq4dPTxj2_J5_NVYFUklELA=.0dc82314-778f-405d-a966-22665c7a2016@github.com>
Message-ID: <ihEXdfwru12UjlljwiAuRuQCjPdEIItVe9YcZHPS5lA=.5115514b-c954-4512-bbd7-5a601fad5ec8@github.com>

On Sun, 6 Sep 2020 05:56:26 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This fixes handling of inline types by CDS -- implemented handling of MetaspaceClosure::_internal_pointer_ref

This pull request has now been integrated.

Changeset: 9616df99
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/9616df99
Stats:     35 lines in 2 files changed: 6 ins; 24 del; 5 mod

8252753: [lworld] Merge of jdk-16+12 broke CDS for inline types

implemented handling of MetaspaceClosure::_internal_pointer_ref

Reviewed-by: dsimms

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

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


From thartmann at openjdk.java.net  Mon Sep  7 09:07:33 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 7 Sep 2020 09:07:33 GMT
Subject: [lworld] RFR: 8252854: [lworld] Buffering in C1 entry can trigger
 safepoint before nmethod entry barrier has been executed
Message-ID: <pTf8Vsp9Ef3i3YYUVVRT08NIkREzkc_C79IsGPsCilQ=.f6280404-9fae-4b0a-ac28-084147e2f00f@github.com>

The runtime call to buffer scalarized inline type arguments in the C1 entry points can safepoint before the entry
barrier of the corresponding nmethod has been executed. As a result, oops in the nmethod might be bad and the GC
crashes in 'nmethod_oops_do'. We should simply execute the entry barrier before calling into the runtime.

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

Commit messages:
 - 8252854: [lworld] Buffering in C1 entry can trigger safepoint before nmethod entry barrier has been executed

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

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


From thartmann at openjdk.java.net  Mon Sep  7 09:08:32 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 7 Sep 2020 09:08:32 GMT
Subject: [lworld] RFR: 8252506: [lworld] Multiple issues with C2's
 arraycopy intrinsic [v2]
In-Reply-To: <PMshE_4djgrY-6fYrZ4pAm6JM-6OwdrrkVnaT2E3WXU=.e27897ef-6a80-4a7f-93a6-806c8e0d21dd@github.com>
References: <PMshE_4djgrY-6fYrZ4pAm6JM-6OwdrrkVnaT2E3WXU=.e27897ef-6a80-4a7f-93a6-806c8e0d21dd@github.com>
Message-ID: <Xhn-IjAeA5uKC0yor2LHWS2n7xPeY1mAofPAflPl7bs=.258cb92c-6b17-47cb-8db4-4b736baa6e6f@github.com>

> This patch fixes multiple issues in C2's arraycopy/copyof/clone intrinsics:
> - Flat inline type arrays containing oops might be copied without GC barriers.
> - Missing membarrier in copyOf code at macro expansion
> - We can often avoid flat/null-free checks by relying on the src <: dst subtype check
> - We often know at parse time that a flat array does not contain oops and should make use of that information
> - And more.. Hopefully the comments in the code are self-explanatory
> 
> Other changes:
> - generic_arraycopy stub needs to handle flat/null-free inline type arrays
>   - Bail if src is flat or dst is flat/null-free
>   - Primitive array verification code is broken because array tag contains more bits
>   - The "Load layout helper" comment needs adjustment as well but I'll wait with that until we've moved bits to the mark
>     word
> - C1 arraycopy intrinsic does not need to check arguments to generic_arraycopy stub (moved checks below)
> - Added asserts and runtime verification code to catch issues earlier
> - Added lots of test for all issues I've found and new IR matching rules to verify that all arraycopy optimizations work
>   as expected
> - Some refactoring
> 
> I've identified some remaining optimization opportunities and marked them with "TODO 8251971" in code and tests.

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 two additional commits since
the last revision:

 - Merge branch 'lworld' into JDK-8252506
 - 8252506: [lworld] Multiple issues with C2's arraycopy intrinsic

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/178/files
  - new: https://git.openjdk.java.net/valhalla/pull/178/files/20ed4d33..9ac5e92c

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

  Stats: 35 lines in 2 files changed: 24 ins; 6 del; 5 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/178.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/178/head:pull/178

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


From thartmann at openjdk.java.net  Mon Sep  7 10:00:35 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 7 Sep 2020 10:00:35 GMT
Subject: [lworld] RFR: 8252506: [lworld] Multiple issues with C2's
 arraycopy intrinsic [v3]
In-Reply-To: <PMshE_4djgrY-6fYrZ4pAm6JM-6OwdrrkVnaT2E3WXU=.e27897ef-6a80-4a7f-93a6-806c8e0d21dd@github.com>
References: <PMshE_4djgrY-6fYrZ4pAm6JM-6OwdrrkVnaT2E3WXU=.e27897ef-6a80-4a7f-93a6-806c8e0d21dd@github.com>
Message-ID: <Nw_BJwDvI7a27Fa4AmRGKr1FObsOUVv5lwR89U2-no0=.a702dac2-4b40-427d-84a3-25600a734a96@github.com>

> This patch fixes multiple issues in C2's arraycopy/copyof/clone intrinsics:
> - Flat inline type arrays containing oops might be copied without GC barriers.
> - Missing membarrier in copyOf code at macro expansion
> - We can often avoid flat/null-free checks by relying on the src <: dst subtype check
> - We often know at parse time that a flat array does not contain oops and should make use of that information
> - And more.. Hopefully the comments in the code are self-explanatory
> 
> Other changes:
> - generic_arraycopy stub needs to handle flat/null-free inline type arrays
>   - Bail if src is flat or dst is flat/null-free
>   - Primitive array verification code is broken because array tag contains more bits
>   - The "Load layout helper" comment needs adjustment as well but I'll wait with that until we've moved bits to the mark
>     word
> - C1 arraycopy intrinsic does not need to check arguments to generic_arraycopy stub (moved checks below)
> - Added asserts and runtime verification code to catch issues earlier
> - Added lots of test for all issues I've found and new IR matching rules to verify that all arraycopy optimizations work
>   as expected
> - Some refactoring
> 
> I've identified some remaining optimization opportunities and marked them with "TODO 8251971" in code and tests.

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

  Fixed bug in generate_generic_copy stub: Non-array src is not detected

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/178/files
  - new: https://git.openjdk.java.net/valhalla/pull/178/files/9ac5e92c..d72baa76

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

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

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


From thartmann at openjdk.java.net  Mon Sep  7 11:20:08 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 7 Sep 2020 11:20:08 GMT
Subject: [lworld] Integrated: 8252854: [lworld] Buffering in C1 entry can
 trigger safepoint before nmethod entry barrier has been executed
In-Reply-To: <pTf8Vsp9Ef3i3YYUVVRT08NIkREzkc_C79IsGPsCilQ=.f6280404-9fae-4b0a-ac28-084147e2f00f@github.com>
References: <pTf8Vsp9Ef3i3YYUVVRT08NIkREzkc_C79IsGPsCilQ=.f6280404-9fae-4b0a-ac28-084147e2f00f@github.com>
Message-ID: <wFzSRVQI7--0HE0FdIF6S6jQtE2vaYvDza8X4KAupZo=.e8134d55-98bf-4861-a2c4-25bb26f5c446@github.com>

On Mon, 7 Sep 2020 09:01:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The runtime call to buffer scalarized inline type arguments in the C1 entry points can safepoint before the entry
> barrier of the corresponding nmethod has been executed. As a result, oops in the nmethod might be bad and the GC
> crashes in 'nmethod_oops_do'. We should simply execute the entry barrier before calling into the runtime.

This pull request has now been integrated.

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

8252854: [lworld] Buffering in C1 entry can trigger safepoint before nmethod entry barrier has been executed

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

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


From thartmann at openjdk.java.net  Mon Sep  7 12:31:52 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 7 Sep 2020 12:31:52 GMT
Subject: [lworld] Integrated: 8252862: [lworld] Accidentally disabled fix for
 JDK-8252110
Message-ID: <HjJWd2i0AfDiik6jWf2h4sDcObVz7JJ9E4RdekC9tIU=.9b9e352b-d2b3-4aa4-b593-2cf98044f648@github.com>

Removed "if (false)".

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

Commit messages:
 - 8252862: [lworld] Accidentally disabled fix for JDK-8252110

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

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


From thartmann at openjdk.java.net  Mon Sep  7 12:31:53 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 7 Sep 2020 12:31:53 GMT
Subject: [lworld] Integrated: 8252862: [lworld] Accidentally disabled fix for
 JDK-8252110
In-Reply-To: <HjJWd2i0AfDiik6jWf2h4sDcObVz7JJ9E4RdekC9tIU=.9b9e352b-d2b3-4aa4-b593-2cf98044f648@github.com>
References: <HjJWd2i0AfDiik6jWf2h4sDcObVz7JJ9E4RdekC9tIU=.9b9e352b-d2b3-4aa4-b593-2cf98044f648@github.com>
Message-ID: <e8wm5P5N5jgbt6Gu3cz1jpNYcxwRXZ4OLENlOFYqLvo=.3891fc9f-c38c-45cb-bb2c-e114734ebdd8@github.com>

On Mon, 7 Sep 2020 12:25:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Removed "if (false)".

This pull request has now been integrated.

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

8252862: [lworld] Accidentally disabled fix for JDK-8252110

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

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


From thartmann at openjdk.java.net  Mon Sep  7 14:17:04 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 7 Sep 2020 14:17:04 GMT
Subject: [lworld] RFR: 8252506: [lworld] Multiple issues with C2's
 arraycopy intrinsic [v4]
In-Reply-To: <PMshE_4djgrY-6fYrZ4pAm6JM-6OwdrrkVnaT2E3WXU=.e27897ef-6a80-4a7f-93a6-806c8e0d21dd@github.com>
References: <PMshE_4djgrY-6fYrZ4pAm6JM-6OwdrrkVnaT2E3WXU=.e27897ef-6a80-4a7f-93a6-806c8e0d21dd@github.com>
Message-ID: <TDDQ47RufknR-GppAXt2HzCx4B0e7410S9DtFeBbmHc=.9d497c00-1cdd-42b5-83e1-318eaf7c23ac@github.com>

> This patch fixes multiple issues in C2's arraycopy/copyof/clone intrinsics:
> - Flat inline type arrays containing oops might be copied without GC barriers.
> - Missing membarrier in copyOf code at macro expansion
> - We can often avoid flat/null-free checks by relying on the src <: dst subtype check
> - We often know at parse time that a flat array does not contain oops and should make use of that information
> - And more.. Hopefully the comments in the code are self-explanatory
> 
> Other changes:
> - generic_arraycopy stub needs to handle flat/null-free inline type arrays
>   - Bail if src is flat or dst is flat/null-free
>   - Primitive array verification code is broken because array tag contains more bits
>   - The "Load layout helper" comment needs adjustment as well but I'll wait with that until we've moved bits to the mark
>     word
> - C1 arraycopy intrinsic does not need to check arguments to generic_arraycopy stub (moved checks below)
> - Added asserts and runtime verification code to catch issues earlier
> - Added lots of test for all issues I've found and new IR matching rules to verify that all arraycopy optimizations work
>   as expected
> - Some refactoring
> 
> I've identified some remaining optimization opportunities and marked them with "TODO 8251971" in code and tests.

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 four additional commits since
the last revision:

 - Merge branch 'lworld' into JDK-8252506
 - Fixed bug in generate_generic_copy stub: Non-array src is not detected
 - Merge branch 'lworld' into JDK-8252506
 - 8252506: [lworld] Multiple issues with C2's arraycopy intrinsic

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/178/files
  - new: https://git.openjdk.java.net/valhalla/pull/178/files/d72baa76..361770b9

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

  Stats: 10 lines in 2 files changed: 7 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/178.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/178/head:pull/178

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


From rwestrel at redhat.com  Tue Sep  8 07:44:24 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 08 Sep 2020 09:44:24 +0200
Subject: [lworld] RFR: 8252506: [lworld] Multiple issues with C2's
 arraycopy intrinsic [v4]
In-Reply-To: <TDDQ47RufknR-GppAXt2HzCx4B0e7410S9DtFeBbmHc=.9d497c00-1cdd-42b5-83e1-318eaf7c23ac@github.com>
References: <PMshE_4djgrY-6fYrZ4pAm6JM-6OwdrrkVnaT2E3WXU=.e27897ef-6a80-4a7f-93a6-806c8e0d21dd@github.com>
 <TDDQ47RufknR-GppAXt2HzCx4B0e7410S9DtFeBbmHc=.9d497c00-1cdd-42b5-83e1-318eaf7c23ac@github.com>
Message-ID: <87imcolnl3.fsf@redhat.com>


That looks good to me.

Roland.



From thartmann at openjdk.java.net  Tue Sep  8 07:52:49 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Sep 2020 07:52:49 GMT
Subject: [lworld] RFR: 8252506: [lworld] Multiple issues with C2's
 arraycopy intrinsic
In-Reply-To: <PMshE_4djgrY-6fYrZ4pAm6JM-6OwdrrkVnaT2E3WXU=.e27897ef-6a80-4a7f-93a6-806c8e0d21dd@github.com>
References: <PMshE_4djgrY-6fYrZ4pAm6JM-6OwdrrkVnaT2E3WXU=.e27897ef-6a80-4a7f-93a6-806c8e0d21dd@github.com>
Message-ID: <Xe1S5FtCEwMYbE095PPHxMIXWN06LUHwkiRTTWzr9xg=.209353eb-440d-4965-9d81-4f01f5a91f53@github.com>

On Fri, 4 Sep 2020 10:02:41 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This patch fixes multiple issues in C2's arraycopy/copyof/clone intrinsics:
> - Flat inline type arrays containing oops might be copied without GC barriers.
> - Missing membarrier in copyOf code at macro expansion
> - We can often avoid flat/null-free checks by relying on the src <: dst subtype check
> - We often know at parse time that a flat array does not contain oops and should make use of that information
> - And more.. Hopefully the comments in the code are self-explanatory
> 
> Other changes:
> - generic_arraycopy stub needs to handle flat/null-free inline type arrays
>   - Bail if src is flat or dst is flat/null-free
>   - Primitive array verification code is broken because array tag contains more bits
>   - The "Load layout helper" comment needs adjustment as well but I'll wait with that until we've moved bits to the mark
>     word
> - C1 arraycopy intrinsic does not need to check arguments to generic_arraycopy stub (moved checks below)
> - Added asserts and runtime verification code to catch issues earlier
> - Added lots of test for all issues I've found and new IR matching rules to verify that all arraycopy optimizations work
>   as expected
> - Some refactoring
> 
> I've identified some remaining optimization opportunities and marked them with "TODO 8251971" in code and tests.

Thanks Roland!

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

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


From thartmann at openjdk.java.net  Tue Sep  8 12:23:59 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Sep 2020 12:23:59 GMT
Subject: [lworld] Integrated: 8252506: [lworld] Multiple issues with C2's
 arraycopy intrinsic
In-Reply-To: <PMshE_4djgrY-6fYrZ4pAm6JM-6OwdrrkVnaT2E3WXU=.e27897ef-6a80-4a7f-93a6-806c8e0d21dd@github.com>
References: <PMshE_4djgrY-6fYrZ4pAm6JM-6OwdrrkVnaT2E3WXU=.e27897ef-6a80-4a7f-93a6-806c8e0d21dd@github.com>
Message-ID: <sDsVhRrIfRIGCexh5V7vhcw3z4v5w3MUYY1mzJ3B9OQ=.9aae8fe2-28cc-4619-bd88-28b747db798d@github.com>

On Fri, 4 Sep 2020 10:02:41 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This patch fixes multiple issues in C2's arraycopy/copyof/clone intrinsics:
> - Flat inline type arrays containing oops might be copied without GC barriers.
> - Missing membarrier in copyOf code at macro expansion
> - We can often avoid flat/null-free checks by relying on the src <: dst subtype check
> - We often know at parse time that a flat array does not contain oops and should make use of that information
> - And more.. Hopefully the comments in the code are self-explanatory
> 
> Other changes:
> - generic_arraycopy stub needs to handle flat/null-free inline type arrays
>   - Bail if src is flat or dst is flat/null-free
>   - Primitive array verification code is broken because array tag contains more bits
>   - The "Load layout helper" comment needs adjustment as well but I'll wait with that until we've moved bits to the mark
>     word
> - C1 arraycopy intrinsic does not need to check arguments to generic_arraycopy stub (moved checks below)
> - Added asserts and runtime verification code to catch issues earlier
> - Added lots of test for all issues I've found and new IR matching rules to verify that all arraycopy optimizations work
>   as expected
> - Some refactoring
> 
> I've identified some remaining optimization opportunities and marked them with "TODO 8251971" in code and tests.

This pull request has now been integrated.

Changeset: 31412b9f
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/31412b9f
Stats:     1076 lines in 11 files changed: 86 ins; 930 del; 60 mod

8252506: [lworld] Multiple issues with C2's arraycopy intrinsic

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

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


From dsimms at openjdk.java.net  Wed Sep  9 09:06:12 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 9 Sep 2020 09:06:12 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <LKQvT31d-Gz7wfX9ta_ud2Ha6-wCFMdMcqGA-awea2M=.349ca381-10c4-411d-a9c8-0d21bad14355@github.com>

Merge tag 'jdk-16+14' into lworld_merge_jdk_16_14
Added tag jdk-16+14 for changeset 36b29df125dc

# Conflicts:
#	src/hotspot/share/memory/heapInspection.cpp
#	src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java

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

Commit messages:
 - Merge tag 'jdk-16+14' into lworld_merge_jdk_16_14
 - 8252303: G1MMUTrackerQueue::when_sec skip queue iteration on max_gc_time pause time
 - 8252093: formula used to calculate decaying variance in numberSeq
 - 8252035: G1: Clean up G1CollectedHeap::*reserved* methods
 - 8252231: G1AdaptiveIHOP has swapped current_occupancy and additional_buffer_size
 - 8252691: Build failure after JDK-8252481
 - Merge
 - 8251274: Provide utilities for function SFINAE using extra template parameters
 - 8252402: rewrite vmTestbase/nsk/jvmti/Allocate/alloc001 shell test to Java
 - 8252532: use Utils.TEST_NATIVE_PATH instead of System.getProperty("test.nativepath")
 - ... and 130 more: https://git.openjdk.java.net/valhalla/compare/31412b9f...88870b81

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

Changes: https://git.openjdk.java.net/valhalla/pull/182/files
  Stats: 16642 lines in 938 files changed: 10249 ins; 3403 del; 2990 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/182.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/182/head:pull/182

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


From dsimms at openjdk.java.net  Wed Sep  9 09:09:11 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 9 Sep 2020 09:09:11 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <LKQvT31d-Gz7wfX9ta_ud2Ha6-wCFMdMcqGA-awea2M=.349ca381-10c4-411d-a9c8-0d21bad14355@github.com>
References: <LKQvT31d-Gz7wfX9ta_ud2Ha6-wCFMdMcqGA-awea2M=.349ca381-10c4-411d-a9c8-0d21bad14355@github.com>
Message-ID: <OtYOq51tevslcqcV_v7OKu8e0ncMtgM1Zngz0ukxRRE=.5dbd66bf-9992-44f7-829b-6d83d7bc2c89@github.com>

On Wed, 9 Sep 2020 08:58:04 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+14' into lworld_merge_jdk_16_14
> Added tag jdk-16+14 for changeset 36b29df125dc
> 
> # Conflicts:
> #	src/hotspot/share/memory/heapInspection.cpp
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java

This pull request has now been integrated.

Changeset: 803d0d34
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/803d0d34
Stats:     16625 lines in 938 files changed: 3386 ins; 10232 del; 3007 mod

Merge jdk

Merge tag 'jdk-16+14'

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

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


From dsimms at openjdk.java.net  Thu Sep 10 11:22:42 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 10 Sep 2020 11:22:42 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <ARjupcbKAaSw-DsNB-Lv5Cjtzt4CQphgHkiWPtMxJf8=.8f1924d7-8b63-474e-82da-fe943b444bf6@github.com>

Merge tag 'jdk-16+15'

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

Commit messages:
 - Merge message
 - Merge tag 'jdk-16+15' into lworld_merge_jdk_16_15
 - 8250217: com.sun.tools.javac.api.JavacTaskImpl swallows compiler exceptions potentially producing false positive test results
 - 8252957: Wrong comment in CgroupV1Subsystem::cpu_quota
 - 8248532: Every time I change keyboard language at my MacBook, Java crashes
 - 8252794: Creation of JNIMethodBlock should be done with a leaf lock
 - 8235229: Compilation against a modular, multi-release JAR erroneous with --release
 - 8240751: Shenandoah: fold ShenandoahTracer definition
 - 8250840: some tests use --enable-preview unnecessarily
 - 8252916: Newline in object field values list of ScopeDesc should be removed
 - ... and 57 more: https://git.openjdk.java.net/valhalla/compare/803d0d34...183f1cc7

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

Changes: https://git.openjdk.java.net/valhalla/pull/183/files
  Stats: 9216 lines in 362 files changed: 7086 ins; 885 del; 1245 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/183.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/183/head:pull/183

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


From thartmann at openjdk.java.net  Thu Sep 10 11:28:51 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 10 Sep 2020 11:28:51 GMT
Subject: [lworld] RFR: 8253006: [lworld] Incorrect debug information for
 fields of scalarized flat array
Message-ID: <yziOxv6sVf7dtJz9lBK0VcWy6UBodSYqVpQeX9N_WDg=.c54c2ae8-fc7c-400c-80db-d1e5de0e1112@github.com>

Loads from a scalarized, flat array generated by PhaseMacroExpand::make_arraycopy_load use a wrong offset because the
shift value is not adjusted to the inline klass element size. Not sure how this slipped through testing that long but
existing tests catch it when increasing the number of warmup iterations.

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

Commit messages:
 - 8253006: [lworld] Incorrect debug information for fields of scalarized flat array

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

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


From dsimms at openjdk.java.net  Thu Sep 10 11:53:41 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 10 Sep 2020 11:53:41 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <ARjupcbKAaSw-DsNB-Lv5Cjtzt4CQphgHkiWPtMxJf8=.8f1924d7-8b63-474e-82da-fe943b444bf6@github.com>
References: <ARjupcbKAaSw-DsNB-Lv5Cjtzt4CQphgHkiWPtMxJf8=.8f1924d7-8b63-474e-82da-fe943b444bf6@github.com>
Message-ID: <2WvibyCBVuHDnUUCSk_EBuZtJdoOM2ueoj3lo0KoXeI=.aa616d2d-0a44-4b7f-9289-7dbc226c026a@github.com>

> Merge tag 'jdk-16+15'

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

 - Merge message
 - Merge tag 'jdk-16+15' into lworld_merge_jdk_16_15
   
   Added tag jdk-16+15 for changeset 4333942
   
   # Conflicts:
   #	.jcheck/conf
   #	src/hotspot/share/opto/matcher.cpp
   #	src/hotspot/share/opto/type.cpp
   #	src/hotspot/share/prims/methodHandles.cpp
   #	src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
 - Merge jdk
   
   Merge tag 'jdk-16+14'
 - 8252506: [lworld] Multiple issues with C2's arraycopy intrinsic
 - 8252862: [lworld] Accidentally disabled fix for JDK-8252110
 - 8252854: [lworld] Buffering in C1 entry can trigger safepoint before nmethod entry barrier has been executed
 - 8252753: [lworld] Merge of jdk-16+12 broke CDS for inline types
   
   implemented handling of MetaspaceClosure::_internal_pointer_ref
   
   Reviewed-by: dsimms
 - Merge jdk
   
   Merge tag 'jdk-16+13'
 - Merge jdk
   
   Merge tag 'jdk-16+12'
 - Merge jdk
   
   Merge tag 'jdk-16+11'
 - ... and 974 more: https://git.openjdk.java.net/valhalla/compare/43339420...183f1cc7

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

Changes: https://git.openjdk.java.net/valhalla/pull/183/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=183&range=01
  Stats: 122354 lines in 1232 files changed: 116824 ins; 1315 del; 4215 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/183.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/183/head:pull/183

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


From dsimms at openjdk.java.net  Thu Sep 10 11:53:42 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 10 Sep 2020 11:53:42 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <ARjupcbKAaSw-DsNB-Lv5Cjtzt4CQphgHkiWPtMxJf8=.8f1924d7-8b63-474e-82da-fe943b444bf6@github.com>
References: <ARjupcbKAaSw-DsNB-Lv5Cjtzt4CQphgHkiWPtMxJf8=.8f1924d7-8b63-474e-82da-fe943b444bf6@github.com>
Message-ID: <zeg4Dk5NwMc2AojsH_MKD7XPrpYv7r-e0i0dmR1AikY=.fe46ba6f-8095-4ede-baaf-89c2ec39887c@github.com>

On Thu, 10 Sep 2020 08:58:26 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+15'

This pull request has now been integrated.

Changeset: 819efc10
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/819efc10
Stats:     9215 lines in 362 files changed: 884 ins; 7085 del; 1246 mod

Merge jdk

Merge tag 'jdk-16+15'

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

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


From thartmann at openjdk.java.net  Thu Sep 10 14:37:33 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 10 Sep 2020 14:37:33 GMT
Subject: [lworld] Integrated: 8253006: [lworld] Incorrect debug information
 for fields of scalarized flat array
In-Reply-To: <yziOxv6sVf7dtJz9lBK0VcWy6UBodSYqVpQeX9N_WDg=.c54c2ae8-fc7c-400c-80db-d1e5de0e1112@github.com>
References: <yziOxv6sVf7dtJz9lBK0VcWy6UBodSYqVpQeX9N_WDg=.c54c2ae8-fc7c-400c-80db-d1e5de0e1112@github.com>
Message-ID: <Krjqa_PX-dOaNNN1c0DqBb0U-YXLaPosiOHTHgZkdvE=.5882669e-c9eb-4899-9055-2c4bee2098d6@github.com>

On Thu, 10 Sep 2020 11:23:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Loads from a scalarized, flat array generated by PhaseMacroExpand::make_arraycopy_load use a wrong offset because the
> shift value is not adjusted to the inline klass element size. Not sure how this slipped through testing that long but
> existing tests catch it when increasing the number of warmup iterations.

This pull request has now been integrated.

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

8253006: [lworld] Incorrect debug information for fields of scalarized flat array

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

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


From thartmann at openjdk.java.net  Fri Sep 11 10:27:48 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 11 Sep 2020 10:27:48 GMT
Subject: [lworld] RFR: 8253047: [lworld] C2 compilation fails with
 guarantee(sect->end() <= sect->limit()) failed: sanity
Message-ID: <TCm_eA8Z7c47ejGQJtlz6rjqIOigL8PdzPPjQvIw8Ow=.c4426794-4753-4a83-9a63-addf7dc78c60@github.com>

We run out of space in C2's scratch buffer when calculating the size of the MachVEPNode because the inline type entry
point requires lots of space for the ZGC barriers when the inline type argument contains many object fields.

The fix is to increase the scratch emit buffer size based on the number of oop fields of scalarized inline type
arguments.

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

Commit messages:
 - 8253047: [lworld] C2 compilation fails with guarantee(sect->end() <= sect->limit()) failed: sanity

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

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


From thartmann at openjdk.java.net  Fri Sep 11 12:08:51 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 11 Sep 2020 12:08:51 GMT
Subject: [lworld] Integrated: 8253047: [lworld] C2 compilation fails with
 guarantee(sect->end() <= sect->limit()) failed: sanity
In-Reply-To: <TCm_eA8Z7c47ejGQJtlz6rjqIOigL8PdzPPjQvIw8Ow=.c4426794-4753-4a83-9a63-addf7dc78c60@github.com>
References: <TCm_eA8Z7c47ejGQJtlz6rjqIOigL8PdzPPjQvIw8Ow=.c4426794-4753-4a83-9a63-addf7dc78c60@github.com>
Message-ID: <zVFTg9HXRWTYVWPIwd7XnOLrGnN8H_9KvoOB8nnJXZY=.a235dcb3-4dff-4cf3-9885-e0507fb4f9de@github.com>

On Fri, 11 Sep 2020 10:22:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We run out of space in C2's scratch buffer when calculating the size of the MachVEPNode because the inline type entry
> point requires lots of space for the ZGC barriers when the inline type argument contains many object fields.
> The fix is to increase the scratch emit buffer size based on the number of oop fields of scalarized inline type
> arguments.

This pull request has now been integrated.

Changeset: 74a85238
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/74a85238
Stats:     116 lines in 4 files changed: 2 ins; 112 del; 2 mod

8253047: [lworld] C2 compilation fails with guarantee(sect->end() <= sect->limit()) failed: sanity

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

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


From fparain at openjdk.java.net  Mon Sep 14 14:01:50 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 14 Sep 2020 14:01:50 GMT
Subject: [lworld] RFR: 8253113: [lworld] [lw3] C1 should avoid copying element
 of flattened arrays when reading a sub-element
Message-ID: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>

Please review these changes optimizing access to flattened arrays in C1.

The optimization avoids unnecessary copies of intermediate values when the code accesses a sub-element of a flattened
array.

For instance, with the following code:

inline class Point { int x = 0, y = 0; }
void foo() {
    Point[] array = new Point[10];
    int i = array[1].x;
}

C1 used to create a new instance of Point, copy the content from the array, then reads the x field from this new
instance. With the optimization, C1 directly accesses the x field from the flattened array, and makes no heap
allocation.

A simple benchmark on the "int i = array[1].x;" line gives these results:

baseline:
Benchmark                          Mode  Samples  Score  Score error  Units
o.s.MyBenchmark.testArrayReads     avgt      200  4.250        0.011  ns/op

optimized:
Benchmark                          Mode  Samples  Score  Score error  Units
o.s.MyBenchmark.testArrayReads     avgt      200  2.228        0.004  ns/op

Thank you,

Fred

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

Commit messages:
 - Remove debug message in unit test
 - Renaming and cleanup
 - Fix flattened sub-element access, add unit tests
 - Fix white space
 - Extend CFG format with information related to sub-element accesses
 - Remove debugging code
 - First implementation

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

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


From thartmann at openjdk.java.net  Tue Sep 15 07:22:45 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Sep 2020 07:22:45 GMT
Subject: [lworld] RFR: 8253113: [lworld] [lw3] C1 should avoid copying
 element of flattened arrays when reading a sub-element
In-Reply-To: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
References: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
Message-ID: <Y8CtvM6UXBozbmKgXYVIDLCinUNjikzBFGhkU7BhvJQ=.53e2645b-d774-4d0a-8d91-3435f4e34db0@github.com>

On Mon, 14 Sep 2020 13:55:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes optimizing access to flattened arrays in C1.
> 
> The optimization avoids unnecessary copies of intermediate values when the code accesses a sub-element of a flattened
> array.
> For instance, with the following code:
> 
> inline class Point { int x = 0, y = 0; }
> void foo() {
>     Point[] array = new Point[10];
>     int i = array[1].x;
> }
> 
> C1 used to create a new instance of Point, copy the content from the array, then reads the x field from this new
> instance. With the optimization, C1 directly accesses the x field from the flattened array, and makes no heap
> allocation.
> A simple benchmark on the "int i = array[1].x;" line gives these results:
> 
> baseline:
> Benchmark                          Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testArrayReads     avgt      200  4.250        0.011  ns/op
> 
> optimized:
> Benchmark                          Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testArrayReads     avgt      200  2.228        0.004  ns/op
> 
> Thank you,
> 
> Fred

Looks good to me, added some minor comments.

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1605:

> 1603:   assert(flat_array_klass->is_loaded(), "must be");
> 1604:
> 1605:   ciInlineKlass* elem_klass = NULL;

Unused.

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1611:

> 1609:   BasicType subelt_type = field->type()->basic_type();
> 1610:
> 1611:   #ifndef _LP64

Wrong indentation.

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1598:

> 1596: };
> 1597:
> 1598: void LIRGenerator::access_sub_element(LIRItem& array, LIRItem& index, LIR_Opr& result, ciField* field, int
> sub_offset) {

There is quite some code duplication here with access_flattened_array, can we factor it out?

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

Marked as reviewed by thartmann (Committer).

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


From thartmann at openjdk.java.net  Tue Sep 15 11:37:07 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Sep 2020 11:37:07 GMT
Subject: [lworld] RFR: 8253161: [lworld] C1's substitutability check should
 use andptr instead of andl for mark word
Message-ID: <skgueVda_1_z16GSCTGMuw1D0FbcN4FjKYsUnfpTPTg=.42a6b4d6-c11c-4c7c-9a3f-9eb01fe95202@github.com>

C1's substitutability check should use andptr instead of andl for mark word. I've also optimized the null check.

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

Commit messages:
 - 8253161: [lworld] C1's substitutability check should use andptr instead of andl for mark word

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

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


From roland at openjdk.java.net  Tue Sep 15 12:29:51 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 15 Sep 2020 12:29:51 GMT
Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode
Message-ID: <X_4FGySCfz6LGA5i3Ml9-KVAvkYZdliInUqpp2BSt1M=.cf1f2f31-2ed8-48d7-8e9d-3a6fbc8fe0d3@github.com>

This includes:
- a new ProfileData structure to profile both inputs to acmp
- profile collection at acmp in the interpreter on x86
- profile collection at acmp in c1 generated code on x86
- changes to c2's acmp implementation to leverage profiling (both existing profiling through type speculation and new
  profile data at acmp)
- small tweaks to the assembly code generated for acmp
- a change to the implementation of LIRGenerator::profile_null_free_array() so it doesn't use a branch (which is
  dangerous given the register allocator is not aware of branches added at the LIR level)
- new tests

Profile collection happens unconditionally. Leveraging profiling at acmp is under UseACmpProfile which is false by
default.

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

Commit messages:
 - fix for CI test failures
 - acmp profiling

Changes: https://git.openjdk.java.net/valhalla/pull/185/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=185&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8235914
  Stats: 1273 lines in 44 files changed: 1147 ins; 70 del; 56 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/185.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/185/head:pull/185

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


From thartmann at openjdk.java.net  Tue Sep 15 12:50:42 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Sep 2020 12:50:42 GMT
Subject: [lworld] Integrated: 8253161: [lworld] C1's substitutability check
 should use andptr instead of andl for mark word
In-Reply-To: <skgueVda_1_z16GSCTGMuw1D0FbcN4FjKYsUnfpTPTg=.42a6b4d6-c11c-4c7c-9a3f-9eb01fe95202@github.com>
References: <skgueVda_1_z16GSCTGMuw1D0FbcN4FjKYsUnfpTPTg=.42a6b4d6-c11c-4c7c-9a3f-9eb01fe95202@github.com>
Message-ID: <s8M_GeD0umEy-4C695c4sFrhzbqyWokGyPBoC-szhtY=.1e78164b-16d7-446f-beb8-69d761d2a039@github.com>

On Tue, 15 Sep 2020 11:32:03 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C1's substitutability check should use andptr instead of andl for mark word. I've also optimized the null check.

This pull request has now been integrated.

Changeset: 07e2fc53
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/07e2fc53
Stats:     11 lines in 2 files changed: 5 ins; 1 del; 5 mod

8253161: [lworld] C1's substitutability check should use andptr instead of andl for mark word

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

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


From fparain at openjdk.java.net  Tue Sep 15 13:02:33 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 15 Sep 2020 13:02:33 GMT
Subject: [lworld] RFR: 8253113: [lworld] [lw3] C1 should avoid copying
 element of flattened arrays when reading a sub-element [v2]
In-Reply-To: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
References: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
Message-ID: <0HMbqyPwV6y9-qgT3R0D-DWiksnR_rCReyUKiFNq6E4=.d3329659-9527-4c98-b59a-34779084c361@github.com>

> Please review these changes optimizing access to flattened arrays in C1.
> 
> The optimization avoids unnecessary copies of intermediate values when the code accesses a sub-element of a flattened
> array.
> For instance, with the following code:
> 
> inline class Point { int x = 0, y = 0; }
> void foo() {
>     Point[] array = new Point[10];
>     int i = array[1].x;
> }
> 
> C1 used to create a new instance of Point, copy the content from the array, then reads the x field from this new
> instance. With the optimization, C1 directly accesses the x field from the flattened array, and makes no heap
> allocation.
> A simple benchmark on the "int i = array[1].x;" line gives these results:
> 
> baseline:
> Benchmark                          Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testArrayReads     avgt      200  4.250        0.011  ns/op
> 
> optimized:
> Benchmark                          Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testArrayReads     avgt      200  2.228        0.004  ns/op
> 
> Thank you,
> 
> Fred

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

  Fixes from review

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/187/files
  - new: https://git.openjdk.java.net/valhalla/pull/187/files/c67a81a7..c7480441

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

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

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


From fparain at openjdk.java.net  Tue Sep 15 13:02:35 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 15 Sep 2020 13:02:35 GMT
Subject: [lworld] RFR: 8253113: [lworld] [lw3] C1 should avoid copying
 element of flattened arrays when reading a sub-element [v2]
In-Reply-To: <Y8CtvM6UXBozbmKgXYVIDLCinUNjikzBFGhkU7BhvJQ=.53e2645b-d774-4d0a-8d91-3435f4e34db0@github.com>
References: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
 <Y8CtvM6UXBozbmKgXYVIDLCinUNjikzBFGhkU7BhvJQ=.53e2645b-d774-4d0a-8d91-3435f4e34db0@github.com>
Message-ID: <6VS4XjqZp9zbl0sqtHk-WqyBLNpj0RRQBvf-by-U5wE=.78dd677c-34e4-47cd-b2f5-ccfcdf418703@github.com>

On Tue, 15 Sep 2020 07:07:04 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes from review
>
> src/hotspot/share/c1/c1_LIRGenerator.cpp line 1605:
> 
>> 1603:   assert(flat_array_klass->is_loaded(), "must be");
>> 1604:
>> 1605:   ciInlineKlass* elem_klass = NULL;
> 
> Unused.

Fixed

> src/hotspot/share/c1/c1_LIRGenerator.cpp line 1611:
> 
>> 1609:   BasicType subelt_type = field->type()->basic_type();
>> 1610:
>> 1611:   #ifndef _LP64
> 
> Wrong indentation.

Fixed

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

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


From thartmann at openjdk.java.net  Tue Sep 15 13:12:17 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Sep 2020 13:12:17 GMT
Subject: [lworld] RFR: 8253113: [lworld] [lw3] C1 should avoid copying
 element of flattened arrays when reading a sub-element [v2]
In-Reply-To: <0HMbqyPwV6y9-qgT3R0D-DWiksnR_rCReyUKiFNq6E4=.d3329659-9527-4c98-b59a-34779084c361@github.com>
References: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
 <0HMbqyPwV6y9-qgT3R0D-DWiksnR_rCReyUKiFNq6E4=.d3329659-9527-4c98-b59a-34779084c361@github.com>
Message-ID: <qtOgZN8XD8PPkDLhsLGQWYsPwhPuC2x3dx4LEWetIbo=.c76de9f7-05ae-4115-8d13-4f29d39c8a95@github.com>

On Tue, 15 Sep 2020 13:02:33 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review these changes optimizing access to flattened arrays in C1.
>> 
>> The optimization avoids unnecessary copies of intermediate values when the code accesses a sub-element of a flattened
>> array.
>> For instance, with the following code:
>> 
>> inline class Point { int x = 0, y = 0; }
>> void foo() {
>>     Point[] array = new Point[10];
>>     int i = array[1].x;
>> }
>> 
>> C1 used to create a new instance of Point, copy the content from the array, then reads the x field from this new
>> instance. With the optimization, C1 directly accesses the x field from the flattened array, and makes no heap
>> allocation.
>> A simple benchmark on the "int i = array[1].x;" line gives these results:
>> 
>> baseline:
>> Benchmark                          Mode  Samples  Score  Score error  Units
>> o.s.MyBenchmark.testArrayReads     avgt      200  4.250        0.011  ns/op
>> 
>> optimized:
>> Benchmark                          Mode  Samples  Score  Score error  Units
>> o.s.MyBenchmark.testArrayReads     avgt      200  2.228        0.004  ns/op
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes from review

Looks good, thanks for making these changes!

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

Marked as reviewed by thartmann (Committer).

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


From roland at openjdk.java.net  Tue Sep 15 13:44:20 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 15 Sep 2020 13:44:20 GMT
Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode [v2]
In-Reply-To: <X_4FGySCfz6LGA5i3Ml9-KVAvkYZdliInUqpp2BSt1M=.cf1f2f31-2ed8-48d7-8e9d-3a6fbc8fe0d3@github.com>
References: <X_4FGySCfz6LGA5i3Ml9-KVAvkYZdliInUqpp2BSt1M=.cf1f2f31-2ed8-48d7-8e9d-3a6fbc8fe0d3@github.com>
Message-ID: <JnnVEJqIrH92duBU87FfxHvEVKf3NEihIvg1jUcSGi8=.45189fe2-36b5-44e3-a42b-4601cb7243b8@github.com>

> This includes:
> - a new ProfileData structure to profile both inputs to acmp
> - profile collection at acmp in the interpreter on x86
> - profile collection at acmp in c1 generated code on x86
> - changes to c2's acmp implementation to leverage profiling (both existing profiling through type speculation and new
>   profile data at acmp)
> - small tweaks to the assembly code generated for acmp
> - a change to the implementation of LIRGenerator::profile_null_free_array() so it doesn't use a branch (which is
>   dangerous given the register allocator is not aware of branches added at the LIR level)
> - new tests
> 
> Profile collection happens unconditionally. Leveraging profiling at acmp is under UseACmpProfile which is false by
> default.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains two commits:

 - fix for CI test failures
 - acmp profiling

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

Changes: https://git.openjdk.java.net/valhalla/pull/185/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=185&range=01
  Stats: 1272 lines in 44 files changed: 1146 ins; 70 del; 56 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/185.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/185/head:pull/185

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


From fparain at openjdk.java.net  Tue Sep 15 14:13:38 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 15 Sep 2020 14:13:38 GMT
Subject: [lworld] RFR: 8253113: [lworld] [lw3] C1 should avoid copying
 element of flattened arrays when reading a sub-element [v3]
In-Reply-To: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
References: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
Message-ID: <6JygQsVGJN5GRkAwAW19CYdWEVjdhGDjsFZpqfvMGcU=.629c07bb-9c36-4062-b02a-c4650eedf4bf@github.com>

> Please review these changes optimizing access to flattened arrays in C1.
> 
> The optimization avoids unnecessary copies of intermediate values when the code accesses a sub-element of a flattened
> array.
> For instance, with the following code:
> 
> inline class Point { int x = 0, y = 0; }
> void foo() {
>     Point[] array = new Point[10];
>     int i = array[1].x;
> }
> 
> C1 used to create a new instance of Point, copy the content from the array, then reads the x field from this new
> instance. With the optimization, C1 directly accesses the x field from the flattened array, and makes no heap
> allocation.
> A simple benchmark on the "int i = array[1].x;" line gives these results:
> 
> baseline:
> Benchmark                          Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testArrayReads     avgt      200  4.250        0.011  ns/op
> 
> optimized:
> Benchmark                          Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testArrayReads     avgt      200  2.228        0.004  ns/op
> 
> Thank you,
> 
> Fred

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

  More refactoring

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/187/files
  - new: https://git.openjdk.java.net/valhalla/pull/187/files/c7480441..fcde3846

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

  Stats: 38 lines in 2 files changed: 14 ins; 18 del; 6 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/187.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/187/head:pull/187

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


From fparain at openjdk.java.net  Tue Sep 15 14:13:44 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 15 Sep 2020 14:13:44 GMT
Subject: [lworld] RFR: 8253113: [lworld] [lw3] C1 should avoid copying
 element of flattened arrays when reading a sub-element [v3]
In-Reply-To: <Y8CtvM6UXBozbmKgXYVIDLCinUNjikzBFGhkU7BhvJQ=.53e2645b-d774-4d0a-8d91-3435f4e34db0@github.com>
References: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
 <Y8CtvM6UXBozbmKgXYVIDLCinUNjikzBFGhkU7BhvJQ=.53e2645b-d774-4d0a-8d91-3435f4e34db0@github.com>
Message-ID: <f3SSgf2St8VIAlFU4VT8uBXvIpWqRdUaskJTxOKKI_k=.d23e6182-b604-4fbe-b613-843e442ee496@github.com>

On Tue, 15 Sep 2020 07:14:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More refactoring
>
> src/hotspot/share/c1/c1_LIRGenerator.cpp line 1598:
> 
>> 1596: };
>> 1597:
>> 1598: void LIRGenerator::access_sub_element(LIRItem& array, LIRItem& index, LIR_Opr& result, ciField* field, int
>> sub_offset) {
> 
> There is quite some code duplication here with access_flattened_array, can we factor it out?

Code has been refactored, and the common code in access_flattened_array() and access_sub_element() is now shared in the
new method get_and_load_element_address().

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

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


From fparain at openjdk.java.net  Tue Sep 15 14:42:10 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 15 Sep 2020 14:42:10 GMT
Subject: [lworld] RFR: 8249887: [lworld] [lw3] Inline types should have a
 single set of array klasses
Message-ID: <5Hf0XEhP1ZcfXFKNh1pmr9UxAM3D4GcfBCsKFMQf4OY=.509a7693-f4b2-4d45-a9fd-025843cc8d58@github.com>

Please review these changes simplifying the handling of meta-data for array classes of inline types.

Tested with Mach5, tiers 1 to 3.

Thank you,

Fred

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

Commit messages:
 - Initial cleanup

Changes: https://git.openjdk.java.net/valhalla/pull/190/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=190&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8249887
  Stats: 84 lines in 6 files changed: 12 ins; 53 del; 19 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/190.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/190/head:pull/190

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


From martijnhoekstra at gmail.com  Tue Sep 15 15:17:13 2020
From: martijnhoekstra at gmail.com (Martijn Hoekstra)
Date: Tue, 15 Sep 2020 17:17:13 +0200
Subject: Crash in valhalla
Message-ID: <CAN8A5NOzovyDnnF9O60mNgOqtWfjV7nHjvYGujZ4sMs8cNBDcA@mail.gmail.com>

I'm trying out valhalla to see if scala is able to leverage it. Hacking on
it a bit, I have a class file that valhalla's javap is fine with, but
crashes the JVM when I try to run it -- which I suspect to be a bad
classfile created by me, and the jvm choking on it.

Are reports of these kinds of things valuable yet? If so, where/how can I
report it?


From dsimms at openjdk.java.net  Tue Sep 15 15:19:45 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 15 Sep 2020 15:19:45 GMT
Subject: [lworld] RFR: 8249887: [lworld] [lw3] Inline types should have a
 single set of array klasses
In-Reply-To: <5Hf0XEhP1ZcfXFKNh1pmr9UxAM3D4GcfBCsKFMQf4OY=.509a7693-f4b2-4d45-a9fd-025843cc8d58@github.com>
References: <5Hf0XEhP1ZcfXFKNh1pmr9UxAM3D4GcfBCsKFMQf4OY=.509a7693-f4b2-4d45-a9fd-025843cc8d58@github.com>
Message-ID: <YYwXOQHzX5pxvlCedkRPp6qoRvqiPx4YKgVcGHA90KY=.a4daf939-1949-40d5-89bf-52cb8eeddda9@github.com>

On Tue, 15 Sep 2020 14:35:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes simplifying the handling of meta-data for array classes of inline types.
> 
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

Looks good Fred, thanks for cleaning this out !

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

Marked as reviewed by dsimms (Committer).

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


From fparain at openjdk.java.net  Tue Sep 15 15:19:45 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 15 Sep 2020 15:19:45 GMT
Subject: [lworld] RFR: 8249887: [lworld] [lw3] Inline types should have a
 single set of array klasses
In-Reply-To: <YYwXOQHzX5pxvlCedkRPp6qoRvqiPx4YKgVcGHA90KY=.a4daf939-1949-40d5-89bf-52cb8eeddda9@github.com>
References: <5Hf0XEhP1ZcfXFKNh1pmr9UxAM3D4GcfBCsKFMQf4OY=.509a7693-f4b2-4d45-a9fd-025843cc8d58@github.com>
 <YYwXOQHzX5pxvlCedkRPp6qoRvqiPx4YKgVcGHA90KY=.a4daf939-1949-40d5-89bf-52cb8eeddda9@github.com>
Message-ID: <JSQC7lt58fSKDZZDt5poTulh7y6doLtJa7AE3D3psfw=.acc3efc0-fa73-49d3-b643-03757860a5db@github.com>

On Tue, 15 Sep 2020 15:15:54 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Please review these changes simplifying the handling of meta-data for array classes of inline types.
>> 
>> Tested with Mach5, tiers 1 to 3.
>> 
>> Thank you,
>> 
>> Fred
>
> Looks good Fred, thanks for cleaning this out !

Thanks David for your review.

Fred

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

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


From tobias.hartmann at oracle.com  Tue Sep 15 15:22:19 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 15 Sep 2020 17:22:19 +0200
Subject: Crash in valhalla
In-Reply-To: <CAN8A5NOzovyDnnF9O60mNgOqtWfjV7nHjvYGujZ4sMs8cNBDcA@mail.gmail.com>
References: <CAN8A5NOzovyDnnF9O60mNgOqtWfjV7nHjvYGujZ4sMs8cNBDcA@mail.gmail.com>
Message-ID: <56a54d68-f3b4-76b9-d595-b391e0f5ffb9@oracle.com>

Hi Martijn,

Thanks for trying out Valhalla!

On 15.09.20 17:17, Martijn Hoekstra wrote:
> Are reports of these kinds of things valuable yet? If so, where/how can I
> report it?

Yes, such feedback is very much appreciated. Feel free to simply share 
the details here (maybe upload the hs_err* file and reproducer somewhere 
and send the link).

Thanks,
Tobias


From thartmann at openjdk.java.net  Tue Sep 15 15:30:34 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Sep 2020 15:30:34 GMT
Subject: [lworld] RFR: 8253113: [lworld] [lw3] C1 should avoid copying
 element of flattened arrays when reading a sub-element [v3]
In-Reply-To: <6JygQsVGJN5GRkAwAW19CYdWEVjdhGDjsFZpqfvMGcU=.629c07bb-9c36-4062-b02a-c4650eedf4bf@github.com>
References: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
 <6JygQsVGJN5GRkAwAW19CYdWEVjdhGDjsFZpqfvMGcU=.629c07bb-9c36-4062-b02a-c4650eedf4bf@github.com>
Message-ID: <On4X6ga6hhQwOYLTdaIckUQMpLUg49NXSpgtuIc0mvs=.dbb66061-54a5-49a7-8f4b-bdcd68454404@github.com>

On Tue, 15 Sep 2020 14:13:38 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review these changes optimizing access to flattened arrays in C1.
>> 
>> The optimization avoids unnecessary copies of intermediate values when the code accesses a sub-element of a flattened
>> array.
>> For instance, with the following code:
>> 
>> inline class Point { int x = 0, y = 0; }
>> void foo() {
>>     Point[] array = new Point[10];
>>     int i = array[1].x;
>> }
>> 
>> C1 used to create a new instance of Point, copy the content from the array, then reads the x field from this new
>> instance. With the optimization, C1 directly accesses the x field from the flattened array, and makes no heap
>> allocation.
>> A simple benchmark on the "int i = array[1].x;" line gives these results:
>> 
>> baseline:
>> Benchmark                          Mode  Samples  Score  Score error  Units
>> o.s.MyBenchmark.testArrayReads     avgt      200  4.250        0.011  ns/op
>> 
>> optimized:
>> Benchmark                          Mode  Samples  Score  Score error  Units
>> o.s.MyBenchmark.testArrayReads     avgt      200  2.228        0.004  ns/op
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More refactoring

Nice refactoring. Looks good to me.

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1638:

> 1636:   assert(field != NULL, "Need a subelement type specified");
> 1637:
> 1638: // Find the starting address of the source (inside the array)

Indentation is wrong.

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1670:

> 1668:   assert(sub_offset == 0 || field != NULL, "Sanity check");
> 1669:
> 1670: // Find the starting address of the source (inside the array)

Indentation is wrong.

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

Marked as reviewed by thartmann (Committer).

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


From fparain at openjdk.java.net  Tue Sep 15 15:40:01 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 15 Sep 2020 15:40:01 GMT
Subject: [lworld] RFR: 8253113: [lworld] [lw3] C1 should avoid copying
 element of flattened arrays when reading a sub-element [v4]
In-Reply-To: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
References: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
Message-ID: <r9W7BPgNbhslc4aFGAJKHwEQmhrSf5grQCcF7AISFRw=.7ebcf2a4-a43a-4d3f-925d-5f09ae81564d@github.com>

> Please review these changes optimizing access to flattened arrays in C1.
> 
> The optimization avoids unnecessary copies of intermediate values when the code accesses a sub-element of a flattened
> array.
> For instance, with the following code:
> 
> inline class Point { int x = 0, y = 0; }
> void foo() {
>     Point[] array = new Point[10];
>     int i = array[1].x;
> }
> 
> C1 used to create a new instance of Point, copy the content from the array, then reads the x field from this new
> instance. With the optimization, C1 directly accesses the x field from the flattened array, and makes no heap
> allocation.
> A simple benchmark on the "int i = array[1].x;" line gives these results:
> 
> baseline:
> Benchmark                          Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testArrayReads     avgt      200  4.250        0.011  ns/op
> 
> optimized:
> Benchmark                          Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testArrayReads     avgt      200  2.228        0.004  ns/op
> 
> Thank you,
> 
> Fred

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

  Fix indentation

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/187/files
  - new: https://git.openjdk.java.net/valhalla/pull/187/files/fcde3846..8d97e01b

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

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

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


From thartmann at openjdk.java.net  Tue Sep 15 15:40:03 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Sep 2020 15:40:03 GMT
Subject: [lworld] RFR: 8253113: [lworld] [lw3] C1 should avoid copying
 element of flattened arrays when reading a sub-element [v4]
In-Reply-To: <r9W7BPgNbhslc4aFGAJKHwEQmhrSf5grQCcF7AISFRw=.7ebcf2a4-a43a-4d3f-925d-5f09ae81564d@github.com>
References: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
 <r9W7BPgNbhslc4aFGAJKHwEQmhrSf5grQCcF7AISFRw=.7ebcf2a4-a43a-4d3f-925d-5f09ae81564d@github.com>
Message-ID: <OB0nxLFnoRIXd5bPhN3vFPBKabR7pRfTGbIbMCN1iAs=.978f9158-3e3c-49a7-b1b2-15b5d935626e@github.com>

On Tue, 15 Sep 2020 15:36:20 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review these changes optimizing access to flattened arrays in C1.
>> 
>> The optimization avoids unnecessary copies of intermediate values when the code accesses a sub-element of a flattened
>> array.
>> For instance, with the following code:
>> 
>> inline class Point { int x = 0, y = 0; }
>> void foo() {
>>     Point[] array = new Point[10];
>>     int i = array[1].x;
>> }
>> 
>> C1 used to create a new instance of Point, copy the content from the array, then reads the x field from this new
>> instance. With the optimization, C1 directly accesses the x field from the flattened array, and makes no heap
>> allocation.
>> A simple benchmark on the "int i = array[1].x;" line gives these results:
>> 
>> baseline:
>> Benchmark                          Mode  Samples  Score  Score error  Units
>> o.s.MyBenchmark.testArrayReads     avgt      200  4.250        0.011  ns/op
>> 
>> optimized:
>> Benchmark                          Mode  Samples  Score  Score error  Units
>> o.s.MyBenchmark.testArrayReads     avgt      200  2.228        0.004  ns/op
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Marked as reviewed by thartmann (Committer).

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

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


From fparain at openjdk.java.net  Tue Sep 15 15:40:06 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 15 Sep 2020 15:40:06 GMT
Subject: [lworld] RFR: 8253113: [lworld] [lw3] C1 should avoid copying
 element of flattened arrays when reading a sub-element [v3]
In-Reply-To: <On4X6ga6hhQwOYLTdaIckUQMpLUg49NXSpgtuIc0mvs=.dbb66061-54a5-49a7-8f4b-bdcd68454404@github.com>
References: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
 <6JygQsVGJN5GRkAwAW19CYdWEVjdhGDjsFZpqfvMGcU=.629c07bb-9c36-4062-b02a-c4650eedf4bf@github.com>
 <On4X6ga6hhQwOYLTdaIckUQMpLUg49NXSpgtuIc0mvs=.dbb66061-54a5-49a7-8f4b-bdcd68454404@github.com>
Message-ID: <OKcotCpmF99CWro1lji-fcpEqIIBGCVrpBimjB0ckwU=.094f52d6-8fb0-49cd-a09f-27501afe9470@github.com>

On Tue, 15 Sep 2020 15:27:57 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More refactoring
>
> Nice refactoring. Looks good to me.

Thanks Tobias for your review.
I've fixed the wrong indentations.

Fred

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

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


From fparain at openjdk.java.net  Tue Sep 15 15:40:09 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 15 Sep 2020 15:40:09 GMT
Subject: [lworld] Integrated: 8253113: [lworld] [lw3] C1 should avoid copying
 element of flattened arrays when reading a sub-element
In-Reply-To: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
References: <Z4XRSKn_eBUhUtdgR6wst9rcmfcbKFxxXYbUq6EJrew=.300494eb-df9b-4ed8-8281-b0a8cfde047d@github.com>
Message-ID: <EX8p8Fspi4t_rTtLEFuM49xig5Pxqq_DRk8YFk1CHjQ=.3fa43945-e3cb-4ed1-8c70-88988a123e2b@github.com>

On Mon, 14 Sep 2020 13:55:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes optimizing access to flattened arrays in C1.
> 
> The optimization avoids unnecessary copies of intermediate values when the code accesses a sub-element of a flattened
> array.
> For instance, with the following code:
> 
> inline class Point { int x = 0, y = 0; }
> void foo() {
>     Point[] array = new Point[10];
>     int i = array[1].x;
> }
> 
> C1 used to create a new instance of Point, copy the content from the array, then reads the x field from this new
> instance. With the optimization, C1 directly accesses the x field from the flattened array, and makes no heap
> allocation.
> A simple benchmark on the "int i = array[1].x;" line gives these results:
> 
> baseline:
> Benchmark                          Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testArrayReads     avgt      200  4.250        0.011  ns/op
> 
> optimized:
> Benchmark                          Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testArrayReads     avgt      200  2.228        0.004  ns/op
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 1a52191c
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/1a52191c
Stats:     343 lines in 7 files changed: 9 ins; 297 del; 37 mod

8253113: [lworld] [lw3] C1 should avoid copying element of flattened arrays when reading a sub-element

Reviewed-by: thartmann

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

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


From fparain at openjdk.java.net  Tue Sep 15 15:42:19 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 15 Sep 2020 15:42:19 GMT
Subject: [lworld] Integrated: 8249887: [lworld] [lw3] Inline types should have
 a single set of array klasses
In-Reply-To: <5Hf0XEhP1ZcfXFKNh1pmr9UxAM3D4GcfBCsKFMQf4OY=.509a7693-f4b2-4d45-a9fd-025843cc8d58@github.com>
References: <5Hf0XEhP1ZcfXFKNh1pmr9UxAM3D4GcfBCsKFMQf4OY=.509a7693-f4b2-4d45-a9fd-025843cc8d58@github.com>
Message-ID: <TXbGg1sSFCnkBjzmDvfFpKRyphuz5Nc8vSEqtI8FvrA=.50a224df-764b-41c3-ab61-f81c75d822c3@github.com>

On Tue, 15 Sep 2020 14:35:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes simplifying the handling of meta-data for array classes of inline types.
> 
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 63076805
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/63076805
Stats:     82 lines in 6 files changed: 51 ins; 10 del; 21 mod

8249887: [lworld] [lw3] Inline types should have a single set of array klasses

Reviewed-by: dsimms

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

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


From martijnhoekstra at gmail.com  Tue Sep 15 15:59:08 2020
From: martijnhoekstra at gmail.com (Martijn Hoekstra)
Date: Tue, 15 Sep 2020 17:59:08 +0200
Subject: Crash in valhalla
In-Reply-To: <56a54d68-f3b4-76b9-d595-b391e0f5ffb9@oracle.com>
References: <CAN8A5NOzovyDnnF9O60mNgOqtWfjV7nHjvYGujZ4sMs8cNBDcA@mail.gmail.com>
 <56a54d68-f3b4-76b9-d595-b391e0f5ffb9@oracle.com>
Message-ID: <CAN8A5NNy+GKrkYuk8X+Zegijv+xvQ36jjjG-6uxMDYSuWm1HsQ@mail.gmail.com>

>
>
> Hi Martijn,
>
> Thanks for trying out Valhalla!
>
> On 15.09.20 17:17, Martijn Hoekstra wrote:
> > Are reports of these kinds of things valuable yet? If so, where/how can I
> > report it?
>
> Yes, such feedback is very much appreciated. Feel free to simply share
> the details here (maybe upload the hs_err* file and reproducer somewhere
> and send the link).
>
> Thanks,
> Tobias
>

Hi Tobias,

Thanks for the quick response.

I have a link with log, dump and class files here:
https://1drv.ms/u/s!Aukg503a2UkIg9NFE7NcQOFg_oKvOQ?e=NnpPCW


From forax at univ-mlv.fr  Tue Sep 15 21:54:59 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 15 Sep 2020 23:54:59 +0200 (CEST)
Subject: Crash in valhalla
In-Reply-To: <CAN8A5NNy+GKrkYuk8X+Zegijv+xvQ36jjjG-6uxMDYSuWm1HsQ@mail.gmail.com>
References: <CAN8A5NOzovyDnnF9O60mNgOqtWfjV7nHjvYGujZ4sMs8cNBDcA@mail.gmail.com>
 <56a54d68-f3b4-76b9-d595-b391e0f5ffb9@oracle.com>
 <CAN8A5NNy+GKrkYuk8X+Zegijv+xvQ36jjjG-6uxMDYSuWm1HsQ@mail.gmail.com>
Message-ID: <121285585.1874804.1600206899274.JavaMail.zimbra@u-pem.fr>

Hi Martijn,
obviously the VM should not crash,
the issue is that an inline class (MyInlineClass) at bytecode level should not have an instance method named <init> but a static method named <init>,
and use defaultvalue + withfield instead of invokespecial <init>() + putfield.

@Tobias, it seems that if an inline class doesn't have a static method <init>, the VM crash.

Using javap, your code is
public value class MyInlineClass {
  private final int i;

  public int i();
    Code:
       0: aload_0
       1: getfield      #13                 // Field i:I
       4: ireturn

  public MyInlineClass(int);     // <---------- WRONG
    Code:
       0: aload_0
       1: iload_1
       2: putfield      #13                 // Field i:I
       5: aload_0
       6: invokespecial #20                 // Method java/lang/Object."<init>":()V
       9: return
}



but it should be
public final value class MyInlineClass {
  private final int i;

  public int i();
    Code:
       0: aload_0
       1: getfield      #3                  // Field i:I
       4: ireturn

  public static MyInlineClass(int);   <---- the method is static here
    Code:
       0: defaultvalue  #1                  // class MyInlineClass
       3: astore_1
       4: iload_0
       5: aload_1
       6: swap
       7: withfield     #3                  // Field i:I
      10: astore_1
      11: aload_1
      12: areturn
}

as a side note, you don't have to generate the instruction swap in the static method <init>, it's an artefact of javac.

regards,
R?mi

----- Mail original -----
> De: "Martijn Hoekstra" <martijnhoekstra at gmail.com>
> ?: "Tobias Hartmann" <tobias.hartmann at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Mardi 15 Septembre 2020 17:59:08
> Objet: Re: Crash in valhalla

>>
>>
>> Hi Martijn,
>>
>> Thanks for trying out Valhalla!
>>
>> On 15.09.20 17:17, Martijn Hoekstra wrote:
>> > Are reports of these kinds of things valuable yet? If so, where/how can I
>> > report it?
>>
>> Yes, such feedback is very much appreciated. Feel free to simply share
>> the details here (maybe upload the hs_err* file and reproducer somewhere
>> and send the link).
>>
>> Thanks,
>> Tobias
>>
> 
> Hi Tobias,
> 
> Thanks for the quick response.
> 
> I have a link with log, dump and class files here:
> https://1drv.ms/u/s!Aukg503a2UkIg9NFE7NcQOFg_oKvOQ?e=NnpPCW


From skuksenko at openjdk.java.net  Tue Sep 15 22:36:40 2020
From: skuksenko at openjdk.java.net (Sergey Kuksenko)
Date: Tue, 15 Sep 2020 22:36:40 GMT
Subject: [lworld] RFR: 8253143: [lworld] Valhalla microbenchmarks bulk update
Message-ID: <7JGuDDOwsvu5am_QdZYNSTPZ8F9KdldTC9PWFkJLO9s=.84c9345b-ddb6-4262-8612-4cf5c3f8b13e@github.com>

Existing Valhalla microbenchmarks were completely revisited, reimplemented and vastly expanded.

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

Commit messages:
 - [lworld] Valhalla microbenchmarks bulk update (jcheck whitespaces fix)
 - Valhalla microbenchmarks bulk update
 - update Merge branch 'lworld' of github.com:openjdk/valhalla into lworld
 - Merge pull request #1 from openjdk/lworld

Changes: https://git.openjdk.java.net/valhalla/pull/188/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=188&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253143
  Stats: 46276 lines in 320 files changed: 34949 ins; 11314 del; 13 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/188.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/188/head:pull/188

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


From jrose at openjdk.java.net  Wed Sep 16 02:42:32 2020
From: jrose at openjdk.java.net (John R Rose)
Date: Wed, 16 Sep 2020 02:42:32 GMT
Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode
In-Reply-To: <X_4FGySCfz6LGA5i3Ml9-KVAvkYZdliInUqpp2BSt1M=.cf1f2f31-2ed8-48d7-8e9d-3a6fbc8fe0d3@github.com>
References: <X_4FGySCfz6LGA5i3Ml9-KVAvkYZdliInUqpp2BSt1M=.cf1f2f31-2ed8-48d7-8e9d-3a6fbc8fe0d3@github.com>
Message-ID: <aQubMHGiubb-12GwOCyRCD5rErvLHzm5x7l7UEe7sDI=.9adc98d5-506a-407a-a23f-4913f068d963@github.com>

On Fri, 11 Sep 2020 07:58:46 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> This includes:
> - a new ProfileData structure to profile both inputs to acmp
> - profile collection at acmp in the interpreter on x86
> - profile collection at acmp in c1 generated code on x86
> - changes to c2's acmp implementation to leverage profiling (both existing profiling through type speculation and new
>   profile data at acmp)
> - small tweaks to the assembly code generated for acmp
> - a change to the implementation of LIRGenerator::profile_null_free_array() so it doesn't use a branch (which is
>   dangerous given the register allocator is not aware of branches added at the LIR level)
> - new tests
> 
> Profile collection happens unconditionally. Leveraging profiling at acmp is under UseACmpProfile which is false by
> default.

When the JIT speculates on an acmp profile, I suppose the independent type profiles will help to make some cases more
profitable to test:  If an inline type is common, you test for it first and inline the rest.

But I don't think a good result requires independent type profiles for the two operands.  I would think that the
relevant history would consist of (a) the number of acmp attempts, and (b) for each inline type *for which the operands
had that as their common type* the frequency of encountering that type.  That's really just a single klass profile
(with counters).

This other form would be somewhat preferable because it would use less footprint and require less bookkeeping, and it
would capture sharper information for the JIT, than two independent profiles.  The weakness of independent profiles is
you don't know how often the two operands end up with the same type.

Just a suggestion.

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

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


From tobias.hartmann at oracle.com  Wed Sep 16 07:02:42 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 16 Sep 2020 09:02:42 +0200
Subject: Crash in valhalla
In-Reply-To: <CAN8A5NNy+GKrkYuk8X+Zegijv+xvQ36jjjG-6uxMDYSuWm1HsQ@mail.gmail.com>
References: <CAN8A5NOzovyDnnF9O60mNgOqtWfjV7nHjvYGujZ4sMs8cNBDcA@mail.gmail.com>
 <56a54d68-f3b4-76b9-d595-b391e0f5ffb9@oracle.com>
 <CAN8A5NNy+GKrkYuk8X+Zegijv+xvQ36jjjG-6uxMDYSuWm1HsQ@mail.gmail.com>
Message-ID: <fc81e795-de5d-9bf9-2f18-187222c2f6b6@oracle.com>

Hi Martijn,

On 15.09.20 17:59, Martijn Hoekstra wrote:
> I have a link with log, dump and class files here: 
> https://1drv.ms/u/s!Aukg503a2UkIg9NFE7NcQOFg_oKvOQ?e=NnpPCW 
> <https://urldefense.com/v3/__https://1drv.ms/u/s!Aukg503a2UkIg9NFE7NcQOFg_oKvOQ?e=NnpPCW__;!!GqivPVa7Brio!JJ_rmBXzOzfGtqT7z0hmxJjGy8vuY1y0B02X0yY9qjITnSgYsql450A5rUbx6vJjwB4$> 

Thanks a lot!

As Remi explained, the VM should not crash but the problematic bytecodes 
should be caught by the verifier. I've filed 
https://bugs.openjdk.java.net/browse/JDK-8253218.

Best regards,
Tobias


From martijnhoekstra at gmail.com  Wed Sep 16 09:01:44 2020
From: martijnhoekstra at gmail.com (Martijn Hoekstra)
Date: Wed, 16 Sep 2020 11:01:44 +0200
Subject: Crash in valhalla
In-Reply-To: <fc81e795-de5d-9bf9-2f18-187222c2f6b6@oracle.com>
References: <CAN8A5NOzovyDnnF9O60mNgOqtWfjV7nHjvYGujZ4sMs8cNBDcA@mail.gmail.com>
 <56a54d68-f3b4-76b9-d595-b391e0f5ffb9@oracle.com>
 <CAN8A5NNy+GKrkYuk8X+Zegijv+xvQ36jjjG-6uxMDYSuWm1HsQ@mail.gmail.com>
 <fc81e795-de5d-9bf9-2f18-187222c2f6b6@oracle.com>
Message-ID: <CAN8A5NPYn_Tn+k_G__rCbivKw8MYBJ0BBFUS21f1=eRcceQzJA@mail.gmail.com>

Thanks, that'll help a lot going forward!




On Wed, Sep 16, 2020 at 9:02 AM Tobias Hartmann <tobias.hartmann at oracle.com>
wrote:

> Hi Martijn,
>
> On 15.09.20 17:59, Martijn Hoekstra wrote:
> > I have a link with log, dump and class files here:
> > https://1drv.ms/u/s!Aukg503a2UkIg9NFE7NcQOFg_oKvOQ?e=NnpPCW
> > <
> https://urldefense.com/v3/__https://1drv.ms/u/s!Aukg503a2UkIg9NFE7NcQOFg_oKvOQ?e=NnpPCW__;!!GqivPVa7Brio!JJ_rmBXzOzfGtqT7z0hmxJjGy8vuY1y0B02X0yY9qjITnSgYsql450A5rUbx6vJjwB4$>
>
>
> Thanks a lot!
>
> As Remi explained, the VM should not crash but the problematic bytecodes
> should be caught by the verifier. I've filed
> https://bugs.openjdk.java.net/browse/JDK-8253218.
>
> Best regards,
> Tobias
>


From roland at openjdk.java.net  Wed Sep 16 16:21:09 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 16 Sep 2020 16:21:09 GMT
Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode
In-Reply-To: <aQubMHGiubb-12GwOCyRCD5rErvLHzm5x7l7UEe7sDI=.9adc98d5-506a-407a-a23f-4913f068d963@github.com>
References: <X_4FGySCfz6LGA5i3Ml9-KVAvkYZdliInUqpp2BSt1M=.cf1f2f31-2ed8-48d7-8e9d-3a6fbc8fe0d3@github.com>
 <aQubMHGiubb-12GwOCyRCD5rErvLHzm5x7l7UEe7sDI=.9adc98d5-506a-407a-a23f-4913f068d963@github.com>
Message-ID: <dowBtwq_eSKY9kE45iTV9tMBL1h6Xsdav8FEsp8cLX8=.818aabff-3ba2-456a-8be2-26f64020a82a@github.com>

On Wed, 16 Sep 2020 02:39:54 GMT, John R Rose <jrose at openjdk.org> wrote:

>> This includes:
>> - a new ProfileData structure to profile both inputs to acmp
>> - profile collection at acmp in the interpreter on x86
>> - profile collection at acmp in c1 generated code on x86
>> - changes to c2's acmp implementation to leverage profiling (both existing profiling through type speculation and new
>>   profile data at acmp)
>> - small tweaks to the assembly code generated for acmp
>> - a change to the implementation of LIRGenerator::profile_null_free_array() so it doesn't use a branch (which is
>>   dangerous given the register allocator is not aware of branches added at the LIR level)
>> - new tests
>> 
>> Profile collection happens unconditionally. Leveraging profiling at acmp is under UseACmpProfile which is false by
>> default.
>
> When the JIT speculates on an acmp profile, I suppose the independent type profiles will help to make some cases more
> profitable to test:  If an inline type is common, you test for it first and inline the rest.
> But I don't think a good result requires independent type profiles for the two operands.  I would think that the
> relevant history would consist of (a) the number of acmp attempts, and (b) for each inline type *for which the operands
> had that as their common type* the frequency of encountering that type.  That's really just a single klass profile
> (with counters).  This other form would be somewhat preferable because it would use less footprint and require less
> bookkeeping, and it would capture sharper information for the JIT, than two independent profiles.  The weakness of
> independent profiles is you don't know how often the two operands end up with the same type.  Just a suggestion.

@rose00 Thanks for the suggestion.

With this patch, my goal is to improve the performance of acmp when there's no inline types involved but the compiler
can't tell from the static types of the acmp inputs so that legacy code that make no use of inline types is not
affected by them. My understanding is that, first of all, we want the new acmp to not cause regressions in non inlined
type code. How important is it to optimize acmp (or aaload/aastore) for cases where inline types hidden behind Object
are compared (or flattened arrays hidden behind Object[])?

Current logic for an acmp is:
if (left == right) {
 // equal
} else {
  if (left == null) {
    // not equal
  } else  if (left not inline type) {
    // not equal
  } else if (right == null) {
    // not equal
  } else if (left.klass != right.klass) {
    // not equal
  } else {
    // substituability test
  }
}
Now if we have profiling for left or right that tells one of them is always null or one them is never an inline type
and never null then we only need 2 comparisons, for instance:

if (left == right) {
  // equal
} else {
  if (left.right.klass == java.lang.Integer) { // implicit null check
    trap;
  }
 // not equal
}

which is a pattern that's a lot friendlier to the compiler.

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

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


From jrose at openjdk.java.net  Wed Sep 16 18:31:14 2020
From: jrose at openjdk.java.net (John R Rose)
Date: Wed, 16 Sep 2020 18:31:14 GMT
Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode
In-Reply-To: <dowBtwq_eSKY9kE45iTV9tMBL1h6Xsdav8FEsp8cLX8=.818aabff-3ba2-456a-8be2-26f64020a82a@github.com>
References: <X_4FGySCfz6LGA5i3Ml9-KVAvkYZdliInUqpp2BSt1M=.cf1f2f31-2ed8-48d7-8e9d-3a6fbc8fe0d3@github.com>
 <aQubMHGiubb-12GwOCyRCD5rErvLHzm5x7l7UEe7sDI=.9adc98d5-506a-407a-a23f-4913f068d963@github.com>
 <dowBtwq_eSKY9kE45iTV9tMBL1h6Xsdav8FEsp8cLX8=.818aabff-3ba2-456a-8be2-26f64020a82a@github.com>
Message-ID: <a_09cb9P1sXZvxMjoBw8KC1B9Ffz9tX36pTOtyY4Hy8=.f67b61ad-1e76-4e6a-aac3-725eec4fa88e@github.com>

On Wed, 16 Sep 2020 16:16:42 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> When the JIT speculates on an acmp profile, I suppose the independent type profiles will help to make some cases more
>> profitable to test:  If an inline type is common, you test for it first and inline the rest.
>> But I don't think a good result requires independent type profiles for the two operands.  I would think that the
>> relevant history would consist of (a) the number of acmp attempts, and (b) for each inline type *for which the operands
>> had that as their common type* the frequency of encountering that type.  That's really just a single klass profile
>> (with counters).  This other form would be somewhat preferable because it would use less footprint and require less
>> bookkeeping, and it would capture sharper information for the JIT, than two independent profiles.  The weakness of
>> independent profiles is you don't know how often the two operands end up with the same type.  Just a suggestion.
>
> @rose00 Thanks for the suggestion.
> 
> With this patch, my goal is to improve the performance of acmp when there's no inline types involved but the compiler
> can't tell from the static types of the acmp inputs so that legacy code that make no use of inline types is not
> affected by them. My understanding is that, first of all, we want the new acmp to not cause regressions in non inlined
> type code. How important is it to optimize acmp (or aaload/aastore) for cases where inline types hidden behind Object
> are compared (or flattened arrays hidden behind Object[])?  Current logic for an acmp is: if (left == right) {
>  // equal
> } else {
>   if (left == null) {
>     // not equal
>   } else  if (left not inline type) {
>     // not equal
>   } else if (right == null) {
>     // not equal
>   } else if (left.klass != right.klass) {
>     // not equal
>   } else {
>     // substituability test
>   }
> }
> Now if we have profiling for left or right that tells one of them is always null or one them is never an inline type
> and never null then we only need 2 comparisons, for instance:
> if (left == right) {
>   // equal
> } else {
>   if (left.right.klass == java.lang.Integer) { // implicit null check
>     trap;
>   }
>  // not equal
> }
> 
> which is a pattern that's a lot friendlier to the compiler.

The simple comparison `left == right` is valid for `acmp` along all paths *except* when `left` and `right` are inlines,
and *even then* the simple comparison is valid if the two inline types are *distinct*.  Therefore, the only evidence
that the JIT needs that the S-test was ever needed is if the two types are (a) inlines and (b) identical.  Your profile
detects (a) but not (b), which means the JIT can't speculate (b).  If you speculate (b) you can use `left == right`
because any inlines that appear are irrelevant.

(Of course you need additional testing to verify the speculation.  That's something like `left.klass == right.klass &&
left.klass.is_inline` or the reverse, which detects (a) and (b).  It can go to an uncommon trap if the profile claims
it's rare, to avoid compiling in a potentially polymorphic S-test.)

My overall point here is that `left == right` is a good way to prove, in many cases, that two things are identical, and
`left != right` is a good heuristic (not proof) that two things are not identical.  The heuristic fails only if (a) and
(b) are true.  That heuristic seems to be a good target for speculation; perhaps you are aiming at other speculations
here and I'm barking up a different tree.  For this speculation, I think you would throw an uncommon trap you saw (a)
and (b), so the complicated S-test path doesn't need to be compiled.

To answer your question, I think (but don't know for sure) that inlines masked by `Object` references will be an
important source of `acmp` slow paths.  If the profile indicates that either (a) inlines are not seen in the operands
or (b) equal inline types are not seen, then the slow S-test can be removed and replaced (at most) by an uncommon trap.

(Idea of the day:  Make an `acmp` entry point a hidden/injected virtual method on every object, with a distinct body
for each inline object, and `this==x` on `jl.Object`.  The body for any given inline class `V` is then `this==x || x
instanceof V && V.$MONOMORPHIC_S_TEST(this, (V)x)`.  Then refer the whole problem to our portfolio of devirtualization
optimizations.  That gives us bimorphic calls, etc., for `acmp`.  Maybe that's a better factoring than adding more and
more ad hoc `acmp` logic.  This idea pairs well with your profile proposal, since it basically treats `acmp` as a
hidden virtual call.)

HTH

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

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


From hseigel at openjdk.java.net  Wed Sep 16 20:43:11 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 16 Sep 2020 20:43:11 GMT
Subject: [lworld] RFR: 8253218 ClassFileParser hits
 =?UTF-8?B?YXNzZXJ0KGtsYXNzLT5hY2Nlc3NfZmxhZ3MoKS5pc19pbmxpbmVfdOKApg==?=
Message-ID: <_lXC6InfuuIW0B_EJwDXEgyUzJRiK2I-4MwoJoqYz1E=.4d56bc26-56ae-4ab7-bf01-378b7562b2bb@github.com>

Please review this fix for JDK-8253218.  The fix throws a ClassFormatError exception if a class file, with an old class
file version, contains a Q signature.

The fix was tested with tiers 1-2 on Windows, Linux x64, and MacOS, and tiers 3-5 on Linux x64.

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

Commit messages:
 - 8253218 ClassFileParser hits assert(klass->access_flags().is_inline_type()) failed: Value type expected

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

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


From fparain at openjdk.java.net  Wed Sep 16 20:46:20 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 16 Sep 2020 20:46:20 GMT
Subject: [lworld] RFR: 8253218 ClassFileParser hits
 =?UTF-8?B?YXNzZXJ0KGtsYXNzLT5hY2Nlc3NfZmxhZ3MoKS5pc19pbmxpbmVfdOKApg==?=
In-Reply-To: <_lXC6InfuuIW0B_EJwDXEgyUzJRiK2I-4MwoJoqYz1E=.4d56bc26-56ae-4ab7-bf01-378b7562b2bb@github.com>
References: <_lXC6InfuuIW0B_EJwDXEgyUzJRiK2I-4MwoJoqYz1E=.4d56bc26-56ae-4ab7-bf01-378b7562b2bb@github.com>
Message-ID: <qU4G1mBH4-M4t06hd3gIh30fG09tRSFKImOtYBHAaDI=.e084ca26-c372-4933-bfd1-3953f5b22677@github.com>

On Wed, 16 Sep 2020 20:37:02 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8253218.  The fix throws a ClassFormatError exception if a class file, with an old class
> file version, contains a Q signature.
> The fix was tested with tiers 1-2 on Windows, Linux x64, and MacOS, and tiers 3-5 on Linux x64.

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

> 5300:                                                    TRAPS) const {
> 5301:   if (!_need_verify) { return; }
> 5302:   if (!supports_inline_types() && signature->is_Q_signature()) {

Shouldn't the test also include a check for Q-arrays?  (signature->is_Q_array_signature()) ?

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

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


From hseigel at openjdk.java.net  Wed Sep 16 20:52:26 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 16 Sep 2020 20:52:26 GMT
Subject: [lworld] RFR: 8253218 ClassFileParser hits
 =?UTF-8?B?YXNzZXJ0KGtsYXNzLT5hY2Nlc3NfZmxhZ3MoKS5pc19pbmxpbmVfdOKApg==?=
In-Reply-To: <qU4G1mBH4-M4t06hd3gIh30fG09tRSFKImOtYBHAaDI=.e084ca26-c372-4933-bfd1-3953f5b22677@github.com>
References: <_lXC6InfuuIW0B_EJwDXEgyUzJRiK2I-4MwoJoqYz1E=.4d56bc26-56ae-4ab7-bf01-378b7562b2bb@github.com>
 <qU4G1mBH4-M4t06hd3gIh30fG09tRSFKImOtYBHAaDI=.e084ca26-c372-4933-bfd1-3953f5b22677@github.com>
Message-ID: <wyER_sW65anEskfRVRf2iupZ05RV15HPmun9oeewpjY=.490d1bf1-cdfe-42e2-9ad4-a4bf3b1acc7d@github.com>

On Wed, 16 Sep 2020 20:43:39 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this fix for JDK-8253218.  The fix throws a ClassFormatError exception if a class file, with an old class
>> file version, contains a Q signature.
>> The fix was tested with tiers 1-2 on Windows, Linux x64, and MacOS, and tiers 3-5 on Linux x64.
>
> src/hotspot/share/classfile/classFileParser.cpp line 5302:
> 
>> 5300:                                                    TRAPS) const {
>> 5301:   if (!_need_verify) { return; }
>> 5302:   if (!supports_inline_types() && signature->is_Q_signature()) {
> 
> Shouldn't the test also include a check for Q-arrays?  (signature->is_Q_array_signature()) ?

Yes, it should check for Q-arrays.  I'll add the check.  Thanks!

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

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


From skuksenko at openjdk.java.net  Wed Sep 16 22:23:55 2020
From: skuksenko at openjdk.java.net (Sergey Kuksenko)
Date: Wed, 16 Sep 2020 22:23:55 GMT
Subject: [lworld] Integrated: 8253143: [lworld] Valhalla microbenchmarks bulk
 update
In-Reply-To: <7JGuDDOwsvu5am_QdZYNSTPZ8F9KdldTC9PWFkJLO9s=.84c9345b-ddb6-4262-8612-4cf5c3f8b13e@github.com>
References: <7JGuDDOwsvu5am_QdZYNSTPZ8F9KdldTC9PWFkJLO9s=.84c9345b-ddb6-4262-8612-4cf5c3f8b13e@github.com>
Message-ID: <5i2W37DnwkuPs1qQG89WyXbeSCa_-oJs4TJGsw_0gZk=.c00f9d85-f16c-48f1-915b-3be25bba5e07@github.com>

On Tue, 15 Sep 2020 03:17:03 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> Existing Valhalla microbenchmarks were completely revisited, reimplemented and vastly expanded.

This pull request has now been integrated.

Changeset: 174dcf50
Author:    Sergey Kuksenko <skuksenko at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/174dcf50
Stats:     46276 lines in 320 files changed: 11314 ins; 34949 del; 13 mod

8253143: [lworld] Valhalla microbenchmarks bulk update

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

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


From dsimms at openjdk.java.net  Thu Sep 17 08:20:54 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 17 Sep 2020 08:20:54 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <S3SrpxQKm_tkfVVT8X-apeLASjJfyP-3yp0gcu1R9q8=.e69e1b5f-cbae-4526-b72b-7ea51f6f942b@github.com>

Merge tag 'jdk-16+16'

Any branch or tag names allowed

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

Commit messages:
 - Any branch or tag names allowed
 - Merge tag 'jdk-16+16' into lworld_merge_jdk_16_16
 - 8253130: bug7072653.java failed "Popup window height ... is wrong"
 - 8253125: vmTestbase/nsk/stress/stack/stack017.java timed out
 - 8253244: Shenandoah: cleanup includes in Shenandoah root processor files
 - 8253207: enable problemlists jcheck's check
 - 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect
 - 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance)
 - 8253206: Enforce whitespace checking for additional source files
 - 8253162: Make frame::oops_do const
 - ... and 65 more: https://git.openjdk.java.net/valhalla/compare/174dcf50...d6adc91d

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

Changes: https://git.openjdk.java.net/valhalla/pull/192/files
  Stats: 15807 lines in 440 files changed: 8027 ins; 5432 del; 2348 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/192.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/192/head:pull/192

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


From dsimms at openjdk.java.net  Thu Sep 17 08:24:47 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 17 Sep 2020 08:24:47 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <S3SrpxQKm_tkfVVT8X-apeLASjJfyP-3yp0gcu1R9q8=.e69e1b5f-cbae-4526-b72b-7ea51f6f942b@github.com>
References: <S3SrpxQKm_tkfVVT8X-apeLASjJfyP-3yp0gcu1R9q8=.e69e1b5f-cbae-4526-b72b-7ea51f6f942b@github.com>
Message-ID: <-Nnm0jWNqfZlOhepBbUburslEeycAE83g0_wMH82LPo=.ef7e0132-b4a3-485c-912e-3eaceff367c6@github.com>

> Merge tag 'jdk-16+16'
> 
> Any branch or tag names allowed

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

  Merge name check fails, work around via removal

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/192/files
  - new: https://git.openjdk.java.net/valhalla/pull/192/files/d6adc91d..c7ad7f97

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

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

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


From dsimms at openjdk.java.net  Thu Sep 17 08:48:41 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 17 Sep 2020 08:48:41 GMT
Subject: [lworld] RFR: Merge jdk [v3]
In-Reply-To: <S3SrpxQKm_tkfVVT8X-apeLASjJfyP-3yp0gcu1R9q8=.e69e1b5f-cbae-4526-b72b-7ea51f6f942b@github.com>
References: <S3SrpxQKm_tkfVVT8X-apeLASjJfyP-3yp0gcu1R9q8=.e69e1b5f-cbae-4526-b72b-7ea51f6f942b@github.com>
Message-ID: <JKWjFEcUpJRAB_8Ap_t8TxQbwDKl2Szy7F3-GPbhS6o=.5f924353-f463-4f18-8605-b67be4493e78@github.com>

> Merge tag 'jdk-16+16'
> 
> Any branch or tag names allowed

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

  Merge name check still fails

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/192/files
  - new: https://git.openjdk.java.net/valhalla/pull/192/files/c7ad7f97..8c89bd0d

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

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

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


From hseigel at openjdk.java.net  Thu Sep 17 18:37:44 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 17 Sep 2020 18:37:44 GMT
Subject: [lworld] RFR: 8253218 ClassFileParser hits
 =?UTF-8?B?YXNzZXJ0KGtsYXNzLT5hY2Nlc3NfZmxhZ3MoKS5pc19pbmxpbmVfdOKApg==?= [v2]
In-Reply-To: <_lXC6InfuuIW0B_EJwDXEgyUzJRiK2I-4MwoJoqYz1E=.4d56bc26-56ae-4ab7-bf01-378b7562b2bb@github.com>
References: <_lXC6InfuuIW0B_EJwDXEgyUzJRiK2I-4MwoJoqYz1E=.4d56bc26-56ae-4ab7-bf01-378b7562b2bb@github.com>
Message-ID: <2jEv79WHNYws30y8k8RsWIW9enarJX5Uih0PoZV5x1E=.0d187b7e-f397-43f1-bf17-7556f2b66959@github.com>

> Please review this fix for JDK-8253218.  The fix throws a ClassFormatError exception if a class file, with an old class
> file version, contains a Q signature.
> The fix was tested with tiers 1-2 on Windows, Linux x64, and MacOS, and tiers 3-5 on Linux x64.

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  8253218 ClassFileParser hits assert(klass->access_flags().is_inline_type()) failed: Value type expected

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/191/files
  - new: https://git.openjdk.java.net/valhalla/pull/191/files/6a25088a..a17e5460

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

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

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


From fparain at openjdk.java.net  Thu Sep 17 18:59:24 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 17 Sep 2020 18:59:24 GMT
Subject: [lworld] RFR: 8253218 ClassFileParser hits
 =?UTF-8?B?YXNzZXJ0KGtsYXNzLT5hY2Nlc3NfZmxhZ3MoKS5pc19pbmxpbmVfdOKApg==?= [v2]
In-Reply-To: <2jEv79WHNYws30y8k8RsWIW9enarJX5Uih0PoZV5x1E=.0d187b7e-f397-43f1-bf17-7556f2b66959@github.com>
References: <_lXC6InfuuIW0B_EJwDXEgyUzJRiK2I-4MwoJoqYz1E=.4d56bc26-56ae-4ab7-bf01-378b7562b2bb@github.com>
 <2jEv79WHNYws30y8k8RsWIW9enarJX5Uih0PoZV5x1E=.0d187b7e-f397-43f1-bf17-7556f2b66959@github.com>
Message-ID: <1ea2QaK2s5mgAIIAKs-xgfspIRAeGumTueEz2p3hT5Y=.ba862f05-ebbb-4e24-ba64-24c2b8dcc39a@github.com>

On Thu, 17 Sep 2020 18:37:44 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this fix for JDK-8253218.  The fix throws a ClassFormatError exception if a class file, with an old class
>> file version, contains a Q signature.
>> The fix was tested with tiers 1-2 on Windows, Linux x64, and MacOS, and tiers 3-5 on Linux x64.
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253218 ClassFileParser hits assert(klass->access_flags().is_inline_type()) failed: Value type expected

Looks good to me.

Fred

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

Marked as reviewed by fparain (Committer).

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


From hseigel at openjdk.java.net  Thu Sep 17 19:18:53 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 17 Sep 2020 19:18:53 GMT
Subject: [lworld] Integrated: 8253218 ClassFileParser hits
 =?UTF-8?B?YXNzZXJ0KGtsYXNzLT5hY2Nlc3NfZmxhZ3MoKS5pc19pbmxpbmVfdOKApg==?=
In-Reply-To: <_lXC6InfuuIW0B_EJwDXEgyUzJRiK2I-4MwoJoqYz1E=.4d56bc26-56ae-4ab7-bf01-378b7562b2bb@github.com>
References: <_lXC6InfuuIW0B_EJwDXEgyUzJRiK2I-4MwoJoqYz1E=.4d56bc26-56ae-4ab7-bf01-378b7562b2bb@github.com>
Message-ID: <_j7po9WbfG1Pv-LMkNRk_2CSPOGwMMYd7hU7NOePSUY=.9ecf18c0-a023-48be-a218-617241b9a034@github.com>

On Wed, 16 Sep 2020 20:37:02 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8253218.  The fix throws a ClassFormatError exception if a class file, with an old class
> file version, contains a Q signature.
> The fix was tested with tiers 1-2 on Windows, Linux x64, and MacOS, and tiers 3-5 on Linux x64.

This pull request has now been integrated.

Changeset: 4f9c2e22
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/4f9c2e22
Stats:     279 lines in 3 files changed: 1 ins; 277 del; 1 mod

8253218: ClassFileParser hits assert(klass->access_flags().is_inline_t?

Reviewed-by: fparain

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

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


From dsimms at openjdk.java.net  Fri Sep 18 08:33:38 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 18 Sep 2020 08:33:38 GMT
Subject: [lworld] RFR: Relax jcheck
Message-ID: <w4ycKWax3Ri_FXKDkJzLWmlFMa90gGGm2t5wsQXBlXk=.16ce9528-8f54-4b4e-8083-d42466feec1b@github.com>

Removed checks

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

Commit messages:
 - Relax jcheck

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

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


From dsimms at openjdk.java.net  Fri Sep 18 08:41:30 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 18 Sep 2020 08:41:30 GMT
Subject: [lworld] Integrated: Relax jcheck
In-Reply-To: <w4ycKWax3Ri_FXKDkJzLWmlFMa90gGGm2t5wsQXBlXk=.16ce9528-8f54-4b4e-8083-d42466feec1b@github.com>
References: <w4ycKWax3Ri_FXKDkJzLWmlFMa90gGGm2t5wsQXBlXk=.16ce9528-8f54-4b4e-8083-d42466feec1b@github.com>
Message-ID: <Ur67y-qvGssTNhnsO-wpcWFPB3IJj9Ssr0VBB8fkNxk=.1c6eb878-4ec8-4fcc-b312-764fbfa52e56@github.com>

On Fri, 18 Sep 2020 08:27:46 GMT, David Simms <dsimms at openjdk.org> wrote:

> Removed checks

This pull request has now been integrated.

Changeset: 17a5215d
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/17a5215d
Stats:     11 lines in 1 file changed: 9 ins; 0 del; 2 mod

Relax jcheck

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

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


From dsimms at openjdk.java.net  Fri Sep 18 08:55:20 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 18 Sep 2020 08:55:20 GMT
Subject: [lworld] RFR: Merge jdk [v4]
In-Reply-To: <S3SrpxQKm_tkfVVT8X-apeLASjJfyP-3yp0gcu1R9q8=.e69e1b5f-cbae-4526-b72b-7ea51f6f942b@github.com>
References: <S3SrpxQKm_tkfVVT8X-apeLASjJfyP-3yp0gcu1R9q8=.e69e1b5f-cbae-4526-b72b-7ea51f6f942b@github.com>
Message-ID: <alsVhB48pfFSUhjoi-duZ1v4U2YEs5_Qfnk5hILWr94=.3f545081-792c-45e9-9d70-74b38a63c206@github.com>

> Merge tag 'jdk-16+16'
> 
> Any branch or tag names allowed

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

 - Merge branch 'lworld' into lworld_merge_jdk_16_16
 - Merge name check still fails
 - Merge name check fails, work around via removal
 - Any branch or tag names allowed
 - Merge tag 'jdk-16+16' into lworld_merge_jdk_16_16
   
   Added tag jdk-16+16 for changeset 1c84cfa2
   
   # Conflicts:
   #	.jcheck/conf
   #	src/hotspot/cpu/x86/globals_x86.hpp
   #	src/hotspot/share/memory/metaspaceShared.cpp
   #	src/hotspot/share/oops/instanceKlass.hpp
   #	src/hotspot/share/oops/objArrayKlass.cpp
   #	src/hotspot/share/oops/typeArrayKlass.cpp
   #	src/hotspot/share/opto/c2_globals.hpp
   #	src/hotspot/share/opto/type.cpp
   #	src/hotspot/share/runtime/frame.cpp
   #	src/hotspot/share/runtime/frame.hpp
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
 - 8253130: bug7072653.java failed "Popup window height ... is wrong"
   
   Reviewed-by: psadhukhan
 - 8253125: vmTestbase/nsk/stress/stack/stack017.java timed out
   
   Reviewed-by: dcubed
 - 8253244: Shenandoah: cleanup includes in Shenandoah root processor files
   
   Reviewed-by: shade
 - 8253207: enable problemlists jcheck's check
   
   Reviewed-by: erikj
 - 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect
   
   Reviewed-by: lancea, alanb
 - ... and 68 more: https://git.openjdk.java.net/valhalla/compare/17a5215d...fe64e403

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

Changes: https://git.openjdk.java.net/valhalla/pull/192/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=192&range=03
  Stats: 15799 lines in 440 files changed: 8024 ins; 5429 del; 2346 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/192.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/192/head:pull/192

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


From dsimms at openjdk.java.net  Fri Sep 18 08:55:29 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 18 Sep 2020 08:55:29 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <S3SrpxQKm_tkfVVT8X-apeLASjJfyP-3yp0gcu1R9q8=.e69e1b5f-cbae-4526-b72b-7ea51f6f942b@github.com>
References: <S3SrpxQKm_tkfVVT8X-apeLASjJfyP-3yp0gcu1R9q8=.e69e1b5f-cbae-4526-b72b-7ea51f6f942b@github.com>
Message-ID: <4Wr2cEzy7dBlbI5xUtd4xgPbdjwLwVN8GqYjr03_EYI=.1f6c4f95-a21f-4448-afc7-8e958a95147f@github.com>

On Thu, 17 Sep 2020 08:10:27 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+16'
> 
> Any branch or tag names allowed

This pull request has now been integrated.

Changeset: 85bd776b
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/85bd776b
Stats:     15780 lines in 440 files changed: 5410 ins; 8005 del; 2365 mod

Merge jdk

Merge tag 'jdk-16+16'

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

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


From roland at openjdk.java.net  Mon Sep 21 15:38:55 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 21 Sep 2020 15:38:55 GMT
Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode
In-Reply-To: <a_09cb9P1sXZvxMjoBw8KC1B9Ffz9tX36pTOtyY4Hy8=.f67b61ad-1e76-4e6a-aac3-725eec4fa88e@github.com>
References: <X_4FGySCfz6LGA5i3Ml9-KVAvkYZdliInUqpp2BSt1M=.cf1f2f31-2ed8-48d7-8e9d-3a6fbc8fe0d3@github.com>
 <aQubMHGiubb-12GwOCyRCD5rErvLHzm5x7l7UEe7sDI=.9adc98d5-506a-407a-a23f-4913f068d963@github.com>
 <dowBtwq_eSKY9kE45iTV9tMBL1h6Xsdav8FEsp8cLX8=.818aabff-3ba2-456a-8be2-26f64020a82a@github.com>
 <a_09cb9P1sXZvxMjoBw8KC1B9Ffz9tX36pTOtyY4Hy8=.f67b61ad-1e76-4e6a-aac3-725eec4fa88e@github.com>
Message-ID: <Ti_CnVUu5Pz7zCDL1N3K6V6aYBrEfuVfpbBGVKSEDsQ=.e637efd2-1f59-4049-9f95-01bfb4906e8d@github.com>

On Wed, 16 Sep 2020 18:28:18 GMT, John R Rose <jrose at openjdk.org> wrote:

>> @rose00 Thanks for the suggestion.
>> 
>> With this patch, my goal is to improve the performance of acmp when there's no inline types involved but the compiler
>> can't tell from the static types of the acmp inputs so that legacy code that make no use of inline types is not
>> affected by them. My understanding is that, first of all, we want the new acmp to not cause regressions in non inlined
>> type code. How important is it to optimize acmp (or aaload/aastore) for cases where inline types hidden behind Object
>> are compared (or flattened arrays hidden behind Object[])?  Current logic for an acmp is: if (left == right) {
>>  // equal
>> } else {
>>   if (left == null) {
>>     // not equal
>>   } else  if (left not inline type) {
>>     // not equal
>>   } else if (right == null) {
>>     // not equal
>>   } else if (left.klass != right.klass) {
>>     // not equal
>>   } else {
>>     // substituability test
>>   }
>> }
>> Now if we have profiling for left or right that tells one of them is always null or one them is never an inline type
>> and never null then we only need 2 comparisons, for instance:
>> if (left == right) {
>>   // equal
>> } else {
>>   if (left.right.klass == java.lang.Integer) { // implicit null check
>>     trap;
>>   }
>>  // not equal
>> }
>> 
>> which is a pattern that's a lot friendlier to the compiler.
>
> The simple comparison `left == right` is valid for `acmp` along all paths *except* when `left` and `right` are inlines,
> and *even then* the simple comparison is valid if the two inline types are *distinct*.  Therefore, the only evidence
> that the JIT needs that the S-test was ever needed is if the two types are (a) inlines and (b) identical.  Your profile
> detects (a) but not (b), which means the JIT can't speculate (b).  If you speculate (b) you can use `left == right`
> because any inlines that appear are irrelevant.  (Of course you need additional testing to verify the speculation.
> That's something like `left.klass == right.klass && left.klass.is_inline` or the reverse, which detects (a) and (b).
> It can go to an uncommon trap if the profile claims it's rare, to avoid compiling in a potentially polymorphic
> S-test.)  My overall point here is that `left == right` is a good way to prove, in many cases, that two things are
> identical, and `left != right` is a good heuristic (not proof) that two things are not identical.  The heuristic fails
> only if (a) and (b) are true.  That heuristic seems to be a good target for speculation; perhaps you are aiming at
> other speculations here and I'm barking up a different tree.  For this speculation, I think you would throw an uncommon
> trap you saw (a) and (b), so the complicated S-test path doesn't need to be compiled.  To answer your question, I think
> (but don't know for sure) that inlines masked by `Object` references will be an important source of `acmp` slow paths.
> If the profile indicates that either (a) inlines are not seen in the operands or (b) equal inline types are not seen,
> then the slow S-test can be removed and replaced (at most) by an uncommon trap.  (Idea of the day:  Make an `acmp`
> entry point a hidden/injected virtual method on every object, with a distinct body for each inline object, and
> `this==x` on `jl.Object`.  The body for any given inline class `V` is then `this==x || x instanceof V &&
> V.$MONOMORPHIC_S_TEST(this, (V)x)`.  Then refer the whole problem to our portfolio of devirtualization optimizations.
> That gives us bimorphic calls, etc., for `acmp`.  Maybe that's a better factoring than adding more and more ad hoc
> `acmp` logic.  This idea pairs well with your profile proposal, since it basically treats `acmp` as a hidden virtual
> call.)  HTH

@rose00 Ideally, wouldn't we want to collect a set of:

(left class, right class, count)

so if:

1. left and right are reference types, we compile acmp as a simple pointer comparison and guard that one of left or
right is the profiled class 2. left is a reference type and right an inline type, we compile acmp as a simple pointer
comparison and guard that left is the profiled class 3. left is an inline type and right a reference type, we compile
acmp as a simple pointer comparison and guard that right is the profiled class 4. left and right are inline types, we
can guard that they are of different (resp same) types (or that each is of the corresponding profiled types) and
compile a simple pointer comparison (resp a substitutability test)?

Anyway, at this point, compiled code calls java.lang.invoke.ValueBootstrapMethods::isSubstitutable() for a
substituability test. It doesn't even take advantage of known inline types to dispatch to the right comparison method.
So, profile data makes no difference and we would first need to optimize acmp for known inline types.

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

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


From jrose at openjdk.java.net  Mon Sep 21 19:13:19 2020
From: jrose at openjdk.java.net (John R Rose)
Date: Mon, 21 Sep 2020 19:13:19 GMT
Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode
In-Reply-To: <Ti_CnVUu5Pz7zCDL1N3K6V6aYBrEfuVfpbBGVKSEDsQ=.e637efd2-1f59-4049-9f95-01bfb4906e8d@github.com>
References: <X_4FGySCfz6LGA5i3Ml9-KVAvkYZdliInUqpp2BSt1M=.cf1f2f31-2ed8-48d7-8e9d-3a6fbc8fe0d3@github.com>
 <aQubMHGiubb-12GwOCyRCD5rErvLHzm5x7l7UEe7sDI=.9adc98d5-506a-407a-a23f-4913f068d963@github.com>
 <dowBtwq_eSKY9kE45iTV9tMBL1h6Xsdav8FEsp8cLX8=.818aabff-3ba2-456a-8be2-26f64020a82a@github.com>
 <a_09cb9P1sXZvxMjoBw8KC1B9Ffz9tX36pTOtyY4Hy8=.f67b61ad-1e76-4e6a-aac3-725eec4fa88e@github.com>
 <Ti_CnVUu5Pz7zCDL1N3K6V6aYBrEfuVfpbBGVKSEDsQ=.e637efd2-1f59-4049-9f95-01bfb4906e8d@github.com>
Message-ID: <jnSKKLYnhN9noijdRVR-xOn6siZdXXnHIXEFYdGeDv8=.09c7af6f-12c7-4472-b19b-1c820e645406@github.com>

On Mon, 21 Sep 2020 15:35:46 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> @rose00 Ideally, wouldn't we want to collect a set of:
> 
> (left class, right class, count)
> 
> so if:
> 
> 1. left and right are reference types, we compile acmp as a simple pointer comparison and guard that one of left or
> right is the profiled class

I see, now, that you are hoping for a monomorphic (or nearly monomorphic) left or right argument.  That would allow you
to speculate an exact type for that particular argument, which then simplifies matters.  I agree this is helpful.  If
you can correctly speculate the exact identity of a type, you don't need runtime tests for whether the type is inline
or not.

That said, you *only* need a runtime test for inline types *if* the left and right types are identical.  That's almost
as fast as correctly verifying a single type.

> 2. left is a reference type and right an inline type, we compile acmp as a simple pointer comparison and guard that
> left is the profiled class 3. left is an inline type and right a reference type, we compile acmp as a simple pointer
> comparison and guard that right is the profiled class

Cases 1..3 can be grouped as:

* (1..3) Either of left type or right right can be speculated as a (constant) reference type R.  Guard that type as R and
  finish with pointer comparison.  This is faster than computing *both* types and comparing for equality.  But it is more
  brittle:  It requires one side to be monomorphic.  If the monomorphism guard fails, comparing the two types for
  equality must be done, probably as the immediate next step.

> 4. left and right are inline types, we can guard that they are of different (resp same) types (or that each is of the
> corresponding profiled types) and compile a simple pointer comparison (resp a substitutability test)?

I guess my main contribution here is to suggest that the profile could be more helpful if it would predict whether the
specific condition of inline type equality is frequent or infrequent.  If frequent, then we compile in the S-test.  (If
frequent *and* monomorphic, we guard for the mono-type.  This will eventually help further inline the S-test.)
Otherwise, if infrequent, we guard for type equality (if we can't guard for a mono-type that's a reference) and
uncommon-trap the S-test.

There are several independent factors that can allow us to avoid compiling the S-test (and use an uncommon trap
instead):

A. We can guard on a known reference type, either left or right.  (Monomorphic sites only.)
B. We can guard on *unequal* types.  (Requires loading both types.  Doesn't require monomorphism.  Failure of equality
can quickly fall through to C to profit on equal reference types.) C. We can guard on whether a type is an inline type
or not.  (Requires a dependent load and test from a klass.)

I think those speculations are in order of preference.  To speculate A. we need a 1-element type profile on both sides
of the test, plus statistics on how many outlier events occurred.  That is handled by your design, and covers cases
1..3.  Monomorphism on *both* sides covers part of case 4, but that's going to be rarer than polymorphism on either or
both sides, I think.

Case 4 (guard equal types) is the same as B.  To speculate B. we want a profile on how often types are equal.  That's
not something you have here yet.  To collect it, you could profile klass equality, or (better IMO) profile klass
equality *only* if the klass is *also* an inline (maybe testing equality first, to avoid a dependent load and cache
pollution?).  The interpreter would collect this extra information.

To speculate C. (which is not on your list, and maybe is in the noise) we would need statistics on how often a type (on
either side) is inline.  That's something you can derive from a multi-element profile, in your current design, but only
if the profile doesn't overflow.  I think it's easier to just collect the inline bit separately.

To tie these requirements back to the interpreter profile structure:

A. Requires logging of *reference* types on either side, enough to detect monomorphism.  (Or maybe bi-morphism?
diminishing returns there...) B. Requires logging of *inequality* of *inline* types, enough to warrant an uncommon trap
if inline-equality occurs.  (I don't think unqualified inequality is an interesting thing to profile:  Too rare in
practice; it means a mostly-useless `acmp` test.) C. Requires logging of inline types.  If inline types are very rare,
then we can speculate against them.

This leads me to the following interpreter profile structure:

(left null seen)
{ (left type, frequency), ? }, (miss frequency)  // A left
(right null seen)
{ (right type, frequency), ? }, (miss frequency)  // A right
{ (same inline type, frequency) ? }, (miss frequency)  // B/C left==right && left.inline
(left inline seen)
(right inline seen)

That's three type-lists instead of two, which seems to get unwieldy.  It also suggests that I'm really talking about a
follow-on RFE (which I'm sure has crossed your mind already).

We could simplify this structure and make it more robust as follows:

(left null seen), (right null seen), (same inline seen), (left inline seen), (right inline seen)
{ (type, code, frequency) ? }
// enum code { left, right, same }; in low 2 bits of profile record count
(left miss frequency)
(right miss frequency)
(same inline miss frequency)

The idea is to merge the lists, but keep separate "long tail" miss frequencies.  This makes sense for `acmp` because it
is a symmetric operation, and you only need monomorphism on one side.  Arguably, you just need one array of types (at
least 3) to prove monomorphism for either side, and then you get a slightly smaller profile for the other side.  The
equal-types case (significant only for `acmp`) is a natural extension.

My suggestion is to put most of this aside as an RFE.  But you could consider, right now, merging the two lists, adding
two type codes (for left and right).  Then adding the third type code (same) would be simpler as an RFE.

> Anyway, at this point, compiled code calls java.lang.invoke.ValueBootstrapMethods::isSubstitutable() for a
> substituability test. It doesn't even take advantage of known inline types to dispatch to the right comparison method.
> So, profile data makes no difference and we would first need to optimize acmp for known inline types.

That's a moving target.  Clearly we want to inline the polymorphic S-test and then try to "de-virtualize" it when we
can.  The current code has fast paths for all the cases we have already discussed (A, B, C above), and then uses a
`jl.ClassValue` to dispatch to a handler.  Devirtualizing that dispatch will require (a) type information about the
inline type shared by the two operands, and (b) a way to inline through a constant `ClassValue::get` call (please see
https://bugs.openjdk.java.net/browse/JDK-8238260).

The profile information to (eventually) drive JDK-8238260 will be either side, but it will be most efficiently
collected if it is filtered down to cases where (a) the two sides have the same klass and (b) that klass is an inline.
If that filtered profile is monomorphic (which doesn't require the profile as a whole to be monomorphic) then
JDK-8238260 (or some other ad hoc devirtualization of the S-test) can get a serious win.

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

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


From sadayapalam at openjdk.java.net  Tue Sep 22 05:39:00 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 22 Sep 2020 05:39:00 GMT
Subject: [lworld] Integrated: 8253181: [lworld] Javac fails to properly handle
 inline class files with inner classes
Message-ID: <kwk3dx4Jn8S9vdzOHP-9zwk3LllwsMNl4SHwlPnGkow=.cb5bdb5a-0ed8-4f79-aaa0-b03496af7f6a@github.com>

Javac should not clone and augment inner classes to reference projection type.

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

Commit messages:
 - 8253181: Javac fails to properly handle inline class files with inner classes

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

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


From sadayapalam at openjdk.java.net  Tue Sep 22 05:39:01 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 22 Sep 2020 05:39:01 GMT
Subject: [lworld] Integrated: 8253181: [lworld] Javac fails to properly handle
 inline class files with inner classes
In-Reply-To: <kwk3dx4Jn8S9vdzOHP-9zwk3LllwsMNl4SHwlPnGkow=.cb5bdb5a-0ed8-4f79-aaa0-b03496af7f6a@github.com>
References: <kwk3dx4Jn8S9vdzOHP-9zwk3LllwsMNl4SHwlPnGkow=.cb5bdb5a-0ed8-4f79-aaa0-b03496af7f6a@github.com>
Message-ID: <OU9aejrdGbIf6tC-KeOAN33kZxr-GImqswBgWPVSBo4=.6c915ccd-927a-45ae-b357-77164d8d7182@github.com>

On Tue, 22 Sep 2020 05:27:42 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Javac should not clone and augment inner classes to reference projection type.

This pull request has now been integrated.

Changeset: 9fc3d54b
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/9fc3d54b
Stats:     104 lines in 3 files changed: 0 ins; 103 del; 1 mod

8253181: [lworld] Javac fails to properly handle inline class files with inner classes

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

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


From fparain at openjdk.java.net  Wed Sep 23 15:48:54 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 23 Sep 2020 15:48:54 GMT
Subject: [lworld] RFR: 8253511: [lworld] ClassFileParser does not handle field
 type mismatch
Message-ID: <a9cB8tpZHUsEqHw29-53iSZ913Te1-RzJpEqypS7I6Q=.c006ee43-d875-427c-8375-402c54c262f1@github.com>

Please review this change with replaces an assert with the throwing of an IncompatibleClassChangeError when a
pre-loaded class is not an inline type. This case was correctly handled for static fields, but not for non-static
fields.

Tested with Mach5, tiers 1 to 3.

Thank you,

Fred

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

Commit messages:
 - Fix exception message
 - Replace assert by exception when field type mismatch is detected

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

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


From hseigel at openjdk.java.net  Wed Sep 23 16:04:42 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 23 Sep 2020 16:04:42 GMT
Subject: [lworld] RFR: 8253511: [lworld] ClassFileParser does not handle
 field type mismatch
In-Reply-To: <a9cB8tpZHUsEqHw29-53iSZ913Te1-RzJpEqypS7I6Q=.c006ee43-d875-427c-8375-402c54c262f1@github.com>
References: <a9cB8tpZHUsEqHw29-53iSZ913Te1-RzJpEqypS7I6Q=.c006ee43-d875-427c-8375-402c54c262f1@github.com>
Message-ID: <etU-7ujEhl2Kie6zFlnDCS5YrPA2F3utLczGqfN3_Pw=.7df53fee-6cac-4356-9a82-c5e60f3fdfeb@github.com>

On Wed, 23 Sep 2020 15:42:59 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this change with replaces an assert with the throwing of an IncompatibleClassChangeError when a
> pre-loaded class is not an inline type. This case was correctly handled for static fields, but not for non-static
> fields.  Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

The changes look good!  You could add code to the test's exception handler that looks at err.getMessage() to check that
ICE got thrown for the expected reason.

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

Marked as reviewed by hseigel (Committer).

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


From fparain at openjdk.java.net  Wed Sep 23 17:39:35 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 23 Sep 2020 17:39:35 GMT
Subject: [lworld] RFR: 8253511: [lworld] ClassFileParser does not handle
 field type mismatch [v2]
In-Reply-To: <a9cB8tpZHUsEqHw29-53iSZ913Te1-RzJpEqypS7I6Q=.c006ee43-d875-427c-8375-402c54c262f1@github.com>
References: <a9cB8tpZHUsEqHw29-53iSZ913Te1-RzJpEqypS7I6Q=.c006ee43-d875-427c-8375-402c54c262f1@github.com>
Message-ID: <jX2b270sZQrqHmeups-Q5omD6hYwXveOM2WvJ66F_qE=.2eca3fb7-a99c-4453-84a8-f6e530ac19ef@github.com>

> Please review this change with replaces an assert with the throwing of an IncompatibleClassChangeError when a
> pre-loaded class is not an inline type. This case was correctly handled for static fields, but not for non-static
> fields.  Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

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

  Verify ICE message in unit test

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/195/files
  - new: https://git.openjdk.java.net/valhalla/pull/195/files/646b78b4..46580ccc

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

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

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


From hseigel at openjdk.java.net  Wed Sep 23 17:39:35 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 23 Sep 2020 17:39:35 GMT
Subject: [lworld] RFR: 8253511: [lworld] ClassFileParser does not handle
 field type mismatch [v2]
In-Reply-To: <jX2b270sZQrqHmeups-Q5omD6hYwXveOM2WvJ66F_qE=.2eca3fb7-a99c-4453-84a8-f6e530ac19ef@github.com>
References: <a9cB8tpZHUsEqHw29-53iSZ913Te1-RzJpEqypS7I6Q=.c006ee43-d875-427c-8375-402c54c262f1@github.com>
 <jX2b270sZQrqHmeups-Q5omD6hYwXveOM2WvJ66F_qE=.2eca3fb7-a99c-4453-84a8-f6e530ac19ef@github.com>
Message-ID: <hsFLXI_VaRxBd3JQnJ7w3_KWX7c1zncSHEF2jiX4rV8=.565c2809-36cf-43cc-bc86-4a28a7611476@github.com>

On Wed, 23 Sep 2020 17:36:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change with replaces an assert with the throwing of an IncompatibleClassChangeError when a
>> pre-loaded class is not an inline type. This case was correctly handled for static fields, but not for non-static
>> fields.  Tested with Mach5, tiers 1 to 3.
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Verify ICE message in unit test

Looks good!  Thanks!

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

Marked as reviewed by hseigel (Committer).

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


From fparain at openjdk.java.net  Wed Sep 23 17:39:36 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 23 Sep 2020 17:39:36 GMT
Subject: [lworld] RFR: 8253511: [lworld] ClassFileParser does not handle
 field type mismatch [v2]
In-Reply-To: <etU-7ujEhl2Kie6zFlnDCS5YrPA2F3utLczGqfN3_Pw=.7df53fee-6cac-4356-9a82-c5e60f3fdfeb@github.com>
References: <a9cB8tpZHUsEqHw29-53iSZ913Te1-RzJpEqypS7I6Q=.c006ee43-d875-427c-8375-402c54c262f1@github.com>
 <etU-7ujEhl2Kie6zFlnDCS5YrPA2F3utLczGqfN3_Pw=.7df53fee-6cac-4356-9a82-c5e60f3fdfeb@github.com>
Message-ID: <epJC6CsmVupPDaou_ajPJD4aP_rabu6o6TgtbxAcmbA=.e2279427-6fa3-47bc-b80c-bc8c8576d5c1@github.com>

On Wed, 23 Sep 2020 16:01:50 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Verify ICE message in unit test
>
> The changes look good!  You could add code to the test's exception handler that looks at err.getMessage() to check that
> ICE got thrown for the expected reason.

Harold,

Thank you for the review, I've updated the test, checking that the error message is the expected one.

Fred

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

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


From fparain at openjdk.java.net  Wed Sep 23 18:42:56 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 23 Sep 2020 18:42:56 GMT
Subject: [lworld] Integrated: 8253511: [lworld] ClassFileParser does not
 handle field type mismatch
In-Reply-To: <a9cB8tpZHUsEqHw29-53iSZ913Te1-RzJpEqypS7I6Q=.c006ee43-d875-427c-8375-402c54c262f1@github.com>
References: <a9cB8tpZHUsEqHw29-53iSZ913Te1-RzJpEqypS7I6Q=.c006ee43-d875-427c-8375-402c54c262f1@github.com>
Message-ID: <q1-A2-3JMV5Tg7qkxbGVcOMYsUQF3UcKIo7VuUCUdO4=.71943045-73e9-42c6-bf5c-78220460eba1@github.com>

On Wed, 23 Sep 2020 15:42:59 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this change with replaces an assert with the throwing of an IncompatibleClassChangeError when a
> pre-loaded class is not an inline type. This case was correctly handled for static fields, but not for non-static
> fields.  Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 4a26a176
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/4a26a176
Stats:     106 lines in 3 files changed: 105 ins; 0 del; 1 mod

8253511: [lworld] ClassFileParser does not handle field type mismatch

Reviewed-by: hseigel

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

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


From dsimms at openjdk.java.net  Thu Sep 24 09:22:36 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 24 Sep 2020 09:22:36 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <AeY5hiGsZ6xGE_jskSPxgtfdgZq2CIwz0kuSYykg6zU=.3b138813-ac4b-4529-942e-c7dc91cc22b7@github.com>

Merge tag 'jdk-16+17'

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

Commit messages:
 - Treat flatArrayKlass as object in G1's copy to survivor space
 - Tag order matters
 - No longer assert correct decode
 - Merge tag 'jdk-16+17' into lworld_merge_jdk_16_17
 - 8253397: Ensure LogTag types are sorted
 - 8253457: Remove unimplemented register stack functions
 - 8253516: ZGC: Remove card table functions
 - 8252696: Loop unswitching may cause out of bound array load to be executed
 - 8253241: Update comment on java_suspend_self_with_safepoint_check()
 - 8253349: Remove unimplemented SharedRuntime::native_method_throw_unsupported_operation_exception_entry
 - ... and 77 more: https://git.openjdk.java.net/valhalla/compare/4a26a176...004797e6

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

Changes: https://git.openjdk.java.net/valhalla/pull/196/files
  Stats: 11513 lines in 360 files changed: 5921 ins; 4547 del; 1045 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/196.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/196/head:pull/196

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


From dsimms at openjdk.java.net  Thu Sep 24 10:55:11 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 24 Sep 2020 10:55:11 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <AeY5hiGsZ6xGE_jskSPxgtfdgZq2CIwz0kuSYykg6zU=.3b138813-ac4b-4529-942e-c7dc91cc22b7@github.com>
References: <AeY5hiGsZ6xGE_jskSPxgtfdgZq2CIwz0kuSYykg6zU=.3b138813-ac4b-4529-942e-c7dc91cc22b7@github.com>
Message-ID: <efIr7QmqqOjKABc0aaxQC3tYGpXkYM77iFgJDGv8bsM=.cd074f0a-a1f1-4559-b31f-662bc0149412@github.com>

On Thu, 24 Sep 2020 09:11:40 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+17'

This pull request has now been integrated.

Changeset: 2989eaaa
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/2989eaaa
Stats:     11513 lines in 360 files changed: 5921 ins; 4547 del; 1045 mod

Merge jdk

Merge tag 'jdk-16+17'

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

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


From thartmann at openjdk.java.net  Thu Sep 24 11:32:26 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 24 Sep 2020 11:32:26 GMT
Subject: [lworld] RFR: 8253592: [lworld] C2: Additional fixes for handling
 empty inline types
Message-ID: <uU4W9DxoL4YKsJOzNDh5x61e5t_Q1aJ_F-0eGQIP3qQ=.989fa3b5-7a06-42d1-82f0-02f8457f737a@github.com>

While working on JDK-8253416, I found more issues with handling of empty inline types in C2:
- Compile::build_start_state assumes that all inline type arguments are scalarized if has_scalarized_args() is true but
  one of the arguments could be non-scalarized (for example, if it's an empty inline type).
- Loads/stores from/to inline type fields should be removed. Refactoring the related code also fixes an issue where alias
  analysis gets confused when looking at flattened fields of empty inline types.

Unrelated fixes:
- Handling of unexpected inline/non-inline klasses in _new/_defaultvalue.
- Missing @DontCompile statements in some tests

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

Commit messages:
 - 8253592: [lworld] C2: Additional fixes for handling empty inline types

Changes: https://git.openjdk.java.net/valhalla/pull/197/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=197&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253592
  Stats: 206 lines in 10 files changed: 119 ins; 50 del; 37 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/197.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/197/head:pull/197

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


From thartmann at openjdk.java.net  Thu Sep 24 12:48:14 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 24 Sep 2020 12:48:14 GMT
Subject: [lworld] RFR: 8253592: [lworld] C2: Additional fixes for handling
 empty inline types [v2]
In-Reply-To: <uU4W9DxoL4YKsJOzNDh5x61e5t_Q1aJ_F-0eGQIP3qQ=.989fa3b5-7a06-42d1-82f0-02f8457f737a@github.com>
References: <uU4W9DxoL4YKsJOzNDh5x61e5t_Q1aJ_F-0eGQIP3qQ=.989fa3b5-7a06-42d1-82f0-02f8457f737a@github.com>
Message-ID: <k1cxM1ILL3zL8xa6CWk1Busue_jFD-eYH5aoQFVVZPo=.8194803b-ffb7-444d-b534-410a21a8f9da@github.com>

> While working on JDK-8253416, I found more issues with handling of empty inline types in C2:
> - Compile::build_start_state assumes that all inline type arguments are scalarized if has_scalarized_args() is true but
>   one of the arguments could be non-scalarized (for example, if it's an empty inline type).
> - Loads/stores from/to inline type fields should be removed. Refactoring the related code also fixes an issue where alias
>   analysis gets confused when looking at flattened fields of empty inline types.
> 
> Unrelated fixes:
> - Handling of unexpected inline/non-inline klasses in _new/_defaultvalue.
> - Missing @DontCompile statements in some tests

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

  Disabling some tests until JDK-8253416 is fixed

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/197/files
  - new: https://git.openjdk.java.net/valhalla/pull/197/files/ea4d32d4..4c32cea6

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

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

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


From thartmann at openjdk.java.net  Thu Sep 24 14:07:01 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 24 Sep 2020 14:07:01 GMT
Subject: [lworld] Integrated: 8253592: [lworld] C2: Additional fixes for
 handling empty inline types
In-Reply-To: <uU4W9DxoL4YKsJOzNDh5x61e5t_Q1aJ_F-0eGQIP3qQ=.989fa3b5-7a06-42d1-82f0-02f8457f737a@github.com>
References: <uU4W9DxoL4YKsJOzNDh5x61e5t_Q1aJ_F-0eGQIP3qQ=.989fa3b5-7a06-42d1-82f0-02f8457f737a@github.com>
Message-ID: <l7pnlUTOeqBY_KE0jcg6KORIz65xbqBDg4PqApQ8ccw=.4141834b-0567-404e-b05a-7ee92f5aff70@github.com>

On Thu, 24 Sep 2020 11:26:13 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> While working on JDK-8253416, I found more issues with handling of empty inline types in C2:
> - Compile::build_start_state assumes that all inline type arguments are scalarized if has_scalarized_args() is true but
>   one of the arguments could be non-scalarized (for example, if it's an empty inline type).
> - Loads/stores from/to inline type fields should be removed. Refactoring the related code also fixes an issue where alias
>   analysis gets confused when looking at flattened fields of empty inline types.
> 
> Unrelated fixes:
> - Handling of unexpected inline/non-inline klasses in _new/_defaultvalue.
> - Missing @DontCompile statements in some tests

This pull request has now been integrated.

Changeset: 33bdce23
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/33bdce23
Stats:     209 lines in 10 files changed: 122 ins; 50 del; 37 mod

8253592: [lworld] C2: Additional fixes for handling empty inline types

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

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


From thartmann at openjdk.java.net  Thu Sep 24 14:15:35 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 24 Sep 2020 14:15:35 GMT
Subject: [lworld] RFR: 8253416: [lworld] C1: incorrect nestmate access to
 flattened field if nest-host is not loaded
Message-ID: <Uly8VEY2zCBDO7nEH7sCC38HjcAU7eS7B1lCNrbYC_Y=.d4c7d4c4-1323-4390-8f57-f2c219a49ef7@github.com>

C1 incorrectly assumes that a nestmate field access is not flat if the nest-host is not loaded.

We are creating the ciField instance for a field in the nest-host via:
`ciField::ciField -> Reflection::verify_member_access -> InstanceKlass::has_nestmate_access_to ->
InstanceKlass::nest_host` Resolving the nest host then requires class loading which is not possible from the C1
compiler thread and as a result we end up with partial field information (is_flattened is always false). The code in
LIRGenerator::flattened_field_load_prolog then assumes that if !field->is_flattened(), the field is indeed not
flattened. However, we can only rely on that information if !needs_patching.

I've completely re-wrote and simplified the complex logic in LIRGenerator::flattened_field_load_prolog and added
asserts/checks to make sure we are not attempting to patch flattened inline type field accesses (that functionality
could be added though but it's not easy).

This patch also includes the following unrelated changes:
- The "new" bytecode needs to throw an exception on inline klasses (the klass might be unloaded). The fix makes sure we
  always take the slow path to "new_instance_no_inline" in that case.
- The "defaultvalue" bytecode needs to throw an exception on non-inline klasses. We simply deoptimize in that case.
- Load/stores from/to fields of an empty inline type should be removed.
- Some refactoring and new asserts.

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

Commit messages:
 - 8253416: [lworld] C1: incorrect nestmate access to flattened field if nest-host is not loaded

Changes: https://git.openjdk.java.net/valhalla/pull/198/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=198&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253416
  Stats: 1135 lines in 15 files changed: 878 ins; 120 del; 137 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/198.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/198/head:pull/198

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


From fparain at openjdk.java.net  Thu Sep 24 20:48:44 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 24 Sep 2020 20:48:44 GMT
Subject: [lworld] RFR: 8253416: [lworld] C1: incorrect nestmate access to
 flattened field if nest-host is not loaded
In-Reply-To: <Uly8VEY2zCBDO7nEH7sCC38HjcAU7eS7B1lCNrbYC_Y=.d4c7d4c4-1323-4390-8f57-f2c219a49ef7@github.com>
References: <Uly8VEY2zCBDO7nEH7sCC38HjcAU7eS7B1lCNrbYC_Y=.d4c7d4c4-1323-4390-8f57-f2c219a49ef7@github.com>
Message-ID: <bKgi4f4vIBEt7-afx7rh2wWRw-x3Wxry7PLc2qnxvuc=.6e02671d-76c3-4dc6-a486-45e7735b0685@github.com>

On Thu, 24 Sep 2020 14:08:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C1 incorrectly assumes that a nestmate field access is not flat if the nest-host is not loaded.
> 
> We are creating the ciField instance for a field in the nest-host via:
> `ciField::ciField -> Reflection::verify_member_access -> InstanceKlass::has_nestmate_access_to ->
> InstanceKlass::nest_host` Resolving the nest host then requires class loading which is not possible from the C1
> compiler thread and as a result we end up with partial field information (is_flattened is always false). The code in
> LIRGenerator::flattened_field_load_prolog then assumes that if !field->is_flattened(), the field is indeed not
> flattened. However, we can only rely on that information if !needs_patching.  I've completely re-wrote and simplified
> the complex logic in LIRGenerator::flattened_field_load_prolog and added asserts/checks to make sure we are not
> attempting to patch flattened inline type field accesses (that functionality could be added though but it's not easy).
> This patch also includes the following unrelated changes:
> - The "new" bytecode needs to throw an exception on inline klasses (the klass might be unloaded). The fix makes sure we
>   always take the slow path to "new_instance_no_inline" in that case.
> - The "defaultvalue" bytecode needs to throw an exception on non-inline klasses. We simply deoptimize in that case.
> - Load/stores from/to fields of an empty inline type should be removed.
> - Some refactoring and new asserts.

Tobias,

I'm still reviewing the code, but here are already two comments:

1 - the empty inline type optimization can be applied to load_indexed() and store_indexed() too.
2 - regarding the assert added at the beginning of copy_inline_content() (needs_patching must be false), it seems to me
that the method can still be called with a needs_patching argument being true from the GraphBuilder::withfield()
method. In the withfield() method, the needs_patching value is computed with this code:
        const bool needs_patching = !holder->is_loaded() ||
                              !field_modify->will_link(method(), Bytecodes::_withfield) ||
                              PatchALot;
And the value is passed as is to the copy_inline_content() method without consideration if the field being processed is
flattened or not.

Regards,

Fred

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

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


From mark.reinhold at oracle.com  Thu Sep 24 21:28:06 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 24 Sep 2020 14:28:06 -0700 (PDT)
Subject: New candidate JEP: 390: Warnings for Value-Based Classes
Message-ID: <20200924212806.8CD983C2F7A@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/390

- Mark


From thartmann at openjdk.java.net  Fri Sep 25 06:27:07 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 25 Sep 2020 06:27:07 GMT
Subject: [lworld] RFR: 8253416: [lworld] C1: incorrect nestmate access to
 flattened field if nest-host is not loaded
In-Reply-To: <bKgi4f4vIBEt7-afx7rh2wWRw-x3Wxry7PLc2qnxvuc=.6e02671d-76c3-4dc6-a486-45e7735b0685@github.com>
References: <Uly8VEY2zCBDO7nEH7sCC38HjcAU7eS7B1lCNrbYC_Y=.d4c7d4c4-1323-4390-8f57-f2c219a49ef7@github.com>
 <bKgi4f4vIBEt7-afx7rh2wWRw-x3Wxry7PLc2qnxvuc=.6e02671d-76c3-4dc6-a486-45e7735b0685@github.com>
Message-ID: <3eE1sDB3LiC0idTe0AEEocHKG52AFZRF_XgHfUosiXI=.a8db6d7f-8dc1-4fbd-915c-dc4ce2388f73@github.com>

On Thu, 24 Sep 2020 20:45:54 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> C1 incorrectly assumes that a nestmate field access is not flat if the nest-host is not loaded.
>> 
>> We are creating the ciField instance for a field in the nest-host via:
>> `ciField::ciField -> Reflection::verify_member_access -> InstanceKlass::has_nestmate_access_to ->
>> InstanceKlass::nest_host` Resolving the nest host then requires class loading which is not possible from the C1
>> compiler thread and as a result we end up with partial field information (is_flattened is always false). The code in
>> LIRGenerator::flattened_field_load_prolog then assumes that if !field->is_flattened(), the field is indeed not
>> flattened. However, we can only rely on that information if !needs_patching.  I've completely re-wrote and simplified
>> the complex logic in LIRGenerator::flattened_field_load_prolog and added asserts/checks to make sure we are not
>> attempting to patch flattened inline type field accesses (that functionality could be added though but it's not easy).
>> This patch also includes the following unrelated changes:
>> - The "new" bytecode needs to throw an exception on inline klasses (the klass might be unloaded). The fix makes sure we
>>   always take the slow path to "new_instance_no_inline" in that case.
>> - The "defaultvalue" bytecode needs to throw an exception on non-inline klasses. We simply deoptimize in that case.
>> - Load/stores from/to fields of an empty inline type should be removed.
>> - Some refactoring and new asserts.
>
> Tobias,
> 
> I'm still reviewing the code, but here are already two comments:
> 
> 1 - the empty inline type optimization can be applied to load_indexed() and store_indexed() too.
> 2 - regarding the assert added at the beginning of copy_inline_content() (needs_patching must be false), it seems to me
> that the method can still be called with a needs_patching argument being true from the GraphBuilder::withfield()
> method. In the withfield() method, the needs_patching value is computed with this code:
>         const bool needs_patching = !holder->is_loaded() ||
>                               !field_modify->will_link(method(), Bytecodes::_withfield) ||
>                               PatchALot;
> And the value is passed as is to the copy_inline_content() method without consideration if the field being processed is
> flattened or not.
> Regards,
> 
> Fred

Hi Fred,

thanks for the quick review!

> 1 - the empty inline type optimization can be applied to load_indexed() and store_indexed() too.

Yes, there are even more optimization opportunities and I'll address these with
[JDK-8248220](https://bugs.openjdk.java.net/browse/JDK-8248220). I've only added the empty field load/store removal
here for correctness because otherwise we miss adding a null check (see re-enabled `TestLWorld::test122` and
`test123`). The "Empty inline type access should be removed" assert in `GraphBuilder::copy_inline_content` would now
catch this.

> 2 - regarding the assert added at the beginning of copy_inline_content() (needs_patching must be false), it seems to me
> that the method can still be called with a needs_patching argument being true from the GraphBuilder::withfield() method.

If `needs_patching` is true, we emit a `WithField` node that triggers deoptimization, see
[here](https://github.com/openjdk/valhalla/pull/198/files#diff-46a0868648fa7bf1ee142760243a6d86R2049). That code will
be re-visited by [JDK-8228634](https://bugs.openjdk.java.net/browse/JDK-8228634).

Thanks,
Tobias

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

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


From fparain at openjdk.java.net  Fri Sep 25 13:12:14 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 25 Sep 2020 13:12:14 GMT
Subject: [lworld] RFR: 8253416: [lworld] C1: incorrect nestmate access to
 flattened field if nest-host is not loaded
In-Reply-To: <Uly8VEY2zCBDO7nEH7sCC38HjcAU7eS7B1lCNrbYC_Y=.d4c7d4c4-1323-4390-8f57-f2c219a49ef7@github.com>
References: <Uly8VEY2zCBDO7nEH7sCC38HjcAU7eS7B1lCNrbYC_Y=.d4c7d4c4-1323-4390-8f57-f2c219a49ef7@github.com>
Message-ID: <vEg03T-Qwh0EqEpYQTsrIr4o9SyQlvqTjcIuHIHP1xM=.9e453876-9db9-48bb-b380-448641bf7fd7@github.com>

On Thu, 24 Sep 2020 14:08:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C1 incorrectly assumes that a nestmate field access is not flat if the nest-host is not loaded.
> 
> We are creating the ciField instance for a field in the nest-host via:
> `ciField::ciField -> Reflection::verify_member_access -> InstanceKlass::has_nestmate_access_to ->
> InstanceKlass::nest_host` Resolving the nest host then requires class loading which is not possible from the C1
> compiler thread and as a result we end up with partial field information (is_flattened is always false). The code in
> LIRGenerator::flattened_field_load_prolog then assumes that if !field->is_flattened(), the field is indeed not
> flattened. However, we can only rely on that information if !needs_patching.  I've completely re-wrote and simplified
> the complex logic in LIRGenerator::flattened_field_load_prolog and added asserts/checks to make sure we are not
> attempting to patch flattened inline type field accesses (that functionality could be added though but it's not easy).
> This patch also includes the following unrelated changes:
> - The "new" bytecode needs to throw an exception on inline klasses (the klass might be unloaded). The fix makes sure we
>   always take the slow path to "new_instance_no_inline" in that case.
> - The "defaultvalue" bytecode needs to throw an exception on non-inline klasses. We simply deoptimize in that case.
> - Load/stores from/to fields of an empty inline type should be removed.
> - Some refactoring and new asserts.

Tobias,

Thank you for the explanation on the needs_patching flag and the Withfield node.
So, did you keep the needs_patching argument in the copy_inline_content()  method only for verification purpose?

Overall, changes look good to me.

Fred

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

Marked as reviewed by fparain (Committer).

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


From thartmann at openjdk.java.net  Fri Sep 25 13:28:13 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 25 Sep 2020 13:28:13 GMT
Subject: [lworld] RFR: 8253416: [lworld] C1: incorrect nestmate access to
 flattened field if nest-host is not loaded
In-Reply-To: <vEg03T-Qwh0EqEpYQTsrIr4o9SyQlvqTjcIuHIHP1xM=.9e453876-9db9-48bb-b380-448641bf7fd7@github.com>
References: <Uly8VEY2zCBDO7nEH7sCC38HjcAU7eS7B1lCNrbYC_Y=.d4c7d4c4-1323-4390-8f57-f2c219a49ef7@github.com>
 <vEg03T-Qwh0EqEpYQTsrIr4o9SyQlvqTjcIuHIHP1xM=.9e453876-9db9-48bb-b380-448641bf7fd7@github.com>
Message-ID: <uXv6aRhxiQcjgl379RwBD3AHzNkIPSR5z38Obj-VTMQ=.70febced-9d33-4e99-8563-6333f7ea3eca@github.com>

On Fri, 25 Sep 2020 13:09:20 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> C1 incorrectly assumes that a nestmate field access is not flat if the nest-host is not loaded.
>> 
>> We are creating the ciField instance for a field in the nest-host via:
>> `ciField::ciField -> Reflection::verify_member_access -> InstanceKlass::has_nestmate_access_to ->
>> InstanceKlass::nest_host` Resolving the nest host then requires class loading which is not possible from the C1
>> compiler thread and as a result we end up with partial field information (is_flattened is always false). The code in
>> LIRGenerator::flattened_field_load_prolog then assumes that if !field->is_flattened(), the field is indeed not
>> flattened. However, we can only rely on that information if !needs_patching.  I've completely re-wrote and simplified
>> the complex logic in LIRGenerator::flattened_field_load_prolog and added asserts/checks to make sure we are not
>> attempting to patch flattened inline type field accesses (that functionality could be added though but it's not easy).
>> This patch also includes the following unrelated changes:
>> - The "new" bytecode needs to throw an exception on inline klasses (the klass might be unloaded). The fix makes sure we
>>   always take the slow path to "new_instance_no_inline" in that case.
>> - The "defaultvalue" bytecode needs to throw an exception on non-inline klasses. We simply deoptimize in that case.
>> - Load/stores from/to fields of an empty inline type should be removed.
>> - Some refactoring and new asserts.
>
> Tobias,
> 
> Thank you for the explanation on the needs_patching flag and the Withfield node.
> So, did you keep the needs_patching argument in the copy_inline_content()  method only for verification purpose?
> 
> Overall, changes look good to me.
> 
> Fred

Thanks a lot for the review!

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

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


From thartmann at openjdk.java.net  Fri Sep 25 13:31:06 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 25 Sep 2020 13:31:06 GMT
Subject: [lworld] RFR: 8253416: [lworld] C1: incorrect nestmate access to
 flattened field if nest-host is not loaded
In-Reply-To: <vEg03T-Qwh0EqEpYQTsrIr4o9SyQlvqTjcIuHIHP1xM=.9e453876-9db9-48bb-b380-448641bf7fd7@github.com>
References: <Uly8VEY2zCBDO7nEH7sCC38HjcAU7eS7B1lCNrbYC_Y=.d4c7d4c4-1323-4390-8f57-f2c219a49ef7@github.com>
 <vEg03T-Qwh0EqEpYQTsrIr4o9SyQlvqTjcIuHIHP1xM=.9e453876-9db9-48bb-b380-448641bf7fd7@github.com>
Message-ID: <iKV4-my0ZOKb7U7nI-Zi05NBNj1UemMAlmGqVlp_FLI=.05bb04f0-08a4-4577-8740-dba0768c9341@github.com>

On Fri, 25 Sep 2020 13:09:20 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> So, did you keep the needs_patching argument in the copy_inline_content() method only for verification purpose?

Yes, but we could also move the assert into the caller. What do you prefer?

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

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


From fparain at openjdk.java.net  Fri Sep 25 14:20:17 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 25 Sep 2020 14:20:17 GMT
Subject: [lworld] RFR: 8253416: [lworld] C1: incorrect nestmate access to
 flattened field if nest-host is not loaded
In-Reply-To: <iKV4-my0ZOKb7U7nI-Zi05NBNj1UemMAlmGqVlp_FLI=.05bb04f0-08a4-4577-8740-dba0768c9341@github.com>
References: <Uly8VEY2zCBDO7nEH7sCC38HjcAU7eS7B1lCNrbYC_Y=.d4c7d4c4-1323-4390-8f57-f2c219a49ef7@github.com>
 <vEg03T-Qwh0EqEpYQTsrIr4o9SyQlvqTjcIuHIHP1xM=.9e453876-9db9-48bb-b380-448641bf7fd7@github.com>
 <iKV4-my0ZOKb7U7nI-Zi05NBNj1UemMAlmGqVlp_FLI=.05bb04f0-08a4-4577-8740-dba0768c9341@github.com>
Message-ID: <mizhkHard4EhYCWmNarXQ5QQW9nyQW6O7LRgjkHH_a0=.71bf7866-c186-442b-a182-220b8bf9e6ab@github.com>

On Fri, 25 Sep 2020 13:27:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Tobias,
>> 
>> Thank you for the explanation on the needs_patching flag and the Withfield node.
>> So, did you keep the needs_patching argument in the copy_inline_content()  method only for verification purpose?
>> 
>> Overall, changes look good to me.
>> 
>> Fred
>
>> So, did you keep the needs_patching argument in the copy_inline_content() method only for verification purpose?
> 
> Yes, but we could also move the assert into the caller. What do you prefer?

I'm fine with both approaches (assert in the caller or in copy_inline_content()), just pick the solution you think is
the safer (I don't think it makes a lot of difference from a performance point of view).

Fred

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

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


From roland at openjdk.java.net  Fri Sep 25 14:27:04 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 25 Sep 2020 14:27:04 GMT
Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode
In-Reply-To: <jnSKKLYnhN9noijdRVR-xOn6siZdXXnHIXEFYdGeDv8=.09c7af6f-12c7-4472-b19b-1c820e645406@github.com>
References: <X_4FGySCfz6LGA5i3Ml9-KVAvkYZdliInUqpp2BSt1M=.cf1f2f31-2ed8-48d7-8e9d-3a6fbc8fe0d3@github.com>
 <aQubMHGiubb-12GwOCyRCD5rErvLHzm5x7l7UEe7sDI=.9adc98d5-506a-407a-a23f-4913f068d963@github.com>
 <dowBtwq_eSKY9kE45iTV9tMBL1h6Xsdav8FEsp8cLX8=.818aabff-3ba2-456a-8be2-26f64020a82a@github.com>
 <a_09cb9P1sXZvxMjoBw8KC1B9Ffz9tX36pTOtyY4Hy8=.f67b61ad-1e76-4e6a-aac3-725eec4fa88e@github.com>
 <Ti_CnVUu5Pz7zCDL1N3K6V6aYBrEfuVfpbBGVKSEDsQ=.e637efd2-1f59-4049-9f95-01bfb4906e8d@github.com>
 <jnSKKLYnhN9noijdRVR-xOn6siZdXXnHIXEFYdGeDv8=.09c7af6f-12c7-4472-b19b-1c820e645406@github.com>
Message-ID: <cNp4EVL4GVTYujV6XNMExYL6C6zBbnsiNk0F0KRpOKI=.6f92c80d-f00d-484c-a3a8-74fa39990897@github.com>

On Mon, 21 Sep 2020 19:10:21 GMT, John R Rose <jrose at openjdk.org> wrote:

>> @rose00 Ideally, wouldn't we want to collect a set of:
>> 
>> (left class, right class, count)
>> 
>> so if:
>> 
>> 1. left and right are reference types, we compile acmp as a simple pointer comparison and guard that one of left or
>> right is the profiled class 2. left is a reference type and right an inline type, we compile acmp as a simple pointer
>> comparison and guard that left is the profiled class 3. left is an inline type and right a reference type, we compile
>> acmp as a simple pointer comparison and guard that right is the profiled class 4. left and right are inline types, we
>> can guard that they are of different (resp same) types (or that each is of the corresponding profiled types) and
>> compile a simple pointer comparison (resp a substitutability test)?  Anyway, at this point, compiled code calls
>> java.lang.invoke.ValueBootstrapMethods::isSubstitutable() for a substituability test. It doesn't even take advantage of
>> known inline types to dispatch to the right comparison method. So, profile data makes no difference and we would first
>> need to optimize acmp for known inline types.
>
>> @rose00 Ideally, wouldn't we want to collect a set of:
>> 
>> (left class, right class, count)
>> 
>> so if:
>> 
>> 1. left and right are reference types, we compile acmp as a simple pointer comparison and guard that one of left or
>> right is the profiled class
> 
> I see, now, that you are hoping for a monomorphic (or nearly monomorphic) left or right argument.  That would allow you
> to speculate an exact type for that particular argument, which then simplifies matters.  I agree this is helpful.  If
> you can correctly speculate the exact identity of a type, you don't need runtime tests for whether the type is inline
> or not.  That said, you *only* need a runtime test for inline types *if* the left and right types are identical.
> That's almost as fast as correctly verifying a single type.
>> 2. left is a reference type and right an inline type, we compile acmp as a simple pointer comparison and guard that
>> left is the profiled class 3. left is an inline type and right a reference type, we compile acmp as a simple pointer
>> comparison and guard that right is the profiled class
> 
> Cases 1..3 can be grouped as:
> 
> * (1..3) Either of left type or right right can be speculated as a (constant) reference type R.  Guard that type as R and
>   finish with pointer comparison.  This is faster than computing *both* types and comparing for equality.  But it is more
>   brittle:  It requires one side to be monomorphic.  If the monomorphism guard fails, comparing the two types for
>   equality must be done, probably as the immediate next step.
> 
>> 4. left and right are inline types, we can guard that they are of different (resp same) types (or that each is of the
>> corresponding profiled types) and compile a simple pointer comparison (resp a substitutability test)?
> 
> I guess my main contribution here is to suggest that the profile could be more helpful if it would predict whether the
> specific condition of inline type equality is frequent or infrequent.  If frequent, then we compile in the S-test.  (If
> frequent *and* monomorphic, we guard for the mono-type.  This will eventually help further inline the S-test.)
> Otherwise, if infrequent, we guard for type equality (if we can't guard for a mono-type that's a reference) and
> uncommon-trap the S-test.  There are several independent factors that can allow us to avoid compiling the S-test (and
> use an uncommon trap instead):  A. We can guard on a known reference type, either left or right.  (Monomorphic sites
> only.) B. We can guard on *unequal* types.  (Requires loading both types.  Doesn't require monomorphism.  Failure of
> equality can quickly fall through to C to profit on equal reference types.) C. We can guard on whether a type is an
> inline type or not.  (Requires a dependent load and test from a klass.)  I think those speculations are in order of
> preference.  To speculate A. we need a 1-element type profile on both sides of the test, plus statistics on how many
> outlier events occurred.  That is handled by your design, and covers cases 1..3.  Monomorphism on *both* sides covers
> part of case 4, but that's going to be rarer than polymorphism on either or both sides, I think.  Case 4 (guard equal
> types) is the same as B.  To speculate B. we want a profile on how often types are equal.  That's not something you
> have here yet.  To collect it, you could profile klass equality, or (better IMO) profile klass equality *only* if the
> klass is *also* an inline (maybe testing equality first, to avoid a dependent load and cache pollution?).  The
> interpreter would collect this extra information.  To speculate C. (which is not on your list, and maybe is in the
> noise) we would need statistics on how often a type (on either side) is inline.  That's something you can derive from a
> multi-element profile, in your current design, but only if the profile doesn't overflow.  I think it's easier to just
> collect the inline bit separately.  To tie these requirements back to the interpreter profile structure:  A. Requires
> logging of *reference* types on either side, enough to detect monomorphism.  (Or maybe bi-morphism?  diminishing
> returns there...) B. Requires logging of *inequality* of *inline* types, enough to warrant an uncommon trap if
> inline-equality occurs.  (I don't think unqualified inequality is an interesting thing to profile:  Too rare in
> practice; it means a mostly-useless `acmp` test.) C. Requires logging of inline types.  If inline types are very rare,
> then we can speculate against them.  This leads me to the following interpreter profile structure:  (left null seen) {
> (left type, frequency), ? }, (miss frequency)  // A left (right null seen)
> { (right type, frequency), ? }, (miss frequency)  // A right
> { (same inline type, frequency) ? }, (miss frequency)  // B/C left==right && left.inline
> (left inline seen)
> (right inline seen)
> 
> That's three type-lists instead of two, which seems to get unwieldy.  It also suggests that I'm really talking about a
> follow-on RFE (which I'm sure has crossed your mind already).
> We could simplify this structure and make it more robust as follows:
> 
> (left null seen), (right null seen), (same inline seen), (left inline seen), (right inline seen)
> { (type, code, frequency) ? }
> // enum code { left, right, same }; in low 2 bits of profile record count
> (left miss frequency)
> (right miss frequency)
> (same inline miss frequency)
> 
> The idea is to merge the lists, but keep separate "long tail" miss frequencies.  This makes sense for `acmp` because it
> is a symmetric operation, and you only need monomorphism on one side.  Arguably, you just need one array of types (at
> least 3) to prove monomorphism for either side, and then you get a slightly smaller profile for the other side.  The
> equal-types case (significant only for `acmp`) is a natural extension.  My suggestion is to put most of this aside as
> an RFE.  But you could consider, right now, merging the two lists, adding two type codes (for left and right).  Then
> adding the third type code (same) would be simpler as an RFE.
>> Anyway, at this point, compiled code calls java.lang.invoke.ValueBootstrapMethods::isSubstitutable() for a
>> substituability test. It doesn't even take advantage of known inline types to dispatch to the right comparison method.
>> So, profile data makes no difference and we would first need to optimize acmp for known inline types.
> 
> That's a moving target.  Clearly we want to inline the polymorphic S-test and then try to "de-virtualize" it when we
> can.  The current code has fast paths for all the cases we have already discussed (A, B, C above), and then uses a
> `jl.ClassValue` to dispatch to a handler.  Devirtualizing that dispatch will require (a) type information about the
> inline type shared by the two operands, and (b) a way to inline through a constant `ClassValue::get` call (please see
> https://bugs.openjdk.java.net/browse/JDK-8238260).  The profile information to (eventually) drive JDK-8238260 will be
> either side, but it will be most efficiently collected if it is filtered down to cases where (a) the two sides have the
> same klass and (b) that klass is an inline.  If that filtered profile is monomorphic (which doesn't require the profile
> as a whole to be monomorphic) then JDK-8238260 (or some other ad hoc devirtualization of the S-test) can get a serious
> win.

@rose00 Thanks for the discussion and suggestions. I propose I file 2 RFEs for this (one to improve handling of known
inline types at acmp and another one to improve profile collection at acmp). I think the patch as it is today is a
worthwhile improvement and I'd like to move forward with it as it is (even small improvements to profiling can turn out
to be quite a bit of work given the interpreter, c1 and c2 all need to be adjusted).

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

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


From fw at deneb.enyo.de  Sat Sep 26 19:33:20 2020
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 26 Sep 2020 21:33:20 +0200
Subject: New candidate JEP: 390: Warnings for Value-Based Classes
In-Reply-To: <20200924212806.8CD983C2F7A@eggemoggin.niobe.net> (mark
 reinhold's message of "Thu, 24 Sep 2020 14:28:06 -0700 (PDT)")
References: <20200924212806.8CD983C2F7A@eggemoggin.niobe.net>
Message-ID: <87v9g0pc3j.fsf@mid.deneb.enyo.de>

* mark reinhold:

> https://openjdk.java.net/jeps/390

Should this JEP mention data races and tearing?  Or put differently,
should @ValueBased be seen as a warning not to access fields of this
type without synchronization?


From thartmann at openjdk.java.net  Mon Sep 28 09:10:09 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 28 Sep 2020 09:10:09 GMT
Subject: [lworld] RFR: 8253416: [lworld] C1: incorrect nestmate access to
 flattened field if nest-host is not loaded
In-Reply-To: <mizhkHard4EhYCWmNarXQ5QQW9nyQW6O7LRgjkHH_a0=.71bf7866-c186-442b-a182-220b8bf9e6ab@github.com>
References: <Uly8VEY2zCBDO7nEH7sCC38HjcAU7eS7B1lCNrbYC_Y=.d4c7d4c4-1323-4390-8f57-f2c219a49ef7@github.com>
 <vEg03T-Qwh0EqEpYQTsrIr4o9SyQlvqTjcIuHIHP1xM=.9e453876-9db9-48bb-b380-448641bf7fd7@github.com>
 <iKV4-my0ZOKb7U7nI-Zi05NBNj1UemMAlmGqVlp_FLI=.05bb04f0-08a4-4577-8740-dba0768c9341@github.com>
 <mizhkHard4EhYCWmNarXQ5QQW9nyQW6O7LRgjkHH_a0=.71bf7866-c186-442b-a182-220b8bf9e6ab@github.com>
Message-ID: <moEmoHjprdUuYlbiwmHLOibGoHu5OkW3YQ3Ibse4EjA=.f3aa636b-350b-4b91-9ae4-fb81bef88533@github.com>

On Fri, 25 Sep 2020 14:17:28 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>>> So, did you keep the needs_patching argument in the copy_inline_content() method only for verification purpose?
>> 
>> Yes, but we could also move the assert into the caller. What do you prefer?
>
> I'm fine with both approaches (assert in the caller or in copy_inline_content()), just pick the solution you think is
> the safest (I don't think it makes a lot of difference from a performance point of view).
> Fred

Thanks. I'll go with the current version and think about refactoring with JDK-8228634.

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

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


From thartmann at openjdk.java.net  Mon Sep 28 09:10:15 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 28 Sep 2020 09:10:15 GMT
Subject: [lworld] Integrated: 8253416: [lworld] C1: incorrect nestmate access
 to flattened field if nest-host is not loaded
In-Reply-To: <Uly8VEY2zCBDO7nEH7sCC38HjcAU7eS7B1lCNrbYC_Y=.d4c7d4c4-1323-4390-8f57-f2c219a49ef7@github.com>
References: <Uly8VEY2zCBDO7nEH7sCC38HjcAU7eS7B1lCNrbYC_Y=.d4c7d4c4-1323-4390-8f57-f2c219a49ef7@github.com>
Message-ID: <2zor_odq-3XePRSGkPxYGU_ydbG7Dje-gWmACN1wblQ=.d0c68979-64d3-4e9a-8991-d4c6cb011dbe@github.com>

On Thu, 24 Sep 2020 14:08:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C1 incorrectly assumes that a nestmate field access is not flat if the nest-host is not loaded.
> 
> We are creating the ciField instance for a field in the nest-host via:
> `ciField::ciField -> Reflection::verify_member_access -> InstanceKlass::has_nestmate_access_to ->
> InstanceKlass::nest_host` Resolving the nest host then requires class loading which is not possible from the C1
> compiler thread and as a result we end up with partial field information (is_flattened is always false). The code in
> LIRGenerator::flattened_field_load_prolog then assumes that if !field->is_flattened(), the field is indeed not
> flattened. However, we can only rely on that information if !needs_patching.  I've completely re-wrote and simplified
> the complex logic in LIRGenerator::flattened_field_load_prolog and added asserts/checks to make sure we are not
> attempting to patch flattened inline type field accesses (that functionality could be added though but it's not easy).
> This patch also includes the following unrelated changes:
> - The "new" bytecode needs to throw an exception on inline klasses (the klass might be unloaded). The fix makes sure we
>   always take the slow path to "new_instance_no_inline" in that case.
> - The "defaultvalue" bytecode needs to throw an exception on non-inline klasses. We simply deoptimize in that case.
> - Load/stores from/to fields of an empty inline type should be removed.
> - Some refactoring and new asserts.

This pull request has now been integrated.

Changeset: 268a9ad0
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/268a9ad0
Stats:     1135 lines in 15 files changed: 878 ins; 120 del; 137 mod

8253416: [lworld] C1: incorrect nestmate access to flattened field if nest-host is not loaded

Reviewed-by: fparain

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

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


From sadayapalam at openjdk.java.net  Mon Sep 28 14:21:30 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 28 Sep 2020 14:21:30 GMT
Subject: RFR: 8253312: Enable JVM experiments in specialization under an
 opt-in mode
Message-ID: <mCJY8UhElRP07bVcPnyMw_Z-H0N0xkK2JZSzP4rEKzc=.beb65b37-3674-49b6-8aed-3269ff777402@github.com>

Early support for specialization experiements via type restrictions on fields.

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

Commit messages:
 - 8253312: Enable JVM experiments in specialization under an opt-in mode

Changes: https://git.openjdk.java.net/valhalla/pull/199/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=199&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253312
  Stats: 311 lines in 17 files changed: 289 ins; 3 del; 19 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/199.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/199/head:pull/199

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


From fparain at openjdk.java.net  Mon Sep 28 14:23:27 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 28 Sep 2020 14:23:27 GMT
Subject: [lworld] RFR: 8253663: [lworld] [lw3] TestJNIArrays crashes in
 jni_CreateSubElementSelector
Message-ID: <MXG4wOYmHQ3ThugYb43I4RXT1SuMyW4L3sq48QkdytQ=.1ccc06a3-60f4-428d-a647-e184220a9933@github.com>

Please review this small changeset fixing two naked oops in the JNI code to access flattened arrays.
These fixes should prevent the crashes we recently saw with TestJNIArrays test.

Tested with Mach5, tiers 1 to 3.

Thank you,

Fred

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

Commit messages:
 - Fix naked oop

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

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


From sadayapalam at openjdk.java.net  Mon Sep 28 14:25:27 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 28 Sep 2020 14:25:27 GMT
Subject: Integrated: 8253312: Enable JVM experiments in specialization under
 an opt-in mode
In-Reply-To: <mCJY8UhElRP07bVcPnyMw_Z-H0N0xkK2JZSzP4rEKzc=.beb65b37-3674-49b6-8aed-3269ff777402@github.com>
References: <mCJY8UhElRP07bVcPnyMw_Z-H0N0xkK2JZSzP4rEKzc=.beb65b37-3674-49b6-8aed-3269ff777402@github.com>
Message-ID: <9jZp9igwQrofAj6afNz0BKtKBnegD7kzWygP2NgBNkY=.21b956bc-129f-4237-b44e-1299ddff18d0@github.com>

On Mon, 28 Sep 2020 13:04:08 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Early support for specialization experiements via type restrictions on fields.

This pull request has now been integrated.

Changeset: 39db5a71
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/39db5a71
Stats:     311 lines in 17 files changed: 289 ins; 3 del; 19 mod

8253312: Enable JVM experiments in specialization under an opt-in mode

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

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


From lfoltan at openjdk.java.net  Mon Sep 28 14:28:49 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 28 Sep 2020 14:28:49 GMT
Subject: [lworld] RFR: 8253663: [lworld] [lw3] TestJNIArrays crashes in
 jni_CreateSubElementSelector
In-Reply-To: <MXG4wOYmHQ3ThugYb43I4RXT1SuMyW4L3sq48QkdytQ=.1ccc06a3-60f4-428d-a647-e184220a9933@github.com>
References: <MXG4wOYmHQ3ThugYb43I4RXT1SuMyW4L3sq48QkdytQ=.1ccc06a3-60f4-428d-a647-e184220a9933@github.com>
Message-ID: <8d7DORLiihXzGz-djAqubAP3izgm03zc_iP5I6CJcjw=.73313b20-b7fd-4bda-babd-05ac4273e0d5@github.com>

On Mon, 28 Sep 2020 14:09:20 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small changeset fixing two naked oops in the JNI code to access flattened arrays.
> These fixes should prevent the crashes we recently saw with TestJNIArrays test.
> 
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

Looks good.

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

Marked as reviewed by lfoltan (Committer).

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


From fparain at openjdk.java.net  Mon Sep 28 14:35:16 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 28 Sep 2020 14:35:16 GMT
Subject: [lworld] RFR: 8253663: [lworld] [lw3] TestJNIArrays crashes in
 jni_CreateSubElementSelector
In-Reply-To: <8d7DORLiihXzGz-djAqubAP3izgm03zc_iP5I6CJcjw=.73313b20-b7fd-4bda-babd-05ac4273e0d5@github.com>
References: <MXG4wOYmHQ3ThugYb43I4RXT1SuMyW4L3sq48QkdytQ=.1ccc06a3-60f4-428d-a647-e184220a9933@github.com>
 <8d7DORLiihXzGz-djAqubAP3izgm03zc_iP5I6CJcjw=.73313b20-b7fd-4bda-babd-05ac4273e0d5@github.com>
Message-ID: <c5wEuRyzpUdJBG2qSKG2w1Xty_Z31AnchGjuSK4Ik2Q=.6eb04193-48d8-44ff-af1e-5cf9808ee603@github.com>

On Mon, 28 Sep 2020 14:26:28 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

>> Please review this small changeset fixing two naked oops in the JNI code to access flattened arrays.
>> These fixes should prevent the crashes we recently saw with TestJNIArrays test.
>> 
>> Tested with Mach5, tiers 1 to 3.
>> 
>> Thank you,
>> 
>> Fred
>
> Looks good.

Lois,

Thank you for your review,

Fred

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

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


From fparain at openjdk.java.net  Mon Sep 28 14:39:39 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 28 Sep 2020 14:39:39 GMT
Subject: [lworld] Integrated: 8253663: [lworld] [lw3] TestJNIArrays crashes in
 jni_CreateSubElementSelector
In-Reply-To: <MXG4wOYmHQ3ThugYb43I4RXT1SuMyW4L3sq48QkdytQ=.1ccc06a3-60f4-428d-a647-e184220a9933@github.com>
References: <MXG4wOYmHQ3ThugYb43I4RXT1SuMyW4L3sq48QkdytQ=.1ccc06a3-60f4-428d-a647-e184220a9933@github.com>
Message-ID: <rC3-kovp40UNSMWOtu1EoEamALocWvwsWRE9SFWFq-g=.606d298a-d1ca-47e0-8746-849f1f72117e@github.com>

On Mon, 28 Sep 2020 14:09:20 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small changeset fixing two naked oops in the JNI code to access flattened arrays.
> These fixes should prevent the crashes we recently saw with TestJNIArrays test.
> 
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: e605c42e
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e605c42e
Stats:     6 lines in 1 file changed: 2 ins; 1 del; 3 mod

8253663: [lworld] [lw3] TestJNIArrays crashes in jni_CreateSubElementSelector

Reviewed-by: lfoltan

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

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


From fparain at openjdk.java.net  Mon Sep 28 20:32:05 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 28 Sep 2020 20:32:05 GMT
Subject: [lworld] RFR: 8253744: [lworld] [lw3] Injected IdentityObject
 interface should not be hidden by the JVM
Message-ID: <D6JvGFZhITzFgWIeCL0q0dE3VCCmgtJX2PRzF8_Ovhk=.117701de-5b40-4cf8-a8d4-a47e355d29ae@github.com>

Please review these changes which expose the IdentityObject interface when it is injected by the JVM instead of hiding
it. Some tests needed some updates because of the new interface showing up.

Thanks to Daniel Fuchs for his work to fix the test/jdk/javax/naming/module/RunBasic.java test (it was not a small
task).

Tested with Mach5, tiers 1 to 3.

Thank you,

Fred

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

Commit messages:
 - Merge pull request #1 from dfuch/jndi_fix
 - [lworld][idobj_intf] Update copyright and fix comments in modified files
 - [lworld][idobj_intf] Fix test/jdk/javax/naming/module/RunBasic.java by updating the .ldap replay files
 - Fix one more test
 - Fix tests
 - Show injected IdentityObject interface

Changes: https://git.openjdk.java.net/valhalla/pull/201/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=201&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253744
  Stats: 213 lines in 8 files changed: 36 ins; 23 del; 154 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/201.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/201/head:pull/201

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


From sadayapalam at openjdk.java.net  Tue Sep 29 07:32:35 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 29 Sep 2020 07:32:35 GMT
Subject: Integrated: 8253760: [type-restrictions] Static inline fields are not
 "erased" to the ref type
In-Reply-To: <FIIDagCtB1p5WXGN1rwg5PDccT7M8Jrn6aO1VUforLc=.594cba5c-733c-42c3-94bf-faa18d6e9ffe@github.com>
References: <FIIDagCtB1p5WXGN1rwg5PDccT7M8Jrn6aO1VUforLc=.594cba5c-733c-42c3-94bf-faa18d6e9ffe@github.com>
Message-ID: <5xEq0VIuWQG_vaOvRqYPJ67vZvYvoYQMqYNJnazIItI=.86c4ae4f-2613-415f-b2c1-e5bdbfdd33ab@github.com>

On Tue, 29 Sep 2020 07:14:10 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> getstatic and putstatic also operate on L descriptors of ref types now

This pull request has now been integrated.

Changeset: 750afaf4
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/750afaf4
Stats:     105 lines in 2 files changed: 104 ins; 0 del; 1 mod

8253760: [type-restrictions] Static inline fields are not "erased" to the ref type

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

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


From sadayapalam at openjdk.java.net  Tue Sep 29 07:32:31 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 29 Sep 2020 07:32:31 GMT
Subject: Integrated: 8253760: [type-restrictions] Static inline fields are not
 "erased" to the ref type
Message-ID: <FIIDagCtB1p5WXGN1rwg5PDccT7M8Jrn6aO1VUforLc=.594cba5c-733c-42c3-94bf-faa18d6e9ffe@github.com>

getstatic and putstatic also operate on L descriptors of ref types now

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

Commit messages:
 - Fix white space issues
 - 8253760: [type-restrictions] Static inline fields are not "erased" to the ref type

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

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


From hseigel at openjdk.java.net  Tue Sep 29 14:14:33 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 29 Sep 2020 14:14:33 GMT
Subject: [lworld] RFR: 8253744: [lworld] [lw3] Injected IdentityObject
 interface should not be hidden by the JVM
In-Reply-To: <D6JvGFZhITzFgWIeCL0q0dE3VCCmgtJX2PRzF8_Ovhk=.117701de-5b40-4cf8-a8d4-a47e355d29ae@github.com>
References: <D6JvGFZhITzFgWIeCL0q0dE3VCCmgtJX2PRzF8_Ovhk=.117701de-5b40-4cf8-a8d4-a47e355d29ae@github.com>
Message-ID: <HtlxSyJUvBC0snblEI5BSBaGKTcAhryN99AwDQsj7cY=.1498f043-7885-4d09-9916-2ec740561c11@github.com>

On Mon, 28 Sep 2020 20:26:08 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes which expose the IdentityObject interface when it is injected by the JVM instead of hiding
> it. Some tests needed some updates because of the new interface showing up.
> 
> Thanks to Daniel Fuchs for his work to fix the test/jdk/javax/naming/module/RunBasic.java test (it was not a small
> task).
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

The changes look good, although I wasn't able to follow the RunBasic.java test changes.

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

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


From rriggs at openjdk.java.net  Tue Sep 29 15:30:06 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 29 Sep 2020 15:30:06 GMT
Subject: [lworld] RFR: 8253744: [lworld] [lw3] Injected IdentityObject
 interface should not be hidden by the JVM
In-Reply-To: <D6JvGFZhITzFgWIeCL0q0dE3VCCmgtJX2PRzF8_Ovhk=.117701de-5b40-4cf8-a8d4-a47e355d29ae@github.com>
References: <D6JvGFZhITzFgWIeCL0q0dE3VCCmgtJX2PRzF8_Ovhk=.117701de-5b40-4cf8-a8d4-a47e355d29ae@github.com>
Message-ID: <F-aTal3tkRngwEq8bgqooDLtjgmQ88G7NLg6ugNOChQ=.78d828c0-28d2-448b-96b1-8aee35f9befa@github.com>

On Mon, 28 Sep 2020 20:26:08 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes which expose the IdentityObject interface when it is injected by the JVM instead of hiding
> it. Some tests needed some updates because of the new interface showing up.
> 
> Thanks to Daniel Fuchs for his work to fix the test/jdk/javax/naming/module/RunBasic.java test (it was not a small
> task).
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

Marked as reviewed by rriggs (Committer).

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

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


From fparain at openjdk.java.net  Tue Sep 29 15:34:56 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 29 Sep 2020 15:34:56 GMT
Subject: [lworld] RFR: 8253744: [lworld] [lw3] Injected IdentityObject
 interface should not be hidden by the JVM
In-Reply-To: <F-aTal3tkRngwEq8bgqooDLtjgmQ88G7NLg6ugNOChQ=.78d828c0-28d2-448b-96b1-8aee35f9befa@github.com>
References: <D6JvGFZhITzFgWIeCL0q0dE3VCCmgtJX2PRzF8_Ovhk=.117701de-5b40-4cf8-a8d4-a47e355d29ae@github.com>
 <F-aTal3tkRngwEq8bgqooDLtjgmQ88G7NLg6ugNOChQ=.78d828c0-28d2-448b-96b1-8aee35f9befa@github.com>
Message-ID: <Ugh28JaOoVmWav6Gfj4_WY5LmL8DG_Be9nMkHLnfdNk=.19b57c59-e156-4b15-9528-66701a55d0e7@github.com>

On Tue, 29 Sep 2020 15:27:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Please review these changes which expose the IdentityObject interface when it is injected by the JVM instead of hiding
>> it. Some tests needed some updates because of the new interface showing up.
>> 
>> Thanks to Daniel Fuchs for his work to fix the test/jdk/javax/naming/module/RunBasic.java test (it was not a small
>> task).
>> Tested with Mach5, tiers 1 to 3.
>> 
>> Thank you,
>> 
>> Fred
>
> Marked as reviewed by rriggs (Committer).

Harold, Roger,

Thank you for reviewing these changes.

Fred

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

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


From fparain at openjdk.java.net  Tue Sep 29 15:34:57 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 29 Sep 2020 15:34:57 GMT
Subject: [lworld] Integrated: 8253744: [lworld] [lw3] Injected IdentityObject
 interface should not be hidden by the JVM
In-Reply-To: <D6JvGFZhITzFgWIeCL0q0dE3VCCmgtJX2PRzF8_Ovhk=.117701de-5b40-4cf8-a8d4-a47e355d29ae@github.com>
References: <D6JvGFZhITzFgWIeCL0q0dE3VCCmgtJX2PRzF8_Ovhk=.117701de-5b40-4cf8-a8d4-a47e355d29ae@github.com>
Message-ID: <aAi8scsX6HPhbmkC_iLH-rpK2SuMTAuJAqBxflvkgwE=.739e486a-1dfd-41e3-be65-4dca01c655c9@github.com>

On Mon, 28 Sep 2020 20:26:08 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes which expose the IdentityObject interface when it is injected by the JVM instead of hiding
> it. Some tests needed some updates because of the new interface showing up.
> 
> Thanks to Daniel Fuchs for his work to fix the test/jdk/javax/naming/module/RunBasic.java test (it was not a small
> task).
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 18d12723
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/18d12723
Stats:     213 lines in 8 files changed: 36 ins; 23 del; 154 mod

8253744: [lworld] [lw3] Injected IdentityObject interface should not be hidden by the JVM

Co-authored-by: Daniel Fuchs <dfuchs at openjdk.org>
Reviewed-by: rriggs

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

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


From fparain at openjdk.java.net  Tue Sep 29 16:00:04 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 29 Sep 2020 16:00:04 GMT
Subject: [lworld] RFR: 8253724: [lworld] C1 compilation hits assert: Empty
 inline type access should be removed
Message-ID: <TUoomMG-ZPhvpWqZAWwcy68B7m7-jIGf9kmdReJFq2w=.7aa2cfc7-6feb-47ae-8e6a-03ddacf4b74f@github.com>

Please review these changes fixing handling the handling of empty inline types in C1.
The changeset includes two new unit tests, but they are currently disabled because they are causing failures with C2
which has issues with empty inline types too (C2 will be fixed with a different patch).

Tested with Mach5, tiers 1 to 3.

Thank you,

Fred

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

Commit messages:
 - Temporarily disable new tests
 - Fix handling of empty types
 - Handle empty inline types in withfield

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

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


From thartmann at openjdk.java.net  Tue Sep 29 16:19:48 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 29 Sep 2020 16:19:48 GMT
Subject: [lworld] RFR: 8253724: [lworld] C1 compilation hits assert: Empty
 inline type access should be removed
In-Reply-To: <TUoomMG-ZPhvpWqZAWwcy68B7m7-jIGf9kmdReJFq2w=.7aa2cfc7-6feb-47ae-8e6a-03ddacf4b74f@github.com>
References: <TUoomMG-ZPhvpWqZAWwcy68B7m7-jIGf9kmdReJFq2w=.7aa2cfc7-6feb-47ae-8e6a-03ddacf4b74f@github.com>
Message-ID: <LWhGh_7dWD8v2RI1DX00OOGdjVzIPktUJYc5So6WDRM=.4982095b-f5ec-412a-8605-2de3ec282491@github.com>

On Tue, 29 Sep 2020 15:54:11 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes fixing handling the handling of empty inline types in C1.
> The changeset includes two new unit tests, but they are currently disabled because they are causing failures with C2
> which has issues with empty inline types too (C2 will be fixed with a different patch).
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

Looks good! I'll re-enable these tests once I've fixed C2.

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

Marked as reviewed by thartmann (Committer).

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


From fparain at openjdk.java.net  Tue Sep 29 16:28:43 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 29 Sep 2020 16:28:43 GMT
Subject: [lworld] RFR: 8253724: [lworld] C1 compilation hits assert: Empty
 inline type access should be removed
In-Reply-To: <LWhGh_7dWD8v2RI1DX00OOGdjVzIPktUJYc5So6WDRM=.4982095b-f5ec-412a-8605-2de3ec282491@github.com>
References: <TUoomMG-ZPhvpWqZAWwcy68B7m7-jIGf9kmdReJFq2w=.7aa2cfc7-6feb-47ae-8e6a-03ddacf4b74f@github.com>
 <LWhGh_7dWD8v2RI1DX00OOGdjVzIPktUJYc5So6WDRM=.4982095b-f5ec-412a-8605-2de3ec282491@github.com>
Message-ID: <eOOMICRQRrZtfU2vbZ5FA1iRExrxzfLCMN4MGJw_dy4=.b6578ee6-f168-4841-8d41-148ea5304928@github.com>

On Tue, 29 Sep 2020 16:17:02 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Please review these changes fixing handling the handling of empty inline types in C1.
>> The changeset includes two new unit tests, but they are currently disabled because they are causing failures with C2
>> which has issues with empty inline types too (C2 will be fixed with a different patch).
>> Tested with Mach5, tiers 1 to 3.
>> 
>> Thank you,
>> 
>> Fred
>
> Looks good! I'll re-enable these tests once I've fixed C2.

Tobias,

Thank you for the review.

Fred

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

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


From fparain at openjdk.java.net  Tue Sep 29 16:28:44 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 29 Sep 2020 16:28:44 GMT
Subject: [lworld] Integrated: 8253724: [lworld] C1 compilation hits assert:
 Empty inline type access should be removed
In-Reply-To: <TUoomMG-ZPhvpWqZAWwcy68B7m7-jIGf9kmdReJFq2w=.7aa2cfc7-6feb-47ae-8e6a-03ddacf4b74f@github.com>
References: <TUoomMG-ZPhvpWqZAWwcy68B7m7-jIGf9kmdReJFq2w=.7aa2cfc7-6feb-47ae-8e6a-03ddacf4b74f@github.com>
Message-ID: <y9fuc_cBs0peyagfJQQrzy2qcgO_tMEHtWHFmyLZiBI=.c9527e28-9308-4887-95d7-aa923e8eb4d8@github.com>

On Tue, 29 Sep 2020 15:54:11 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review these changes fixing handling the handling of empty inline types in C1.
> The changeset includes two new unit tests, but they are currently disabled because they are causing failures with C2
> which has issues with empty inline types too (C2 will be fixed with a different patch).
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: c6f85a33
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c6f85a33
Stats:     48 lines in 2 files changed: 45 ins; 0 del; 3 mod

8253724: [lworld] C1 compilation hits assert: Empty inline type access should be removed

Reviewed-by: thartmann

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

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