From dsimms at openjdk.java.net Thu Oct 1 10:18:38 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 1 Oct 2020 10:18:38 GMT Subject: [lworld] Integrated: Merge jdk Message-ID: <_D4U6DAiRA5Y760SfIFGk3B2LS9Mf_abG1d623N75-E=.5314978e-aced-47a6-9225-6b803da89d9c@github.com> Merge tag 'jdk-16+18' into lworld_merge_jdk_16_18 Added tag jdk-16+18 for changeset e5ba020e # Conflicts: # src/hotspot/share/gc/shared/memAllocator.cpp # src/hotspot/share/oops/accessBackend.hpp # src/hotspot/share/oops/oop.inline.hpp # src/hotspot/share/opto/compile.cpp # src/hotspot/share/opto/compile.hpp ------------- Commit messages: - Merge tag 'jdk-16+18' into lworld_merge_jdk_16_18 - 8253724: [lworld] C1 compilation hits assert: Empty inline type access should be removed - 8253744: [lworld] [lw3] Injected IdentityObject interface should not be hidden by the JVM - 8253663: [lworld] [lw3] TestJNIArrays crashes in jni_CreateSubElementSelector - 8253416: [lworld] C1: incorrect nestmate access to flattened field if nest-host is not loaded - 8253592: [lworld] C2: Additional fixes for handling empty inline types - Merge jdk - 8253511: [lworld] ClassFileParser does not handle field type mismatch - 8253181: [lworld] Javac fails to properly handle inline class files with inner classes - Merge jdk - ... and 991 more: https://git.openjdk.java.net/valhalla/compare/e5ba020e...72788d56 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/valhalla/pull/204/files Stats: 147941 lines in 1322 files changed: 142212 ins; 1334 del; 4395 mod Patch: https://git.openjdk.java.net/valhalla/pull/204.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/204/head:pull/204 PR: https://git.openjdk.java.net/valhalla/pull/204 From dsimms at openjdk.java.net Thu Oct 1 10:18:42 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 1 Oct 2020 10:18:42 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: <_D4U6DAiRA5Y760SfIFGk3B2LS9Mf_abG1d623N75-E=.5314978e-aced-47a6-9225-6b803da89d9c@github.com> References: <_D4U6DAiRA5Y760SfIFGk3B2LS9Mf_abG1d623N75-E=.5314978e-aced-47a6-9225-6b803da89d9c@github.com> Message-ID: <3KP3tSNSNnwGieTGESGK-J30kYRXa5wmOIis-_FJ-Rs=.7eba94e0-c33b-4e83-8afb-84d10f2715b2@github.com> On Thu, 1 Oct 2020 10:06:39 GMT, David Simms wrote: > Merge tag 'jdk-16+18' into lworld_merge_jdk_16_18 > Added tag jdk-16+18 for changeset e5ba020e > > # Conflicts: > # src/hotspot/share/gc/shared/memAllocator.cpp > # src/hotspot/share/oops/accessBackend.hpp > # src/hotspot/share/oops/oop.inline.hpp > # src/hotspot/share/opto/compile.cpp > # src/hotspot/share/opto/compile.hpp This pull request has now been integrated. Changeset: d248d383 Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/d248d383 Stats: 35531 lines in 2077 files changed: 7112 ins; 23255 del; 5164 mod Merge jdk Merge tag 'jdk-16+18' ------------- PR: https://git.openjdk.java.net/valhalla/pull/204 From hseigel at openjdk.java.net Thu Oct 1 20:37:18 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 1 Oct 2020 20:37:18 GMT Subject: [lworld] RFR: 8253873: jdi, jvmti, and jdwp tests fail because of unexpected number of interfaces Message-ID: Please review these changes to fix tier4 and tier5 tests that started failing because injected interface IdentityObject is no longer hidden. Tiers 4 and 5 were run on linux X64, Macosx, and Windows to check that the tests passed. ------------- Commit messages: - 8253873: jdi, jvmti, and jdwp tests fail because of unexpected number of interfaces Changes: https://git.openjdk.java.net/valhalla/pull/206/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=206&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253873 Stats: 76 lines in 8 files changed: 13 ins; 0 del; 63 mod Patch: https://git.openjdk.java.net/valhalla/pull/206.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/206/head:pull/206 PR: https://git.openjdk.java.net/valhalla/pull/206 From thartmann at openjdk.java.net Fri Oct 2 11:55:52 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 2 Oct 2020 11:55:52 GMT Subject: [lworld] RFR: 8248220: [lworld] Optimize empty inline types Message-ID: The change includes the following optimizations for empty inline types and several bug fixes: - All uses ((array) loads, stores, allocations, ...) are replaced by the default oop or removed - Calling convention should not pass/return anything ------------- Commit messages: - Fixed trailing whitespace - 8248220: [lworld] Optimize empty inline types Changes: https://git.openjdk.java.net/valhalla/pull/207/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=207&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248220 Stats: 372 lines in 19 files changed: 258 ins; 15 del; 99 mod Patch: https://git.openjdk.java.net/valhalla/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/207/head:pull/207 PR: https://git.openjdk.java.net/valhalla/pull/207 From thartmann at openjdk.java.net Mon Oct 5 06:26:48 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 5 Oct 2020 06:26:48 GMT Subject: [lworld] Integrated: 8248220: [lworld] Optimize empty inline types In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 11:48:09 GMT, Tobias Hartmann wrote: > The change includes the following optimizations for empty inline types and several bug fixes: > - All uses ((array) loads, stores, allocations, ...) are replaced by the default oop or removed > - Calling convention should not pass/return anything This pull request has now been integrated. Changeset: 67af0b73 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/67af0b73 Stats: 372 lines in 19 files changed: 258 ins; 15 del; 99 mod 8248220: [lworld] Optimize empty inline types ------------- PR: https://git.openjdk.java.net/valhalla/pull/207 From thartmann at openjdk.java.net Mon Oct 5 09:20:56 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 5 Oct 2020 09:20:56 GMT Subject: [lworld] RFR: 8253745: [lworld] C1: Flat inline type array store may write out of bounds Message-ID: When storing to a flat inline type array, C1 emits code for a field-wise copy from the source buffer to the destination array element. The field contents are stored in a temp register. If the field type is smaller than T_INT, we increase it to T_INT because smaller registers are not supported. However, the type of the load/store should not be updated. ------------- Commit messages: - 8253745: [lworld] C1: Flat inline type array store may write out of bounds Changes: https://git.openjdk.java.net/valhalla/pull/208/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=208&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253745 Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/valhalla/pull/208.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/208/head:pull/208 PR: https://git.openjdk.java.net/valhalla/pull/208 From thartmann at openjdk.java.net Mon Oct 5 11:39:44 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 5 Oct 2020 11:39:44 GMT Subject: [lworld] Integrated: 8253745: [lworld] C1: Flat inline type array store may write out of bounds In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 09:17:04 GMT, Tobias Hartmann wrote: > When storing to a flat inline type array, C1 emits code for a field-wise copy from the source buffer to the destination > array element. The field contents are stored in a temp register. If the field type is smaller than T_INT, we increase > it to T_INT because smaller registers are not supported. However, the type of the load/store should not be updated. This pull request has now been integrated. Changeset: f24c2a82 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/f24c2a82 Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod 8253745: [lworld] C1: Flat inline type array store may write out of bounds ------------- PR: https://git.openjdk.java.net/valhalla/pull/208 From fparain at openjdk.java.net Mon Oct 5 14:41:18 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Mon, 5 Oct 2020 14:41:18 GMT Subject: [lworld] RFR: 8254022: [lworld] [type-restrictions] Initial support for RestrictedField Message-ID: Please review these changes adding an initial support for RestrictedField. The patch includes: - recognizing and processing the new attribute during class file parsing - creating new meta-data to store both the erased type and the restricted type - fixing all intermediate method dealing with field types (FieldInfo, FieldStream, etc) - fixing field resolution to take into the two possible signatures of the fields - adding checkcast against the restricted type in the interpreter implementation of putfield The patch doesn't include: - propagating new meta-data to CI - adding new type checks in JIT generated code The main take away of this first patch is that the VM mostly cares about the sharp type (from the RestrictedField attribute), and the only place where it needs knowledge of the erased type is for field resolution. This is why the implementation of the RestrictedField in the VM is inverted compared to the content of the class file: the traditional FieldInfo is filled with the sharp type from the RestrictedField attribute, while the original erased type is moved to a new variable section of InstanceKlass. Note: the patch includes a serious clean up of the FieldInfo data structure. It used to store the allocation type of the field, but this information is not used anymore after the replacement of the old field layout code by the field layout builder. Removing the allocation type from the data structure simplifies it a lot. Thank you, Fred ------------- Commit messages: - Initial support for restricted fields - Beginning befofe switching signatures - Refine checks to inline-typed fields - Basic framework to add checkcast to putfield - 8253312: Enable JVM experiments in specialization under an opt-in mode Changes: https://git.openjdk.java.net/valhalla/pull/209/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=209&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254022 Stats: 704 lines in 35 files changed: 533 ins; 101 del; 70 mod Patch: https://git.openjdk.java.net/valhalla/pull/209.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/209/head:pull/209 PR: https://git.openjdk.java.net/valhalla/pull/209 From fparain at openjdk.java.net Mon Oct 5 14:53:51 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Mon, 5 Oct 2020 14:53:51 GMT Subject: [lworld] RFR: 8253873: jdi, jvmti, and jdwp tests fail because of unexpected number of interfaces In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 20:31:59 GMT, Harold Seigel wrote: > Please review these changes to fix tier4 and tier5 tests that started failing because injected interface IdentityObject > is no longer hidden. Tiers 4 and 5 were run on linux X64, Macosx, and Windows to check that the tests passed. Harold, Thank you for fixing this. Overall, changes look good, but it would be good to update the comments because in the current form, it looks like there's a mismatch between the comments and the code. For instance, one test has this comment: "// Class1forCheck - 1 direct and 1 indirect interfaces" but the code has been updated to: " if (iface1list.size() != 3) {" Someone not familiar with the IdentityObject injection would wonder where this "3" comes from, as the comment suggest the correct answer is "2". Regards, Fred ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.java.net/valhalla/pull/206 From fparain at openjdk.java.net Mon Oct 5 14:57:53 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Mon, 5 Oct 2020 14:57:53 GMT Subject: [lworld] Withdrawn: 8254022: [lworld] [type-restrictions] Initial support for RestrictedField In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 14:36:44 GMT, Frederic Parain wrote: > Please review these changes adding an initial support for RestrictedField. > > The patch includes: > - recognizing and processing the new attribute during class file parsing > - creating new meta-data to store both the erased type and the restricted type > - fixing all intermediate method dealing with field types (FieldInfo, FieldStream, etc) > - fixing field resolution to take into the two possible signatures of the fields > - adding checkcast against the restricted type in the interpreter implementation of putfield > > The patch doesn't include: > - propagating new meta-data to CI > - adding new type checks in JIT generated code > > The main take away of this first patch is that the VM mostly cares about the sharp type (from the > RestrictedField attribute), and the only place where it needs knowledge of the erased type is for > field resolution. This is why the implementation of the RestrictedField in the VM is inverted compared > to the content of the class file: the traditional FieldInfo is filled with the sharp type from the RestrictedField > attribute, while the original erased type is moved to a new variable section of InstanceKlass. > > Note: the patch includes a serious clean up of the FieldInfo data structure. It used to store the allocation > type of the field, but this information is not used anymore after the replacement of the old field layout > code by the field layout builder. Removing the allocation type from the data structure simplifies it a lot. > > Thank you, > > Fred This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/valhalla/pull/209 From fparain at openjdk.java.net Mon Oct 5 15:04:04 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Mon, 5 Oct 2020 15:04:04 GMT Subject: RFR: 8254022: [lworld] [type-restrictions] Initial support for RestrictedField Message-ID: [Second attempt, trying to do it on the right branch this time] Please review these changes adding an initial support for RestrictedField. The patch includes: - recognizing and processing the new attribute during class file parsing - creating new meta-data to store both the erased type and the restricted type - fixing all intermediate method dealing with field types (FieldInfo, FieldStream, etc) - fixing field resolution to take into the two possible signatures of the fields - adding checkcast against the restricted type in the interpreter implementation of putfield The patch doesn't include: - propagating new meta-data to CI - adding new type checks in JIT generated code The main take away of this first patch is that the VM mostly cares about the sharp type (from the RestrictedField attribute), and the only place where it needs knowledge of the erased type is for field resolution. This is why the implementation of the RestrictedField in the VM is inverted compared to the content of the class file: the traditional FieldInfo is filled with the sharp type from the RestrictedField attribute, while the original erased type is moved to a new variable section of InstanceKlass. Note: the patch includes a serious clean up of the FieldInfo data structure. It used to store the allocation type of the field, but this information is not used anymore after the replacement of the old field layout code by the field layout builder. Removing the allocation type from the data structure simplifies it a lot. Thank you, Fred ------------- Commit messages: - Initial support for restricted fields - Beginning befofe switching signatures - Refine checks to inline-typed fields - Basic framework to add checkcast to putfield Changes: https://git.openjdk.java.net/valhalla/pull/210/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=210&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254022 Stats: 393 lines in 18 files changed: 244 ins; 98 del; 51 mod Patch: https://git.openjdk.java.net/valhalla/pull/210.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/210/head:pull/210 PR: https://git.openjdk.java.net/valhalla/pull/210 From thartmann at openjdk.java.net Mon Oct 5 15:18:58 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 5 Oct 2020 15:18:58 GMT Subject: [lworld] Integrated: 8254026: [lworld] Execute compiler unit tests in random order by default Message-ID: Execute compiler unit tests in random order because the order affects profiling. Functionality was added by JDK-8252040. Now enabling by default after all bugs that were triggered have been fixed. ------------- Commit messages: - 8254026: [lworld] Execute compiler unit tests in random order by default Changes: https://git.openjdk.java.net/valhalla/pull/211/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=211&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254026 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/211.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/211/head:pull/211 PR: https://git.openjdk.java.net/valhalla/pull/211 From thartmann at openjdk.java.net Mon Oct 5 15:18:58 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 5 Oct 2020 15:18:58 GMT Subject: [lworld] Integrated: 8254026: [lworld] Execute compiler unit tests in random order by default In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 15:13:50 GMT, Tobias Hartmann wrote: > Execute compiler unit tests in random order because the order affects profiling. Functionality was added by > JDK-8252040. Now enabling by default after all bugs that were triggered have been fixed. This pull request has now been integrated. Changeset: 157f8c31 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/157f8c31 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8254026: [lworld] Execute compiler unit tests in random order by default ------------- PR: https://git.openjdk.java.net/valhalla/pull/211 From hseigel at openjdk.java.net Mon Oct 5 17:34:01 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 5 Oct 2020 17:34:01 GMT Subject: [lworld] RFR: 8253873: jdi, jvmti, and jdwp tests fail because of unexpected number of interfaces [v2] In-Reply-To: References: Message-ID: > Please review these changes to fix tier4 and tier5 tests that started failing because injected interface IdentityObject > is no longer hidden. Tiers 4 and 5 were run on linux X64, Macosx, and Windows to check that the tests passed. Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8253873 jdi, jvmti, and jdwp tests fail because of unexpected number of interfaces ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/206/files - new: https://git.openjdk.java.net/valhalla/pull/206/files/147c4fb3..fbd6736c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=206&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=206&range=00-01 Stats: 16 lines in 5 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/valhalla/pull/206.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/206/head:pull/206 PR: https://git.openjdk.java.net/valhalla/pull/206 From fparain at openjdk.java.net Mon Oct 5 17:34:02 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Mon, 5 Oct 2020 17:34:02 GMT Subject: [lworld] RFR: 8253873: jdi, jvmti, and jdwp tests fail because of unexpected number of interfaces [v2] In-Reply-To: References: Message-ID: <_6CdhrFJrCdtl4Z9CpeKYWENS9AQD_UDkX76p1_9TYc=.66695c40-0a18-451f-bf2f-32d92622e338@github.com> On Mon, 5 Oct 2020 17:31:22 GMT, Harold Seigel wrote: >> Please review these changes to fix tier4 and tier5 tests that started failing because injected interface IdentityObject >> is no longer hidden. Tiers 4 and 5 were run on linux X64, Macosx, and Windows to check that the tests passed. > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8253873 jdi, jvmti, and jdwp tests fail because of unexpected number of interfaces Looks good to me. Thank you for the updated comments. Fred ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.java.net/valhalla/pull/206 From hseigel at openjdk.java.net Mon Oct 5 17:34:03 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 5 Oct 2020 17:34:03 GMT Subject: [lworld] RFR: 8253873: jdi, jvmti, and jdwp tests fail because of unexpected number of interfaces [v2] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 14:51:21 GMT, Frederic Parain wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8253873 jdi, jvmti, and jdwp tests fail because of unexpected number of interfaces > > Harold, > > Thank you for fixing this. > Overall, changes look good, but it would be good to update the comments because in the current form, it looks like > there's a mismatch between the comments and the code. > For instance, one test has this comment: > "// Class1forCheck - 1 direct and 1 indirect interfaces" > but the code has been updated to: > " if (iface1list.size() != 3) {" > > Someone not familiar with the IdentityObject injection would wonder where this "3" comes from, > as the comment suggest the correct answer is "2". > > Regards, > > Fred Hi Fred, Thanks for reviewing this change. Please see updated commit containing additional comments about interface IdentityObject. Thanks, Harold ------------- PR: https://git.openjdk.java.net/valhalla/pull/206 From hseigel at openjdk.java.net Mon Oct 5 17:38:47 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 5 Oct 2020 17:38:47 GMT Subject: [lworld] Integrated: 8253873: jdi, jvmti, and jdwp tests fail because of unexpected number of interfaces In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 20:31:59 GMT, Harold Seigel wrote: > Please review these changes to fix tier4 and tier5 tests that started failing because injected interface IdentityObject > is no longer hidden. Tiers 4 and 5 were run on linux X64, Macosx, and Windows to check that the tests passed. This pull request has now been integrated. Changeset: 644b057b Author: Harold Seigel URL: https://git.openjdk.java.net/valhalla/commit/644b057b Stats: 83 lines in 8 files changed: 13 ins; 0 del; 70 mod 8253873: jdi, jvmti, and jdwp tests fail because of unexpected number of interfaces Reviewed-by: fparain ------------- PR: https://git.openjdk.java.net/valhalla/pull/206 From thartmann at openjdk.java.net Tue Oct 6 11:57:58 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 6 Oct 2020 11:57:58 GMT Subject: [lworld] Integrated: 8252030: [lworld] Enable UseArrayLoadStoreProfile by default Message-ID: Profiling at array loads/stores should be enabled by default and only be disabled by test scenarios that do IR verification (to make sure the IR shape does not vary depending on profiling). This patch also disables compile commands if we are running with -Xcomp to make sure more code is inlined/compiled. ------------- Commit messages: - 8252030: [lworld] Enable UseArrayLoadStoreProfile by default Changes: https://git.openjdk.java.net/valhalla/pull/212/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=212&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252030 Stats: 12 lines in 2 files changed: 4 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/212/head:pull/212 PR: https://git.openjdk.java.net/valhalla/pull/212 From thartmann at openjdk.java.net Tue Oct 6 11:57:59 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 6 Oct 2020 11:57:59 GMT Subject: [lworld] Integrated: 8252030: [lworld] Enable UseArrayLoadStoreProfile by default In-Reply-To: References: Message-ID: <1JoIVctzzEfjdxYvACtn-5aGlC7rz8qJxkpqCdjeCZw=.c609b182-cd30-4b11-bd26-e28d9f5e7c82@github.com> On Tue, 6 Oct 2020 11:52:07 GMT, Tobias Hartmann wrote: > Profiling at array loads/stores should be enabled by default and only be disabled by test scenarios that do IR > verification (to make sure the IR shape does not vary depending on profiling). > This patch also disables compile commands if we are running with -Xcomp to make sure more code is inlined/compiled. This pull request has now been integrated. Changeset: d5519976 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/d5519976 Stats: 12 lines in 2 files changed: 4 ins; 6 del; 2 mod 8252030: [lworld] Enable UseArrayLoadStoreProfile by default ------------- PR: https://git.openjdk.java.net/valhalla/pull/212 From dsimms at openjdk.java.net Tue Oct 6 15:42:19 2020 From: dsimms at openjdk.java.net (David Simms) Date: Tue, 6 Oct 2020 15:42:19 GMT Subject: RFR: 8254022: [lworld] [type-restrictions] Initial support for RestrictedField In-Reply-To: References: Message-ID: <5IWFmGh6_lkrzVPgsof715Pk3WcFA1qNNFP9eKYmsyM=.85462e5c-4032-4abb-a01b-4ed5daa27f8f@github.com> On Mon, 5 Oct 2020 14:59:38 GMT, Frederic Parain wrote: > [Second attempt, trying to do it on the right branch this time] > > Please review these changes adding an initial support for RestrictedField. > > The patch includes: > - recognizing and processing the new attribute during class file parsing > - creating new meta-data to store both the erased type and the restricted type > - fixing all intermediate method dealing with field types (FieldInfo, FieldStream, etc) > - fixing field resolution to take into the two possible signatures of the fields > - adding checkcast against the restricted type in the interpreter implementation of putfield > > The patch doesn't include: > - propagating new meta-data to CI > - adding new type checks in JIT generated code > > The main take away of this first patch is that the VM mostly cares about the sharp type (from the > RestrictedField attribute), and the only place where it needs knowledge of the erased type is for > field resolution. This is why the implementation of the RestrictedField in the VM is inverted compared > to the content of the class file: the traditional FieldInfo is filled with the sharp type from the RestrictedField > attribute, while the original erased type is moved to a new variable section of InstanceKlass. > > Note: the patch includes a serious clean up of the FieldInfo data structure. It used to store the allocation > type of the field, but this information is not used anymore after the replacement of the old field layout > code by the field layout builder. Removing the allocation type from the data structure simplifies it a lot. > > Thank you, > > Fred It looks good. Thanks for explanation on the fieldInfo clean up (described in PR body). ------------- Marked as reviewed by dsimms (Committer). PR: https://git.openjdk.java.net/valhalla/pull/210 From fparain at openjdk.java.net Tue Oct 6 18:31:19 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Tue, 6 Oct 2020 18:31:19 GMT Subject: RFR: 8254022: [lworld] [type-restrictions] Initial support for RestrictedField In-Reply-To: <5IWFmGh6_lkrzVPgsof715Pk3WcFA1qNNFP9eKYmsyM=.85462e5c-4032-4abb-a01b-4ed5daa27f8f@github.com> References: <5IWFmGh6_lkrzVPgsof715Pk3WcFA1qNNFP9eKYmsyM=.85462e5c-4032-4abb-a01b-4ed5daa27f8f@github.com> Message-ID: <05PMnzxa5wCkZzNvZfgZ_9xjdBqLZz9E2KZTvdE5-oA=.831eb6cd-4d25-4a39-8113-2a27ce09f6fd@github.com> On Tue, 6 Oct 2020 15:39:03 GMT, David Simms wrote: >> [Second attempt, trying to do it on the right branch this time] >> >> Please review these changes adding an initial support for RestrictedField. >> >> The patch includes: >> - recognizing and processing the new attribute during class file parsing >> - creating new meta-data to store both the erased type and the restricted type >> - fixing all intermediate method dealing with field types (FieldInfo, FieldStream, etc) >> - fixing field resolution to take into the two possible signatures of the fields >> - adding checkcast against the restricted type in the interpreter implementation of putfield >> >> The patch doesn't include: >> - propagating new meta-data to CI >> - adding new type checks in JIT generated code >> >> The main take away of this first patch is that the VM mostly cares about the sharp type (from the >> RestrictedField attribute), and the only place where it needs knowledge of the erased type is for >> field resolution. This is why the implementation of the RestrictedField in the VM is inverted compared >> to the content of the class file: the traditional FieldInfo is filled with the sharp type from the RestrictedField >> attribute, while the original erased type is moved to a new variable section of InstanceKlass. >> >> Note: the patch includes a serious clean up of the FieldInfo data structure. It used to store the allocation >> type of the field, but this information is not used anymore after the replacement of the old field layout >> code by the field layout builder. Removing the allocation type from the data structure simplifies it a lot. >> >> Thank you, >> >> Fred > > It looks good. Thanks for explanation on the fieldInfo clean up (described in PR body). David, Thank you for the review. Fred ------------- PR: https://git.openjdk.java.net/valhalla/pull/210 From fparain at openjdk.java.net Tue Oct 6 18:31:22 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Tue, 6 Oct 2020 18:31:22 GMT Subject: Integrated: 8254022: [lworld] [type-restrictions] Initial support for RestrictedField In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 14:59:38 GMT, Frederic Parain wrote: > [Second attempt, trying to do it on the right branch this time] > > Please review these changes adding an initial support for RestrictedField. > > The patch includes: > - recognizing and processing the new attribute during class file parsing > - creating new meta-data to store both the erased type and the restricted type > - fixing all intermediate method dealing with field types (FieldInfo, FieldStream, etc) > - fixing field resolution to take into the two possible signatures of the fields > - adding checkcast against the restricted type in the interpreter implementation of putfield > > The patch doesn't include: > - propagating new meta-data to CI > - adding new type checks in JIT generated code > > The main take away of this first patch is that the VM mostly cares about the sharp type (from the > RestrictedField attribute), and the only place where it needs knowledge of the erased type is for > field resolution. This is why the implementation of the RestrictedField in the VM is inverted compared > to the content of the class file: the traditional FieldInfo is filled with the sharp type from the RestrictedField > attribute, while the original erased type is moved to a new variable section of InstanceKlass. > > Note: the patch includes a serious clean up of the FieldInfo data structure. It used to store the allocation > type of the field, but this information is not used anymore after the replacement of the old field layout > code by the field layout builder. Removing the allocation type from the data structure simplifies it a lot. > > Thank you, > > Fred This pull request has now been integrated. Changeset: 3f60fc1b Author: Frederic Parain URL: https://git.openjdk.java.net/valhalla/commit/3f60fc1b Stats: 393 lines in 18 files changed: 244 ins; 98 del; 51 mod 8254022: [lworld] [type-restrictions] Initial support for RestrictedField Reviewed-by: dsimms ------------- PR: https://git.openjdk.java.net/valhalla/pull/210 From fparain at openjdk.java.net Wed Oct 7 16:06:21 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Wed, 7 Oct 2020 16:06:21 GMT Subject: [lworld] RFR: 8254174: [lworld] [lw3] C1 should optimize access to array of empty types Message-ID: Please review these changes adding more optimizations related to empty inline types when accessing flattened arrays. Thank you, Fred ------------- Commit messages: - Remove empty line - C1 optimization when accessing arrays of empty inline types Changes: https://git.openjdk.java.net/valhalla/pull/213/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=213&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254174 Stats: 116 lines in 3 files changed: 110 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/valhalla/pull/213.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/213/head:pull/213 PR: https://git.openjdk.java.net/valhalla/pull/213 From thartmann at openjdk.java.net Thu Oct 8 08:04:48 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 8 Oct 2020 08:04:48 GMT Subject: [lworld] RFR: 8254174: [lworld] [lw3] C1 should optimize access to array of empty types In-Reply-To: References: Message-ID: <4kYb0wA-bV92hgPrVksD89nmNFVWz10ltdGe5aPiGAM=.9cfe7e74-ce93-4894-9db5-e931eb5f1894@github.com> On Wed, 7 Oct 2020 16:02:39 GMT, Frederic Parain wrote: > Please review these changes adding more optimizations related to empty inline types when accessing flattened arrays. > > Thank you, > > Fred Looks good to me. test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestC1.java line 336: > 334: e = null; > 335: try { > 336: EmptyType et = test11(array, -1); Extra whitespace before `=`. test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestC1.java line 343: > 341: e = null; > 342: try { > 343: EmptyType et = test11(null, 1); Extra whitespace before `=`. test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestC1.java line 329: > 327: EmptyType[] array = new EmptyType[10]; > 328: try { > 329: EmptyType et = test11(array, 11); Extra whitespace before `=`. test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestC1.java line 290: > 288: > 289: // Test optimizations for arrays of empty types > 290: // (ead/write are not performed, pre-allocated instance is used for reads) "ead" -> "read" ------------- Marked as reviewed by thartmann (Committer). PR: https://git.openjdk.java.net/valhalla/pull/213 From thartmann at openjdk.java.net Thu Oct 8 08:07:57 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 8 Oct 2020 08:07:57 GMT Subject: [lworld] RFR: 8254219: [lworld] Remove reserved entries from the calling convention Message-ID: <5YgQSGpB90fucg_2KLhvQhl9jHp5D7uOLwIKjHzTcE4=.476eec7f-dc61-407e-a454-a187fefa118b@github.com> When packing/unpacking inline type arguments to convert between the scalarized and the non-scalarized calling conventions in the nmethod entry points, we may need to extend the stack. To save stack space, C2 re-uses the existing stack slots and only extends the stack to fit additional fields. As a result, the original return address is in-between and to avoid overwriting it by accident, we need "reserved entries" that are not used by the calling convention. Similar to C1 (see JDK-8241764), we should extend the stack enough for unpacking to have its "own" stack space to lay out arguments and get rid off all the ridiculous complexity that reserved entries require in the JIT. If necessary, there are other ways to save stack space (for example, to allow overwriting the original return address and restore it on return). This fix is part of the "Calling Convention 2.0" umbrella (JDK-8254218) which aims to improve and simplify the implementation of the scalarized calling convention. Best regards, Tobias ------------- Commit messages: - 8254219: [lworld] Remove reserved entries from the calling convention Changes: https://git.openjdk.java.net/valhalla/pull/214/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=214&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254219 Stats: 743 lines in 25 files changed: 61 ins; 459 del; 223 mod Patch: https://git.openjdk.java.net/valhalla/pull/214.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/214/head:pull/214 PR: https://git.openjdk.java.net/valhalla/pull/214 From dsimms at openjdk.java.net Thu Oct 8 09:22:25 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 8 Oct 2020 09:22:25 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge tag 'jdk-16+19' JDK-8251464 removes tabs, breaking node matching regex ------------- Commit messages: - JDK-8251464 removes tabs, breaking node matching regex - Merge tag 'jdk-16+19' into lworld_merge_jdk_16_19 - 8252324: Signal related code should be shared among POSIX platforms - 8216497: javadoc should auto-link to platform classes - 8253874: [JVMCI] added test omitted in 8252881 - 8253475: Javadoc clean up in HttpExchange and HttpServer - 8253000: Remove redundant MAKE_SUBDIR argument - 8252997: Null-proofing for linker_md.c - 8254141: Typo in copyright year - 8249095: tools/javac/launcher/SourceLauncherTest.java fails on Windows - ... and 81 more: https://git.openjdk.java.net/valhalla/compare/d5519976...7d170c99 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=215&range=00.0 - jdk: https://webrevs.openjdk.java.net/?repo=valhalla&pr=215&range=00.1 Changes: https://git.openjdk.java.net/valhalla/pull/215/files Stats: 22878 lines in 737 files changed: 10626 ins; 6946 del; 5306 mod Patch: https://git.openjdk.java.net/valhalla/pull/215.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/215/head:pull/215 PR: https://git.openjdk.java.net/valhalla/pull/215 From dsimms at openjdk.java.net Thu Oct 8 11:38:58 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 8 Oct 2020 11:38:58 GMT Subject: [lworld] RFR: Merge jdk [v2] In-Reply-To: References: Message-ID: <4Z4o8nj_3kN9S9rDek1cWgPjmfsQgyrcpypL8xMUiOs=.edec8785-2af4-4d3f-9489-390b3d0435f8@github.com> > Merge tag 'jdk-16+19' > > JDK-8251464 removes tabs, breaking node matching regex David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 1008 commits: - JDK-8251464 removes tabs, breaking node matching regex - Merge tag 'jdk-16+19' into lworld_merge_jdk_16_19 Added tag jdk-16+19 for changeset 4fe07ccc # Conflicts: # src/java.base/share/classes/java/lang/Object.java # src/java.base/share/classes/java/lang/reflect/Array.java # src/java.base/share/classes/jdk/internal/misc/Unsafe.java - 8252030: [lworld] Enable UseArrayLoadStoreProfile by default - 8253873: jdi, jvmti, and jdwp tests fail because of unexpected number of interfaces Reviewed-by: fparain - 8254026: [lworld] Execute compiler unit tests in random order by default - 8253745: [lworld] C1: Flat inline type array store may write out of bounds - 8248220: [lworld] Optimize empty inline types - Merge jdk Merge tag 'jdk-16+18' - 8253724: [lworld] C1 compilation hits assert: Empty inline type access should be removed Reviewed-by: thartmann - 8253744: [lworld] [lw3] Injected IdentityObject interface should not be hidden by the JVM Co-authored-by: Daniel Fuchs Reviewed-by: rriggs - ... and 998 more: https://git.openjdk.java.net/valhalla/compare/4fe07ccc...7d170c99 ------------- Changes: https://git.openjdk.java.net/valhalla/pull/215/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=215&range=01 Stats: 148263 lines in 1329 files changed: 142468 ins; 1334 del; 4461 mod Patch: https://git.openjdk.java.net/valhalla/pull/215.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/215/head:pull/215 PR: https://git.openjdk.java.net/valhalla/pull/215 From dsimms at openjdk.java.net Thu Oct 8 11:39:00 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 8 Oct 2020 11:39:00 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 09:14:12 GMT, David Simms wrote: > Merge tag 'jdk-16+19' > > JDK-8251464 removes tabs, breaking node matching regex This pull request has now been integrated. Changeset: cae9a890 Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/cae9a890 Stats: 22878 lines in 737 files changed: 10626 ins; 6946 del; 5306 mod Merge jdk Merge tag 'jdk-16+19' ------------- PR: https://git.openjdk.java.net/valhalla/pull/215 From fparain at openjdk.java.net Thu Oct 8 12:11:02 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Thu, 8 Oct 2020 12:11:02 GMT Subject: [lworld] RFR: 8254174: [lworld] [lw3] C1 should optimize access to array of empty types [v2] In-Reply-To: References: Message-ID: > Please review these changes adding more optimizations related to empty inline types when accessing flattened arrays. > > Thank you, > > Fred Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: Fix whitespaces ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/213/files - new: https://git.openjdk.java.net/valhalla/pull/213/files/a3d7a8e6..284217d2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=213&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=213&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/valhalla/pull/213.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/213/head:pull/213 PR: https://git.openjdk.java.net/valhalla/pull/213 From fparain at openjdk.java.net Thu Oct 8 12:11:02 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Thu, 8 Oct 2020 12:11:02 GMT Subject: [lworld] RFR: 8254174: [lworld] [lw3] C1 should optimize access to array of empty types [v2] In-Reply-To: <4kYb0wA-bV92hgPrVksD89nmNFVWz10ltdGe5aPiGAM=.9cfe7e74-ce93-4894-9db5-e931eb5f1894@github.com> References: <4kYb0wA-bV92hgPrVksD89nmNFVWz10ltdGe5aPiGAM=.9cfe7e74-ce93-4894-9db5-e931eb5f1894@github.com> Message-ID: <73oCfXYVnYX3zDeZKKwd5jy4R7XBaHqHQaKbu2h4gYQ=.ab63b7d2-ab86-439d-94a4-e85c2816aaaf@github.com> On Thu, 8 Oct 2020 08:01:44 GMT, Tobias Hartmann wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix whitespaces > > Looks good to me. Tobias, Thank your for the review, I have fixed all whitespaces/typo you spotted. Fred ------------- PR: https://git.openjdk.java.net/valhalla/pull/213 From thartmann at openjdk.java.net Thu Oct 8 12:30:53 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 8 Oct 2020 12:30:53 GMT Subject: [lworld] RFR: 8254174: [lworld] [lw3] C1 should optimize access to array of empty types [v2] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 12:11:02 GMT, Frederic Parain wrote: >> Please review these changes adding more optimizations related to empty inline types when accessing flattened arrays. >> >> Thank you, >> >> Fred > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespaces Marked as reviewed by thartmann (Committer). ------------- PR: https://git.openjdk.java.net/valhalla/pull/213 From thartmann at openjdk.java.net Thu Oct 8 12:31:55 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 8 Oct 2020 12:31:55 GMT Subject: [lworld] Integrated: 8254219: [lworld] Remove reserved entries from the calling convention In-Reply-To: <5YgQSGpB90fucg_2KLhvQhl9jHp5D7uOLwIKjHzTcE4=.476eec7f-dc61-407e-a454-a187fefa118b@github.com> References: <5YgQSGpB90fucg_2KLhvQhl9jHp5D7uOLwIKjHzTcE4=.476eec7f-dc61-407e-a454-a187fefa118b@github.com> Message-ID: On Thu, 8 Oct 2020 08:04:23 GMT, Tobias Hartmann wrote: > When packing/unpacking inline type arguments to convert between the scalarized and the non-scalarized calling > conventions in the nmethod entry points, we may need to extend the stack. To save stack space, C2 re-uses the existing > stack slots and only extends the stack to fit additional fields. As a result, the original return address is in-between > and to avoid overwriting it by accident, we need "reserved entries" that are not used by the calling convention. > Similar to C1 (see JDK-8241764), we should extend the stack enough for unpacking to have its "own" stack space to lay > out arguments and get rid off all the ridiculous complexity that reserved entries require in the JIT. If necessary, > there are other ways to save stack space (for example, to allow overwriting the original return address and restore it > on return). This fix is part of the "Calling Convention 2.0" umbrella (JDK-8254218) which aims to improve and simplify > the implementation of the scalarized calling convention. Best regards, Tobias This pull request has now been integrated. Changeset: ea780c91 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/ea780c91 Stats: 743 lines in 25 files changed: 61 ins; 459 del; 223 mod 8254219: [lworld] Remove reserved entries from the calling convention ------------- PR: https://git.openjdk.java.net/valhalla/pull/214 From fparain at openjdk.java.net Thu Oct 8 12:38:49 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Thu, 8 Oct 2020 12:38:49 GMT Subject: [lworld] Integrated: 8254174: [lworld] [lw3] C1 should optimize access to array of empty types In-Reply-To: References: Message-ID: On Wed, 7 Oct 2020 16:02:39 GMT, Frederic Parain wrote: > Please review these changes adding more optimizations related to empty inline types when accessing flattened arrays. > > Thank you, > > Fred This pull request has now been integrated. Changeset: 735bd44d Author: Frederic Parain URL: https://git.openjdk.java.net/valhalla/commit/735bd44d Stats: 116 lines in 3 files changed: 110 ins; 0 del; 6 mod 8254174: [lworld] [lw3] C1 should optimize access to array of empty types Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/valhalla/pull/213 From dsimms at openjdk.java.net Thu Oct 8 12:43:17 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 8 Oct 2020 12:43:17 GMT Subject: RFR: Merge lworld Message-ID: <4T8ODCSWNHy7XrwMXsjT_O2pjzTEnrvTwD4DNwBpDnw=.b5f6676c-0814-4cfe-ad3f-83e14376c278@github.com> Merge tag 'jdk-16+19' Merge branch 'lworld' into type-restrictions_merge_16_19 ------------- Commit messages: - Merge branch 'lworld' into type-restrictions_merge_16_19 - Merge jdk - 8252324: Signal related code should be shared among POSIX platforms - 8216497: javadoc should auto-link to platform classes - 8253874: [JVMCI] added test omitted in 8252881 - 8253475: Javadoc clean up in HttpExchange and HttpServer - 8253000: Remove redundant MAKE_SUBDIR argument - 8252997: Null-proofing for linker_md.c - 8254141: Typo in copyright year - 8249095: tools/javac/launcher/SourceLauncherTest.java fails on Windows - ... and 275 more: https://git.openjdk.java.net/valhalla/compare/3f60fc1b...d0d81c2d The webrevs contain the adjustments done while merging with regards to each parent branch: - type-restrictions: https://webrevs.openjdk.java.net/?repo=valhalla&pr=217&range=00.0 - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=217&range=00.1 Changes: https://git.openjdk.java.net/valhalla/pull/217/files Stats: 77268 lines in 3018 files changed: 28030 ins; 37423 del; 11815 mod Patch: https://git.openjdk.java.net/valhalla/pull/217.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/217/head:pull/217 PR: https://git.openjdk.java.net/valhalla/pull/217 From dsimms at openjdk.java.net Thu Oct 8 12:47:12 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 8 Oct 2020 12:47:12 GMT Subject: RFR: Merge lworld [v2] In-Reply-To: <4T8ODCSWNHy7XrwMXsjT_O2pjzTEnrvTwD4DNwBpDnw=.b5f6676c-0814-4cfe-ad3f-83e14376c278@github.com> References: <4T8ODCSWNHy7XrwMXsjT_O2pjzTEnrvTwD4DNwBpDnw=.b5f6676c-0814-4cfe-ad3f-83e14376c278@github.com> Message-ID: > Merge tag 'jdk-16+19' > > Merge branch 'lworld' into type-restrictions_merge_16_19 David Simms 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 type-restrictions_merge_16_19 - 8254022: [lworld] [type-restrictions] Initial support for RestrictedField Reviewed-by: dsimms - 8253760: [type-restrictions] Static inline fields are not "erased" to the ref type - 8253312: Enable JVM experiments in specialization under an opt-in mode ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/217/files - new: https://git.openjdk.java.net/valhalla/pull/217/files/d0d81c2d..d0d81c2d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=217&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=217&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/217.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/217/head:pull/217 PR: https://git.openjdk.java.net/valhalla/pull/217 From dsimms at openjdk.java.net Thu Oct 8 12:47:15 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 8 Oct 2020 12:47:15 GMT Subject: Integrated: Merge lworld In-Reply-To: <4T8ODCSWNHy7XrwMXsjT_O2pjzTEnrvTwD4DNwBpDnw=.b5f6676c-0814-4cfe-ad3f-83e14376c278@github.com> References: <4T8ODCSWNHy7XrwMXsjT_O2pjzTEnrvTwD4DNwBpDnw=.b5f6676c-0814-4cfe-ad3f-83e14376c278@github.com> Message-ID: On Thu, 8 Oct 2020 12:36:07 GMT, David Simms wrote: > Merge tag 'jdk-16+19' > > Merge branch 'lworld' into type-restrictions_merge_16_19 This pull request has now been integrated. Changeset: 1afa9fbd Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/1afa9fbd Stats: 77268 lines in 3018 files changed: 28030 ins; 37423 del; 11815 mod Merge lworld Merge tag 'jdk-16+19' ------------- PR: https://git.openjdk.java.net/valhalla/pull/217 From fparain at openjdk.java.net Thu Oct 8 17:36:37 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Thu, 8 Oct 2020 17:36:37 GMT Subject: [lworld] RFR: 8254258: [lworld] [lw3] Inline types layout can be optimized Message-ID: Please review theses changes optimizing fields layout involving small flattened fields. The patch also includes a fix for the oop map generation of contended field groups. Tested with Mach5, tier1, tier2, tier3 (no regressions compared to actual status of HEAD). Thank you, Fred ------------- Commit messages: - Improve field layout for inline types Changes: https://git.openjdk.java.net/valhalla/pull/218/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=218&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254258 Stats: 118 lines in 2 files changed: 53 ins; 33 del; 32 mod Patch: https://git.openjdk.java.net/valhalla/pull/218.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/218/head:pull/218 PR: https://git.openjdk.java.net/valhalla/pull/218 From fparain at openjdk.java.net Thu Oct 8 18:48:37 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Thu, 8 Oct 2020 18:48:37 GMT Subject: RFR: 8254254: [lworld][type-restrictions] Serviceability tests failing missing FIELDINFO_TAG_MASK Message-ID: Please review this changeset which updates the SA to match the new format of FieldInfo. Tested locally with test/hotspot/jtreg/serviceability/sa/ tests. Thank you, Fred ------------- Commit messages: - Fix SA after FieldInfo format change Changes: https://git.openjdk.java.net/valhalla/pull/219/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=219&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254254 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/219.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/219/head:pull/219 PR: https://git.openjdk.java.net/valhalla/pull/219 From lfoltan at openjdk.java.net Thu Oct 8 19:37:27 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 8 Oct 2020 19:37:27 GMT Subject: RFR: 8254254: [lworld][type-restrictions] Serviceability tests failing missing FIELDINFO_TAG_MASK In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 18:43:55 GMT, Frederic Parain wrote: > Please review this changeset which updates the SA to match the new format of FieldInfo. > > Tested locally with test/hotspot/jtreg/serviceability/sa/ tests. > > Thank you, > > Fred Marked as reviewed by lfoltan (Committer). ------------- PR: https://git.openjdk.java.net/valhalla/pull/219 From roland at openjdk.java.net Fri Oct 9 11:24:22 2020 From: roland at openjdk.java.net (Roland Westrelin) Date: Fri, 9 Oct 2020 11:24:22 GMT Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode In-Reply-To: References: Message-ID: <_38C4tHm441S9IOOb6pRK30nIC32Ieo6XvoTFV9TcNI=.6cabe29b-b96c-4f26-b379-aaa9383df283@github.com> On Fri, 25 Sep 2020 14:23:59 GMT, Roland Westrelin wrote: > @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). Actually there's already an RFE for that: https://bugs.openjdk.java.net/browse/JDK-8228361 ------------- PR: https://git.openjdk.java.net/valhalla/pull/185 From roland at openjdk.java.net Fri Oct 9 12:00:35 2020 From: roland at openjdk.java.net (Roland Westrelin) Date: Fri, 9 Oct 2020 12:00:35 GMT Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode [v3] In-Reply-To: References: Message-ID: > 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=02 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 Fri Oct 9 12:37:24 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Fri, 9 Oct 2020 12:37:24 GMT Subject: RFR: 8254254: [lworld][type-restrictions] Serviceability tests failing missing FIELDINFO_TAG_MASK In-Reply-To: References: Message-ID: <7_HlUDD80rPcGr2Ixmg8uAn399PdjnoDpDHyFuhUJdI=.a47a07ed-9a89-4efc-9d80-aecdec3e2b1f@github.com> On Thu, 8 Oct 2020 19:34:22 GMT, Lois Foltan wrote: >> Please review this changeset which updates the SA to match the new format of FieldInfo. >> >> Tested locally with test/hotspot/jtreg/serviceability/sa/ tests. >> >> Thank you, >> >> Fred > > Marked as reviewed by lfoltan (Committer). Hi Lois! Thank you for the review. Fred ------------- PR: https://git.openjdk.java.net/valhalla/pull/219 From fparain at openjdk.java.net Fri Oct 9 12:37:25 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Fri, 9 Oct 2020 12:37:25 GMT Subject: Integrated: 8254254: [lworld][type-restrictions] Serviceability tests failing missing FIELDINFO_TAG_MASK In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 18:43:55 GMT, Frederic Parain wrote: > Please review this changeset which updates the SA to match the new format of FieldInfo. > > Tested locally with test/hotspot/jtreg/serviceability/sa/ tests. > > Thank you, > > Fred This pull request has now been integrated. Changeset: 0fb77efa Author: Frederic Parain URL: https://git.openjdk.java.net/valhalla/commit/0fb77efa Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 8254254: [lworld][type-restrictions] Serviceability tests failing missing FIELDINFO_TAG_MASK Reviewed-by: lfoltan ------------- PR: https://git.openjdk.java.net/valhalla/pull/219 From fparain at openjdk.java.net Fri Oct 9 17:03:30 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Fri, 9 Oct 2020 17:03:30 GMT Subject: [lworld] RFR: 8254326: [lworld] [lw3] Extend definition of empty inline types Message-ID: Please review these changes which extend the runtime definition of empty inline types to also include inline type with only empty non-static fields. This is a first step of an attempt to unify the definition of empty inline types between the runtime and the JITs. Thank you, Fred ------------- Commit messages: - Adjust and comment with JIT code - Unify empty type definition Changes: https://git.openjdk.java.net/valhalla/pull/220/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=220&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254326 Stats: 34 lines in 3 files changed: 17 ins; 6 del; 11 mod Patch: https://git.openjdk.java.net/valhalla/pull/220.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/220/head:pull/220 PR: https://git.openjdk.java.net/valhalla/pull/220 From hseigel at openjdk.java.net Fri Oct 9 17:27:18 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 9 Oct 2020 17:27:18 GMT Subject: [lworld] RFR: 8254326: [lworld] [lw3] Extend definition of empty inline types In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 16:59:15 GMT, Frederic Parain wrote: > Please review these changes which extend the runtime definition of empty inline types to also include inline type with > only empty non-static fields. > This is a first step of an attempt to unify the definition of empty inline types between the runtime and the JITs. > > Thank you, > > Fred The changes look good! ------------- Marked as reviewed by hseigel (Committer). PR: https://git.openjdk.java.net/valhalla/pull/220 From fparain at openjdk.java.net Fri Oct 9 17:54:19 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Fri, 9 Oct 2020 17:54:19 GMT Subject: [lworld] RFR: 8254326: [lworld] [lw3] Extend definition of empty inline types In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 17:24:04 GMT, Harold Seigel wrote: >> Please review these changes which extend the runtime definition of empty inline types to also include inline type with >> only empty non-static fields. >> This is a first step of an attempt to unify the definition of empty inline types between the runtime and the JITs. >> >> Thank you, >> >> Fred > > The changes look good! Harold, Thank you for the review. Fred ------------- PR: https://git.openjdk.java.net/valhalla/pull/220 From fparain at openjdk.java.net Fri Oct 9 17:54:20 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Fri, 9 Oct 2020 17:54:20 GMT Subject: [lworld] Integrated: 8254326: [lworld] [lw3] Extend definition of empty inline types In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 16:59:15 GMT, Frederic Parain wrote: > Please review these changes which extend the runtime definition of empty inline types to also include inline type with > only empty non-static fields. > This is a first step of an attempt to unify the definition of empty inline types between the runtime and the JITs. > > Thank you, > > Fred This pull request has now been integrated. Changeset: e8152142 Author: Frederic Parain URL: https://git.openjdk.java.net/valhalla/commit/e8152142 Stats: 34 lines in 3 files changed: 17 ins; 6 del; 11 mod 8254326: [lworld] [lw3] Extend definition of empty inline types Reviewed-by: hseigel ------------- PR: https://git.openjdk.java.net/valhalla/pull/220 From rriggs at openjdk.java.net Fri Oct 9 17:54:30 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 9 Oct 2020 17:54:30 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal Message-ID: The public constructors of the following classes have been deprecated since SE 9, and should be deprecated for removal in anticipation of these classes becoming inline classes. java.lang.Boolean, Byte, Short, Integer, Long, Float, Double, and Character. Existing uses of the constructors are converted to use the .valueOf(xxx) methods in classes and tests. ------------- Commit messages: - Deprecate primitive wrapper types for 'removal' and related updates Changes: https://git.openjdk.java.net/valhalla/pull/221/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=221&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252180 Stats: 115 lines in 21 files changed: 66 ins; 0 del; 49 mod Patch: https://git.openjdk.java.net/valhalla/pull/221.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/221/head:pull/221 PR: https://git.openjdk.java.net/valhalla/pull/221 From dlsmith at openjdk.java.net Fri Oct 9 20:30:23 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 9 Oct 2020 20:30:23 GMT Subject: RFR: 8254275: Development to revise ValueBased.html for consistency with inline class migration Message-ID: Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients. ------------- Commit messages: - 8254275: Development to revise ValueBased.html for consistency with inline class migration Changes: https://git.openjdk.java.net/valhalla/pull/222/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254275 Stats: 25 lines in 1 file changed: 13 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/valhalla/pull/222.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/222/head:pull/222 PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 9 20:33:22 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 9 Oct 2020 20:33:22 GMT Subject: RFR: 8254275: Development to revise ValueBased.html for consistency with inline class migration In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 20:26:31 GMT, Dan Smith wrote: > Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like > Integer) with deprecated constructors, and clarify expectations for clients. src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 48: > 46: instances, or synchronization on an instances's intrinsic lock; > 47:
  • are considered equal solely based on equals(), not > 48: based on reference equality (==);
  • I removed this bullet because I don't think it really means anything. We already said classes are required not to expose identity through their methods, and to override 'equals' ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 9 20:38:14 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 9 Oct 2020 20:38:14 GMT Subject: RFR: 8254275: Development to revise ValueBased.html for consistency with inline class migration In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 20:26:31 GMT, Dan Smith wrote: > Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like > Integer) with deprecated constructors, and clarify expectations for clients. src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 42: > 40: objects); > 41:
  • extend either Object or a hierarchy of abstract classes that > 42: declare no instance fields and have no instance initialization logic
  • This is new, and is relevant only to suitability for inline class migration. But it's true for all classes that claim to be value-based, so seems like a reasonable thing to state, and a good way to encourage people who care about this concept to structure their API in a migration-friendly way. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From mchung at openjdk.java.net Fri Oct 9 21:04:21 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 9 Oct 2020 21:04:21 GMT Subject: RFR: 8254275: Development to revise ValueBased.html for consistency with inline class migration In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 20:26:31 GMT, Dan Smith wrote: > Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like > Integer) with deprecated constructors, and clarify expectations for clients. > Here are the files that link to ValueBased.html: > > % -> grep -lR "ValueBased.html" src > src/java.base/share/classes/java/util/Map.java > src/java.base/share/classes/java/util/Optional.java > src/java.base/share/classes/java/util/OptionalDouble.java > src/java.base/share/classes/java/util/KeyValueHolder.java > src/java.base/share/classes/java/util/List.java > src/java.base/share/classes/java/util/OptionalInt.java > src/java.base/share/classes/java/util/OptionalLong.java > src/java.base/share/classes/java/util/Set.java > src/java.base/share/classes/java/time/OffsetTime.java > src/java.base/share/classes/java/time/ZonedDateTime.java > src/java.base/share/classes/java/time/Duration.java > src/java.base/share/classes/java/time/Instant.java > src/java.base/share/classes/java/time/chrono/MinguoDate.java > src/java.base/share/classes/java/time/chrono/HijrahDate.java > src/java.base/share/classes/java/time/chrono/JapaneseDate.java > src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java > src/java.base/share/classes/java/time/LocalDateTime.java > src/java.base/share/classes/java/time/LocalTime.java > src/java.base/share/classes/java/time/YearMonth.java > src/java.base/share/classes/java/time/Year.java > src/java.base/share/classes/java/time/MonthDay.java > src/java.base/share/classes/java/time/OffsetDateTime.java > src/java.base/share/classes/java/time/ZoneId.java > src/java.base/share/classes/java/time/LocalDate.java > src/java.base/share/classes/java/time/Period.java > src/java.base/share/classes/java/time/ZoneOffset.java > src/java.base/share/classes/java/lang/ProcessHandle.java > src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java > src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java > src/java.base/share/classes/java/lang/constant/ConstantDesc.java > src/java.base/share/classes/java/lang/Runtime.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MappedMemorySegment.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/GroupLayout.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/PaddingLayout.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SequenceLayout.java This looks fine to me. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 9 21:07:13 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 9 Oct 2020 21:07:13 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: References: Message-ID: <1Oa_KcARb1B50JN7-3nduKc5GGb0sPaNm6LmGEnr4Dc=.874ee251-d8dc-4d89-b6e2-7b8105b01899@github.com> On Fri, 9 Oct 2020 17:49:09 GMT, Roger Riggs wrote: > The public constructors of the following classes have been deprecated since SE 9, and should be deprecated for removal > in anticipation of these classes becoming inline classes. > java.lang.Boolean, Byte, Short, Integer, Long, Float, Double, and Character. > > Existing uses of the constructors are converted to use the .valueOf(xxx) methods in classes and tests. Should change issue number to 8254271, which is targeted to 'repo-valhalla'. (I'm actually not sure what happens if you push with 8252180, which is targeted to 'tbd'...) ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From rriggs at openjdk.java.net Fri Oct 9 21:24:12 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 9 Oct 2020 21:24:12 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: <1Oa_KcARb1B50JN7-3nduKc5GGb0sPaNm6LmGEnr4Dc=.874ee251-d8dc-4d89-b6e2-7b8105b01899@github.com> References: <1Oa_KcARb1B50JN7-3nduKc5GGb0sPaNm6LmGEnr4Dc=.874ee251-d8dc-4d89-b6e2-7b8105b01899@github.com> Message-ID: On Fri, 9 Oct 2020 21:04:54 GMT, Dan Smith wrote: > Should change issue number to 8254271, which is targeted to 'repo-valhalla'. (I'm actually not sure what happens if you > push with 8252180, which is targeted to 'tbd'...) The fields in the bug are just hints for people. The actual push using git is specific to the repo and branch its targeted to. The bugs are updated after the fact by 'hgupdater'. ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From rriggs at openjdk.java.net Fri Oct 9 21:30:19 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 9 Oct 2020 21:30:19 GMT Subject: RFR: 8254275: Development to revise ValueBased.html for consistency with inline class migration In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 20:26:31 GMT, Dan Smith wrote: > Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like > Integer) with deprecated constructors, and clarify expectations for clients. > Here are the files that link to ValueBased.html: > > % -> grep -lR "ValueBased.html" src > src/java.base/share/classes/java/util/Map.java > src/java.base/share/classes/java/util/Optional.java > src/java.base/share/classes/java/util/OptionalDouble.java > src/java.base/share/classes/java/util/KeyValueHolder.java > src/java.base/share/classes/java/util/List.java > src/java.base/share/classes/java/util/OptionalInt.java > src/java.base/share/classes/java/util/OptionalLong.java > src/java.base/share/classes/java/util/Set.java > src/java.base/share/classes/java/time/OffsetTime.java > src/java.base/share/classes/java/time/ZonedDateTime.java > src/java.base/share/classes/java/time/Duration.java > src/java.base/share/classes/java/time/Instant.java > src/java.base/share/classes/java/time/chrono/MinguoDate.java > src/java.base/share/classes/java/time/chrono/HijrahDate.java > src/java.base/share/classes/java/time/chrono/JapaneseDate.java > src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java > src/java.base/share/classes/java/time/LocalDateTime.java > src/java.base/share/classes/java/time/LocalTime.java > src/java.base/share/classes/java/time/YearMonth.java > src/java.base/share/classes/java/time/Year.java > src/java.base/share/classes/java/time/MonthDay.java > src/java.base/share/classes/java/time/OffsetDateTime.java > src/java.base/share/classes/java/time/ZoneId.java > src/java.base/share/classes/java/time/LocalDate.java > src/java.base/share/classes/java/time/Period.java > src/java.base/share/classes/java/time/ZoneOffset.java > src/java.base/share/classes/java/lang/ProcessHandle.java > src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java > src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java > src/java.base/share/classes/java/lang/constant/ConstantDesc.java > src/java.base/share/classes/java/lang/Runtime.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MappedMemorySegment.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/GroupLayout.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/PaddingLayout.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SequenceLayout.java The existing value-based classes do not adhere to the new statements. These changes are re-writing the spec after the fact. Existing classes do not have to be final and can extend anything they want. ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 9 21:39:14 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 9 Oct 2020 21:39:14 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: References: Message-ID: <-BXIlc2Q6Z_r-D4T2JT71CJJtYk18QiSUsHKQ34cCO8=.c1562c32-b474-4d03-a626-2a2cff4e5167@github.com> On Fri, 9 Oct 2020 17:49:09 GMT, Roger Riggs wrote: > The public constructors of the following classes have been deprecated since SE 9, and should be deprecated for removal > in anticipation of these classes becoming inline classes. > java.lang.Boolean, Byte, Short, Integer, Long, Float, Double, and Character. > > Existing uses of the constructors are converted to use the .valueOf(xxx) methods in classes and tests. src/java.base/share/classes/java/lang/invoke/MemberName.java line 776: > 774: > 775: @Override > 776: @SuppressWarnings({"deprecation", "removal"}) What's going to happen to these warning suppressions when we actually remove (make private) the constructors? Is the intent to just defer that problem until it happens? ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From dlsmith at openjdk.java.net Fri Oct 9 21:42:23 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 9 Oct 2020 21:42:23 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: References: <1Oa_KcARb1B50JN7-3nduKc5GGb0sPaNm6LmGEnr4Dc=.874ee251-d8dc-4d89-b6e2-7b8105b01899@github.com> Message-ID: On Fri, 9 Oct 2020 21:22:01 GMT, Roger Riggs wrote: > > Should change issue number to 8254271, which is targeted to 'repo-valhalla'. (I'm actually not sure what happens if you > > push with 8252180, which is targeted to 'tbd'...) > > The fields in the bug are just hints for people. The actual push using git is specific to the repo and branch its > targeted to. The bugs are updated after the fact by 'hgupdater'. Understood. I'm saying it needs to be configured so that 'hgupdater' leaves 8252180 open and closes 8254271. (And I'm unsure of exactly how things will go wrong otherwise. I know sometimes hgupdater will create backport issues...) ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From Roger.Riggs at oracle.com Fri Oct 9 21:46:55 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 9 Oct 2020 17:46:55 -0400 Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: References: <1Oa_KcARb1B50JN7-3nduKc5GGb0sPaNm6LmGEnr4Dc=.874ee251-d8dc-4d89-b6e2-7b8105b01899@github.com> Message-ID: <3f4019be-e53f-be74-e96e-b741aa695d6b@oracle.com> Hg updater updates whatever issue/task id is used in the commit. Having two Jira issues where only one is needed is a bad idea. Roger On 10/9/20 5:42 PM, Dan Smith wrote: > On Fri, 9 Oct 2020 21:22:01 GMT, Roger Riggs wrote: > >>> Should change issue number to 8254271, which is targeted to 'repo-valhalla'. (I'm actually not sure what happens if you >>> push with 8252180, which is targeted to 'tbd'...) >> The fields in the bug are just hints for people. The actual push using git is specific to the repo and branch its >> targeted to. The bugs are updated after the fact by 'hgupdater'. > Understood. > > I'm saying it needs to be configured so that 'hgupdater' leaves 8252180 open and closes 8254271. (And I'm unsure of > exactly how things will go wrong otherwise. I know sometimes hgupdater will create backport issues...) > > ------------- > > PR: https://git.openjdk.java.net/valhalla/pull/221 From rriggs at openjdk.java.net Fri Oct 9 21:48:14 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 9 Oct 2020 21:48:14 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: <-BXIlc2Q6Z_r-D4T2JT71CJJtYk18QiSUsHKQ34cCO8=.c1562c32-b474-4d03-a626-2a2cff4e5167@github.com> References: <-BXIlc2Q6Z_r-D4T2JT71CJJtYk18QiSUsHKQ34cCO8=.c1562c32-b474-4d03-a626-2a2cff4e5167@github.com> Message-ID: <_oqbqWZd0uyEA9XaGtjcHcCWMQF06Jj3uAlPo8l9LCE=.9c8fe036-3bf3-4907-9900-772036ab0e16@github.com> On Fri, 9 Oct 2020 21:36:33 GMT, Dan Smith wrote: >> The public constructors of the following classes have been deprecated since SE 9, and should be deprecated for removal >> in anticipation of these classes becoming inline classes. >> java.lang.Boolean, Byte, Short, Integer, Long, Float, Double, and Character. >> >> Existing uses of the constructors are converted to use the .valueOf(xxx) methods in classes and tests. > > src/java.base/share/classes/java/lang/invoke/MemberName.java line 776: > >> 774: >> 775: @Override >> 776: @SuppressWarnings({"deprecation", "removal"}) > > What's going to happen to these warning suppressions when we actually remove (make private) the constructors? Is the > intent to just defer that problem until it happens? When the code is changed to not use the constructors, the warning (deprecation and remove) should be removed. Some of the code is upstream and requires more changes. ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From darcy at openjdk.java.net Fri Oct 9 23:41:17 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 9 Oct 2020 23:41:17 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 17:49:09 GMT, Roger Riggs wrote: > The public constructors of the following classes have been deprecated since SE 9, and should be deprecated for removal > in anticipation of these classes becoming inline classes. > java.lang.Boolean, Byte, Short, Integer, Long, Float, Double, and Character. > > Existing uses of the constructors are converted to use the .valueOf(xxx) methods in classes and tests. test/jdk/java/lang/WrappersTest.java line 1: > 1: /* We have historically not found it necessary to write tests to verify this kind of change and have instead relied on signature testing. src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLdtd.java line 441: > 439: { > 440: if ( _byName.get( name ) == null ) { > 441: _byName.put( name, new Integer( value ) ); Please make sure @JoeWang-Java reviews the XML changes; there are complications in some areas where the master code is upstream of the code in the JDK. ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From dlsmith at openjdk.java.net Fri Oct 9 23:42:16 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 9 Oct 2020 23:42:16 GMT Subject: RFR: 8254275: Development to revise ValueBased.html for consistency with inline class migration In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 21:27:04 GMT, Roger Riggs wrote: > The existing value-based classes do not adhere to the new statements. > These changes are re-writing the spec after the fact. > Existing classes do not have to be final and can extend anything they want. Yes, this is a deceptively-small-looking change to the spec for a large number of classes. You'll have to clarify which classes you're concerned about, though. I just verified that all of the following classes are both `final` and extend an appropriate superclass: KeyValueHolder, MapN, Map1, SetN, Set12, ListN, List12, Optional, OptionalDouble, OptionalInt, OptionalLong, OffsetTime, ZonedDateTime, Duration, Instant, LocalDateTime, LocalTime, YearMonth, Year, MonthDay, OffsetDateTime, ZoneRegion, ZoneOffset, MinguoDate, HijrahDate, JapaneseDate, ThaiBuddhistDate, ProcessHandleImpl, Runtime.Version (I stopped before digging into the ConstantDesc and foreign classes...) ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From mchung at openjdk.java.net Sat Oct 10 00:08:15 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 10 Oct 2020 00:08:15 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: <_oqbqWZd0uyEA9XaGtjcHcCWMQF06Jj3uAlPo8l9LCE=.9c8fe036-3bf3-4907-9900-772036ab0e16@github.com> References: <-BXIlc2Q6Z_r-D4T2JT71CJJtYk18QiSUsHKQ34cCO8=.c1562c32-b474-4d03-a626-2a2cff4e5167@github.com> <_oqbqWZd0uyEA9XaGtjcHcCWMQF06Jj3uAlPo8l9LCE=.9c8fe036-3bf3-4907-9900-772036ab0e16@github.com> Message-ID: <4pK-Hd324zQa_JLbxeq6Sp-amqQAuu-Jp3iB4OeCuYk=.846da037-6bc0-4133-bf7d-3d6265e62145@github.com> On Fri, 9 Oct 2020 21:45:32 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/lang/invoke/MemberName.java line 776: >> >>> 774: >>> 775: @Override >>> 776: @SuppressWarnings({"deprecation", "removal"}) >> >> What's going to happen to these warning suppressions when we actually remove (make private) the constructors? Is the >> intent to just defer that problem until it happens? > > When the code is changed to not use the constructors, the warning (deprecation and remove) should be removed. > Some of the code is upstream and requires more changes. We should change `MemberName` to call the factory method `Byte::valueof` (that's JDK code). For the Graal change, you are touching the code anyway -- I think changing them to use the factory methods would be better than adding "removal" to the suppression. But it may be better to check if these tests intentionally test with the public constructors to test for JIT optimization before applying the change. ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From mchung at openjdk.java.net Sat Oct 10 00:08:16 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 10 Oct 2020 00:08:16 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 23:35:43 GMT, Joe Darcy wrote: >> The public constructors of the following classes have been deprecated since SE 9, and should be deprecated for removal >> in anticipation of these classes becoming inline classes. >> java.lang.Boolean, Byte, Short, Integer, Long, Float, Double, and Character. >> >> Existing uses of the constructors are converted to use the .valueOf(xxx) methods in classes and tests. > > test/jdk/java/lang/WrappersTest.java line 1: > >> 1: /* > > We have historically not found it necessary to write tests to verify this kind of change and have instead relied on > signature testing. +1. FWIW. You have also verified when you get the warnings from JDK build and needs to suppressed it. ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From mchung at openjdk.java.net Sat Oct 10 01:53:13 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 10 Oct 2020 01:53:13 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 23:38:11 GMT, Joe Darcy wrote: >> The public constructors of the following classes have been deprecated since SE 9, and should be deprecated for removal >> in anticipation of these classes becoming inline classes. >> java.lang.Boolean, Byte, Short, Integer, Long, Float, Double, and Character. >> >> Existing uses of the constructors are converted to use the .valueOf(xxx) methods in classes and tests. > > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLdtd.java line 441: > >> 439: { >> 440: if ( _byName.get( name ) == null ) { >> 441: _byName.put( name, new Integer( value ) ); > > Please make sure @JoeWang-Java reviews the XML changes; there are complications in some areas where the master code is > upstream of the code in the JDK. JAXP was subsumed by JSR 379 in Java SE 9. ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From dlsmith at openjdk.java.net Sat Oct 10 06:32:21 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Sat, 10 Oct 2020 06:32:21 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: <4pK-Hd324zQa_JLbxeq6Sp-amqQAuu-Jp3iB4OeCuYk=.846da037-6bc0-4133-bf7d-3d6265e62145@github.com> References: <-BXIlc2Q6Z_r-D4T2JT71CJJtYk18QiSUsHKQ34cCO8=.c1562c32-b474-4d03-a626-2a2cff4e5167@github.com> <_oqbqWZd0uyEA9XaGtjcHcCWMQF06Jj3uAlPo8l9LCE=.9c8fe036-3bf3-4907-9900-772036ab0e16@github.com> <4pK-Hd324zQa_JLbxeq6Sp-amqQAuu-Jp3iB4OeCuYk=.846da037-6bc0-4133-bf7d-3d6265e62145@github.com> Message-ID: On Fri, 9 Oct 2020 23:54:01 GMT, Mandy Chung wrote: >> When the code is changed to not use the constructors, the warning (deprecation and remove) should be removed. >> Some of the code is upstream and requires more changes. > > We should change `MemberName` to call the factory method `Byte::valueof` (that's JDK code). > > For the Graal change, you are touching the code anyway -- I think changing them to use the factory methods would be > better than adding "removal" to the suppression. But it may be better to check if these tests intentionally test > with the public constructors to test for JIT optimization before applying the change. Yeah, Mandy replied to the question I should have asked: for all the suppressed "removal" points, what is the plan to fix the offending code? If not now, when? ("Later" may be a reasonable answer, but fleshing out the followup tasks would be helpful.) ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From dsimms at openjdk.java.net Mon Oct 12 06:25:23 2020 From: dsimms at openjdk.java.net (David Simms) Date: Mon, 12 Oct 2020 06:25:23 GMT Subject: [lworld] RFR: 8254258: [lworld] [lw3] Inline types layout can be optimized In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 17:31:14 GMT, Frederic Parain wrote: > Please review theses changes optimizing fields layout involving small flattened fields. > The patch also includes a fix for the oop map generation of contended field groups. > > Tested with Mach5, tier1, tier2, tier3 (no regressions compared to actual status of HEAD). > > Thank you, > > Fred Nice layout reorg, change looks good. ------------- Marked as reviewed by dsimms (Committer). PR: https://git.openjdk.java.net/valhalla/pull/218 From thartmann at openjdk.java.net Mon Oct 12 12:04:31 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 12 Oct 2020 12:04:31 GMT Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode [v3] In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 12:00:35 GMT, Roland Westrelin 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. > > 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 requested by thartmann (Committer). test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java line 239: > 237: protected static final String JLONG_ARRAYCOPY = "(.*call_leaf_nofp,runtime jlong_disjoint_arraycopy.*" + END; > 238: protected static final String FIELD_ACCESS = "(.*Field: *" + END; > 239: protected static final String SUBSTITUTABLITY_TEST = START + "CallStaticJava" + MID + > "java.lang.invoke.ValueBootstrapMethods::isSubstitutable" + END; `SUBSTITUTABLITY_TEST` -> `SUBSTITUTABILITY_TEST` test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java line 300: > 298: "-XX:+StressInlineTypeReturnedAsFields"}; > 299: case 3: return new String[] { > 300: "-XX:-UseACmpProfile", We can enable profiling when IR verification is disabled `-DVerifyIR=false`. test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java line 309: > 307: "-XX:+InlineTypeReturnedAsFields"}; > 308: case 4: return new String[] { > 309: "-XX:-UseACmpProfile", We can enable profiling when IR verification is disabled `-DVerifyIR=false`. test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java line 3388: > 3386: } > 3387: > 3388: // acmp doesn't need substitutablity test when one input is known "substitutablity" -> "substitutability" test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java line 3401: > 3399: } > 3400: > 3401: // acmp doesn't need substitutablity test when one input null "substitutablity" -> "substitutability" src/hotspot/cpu/x86/templateTable_x86.cpp line 2500: > 2498: __ andptr(rbx, Address(rax, oopDesc::mark_offset_in_bytes())); > 2499: __ andptr(rbx, is_inline_type_mask); > 2500: __ cmpptr(rbx, is_inline_type_mask); Good catch! src/hotspot/share/c1/c1_Instruction.hpp line 2730: > 2728: Value right() const { return _right; } > 2729: bool left_maybe_null() const { return _left_maybe_null; } > 2730: bool right_maybe_null() const { return _right_maybe_null; } Indentation looks weird. src/hotspot/share/oops/methodData.hpp line 397: > 395: virtual bool is_SpeculativeTrapData()const { return false; } > 396: virtual bool is_ArrayLoadStoreData() const { return false; } > 397: virtual bool is_ACmpData() const { return false; } Indentation is wrong. src/hotspot/share/opto/c2_globals.hpp line 784: > 782: \ > 783: product(bool, UseACmpProfile, false, \ > 784: "Take advantage of profiling at acmp") \ Why not enable it by default? src/hotspot/share/opto/parse2.cpp line 2180: > 2178: } > 2179: > 2180: void Parse::do_acmp(BoolTest::mask btest, Node* right, Node* left) { `Node* left, Node* right` seems more natural. Also in the code below, where `right` is processed first. src/hotspot/share/opto/parse2.cpp line 2313: > 2311: } > 2312: if (!left_inline_type) { > 2313: // Comparison with an object of known not to be an inline type Should be "object ~~of~~ known" src/hotspot/share/opto/parse2.cpp line 2318: > 2316: } > 2317: if (!right_inline_type) { > 2318: // Comparison with an object of known not to be an inline type Should be "object ~~of~~ known" ------------- PR: https://git.openjdk.java.net/valhalla/pull/185 From roland at openjdk.java.net Mon Oct 12 13:08:38 2020 From: roland at openjdk.java.net (Roland Westrelin) Date: Mon, 12 Oct 2020 13:08:38 GMT Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode [v4] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/185/files - new: https://git.openjdk.java.net/valhalla/pull/185/files/01b00395..b88029c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=185&range=03 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=185&range=02-03 Stats: 58 lines in 7 files changed: 0 ins; 2 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 roland at openjdk.java.net Mon Oct 12 13:16:34 2020 From: roland at openjdk.java.net (Roland Westrelin) Date: Mon, 12 Oct 2020 13:16:34 GMT Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode [v5] In-Reply-To: References: Message-ID: > 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 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: review ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/185/files - new: https://git.openjdk.java.net/valhalla/pull/185/files/b88029c6..60561b7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=185&range=04 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=185&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 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 roland at openjdk.java.net Mon Oct 12 13:16:38 2020 From: roland at openjdk.java.net (Roland Westrelin) Date: Mon, 12 Oct 2020 13:16:38 GMT Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode [v3] In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 12:01:18 GMT, Tobias Hartmann wrote: >> 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 requested by thartmann (Committer). @TobiHartmann thanks for the review. I fixed the things you spotted and made this on by default. ------------- PR: https://git.openjdk.java.net/valhalla/pull/185 From roland at openjdk.java.net Mon Oct 12 13:32:36 2020 From: roland at openjdk.java.net (Roland Westrelin) Date: Mon, 12 Oct 2020 13:32:36 GMT Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode [v6] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: more review ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/185/files - new: https://git.openjdk.java.net/valhalla/pull/185/files/60561b7d..2de9555f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=185&range=05 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=185&range=04-05 Stats: 12 lines in 1 file changed: 2 ins; 2 del; 8 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 Mon Oct 12 13:32:36 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 12 Oct 2020 13:32:36 GMT Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode [v6] In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 13:30:04 GMT, Roland Westrelin 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. > > Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision: > > more review Thanks for making these changes. Looks good to me. ------------- Marked as reviewed by thartmann (Committer). PR: https://git.openjdk.java.net/valhalla/pull/185 From roland at openjdk.java.net Mon Oct 12 13:32:36 2020 From: roland at openjdk.java.net (Roland Westrelin) Date: Mon, 12 Oct 2020 13:32:36 GMT Subject: [lworld] RFR: 8235914: [lworld] Profile acmp bytecode [v6] In-Reply-To: References: Message-ID: <4nM1P5O8XWE5_8tj84C6tPHkZV9vsZcTyQ-mdLgu9k0=.cc383ab0-2eba-4d3b-b14a-7c06656b1d28@github.com> On Mon, 12 Oct 2020 13:26:51 GMT, Tobias Hartmann wrote: > Thanks for making these changes. Looks good to me. Thanks for the review. ------------- PR: https://git.openjdk.java.net/valhalla/pull/185 From roland at openjdk.java.net Mon Oct 12 13:32:37 2020 From: roland at openjdk.java.net (Roland Westrelin) Date: Mon, 12 Oct 2020 13:32:37 GMT Subject: [lworld] Integrated: 8235914: [lworld] Profile acmp bytecode In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 07:58:46 GMT, Roland Westrelin 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. This pull request has now been integrated. Changeset: 378279c9 Author: Roland Westrelin URL: https://git.openjdk.java.net/valhalla/commit/378279c9 Stats: 1261 lines in 44 files changed: 1133 ins; 59 del; 69 mod 8235914: [lworld] Profile acmp bytecode Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/valhalla/pull/185 From fparain at openjdk.java.net Tue Oct 13 12:09:24 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Tue, 13 Oct 2020 12:09:24 GMT Subject: [lworld] RFR: 8254258: [lworld] [lw3] Inline types layout can be optimized In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 06:22:56 GMT, David Simms wrote: >> Please review theses changes optimizing fields layout involving small flattened fields. >> The patch also includes a fix for the oop map generation of contended field groups. >> >> Tested with Mach5, tier1, tier2, tier3 (no regressions compared to actual status of HEAD). >> >> Thank you, >> >> Fred > > Nice layout reorg, change looks good. David, Thank you for the review. Fred ------------- PR: https://git.openjdk.java.net/valhalla/pull/218 From fparain at openjdk.java.net Tue Oct 13 12:13:29 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Tue, 13 Oct 2020 12:13:29 GMT Subject: [lworld] Integrated: 8254258: [lworld] [lw3] Inline types layout can be optimized In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 17:31:14 GMT, Frederic Parain wrote: > Please review theses changes optimizing fields layout involving small flattened fields. > The patch also includes a fix for the oop map generation of contended field groups. > > Tested with Mach5, tier1, tier2, tier3 (no regressions compared to actual status of HEAD). > > Thank you, > > Fred This pull request has now been integrated. Changeset: 85f6d5b6 Author: Frederic Parain URL: https://git.openjdk.java.net/valhalla/commit/85f6d5b6 Stats: 118 lines in 2 files changed: 53 ins; 33 del; 32 mod 8254258: [lworld] [lw3] Inline types layout can be optimized Reviewed-by: dsimms ------------- PR: https://git.openjdk.java.net/valhalla/pull/218 From rriggs at openjdk.java.net Tue Oct 13 14:35:26 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 13 Oct 2020 14:35:26 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: References: <-BXIlc2Q6Z_r-D4T2JT71CJJtYk18QiSUsHKQ34cCO8=.c1562c32-b474-4d03-a626-2a2cff4e5167@github.com> <_oqbqWZd0uyEA9XaGtjcHcCWMQF06Jj3uAlPo8l9LCE=.9c8fe036-3bf3-4907-9900-772036ab0e16@github.com> <4pK-Hd324zQa_JLbxeq6Sp-amqQAuu-Jp3iB4OeCuYk=.846da037-6bc0-4133-bf7d-3d6265e62145@github.com> Message-ID: <7-QLmOXNMjvh7Ge5pbmCurvr9JZHcxs-HisOCA67um8=.686a3c0c-4dcb-4177-b40a-843c5a06345e@github.com> On Sat, 10 Oct 2020 06:29:48 GMT, Dan Smith wrote: >> We should change `MemberName` to call the factory method `Byte::valueof` (that's JDK code). >> >> For the Graal change, you are touching the code anyway -- I think changing them to use the factory methods would be >> better than adding "removal" to the suppression. But it may be better to check if these tests intentionally test >> with the public constructors to test for JIT optimization before applying the change. > > Yeah, Mandy replied to the question I should have asked: for all the suppressed "removal" points, what is the plan to > fix the offending code? If not now, when? ("Later" may be a reasonable answer, but fleshing out the followup tasks > would be helpful.) The comment in MemberName makes it clear that `hashCode` method may be called *before* the cache is setup and `valueOf` uses the cache. ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From rriggs at openjdk.java.net Tue Oct 13 14:40:28 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 13 Oct 2020 14:40:28 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: References: Message-ID: On Sat, 10 Oct 2020 00:03:24 GMT, Mandy Chung wrote: >> test/jdk/java/lang/WrappersTest.java line 1: >> >>> 1: /* >> >> We have historically not found it necessary to write tests to verify this kind of change and have instead relied on >> signature testing. > > +1. > > FWIW. You have also verified when you get the warnings from JDK build and needs to suppressed it. The test can be removed but was a double check that all of the constructors of the named classes had been modified. ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From rriggs at openjdk.java.net Tue Oct 13 14:40:29 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 13 Oct 2020 14:40:29 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: <7-QLmOXNMjvh7Ge5pbmCurvr9JZHcxs-HisOCA67um8=.686a3c0c-4dcb-4177-b40a-843c5a06345e@github.com> References: <-BXIlc2Q6Z_r-D4T2JT71CJJtYk18QiSUsHKQ34cCO8=.c1562c32-b474-4d03-a626-2a2cff4e5167@github.com> <_oqbqWZd0uyEA9XaGtjcHcCWMQF06Jj3uAlPo8l9LCE=.9c8fe036-3bf3-4907-9900-772036ab0e16@github.com> <4pK-Hd324zQa_JLbxeq6Sp-amqQAuu-Jp3iB4OeCuYk=.846da037-6bc0-4133-bf7d-3d6265e62145@github.com> <7-QLmOXNMjvh7Ge5pbmCurvr9JZHcxs-HisOCA67um8=.686a3c0c-4dcb-4177-b40a-843c5a06345e@github.com> Message-ID: On Tue, 13 Oct 2020 14:32:10 GMT, Roger Riggs wrote: >> Yeah, Mandy replied to the question I should have asked: for all the suppressed "removal" points, what is the plan to >> fix the offending code? If not now, when? ("Later" may be a reasonable answer, but fleshing out the followup tasks >> would be helpful.) > > The comment in MemberName makes it clear that `hashCode` method may be called *before* the cache is setup and `valueOf` > uses the cache. Its up to the Graal folks to replace their code. In some cases, they are depending on Identity semantics of new Integer(). ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From rriggs at openjdk.java.net Tue Oct 13 15:13:22 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 13 Oct 2020 15:13:22 GMT Subject: RFR: 8254275: Development to revise ValueBased.html for consistency with inline class migration In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 23:39:53 GMT, Dan Smith wrote: >> The existing value-based classes do not adhere to the new statements. >> These changes are re-writing the spec after the fact. >> Existing classes do not have to be final and can extend anything they want. > >> The existing value-based classes do not adhere to the new statements. >> These changes are re-writing the spec after the fact. >> Existing classes do not have to be final and can extend anything they want. > > Yes, this is a deceptively-small-looking change to the spec for a large number of classes. > > You'll have to clarify which classes you're concerned about, though. I just verified that all of the following classes > are both `final` and extend an appropriate superclass: > KeyValueHolder, MapN, Map1, SetN, Set12, ListN, List12, Optional, OptionalDouble, OptionalInt, OptionalLong, > OffsetTime, ZonedDateTime, Duration, Instant, LocalDateTime, LocalTime, YearMonth, Year, MonthDay, OffsetDateTime, > ZoneRegion, ZoneOffset, MinguoDate, HijrahDate, JapaneseDate, ThaiBuddhistDate, ProcessHandleImpl, Runtime.Version (I > stopped before digging into the ConstantDesc and foreign classes...) I was most concerned about the primitive wrapper classes, that are not currently specified to be value based (currently do not have references to ValueBased.html or similar statements). The existing classes wrapper classes have some explicit identity requirements in the JLS. Adding the @ValueBased annotation, with a javadoc reference to the updated ValueBased.html would be a specification change. For JEP 390, the intention is to enable warnings, not to change the specification. So either the @ValueBased annotation is weaker than a spec change or the link to ValueBased.html must be a future aspirational statement, not a link to a current specification requirement. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From mchung at openjdk.java.net Tue Oct 13 16:42:30 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 13 Oct 2020 16:42:30 GMT Subject: RFR: 8254275: Development to revise ValueBased.html for consistency with inline class migration In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 15:10:25 GMT, Roger Riggs wrote: > For JEP 390, the intention is to enable warnings, not to change the specification. So either the @ValueBased annotation is weaker than a spec change or the link to ValueBased.html must be a future aspirational statement, not a link to a current specification requirement. I guess you may be concerning about the potential compatibility risks by this proposed spec change. Of course JEP 390 can make spec change if discussed and agreed. There is no behavioral change to the primitive wrapper classes except the warnings are emitted if `synchronized` on these wrapper objects. @RogerRiggs can you clarify more what you are concerned about? ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From rriggs at openjdk.java.net Tue Oct 13 17:29:29 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 13 Oct 2020 17:29:29 GMT Subject: RFR: 8254275: Development to revise ValueBased.html for consistency with inline class migration In-Reply-To: References: Message-ID: <2e0mDtMO-UL8FRTNjWA2-qSa-N0adsxnMvfKgBkT2X0=.3563aea1-3d41-4e9b-b91f-81b15ae88a30@github.com> On Tue, 13 Oct 2020 16:39:33 GMT, Mandy Chung wrote: >> I was most concerned about the primitive wrapper classes, that are not currently specified to be value based (currently >> do not have references to ValueBased.html or similar statements). The existing classes wrapper classes have some >> explicit identity requirements in the JLS. Adding the @ValueBased annotation, with a javadoc reference to the updated >> ValueBased.html would be a specification change. For JEP 390, the intention is to enable warnings, not to change the >> specification. So either the @ValueBased annotation is weaker than a spec change or the link to ValueBased.html must >> be a future aspirational statement, not a link to a current specification requirement. > >> For JEP 390, the intention is to enable warnings, not to change the specification. > So either the @ValueBased annotation is weaker than a spec change or the link to ValueBased.html must be a future > aspirational statement, not a link to a current specification requirement. > I guess you may be concerning about the potential compatibility risks by this proposed spec change. Of course JEP 390 > can make spec change if discussed and agreed. There is no behavioral change to the primitive wrapper classes except > the warnings are emitted if `synchronized` on these wrapper objects. @RogerRiggs can you clarify more what you are > concerned about? Yes, the compatibility concern is foremost. We don't intend to change the behavior (yet) so the exact language used to describe what is being changed is important. A simple assertion that Integer is ValueBased breaks compatibility. The JLS requirement for reference equality for small values is at odds with ValueBased. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Tue Oct 13 17:58:26 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 13 Oct 2020 17:58:26 GMT Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal In-Reply-To: References: <1Oa_KcARb1B50JN7-3nduKc5GGb0sPaNm6LmGEnr4Dc=.874ee251-d8dc-4d89-b6e2-7b8105b01899@github.com> Message-ID: On Fri, 9 Oct 2020 21:39:44 GMT, Dan Smith wrote: >>> Should change issue number to 8254271, which is targeted to 'repo-valhalla'. (I'm actually not sure what happens if you >>> push with 8252180, which is targeted to 'tbd'...) >> >> The fields in the bug are just hints for people. The actual push using git is specific to the repo and branch its >> targeted to. The bugs are updated after the fact by 'hgupdater'. > >> > Should change issue number to 8254271, which is targeted to 'repo-valhalla'. (I'm actually not sure what happens if you >> > push with 8252180, which is targeted to 'tbd'...) >> >> The fields in the bug are just hints for people. The actual push using git is specific to the repo and branch its >> targeted to. The bugs are updated after the fact by 'hgupdater'. > > Understood. > > I'm saying it needs to be configured so that 'hgupdater' leaves 8252180 open and closes 8254271. (And I'm unsure of > exactly how things will go wrong otherwise. I know sometimes hgupdater will create backport issues...) Clarification on integration behavior: The model is that each pull to `valhalla` or `jdk` needs a separate bugid. That's the workflow we need to follow unless we can flesh out and get tooling support for an alternative model. I'm asking that 8252180 be reserved for the `jdk` pull and for the CSR. And that all pulls to `valhalla` use bugids of subtasks of that issue, such as 8254271. Robin says if you push with bugid 8252180 (which is targeted to 'tbd'), the issue will be closed, disrupting its use for the `jdk` pull and CSR. He will consider adding a guard that warns about the mismatch of JBS target and PR target to prevent this sort of accident. ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From rriggs at openjdk.java.net Tue Oct 13 18:15:25 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 13 Oct 2020 18:15:25 GMT Subject: RFR: 8254271: Development to deprecate wrapper class constructors for removal In-Reply-To: References: <1Oa_KcARb1B50JN7-3nduKc5GGb0sPaNm6LmGEnr4Dc=.874ee251-d8dc-4d89-b6e2-7b8105b01899@github.com> Message-ID: On Tue, 13 Oct 2020 17:55:08 GMT, Dan Smith wrote: >>> > Should change issue number to 8254271, which is targeted to 'repo-valhalla'. (I'm actually not sure what happens if you >>> > push with 8252180, which is targeted to 'tbd'...) >>> >>> The fields in the bug are just hints for people. The actual push using git is specific to the repo and branch its >>> targeted to. The bugs are updated after the fact by 'hgupdater'. >> >> Understood. >> >> I'm saying it needs to be configured so that 'hgupdater' leaves 8252180 open and closes 8254271. (And I'm unsure of >> exactly how things will go wrong otherwise. I know sometimes hgupdater will create backport issues...) > > Clarification on integration behavior: > > The model is that each pull to `valhalla` or `jdk` needs a separate bugid. That's the workflow we need to follow unless > we can flesh out and get tooling support for an alternative model. > I'm asking that 8252180 be reserved for the `jdk` pull and for the CSR. And that all pulls to `valhalla` use bugids of > subtasks of that issue, such as 8254271. > Robin says if you push with bugid 8252180 (which is targeted to 'tbd'), the issue will be closed, disrupting its use > for the `jdk` pull and CSR. He will consider adding a guard that warns about the mismatch of JBS target and PR target > to prevent this sort of accident. The CSR for this change will be made against 8252180 ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From mchung at openjdk.java.net Tue Oct 13 19:07:24 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 13 Oct 2020 19:07:24 GMT Subject: RFR: 8254271: Development to deprecate wrapper class constructors for removal In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 17:49:09 GMT, Roger Riggs wrote: > The public constructors of the following classes have been deprecated since SE 9, and should be deprecated for removal > in anticipation of these classes becoming inline classes. > java.lang.Boolean, Byte, Short, Integer, Long, Float, Double, and Character. > > Existing uses of the constructors are converted to use the .valueOf(xxx) methods in classes and tests. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From mchung at openjdk.java.net Tue Oct 13 19:07:25 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 13 Oct 2020 19:07:25 GMT Subject: RFR: 8254271: Development to deprecate wrapper class constructors for removal In-Reply-To: References: <-BXIlc2Q6Z_r-D4T2JT71CJJtYk18QiSUsHKQ34cCO8=.c1562c32-b474-4d03-a626-2a2cff4e5167@github.com> <_oqbqWZd0uyEA9XaGtjcHcCWMQF06Jj3uAlPo8l9LCE=.9c8fe036-3bf3-4907-9900-772036ab0e16@github.com> <4pK-Hd324zQa_JLbxeq6Sp-amqQAuu-Jp3iB4OeCuYk=.846da037-6bc0-4133-bf7d-3d6265e62145@github.com> <7-QLmOXNMjvh7Ge5pbmCurvr9JZHcxs-HisOCA67um8=.686a3c0c-4dcb-4177-b40a-843c5a06345e@github.com> Message-ID: <9mv85P2kmzeFTmmCM1DulvcYlpgdcNtS0uWZxOoJcQ0=.723635b9-e916-4332-80b9-7c9b9796b066@github.com> On Tue, 13 Oct 2020 14:37:35 GMT, Roger Riggs wrote: >> The comment in MemberName makes it clear that `hashCode` method may be called *before* the cache is setup and `valueOf` >> uses the cache. > > Its up to the Graal folks to replace their code. In some cases, they are depending on Identity semantics of new > Integer(). Thanks for the clarification. Can you file a JBS issue to Graal to make change in its upstream project? ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From dlsmith at openjdk.java.net Tue Oct 13 19:43:26 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 13 Oct 2020 19:43:26 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers In-Reply-To: <2e0mDtMO-UL8FRTNjWA2-qSa-N0adsxnMvfKgBkT2X0=.3563aea1-3d41-4e9b-b91f-81b15ae88a30@github.com> References: <2e0mDtMO-UL8FRTNjWA2-qSa-N0adsxnMvfKgBkT2X0=.3563aea1-3d41-4e9b-b91f-81b15ae88a30@github.com> Message-ID: <6THoj2noYHgs4a15LjBUntfssaGDacxx74vd2sJ4z4Q=.00ab37c5-3813-408e-9e34-5eea84db1c21@github.com> On Tue, 13 Oct 2020 17:26:41 GMT, Roger Riggs wrote: >>> For JEP 390, the intention is to enable warnings, not to change the specification. >> So either the @ValueBased annotation is weaker than a spec change or the link to ValueBased.html must be a future >> aspirational statement, not a link to a current specification requirement. >> I guess you may be concerning about the potential compatibility risks by this proposed spec change. Of course JEP 390 >> can make spec change if discussed and agreed. There is no behavioral change to the primitive wrapper classes except >> the warnings are emitted if `synchronized` on these wrapper objects. @RogerRiggs can you clarify more what you are >> concerned about? > > Yes, the compatibility concern is foremost. We don't intend to change the behavior (yet) so the exact language used to > describe what is being changed is important. A simple assertion that Integer is ValueBased breaks compatibility. The > JLS requirement for reference equality for small values is at odds with ValueBased. To clarify my thinking on the identity/cacheing behavior of wrappers: - Integer should claim to be a value-based class. I've made that part of this issue, and will include it in another iteration of the code. - ValueBased.html needs to allow for factory methods that guarantee consistent identity for at least some results. It's okay to relax the definition of "value-based class" in this way?it doesn't change the contract of other value-based classes' factories, just gives them the option to do cacheing if they want. - When Integer becomes a primitive class, the consistent identity guarantee of `Integer.valueOf` will continue to be true, and will extend to the full domain of Integers. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From rriggs at openjdk.java.net Tue Oct 13 19:52:23 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 13 Oct 2020 19:52:23 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers In-Reply-To: <6THoj2noYHgs4a15LjBUntfssaGDacxx74vd2sJ4z4Q=.00ab37c5-3813-408e-9e34-5eea84db1c21@github.com> References: <2e0mDtMO-UL8FRTNjWA2-qSa-N0adsxnMvfKgBkT2X0=.3563aea1-3d41-4e9b-b91f-81b15ae88a30@github.com> <6THoj2noYHgs4a15LjBUntfssaGDacxx74vd2sJ4z4Q=.00ab37c5-3813-408e-9e34-5eea84db1c21@github.com> Message-ID: On Tue, 13 Oct 2020 19:40:06 GMT, Dan Smith wrote: >> Yes, the compatibility concern is foremost. We don't intend to change the behavior (yet) so the exact language used to >> describe what is being changed is important. A simple assertion that Integer is ValueBased breaks compatibility. The >> JLS requirement for reference equality for small values is at odds with ValueBased. > > To clarify my thinking on the identity/cacheing behavior of wrappers: > > - Integer should claim to be a value-based class. I've made that part of this issue, and will include it in another > iteration of the code. > > - ValueBased.html needs to allow for factory methods that guarantee consistent identity for at least some results. It's > okay to relax the definition of "value-based class" in this way?it doesn't change the contract of other value-based > classes' factories, just gives them the option to do cacheing if they want. > > - When Integer becomes a primitive class, the consistent identity guarantee of `Integer.valueOf` will continue to be > true, and will extend to the full domain of Integers. Byte, Short, Integer, and Long all have caches for small values. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Tue Oct 13 19:52:23 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 13 Oct 2020 19:52:23 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers In-Reply-To: References: <2e0mDtMO-UL8FRTNjWA2-qSa-N0adsxnMvfKgBkT2X0=.3563aea1-3d41-4e9b-b91f-81b15ae88a30@github.com> <6THoj2noYHgs4a15LjBUntfssaGDacxx74vd2sJ4z4Q=.00ab37c5-3813-408e-9e34-5eea84db1c21@github.com> Message-ID: On Tue, 13 Oct 2020 19:47:44 GMT, Roger Riggs wrote: >> To clarify my thinking on the identity/cacheing behavior of wrappers: >> >> - Integer should claim to be a value-based class. I've made that part of this issue, and will include it in another >> iteration of the code. >> >> - ValueBased.html needs to allow for factory methods that guarantee consistent identity for at least some results. It's >> okay to relax the definition of "value-based class" in this way?it doesn't change the contract of other value-based >> classes' factories, just gives them the option to do cacheing if they want. >> >> - When Integer becomes a primitive class, the consistent identity guarantee of `Integer.valueOf` will continue to be >> true, and will extend to the full domain of Integers. > > Byte, Short, Integer, and Long all have caches for small values. Yes, understood. I was using Integer as an example, but the above should apply to all of those classes. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From rriggs at openjdk.java.net Tue Oct 13 20:35:24 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 13 Oct 2020 20:35:24 GMT Subject: RFR: 8254271: Development to deprecate wrapper class constructors for removal In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 19:04:31 GMT, Mandy Chung wrote: >> The public constructors of the following classes have been deprecated since SE 9, and should be deprecated for removal >> in anticipation of these classes becoming inline classes. >> java.lang.Boolean, Byte, Short, Integer, Long, Float, Double, and Character. >> >> Existing uses of the constructors are converted to use the .valueOf(xxx) methods in classes and tests. > > Marked as reviewed by mchung (Reviewer). Please review the CSR for 8252180, to be used for the integration CSR 8254324: [JEP 390] Deprecate wrapper class constructors for removal ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From dlsmith at openjdk.java.net Tue Oct 13 21:43:27 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 13 Oct 2020 21:43:27 GMT Subject: RFR: 8254271: Development to deprecate wrapper class constructors for removal In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 20:32:46 GMT, Roger Riggs wrote: >> Marked as reviewed by mchung (Reviewer). > > Please review the CSR for 8252180, to be used for the integration > > CSR 8254324: [JEP 390] Deprecate wrapper class constructors for removal Have you considered rephrasing the reference to constructors in the `valueOf` methods?: * If a new {@code Byte} instance is not required, this method * should generally be used in preference to the constructor * {@link #Byte(byte)} The message now is "Don't use the constructors! Don't try to get a new instance!" ------------- PR: https://git.openjdk.java.net/valhalla/pull/221 From dlsmith at openjdk.java.net Tue Oct 13 22:59:36 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 13 Oct 2020 22:59:36 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: Message-ID: > Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like > Integer) with deprecated constructors, and clarify expectations for clients. > Here are the files that link to ValueBased.html: > > % -> grep -lR "ValueBased.html" src > src/java.base/share/classes/java/util/Map.java > src/java.base/share/classes/java/util/Optional.java > src/java.base/share/classes/java/util/OptionalDouble.java > src/java.base/share/classes/java/util/KeyValueHolder.java > src/java.base/share/classes/java/util/List.java > src/java.base/share/classes/java/util/OptionalInt.java > src/java.base/share/classes/java/util/OptionalLong.java > src/java.base/share/classes/java/util/Set.java > src/java.base/share/classes/java/time/OffsetTime.java > src/java.base/share/classes/java/time/ZonedDateTime.java > src/java.base/share/classes/java/time/Duration.java > src/java.base/share/classes/java/time/Instant.java > src/java.base/share/classes/java/time/chrono/MinguoDate.java > src/java.base/share/classes/java/time/chrono/HijrahDate.java > src/java.base/share/classes/java/time/chrono/JapaneseDate.java > src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java > src/java.base/share/classes/java/time/LocalDateTime.java > src/java.base/share/classes/java/time/LocalTime.java > src/java.base/share/classes/java/time/YearMonth.java > src/java.base/share/classes/java/time/Year.java > src/java.base/share/classes/java/time/MonthDay.java > src/java.base/share/classes/java/time/OffsetDateTime.java > src/java.base/share/classes/java/time/ZoneId.java > src/java.base/share/classes/java/time/LocalDate.java > src/java.base/share/classes/java/time/Period.java > src/java.base/share/classes/java/time/ZoneOffset.java > src/java.base/share/classes/java/lang/ProcessHandle.java > src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java > src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java > src/java.base/share/classes/java/lang/constant/ConstantDesc.java > src/java.base/share/classes/java/lang/Runtime.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MappedMemorySegment.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/GroupLayout.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/PaddingLayout.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SequenceLayout.java Dan Smith has updated the pull request incrementally with one additional commit since the last revision: Revise definition for more flexible ==. Apply revised boilerplate to wrappers and existing references. ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/222/files - new: https://git.openjdk.java.net/valhalla/pull/222/files/5ae32ad8..0b97d4ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=00-01 Stats: 265 lines in 46 files changed: 70 ins; 32 del; 163 mod Patch: https://git.openjdk.java.net/valhalla/pull/222.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/222/head:pull/222 PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Tue Oct 13 22:59:36 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 13 Oct 2020 22:59:36 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: <2e0mDtMO-UL8FRTNjWA2-qSa-N0adsxnMvfKgBkT2X0=.3563aea1-3d41-4e9b-b91f-81b15ae88a30@github.com> <6THoj2noYHgs4a15LjBUntfssaGDacxx74vd2sJ4z4Q=.00ab37c5-3813-408e-9e34-5eea84db1c21@github.com> Message-ID: On Tue, 13 Oct 2020 19:49:11 GMT, Dan Smith wrote: >> Byte, Short, Integer, and Long all have caches for small values. > > Yes, understood. I was using Integer as an example, but the above should apply to all of those classes. New revision: I updated the definition, especially with respect to `==`, and applied the boilerplate to the wrapper classes. I realized the changed definition requires changing the boilerplate everywhere, so I've done so, fixing up all the references to `ValueBased.html`. Please be hyper-critical of the boilerplate text, as this appears in lots of places?it's worth getting it just right. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Tue Oct 13 23:19:23 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 13 Oct 2020 23:19:23 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: <2e0mDtMO-UL8FRTNjWA2-qSa-N0adsxnMvfKgBkT2X0=.3563aea1-3d41-4e9b-b91f-81b15ae88a30@github.com> <6THoj2noYHgs4a15LjBUntfssaGDacxx74vd2sJ4z4Q=.00ab37c5-3813-408e-9e34-5eea84db1c21@github.com> Message-ID: On Tue, 13 Oct 2020 22:55:02 GMT, Dan Smith wrote: >> Yes, understood. I was using Integer as an example, but the above should apply to all of those classes. > > New revision: I updated the definition, especially with respect to `==`, and applied the boilerplate to the wrapper > classes. I realized the changed definition requires changing the boilerplate everywhere, so I've done so, fixing up all > the references to `ValueBased.html`. Please be hyper-critical of the boilerplate text, as this appears in lots of > places?it's worth getting it just right. I added a link to a docs build in the summary. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From john.r.rose at oracle.com Wed Oct 14 18:02:13 2020 From: john.r.rose at oracle.com (John Rose) Date: Wed, 14 Oct 2020 12:02:13 -0600 Subject: factoring InstanceKlass for species, template, classfile, _klass, etc. Message-ID: This morning some of us had an excellent conversation about the role of `InstanceKlass` in the JVM after we start wiring up flattening and scalarization information. Here are some thoughts about it. 1. `InstanceKlass` today serves triple duty: (a) It records the contents of a loaded classfile plus resolution states, (b) it represents a ?live type? (a sort of `Klass) in the JVM internals, and (c) it is the pointer in the header of an instance of an object (when it has a header!). 2. The name `InstanceKlass` is tilted towards 1(c), the ?thing in the instance header?. 3. Specialized instances comprise a ?binding?, a composition of (alpha) a loaded template class, and (beta) a collection of parametric arguments. 4. This suggests that `SpeciesKlass` and `TemplateKlass` are possible entities in the JVM (both <: `Klass`), and/or that 1(a) `ClassFileInfo` and 1(b) `SpeciesKlass` (<: `Klass`), and maybe even 1(c) `InstanceKlassInfo` are types we could introduce to represent new stuff and/or refactorings of old stuff. 5. Backing up, in reality today?s `InstanceKlass` has three aspects, which we should give provisional names for: 1(a) information on a loaded class file (cf. JVMS 4.1. The ClassFile Structure), 1(b) a live type (the C++ super `Klass`), and 1(c) the `_klass` field in the header. I like to distinguish 1(c) because there are very special rules for working with the `_klass` field, which are distinct from its role in 1(b). Also, I?d like to use the term ?plain class? (or the more high-falutin? ?invariant class?) to mean ?a regular old class which is free of any template stuff?. 6. FTR, I (currently) think that factoring out the classfile structure is the efficient move, so today?s `InstanceKlass` (N.B. whether it is renamed to `PlainKlass` or not!) points to a (unique) `ClassFileStructure`, while tomorrow?s `SpeciesKlass` points to a shared (by multiple species) `ClassFileStructure` which contains template stuff derived from its class file. 7. In the grand scheme of things, I don?t see a need or motivation to factor out a new type `TemplateClassFileStructure` from (the extended) `ClassFileStructure`, any more than we have a distinction between `InterfaceInstanceKlass` and `ClassInstanceKlass`. It?s all one classfile format in the JVM, I assume, for now. (If we decide to use a completely different file format for templates, then, yes, a new C++ data structure should reflect that decision. But it seems very likely we?ll add templating on top of class file structure, not as a new file type.) 8. Thus: `ClassFileStructure` would contain everything known/knowable when a `.class` file is loaded. It?s constant pool ?stuff? is associated with today?s resolution states. 9. And: we add an indirection to `InstanceKlass` to point to all the `ClassFileStructure` goodness. Perhaps it goes via the constant pool (for purlely technical reasons, to cut out an indirection on some fast paths). Perhaps (again for purely technical reasons) some of the `ClassFileStructure` is copied or hoisted into the `InstanceKlass`, for fast path access. 10. Then we add `SpeciesKlass` which points to whatever a parameter binding is (I call it `ParameterBinding` in my draft), *plus* a `ClassFileStructure`. 11. Probably `SpeciesKlass` is a subtype of `InstanceKlass`, not merely of `Klass`. In that case maybe there?s another type `PlainKlass`, or (more likely) `InstanceKlass` has the obvious pointer to `ClassFileStructure` and `SpeciesKlass` *extends* that. 12. There?s potentially a temporary advantage to having `_klass` point to a restricted type, such as `ClassFileStructure`, and having a second word (optional, injected only in species instances) point to the parameter binding. I?m on the fence about this, given all of the above. From rriggs at openjdk.java.net Wed Oct 14 20:21:25 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 14 Oct 2020 20:21:25 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 22:59:36 GMT, Dan Smith wrote: >> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like >> Integer) with deprecated constructors, and clarify expectations for clients. >> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Revise definition for more flexible ==. Apply revised boilerplate to wrappers and existing references. In the text referring to ValueBase.html in many classes: Is the "," misplaced. Should it read: "not use instances for synchronization or unpredictable behavior may occur." If the comment in each class was a simple reference to ValueBased, it would be easier to maintain and there would be less duplication between lots of classes and the explanation in ValueBased.html. src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 43: > 41: hashCode, and toString which are computed > 42: solely from the instance's state and not from its identity or the state > 43: of any other object or variable; Quibble on pre-existing text: If the instance state is a reference to another object, can its hashCode be included in the hashCode? The " not... from the state of any object" would seem to prohibit that. src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 49: > 47: the behavior of the class's methods; > 48: > 49:
  • perform no synchronization on an instance's intrinsic lock;
  • "Intrinsic lock": should be a more concrete reference to some term in the JLS or JVMS. src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 52: > 50:
  • do not have (or have deprecated any) accessible constructors;
  • > 51:
  • may support instance creation through factory methods that do not > 52: promise a unique identity for each invocation?in particular, each factory Since the factory method are in a value-based classes, they are not allowed to promise a unique identity. So that statement is always true in the value-based context. Use "," instead of "-" or start a new sentence. src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 55: > 53: method must allow for the possibility that if two independently-produced > 54: instances are equal according to equals(), they may also be > 55: equal according to ==; Is using "may" a way to allow contradiction of the previous requirements? Otherwise, in a spec, any statement using 'may' can be ignored or removed, it does not specify any behavior either required or disallowed. src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 70: > 68:

    Synchronization on instances of value-based classes is strongly discouraged, > 69: because the programmer cannot usually guarantee unique ownership of the > 70: associated lock.

    I don't think the phrase: `because the programmer cannot usually guarantee unique ownership of the associated lock.` adds anything and is obscure. Until the semantics of object change, there is no change in the synchronization behavior. For Valhalla value-based instances, there is explicitly no (implicitly) associated lock, so synchronization is illegal. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From github.com+213212+jodastephen at openjdk.java.net Fri Oct 16 10:32:24 2020 From: github.com+213212+jodastephen at openjdk.java.net (Stephen Colebourne) Date: Fri, 16 Oct 2020 10:32:24 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 22:59:36 GMT, Dan Smith wrote: >> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like >> Integer) with deprecated constructors, and clarify expectations for clients. >> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Revise definition for more flexible ==. Apply revised boilerplate to wrappers and existing references. src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 35: > 33: > 34: Some classes, such as java.lang.Integer and > 35: java.time.LocalDateTime, are value-based. `LocalDate` is a better examplar than `LocalDateTime` because `LocalDate` is much more widely used. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From david.simms at oracle.com Fri Oct 16 10:50:23 2020 From: david.simms at oracle.com (David Simms) Date: Fri, 16 Oct 2020 12:50:23 +0200 Subject: Valhalla repository status Message-ID: <9f27e258-5ba1-0928-f38d-588f5eb1066a@oracle.com> Greetings, Some new branches have appeared in the Valhalla project repository, so here's a short summary of the state of the active branches[1]. "master": automatically synchronized from "openjdk/jdk" [2] (a.k.a. mainline), read-only "jep390": branched from "master", warnings for value-based classes[4], intended as preparatory warnings pre-Valhalla (does not contain any Valhalla features). "lworld": current prototype of "Primitive Objects", as described by "State of Valhalla" documents [3] "type-restrictions": branched from "lworld", an experiment in specialization /D [1] https://github.com/openjdk/valhalla/branches [2] https://github.com/openjdk/jdk [3] http://cr.openjdk.java.net/~briangoetz/valhalla/sov/ [4] https://openjdk.java.net/jeps/390 From thartmann at openjdk.java.net Fri Oct 16 11:16:32 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 16 Oct 2020 11:16:32 GMT Subject: [lworld] RFR: 8254888: [lworld] Remove dead code from array property checking Message-ID: There's still some dead code left after we've removed array property checking with JDK-8244931. ------------- Commit messages: - 8254888: [lworld] Remove dead code from array property checking Changes: https://git.openjdk.java.net/valhalla/pull/224/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=224&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254888 Stats: 104 lines in 6 files changed: 0 ins; 104 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/224.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/224/head:pull/224 PR: https://git.openjdk.java.net/valhalla/pull/224 From thartmann at openjdk.java.net Fri Oct 16 12:00:56 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 16 Oct 2020 12:00:56 GMT Subject: git: openjdk/valhalla: lworld: 8254888: [lworld] Remove dead code from array property checking Message-ID: Changeset: 9b39695b Author: Tobias Hartmann Date: 2020-10-16 12:00:25 +0000 URL: https://git.openjdk.java.net/valhalla/commit/9b39695b 8254888: [lworld] Remove dead code from array property checking ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/runtime/vmStructs.cpp From thartmann at openjdk.java.net Fri Oct 16 12:03:20 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 16 Oct 2020 12:03:20 GMT Subject: [lworld] Integrated: 8254888: [lworld] Remove dead code from array property checking In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 11:10:46 GMT, Tobias Hartmann wrote: > There's still some dead code left after we've removed array property checking with JDK-8244931. This pull request has now been integrated. Changeset: 9b39695b Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/9b39695b Stats: 104 lines in 6 files changed: 0 ins; 104 del; 0 mod 8254888: [lworld] Remove dead code from array property checking ------------- PR: https://git.openjdk.java.net/valhalla/pull/224 From thartmann at openjdk.java.net Fri Oct 16 13:16:25 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 16 Oct 2020 13:16:25 GMT Subject: [lworld] RFR: 8254898: [lworld] TestArrayAccessDeopt fails with RuntimeException: 'Uncommon trap occurred' Message-ID: Test should disable UseArrayLoadStoreProfile (which was enabled by default with JDK-8252030). ------------- Commit messages: - 8254898: [lworld] TestArrayAccessDeopt fails with RuntimeException: 'Uncommon trap occurred' Changes: https://git.openjdk.java.net/valhalla/pull/225/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=225&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254898 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/225.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/225/head:pull/225 PR: https://git.openjdk.java.net/valhalla/pull/225 From thartmann at openjdk.java.net Fri Oct 16 13:30:25 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 16 Oct 2020 13:30:25 GMT Subject: git: openjdk/valhalla: lworld: 8254898: [lworld] TestArrayAccessDeopt fails with RuntimeException: 'Uncommon trap occurred' Message-ID: Changeset: a89eba31 Author: Tobias Hartmann Date: 2020-10-16 13:29:59 +0000 URL: https://git.openjdk.java.net/valhalla/commit/a89eba31 8254898: [lworld] TestArrayAccessDeopt fails with RuntimeException: 'Uncommon trap occurred' ! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrayAccessDeopt.java From thartmann at openjdk.java.net Fri Oct 16 13:33:20 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 16 Oct 2020 13:33:20 GMT Subject: [lworld] Integrated: 8254898: [lworld] TestArrayAccessDeopt fails with RuntimeException: 'Uncommon trap occurred' In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 13:11:02 GMT, Tobias Hartmann wrote: > Test should disable UseArrayLoadStoreProfile (which was enabled by default with JDK-8252030). This pull request has now been integrated. Changeset: a89eba31 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/a89eba31 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8254898: [lworld] TestArrayAccessDeopt fails with RuntimeException: 'Uncommon trap occurred' ------------- PR: https://git.openjdk.java.net/valhalla/pull/225 From hseigel at openjdk.java.net Fri Oct 16 14:00:24 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 16 Oct 2020 14:00:24 GMT Subject: [lworld] RFR: 8254891: [lworld] runtime/valhalla/inlinetypes/UnsafeTest.java fails with flattening disabled Message-ID: Please review this small fix for test UnsafeTest.java. The test depends on flattening being enable so this fix adds options -XX:FlatArrayElementMaxSize=-1 -XX:InlineFieldMaxFlatSize=-1 to ensure flattening is enabled. Thanks, Harold ------------- Commit messages: - 8254891: [lworld] runtime/valhalla/inlinetypes/UnsafeTest.java fails with flattening disabled Changes: https://git.openjdk.java.net/valhalla/pull/226/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=226&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254891 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/226.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/226/head:pull/226 PR: https://git.openjdk.java.net/valhalla/pull/226 From fparain at openjdk.java.net Fri Oct 16 14:00:24 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Fri, 16 Oct 2020 14:00:24 GMT Subject: [lworld] RFR: 8254891: [lworld] runtime/valhalla/inlinetypes/UnsafeTest.java fails with flattening disabled In-Reply-To: References: Message-ID: <7NKK_QM2eEApXLl2ucigImNkf9Eq6Anjwd2csDS1uRk=.586e483e-764a-4e02-bd2d-2b6f7a7a8282@github.com> On Fri, 16 Oct 2020 13:55:02 GMT, Harold Seigel wrote: > Please review this small fix for test UnsafeTest.java. The test depends on flattening being enable so this fix adds > options -XX:FlatArrayElementMaxSize=-1 -XX:InlineFieldMaxFlatSize=-1 to ensure flattening is enabled. > Thanks, Harold Looks good to me. Fred ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.java.net/valhalla/pull/226 From hseigel at openjdk.java.net Fri Oct 16 14:12:22 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 16 Oct 2020 14:12:22 GMT Subject: git: openjdk/valhalla: lworld: 8254891: [lworld] runtime/valhalla/inlinetypes/UnsafeTest.java fails with flattening disabled Message-ID: <89cd653b-50d7-4d4b-a0e2-613555e2ba15@openjdk.org> Changeset: e8a9d251 Author: Harold Seigel Date: 2020-10-16 14:11:30 +0000 URL: https://git.openjdk.java.net/valhalla/commit/e8a9d251 8254891: [lworld] runtime/valhalla/inlinetypes/UnsafeTest.java fails with flattening disabled Reviewed-by: fparain ! test/hotspot/jtreg/runtime/valhalla/inlinetypes/UnsafeTest.java From hseigel at openjdk.java.net Fri Oct 16 14:15:24 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 16 Oct 2020 14:15:24 GMT Subject: [lworld] Integrated: 8254891: [lworld] runtime/valhalla/inlinetypes/UnsafeTest.java fails with flattening disabled In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 13:55:02 GMT, Harold Seigel wrote: > Please review this small fix for test UnsafeTest.java. The test depends on flattening being enable so this fix adds > options -XX:FlatArrayElementMaxSize=-1 -XX:InlineFieldMaxFlatSize=-1 to ensure flattening is enabled. > Thanks, Harold This pull request has now been integrated. Changeset: e8a9d251 Author: Harold Seigel URL: https://git.openjdk.java.net/valhalla/commit/e8a9d251 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8254891: [lworld] runtime/valhalla/inlinetypes/UnsafeTest.java fails with flattening disabled Reviewed-by: fparain ------------- PR: https://git.openjdk.java.net/valhalla/pull/226 From dsimms at openjdk.java.net Fri Oct 16 15:08:18 2020 From: dsimms at openjdk.java.net (David Simms) Date: Fri, 16 Oct 2020 15:08:18 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge tag 'jdk-16+20' # Conflicts: # src/hotspot/cpu/x86/frame_x86.cpp # src/hotspot/share/classfile/classFileParser.cpp # src/hotspot/share/opto/cfgnode.hpp # src/hotspot/share/runtime/thread.cpp ------------- Commit messages: - Merge tag 'jdk-16+20' into lworld_merge_jdk_16_20 - 8249623: test @ignore-d due to 7013634 should be returned back to execution - 8254345: com/sun/jdi/JdwpAttachTest.java reports error incorrectly - 8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum - 8254775: Microbenchmark StringIndexOfChar doesn't compile - 8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar - 8254744: Clean-up CodeBlob::align_code_offset - 8173585: Intrinsify StringLatin1.indexOf(char) - 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp - 8254748: Bad Copyright header format after JDK-8212218 - ... and 102 more: https://git.openjdk.java.net/valhalla/compare/85f6d5b6...99696d60 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=227&range=00.0 - jdk: https://webrevs.openjdk.java.net/?repo=valhalla&pr=227&range=00.1 Changes: https://git.openjdk.java.net/valhalla/pull/227/files Stats: 22363 lines in 573 files changed: 13396 ins; 5024 del; 3943 mod Patch: https://git.openjdk.java.net/valhalla/pull/227.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/227/head:pull/227 PR: https://git.openjdk.java.net/valhalla/pull/227 From dsimms at openjdk.java.net Fri Oct 16 15:19:59 2020 From: dsimms at openjdk.java.net (David Simms) Date: Fri, 16 Oct 2020 15:19:59 GMT Subject: [lworld] RFR: Merge jdk [v2] In-Reply-To: References: Message-ID: > Merge tag 'jdk-16+20' > > # Conflicts: > # src/hotspot/cpu/x86/frame_x86.cpp > # src/hotspot/share/classfile/classFileParser.cpp > # src/hotspot/share/opto/cfgnode.hpp > # src/hotspot/share/runtime/thread.cpp David Simms has updated the pull request incrementally with 25 additional commits since the last revision: - Merge commit '5145bed0282575a580cf3ebc343038c1dc8ddb8d' into lworld_merge_jdk_16_20 - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows Reviewed-by: shade, ccheung - 8254369: Node::disconnect_inputs may skip precedences disconnect_inputs() needs to iterate precedences edges in reverse order because rm_prec(i) may backfill _in[i] with a value afterward. also remove the predicate if (n != NULL) in set_prec because it's always true. Reviewed-by: kvn, redestad - 8251325: Miss 'L' for long value in if statement Reviewed-by: iklam - 8254192: ExtraSharedClassListFile contains extra white space at end of line Reviewed-by: iklam, ccheung, mchung - 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs Reviewed-by: dholmes, dcubed, stuefe - 8254811: JDK-8254158 broke ppc64, s390 builds Reviewed-by: stuefe, goetz - 8249878: jfr_emergency_dump has secondary crashes Reviewed-by: egahlin - 8254674: G1: Improve root location reference to dead obj verification message Reviewed-by: sjohanss, lkorinth - 8254719: ZGC: Clean up includes Reviewed-by: stefank - ... and 15 more: https://git.openjdk.java.net/valhalla/compare/99696d60...63391b87 ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/227/files - new: https://git.openjdk.java.net/valhalla/pull/227/files/99696d60..63391b87 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=227&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=227&range=00-01 Stats: 296921 lines in 439 files changed: 294014 ins; 1482 del; 1425 mod Patch: https://git.openjdk.java.net/valhalla/pull/227.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/227/head:pull/227 PR: https://git.openjdk.java.net/valhalla/pull/227 From dsimms at openjdk.java.net Fri Oct 16 15:26:57 2020 From: dsimms at openjdk.java.net (David Simms) Date: Fri, 16 Oct 2020 15:26:57 GMT Subject: [lworld] RFR: Merge jdk [v3] In-Reply-To: References: Message-ID: <8DycvoN3LzcIRRhG-F1W4PczpBS2OqW79MrQT4h4ock=.4ffaba3b-f266-4292-8f72-3d2175e657ed@github.com> > Merge tag 'jdk-16+20' > > # Conflicts: > # src/hotspot/cpu/x86/frame_x86.cpp > # src/hotspot/share/classfile/classFileParser.cpp > # src/hotspot/share/opto/cfgnode.hpp > # src/hotspot/share/runtime/thread.cpp David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 138 commits: - Merge - Merge commit '5145bed0282575a580cf3ebc343038c1dc8ddb8d' into lworld_merge_jdk_16_20 - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows Reviewed-by: shade, ccheung - 8254369: Node::disconnect_inputs may skip precedences disconnect_inputs() needs to iterate precedences edges in reverse order because rm_prec(i) may backfill _in[i] with a value afterward. also remove the predicate if (n != NULL) in set_prec because it's always true. Reviewed-by: kvn, redestad - 8251325: Miss 'L' for long value in if statement Reviewed-by: iklam - 8254192: ExtraSharedClassListFile contains extra white space at end of line Reviewed-by: iklam, ccheung, mchung - 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs Reviewed-by: dholmes, dcubed, stuefe - 8254811: JDK-8254158 broke ppc64, s390 builds Reviewed-by: stuefe, goetz - 8249878: jfr_emergency_dump has secondary crashes Reviewed-by: egahlin - 8254674: G1: Improve root location reference to dead obj verification message Reviewed-by: sjohanss, lkorinth - ... and 128 more: https://git.openjdk.java.net/valhalla/compare/e8a9d251...60cbb25e ------------- Changes: https://git.openjdk.java.net/valhalla/pull/227/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=227&range=02 Stats: 319376 lines in 944 files changed: 307469 ins; 6565 del; 5342 mod Patch: https://git.openjdk.java.net/valhalla/pull/227.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/227/head:pull/227 PR: https://git.openjdk.java.net/valhalla/pull/227 From dsimms at openjdk.java.net Fri Oct 16 17:01:18 2020 From: dsimms at openjdk.java.net (David Simms) Date: Fri, 16 Oct 2020 17:01:18 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 14:59:37 GMT, David Simms wrote: > Merge tag 'jdk-16+20' > > # Conflicts: > # src/hotspot/cpu/x86/frame_x86.cpp > # src/hotspot/share/classfile/classFileParser.cpp > # src/hotspot/share/opto/cfgnode.hpp > # src/hotspot/share/runtime/thread.cpp This pull request has now been integrated. Changeset: b9bec068 Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/b9bec068 Stats: 319376 lines in 944 files changed: 307469 ins; 6565 del; 5342 mod Merge jdk Merge tag 'jdk-16+20' ------------- PR: https://git.openjdk.java.net/valhalla/pull/227 From dlsmith at openjdk.java.net Fri Oct 16 17:20:28 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 16 Oct 2020 17:20:28 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 20:18:11 GMT, Roger Riggs wrote: > In the text referring to ValueBase.html in many classes: > > Is the "," misplaced. Should it read: > "not use instances for synchronization or unpredictable behavior may occur." Grammatically, it's a compound sentence. Two statements: 1) programmers should do some stuff; 2) otherwise, unpredictable behavior. The comma helps to communicate where the "parentheses" go: (1a && 1b) || 2. But I think you may be concerned that the "unpredictable behavior" only applies to the synchronization part of (1), not the "interchangeable" part? It's my intent that it applies to both. If you try to distinguish between instances with ==, or do synchronization, behavior will be unpredictable (because it's possible things that were != yesterday will be == today, per the rules about factories). > If the comment in each class was a simple reference to ValueBased, it would be easier to maintain and there would be > less duplication between lots of classes and the explanation in ValueBased.html. Yes. This approach of scattering boilerplate throughout the API is not optimized for maintainability. But that's okay, because change will not be frequent, and meanwhile it's optimized for getting readers' attention instead. I would worry that if we stripped out all the boilerplate and just had a link, most readers wouldn't follow the link or appreciate what it meant. > src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 43: > >> 41: hashCode, and toString which are computed >> 42: solely from the instance's state and not from its identity or the state >> 43: of any other object or variable;
  • > > Quibble on pre-existing text: > > If the instance state is a reference to another object, can its hashCode be included in the hashCode? > The " not... from the state of any object" would seem to prohibit that. Perhaps "not from its identity or the state of any other object or variable that is not part of the instance's state"? > src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 49: > >> 47: the behavior of the class's methods; >> 48: >> 49:
  • perform no synchronization on an instance's intrinsic lock;
  • > > "Intrinsic lock": should be a more concrete reference to some term in the JLS or JVMS. "perform no synchronization using an instance's monitor" (aligns with terminology in JLS 17.1) ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 16 17:29:24 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 16 Oct 2020 17:29:24 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: Message-ID: <3zTJrJBArrsj9OfnoLyRuCVq2iMGFe2OdL8OkiiDd7o=.4f8b70ea-5691-4b28-961c-b4f54b5d1b79@github.com> On Wed, 14 Oct 2020 19:29:59 GMT, Roger Riggs wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Revise definition for more flexible ==. Apply revised boilerplate to wrappers and existing references. > > src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 52: > >> 50:
  • do not have (or have deprecated any) accessible constructors;
  • >> 51:
  • may support instance creation through factory methods that do not >> 52: promise a unique identity for each invocation?in particular, each factory > > Since the factory method are in a value-based classes, they are not allowed to promise a unique identity. > So that statement is always true in the value-based context. > > Use "," instead of "-" or start a new sentence. "Not allowed to promise a unique identity" based on what? Which other bullet in this list? There's the assertion about being "freely substitutable", but that doesn't mean a factory method can't promise to create a new instance on every invocation. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 16 17:32:24 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 16 Oct 2020 17:32:24 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: Message-ID: <2lbF5iq03RIG_RUdQbePQ8jEBvL4Rb4CRRvP4MXpj9o=.7dbf12b3-fb2b-4505-b28d-f4dd93c61f5e@github.com> On Wed, 14 Oct 2020 20:03:44 GMT, Roger Riggs wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Revise definition for more flexible ==. Apply revised boilerplate to wrappers and existing references. > > src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 55: > >> 53: method must allow for the possibility that if two independently-produced >> 54: instances are equal according to equals(), they may also be >> 55: equal according to ==; > > Is using "may" a way to allow contradiction of the previous requirements? > Otherwise, in a spec, any statement using 'may' can be ignored or removed, it does not specify any behavior either > required or disallowed. What I'm going for is "may declare factory methods, and if they do then...". But you're right, it doesn't work as written. I'll rephrase. (Why not require a factory method? Because a class could also just define a handful of named instances, enum-style, and not expose any factory-like behavior. Boolean is almost an example of this, although it does have a 'valueOf' method, too.) ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 16 17:38:21 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 16 Oct 2020 17:38:21 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 20:08:32 GMT, Roger Riggs wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Revise definition for more flexible ==. Apply revised boilerplate to wrappers and existing references. > > src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 70: > >> 68:

    Synchronization on instances of value-based classes is strongly discouraged, >> 69: because the programmer cannot usually guarantee unique ownership of the >> 70: associated lock.

    > > I don't think the phrase: > `because the programmer cannot usually guarantee unique ownership of the associated lock.` > adds anything and is obscure. Until the semantics of object change, there is no change in the synchronization behavior. > For Valhalla value-based instances, there is explicitly no (implicitly) associated lock, so synchronization is illegal. The point is that if you can't prove you have a unique identity (per the factory method clause), then you can't guarantee that you have exclusive control over the monitor, so synchronization is dangerous. A variant of the text discouraging synchronization was there before any design discussions about primitive object semantics. I added "usually" because of the possibility that someone can prove that a field value they provide is unique (according to 'equals') and thus can prove that the value-based class instance is also unique. But when I think about actual examples of value-based classes, that seems quite unlikely, and it would probably be clearer to remove the "usually". ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 16 17:56:20 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 16 Oct 2020 17:56:20 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 17:15:58 GMT, Dan Smith wrote: >> src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 43: >> >>> 41: hashCode, and toString which are computed >>> 42: solely from the instance's state and not from its identity or the state >>> 43: of any other object or variable;
  • >> >> Quibble on pre-existing text: >> >> If the instance state is a reference to another object, can its hashCode be included in the hashCode? >> The " not... from the state of any object" would seem to prohibit that. > > Perhaps "not from its identity or the state of any other object or variable that is not part of the instance's state"? Eh, the "any other object or variable" clause is too strong. What about a `toString` based on `System.lineSeparator()` or something like that? Seems like it's trying too hard to prohibit some kind of workaround to mutable state. But I think "computed solely" already communicates that pretty clearly. How about just: "which are computed solely from the values of the class's instance fields (and properties of the objects they reference), not from the instance's identity" ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 16 18:34:33 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 16 Oct 2020 18:34:33 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v3] In-Reply-To: References: Message-ID: <_d4x3mRh3GahVXMCdGFI3bv0J48hi0KmC4GnHAUmS-Q=.30ee041d-204b-4dbf-8fbe-b9ad62abff96@github.com> > Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like > Integer) with deprecated constructors, and clarify expectations for clients. > Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html Dan Smith has updated the pull request incrementally with one additional commit since the last revision: Addressing review comments in ValueBased.html ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/222/files - new: https://git.openjdk.java.net/valhalla/pull/222/files/0b97d4ab..2f13d535 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=02 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=01-02 Stats: 12 lines in 1 file changed: 0 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/valhalla/pull/222.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/222/head:pull/222 PR: https://git.openjdk.java.net/valhalla/pull/222 From rriggs at openjdk.java.net Fri Oct 16 21:11:16 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 16 Oct 2020 21:11:16 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v3] In-Reply-To: <_d4x3mRh3GahVXMCdGFI3bv0J48hi0KmC4GnHAUmS-Q=.30ee041d-204b-4dbf-8fbe-b9ad62abff96@github.com> References: <_d4x3mRh3GahVXMCdGFI3bv0J48hi0KmC4GnHAUmS-Q=.30ee041d-204b-4dbf-8fbe-b9ad62abff96@github.com> Message-ID: <1mascak3V6UbW35t70TpdLj95vhuIlBZGGk_DgNcWQM=.6383c17a-611b-4894-bf17-89214b8e7b7b@github.com> On Fri, 16 Oct 2020 18:34:33 GMT, Dan Smith wrote: >> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like >> Integer) with deprecated constructors, and clarify expectations for clients. >> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review comments in ValueBased.html src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 49: > 47: the behavior of the class's methods; > 48:
  • perform no synchronization using an instance's monitor;
  • > 49:
  • do not have (or have deprecated any) accessible constructors;
  • Having an accessible constructor should not be prohibited. Constructors do not imply or contradict the other constraints. And when we get to Valhalla, primitive classes are allowed to have accessible constructors. At least for the time being, the wrapper classes DO have accessible constructors; if the constraint is retained, then Integer, etc cannot be value-based. src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 51: > 49:
  • do not have (or have deprecated any) accessible constructors;
  • > 50:
  • do not provide any other instance creation mechanism that promises > 51: a unique identity on each method call—in particular, any factory The mdash came out as "?" in the javadoc. src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 55: > 53: instances are equal according to equals(), they may also be > 54: equal according to ==;
  • > 55:
  • are final;
  • It might be useful to be able to mark an abstract class as @ValueBased to document that it is part of an intended ValueBased class hierarchy. Perhaps add "or be abstract". src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 68: > 66:

    Synchronization on instances of value-based classes is strongly discouraged, > 67: because the programmer cannot guarantee exclusive ownership of the > 68: associated monitor.

    Duplicates the requirements in the bullet list. The bullet list seems too long and the statements are not all orthogonal, making it a bit less clear. Suggestion: - Combine bullet for class is final, with the first bullet requiring final fields. - combing the bullets on substitutability and equality, defining substtitutability in terms of the methods. If the paragraph above is kept, move it to before the bullet list, using the bullet list at the details that explain the more general understanding of value-based. The last sentence is still problematic. For current usage, there is a monitor. For Valhalla, there is no monitor and it will be a runtime error. I don't think exclusive ownership comes into it. And it duplicates an item in the bullet list. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 16 22:01:16 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 16 Oct 2020 22:01:16 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v3] In-Reply-To: <1mascak3V6UbW35t70TpdLj95vhuIlBZGGk_DgNcWQM=.6383c17a-611b-4894-bf17-89214b8e7b7b@github.com> References: <_d4x3mRh3GahVXMCdGFI3bv0J48hi0KmC4GnHAUmS-Q=.30ee041d-204b-4dbf-8fbe-b9ad62abff96@github.com> <1mascak3V6UbW35t70TpdLj95vhuIlBZGGk_DgNcWQM=.6383c17a-611b-4894-bf17-89214b8e7b7b@github.com> Message-ID: On Fri, 16 Oct 2020 20:44:25 GMT, Roger Riggs wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing review comments in ValueBased.html > > src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 49: > >> 47: the behavior of the class's methods; >> 48:
  • perform no synchronization using an instance's monitor;
  • >> 49:
  • do not have (or have deprecated any) accessible constructors;
  • > > Having an accessible constructor should not be prohibited. > Constructors do not imply or contradict the other constraints. > And when we get to Valhalla, primitive classes are allowed to have accessible constructors. > At least for the time being, the wrapper classes DO have accessible constructors; if the constraint is retained, then > Integer, etc cannot be value-based. The idea behind all the instance creation restrictions is this: clients of value-based classes should never be promised a unique, private identity associated with any instances they are given. By designing the API in this way, we discourage clients from inappropriate dependencies on identity, and pave the way for the classes to more smoothly migrate to be primitive classes someday. Yes, primitive classes can have public constructors. But if a *migrated* primitive class has a public constructor, its clients will face binary and behavioral incompatibilities when the migration happens. If clients are using factories that don't promise unique identities, and aren't doing risky synchronization on objects they don't uniquely control, they will encounter neither of those incompatibilities. The "or have deprecated any" rule allows for classes like the wrapper classes that do have accessible constructors, but have used deprecation to discourage clients from using them. Deprecation is a strong enough signal that when clients face future incompatibilities, they will have been sufficiently warned. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 16 22:05:22 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 16 Oct 2020 22:05:22 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v3] In-Reply-To: <1mascak3V6UbW35t70TpdLj95vhuIlBZGGk_DgNcWQM=.6383c17a-611b-4894-bf17-89214b8e7b7b@github.com> References: <_d4x3mRh3GahVXMCdGFI3bv0J48hi0KmC4GnHAUmS-Q=.30ee041d-204b-4dbf-8fbe-b9ad62abff96@github.com> <1mascak3V6UbW35t70TpdLj95vhuIlBZGGk_DgNcWQM=.6383c17a-611b-4894-bf17-89214b8e7b7b@github.com> Message-ID: <2l1WEOFi5jCL-s6aWd-2Qfe0PnTr0dYBizcasbzouCc=.c6742061-2497-46e9-b832-90837302bdf1@github.com> On Fri, 16 Oct 2020 20:51:26 GMT, Roger Riggs wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing review comments in ValueBased.html > > src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 51: > >> 49:
  • do not have (or have deprecated any) accessible constructors;
  • >> 50:
  • do not provide any other instance creation mechanism that promises >> 51: a unique identity on each method call—in particular, any factory > > The mdash came out as "?" in the javadoc. Hmm. That's annoying. In what context? Worked okay when I did a `make docs`... Are character entities *supposed* to work? Or is the coding convention to stick strictly to ASCII? ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 16 22:08:23 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 16 Oct 2020 22:08:23 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v3] In-Reply-To: <1mascak3V6UbW35t70TpdLj95vhuIlBZGGk_DgNcWQM=.6383c17a-611b-4894-bf17-89214b8e7b7b@github.com> References: <_d4x3mRh3GahVXMCdGFI3bv0J48hi0KmC4GnHAUmS-Q=.30ee041d-204b-4dbf-8fbe-b9ad62abff96@github.com> <1mascak3V6UbW35t70TpdLj95vhuIlBZGGk_DgNcWQM=.6383c17a-611b-4894-bf17-89214b8e7b7b@github.com> Message-ID: On Fri, 16 Oct 2020 20:54:19 GMT, Roger Riggs wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing review comments in ValueBased.html > > src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 55: > >> 53: instances are equal according to equals(), they may also be >> 54: equal according to ==;
  • >> 55:
  • are final;
  • > > It might be useful to be able to mark an abstract class as @ValueBased to document that it is part of an intended > ValueBased class hierarchy. Perhaps add "or be abstract". The way this has been handled until now is to say "all implementing classes should be value-based" in the abstract class's (or factory method's) javadoc. In terms of prose, that seems to get the job done, without needing to complicate the definition of *value-based class*. For the annotation, yes the intent is that it will be applied both to value-based classes and to abstract classes/interfaces that require all implementing classes to be value-based. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 16 22:46:16 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 16 Oct 2020 22:46:16 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v3] In-Reply-To: <1mascak3V6UbW35t70TpdLj95vhuIlBZGGk_DgNcWQM=.6383c17a-611b-4894-bf17-89214b8e7b7b@github.com> References: <_d4x3mRh3GahVXMCdGFI3bv0J48hi0KmC4GnHAUmS-Q=.30ee041d-204b-4dbf-8fbe-b9ad62abff96@github.com> <1mascak3V6UbW35t70TpdLj95vhuIlBZGGk_DgNcWQM=.6383c17a-611b-4894-bf17-89214b8e7b7b@github.com> Message-ID: On Fri, 16 Oct 2020 21:07:09 GMT, Roger Riggs wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing review comments in ValueBased.html > > src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 68: > >> 66:

    Synchronization on instances of value-based classes is strongly discouraged, >> 67: because the programmer cannot guarantee exclusive ownership of the >> 68: associated monitor.

    > > Duplicates the requirements in the bullet list. > The bullet list seems too long and the statements are not all orthogonal, making it a bit less clear. > Suggestion: > - Combine bullet for class is final, with the first bullet requiring final fields. > - combing the bullets on substitutability and equality, defining substtitutability in terms of the methods. > > If the paragraph above is kept, move it to before the bullet list, using the bullet list at the details that explain > the more general understanding of value-based. > The last sentence is still problematic. For current usage, there is a monitor. > For Valhalla, there is no monitor and it will be a runtime error. I don't think exclusive ownership comes into it. > And it duplicates an item in the bullet list. I'll revise to clarify that the bulleted list is about properties of the class declaration, while the subsequent sentences are constraints on/advice to clients. (Is there a better way to talk about clients than "a program should not..."? "Programmer", "client", "user" all kind of work, but I don't love any of them...) With that distinction in mind, I don't think the client stuff works very well until we first define what we mean by "value-based class". I did remove what seemed to me like a redundant bullet from the original list (see my earlier comment). With what's left, each one is trying to say something distinct, although maybe some rephrasing in certain places could help. The `final` class and field restrictions were combined before, but I split them because they're two very different constraints?one about extension, the other about immutability. (It's not ideal that Java uses the same keyword for both properties.) Actually, though, it works pretty well to combine the final class restriction with the superclass restriction, leaving one bullet all about subclassing. I'll do that. The bullets that talk about equality are saying 1) the class needs an appropriate equals/hashCode/toString; 2) the class's instance methods don't have distinct behaviors for instances that are `equals`; 3) the class's factories do not promise distinct identities for instances that are `equals`. Those are three distinct things to say; I'm not seeing a clear way to combine them. Synchronization: forget primitive classes. This is advice to current clients of value-based classes. And the advice is: don't synchronize, because you can't be sure someone else isn't doing the same on the same object. This is advice that is relevant to current clients without asking them to imagine a future in which the Object & monitor model has changed. Yet the implication is the same: don't do it. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 16 22:51:31 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 16 Oct 2020 22:51:31 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v4] In-Reply-To: References: Message-ID: > Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like > Integer) with deprecated constructors, and clarify expectations for clients. > Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html Dan Smith has updated the pull request incrementally with one additional commit since the last revision: Addressing additional review comments for ValueBased.html ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/222/files - new: https://git.openjdk.java.net/valhalla/pull/222/files/2f13d535..3288f433 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=03 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=02-03 Stats: 17 lines in 1 file changed: 0 ins; 1 del; 16 mod Patch: https://git.openjdk.java.net/valhalla/pull/222.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/222/head:pull/222 PR: https://git.openjdk.java.net/valhalla/pull/222 From dlsmith at openjdk.java.net Fri Oct 16 23:02:16 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 16 Oct 2020 23:02:16 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 17:13:10 GMT, Dan Smith wrote: >> In the text referring to ValueBase.html in many classes: >> >> Is the "," misplaced. Should it read: >> "not use instances for synchronization or unpredictable behavior may occur." >> >> If the comment in each class was a simple reference to ValueBased, it would be easier to maintain and there would be >> less duplication between lots of classes and the explanation in ValueBased.html. > >> In the text referring to ValueBase.html in many classes: >> >> Is the "," misplaced. Should it read: >> "not use instances for synchronization or unpredictable behavior may occur." > > Grammatically, it's a compound sentence. Two statements: 1) programmers should do some stuff; 2) otherwise, > unpredictable behavior. The comma helps to communicate where the "parentheses" go: (1a && 1b) || 2. > But I think you may be concerned that the "unpredictable behavior" only applies to the synchronization part of (1), not > the "interchangeable" part? It's my intent that it applies to both. If you try to distinguish between instances with > ==, or do synchronization, behavior will be unpredictable (because it's possible things that were != yesterday will be > == today, per the rules about factories). >> If the comment in each class was a simple reference to ValueBased, it would be easier to maintain and there would be >> less duplication between lots of classes and the explanation in ValueBased.html. > > Yes. This approach of scattering boilerplate throughout the API is not optimized for maintainability. But that's okay, > because change will not be frequent, and meanwhile it's optimized for getting readers' attention instead. I would worry > that if we stripped out all the boilerplate and just had a link, most readers wouldn't follow the link or appreciate > what it meant. Pushed some updates; here's an updated docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201016/api/index.html ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dsimms at openjdk.java.net Sat Oct 17 08:25:37 2020 From: dsimms at openjdk.java.net (David Simms) Date: Sat, 17 Oct 2020 08:25:37 GMT Subject: RFR: Merge lworld Message-ID: Merge jdk-16+20 Adjust to vmSymbols changes ------------- Commit messages: - Adjust to vmSymbols changes - Merge branch 'lworld' into type_restrictions_merge_lworld_jdk_16_20 - Merge jdk - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows - 8254369: Node::disconnect_inputs may skip precedences - 8251325: Miss 'L' for long value in if statement - 8254192: ExtraSharedClassListFile contains extra white space at end of line - 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs - 8254811: JDK-8254158 broke ppc64, s390 builds - 8249878: jfr_emergency_dump has secondary crashes - ... and 136 more: https://git.openjdk.java.net/valhalla/compare/0fb77efa...e623b9fe The webrevs contain the adjustments done while merging with regards to each parent branch: - type-restrictions: https://webrevs.openjdk.java.net/?repo=valhalla&pr=228&range=00.0 - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=228&range=00.1 Changes: https://git.openjdk.java.net/valhalla/pull/228/files Stats: 321759 lines in 989 files changed: 308844 ins; 7226 del; 5689 mod Patch: https://git.openjdk.java.net/valhalla/pull/228.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/228/head:pull/228 PR: https://git.openjdk.java.net/valhalla/pull/228 From rriggs at openjdk.java.net Sat Oct 17 20:59:29 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sat, 17 Oct 2020 20:59:29 GMT Subject: [lworld] RFR: 8254957: Comparison of ArrayList with int, Integer, PrimitiveInt, ... Message-ID: Prototypes and JMH benchmarks to compare possible implementations of ArrayListInt, ArrayListPrimitiveInt with ArrayList and ArrayList. Located in .../test/micro/org/openjdk/bench/valhalla/sandbox/corelibs/... ------------- Commit messages: - Merge branch 'lworld' into ArrayListOfInt - adding benchmarks - Benchmark cleanup and improvements - Start of comparison of List, List, List Changes: https://git.openjdk.java.net/valhalla/pull/229/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=229&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254957 Stats: 1628 lines in 19 files changed: 1587 ins; 41 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/229.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/229/head:pull/229 PR: https://git.openjdk.java.net/valhalla/pull/229 From github.com+213212+jodastephen at openjdk.java.net Sat Oct 17 22:38:25 2020 From: github.com+213212+jodastephen at openjdk.java.net (Stephen Colebourne) Date: Sat, 17 Oct 2020 22:38:25 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 20:18:11 GMT, Roger Riggs wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Revise definition for more flexible ==. Apply revised boilerplate to wrappers and existing references. > > In the text referring to ValueBase.html in many classes: > > Is the "," misplaced. Should it read: > "not use instances for synchronization or unpredictable behavior may occur." > > If the comment in each class was a simple reference to ValueBased, it would be easier to maintain and there would be > less duplication between lots of classes and the explanation in ValueBased.html. Can I suggest some additions? * `java.time.temporal.ValueRange` - meets the criteria AFAICT * `java.time.format.DecimalStyle` - meets the criteria AFAICT despite implementation internal cache of instances * `java.time.Clock` subclasses - abstract base class equals/hashCode looks hostile, but JDK impls like `SystemClock` meet the criteria AFAICT * `java.time.chrono.AbstractChronology` subclases - all five subclasses meet the criteria AFAICT I don't think `java.time.temporal.WeekFields` meets the criteria as the factory promises "same instance", although it is conceptually value-based. `java.util.Currency` is conceptually value-based, but equals/hashCode isn't suitable at present - I think this should be worked on, as currency is a key value-based concept. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From dsimms at openjdk.java.net Mon Oct 19 06:00:44 2020 From: dsimms at openjdk.java.net (David Simms) Date: Mon, 19 Oct 2020 06:00:44 GMT Subject: RFR: Merge lworld [v2] In-Reply-To: References: Message-ID: > Merge jdk-16+20 > > Adjust to vmSymbols changes David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Adjust to vmSymbols changes - Merge branch 'lworld' into type_restrictions_merge_lworld_jdk_16_20 Merge jdk-16+20 - 8254254: [lworld][type-restrictions] Serviceability tests failing missing FIELDINFO_TAG_MASK Reviewed-by: lfoltan - Merge lworld Merge tag 'jdk-16+19' - 8254022: [lworld] [type-restrictions] Initial support for RestrictedField Reviewed-by: dsimms - 8253760: [type-restrictions] Static inline fields are not "erased" to the ref type - 8253312: Enable JVM experiments in specialization under an opt-in mode ------------- Changes: https://git.openjdk.java.net/valhalla/pull/228/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=228&range=01 Stats: 813 lines in 37 files changed: 638 ins; 103 del; 72 mod Patch: https://git.openjdk.java.net/valhalla/pull/228.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/228/head:pull/228 PR: https://git.openjdk.java.net/valhalla/pull/228 From dsimms at openjdk.java.net Mon Oct 19 06:00:46 2020 From: dsimms at openjdk.java.net (David Simms) Date: Mon, 19 Oct 2020 06:00:46 GMT Subject: Integrated: Merge lworld In-Reply-To: References: Message-ID: On Sat, 17 Oct 2020 08:17:08 GMT, David Simms wrote: > Merge jdk-16+20 > > Adjust to vmSymbols changes This pull request has now been integrated. Changeset: 5194e6c1 Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/5194e6c1 Stats: 321759 lines in 989 files changed: 308844 ins; 7226 del; 5689 mod Merge lworld Merge jdk-16+20 ------------- PR: https://git.openjdk.java.net/valhalla/pull/228 From thartmann at openjdk.java.net Mon Oct 19 09:04:37 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 19 Oct 2020 09:04:37 GMT Subject: [lworld] Integrated: 8254985: [lworld] C2 compilation fails with assert(field_type->is_loaded()) failed: field type must be loaded Message-ID: Removed the assert which is too strong and added a regression test. ------------- Commit messages: - 8254985: [lworld] C2 compilation fails with assert(field_type->is_loaded()) failed: field type must be loaded Changes: https://git.openjdk.java.net/valhalla/pull/230/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=230&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254985 Stats: 26 lines in 2 files changed: 25 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/230.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/230/head:pull/230 PR: https://git.openjdk.java.net/valhalla/pull/230 From thartmann at openjdk.java.net Mon Oct 19 09:04:37 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 19 Oct 2020 09:04:37 GMT Subject: [lworld] Integrated: 8254985: [lworld] C2 compilation fails with assert(field_type->is_loaded()) failed: field type must be loaded In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 08:57:20 GMT, Tobias Hartmann wrote: > Removed the assert which is too strong and added a regression test. This pull request has now been integrated. Changeset: 6be188d8 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/6be188d8 Stats: 26 lines in 2 files changed: 25 ins; 1 del; 0 mod 8254985: [lworld] C2 compilation fails with assert(field_type->is_loaded()) failed: field type must be loaded ------------- PR: https://git.openjdk.java.net/valhalla/pull/230 From rriggs at openjdk.java.net Mon Oct 19 15:21:46 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 19 Oct 2020 15:21:46 GMT Subject: [lworld] RFR: 8254957: Comparison of ArrayList with int, Integer, PrimitiveInt, ... [v2] In-Reply-To: References: Message-ID: > Prototypes and JMH benchmarks to compare possible implementations of ArrayListInt, ArrayListPrimitiveInt with > ArrayList and ArrayList. > Located in .../test/micro/org/openjdk/bench/valhalla/sandbox/corelibs/... Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'lworld' into ArrayListOfInt - simplify ArrayListOfIntBench to reduce running time - Merge branch 'lworld' into ArrayListOfInt - adding benchmarks - Benchmark cleanup and improvements - Start of comparison of List, List, List ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/229/files - new: https://git.openjdk.java.net/valhalla/pull/229/files/12c87535..a7620d1d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=229&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=229&range=00-01 Stats: 67 lines in 3 files changed: 26 ins; 15 del; 26 mod Patch: https://git.openjdk.java.net/valhalla/pull/229.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/229/head:pull/229 PR: https://git.openjdk.java.net/valhalla/pull/229 From rriggs at openjdk.java.net Mon Oct 19 15:21:46 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 19 Oct 2020 15:21:46 GMT Subject: [lworld] RFR: 8254957: Comparison of ArrayList with int, Integer, PrimitiveInt, ... In-Reply-To: References: Message-ID: On Sat, 17 Oct 2020 20:52:44 GMT, Roger Riggs wrote: > Prototypes and JMH benchmarks to compare possible implementations of ArrayListInt, ArrayListPrimitiveInt with > ArrayList and ArrayList. > Located in .../test/micro/org/openjdk/bench/valhalla/sandbox/corelibs/... A sample set of benchmark scores. (size) Mode Cnt Score Error Units ArrayListOfIntBench.appendListInt 100 avgt 5 0.190 ? 0.031 us/op ArrayListOfIntBench.appendListOfInteger 100 avgt 5 0.507 ? 0.053 us/op ArrayListOfIntBench.appendListOfPrimitiveInt 100 avgt 5 0.552 ? 0.088 us/op ArrayListOfIntBench.appendListPrimitiveInt 100 avgt 5 0.188 ? 0.032 us/op ArrayListOfIntBench.sumListInt 100 avgt 5 0.040 ? 0.001 us/op ArrayListOfIntBench.sumListOfInteger 100 avgt 5 0.093 ? 0.005 us/op ArrayListOfIntBench.sumListOfPrimitiveInt 100 avgt 5 0.092 ? 0.003 us/op ArrayListOfIntBench.sumListPrimitiveInt 100 avgt 5 0.038 ? 0.002 us/op ArrayListOfIntBench.thrashListInt 100 avgt 5 27.725 ? 1.160 us/op ArrayListOfIntBench.thrashListOfInteger 100 avgt 5 34.020 ? 0.350 us/op ArrayListOfIntBench.thrashListOfPrimitiveInt 100 avgt 5 55.849 ? 5.382 us/op ArrayListOfIntBench.thrashListPrimitiveInt 100 avgt 5 42.042 ? 0.673 us/op ArrayListOfIntBench.appendListInt 1000000 avgt 5 2314.797 ? 725.937 us/op ArrayListOfIntBench.appendListOfInteger 1000000 avgt 5 7057.021 ? 1370.781 us/op ArrayListOfIntBench.appendListOfPrimitiveInt 1000000 avgt 5 7143.504 ? 2125.302 us/op ArrayListOfIntBench.appendListPrimitiveInt 1000000 avgt 5 2146.208 ? 382.608 us/op ArrayListOfIntBench.sumListInt 1000000 avgt 5 345.963 ? 5.328 us/op ArrayListOfIntBench.sumListOfInteger 1000000 avgt 5 1743.291 ? 1454.943 us/op ArrayListOfIntBench.sumListOfPrimitiveInt 1000000 avgt 5 1405.064 ? 32.415 us/op ArrayListOfIntBench.sumListPrimitiveInt 1000000 avgt 5 341.422 ? 8.290 us/op ArrayListOfIntBench.thrashListInt 1000000 avgt 5 56875.384 ? 1446.936 us/op ArrayListOfIntBench.thrashListOfInteger 1000000 avgt 5 58388.353 ? 3004.966 us/op ArrayListOfIntBench.thrashListOfPrimitiveInt 1000000 avgt 5 116907.473 ? 1190.818 us/op ArrayListOfIntBench.thrashListPrimitiveInt 1000000 avgt 5 113999.171 ? 7173.833 us/op ------------- PR: https://git.openjdk.java.net/valhalla/pull/229 From rriggs at openjdk.java.net Mon Oct 19 15:21:47 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 19 Oct 2020 15:21:47 GMT Subject: [lworld] Integrated: 8254957: Comparison of ArrayList with int, Integer, PrimitiveInt, ... In-Reply-To: References: Message-ID: On Sat, 17 Oct 2020 20:52:44 GMT, Roger Riggs wrote: > Prototypes and JMH benchmarks to compare possible implementations of ArrayListInt, ArrayListPrimitiveInt with > ArrayList and ArrayList. > Located in .../test/micro/org/openjdk/bench/valhalla/sandbox/corelibs/... This pull request has now been integrated. Changeset: 28fb33d2 Author: Roger Riggs URL: https://git.openjdk.java.net/valhalla/commit/28fb33d2 Stats: 1615 lines in 19 files changed: 1574 ins; 41 del; 0 mod 8254957: Comparison of ArrayList with int, Integer, PrimitiveInt,... ------------- PR: https://git.openjdk.java.net/valhalla/pull/229 From dlsmith at openjdk.java.net Mon Oct 19 18:41:24 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Mon, 19 Oct 2020 18:41:24 GMT Subject: RFR: 8254275: Development to revise "value-based class" & apply to wrappers [v2] In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 10:52:38 GMT, Stephen Colebourne wrote: > Can I suggest some additions? Thanks for the suggestions, I've initiated a discussion about them. For this issue & JEP, we'll restrict ourselves to classes that already claim to be value-based (plus the wrappers). But it would be worthwhile to separately explore applying the term to additional Java SE classes. It can be handled as an RFE for each of the relevant APIs. ------------- PR: https://git.openjdk.java.net/valhalla/pull/222 From john.r.rose at oracle.com Mon Oct 19 19:30:27 2020 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 Oct 2020 12:30:27 -0700 Subject: one way to devirtualize acmps that LIFE throws at the VM Message-ID: <86889F23-2B23-4CE7-A362-EB58834369CB@oracle.com> Here?s an old idea I?ve mentioned in the past, but not written up until now: Capture the LIFE (Legacy Idiom For Equality) as a synthetic API point derived from Object.equals. In the presence of value types it would devirtualize acmp instructions in generic code, where they are part of LIFE. https://bugs.openjdk.java.net/browse/JDK-8255024 Let?s keep this in our back pocket, in case generic uses of acmp become a bottleneck. ? John From rriggs at openjdk.java.net Tue Oct 20 13:31:23 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 20 Oct 2020 13:31:23 GMT Subject: [lworld] RFR: 8255054: Fix test broken by incorrect removal of java.lang.ValueBased Message-ID: Restore java.lang.ValueBased that was incorrectly removed by 8254957. ------------- Commit messages: - Restore java/lang/ValueBased.java removed incorrectly - Merge branch 'lworld' into ArrayListOfInt - simplify ArrayListOfIntBench to reduce running time - Merge branch 'lworld' into ArrayListOfInt - adding benchmarks - Benchmark cleanup and improvements - Start of comparison of List, List, List Changes: https://git.openjdk.java.net/valhalla/pull/231/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=231&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255054 Stats: 1574 lines in 18 files changed: 1574 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/231.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/231/head:pull/231 PR: https://git.openjdk.java.net/valhalla/pull/231 From rriggs at openjdk.java.net Tue Oct 20 14:00:29 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 20 Oct 2020 14:00:29 GMT Subject: [lworld] RFR: 8255054: Fix test broken by incorrect removal of java.lang.ValueBased In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 13:26:40 GMT, Roger Riggs wrote: > Restore java.lang.ValueBased that was incorrectly removed by 8254957. The commits have the wrong contents. Withdrawing. ------------- PR: https://git.openjdk.java.net/valhalla/pull/231 From rriggs at openjdk.java.net Tue Oct 20 14:00:30 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 20 Oct 2020 14:00:30 GMT Subject: [lworld] Withdrawn: 8255054: Fix test broken by incorrect removal of java.lang.ValueBased In-Reply-To: References: Message-ID: <9c660-YuejQugfnEejnYPrI4ECcU56LXX6SlrLjEITM=.fda03e07-eb60-46ff-bd2d-d77df1e0338a@github.com> On Tue, 20 Oct 2020 13:26:40 GMT, Roger Riggs wrote: > Restore java.lang.ValueBased that was incorrectly removed by 8254957. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/valhalla/pull/231 From rriggs at openjdk.java.net Tue Oct 20 15:30:37 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 20 Oct 2020 15:30:37 GMT Subject: [lworld] RFR: 8254797: [Development] Define & apply annotation jdk.internal.ValueBased Message-ID: Define a JDK-internal annotation, jdk.internal.ValueBased, which indicates that a class or interface is value-based, per: java/lang/doc-files/ValueBased.html (The switch of the compiler from the existing java.lang.ValueBased to jdk.internal.ValueBased will occur separately). Apply the annotation wherever existing documentation references ValueBased.html, including: - The primitive wrapper classes in java.lang; - The class java.lang.Runtime.Version; - The "optional" classes in java.util: Optional, OptionalInt, OptionalLong, and OptionalDouble; - Many classes in the java.time API: Instant, LocalDate, LocalTime, LocalDateTime, ZonedDateTime, ZoneId, OffsetTime, OffsetDateTime, ZoneOffset, Duration, Period, Year, YearMonth, and MonthDay, and, in java.time.chrono: MinguoDate, HijrahDate, JapaneseDate, and ThaiBuddhistDate; - The interface java.lang.ProcessHandle and its implementation classes; - and an initial set of other classes The CSR for these changes will occur *after* the prototyping of javac and the VM runtime is working. ------------- Commit messages: - Merge branch 'value-based-8254797' of https://github.com/RogerRiggs/valhalla into value-based-8254797 - Add java.lang.ValueBased and apply to java.lang wrapper and java.time immutable classes - Add java.lang.ValueBased and apply to java.lang wrapper and java.time immutable classes Changes: https://git.openjdk.java.net/valhalla/pull/233/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=233&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254797 Stats: 80 lines in 37 files changed: 78 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/233.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/233/head:pull/233 PR: https://git.openjdk.java.net/valhalla/pull/233 From dsimms at openjdk.java.net Tue Oct 20 16:05:31 2020 From: dsimms at openjdk.java.net (David Simms) Date: Tue, 20 Oct 2020 16:05:31 GMT Subject: [lworld] RFR: 8247299: [lworld] Disable UseBiasedLocking by default Message-ID: <2UZBUQ4bleTxWsNuQeupRkH3uHtgDmIKgBWhopO-wBc=.87dde588-8115-4cc2-ab94-140bfd4ef5af@github.com> Disabled UseBiasedLocking, and reorganized markWord to serve Valhalla requirements (see also JDK-8247298 for motivation). Actual UseBiasedLocking code remains simply to avoid future conflicts. Since static constants have changed and UseBiasedLocking is deprecated, Valhalla assumes it will be removed, and it is not only disabled "by default", but now unusable. Tier1-3 testing clean ------------- Commit messages: - Remove more biased lock testing - extend into hash area for unlocked should_preserve - Merge branch 'lworld' into mark_word_without_bias - Disable biased locking testing - Fix later LoadNode::Value() prototype mark later - EnableValhalla guards - Init markWord with prototype for klass - Don't UseBiasedLocking at all, unconditional changes to markWord - Revert to poisioning inline bit for locking slow path, flat is also null free same as klass _layout_helper - Oop header minor fix/format - ... and 2 more: https://git.openjdk.java.net/valhalla/compare/28fb33d2...4b02f030 Changes: https://git.openjdk.java.net/valhalla/pull/234/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=234&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247299 Stats: 759 lines in 42 files changed: 201 ins; 452 del; 106 mod Patch: https://git.openjdk.java.net/valhalla/pull/234.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/234/head:pull/234 PR: https://git.openjdk.java.net/valhalla/pull/234 From rriggs at openjdk.java.net Tue Oct 20 16:10:42 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 20 Oct 2020 16:10:42 GMT Subject: [lworld] Integrated: 8255054: Fix test broken by incorrect removal of java.lang.ValueBased Message-ID: 8254957 mistakenly deleted java/lang/ValueBased.java. The file is restored. ------------- Commit messages: - fix whitespace - Restore java/lang/ValueBased.java removed incorrectly Changes: https://git.openjdk.java.net/valhalla/pull/232/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=232&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255054 Stats: 42 lines in 1 file changed: 42 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/232.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/232/head:pull/232 PR: https://git.openjdk.java.net/valhalla/pull/232 From rriggs at openjdk.java.net Tue Oct 20 16:10:44 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 20 Oct 2020 16:10:44 GMT Subject: [lworld] Integrated: 8255054: Fix test broken by incorrect removal of java.lang.ValueBased In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 14:21:52 GMT, Roger Riggs wrote: > 8254957 mistakenly deleted java/lang/ValueBased.java. > The file is restored. This pull request has now been integrated. Changeset: 28b90dcd Author: Roger Riggs URL: https://git.openjdk.java.net/valhalla/commit/28b90dcd Stats: 42 lines in 1 file changed: 42 ins; 0 del; 0 mod 8255054: Fix test broken by incorrect removal of java.lang.ValueBased ------------- PR: https://git.openjdk.java.net/valhalla/pull/232 From fparain at openjdk.java.net Tue Oct 20 18:33:24 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Tue, 20 Oct 2020 18:33:24 GMT Subject: [lworld] RFR: 8247299: [lworld] Disable UseBiasedLocking by default In-Reply-To: <2UZBUQ4bleTxWsNuQeupRkH3uHtgDmIKgBWhopO-wBc=.87dde588-8115-4cc2-ab94-140bfd4ef5af@github.com> References: <2UZBUQ4bleTxWsNuQeupRkH3uHtgDmIKgBWhopO-wBc=.87dde588-8115-4cc2-ab94-140bfd4ef5af@github.com> Message-ID: On Tue, 20 Oct 2020 15:52:40 GMT, David Simms wrote: > Disabled UseBiasedLocking, and reorganized markWord to serve Valhalla requirements (see also JDK-8247298 for > motivation). > Actual UseBiasedLocking code remains simply to avoid future conflicts. Since static constants have changed and > UseBiasedLocking is deprecated, Valhalla assumes it will be removed, and it is not only disabled "by default", but now > unusable. Tier1-3 testing clean Looks good to me. Fred ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.java.net/valhalla/pull/234 From rriggs at openjdk.java.net Tue Oct 20 20:18:59 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 20 Oct 2020 20:18:59 GMT Subject: git: openjdk/valhalla: lworld: 8254797: [Development] Define & apply annotation jdk.internal.ValueBased Message-ID: <56efb36f-dafb-4797-8f09-3c6a3c2f1c08@openjdk.org> Changeset: 31678561 Author: Roger Riggs Date: 2020-10-20 20:18:18 +0000 URL: https://git.openjdk.java.net/valhalla/commit/31678561 8254797: [Development] Define & apply annotation jdk.internal.ValueBased ! src/java.base/share/classes/java/lang/Boolean.java ! src/java.base/share/classes/java/lang/Byte.java ! src/java.base/share/classes/java/lang/Character.java ! src/java.base/share/classes/java/lang/Double.java ! src/java.base/share/classes/java/lang/Float.java ! src/java.base/share/classes/java/lang/Integer.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/ProcessHandle.java ! src/java.base/share/classes/java/lang/ProcessHandleImpl.java ! src/java.base/share/classes/java/lang/Runtime.java ! src/java.base/share/classes/java/lang/Short.java ! src/java.base/share/classes/java/time/Duration.java ! src/java.base/share/classes/java/time/Instant.java ! src/java.base/share/classes/java/time/LocalDate.java ! src/java.base/share/classes/java/time/LocalDateTime.java ! src/java.base/share/classes/java/time/LocalTime.java ! src/java.base/share/classes/java/time/MonthDay.java ! src/java.base/share/classes/java/time/OffsetDateTime.java ! src/java.base/share/classes/java/time/OffsetTime.java ! src/java.base/share/classes/java/time/Period.java ! src/java.base/share/classes/java/time/Year.java ! src/java.base/share/classes/java/time/YearMonth.java ! src/java.base/share/classes/java/time/ZoneId.java ! src/java.base/share/classes/java/time/ZoneOffset.java ! src/java.base/share/classes/java/time/ZonedDateTime.java ! src/java.base/share/classes/java/time/chrono/HijrahDate.java ! src/java.base/share/classes/java/time/chrono/JapaneseDate.java ! src/java.base/share/classes/java/time/chrono/MinguoDate.java ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/java.base/share/classes/java/time/format/TextStyle.java ! src/java.base/share/classes/java/util/KeyValueHolder.java ! src/java.base/share/classes/java/util/Optional.java ! src/java.base/share/classes/java/util/OptionalDouble.java ! src/java.base/share/classes/java/util/OptionalInt.java ! src/java.base/share/classes/java/util/OptionalLong.java + src/java.base/share/classes/jdk/internal/ValueBased.java From rriggs at openjdk.java.net Tue Oct 20 20:22:31 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 20 Oct 2020 20:22:31 GMT Subject: [lworld] Integrated: 8254797: [Development] Define & apply annotation jdk.internal.ValueBased In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 15:26:04 GMT, Roger Riggs wrote: > Define a JDK-internal annotation, jdk.internal.ValueBased, which indicates that a class or interface is value-based, > per: java/lang/doc-files/ValueBased.html > (The switch of the compiler from the existing java.lang.ValueBased to jdk.internal.ValueBased will occur separately). > > Apply the annotation wherever existing documentation references ValueBased.html, including: > - The primitive wrapper classes in java.lang; > - The class java.lang.Runtime.Version; > - The "optional" classes in java.util: Optional, OptionalInt, OptionalLong, and OptionalDouble; > - Many classes in the java.time API: Instant, LocalDate, LocalTime, LocalDateTime, ZonedDateTime, ZoneId, OffsetTime, > OffsetDateTime, ZoneOffset, Duration, Period, Year, YearMonth, and MonthDay, and, in java.time.chrono: MinguoDate, > HijrahDate, JapaneseDate, and ThaiBuddhistDate; > - The interface java.lang.ProcessHandle and its implementation classes; > - and an initial set of other classes > > The CSR for these changes will occur *after* the prototyping of javac and the VM runtime is working. This pull request has now been integrated. Changeset: 31678561 Author: Roger Riggs URL: https://git.openjdk.java.net/valhalla/commit/31678561 Stats: 80 lines in 37 files changed: 78 ins; 1 del; 1 mod 8254797: [Development] Define & apply annotation jdk.internal.ValueBased ------------- PR: https://git.openjdk.java.net/valhalla/pull/233 From srikanth.adayapalam at oracle.com Wed Oct 21 06:00:41 2020 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Wed, 21 Oct 2020 11:30:41 +0530 Subject: [lworld] Integrated: 8254797: [Development] Define & apply annotation jdk.internal.ValueBased In-Reply-To: References: Message-ID: <6895e325-6bbd-ebce-2dfe-da29d10468f6@oracle.com> Hello! May be I have understood the process wrong - Should this change have been integrated into lworld branch ?? I thought JEP390 branch on valhalla was supposed to host all the changes pertinent to JEP390 and that these would make it to lworld only via a merge from jdk/jdk after they make it to there from jep390 branch. Thanks in advance for clarifying the process to be followed. Srikanth On 21/10/20 1:52 am, Roger Riggs wrote: > On Tue, 20 Oct 2020 15:26:04 GMT, Roger Riggs wrote: > >> Define a JDK-internal annotation, jdk.internal.ValueBased, which indicates that a class or interface is value-based, >> per: java/lang/doc-files/ValueBased.html >> (The switch of the compiler from the existing java.lang.ValueBased to jdk.internal.ValueBased will occur separately). >> >> Apply the annotation wherever existing documentation references ValueBased.html, including: >> - The primitive wrapper classes in java.lang; >> - The class java.lang.Runtime.Version; >> - The "optional" classes in java.util: Optional, OptionalInt, OptionalLong, and OptionalDouble; >> - Many classes in the java.time API: Instant, LocalDate, LocalTime, LocalDateTime, ZonedDateTime, ZoneId, OffsetTime, >> OffsetDateTime, ZoneOffset, Duration, Period, Year, YearMonth, and MonthDay, and, in java.time.chrono: MinguoDate, >> HijrahDate, JapaneseDate, and ThaiBuddhistDate; >> - The interface java.lang.ProcessHandle and its implementation classes; >> - and an initial set of other classes >> >> The CSR for these changes will occur *after* the prototyping of javac and the VM runtime is working. > This pull request has now been integrated. > > Changeset: 31678561 > Author: Roger Riggs > URL: https://git.openjdk.java.net/valhalla/commit/31678561 > Stats: 80 lines in 37 files changed: 78 ins; 1 del; 1 mod > > 8254797: [Development] Define & apply annotation jdk.internal.ValueBased > > ------------- > > PR: https://git.openjdk.java.net/valhalla/pull/233 From dsimms at openjdk.java.net Wed Oct 21 08:30:24 2020 From: dsimms at openjdk.java.net (David Simms) Date: Wed, 21 Oct 2020 08:30:24 GMT Subject: [lworld] Integrated: 8247299: [lworld] Disable UseBiasedLocking by default In-Reply-To: <2UZBUQ4bleTxWsNuQeupRkH3uHtgDmIKgBWhopO-wBc=.87dde588-8115-4cc2-ab94-140bfd4ef5af@github.com> References: <2UZBUQ4bleTxWsNuQeupRkH3uHtgDmIKgBWhopO-wBc=.87dde588-8115-4cc2-ab94-140bfd4ef5af@github.com> Message-ID: <6grvTukNrIq_cF_M6j-hK3YpAHZvBGvLKE1wdAJ8u-o=.b6045701-4bcd-44d4-a662-e34d22ff82ed@github.com> On Tue, 20 Oct 2020 15:52:40 GMT, David Simms wrote: > Disabled UseBiasedLocking, and reorganized markWord to serve Valhalla requirements (see also JDK-8247298 for > motivation). > Actual UseBiasedLocking code remains simply to avoid future conflicts. Since static constants have changed and > UseBiasedLocking is deprecated, Valhalla assumes it will be removed, and it is not only disabled "by default", but now > unusable. Tier1-3 testing clean This pull request has now been integrated. Changeset: 3a7c9fe6 Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/3a7c9fe6 Stats: 759 lines in 42 files changed: 201 ins; 452 del; 106 mod 8247299: [lworld] Disable UseBiasedLocking by default Reviewed-by: fparain ------------- PR: https://git.openjdk.java.net/valhalla/pull/234 From tobias.hartmann at oracle.com Wed Oct 21 12:02:49 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 21 Oct 2020 14:02:49 +0200 Subject: Limitations of the Calling Convention Optimization Message-ID: Hi, After having a discussion with Maurizio who was observing some unexpected allocations when using inline types in the Foreign-Memory Access API (Panama), I've decided to summarize the limitations of the calling convention optimization. This is to make sure we share the same expectations. Inline types are passed/returned in a scalarized (flat) representation. That means that instead of passing/returning a pointer to a buffer, each field of an inline type is passed/returned individually in registers or on the stack. Only C2 compiled code uses this scalarized calling convention because C1 and the interpreter are always using buffers to access inline types. This adds some major complexity to the implementation because we need to handle mismatches in the calling convention between the interpreter, C1 and C2. The technical details are explained here [1]. Now this optimization only applies to "sharp" inline type arguments and returns and does *not* apply to the reference projection or interface types (even if they are sealed and/or only implemented by one inline type). For example, the 'MyInline' return value of 'method' is buffered and returned as a pointer to that buffer because the return type is 'MyInterface': interface MyInterface { [...] } inline class MyInline implements MyInterface { [...] } static MyInterface method() { return new MyInline(); } Now it's important to understand that "buffering" an inline type means a full-blown Java heap allocation with all the expected impact on the GC and footprint. We often referred to these as "lightweight boxes" which might be a bit misleading because the impact on performance and footprint is the same as for a "heavyweight box". The difference is that we don't need to keep track of identity (they are not Java objects) and can therefore create/destroy such "boxes" on the fly. Of course, this is a limitation of the HotSpot implementation. Other implementations might choose to allocate on the stack or in a thread local buffer (see below). Also, buffering is not specific to the calling convention optimization but also required in other cases (for example, when storing an inline type into a non-flattened container). It's also important to understand that the calling convention optimization is highly dependent on inlining decisions. If we successfully inline a call, no buffering will be required. Unfortunately, for a Java developer it's very hard to track and control inlining. Possible solutions/mitigations: 1) Improve inlining. 2) Make buffering more light-weight. 3) Speculate that an interface is only implemented by a single inline type. 1) Improving the inlining heuristic is a long standing issue with C2 that is independent of inline types and an entire project on its own. Of course, we could tweak the current implementation such that problematic calls are more likely to be inlined but that will still be limited and might have side effects. 2) We've already evaluated options to make buffering more light-weight in the past. For example, thread-local value buffering [2] turned out to not improve performance as expected while adding lots of complexity and required costly runtime checks. And even if we buffer inline types outside of the Java heap, the GC still needs to know about object fields. 3) In above example, we could speculate that 'MyInterface' is only implemented by 'MyInline' (or maybe use the fact that 'MyInterface' is sealed). However, even in that case we would still need to handle a 'null' value. I.e., we are back to the discussion of flattening "nullable" inline types. One option to scalarize nullable inline types in the calling convention would be to pass an additional, artificial field that can be used to check if the inline type is null. Compiled code would then "null-check" before using the fields. However, this solution is far from trivial to implement and the overhead of the additional fields and especially the runtime checks might cancel out the improvements of scalarization. It's even worse if the interface is then suddenly implemented by a different, non-inline type. We would need to re-compile all dependent code resulting in a deoptimization-storm and re-compute the calling convention (something that is not easily possible with the current implementation). Also, the VM would need to ensure that the argument/return type is eagerly loaded when the adapters are created at method link time (how do we even know eager loading is required for these L-types?). Of course, we can push these limits as far as we can but the reality is that when mixing inline types with objects or interfaces, there will always be "boundaries" at which we have to buffer and this will lead to "unexpected" drops in performance. Hope that helps. Best regards, Tobias [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2019-December/006668.html [2] https://bugs.openjdk.java.net/browse/JDK-8212245 From brian.goetz at oracle.com Wed Oct 21 13:48:10 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 21 Oct 2020 09:48:10 -0400 Subject: Limitations of the Calling Convention Optimization In-Reply-To: References: Message-ID: Tobias; Thanks for these great notes.? This project is, in many ways, like boring the Channel Tunnel; there's a certain amount of "start drilling from each side, and pray that you meet in the middle."? The calling convention optimizations represent one direction of effort; the attempt to use Valhalla in libraries like Panama represent the other.? But, unlike our tunnel-boring brethren, we didn't expect that we'd meet on our first attempt, and that's OK. What I recommend here is that we do a similar analysis from the other side -- the API idioms we are trying to use -- and see if there is something missing to bridge the gap.? It may be that we can identify a restricted set of idioms, that meet the needs of libraries, that can be optimized better. My hope was that sealing could be part of the story for (3), since if the classfile tells you "permits X", you don't have to speculate on X -- you can bank on it.? But it sounds like that's only part of the story -- we also need to wrangle nullity constraints. On 10/21/2020 8:02 AM, Tobias Hartmann wrote: > Hi, > > After having a discussion with Maurizio who was observing some unexpected allocations when using > inline types in the Foreign-Memory Access API (Panama), I've decided to summarize the limitations of > the calling convention optimization. This is to make sure we share the same expectations. > > Inline types are passed/returned in a scalarized (flat) representation. That means that instead of > passing/returning a pointer to a buffer, each field of an inline type is passed/returned > individually in registers or on the stack. Only C2 compiled code uses this scalarized calling > convention because C1 and the interpreter are always using buffers to access inline types. This adds > some major complexity to the implementation because we need to handle mismatches in the calling > convention between the interpreter, C1 and C2. The technical details are explained here [1]. > > Now this optimization only applies to "sharp" inline type arguments and returns and does *not* apply > to the reference projection or interface types (even if they are sealed and/or only implemented by > one inline type). For example, the 'MyInline' return value of 'method' is buffered and returned as a > pointer to that buffer because the return type is 'MyInterface': > > interface MyInterface { > [...] > } > > inline class MyInline implements MyInterface { > [...] > } > > static MyInterface method() { > return new MyInline(); > } > > Now it's important to understand that "buffering" an inline type means a full-blown Java heap > allocation with all the expected impact on the GC and footprint. We often referred to these as > "lightweight boxes" which might be a bit misleading because the impact on performance and footprint > is the same as for a "heavyweight box". The difference is that we don't need to keep track of > identity (they are not Java objects) and can therefore create/destroy such "boxes" on the fly. Of > course, this is a limitation of the HotSpot implementation. Other implementations might choose to > allocate on the stack or in a thread local buffer (see below). > > Also, buffering is not specific to the calling convention optimization but also required in other > cases (for example, when storing an inline type into a non-flattened container). > > It's also important to understand that the calling convention optimization is highly dependent on > inlining decisions. If we successfully inline a call, no buffering will be required. Unfortunately, > for a Java developer it's very hard to track and control inlining. > > Possible solutions/mitigations: > 1) Improve inlining. > 2) Make buffering more light-weight. > 3) Speculate that an interface is only implemented by a single inline type. > > 1) Improving the inlining heuristic is a long standing issue with C2 that is independent of inline > types and an entire project on its own. Of course, we could tweak the current implementation such > that problematic calls are more likely to be inlined but that will still be limited and might have > side effects. > > 2) We've already evaluated options to make buffering more light-weight in the past. For example, > thread-local value buffering [2] turned out to not improve performance as expected while adding lots > of complexity and required costly runtime checks. And even if we buffer inline types outside of the > Java heap, the GC still needs to know about object fields. > > 3) In above example, we could speculate that 'MyInterface' is only implemented by 'MyInline' (or > maybe use the fact that 'MyInterface' is sealed). However, even in that case we would still need to > handle a 'null' value. I.e., we are back to the discussion of flattening "nullable" inline types. > > One option to scalarize nullable inline types in the calling convention would be to pass an > additional, artificial field that can be used to check if the inline type is null. Compiled code > would then "null-check" before using the fields. However, this solution is far from trivial to > implement and the overhead of the additional fields and especially the runtime checks might cancel > out the improvements of scalarization. > > It's even worse if the interface is then suddenly implemented by a different, non-inline type. We > would need to re-compile all dependent code resulting in a deoptimization-storm and re-compute the > calling convention (something that is not easily possible with the current implementation). > > Also, the VM would need to ensure that the argument/return type is eagerly loaded when the adapters > are created at method link time (how do we even know eager loading is required for these L-types?). > > Of course, we can push these limits as far as we can but the reality is that when mixing inline > types with objects or interfaces, there will always be "boundaries" at which we have to buffer and > this will lead to "unexpected" drops in performance. > > Hope that helps. > > Best regards, > Tobias > > [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2019-December/006668.html > [2] https://bugs.openjdk.java.net/browse/JDK-8212245 From rriggs at openjdk.java.net Wed Oct 21 13:55:37 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 21 Oct 2020 13:55:37 GMT Subject: RFR: 8255125: [Development] copy jdk.internal.ValueBased to jep390 branch Message-ID: <7ICzUddVzxLZPMi1grTzaHbrX96te8xjRw7q0leZFMQ=.a282096f-6c2d-4e50-a221-58b664759ba1@github.com> Commit a copy of the ValueBased.java and its uses to the JEP 390 branch. ------------- Commit messages: - 8254797: [Development] Define & apply annotation jdk.internal.ValueBased Changes: https://git.openjdk.java.net/valhalla/pull/235/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=235&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255125 Stats: 80 lines in 37 files changed: 78 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/235.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/235/head:pull/235 PR: https://git.openjdk.java.net/valhalla/pull/235 From john.r.rose at oracle.com Wed Oct 21 16:34:49 2020 From: john.r.rose at oracle.com (John Rose) Date: Wed, 21 Oct 2020 09:34:49 -0700 Subject: Limitations of the Calling Convention Optimization In-Reply-To: References: Message-ID: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> On Oct 21, 2020, at 5:02 AM, Tobias Hartmann wrote: > > Also, the VM would need to ensure that the argument/return type is eagerly loaded when the adapters > are created at method link time (how do we even know eager loading is required for these L-types?). This is the hard kernel of the problem. The L in LFoo; means ?Lazy Loading? (among other things); you simply cannot assume that Foo.class will be loaded when you are setting up layouts and calling sequences for an LFoo;. To get that information (and more) we will always need a signal somewhere in the call site which says, ?do the preload? (which is what I call the ?go and look? signal). The Q in QFooVal; performs this duty. That said, we might have wiggle room with sealed interfaces. If there is a ?go and look? signal (QFooVal;) nearby that has forced the loading of an inline type FooVal which has an interface type FooRef as a super, *and* if FooRef is sealed, then we can go to work on FooRef calling sequences, if we think it?s profitable. (We could substitute in a null flag plus a FooVal instance, and we can try to merge the null flag into the ?guts? of the FooVal registers, if there is slack. Or pass the FooVal on stack by reference. Or other tricks like that.) But, back to the hard kernel of the problem, if there is no mention of QFooVal; near the LFooRef; descriptor, all bets are off; FooRef.class must be assumed to be unavailable in the general case when forming calling sequences involving LFooRef;. The laziness of LFoo; gives it opaqueness, abstraction. All you know is it?s a pointer; you can?t know (in general) what it points to until Foo.class is loaded and there?s an instance of Foo running around. Before that it?s just nulls. The opaqueness of LFoo; in turn means that you don?t know whether it is just a GC heap reference or something special (a disguised value). When we try to do special side-heap treatment for LFoo; values that we discover are disguised values, we find that it?s difficult to contain the uses of those values; they are so nondescript they mix with Object pointers. This creates a kind of pollution where suddenly every pointer that might be handed to the GC has to be checked to see if it?s a side-heap pointer (e.g., thread local or on-stack). This possibility of pollution is introduced by the abstractness of LFoo; and the result of it is hard-to-control extra expenses wherever an opaque pointer must be stored in the real GC heap. Maybe we can slim those expenses down in the future, using ZGC-like colored pointers. For now, I think the good thing to do is buffer on the real GC heap, as we do now. Maybe the performance can be increased in the future by using side-heap tricks, after we figure out how to prevent side-heap pointers from polluting the real GC heap. It?s an odd linkage: the Lazy Loading LFoo;, by its nature, has surprising connections to the GC. ? John From mchung at openjdk.java.net Wed Oct 21 17:04:27 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 21 Oct 2020 17:04:27 GMT Subject: [lworld] RFR: 8254797: [Development] Define & apply annotation jdk.internal.ValueBased In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 15:26:04 GMT, Roger Riggs wrote: > Define a JDK-internal annotation, jdk.internal.ValueBased, which indicates that a class or interface is value-based, per: java/lang/doc-files/ValueBased.html > > (The switch of the compiler from the existing java.lang.ValueBased to jdk.internal.ValueBased will occur separately). > > Apply the annotation wherever existing documentation references ValueBased.html, including: > - The primitive wrapper classes in java.lang; > - The class java.lang.Runtime.Version; > - The "optional" classes in java.util: Optional, OptionalInt, OptionalLong, and OptionalDouble; > - Many classes in the java.time API: Instant, LocalDate, LocalTime, LocalDateTime, ZonedDateTime, ZoneId, OffsetTime, OffsetDateTime, ZoneOffset, Duration, Period, Year, YearMonth, and MonthDay, and, in java.time.chrono: MinguoDate, HijrahDate, JapaneseDate, and ThaiBuddhistDate; > - The interface java.lang.ProcessHandle and its implementation classes; > - and an initial set of other classes > > The CSR for these changes will occur *after* the prototyping of javac and the VM runtime is working. Looks like Roger pushed to the wrong branch. It's supposed to push to jep390 branch. ------------- PR: https://git.openjdk.java.net/valhalla/pull/233 From brian.goetz at oracle.com Wed Oct 21 17:14:04 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 21 Oct 2020 13:14:04 -0400 Subject: Limitations of the Calling Convention Optimization In-Reply-To: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> References: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> Message-ID: <245e5987-0d03-b3a6-ba6b-6c02b74e1da5@oracle.com> What I am hoping to get out of this discussion is a better understanding of what API design guidelines we have to give to developers.? The standard advice is "use interfaces in external APIs", and there are very good reasons for this. Interfaces make no commitment as to implementation, allowing implementations to evolve.? Maybe there's one implementation now and multiple later; maybe there are multiple now and one later; interfaces give us this freedom (and sealing further gives us the freedom to control this destiny.) If we have to tell people "if you ever might want to use a primitive class to implement X, you must do that up-front, burn that into your APIs, and permanently give up on ever having multiple implementations", this is a different story, and obviously more limiting. I think Maurizio had been (reasonably) assuming that, if there was just one inline implementation, we would be able to get some reasonable baseline of performance expectations in the sealed interface + primitive class implementation world, allowing us to continue with the API design principles that have stood us well for decades.? But it sounds like we're not sure about that now. To be clear, this is bigger than calling-convention optimizations; it's about our goals for what language we want to build; it seems like we have been assuming some things that are not quite valid, and its important to understand the implications and whether the requirements need to be adjusted. On 10/21/2020 12:34 PM, John Rose wrote: > On Oct 21, 2020, at 5:02 AM, Tobias Hartmann wrote: >> Also, the VM would need to ensure that the argument/return type is eagerly loaded when the adapters >> are created at method link time (how do we even know eager loading is required for these L-types?). > This is the hard kernel of the problem. The L in LFoo; means > ?Lazy Loading? (among other things); you simply cannot assume > that Foo.class will be loaded when you are setting up layouts and > calling sequences for an LFoo;. To get that information (and more) > we will always need a signal somewhere in the call site which says, > ?do the preload? (which is what I call the ?go and look? signal). > The Q in QFooVal; performs this duty. > > That said, we might have wiggle room with sealed interfaces. > If there is a ?go and look? signal (QFooVal;) nearby that has > forced the loading of an inline type FooVal which has an > interface type FooRef as a super, *and* if FooRef is sealed, > then we can go to work on FooRef calling sequences, if we > think it?s profitable. (We could substitute in a null flag plus > a FooVal instance, and we can try to merge the null flag into > the ?guts? of the FooVal registers, if there is slack. Or pass > the FooVal on stack by reference. Or other tricks like that.) > > But, back to the hard kernel of the problem, if there is no > mention of QFooVal; near the LFooRef; descriptor, all bets > are off; FooRef.class must be assumed to be unavailable in > the general case when forming calling sequences involving > LFooRef;. > > The laziness of LFoo; gives it opaqueness, abstraction. All you > know is it?s a pointer; you can?t know (in general) what it > points to until Foo.class is loaded and there?s an instance > of Foo running around. Before that it?s just nulls. The > opaqueness of LFoo; in turn means that you don?t know > whether it is just a GC heap reference or something special > (a disguised value). When we try to do special side-heap > treatment for LFoo; values that we discover are disguised > values, we find that it?s difficult to contain the uses of > those values; they are so nondescript they mix with > Object pointers. This creates a kind of pollution where > suddenly every pointer that might be handed to the GC > has to be checked to see if it?s a side-heap pointer (e.g., > thread local or on-stack). This possibility of pollution > is introduced by the abstractness of LFoo; and the > result of it is hard-to-control extra expenses wherever > an opaque pointer must be stored in the real GC heap. > > Maybe we can slim those expenses down in the future, > using ZGC-like colored pointers. For now, I think the > good thing to do is buffer on the real GC heap, as we > do now. Maybe the performance can be increased in > the future by using side-heap tricks, after we figure > out how to prevent side-heap pointers from polluting > the real GC heap. > > It?s an odd linkage: the Lazy Loading LFoo;, by its > nature, has surprising connections to the GC. > > ? John From rriggs at openjdk.java.net Wed Oct 21 17:25:22 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 21 Oct 2020 17:25:22 GMT Subject: [lworld] RFR: 8254797: [Development] Define & apply annotation jdk.internal.ValueBased In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 17:01:21 GMT, Mandy Chung wrote: >> Define a JDK-internal annotation, jdk.internal.ValueBased, which indicates that a class or interface is value-based, per: java/lang/doc-files/ValueBased.html >> >> (The switch of the compiler from the existing java.lang.ValueBased to jdk.internal.ValueBased will occur separately). >> >> Apply the annotation wherever existing documentation references ValueBased.html, including: >> - The primitive wrapper classes in java.lang; >> - The class java.lang.Runtime.Version; >> - The "optional" classes in java.util: Optional, OptionalInt, OptionalLong, and OptionalDouble; >> - Many classes in the java.time API: Instant, LocalDate, LocalTime, LocalDateTime, ZonedDateTime, ZoneId, OffsetTime, OffsetDateTime, ZoneOffset, Duration, Period, Year, YearMonth, and MonthDay, and, in java.time.chrono: MinguoDate, HijrahDate, JapaneseDate, and ThaiBuddhistDate; >> - The interface java.lang.ProcessHandle and its implementation classes; >> - and an initial set of other classes >> >> The CSR for these changes will occur *after* the prototyping of javac and the VM runtime is working. > > Looks like Roger pushed to the wrong branch. It's supposed to push to jep390 branch. Yep, I didn't change the pull-down when creating the PR. Please review... https://github.com/openjdk/valhalla/pull/235 ------------- PR: https://git.openjdk.java.net/valhalla/pull/233 From forax at univ-mlv.fr Wed Oct 21 17:37:25 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 21 Oct 2020 19:37:25 +0200 (CEST) Subject: Limitations of the Calling Convention Optimization In-Reply-To: References: Message-ID: <396995431.1797864.1603301845623.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Tobias Hartmann" > ?: "valhalla-dev" > Envoy?: Mercredi 21 Octobre 2020 14:02:49 > Objet: Limitations of the Calling Convention Optimization > Hi, > > After having a discussion with Maurizio who was observing some unexpected > allocations when using > inline types in the Foreign-Memory Access API (Panama), I've decided to > summarize the limitations of > the calling convention optimization. This is to make sure we share the same > expectations. > > Inline types are passed/returned in a scalarized (flat) representation. That > means that instead of > passing/returning a pointer to a buffer, each field of an inline type is > passed/returned > individually in registers or on the stack. Only C2 compiled code uses this > scalarized calling > convention because C1 and the interpreter are always using buffers to access > inline types. This adds > some major complexity to the implementation because we need to handle mismatches > in the calling > convention between the interpreter, C1 and C2. The technical details are > explained here [1]. > > Now this optimization only applies to "sharp" inline type arguments and returns > and does *not* apply > to the reference projection or interface types (even if they are sealed and/or > only implemented by > one inline type). For example, the 'MyInline' return value of 'method' is > buffered and returned as a > pointer to that buffer because the return type is 'MyInterface': > > interface MyInterface { > [...] > } > > inline class MyInline implements MyInterface { > [...] > } > > static MyInterface method() { > return new MyInline(); > } > > Now it's important to understand that "buffering" an inline type means a > full-blown Java heap > allocation with all the expected impact on the GC and footprint. We often > referred to these as > "lightweight boxes" which might be a bit misleading because the impact on > performance and footprint > is the same as for a "heavyweight box". The difference is that we don't need to > keep track of > identity (they are not Java objects) and can therefore create/destroy such > "boxes" on the fly. Of > course, this is a limitation of the HotSpot implementation. Other > implementations might choose to > allocate on the stack or in a thread local buffer (see below). > > Also, buffering is not specific to the calling convention optimization but also > required in other > cases (for example, when storing an inline type into a non-flattened container). > > It's also important to understand that the calling convention optimization is > highly dependent on > inlining decisions. If we successfully inline a call, no buffering will be > required. Unfortunately, > for a Java developer it's very hard to track and control inlining. > > Possible solutions/mitigations: > 1) Improve inlining. > 2) Make buffering more light-weight. > 3) Speculate that an interface is only implemented by a single inline type. > > 1) Improving the inlining heuristic is a long standing issue with C2 that is > independent of inline > types and an entire project on its own. Of course, we could tweak the current > implementation such > that problematic calls are more likely to be inlined but that will still be > limited and might have > side effects. There are possible tweaks that are backward compatible because currently there is no Q-type in any published jars. Instead of doing the inlining from top to bottom, starts by inlining methods that have a Q-type and then inline the other methods from top to bottom. The other thing is that from my own experience, it's kind of rare to have all the interresting methods compiled with c2, usually you have a mix of methods compiled with c2 and c1. So it seams that implementing the scalarization calling convention in c1 may help. > > 2) We've already evaluated options to make buffering more light-weight in the > past. For example, > thread-local value buffering [2] turned out to not improve performance as > expected while adding lots > of complexity and required costly runtime checks. And even if we buffer inline > types outside of the > Java heap, the GC still needs to know about object fields. I wonder if aload(slot)/astore(slot) can be transformed to qload(slot, inlineSize) and qstore(slot, inlineSize) before being interpreted. > > 3) In above example, we could speculate that 'MyInterface' is only implemented > by 'MyInline' (or > maybe use the fact that 'MyInterface' is sealed). However, even in that case we > would still need to > handle a 'null' value. I.e., we are back to the discussion of flattening > "nullable" inline types. > > One option to scalarize nullable inline types in the calling convention would be > to pass an > additional, artificial field that can be used to check if the inline type is > null. Compiled code > would then "null-check" before using the fields. However, this solution is far > from trivial to > implement and the overhead of the additional fields and especially the runtime > checks might cancel > out the improvements of scalarization. > > It's even worse if the interface is then suddenly implemented by a different, > non-inline type. We > would need to re-compile all dependent code resulting in a deoptimization-storm > and re-compute the > calling convention (something that is not easily possible with the current > implementation). This can be implemented for sealed interface only where there is only one subclass. > > Also, the VM would need to ensure that the argument/return type is eagerly > loaded when the adapters > are created at method link time (how do we even know eager loading is required > for these L-types?). You can't, but you may know at JIT time that an interface if solely implemented by an inline type (primitive object type ?) > > Of course, we can push these limits as far as we can but the reality is that > when mixing inline > types with objects or interfaces, there will always be "boundaries" at which we > have to buffer and > this will lead to "unexpected" drops in performance. yes, avoid buffering in c1 may help, tweaking the inlining may help but those are > > Hope that helps. > > Best regards, > Tobias R?mi > > [1] > https://mail.openjdk.java.net/pipermail/valhalla-dev/2019-December/006668.html > [2] https://bugs.openjdk.java.net/browse/JDK-8212245 From maurizio.cimadamore at oracle.com Wed Oct 21 17:40:57 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Oct 2020 18:40:57 +0100 Subject: Limitations of the Calling Convention Optimization In-Reply-To: <245e5987-0d03-b3a6-ba6b-6c02b74e1da5@oracle.com> References: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> <245e5987-0d03-b3a6-ba6b-6c02b74e1da5@oracle.com> Message-ID: <9c8c2068-9f7a-99b5-4729-5c4b914c8c46@oracle.com> On 21/10/2020 18:14, Brian Goetz wrote: > What I am hoping to get out of this discussion is a better > understanding of what API design guidelines we have to give to > developers.? The standard advice is "use interfaces in external APIs", > and there are very good reasons for this. Interfaces make no > commitment as to implementation, allowing implementations to evolve.? > Maybe there's one implementation now and multiple later; maybe there > are multiple now and one later; interfaces give us this freedom (and > sealing further gives us the freedom to control this destiny.) > > If we have to tell people "if you ever might want to use a primitive > class to implement X, you must do that up-front, burn that into your > APIs, and permanently give up on ever having multiple > implementations", this is a different story, and obviously more limiting. > > I think Maurizio had been (reasonably) assuming that, if there was > just one inline implementation, we would be able to get some > reasonable baseline of performance expectations in the sealed > interface + primitive class implementation world, allowing us to > continue with the API design principles that have stood us well for > decades.? But it sounds like we're not sure about that now. Yes - here's some context to what I'm doing. There are some interfaces in Panama, such as MemorySegment and MemoryAddress which "scream" to be implemented by an inline class: https://docs.oracle.com/en/java/javase/15/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/MemoryAddress.html https://docs.oracle.com/en/java/javase/15/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/MemorySegment.html My mental model all along has been that, if we design things carefully, we can switch to a world where these interfaces are implemented by a regular class to a world where these interfaces are implemented by a (single) inline class. Note that the javadoc already states that these interfaces are value-based, and that in the future they will become sealed - that is, no 3rd party implementation of them is possible (since their implementation are so tied to the Panama runtime). Unfortunately, the problematic idioms referred to in this thread shows up quite a bit throughout the API; these are only some of the methods which return new instances of these classes: For instance, in MemoryAddress we find the following methods: MemoryAddress addOffset(long offset); // returns _new_ address with given offset from existing one static MemoryAddress ofLong(long value); // create _new_ address with given long value And, in MemorySegment, we have many more examples, for instance: MemorySegment withAccessModes(int modes); // create _new_ segment with given access modes MemorySegment asSlice(long offset, long size); // create _new_ segment with given offset and size static MemorySegment ofArray(byte[]); // create _new_ segment from byte heap array The limitations described in this thread means that, as an API developer, the only way for me to guarantee a predictable performance model is to replace the MA/MS interfaces with inline classes. Which I can do,? no problem (after all the API is still incubating). But I'm worried, as Brian says clearly above, as to where this leaves API developers in general, where, sometimes, binary compatibility might put additional constraints on which refactorings are possible. In other words, have an interface being implemented by an inline/primitive class is a powerful concept on paper - as it allows _existing_ API to take advantage of (some?) the performance optimization promised by Valhalla. So, while I understand why things work the way they do (in hindsight the nullability problem is rather obvious) this affair let me a bit sad :-) Cheers Maurizio > > To be clear, this is bigger than calling-convention optimizations; > it's about our goals for what language we want to build; it seems like > we have been assuming some things that are not quite valid, and its > important to understand the implications and whether the requirements > need to be adjusted. > > > On 10/21/2020 12:34 PM, John Rose wrote: >> On Oct 21, 2020, at 5:02 AM, Tobias Hartmann >> wrote: >>> Also, the VM would need to ensure that the argument/return type is >>> eagerly loaded when the adapters >>> are created at method link time (how do we even know eager loading >>> is required for these L-types?). >> This is the hard kernel of the problem.? The L in LFoo; means >> ?Lazy Loading? (among other things); you simply cannot assume >> that Foo.class will be loaded when you are setting up layouts and >> calling sequences for an LFoo;.? To get that information (and more) >> we will always need a signal somewhere in the call site which says, >> ?do the preload? (which is what I call the ?go and look? signal). >> The Q in QFooVal; performs this duty. >> >> That said, we might have wiggle room with sealed interfaces. >> If there is a ?go and look? signal (QFooVal;) nearby that has >> forced the loading of an inline type FooVal which has an >> interface type FooRef as a super, *and* if FooRef is sealed, >> then we can go to work on FooRef calling sequences, if we >> think it?s profitable.? (We could substitute in a null flag plus >> a FooVal instance, and we can try to merge the null flag into >> the ?guts? of the FooVal registers, if there is slack.? Or pass >> the FooVal on stack by reference.? Or other tricks like that.) >> >> But, back to the hard kernel of the problem, if there is no >> mention of QFooVal; near the LFooRef; descriptor, all bets >> are off; FooRef.class must be assumed to be unavailable in >> the general case when forming calling sequences involving >> LFooRef;. >> >> The laziness of LFoo; gives it opaqueness, abstraction.? All you >> know is it?s a pointer; you can?t know (in general) what it >> points to until Foo.class is loaded and there?s an instance >> of Foo running around.? Before that it?s just nulls.? The >> opaqueness of LFoo; in turn means that you don?t know >> whether it is just a GC heap reference or something special >> (a disguised value).? When we try to do special side-heap >> treatment for LFoo; values that we discover are disguised >> values, we find that it?s difficult to contain the uses of >> those values; they are so nondescript they mix with >> Object pointers.? This creates a kind of pollution where >> suddenly every pointer that might be handed to the GC >> has to be checked to see if it?s a side-heap pointer (e.g., >> thread local or on-stack). This possibility of pollution >> is introduced by the abstractness of LFoo; and the >> result of it is hard-to-control extra expenses wherever >> an opaque pointer must be stored in the real GC heap. >> >> Maybe we can slim those expenses down in the future, >> using ZGC-like colored pointers.? For now, I think the >> good thing to do is buffer on the real GC heap, as we >> do now.? Maybe the performance can be increased in >> the future by using side-heap tricks, after we figure >> out how to prevent side-heap pointers from polluting >> the real GC heap. >> >> It?s an odd linkage:? the Lazy Loading LFoo;, by its >> nature, has surprising connections to the GC. >> >> ? John > From mchung at openjdk.java.net Wed Oct 21 17:43:19 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 21 Oct 2020 17:43:19 GMT Subject: RFR: 8255125: [Development] copy jdk.internal.ValueBased to jep390 branch In-Reply-To: <7ICzUddVzxLZPMi1grTzaHbrX96te8xjRw7q0leZFMQ=.a282096f-6c2d-4e50-a221-58b664759ba1@github.com> References: <7ICzUddVzxLZPMi1grTzaHbrX96te8xjRw7q0leZFMQ=.a282096f-6c2d-4e50-a221-58b664759ba1@github.com> Message-ID: On Wed, 21 Oct 2020 13:48:41 GMT, Roger Riggs wrote: > Commit a copy of the ValueBased.java and its uses to the JEP 390 branch. The initial patch looks okay that will allow javac and VM change to proceed. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/valhalla/pull/235 From rriggs at openjdk.java.net Wed Oct 21 18:06:30 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 21 Oct 2020 18:06:30 GMT Subject: Integrated: 8255125: [Development] copy jdk.internal.ValueBased to jep390 branch In-Reply-To: <7ICzUddVzxLZPMi1grTzaHbrX96te8xjRw7q0leZFMQ=.a282096f-6c2d-4e50-a221-58b664759ba1@github.com> References: <7ICzUddVzxLZPMi1grTzaHbrX96te8xjRw7q0leZFMQ=.a282096f-6c2d-4e50-a221-58b664759ba1@github.com> Message-ID: On Wed, 21 Oct 2020 13:48:41 GMT, Roger Riggs wrote: > Commit a copy of the ValueBased.java and its uses to the JEP 390 branch. This pull request has now been integrated. Changeset: f2f03c8b Author: Roger Riggs URL: https://git.openjdk.java.net/valhalla/commit/f2f03c8b Stats: 80 lines in 37 files changed: 78 ins; 1 del; 1 mod 8255125: [Development] copy jdk.internal.ValueBased to jep390 branch Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/valhalla/pull/235 From brian.goetz at oracle.com Wed Oct 21 18:25:19 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 21 Oct 2020 14:25:19 -0400 Subject: Limitations of the Calling Convention Optimization In-Reply-To: <9c8c2068-9f7a-99b5-4729-5c4b914c8c46@oracle.com> References: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> <245e5987-0d03-b3a6-ba6b-6c02b74e1da5@oracle.com> <9c8c2068-9f7a-99b5-4729-5c4b914c8c46@oracle.com> Message-ID: <40310a9c-eee2-018a-ebc9-98ec1c35a880@oracle.com> > > Unfortunately, the problematic idioms referred to in this thread shows > up quite a bit throughout the API; these are only some of the methods > which return new instances of these classes: > > For instance, in MemoryAddress we find the following methods: > > MemoryAddress addOffset(long offset); // returns _new_ address with > given offset from existing one > static MemoryAddress ofLong(long value); // create _new_ address with > given long value Let's try and invert the question.? Rather than beating up the JIT guys with "Y U no scalarize", let's ask: what information would the JIT need (and _when_) in order to routinely scalarize methods like this? It seems that one part of it is knowing that these will never return a null reference.? Here's one way we might express this constraint in source code, using idioms the language already has: ??? sealed interface MA permits Impl { MA offset(long offset); } ??? primitive class Impl implements MA { ??????? @Override??????? // covariant override ??????? Impl addOffset(long offset) { ... } ??? } From a language perspective, this makes sense to developers (and, this is hidden in the implementation); we're returning a more constrained type, which the language already allows.? Ignoring the translation story here (MA::offset and Impl::offset might have different descriptors, bridge methods, yada yada), would having information like this strewn throughout the implementation be sufficient to hint the JIT that no nulls will be forthcoming? From maurizio.cimadamore at oracle.com Wed Oct 21 19:58:40 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Oct 2020 20:58:40 +0100 Subject: Limitations of the Calling Convention Optimization In-Reply-To: <40310a9c-eee2-018a-ebc9-98ec1c35a880@oracle.com> References: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> <245e5987-0d03-b3a6-ba6b-6c02b74e1da5@oracle.com> <9c8c2068-9f7a-99b5-4729-5c4b914c8c46@oracle.com> <40310a9c-eee2-018a-ebc9-98ec1c35a880@oracle.com> Message-ID: <24d1d2d8-e5db-bd0d-4323-55f6d079beab@oracle.com> On 21/10/2020 19:25, Brian Goetz wrote: > >> >> Unfortunately, the problematic idioms referred to in this thread >> shows up quite a bit throughout the API; these are only some of the >> methods which return new instances of these classes: >> >> For instance, in MemoryAddress we find the following methods: >> >> MemoryAddress addOffset(long offset); // returns _new_ address with >> given offset from existing one >> static MemoryAddress ofLong(long value); // create _new_ address with >> given long value > > Let's try and invert the question.? Rather than beating up the JIT > guys with "Y U no scalarize", let's ask: what information would the > JIT need (and _when_) in order to routinely scalarize methods like this? > > It seems that one part of it is knowing that these will never return a > null reference.? Here's one way we might express this constraint in > source code, using idioms the language already has: > > ??? sealed interface MA permits Impl { MA offset(long offset); } > > ??? primitive class Impl implements MA { > ??????? @Override??????? // covariant override > ??????? Impl addOffset(long offset) { ... } > ??? } > > From a language perspective, this makes sense to developers (and, this > is hidden in the implementation); we're returning a more constrained > type, which the language already allows.? Ignoring the translation > story here (MA::offset and Impl::offset might have different > descriptors, bridge methods, yada yada), would having information like > this strewn throughout the implementation be sufficient to hint the > JIT that no nulls will be forthcoming? > > I tried this - I couldn't get it to work - the compiler complains if you try that. Also, while this works for return types, it doesn't scale to parameters, right? Maurizio From brian.goetz at oracle.com Wed Oct 21 21:02:11 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 21 Oct 2020 17:02:11 -0400 Subject: Limitations of the Calling Convention Optimization In-Reply-To: <24d1d2d8-e5db-bd0d-4323-55f6d079beab@oracle.com> References: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> <245e5987-0d03-b3a6-ba6b-6c02b74e1da5@oracle.com> <9c8c2068-9f7a-99b5-4729-5c4b914c8c46@oracle.com> <40310a9c-eee2-018a-ebc9-98ec1c35a880@oracle.com> <24d1d2d8-e5db-bd0d-4323-55f6d079beab@oracle.com> Message-ID: <01a4c8e3-6286-cd7c-4500-c127d461cf83@oracle.com> Sorry, I wasn't suggesting "try changing your code this way and see if it works", as much as "if the user could code this way, could we infer what is going on, and put information in the classfile that can help the VM do the right thing at runtime." On 10/21/2020 3:58 PM, Maurizio Cimadamore wrote: > > On 21/10/2020 19:25, Brian Goetz wrote: >> >>> >>> Unfortunately, the problematic idioms referred to in this thread >>> shows up quite a bit throughout the API; these are only some of the >>> methods which return new instances of these classes: >>> >>> For instance, in MemoryAddress we find the following methods: >>> >>> MemoryAddress addOffset(long offset); // returns _new_ address with >>> given offset from existing one >>> static MemoryAddress ofLong(long value); // create _new_ address >>> with given long value >> >> Let's try and invert the question.? Rather than beating up the JIT >> guys with "Y U no scalarize", let's ask: what information would the >> JIT need (and _when_) in order to routinely scalarize methods like this? >> >> It seems that one part of it is knowing that these will never return >> a null reference.? Here's one way we might express this constraint in >> source code, using idioms the language already has: >> >> ??? sealed interface MA permits Impl { MA offset(long offset); } >> >> ??? primitive class Impl implements MA { >> ??????? @Override??????? // covariant override >> ??????? Impl addOffset(long offset) { ... } >> ??? } >> >> From a language perspective, this makes sense to developers (and, >> this is hidden in the implementation); we're returning a more >> constrained type, which the language already allows. Ignoring the >> translation story here (MA::offset and Impl::offset might have >> different descriptors, bridge methods, yada yada), would having >> information like this strewn throughout the implementation be >> sufficient to hint the JIT that no nulls will be forthcoming? >> >> > I tried this - I couldn't get it to work - the compiler complains if > you try that. > > Also, while this works for return types, it doesn't scale to > parameters, right? > > Maurizio > From forax at univ-mlv.fr Wed Oct 21 21:49:19 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 21 Oct 2020 23:49:19 +0200 (CEST) Subject: Limitations of the Calling Convention Optimization In-Reply-To: <40310a9c-eee2-018a-ebc9-98ec1c35a880@oracle.com> References: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> <245e5987-0d03-b3a6-ba6b-6c02b74e1da5@oracle.com> <9c8c2068-9f7a-99b5-4729-5c4b914c8c46@oracle.com> <40310a9c-eee2-018a-ebc9-98ec1c35a880@oracle.com> Message-ID: <513555884.658.1603316959531.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Brian Goetz" > ?: "Maurizio Cimadamore" , "John Rose" , "Tobias Hartmann" > > Cc: "valhalla-dev" > Envoy?: Mercredi 21 Octobre 2020 20:25:19 > Objet: Re: Limitations of the Calling Convention Optimization >> >> Unfortunately, the problematic idioms referred to in this thread shows >> up quite a bit throughout the API; these are only some of the methods >> which return new instances of these classes: >> >> For instance, in MemoryAddress we find the following methods: >> >> MemoryAddress addOffset(long offset); // returns _new_ address with >> given offset from existing one >> static MemoryAddress ofLong(long value); // create _new_ address with >> given long value > > Let's try and invert the question.? Rather than beating up the JIT guys > with "Y U no scalarize", let's ask: what information would the JIT need > (and _when_) in order to routinely scalarize methods like this? > > It seems that one part of it is knowing that these will never return a > null reference.? Here's one way we might express this constraint in > source code, using idioms the language already has: > > ??? sealed interface MA permits Impl { MA offset(long offset); } > > ??? primitive class Impl implements MA { > ??????? @Override??????? // covariant override > ??????? Impl addOffset(long offset) { ... } > ??? } > > From a language perspective, this makes sense to developers (and, this > is hidden in the implementation); we're returning a more constrained > type, which the language already allows.? Ignoring the translation story > here (MA::offset and Impl::offset might have different descriptors, > bridge methods, yada yada), would having information like this strewn > throughout the implementation be sufficient to hint the JIT that no > nulls will be forthcoming? It doesn't work in the general case because it still requires inlining to work. If there is no inlining, the caller doesn't inline the bridge method. Until we have something like the bridge-o-matic proposal, I propose this hack, it's not pretty but it should work. sealed interface Ma permits Impl { @ForceInline default MA add(MA ma) { return Impl.add(this, (Impl)ma); } } primitive class Impl implements MA { /* package private */ static Impl add(Impl impl1, Impl impl2) { ... } } cheers, R?mi From maurizio.cimadamore at oracle.com Thu Oct 22 09:47:32 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 22 Oct 2020 10:47:32 +0100 Subject: Limitations of the Calling Convention Optimization In-Reply-To: <01a4c8e3-6286-cd7c-4500-c127d461cf83@oracle.com> References: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> <245e5987-0d03-b3a6-ba6b-6c02b74e1da5@oracle.com> <9c8c2068-9f7a-99b5-4729-5c4b914c8c46@oracle.com> <40310a9c-eee2-018a-ebc9-98ec1c35a880@oracle.com> <24d1d2d8-e5db-bd0d-4323-55f6d079beab@oracle.com> <01a4c8e3-6286-cd7c-4500-c127d461cf83@oracle.com> Message-ID: On 21/10/2020 22:02, Brian Goetz wrote: > Sorry, I wasn't suggesting "try changing your code this way and see if > it works", as much as "if the user could code this way, could we infer > what is going on, and put information in the classfile that can help > the VM do the right thing at runtime." And, my email came off wrong - the thought of covariant override occurred to me as well when writing the implementation - I think it has some legs (especially if the interface call can be devirtualized). But I'm still at a loss as to what can be done for parameter types (albeit, admittedly, the Panama API has far fewer examples in this category). Maurizio > > On 10/21/2020 3:58 PM, Maurizio Cimadamore wrote: >> >> On 21/10/2020 19:25, Brian Goetz wrote: >>> >>>> >>>> Unfortunately, the problematic idioms referred to in this thread >>>> shows up quite a bit throughout the API; these are only some of the >>>> methods which return new instances of these classes: >>>> >>>> For instance, in MemoryAddress we find the following methods: >>>> >>>> MemoryAddress addOffset(long offset); // returns _new_ address with >>>> given offset from existing one >>>> static MemoryAddress ofLong(long value); // create _new_ address >>>> with given long value >>> >>> Let's try and invert the question.? Rather than beating up the JIT >>> guys with "Y U no scalarize", let's ask: what information would the >>> JIT need (and _when_) in order to routinely scalarize methods like >>> this? >>> >>> It seems that one part of it is knowing that these will never return >>> a null reference.? Here's one way we might express this constraint >>> in source code, using idioms the language already has: >>> >>> ??? sealed interface MA permits Impl { MA offset(long offset); } >>> >>> ??? primitive class Impl implements MA { >>> ??????? @Override??????? // covariant override >>> ??????? Impl addOffset(long offset) { ... } >>> ??? } >>> >>> From a language perspective, this makes sense to developers (and, >>> this is hidden in the implementation); we're returning a more >>> constrained type, which the language already allows. Ignoring the >>> translation story here (MA::offset and Impl::offset might have >>> different descriptors, bridge methods, yada yada), would having >>> information like this strewn throughout the implementation be >>> sufficient to hint the JIT that no nulls will be forthcoming? >>> >>> >> I tried this - I couldn't get it to work - the compiler complains if >> you try that. >> >> Also, while this works for return types, it doesn't scale to >> parameters, right? >> >> Maurizio >> > From tobias.hartmann at oracle.com Thu Oct 22 10:30:30 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 22 Oct 2020 12:30:30 +0200 Subject: Limitations of the Calling Convention Optimization In-Reply-To: <396995431.1797864.1603301845623.JavaMail.zimbra@u-pem.fr> References: <396995431.1797864.1603301845623.JavaMail.zimbra@u-pem.fr> Message-ID: Hi R?mi, On 21.10.20 19:37, Remi Forax wrote: >> 1) Improving the inlining heuristic is a long standing issue with C2 that is >> independent of inline >> types and an entire project on its own. Of course, we could tweak the current >> implementation such >> that problematic calls are more likely to be inlined but that will still be >> limited and might have >> side effects. > > There are possible tweaks that are backward compatible because currently there is no Q-type in any published jars. > Instead of doing the inlining from top to bottom, starts by inlining methods that have a Q-type and then inline the other methods from top to bottom. Sure but my point is that tweaking the inlining heuristic is far from trivial and even inline type specific tweaks will have unforeseeable side effects on code not using inline types. And as always, we can't inline everything. > The other thing is that from my own experience, it's kind of rare to have all the interresting methods compiled with c2, > usually you have a mix of methods compiled with c2 and c1. So it seams that implementing the scalarization calling convention in c1 may help. Yes but that won't help because C1 does not even scalarize in the scope of a compilation unit (i.e. even if we pass/return to C1 in a scalarized form, C1 will need to immediately buffer). Like the interpreter, it always buffers inline types and it was never designed to support scalarization. >> 2) We've already evaluated options to make buffering more light-weight in the >> past. For example, >> thread-local value buffering [2] turned out to not improve performance as >> expected while adding lots >> of complexity and required costly runtime checks. And even if we buffer inline >> types outside of the >> Java heap, the GC still needs to know about object fields. > > I wonder if aload(slot)/astore(slot) can be transformed to qload(slot, inlineSize) and qstore(slot, inlineSize) before being interpreted. Not sure if I'm following but are you suggesting to replace individual inline buffer loads/stores by vectorized loads/stores? First, it's not necessary to do any kind of bytecode transformations here to help the JIT. The JIT has the "full picture" and can do all kinds of transformations at compilation time. Second, the most expensive part of buffering is not the buffer creation or the loads/stores but the impact on the GC. Also, the JIT already plays all kinds of tricks to avoid unnecessary loads/stores. >> It's even worse if the interface is then suddenly implemented by a different, >> non-inline type. We >> would need to re-compile all dependent code resulting in a deoptimization-storm >> and re-compute the >> calling convention (something that is not easily possible with the current >> implementation). > > This can be implemented for sealed interface only where there is only one subclass. Sure but then we still have the issue of not being able to represent 'null' in the flat representation (i.e. we are back to that discussion). >> Also, the VM would need to ensure that the argument/return type is eagerly >> loaded when the adapters >> are created at method link time (how do we even know eager loading is required >> for these L-types?). > > You can't, but you may know at JIT time that an interface if solely implemented by an inline type (primitive object type ?) Yes but that is too late. The calling convention needs to be determined at method link time and can't be changed later. >> Of course, we can push these limits as far as we can but the reality is that >> when mixing inline >> types with objects or interfaces, there will always be "boundaries" at which we >> have to buffer and >> this will lead to "unexpected" drops in performance. > > yes, > avoid buffering in c1 may help, tweaking the inlining may help but those are Seems like part of your sentence got cut off but yes, these are only mitigations. Best regards, Tobias From skuksenko at openjdk.java.net Thu Oct 22 17:22:25 2020 From: skuksenko at openjdk.java.net (Sergey Kuksenko) Date: Thu, 22 Oct 2020 17:22:25 GMT Subject: [lworld] RFR: 8247299: [lworld] Disable UseBiasedLocking by default In-Reply-To: References: <2UZBUQ4bleTxWsNuQeupRkH3uHtgDmIKgBWhopO-wBc=.87dde588-8115-4cc2-ab94-140bfd4ef5af@github.com> Message-ID: <2rhA8zDYphvFowHtZF4UNEU6E-DI4rppLkWu_OJ7sYU=.93ba71a3-201d-4207-b571-ede8773548c8@github.com> On Tue, 20 Oct 2020 18:30:33 GMT, Frederic Parain wrote: >> Disabled UseBiasedLocking, and reorganized markWord to serve Valhalla requirements (see also JDK-8247298 for motivation). >> >> Actual UseBiasedLocking code remains simply to avoid future conflicts. Since static constants have changed and UseBiasedLocking is deprecated, Valhalla assumes it will be removed, and it is not only disabled "by default", but now unusable. >> >> Tier1-3 testing clean > > Looks good to me. > > Fred Comment. It won't work for arrays properly. file: oop.inline.hpp line 207 - bool oopDesc::is_flatArray() const { return klass()->is_flatArray_klass(); } + bool oopDesc::is_flatArray() const { return mark().is_flat_array(); } Array maybe locked. So is_flatArray should be like this: bool oopDesc::is_flatArray() const { if(mark().is_unlocked()) { return mark().is_flat_array(); } else { return klass()->is_flatArray_klass(); } } ------------- PR: https://git.openjdk.java.net/valhalla/pull/234 From forax at univ-mlv.fr Thu Oct 22 18:02:59 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 22 Oct 2020 20:02:59 +0200 (CEST) Subject: Limitations of the Calling Convention Optimization In-Reply-To: References: <396995431.1797864.1603301845623.JavaMail.zimbra@u-pem.fr> Message-ID: <527037565.1221157.1603389779944.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Tobias Hartmann" > ?: "Remi Forax" > Cc: "valhalla-dev" > Envoy?: Jeudi 22 Octobre 2020 12:30:30 > Objet: Re: Limitations of the Calling Convention Optimization > Hi R?mi, > > On 21.10.20 19:37, Remi Forax wrote: >>> 1) Improving the inlining heuristic is a long standing issue with C2 that is >>> independent of inline >>> types and an entire project on its own. Of course, we could tweak the current >>> implementation such >>> that problematic calls are more likely to be inlined but that will still be >>> limited and might have >>> side effects. >> >> There are possible tweaks that are backward compatible because currently there >> is no Q-type in any published jars. >> Instead of doing the inlining from top to bottom, starts by inlining methods >> that have a Q-type and then inline the other methods from top to bottom. > > Sure but my point is that tweaking the inlining heuristic is far from trivial > and even inline type > specific tweaks will have unforeseeable side effects on code not using inline > types. ??, i fail to see how it can affect code that not have been written yet. > And as always, we can't inline everything. yes. > >> The other thing is that from my own experience, it's kind of rare to have all >> the interresting methods compiled with c2, >> usually you have a mix of methods compiled with c2 and c1. So it seams that >> implementing the scalarization calling convention in c1 may help. > > Yes but that won't help because C1 does not even scalarize in the scope of a > compilation unit (i.e. even if we pass/return to C1 in a scalarized form, C1 will need to immediately > buffer). Like the interpreter, it always buffers inline types and it was never designed to support > scalarization. c1 doesn't have to buffer because it can do on stack allocation (at least for small inline object). With that, you may be able to scalarize method calls in c1. > >>> 2) We've already evaluated options to make buffering more light-weight in the >>> past. For example, >>> thread-local value buffering [2] turned out to not improve performance as >>> expected while adding lots >>> of complexity and required costly runtime checks. And even if we buffer inline >>> types outside of the >>> Java heap, the GC still needs to know about object fields. >> >> I wonder if aload(slot)/astore(slot) can be transformed to qload(slot, >> inlineSize) and qstore(slot, inlineSize) before being interpreted. > > Not sure if I'm following but are you suggesting to replace individual inline > buffer loads/stores by vectorized loads/stores? I was suggesting to see inline objects as part of the stack (like double are using two slots) for small inline object. This can be don by c1 and maybe by the interpreter if you can rewrite the bytecode. > > First, it's not necessary to do any kind of bytecode transformations here to help the JIT. yes, for c2, but it can help for c1 and the interpreter. And if small inline objects are stack allocated, they can use a scalarized calling convention. > The JIT has the "full picture" and can do all kinds of transformations at compilation time. it has a full picture when everything is inlined. Here we are talking when the inlining fails. > Second, the most > expensive part of buffering is not the buffer creation or the loads/stores but > the impact on the GC. > Also, the JIT already plays all kinds of tricks to avoid unnecessary > loads/stores. yep, that why i'm proposing to do stack allocation, to avoid to put pressure on the GC. I believe c1 can use two different types to represent stack allocated inline objects and heap allocated inline objects, avoiding to heap allocate if not necessary but also avoiding to stack allocate something that will escape into a reference too. If you are using two different types, you should not have to do runtime check unlike when the runtime was doing buffering. > >>> It's even worse if the interface is then suddenly implemented by a different, >>> non-inline type. We >>> would need to re-compile all dependent code resulting in a deoptimization-storm >>> and re-compute the >>> calling convention (something that is not easily possible with the current >>> implementation). >> >> This can be implemented for sealed interface only where there is only one >> subclass. > > Sure but then we still have the issue of not being able to represent 'null' in > the flat representation (i.e. we are back to that discussion). Null check speculation may help here. It's what i'm doing to do primitive speculation (for a dynamically typed language) but it's a speculative optimization and it requires to have at least two calling convention, the boxed one when you send a reference and the stack allocated one where you copy the primitive object. >>> Also, the VM would need to ensure that the argument/return type is eagerly >>> loaded when the adapters >>> are created at method link time (how do we even know eager loading is required >>> for these L-types?). >> >> You can't, but you may know at JIT time that an interface if solely implemented >> by an inline type (primitive object type ?) > > Yes but that is too late. The calling convention needs to be determined at method link time and can't be changed later. It's a current limitation of Hotspot, it doesn't have to be that way. You already have multiple entry points, you may be able to have two calling conventions, the one with primitive object scalarized and the one using reference. It will make less allocation when transitionning from c1 to c2 and back. >>> Of course, we can push these limits as far as we can but the reality is that >>> when mixing inline >>> types with objects or interfaces, there will always be "boundaries" at which we >>> have to buffer and >>> this will lead to "unexpected" drops in performance. >> >> yes, >> avoid buffering in c1 may help, tweaking the inlining may help but those are > > Seems like part of your sentence got cut off but yes, these are only > mitigations. yes, "those are mostly optimistic optimizations" was the sentence that was cut off. To summarize, i believe it's possible to - have two different types for primitive objects in c1 and do stack allocation when possible. - have at least two different calling conventions, so if a primitve object is stack allocated, it can use the scalarized function call. - that you can speculate on sealed primitive ref interface/abstract class being not null when calling a method by adding a probe that checks if the ref is null or not (the same way you know if a branch is taken or which class has been seen). > > Best regards, > Tobias regards, R?mi From rriggs at openjdk.java.net Thu Oct 22 18:40:39 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 22 Oct 2020 18:40:39 GMT Subject: [lworld] RFR: 8255250: [lworld] Backout patch adding jdk.internal.ValueBased Message-ID: <9gAAAjaJGJRfxwuxXw-XJn_Advr6UG6qpnZCGzB7-e0=.41505f5b-2617-4a92-85bc-a0003f3448da@github.com> Backout the change that added jdk.internal.ValueBased that should have been pushed to the jep390 branch. ------------- Commit messages: - 8255250: [lworld] Backout patch adding jdk.internal.ValueBased Changes: https://git.openjdk.java.net/valhalla/pull/236/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=236&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255250 Stats: 80 lines in 37 files changed: 1 ins; 78 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/236.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/236/head:pull/236 PR: https://git.openjdk.java.net/valhalla/pull/236 From mchung at openjdk.java.net Thu Oct 22 18:45:21 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 22 Oct 2020 18:45:21 GMT Subject: [lworld] RFR: 8255250: [lworld] Backout patch adding jdk.internal.ValueBased In-Reply-To: <9gAAAjaJGJRfxwuxXw-XJn_Advr6UG6qpnZCGzB7-e0=.41505f5b-2617-4a92-85bc-a0003f3448da@github.com> References: <9gAAAjaJGJRfxwuxXw-XJn_Advr6UG6qpnZCGzB7-e0=.41505f5b-2617-4a92-85bc-a0003f3448da@github.com> Message-ID: On Thu, 22 Oct 2020 18:34:43 GMT, Roger Riggs wrote: > Backout the change that added jdk.internal.ValueBased that should have been pushed to the jep390 branch. Marked as reviewed by mchung (Committer). ------------- PR: https://git.openjdk.java.net/valhalla/pull/236 From rriggs at openjdk.java.net Thu Oct 22 19:44:24 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 22 Oct 2020 19:44:24 GMT Subject: git: openjdk/valhalla: lworld: 8255250: [lworld] Backout patch adding jdk.internal.ValueBased Message-ID: Changeset: d387b298 Author: Roger Riggs Date: 2020-10-22 19:44:05 +0000 URL: https://git.openjdk.java.net/valhalla/commit/d387b298 8255250: [lworld] Backout patch adding jdk.internal.ValueBased Reviewed-by: mchung ! src/java.base/share/classes/java/lang/Boolean.java ! src/java.base/share/classes/java/lang/Byte.java ! src/java.base/share/classes/java/lang/Character.java ! src/java.base/share/classes/java/lang/Double.java ! src/java.base/share/classes/java/lang/Float.java ! src/java.base/share/classes/java/lang/Integer.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/ProcessHandle.java ! src/java.base/share/classes/java/lang/ProcessHandleImpl.java ! src/java.base/share/classes/java/lang/Runtime.java ! src/java.base/share/classes/java/lang/Short.java ! src/java.base/share/classes/java/time/Duration.java ! src/java.base/share/classes/java/time/Instant.java ! src/java.base/share/classes/java/time/LocalDate.java ! src/java.base/share/classes/java/time/LocalDateTime.java ! src/java.base/share/classes/java/time/LocalTime.java ! src/java.base/share/classes/java/time/MonthDay.java ! src/java.base/share/classes/java/time/OffsetDateTime.java ! src/java.base/share/classes/java/time/OffsetTime.java ! src/java.base/share/classes/java/time/Period.java ! src/java.base/share/classes/java/time/Year.java ! src/java.base/share/classes/java/time/YearMonth.java ! src/java.base/share/classes/java/time/ZoneId.java ! src/java.base/share/classes/java/time/ZoneOffset.java ! src/java.base/share/classes/java/time/ZonedDateTime.java ! src/java.base/share/classes/java/time/chrono/HijrahDate.java ! src/java.base/share/classes/java/time/chrono/JapaneseDate.java ! src/java.base/share/classes/java/time/chrono/MinguoDate.java ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/java.base/share/classes/java/time/format/TextStyle.java ! src/java.base/share/classes/java/util/KeyValueHolder.java ! src/java.base/share/classes/java/util/Optional.java ! src/java.base/share/classes/java/util/OptionalDouble.java ! src/java.base/share/classes/java/util/OptionalInt.java ! src/java.base/share/classes/java/util/OptionalLong.java - src/java.base/share/classes/jdk/internal/ValueBased.java From rriggs at openjdk.java.net Thu Oct 22 19:47:24 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 22 Oct 2020 19:47:24 GMT Subject: [lworld] Integrated: 8255250: [lworld] Backout patch adding jdk.internal.ValueBased In-Reply-To: <9gAAAjaJGJRfxwuxXw-XJn_Advr6UG6qpnZCGzB7-e0=.41505f5b-2617-4a92-85bc-a0003f3448da@github.com> References: <9gAAAjaJGJRfxwuxXw-XJn_Advr6UG6qpnZCGzB7-e0=.41505f5b-2617-4a92-85bc-a0003f3448da@github.com> Message-ID: On Thu, 22 Oct 2020 18:34:43 GMT, Roger Riggs wrote: > Backout the change that added jdk.internal.ValueBased that should have been pushed to the jep390 branch. This pull request has now been integrated. Changeset: d387b298 Author: Roger Riggs URL: https://git.openjdk.java.net/valhalla/commit/d387b298 Stats: 80 lines in 37 files changed: 1 ins; 78 del; 1 mod 8255250: [lworld] Backout patch adding jdk.internal.ValueBased Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/valhalla/pull/236 From tobias.hartmann at oracle.com Fri Oct 23 06:51:11 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 23 Oct 2020 08:51:11 +0200 Subject: Limitations of the Calling Convention Optimization In-Reply-To: <527037565.1221157.1603389779944.JavaMail.zimbra@u-pem.fr> References: <396995431.1797864.1603301845623.JavaMail.zimbra@u-pem.fr> <527037565.1221157.1603389779944.JavaMail.zimbra@u-pem.fr> Message-ID: <7d1afd16-0d89-44aa-bc41-78b93b8819a9@oracle.com> On 22.10.20 20:02, forax at univ-mlv.fr wrote: >> Sure but my point is that tweaking the inlining heuristic is far from trivial >> and even inline type >> specific tweaks will have unforeseeable side effects on code not using inline >> types. > > ??, > i fail to see how it can affect code that not have been written yet. You suggested to prefer Q-typed methods in the inlining heuristic which will in turn have a negative effect on inlining of other methods that don't use Q-types (given that we only have a limited inlining budget). I.e., just having one little Q-typed method somewhere in the call stack could in the worst case negatively affect the performance because suddenly that method is preferred over another method. But let's not go too much into detail here, my point is that inlining should not be improved as part of this project and certainly not by adding tweaks for every new feature that would benefit from special treatment by the heuristic. > c1 doesn't have to buffer because it can do on stack allocation (at least for small inline object). > With that, you may be able to scalarize method calls in c1. No, C1 can't do stack allocation because we don't support stack allocation anywhere in the VM. It would be a completely new feature. What we do for inline types in C2 is *scalarization* (pass field values individually in registers or on the stack) but C1 does not support that either. Microsoft recently proposed to add this feature but only for the C2 compiler: https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-July/042419.html There are no plans to ever add stack allocation support to C1. > I was suggesting to see inline objects as part of the stack (like double are using two slots) for small inline object. > This can be don by c1 and maybe by the interpreter if you can rewrite the bytecode. I think you are confusing the Java stack with the native stack. There is no 1:1 mapping between the two and the layout of the Java stack does not directly affect the layout of the native stack as used by C1/C2 compiled code. I.e., a bytecode transformation to load/store inline types as "vectors" does not magically implement stack allocation. >> First, it's not necessary to do any kind of bytecode transformations here to help the JIT. > > yes, for c2, but it can help for c1 and the interpreter. And if small inline objects are stack allocated, they can use a scalarized calling convention. Yes, assuming that we have support for stack allocation but even then, similar to a thread local buffer, we would still need additional runtime checks (see below). > I believe c1 can use two different types to represent stack allocated inline objects and heap allocated inline objects, > avoiding to heap allocate if not necessary but also avoiding to stack allocate something that will escape into a reference too. > > If you are using two different types, you should not have to do runtime check unlike when the runtime was doing buffering. I was referring to the runtime check that is required to check if a reference is referring to a stack allocated object. If these are passed/returned over method boundaries, we need to check before storing them into any container (because stack allocated objects would require re-allocation on the heap). For example, the callee does not know if the caller passes a stack or heap allocated object. >> Sure but then we still have the issue of not being able to represent 'null' in >> the flat representation (i.e. we are back to that discussion). > > Null check speculation may help here. > It's what i'm doing to do primitive speculation (for a dynamically typed language) but it's a speculative optimization and it requires to have at least two calling convention, > the boxed one when you send a reference and the stack allocated one where you copy the primitive object. We can speculate but the question is how do we handle null if it still shows ups? The easiest way would be to just deoptimize but then performance will suck whenever null is passed. For handling null, it's not sufficient to have two calling conventions (which we already have). You would need to have two complete versions of the method. For example: void int foo(MyInterface bar) { if (bar == null) return 42; return bar.getX(); } If we now speculate that MyInterface is only implemented by MyValue and 'bar' is never null, this will be optimized by C2 to: void int foo(int X) { return X; } Now for that method we already have two calling conventions: 1) bar is passed as reference and then "unpacked" because the method body only works on X 2) bar is passed as field X (i.e. only an integer is passed) But above code does not support a 'null' being passed. To handle null, we would need to have a second version of the same method where the method body handles null: void int foo(MyValue bar) { if (bar == null) return 42; return bar.x; } >>> You can't, but you may know at JIT time that an interface if solely implemented >>> by an inline type (primitive object type ?) >> >> Yes but that is too late. The calling convention needs to be determined at method link time and can't be changed later. > > It's a current limitation of Hotspot, it doesn't have to be that way. Yes, all the things we are talking about in this thread are current limitations of HotSpot. I'm not talking about a generic VM (re-)implementation ;) > You already have multiple entry points, you may be able to have two calling conventions, the one with primitive object scalarized and the one using reference. > It will make less allocation when transitionning from c1 to c2 and back. Sure, we already have that. Best regards, Tobias From tobias.hartmann at oracle.com Fri Oct 23 07:40:44 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 23 Oct 2020 09:40:44 +0200 Subject: Limitations of the Calling Convention Optimization In-Reply-To: <40310a9c-eee2-018a-ebc9-98ec1c35a880@oracle.com> References: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> <245e5987-0d03-b3a6-ba6b-6c02b74e1da5@oracle.com> <9c8c2068-9f7a-99b5-4729-5c4b914c8c46@oracle.com> <40310a9c-eee2-018a-ebc9-98ec1c35a880@oracle.com> Message-ID: Hi Brian, On 21.10.20 20:25, Brian Goetz wrote: > Let's try and invert the question.? Rather than beating up the JIT guys with "Y U no scalarize", > let's ask: what information would the JIT need (and _when_) in order to routinely scalarize methods > like this? With the current implementation, we would need the following information to scalarize interface arguments and returns: - A signal to load the type at method link time (John already elaborated on this [1]) and the information that it's a sealed interface with a single inline type implementor which also needs to be loaded. - A guarantee that the argument/return is null free OR the expectation that passing null will be slow (deoptimization -> execution in the interpreter). Best regards, Tobias [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-October/008141.html From maurizio.cimadamore at oracle.com Fri Oct 23 10:17:00 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 23 Oct 2020 11:17:00 +0100 Subject: Limitations of the Calling Convention Optimization In-Reply-To: <7d1afd16-0d89-44aa-bc41-78b93b8819a9@oracle.com> References: <396995431.1797864.1603301845623.JavaMail.zimbra@u-pem.fr> <527037565.1221157.1603389779944.JavaMail.zimbra@u-pem.fr> <7d1afd16-0d89-44aa-bc41-78b93b8819a9@oracle.com> Message-ID: On 23/10/2020 07:51, Tobias Hartmann wrote: > We can speculate but the question is how do we handle null if it still shows ups? The easiest way > would be to just deoptimize but then performance will suck whenever null is passed. Just a quick note: from an API observation (and of course we need more experiments and data), this might not be as horrible of a compromise as it sounds. If you think of a factory like this: Point makePoint(int x, int y); // Point is an interface which is implemented in the usual way like: Point makePoint(int x, int y) { ??? return new PointImpl(x, y); // PointImpl is an inline implementation of Point } Nulls here are simply not possible, by construction. As my experiment with Panama API show, this is a common idiom when you work with immutable classes with lots of "withers". But it works the other way around too - consider: double distance(Point p1, Point p2); E.g. I would expect the vast majority of the arguments to be null-checked on the way in (Objects.requiresNonNull(p1)). So, my point is that, if we take a slow path when a null is encountered, it might not matter _that_ much because we're about to throw an NPE anyways. Of course this assumption needs to be validated with hard(er) data. Maurizio From brian.goetz at oracle.com Fri Oct 23 12:42:42 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 23 Oct 2020 08:42:42 -0400 Subject: Limitations of the Calling Convention Optimization In-Reply-To: References: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> <245e5987-0d03-b3a6-ba6b-6c02b74e1da5@oracle.com> <9c8c2068-9f7a-99b5-4729-5c4b914c8c46@oracle.com> <40310a9c-eee2-018a-ebc9-98ec1c35a880@oracle.com> Message-ID: So, confirming: we can have multiple calling conventions for a given method, but for a given _call site_, we choose a CC at linkage time and we have to stick with that.? Correct? An "easy" case in Maurizio's library is something like this: ??? sealed interface X permits Val { } ??? primitive class Val implements X { } ??? X makeVal() { return new Val(); } Here, we are always returning a non-null Val.? So ideally, we'd like invocations ??? Val v = makeVal() to scalarize.? But the method descriptor is `()LX;`, and, at linkage time, we can't guarantee `X` has been loaded, which means we can't observe that Val is the only subtype of X.? So what you need is: ?- X and Val have to have been loaded at linkage time; ?- we need some confidence that `makeVal()` always returns a non-null value. Does this capture what you're saying? > Hi Brian, > > On 21.10.20 20:25, Brian Goetz wrote: >> Let's try and invert the question.? Rather than beating up the JIT guys with "Y U no scalarize", >> let's ask: what information would the JIT need (and _when_) in order to routinely scalarize methods >> like this? > With the current implementation, we would need the following information to scalarize interface > arguments and returns: > - A signal to load the type at method link time (John already elaborated on this [1]) and the > information that it's a sealed interface with a single inline type implementor which also needs to > be loaded. > - A guarantee that the argument/return is null free OR the expectation that passing null will be > slow (deoptimization -> execution in the interpreter). > > Best regards, > Tobias > > [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-October/008141.html From tobias.hartmann at oracle.com Fri Oct 23 13:07:21 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 23 Oct 2020 15:07:21 +0200 Subject: Limitations of the Calling Convention Optimization In-Reply-To: References: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> <245e5987-0d03-b3a6-ba6b-6c02b74e1da5@oracle.com> <9c8c2068-9f7a-99b5-4729-5c4b914c8c46@oracle.com> <40310a9c-eee2-018a-ebc9-98ec1c35a880@oracle.com> Message-ID: <9842d25b-50a3-bb99-a7e6-541da8283285@oracle.com> On 23.10.20 14:42, Brian Goetz wrote: > So, confirming: we can have multiple calling conventions for a given method, but for a given _call > site_, we choose a CC at linkage time and we have to stick with that.? Correct? Not quite. A method always supports the "default" calling convention (all arguments/returns passed as pointers) but if the type of an argument/return is known to be an inline type at *method* link time (i.e. when the method holder is loaded by the VM), we can optimize that default calling convention by adding a scalarized calling convention. Now whenever a call site to such a method is C2 compiled, that scalarized calling convention can be used if available. C1 and the interpreter will only use the default calling convention anyway. > An "easy" case in Maurizio's library is something like this: > > ??? sealed interface X permits Val { } > ??? primitive class Val implements X { } > > ??? X makeVal() { return new Val(); } > > Here, we are always returning a non-null Val.? So ideally, we'd like invocations > > ??? Val v = makeVal() > > to scalarize.? But the method descriptor is `()LX;`, and, at linkage time, we can't guarantee `X` > has been loaded, which means we can't observe that Val is the only subtype of X.? So what you need is: > > ?- X and Val have to have been loaded at linkage time; > ?- we need some confidence that `makeVal()` always returns a non-null value. > > Does this capture what you're saying? Yes, that is correct but we don't need that information at linkage time of the call but at linkage time of the method holder ('InstanceKlass::link_methods' -> 'Method::link_method' in the HotSpot implementation). This is a technical limitation of how things work internally (adapters to jump between interpreted and compiled code need to be created eagerly). Best regards, Tobias From forax at univ-mlv.fr Fri Oct 23 13:40:37 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 23 Oct 2020 15:40:37 +0200 (CEST) Subject: Limitations of the Calling Convention Optimization In-Reply-To: <7d1afd16-0d89-44aa-bc41-78b93b8819a9@oracle.com> References: <396995431.1797864.1603301845623.JavaMail.zimbra@u-pem.fr> <527037565.1221157.1603389779944.JavaMail.zimbra@u-pem.fr> <7d1afd16-0d89-44aa-bc41-78b93b8819a9@oracle.com> Message-ID: <496459059.1818832.1603460437756.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Tobias Hartmann" > ?: "Remi Forax" > Cc: "valhalla-dev" > Envoy?: Vendredi 23 Octobre 2020 08:51:11 > Objet: Re: Limitations of the Calling Convention Optimization > On 22.10.20 20:02, forax at univ-mlv.fr wrote: >>> Sure but my point is that tweaking the inlining heuristic is far from trivial >>> and even inline type >>> specific tweaks will have unforeseeable side effects on code not using inline >>> types. >> >> ??, >> i fail to see how it can affect code that not have been written yet. > > You suggested to prefer Q-typed methods in the inlining heuristic which will in > turn have a negative > effect on inlining of other methods that don't use Q-types (given that we only > have a limited > inlining budget). I.e., just having one little Q-typed method somewhere in the > call stack could in > the worst case negatively affect the performance because suddenly that method is > preferred over > another method. > > But let's not go too much into detail here, my point is that inlining should not > be improved as part > of this project and certainly not by adding tweaks for every new feature that > would benefit from > special treatment by the heuristic. Ok ! > >> c1 doesn't have to buffer because it can do on stack allocation (at least for >> small inline object). >> With that, you may be able to scalarize method calls in c1. > > No, C1 can't do stack allocation because we don't support stack allocation > anywhere in the VM. It > would be a completely new feature. What we do for inline types in C2 is > *scalarization* (pass field > values individually in registers or on the stack) but C1 does not support that > either. Technically, if you look one layer below, the register allocator of c1 is able to do register spilling, which is a kind of stack allocation with more constraints. Hence my proposal to have a special type to represent an inline object has a value that always end up on stack. > > Microsoft recently proposed to add this feature but only for the C2 compiler: > https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-July/042419.html > > There are no plans to ever add stack allocation support to C1. > >> I was suggesting to see inline objects as part of the stack (like double are >> using two slots) for small inline object. >> This can be don by c1 and maybe by the interpreter if you can rewrite the >> bytecode. > > I think you are confusing the Java stack with the native stack. There is no 1:1 > mapping between the > two and the layout of the Java stack does not directly affect the layout of the > native stack as used > by C1/C2 compiled code. I.e., a bytecode transformation to load/store inline > types as "vectors" does > not magically implement stack allocation. yes, that's more of less what i'm trying to say, what is needed to put inline object on stack for c1 is a kind of restricted form of stack allocation. It's like stack allocation where you will never send the address of the inline object on stack. So it's quite different from what Microsoft proposes for c2. > >>> First, it's not necessary to do any kind of bytecode transformations here to >>> help the JIT. >> >> yes, for c2, but it can help for c1 and the interpreter. And if small inline >> objects are stack allocated, they can use a scalarized calling convention. > > Yes, assuming that we have support for stack allocation but even then, similar > to a thread local > buffer, we would still need additional runtime checks (see below). If you never send the address of the stack or the address of a page that grows has the stack, there is no additional runtime check. > >> I believe c1 can use two different types to represent stack allocated inline >> objects and heap allocated inline objects, >> avoiding to heap allocate if not necessary but also avoiding to stack allocate >> something that will escape into a reference too. >> >> If you are using two different types, you should not have to do runtime check >> unlike when the runtime was doing buffering. > > I was referring to the runtime check that is required to check if a reference is > referring to a > stack allocated object. If these are passed/returned over method boundaries, we > need to check before > storing them into any container (because stack allocated objects would require > re-allocation on the > heap). For example, the callee does not know if the caller passes a stack or > heap allocated object. In you can not send the address of a stack allocated object, then there is no runtime check. > >>> Sure but then we still have the issue of not being able to represent 'null' in >>> the flat representation (i.e. we are back to that discussion). >> >> Null check speculation may help here. >> It's what i'm doing to do primitive speculation (for a dynamically typed >> language) but it's a speculative optimization and it requires to have at least >> two calling convention, >> the boxed one when you send a reference and the stack allocated one where you >> copy the primitive object. > > We can speculate but the question is how do we handle null if it still shows > ups? The easiest way > would be to just deoptimize but then performance will suck whenever null is > passed. yep, in the case of Maurizio, the interface acts as an opaque type because as a user, you can not directly access to the implementation of the interface, so it's safe to assume that if a user uses null it will hit a requireNonNull soon. > > For handling null, it's not sufficient to have two calling conventions (which we > already have). You > would need to have two complete versions of the method. For example: > > void int foo(MyInterface bar) { > if (bar == null) return 42; > return bar.getX(); > } > > If we now speculate that MyInterface is only implemented by MyValue and 'bar' is > never null, this > will be optimized by C2 to: > > void int foo(int X) { > return X; > } > > Now for that method we already have two calling conventions: > 1) bar is passed as reference and then "unpacked" because the method body only > works on X > 2) bar is passed as field X (i.e. only an integer is passed) > > But above code does not support a 'null' being passed. To handle null, we would > need to have a > second version of the same method where the method body handles null: > > void int foo(MyValue bar) { > if (bar == null) return 42; > return bar.x; > } I believe the code will be more like void int foo(MyInterface bar) { requireNonNull(bar); return bar.getX(); } so it worth to aggressively speculate that bar is never null and deopt if necessary. [...] > > Best regards, > Tobias R?mi From tobias.hartmann at oracle.com Mon Oct 26 08:15:33 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 26 Oct 2020 09:15:33 +0100 Subject: Limitations of the Calling Convention Optimization In-Reply-To: <496459059.1818832.1603460437756.JavaMail.zimbra@u-pem.fr> References: <396995431.1797864.1603301845623.JavaMail.zimbra@u-pem.fr> <527037565.1221157.1603389779944.JavaMail.zimbra@u-pem.fr> <7d1afd16-0d89-44aa-bc41-78b93b8819a9@oracle.com> <496459059.1818832.1603460437756.JavaMail.zimbra@u-pem.fr> Message-ID: Hi R?mi, On 23.10.20 15:40, forax at univ-mlv.fr wrote: > Technically, if you look one layer below, the register allocator of c1 is able to do register spilling, which is a kind of stack allocation with more constraints. > Hence my proposal to have a special type to represent an inline object has a value that always end up on stack. Sure, C1's register allocator is able to spill values on the stack. But "stack allocation" of an object is much more than that. For example, the object needs to be "split" into its field values and re-allocated on the heap if it escapes from the method. Also, compiled code needs to provide debug information at safepoints such that the interpreter state can be re-constructed and objects can be re-allocated on the heap to continue execution in the interpreter if deoptimization happens. That's exactly what scalarization in C2 does. We keep the field values of an object in registers or on the stack (if we run out of registers). However, my point is that it is not feasible to implement scalarization in C1 due to technical limitations with its current design. > yes, that's more of less what i'm trying to say, what is needed to put inline object on stack for c1 is a kind of restricted form of stack allocation. > It's like stack allocation where you will never send the address of the inline object on stack. > > So it's quite different from what Microsoft proposes for c2. > If you never send the address of the stack or the address of a page that grows has the stack, there is no additional runtime check. But isn't that exactly what we want to do? After all, the problem we are trying to solve here is that we need a way to pass an inline type between C1 and C2 compiled code. And since C1 does not support scalarization, we need to pass a pointer to a buffer. Currently that buffer is a heap allocation and as I understood, you were proposing to use a stack allocation instead. >> We can speculate but the question is how do we handle null if it still shows up? >> The easiest way would be to just deoptimize but then performance will suck whenever null is passed. > > yep, > in the case of Maurizio, the interface acts as an opaque type because as a user, you can not directly access to the implementation of the interface, > so it's safe to assume that if a user uses null it will hit a requireNonNull soon. Right but that's not always the case. An interface might be used in a context where passing null is frequent and therefore expected to be fast while inline types should still be fully optimized (i.e. pollution by null should not have a negative effect on inline type performance). >> But above code does not support a 'null' being passed. To handle null, we would >> need to have a >> second version of the same method where the method body handles null: >> >> void int foo(MyValue bar) { >> if (bar == null) return 42; >> return bar.x; >> } > > > I believe the code will be more like > void int foo(MyInterface bar) { > requireNonNull(bar); > return bar.getX(); > } > > so it worth to aggressively speculate that bar is never null and deopt if necessary. Yes, in this case it would be fine to just deopt on null. Best regards, Tobias From tobias.hartmann at oracle.com Mon Oct 26 09:43:14 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 26 Oct 2020 10:43:14 +0100 Subject: Limitations of the Calling Convention Optimization In-Reply-To: <9842d25b-50a3-bb99-a7e6-541da8283285@oracle.com> References: <1679DE04-8533-4DFE-B50B-25C0EF5D8A28@oracle.com> <245e5987-0d03-b3a6-ba6b-6c02b74e1da5@oracle.com> <9c8c2068-9f7a-99b5-4729-5c4b914c8c46@oracle.com> <40310a9c-eee2-018a-ebc9-98ec1c35a880@oracle.com> <9842d25b-50a3-bb99-a7e6-541da8283285@oracle.com> Message-ID: On 23.10.20 15:07, Tobias Hartmann wrote: > Not quite. A method always supports the "default" calling convention (all arguments/returns passed > as pointers) but if the type of an argument/return is known to be an inline type at *method* link > time (i.e. when the method holder is loaded by the VM), we can optimize that default calling > convention by adding a scalarized calling convention. The significant limitation here is that for a scalarized method, even when calling through the "default" entry point, the method body does not support null. For example, a C2 compiled method int foo(MyInline bar) { return bar.x; } will have the following entry points (simplified): int foo(MyInline bar) { <- Default entry, 'bar' is passed as pointer int x = bar.x; goto Body: } int foo(int x) { <- Scalarized entry, only the integer field of bar is passed Body: return x; } Please let me know if things are still unclear, I'm happy to provide more details about the implementation and its limitations. Best regards, Tobias From sadayapalam at openjdk.java.net Mon Oct 26 11:05:51 2020 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Mon, 26 Oct 2020 11:05:51 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes Message-ID: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> New javac lint mode (-Xlint:synchronize) to warn about client side as well JDK internal attempts to synchronize on instances of value based classes ------------- Commit messages: - 8254274: Lint mode to warn on synchronization attempts on instances of value based classes Changes: https://git.openjdk.java.net/valhalla/pull/237/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=237&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254274 Stats: 352 lines in 20 files changed: 352 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/237.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/237/head:pull/237 PR: https://git.openjdk.java.net/valhalla/pull/237 From sadayapalam at openjdk.java.net Mon Oct 26 11:11:23 2020 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Mon, 26 Oct 2020 11:11:23 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes In-Reply-To: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: On Mon, 26 Oct 2020 11:01:59 GMT, Srikanth Adayapalam wrote: > New javac lint mode (-Xlint:synchronize) to warn about client side as well JDK internal attempts to synchronize on instances of value based classes A few questions for reviewers: (1) Do we want the lint mode to be on my default ? Presently it is off and has to be expressly opted into. (2) Do we want to not use up a bit for VALUE_BASED flag and simply walk the annotations to determine if a type is value based ?? ------------- PR: https://git.openjdk.java.net/valhalla/pull/237 From dsimms at openjdk.java.net Mon Oct 26 14:23:30 2020 From: dsimms at openjdk.java.net (David Simms) Date: Mon, 26 Oct 2020 14:23:30 GMT Subject: [lworld] RFR: 8255396: [lworld] locking breaks oopDesc is_flatArray/is_nullfreeArray type checks Message-ID: Added unlocked test and fallback to klass ------------- Commit messages: - 8255396: [lworld] locking breaks oopDesc is_flatArray/is_nullfreeArray type checks Changes: https://git.openjdk.java.net/valhalla/pull/238/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=238&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255396 Stats: 36 lines in 2 files changed: 33 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/238.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/238/head:pull/238 PR: https://git.openjdk.java.net/valhalla/pull/238 From fparain at openjdk.java.net Mon Oct 26 14:43:15 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Mon, 26 Oct 2020 14:43:15 GMT Subject: [lworld] RFR: 8255396: [lworld] locking breaks oopDesc is_flatArray/is_nullfreeArray type checks In-Reply-To: References: Message-ID: <6hiWXc2oxHVz0Wy4fXD-fgpurY771zlEU2a2fE0nNyg=.53b0c750-5d8e-4b65-9fc3-551c1c15f2a5@github.com> On Mon, 26 Oct 2020 14:18:55 GMT, David Simms wrote: > Added unlocked test and fallback to klass Looks good to me. Sorry I missed that during the review of #234 (Thanks to Sergey for spotting it). Nice to have unit tests for that. Fred ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.java.net/valhalla/pull/238 From thartmann at openjdk.java.net Mon Oct 26 15:21:24 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 26 Oct 2020 15:21:24 GMT Subject: [lworld] RFR: 8255230: [lworld] C2 compilation fails with assert(!inline_alloc) failed: Inline type allocations should not have safepoint uses Message-ID: <6DLVv8ixEIsNudzxrC1IUlBA9ej6fgZ4rHZJhOZwplk=.f7a0bd7b-0082-498f-bdf1-6a754315ef3e@github.com> The problem is that sometimes an inline type can only be scalarized after Loop Optimizations or CCP when we already removed the inline type nodes from the graph and therefore lost track of individual field values. The fix is to simply keep the nodes until macro expansion. Thanks to @mcimadamore for reporting! Best regards, Tobias ------------- Commit messages: - 8255230: [lworld] C2 compilation fails with assert(\!inline_alloc) failed: Inline type allocations should not have safepoint uses Changes: https://git.openjdk.java.net/valhalla/pull/239/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=239&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255230 Stats: 164 lines in 6 files changed: 131 ins; 27 del; 6 mod Patch: https://git.openjdk.java.net/valhalla/pull/239.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/239/head:pull/239 PR: https://git.openjdk.java.net/valhalla/pull/239 From dsimms at openjdk.java.net Mon Oct 26 15:50:35 2020 From: dsimms at openjdk.java.net (David Simms) Date: Mon, 26 Oct 2020 15:50:35 GMT Subject: [lworld] Integrated: 8255396: [lworld] locking breaks oopDesc is_flatArray/is_nullfreeArray type checks In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 14:18:55 GMT, David Simms wrote: > Added unlocked test and fallback to klass This pull request has now been integrated. Changeset: 9b5f54a7 Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/9b5f54a7 Stats: 36 lines in 2 files changed: 33 ins; 1 del; 2 mod 8255396: [lworld] locking breaks oopDesc is_flatArray/is_nullfreeArray type checks Reviewed-by: fparain ------------- PR: https://git.openjdk.java.net/valhalla/pull/238 From forax at univ-mlv.fr Mon Oct 26 15:53:52 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 26 Oct 2020 16:53:52 +0100 (CET) Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes In-Reply-To: References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: <913606892.463898.1603727632710.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Srikanth Adayapalam" > ?: "valhalla-dev" > Envoy?: Lundi 26 Octobre 2020 12:11:23 > Objet: Re: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes > On Mon, 26 Oct 2020 11:01:59 GMT, Srikanth Adayapalam > wrote: > >> New javac lint mode (-Xlint:synchronize) to warn about client side as well JDK >> internal attempts to synchronize on instances of value based classes > > A few questions for reviewers: > > (1) Do we want the lint mode to be on my default ? Presently it is off and has > to be expressly opted into. yes ! It should be enable by default. Not enough people are using -Xlint:all in the wild. [...] R?mi From sergey.kuksenko at oracle.com Mon Oct 26 16:53:28 2020 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Mon, 26 Oct 2020 09:53:28 -0700 Subject: [lworld] RFR: 8255396: [lworld] locking breaks oopDesc is_flatArray/is_nullfreeArray type checks In-Reply-To: References: Message-ID: <8ce118d9-6510-70dd-1fbc-1564f68c2034@oracle.com> I have a question about the following methods from markWord.hpp: bool is_locked()const { return (mask_bits(value(),lock_mask_in_place) !=unlocked_value); } bool is_unlocked()const { return (mask_bits(value(),biased_lock_mask_in_place) ==unlocked_value); } First of all these methods are not symmetrical. "lock_mask_in_place"==0x011 when "biased_lock_mask_in_place"==0x111. The second. If we invoke is_unlocked() on inline/primitive object we get "false". is_locked() on inline also gives "false". I am not sure if may cause an error, maybe all such checks are preguarded with is_inline_type(). The third. Valhalla can't work with BiasedLocking. I think it would be better to remove all usage of BiasedLocking constant in Valhalla to avoid errors. As far as I understand, BiasedLocking has became "obsolete" in jdk16. That means: // When the JDK version reaches 'obsolete_in' limit, the JVM will continue accepting this flag on // the command-line, while issuing a warning and ignoring the flag value. So, now BasedLocking can't be turn on in mainline jdk. To simplify merging, maybe make sense to remove biased locking constants and masks in mainline jdk. On 10/26/20 7:23 AM, David Simms wrote: > Added unlocked test and fallback to klass > > ------------- > > Commit messages: > - 8255396: [lworld] locking breaks oopDesc is_flatArray/is_nullfreeArray type checks > > Changes: https://git.openjdk.java.net/valhalla/pull/238/files > Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=238&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8255396 > Stats: 36 lines in 2 files changed: 33 ins; 1 del; 2 mod > Patch: https://git.openjdk.java.net/valhalla/pull/238.diff > Fetch: git fetch https://git.openjdk.java.net/valhalla pull/238/head:pull/238 > > PR: https://git.openjdk.java.net/valhalla/pull/238 From dlsmith at openjdk.java.net Mon Oct 26 17:14:26 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Mon, 26 Oct 2020 17:14:26 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes In-Reply-To: References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: On Mon, 26 Oct 2020 11:08:06 GMT, Srikanth Adayapalam wrote: > (1) Do we want the lint mode to be on my default ? Presently it is off and has to be expressly opted into. Given that it's already been established that there's an ad hoc set of on-by-default lint warnings, yeah, I think this one makes sense to put in that set. (Inventing a new concept of on-by-default lint warnings is something I'd be more hesitant about.) ------------- PR: https://git.openjdk.java.net/valhalla/pull/237 From dlsmith at openjdk.java.net Mon Oct 26 17:14:28 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Mon, 26 Oct 2020 17:14:28 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes In-Reply-To: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: On Mon, 26 Oct 2020 11:01:59 GMT, Srikanth Adayapalam wrote: > New javac lint mode (-Xlint:synchronize) to warn about client side as well JDK internal attempts to synchronize on instances of value based classes src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 288: > 286: * Warn about synchronization attempts on instances of @ValueBased classes. > 287: */ > 288: SYNCHRONIZE("synchronize"), Suggest calling this `synchronized`, to match the keyword, or `synchronization`, to make it a noun. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 2424: > 2422: chk.checkRefTypes(tree.typeargs, typeargtypes); > 2423: > 2424: if (localEnv.info.lint.isEnabled(LintCategory.SYNCHRONIZE)) { Looks like you're checking calls to wait/notify? I don't think that's necessary?there will already be a warning at the `synchronized` statement; if that doesn't happen, it's malformed code that will fail at runtime (attempting to wait without owning the lock). In practice, I think we just end up with lots of redundant warnings. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 262: > 260: > 261: javac.opt.Xlint.desc.preview=\ > 262: Warn about use of preview language features Old code, I know, but the convention appears to be that these descriptions should end in a period. (Same comment for both `javac.opt.Xlint.desc.varargs` and `javac.opt.Xlint.desc.preview`.) ------------- PR: https://git.openjdk.java.net/valhalla/pull/237 From sergey.kuksenko at oracle.com Tue Oct 27 01:34:12 2020 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Mon, 26 Oct 2020 18:34:12 -0700 Subject: [lworld] RFR: 8255396: [lworld] locking breaks oopDesc is_flatArray/is_nullfreeArray type checks In-Reply-To: <8ce118d9-6510-70dd-1fbc-1564f68c2034@oracle.com> References: <8ce118d9-6510-70dd-1fbc-1564f68c2034@oracle.com> Message-ID: On 10/26/20 9:53 AM, Sergey Kuksenko wrote: > I have a question about the following methods from markWord.hpp: > > bool is_locked()const { > ? return (mask_bits(value(),lock_mask_in_place) !=unlocked_value); > } > bool is_unlocked()const { > ? return (mask_bits(value(),biased_lock_mask_in_place) ==unlocked_value); > } > > First of all these methods are not symmetrical. > "lock_mask_in_place"==0x011 when "biased_lock_mask_in_place"==0x111. Sorry, misprint. I mean 0b011 & 0b111 > > The second. If we invoke is_unlocked() on inline/primitive object we > get "false". is_locked() on inline also gives "false". > I am not sure if may cause an error, maybe all such checks are > preguarded with is_inline_type(). > > The third. Valhalla can't work with BiasedLocking. I think it would be > better to remove all usage of BiasedLocking constant in Valhalla to > avoid errors. As far as I understand, BiasedLocking has became > "obsolete" in jdk16. > That means: > // When the JDK version reaches 'obsolete_in' limit, the JVM will > continue accepting this flag on // the command-line, while issuing a > warning and ignoring the flag value. > > So, now BasedLocking can't be turn on in mainline jdk. To simplify > merging, maybe make sense to remove biased locking constants and masks > in mainline jdk. > > > On 10/26/20 7:23 AM, David Simms wrote: >> Added unlocked test and fallback to klass >> >> ------------- >> >> Commit messages: >> ? - 8255396: [lworld] locking breaks oopDesc >> is_flatArray/is_nullfreeArray type checks >> >> Changes: https://git.openjdk.java.net/valhalla/pull/238/files >> ? Webrev: >> https://webrevs.openjdk.java.net/?repo=valhalla&pr=238&range=00 >> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8255396 >> ?? Stats: 36 lines in 2 files changed: 33 ins; 1 del; 2 mod >> ?? Patch: https://git.openjdk.java.net/valhalla/pull/238.diff >> ?? Fetch: git fetch https://git.openjdk.java.net/valhalla >> pull/238/head:pull/238 >> >> PR: https://git.openjdk.java.net/valhalla/pull/238 From david.holmes at oracle.com Tue Oct 27 02:28:58 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Oct 2020 12:28:58 +1000 Subject: [lworld] RFR: 8255396: [lworld] locking breaks oopDesc is_flatArray/is_nullfreeArray type checks In-Reply-To: References: <8ce118d9-6510-70dd-1fbc-1564f68c2034@oracle.com> Message-ID: <7566b24e-0ab5-5c74-03a7-096a11cab4e0@oracle.com> Hi Sergey, Just a note on BiasedLocking. While we put the process in place to allow for it to be obsoleted in JDK 16 (after disabling by default and deprecating in 15) we have not yet established that there is a consensus (in the community) on its removal. We (runtime) need to establish this one way or the other before the FC date. Cheers, David On 27/10/2020 11:34 am, Sergey Kuksenko wrote: > > On 10/26/20 9:53 AM, Sergey Kuksenko wrote: >> I have a question about the following methods from markWord.hpp: >> >> bool is_locked()const { >> ? return (mask_bits(value(),lock_mask_in_place) !=unlocked_value); >> } >> bool is_unlocked()const { >> ? return (mask_bits(value(),biased_lock_mask_in_place) ==unlocked_value); >> } >> >> First of all these methods are not symmetrical. >> "lock_mask_in_place"==0x011 when "biased_lock_mask_in_place"==0x111. > > Sorry, misprint. I mean 0b011 & 0b111 > > >> >> The second. If we invoke is_unlocked() on inline/primitive object we >> get "false". is_locked() on inline also gives "false". >> I am not sure if may cause an error, maybe all such checks are >> preguarded with is_inline_type(). >> >> The third. Valhalla can't work with BiasedLocking. I think it would be >> better to remove all usage of BiasedLocking constant in Valhalla to >> avoid errors. As far as I understand, BiasedLocking has became >> "obsolete" in jdk16. >> That means: >> // When the JDK version reaches 'obsolete_in' limit, the JVM will >> continue accepting this flag on // the command-line, while issuing a >> warning and ignoring the flag value. >> >> So, now BasedLocking can't be turn on in mainline jdk. To simplify >> merging, maybe make sense to remove biased locking constants and masks >> in mainline jdk. >> >> >> On 10/26/20 7:23 AM, David Simms wrote: >>> Added unlocked test and fallback to klass >>> >>> ------------- >>> >>> Commit messages: >>> ? - 8255396: [lworld] locking breaks oopDesc >>> is_flatArray/is_nullfreeArray type checks >>> >>> Changes: https://git.openjdk.java.net/valhalla/pull/238/files >>> ? Webrev: >>> https://webrevs.openjdk.java.net/?repo=valhalla&pr=238&range=00 >>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8255396 >>> ?? Stats: 36 lines in 2 files changed: 33 ins; 1 del; 2 mod >>> ?? Patch: https://git.openjdk.java.net/valhalla/pull/238.diff >>> ?? Fetch: git fetch https://git.openjdk.java.net/valhalla >>> pull/238/head:pull/238 >>> >>> PR: https://git.openjdk.java.net/valhalla/pull/238 From thartmann at openjdk.java.net Tue Oct 27 07:20:43 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 27 Oct 2020 07:20:43 GMT Subject: git: openjdk/valhalla: lworld: 8255230: [lworld] C2 compilation fails with assert(!inline_alloc) failed: Inline type allocations should not have safepoint uses Message-ID: <804eaab6-d458-46d1-a7ed-689d950ccd67@openjdk.org> Changeset: 1e44a3b8 Author: Tobias Hartmann Date: 2020-10-27 07:19:49 +0000 URL: https://git.openjdk.java.net/valhalla/commit/1e44a3b8 8255230: [lworld] C2 compilation fails with assert(!inline_alloc) failed: Inline type allocations should not have safepoint uses ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/inlinetypenode.cpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/split_if.cpp ! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java From thartmann at openjdk.java.net Tue Oct 27 07:23:29 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 27 Oct 2020 07:23:29 GMT Subject: [lworld] Integrated: 8255230: [lworld] C2 compilation fails with assert(!inline_alloc) failed: Inline type allocations should not have safepoint uses In-Reply-To: <6DLVv8ixEIsNudzxrC1IUlBA9ej6fgZ4rHZJhOZwplk=.f7a0bd7b-0082-498f-bdf1-6a754315ef3e@github.com> References: <6DLVv8ixEIsNudzxrC1IUlBA9ej6fgZ4rHZJhOZwplk=.f7a0bd7b-0082-498f-bdf1-6a754315ef3e@github.com> Message-ID: On Mon, 26 Oct 2020 15:16:20 GMT, Tobias Hartmann wrote: > The problem is that sometimes an inline type can only be scalarized after Loop Optimizations or CCP when we already removed the inline type nodes from the graph and therefore lost track of individual field values. The fix is to simply keep the nodes until macro expansion. > > Thanks to @mcimadamore for reporting! > > Best regards, > Tobias This pull request has now been integrated. Changeset: 1e44a3b8 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/1e44a3b8 Stats: 164 lines in 6 files changed: 131 ins; 27 del; 6 mod 8255230: [lworld] C2 compilation fails with assert(!inline_alloc) failed: Inline type allocations should not have safepoint uses ------------- PR: https://git.openjdk.java.net/valhalla/pull/239 From thartmann at openjdk.java.net Tue Oct 27 12:46:26 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 27 Oct 2020 12:46:26 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merging master into the lworld branch. ------------- Commit messages: - Disabled assert until JDK-8255120 is fixed in mainline - Removed test run statements with UseBiasedLocking - Merge lworld - 8255040: Replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors with clang - 8199054: Test javax/swing/UIDefaults/8149879/InternalResourceBundle.java is unstable - 8167355: [macos 10.12] Timeout in javax/swing/JTextArea/TextViewOOM/TextViewOOM.java - 8254370: Update the classes in the java.awt.color package - 8255206: [macos] LicenseTest fails on macOS 11 - 8238263: Create at-requires mechanism for containers - 8251994: VM crashed running TestComplexAddrExpr.java test with -XX:UseAVX=X - ... and 178 more: https://git.openjdk.java.net/valhalla/compare/1e44a3b8...3271612c The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=241&range=00.0 - jdk: https://webrevs.openjdk.java.net/?repo=valhalla&pr=241&range=00.1 Changes: https://git.openjdk.java.net/valhalla/pull/241/files Stats: 66444 lines in 917 files changed: 49679 ins; 12679 del; 4086 mod Patch: https://git.openjdk.java.net/valhalla/pull/241.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/241/head:pull/241 PR: https://git.openjdk.java.net/valhalla/pull/241 From thartmann at openjdk.java.net Tue Oct 27 12:59:35 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 27 Oct 2020 12:59:35 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 10:59:42 GMT, Tobias Hartmann wrote: > Merging master into the lworld branch. This pull request has now been integrated. Changeset: fd02c477 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/fd02c477 Stats: 66444 lines in 917 files changed: 49679 ins; 12679 del; 4086 mod Merge jdk ------------- PR: https://git.openjdk.java.net/valhalla/pull/241 From dsimms at openjdk.java.net Tue Oct 27 18:30:41 2020 From: dsimms at openjdk.java.net (David Simms) Date: Tue, 27 Oct 2020 18:30:41 GMT Subject: [lworld] RFR: 8255130: [lworld] Adjust github actions Message-ID: Cleaned up minimal target, disabled zero port, disabled PCH for Windows: ------------- Commit messages: - Undo initial bump - PCH yield C2908 error - Fix minimal as build target - x86_64 only - Bump for action testing Changes: https://git.openjdk.java.net/valhalla/pull/242/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=242&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255130 Stats: 14 lines in 4 files changed: 8 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/242.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/242/head:pull/242 PR: https://git.openjdk.java.net/valhalla/pull/242 From sadayapalam at openjdk.java.net Wed Oct 28 06:24:25 2020 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 28 Oct 2020 06:24:25 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes In-Reply-To: References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: On Mon, 26 Oct 2020 16:55:22 GMT, Dan Smith wrote: >> New javac lint mode (-Xlint:synchronize) to warn about client side as well JDK internal attempts to synchronize on instances of value based classes > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 288: > >> 286: * Warn about synchronization attempts on instances of @ValueBased classes. >> 287: */ >> 288: SYNCHRONIZE("synchronize"), > > Suggest calling this `synchronized`, to match the keyword, or `synchronization`, to make it a noun. Thanks, I prefer the latter and will opt for it (synchronization) > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 2424: > >> 2422: chk.checkRefTypes(tree.typeargs, typeargtypes); >> 2423: >> 2424: if (localEnv.info.lint.isEnabled(LintCategory.SYNCHRONIZE)) { > > Looks like you're checking calls to wait/notify? I don't think that's necessary?there will already be a warning at the `synchronized` statement; if that doesn't happen, it's malformed code that will fail at runtime (attempting to wait without owning the lock). In practice, I think we just end up with lots of redundant warnings. Sounds good. I agree this is redundant and noisy. > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 262: > >> 260: >> 261: javac.opt.Xlint.desc.preview=\ >> 262: Warn about use of preview language features > > Old code, I know, but the convention appears to be that these descriptions should end in a period. (Same comment for both `javac.opt.Xlint.desc.varargs` and `javac.opt.Xlint.desc.preview`.) OK, will do. ------------- PR: https://git.openjdk.java.net/valhalla/pull/237 From dsimms at openjdk.java.net Wed Oct 28 06:33:32 2020 From: dsimms at openjdk.java.net (David Simms) Date: Wed, 28 Oct 2020 06:33:32 GMT Subject: [lworld] Integrated: 8255130: [lworld] Adjust github actions In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 18:24:36 GMT, David Simms wrote: > Cleaned up minimal target, disabled zero port, disabled PCH for Windows: This pull request has now been integrated. Changeset: a15b665f Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/a15b665f Stats: 14 lines in 4 files changed: 8 ins; 6 del; 0 mod 8255130: [lworld] Adjust github actions ------------- PR: https://git.openjdk.java.net/valhalla/pull/242 From dsimms at openjdk.java.net Wed Oct 28 08:19:45 2020 From: dsimms at openjdk.java.net (David Simms) Date: Wed, 28 Oct 2020 08:19:45 GMT Subject: RFR: Merge lworld Message-ID: Merge lworld at tag jdk-16+21 ------------- Commit messages: - Merge branch 'lworld' into type-restrictions_merge_jdk_16_21 - 8255130: [lworld] Adjust github actions - Merge jdk - 8255040: Replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors with clang - 8199054: Test javax/swing/UIDefaults/8149879/InternalResourceBundle.java is unstable - 8167355: [macos 10.12] Timeout in javax/swing/JTextArea/TextViewOOM/TextViewOOM.java - 8254370: Update the classes in the java.awt.color package - 8255206: [macos] LicenseTest fails on macOS 11 - 8238263: Create at-requires mechanism for containers - 8251994: VM crashed running TestComplexAddrExpr.java test with -XX:UseAVX=X - ... and 186 more: https://git.openjdk.java.net/valhalla/compare/5194e6c1...19feeda2 The webrevs contain the adjustments done while merging with regards to each parent branch: - type-restrictions: https://webrevs.openjdk.java.net/?repo=valhalla&pr=243&range=00.0 - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=243&range=00.1 Changes: https://git.openjdk.java.net/valhalla/pull/243/files Stats: 69016 lines in 973 files changed: 51651 ins; 13165 del; 4200 mod Patch: https://git.openjdk.java.net/valhalla/pull/243.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/243/head:pull/243 PR: https://git.openjdk.java.net/valhalla/pull/243 From dsimms at openjdk.java.net Wed Oct 28 08:54:38 2020 From: dsimms at openjdk.java.net (David Simms) Date: Wed, 28 Oct 2020 08:54:38 GMT Subject: RFR: Merge lworld [v2] In-Reply-To: References: Message-ID: > Merge lworld at tag jdk-16+21 David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'lworld' into type-restrictions_merge_jdk_16_21 - Merge lworld Merge jdk-16+20 - 8254254: [lworld][type-restrictions] Serviceability tests failing missing FIELDINFO_TAG_MASK Reviewed-by: lfoltan - Merge lworld Merge tag 'jdk-16+19' - 8254022: [lworld] [type-restrictions] Initial support for RestrictedField Reviewed-by: dsimms - 8253760: [type-restrictions] Static inline fields are not "erased" to the ref type - 8253312: Enable JVM experiments in specialization under an opt-in mode ------------- Changes: https://git.openjdk.java.net/valhalla/pull/243/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=243&range=01 Stats: 813 lines in 37 files changed: 638 ins; 103 del; 72 mod Patch: https://git.openjdk.java.net/valhalla/pull/243.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/243/head:pull/243 PR: https://git.openjdk.java.net/valhalla/pull/243 From dsimms at openjdk.java.net Wed Oct 28 08:54:42 2020 From: dsimms at openjdk.java.net (David Simms) Date: Wed, 28 Oct 2020 08:54:42 GMT Subject: Integrated: Merge lworld In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 08:14:56 GMT, David Simms wrote: > Merge lworld at tag jdk-16+21 This pull request has now been integrated. Changeset: 4c989999 Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/4c989999 Stats: 69016 lines in 973 files changed: 51651 ins; 13165 del; 4200 mod Merge lworld Merge lworld at tag jdk-16+21 ------------- PR: https://git.openjdk.java.net/valhalla/pull/243 From sadayapalam at openjdk.java.net Wed Oct 28 08:57:05 2020 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 28 Oct 2020 08:57:05 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes [v2] In-Reply-To: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: > New javac lint mode (-Xlint:synchronize) to warn about client side as well JDK internal attempts to synchronize on instances of value based classes Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision: 8254274: Incorporate review comments ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/237/files - new: https://git.openjdk.java.net/valhalla/pull/237/files/8c962dc7..1a660823 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=237&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=237&range=00-01 Stats: 339 lines in 18 files changed: 70 ins; 251 del; 18 mod Patch: https://git.openjdk.java.net/valhalla/pull/237.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/237/head:pull/237 PR: https://git.openjdk.java.net/valhalla/pull/237 From sadayapalam at openjdk.java.net Wed Oct 28 09:00:28 2020 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Wed, 28 Oct 2020 09:00:28 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes In-Reply-To: References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: <8u-Enai4POFv_FTqubQljVJE_M6geugkcpJOC_hf9JQ=.f5d51cfb-484f-47d2-8b05-eef48d6a2fec@github.com> On Mon, 26 Oct 2020 17:11:55 GMT, Dan Smith wrote: >> A few questions for reviewers: >> >> (1) Do we want the lint mode to be on my default ? Presently it is off and has to be expressly opted into. >> (2) Do we want to not use up a bit for VALUE_BASED flag and simply walk the annotations to determine if a type is value based ?? > >> (1) Do we want the lint mode to be on my default ? Presently it is off and has to be expressly opted into. > > Given that it's already been established that there's an ad hoc set of on-by-default lint warnings, yeah, I think this one makes sense to put in that set. (Inventing a new concept of on-by-default lint warnings is something I'd be more hesitant about.) I have pushed additional changes to incorporate review comments: - The lint mode's token is "synchronization" (instead of "synchronize") - This lint mode is on by default - Redundant warnings on wait/notify calls are removed. - We don't burn up a flag bit to mark value based classes. We simply walk the declaration annotations on a class to discover the ones that are @ValueBased - Ensure descriptions (in the neighbourhood) in javac.properties end with a period for consistency's sake. - Streamline and simplify tests. ------------- PR: https://git.openjdk.java.net/valhalla/pull/237 From david.simms at oracle.com Wed Oct 28 10:25:12 2020 From: david.simms at oracle.com (David Simms) Date: Wed, 28 Oct 2020 11:25:12 +0100 Subject: JDK-8255522: was Re: [lworld] RFR: 8255396: [lworld] locking breaks oopDesc is_flatArray/is_nullfreeArray type checks In-Reply-To: <8ce118d9-6510-70dd-1fbc-1564f68c2034@oracle.com> References: <8ce118d9-6510-70dd-1fbc-1564f68c2034@oracle.com> Message-ID: <99e36971-44fd-856d-b3b9-5508a16a090e@oracle.com> Filed a new issue for further testing and cleanup JDK-8255522, ... On 2020-10-26 17:53, Sergey Kuksenko wrote: > I have a question about the following methods from markWord.hpp: > > bool is_locked()const { > ? return (mask_bits(value(),lock_mask_in_place) !=unlocked_value); > } > bool is_unlocked()const { > ? return (mask_bits(value(),biased_lock_mask_in_place) ==unlocked_value); > } > You are correct, remains from the original code, due to a lack of testing quite frankly. Filed 8255522? to: * add more gtest mark word tests * assert any use of "biased locking" (there are some existing "has_biased_pattern()" asserts not guarded "UseBiasedLocking") * remove biased_lock_mask_in_place from is_unlocked > First of all these methods are not symmetrical. > "lock_mask_in_place"==0x011 when "biased_lock_mask_in_place"==0x111. > > The second. If we invoke is_unlocked() on inline/primitive object we > get "false". is_locked() on inline also gives "false". > I am not sure if may cause an error, maybe all such checks are > preguarded with is_inline_type(). Not much code uses the runtime check, and those that do would have fallen back to klass->layout_helper() That said, I will spend some time looking into further testing and asserts that could have found that. > > The third. Valhalla can't work with BiasedLocking. I think it would be > better to remove all usage of BiasedLocking constant in Valhalla to > avoid errors. As far as I understand, BiasedLocking has became > "obsolete" in jdk16. > That means: > // When the JDK version reaches 'obsolete_in' limit, the JVM will > continue accepting this flag on // the command-line, while issuing a > warning and ignoring the flag value. > > So, now BasedLocking can't be turn on in mainline jdk. To simplify > merging, maybe make sense to remove biased locking constants and masks > in mainline jdk. So "markWord.hpp" changes very little, and when it does, we want to know about it. Therefore I was more than happy to make potentially conflicting code changes. The rest of the code base, I was not so interested in having unnecessary merge conflicts with a future removal...so the rest of the code is left in situ. But yes UseBiasedLocking will exit VM init in Valhalla. The addition of ShouldNotReadHere() in markWord.hpp biased locking code should do the trick for now ? Cheers /Simms From thartmann at openjdk.java.net Wed Oct 28 14:01:02 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 28 Oct 2020 14:01:02 GMT Subject: [lworld] RFR: 8255541: [lworld] Improve array layout checks in C2 compiled code Message-ID: C2 should use a single bit test of the layout helper value to check for flat/null-free inline type arrays. This is a prerequisite of JDK-8255046 which will then add support for checking the corresponding bits in the mark word instead. Best regards, Tobias ------------- Commit messages: - 8255541: [lworld] Improve array layout checks in C2 compiled code Changes: https://git.openjdk.java.net/valhalla/pull/244/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=244&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255541 Stats: 168 lines in 8 files changed: 32 ins; 73 del; 63 mod Patch: https://git.openjdk.java.net/valhalla/pull/244.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/244/head:pull/244 PR: https://git.openjdk.java.net/valhalla/pull/244 From thartmann at openjdk.java.net Wed Oct 28 14:42:08 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 28 Oct 2020 14:42:08 GMT Subject: [lworld] RFR: 8255541: [lworld] Improve array layout checks in C2 compiled code [v2] In-Reply-To: References: Message-ID: > C2 should use a single bit test of the layout helper value to check for flat/null-free inline type arrays. This is a prerequisite of JDK-8255046 which will then add support for checking the corresponding bits in the mark word instead. > > Best regards, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: Added missing EnableValhalla check ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/244/files - new: https://git.openjdk.java.net/valhalla/pull/244/files/e4243fc5..8f38bb8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=244&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=244&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/244.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/244/head:pull/244 PR: https://git.openjdk.java.net/valhalla/pull/244 From dsimms at openjdk.java.net Wed Oct 28 15:00:00 2020 From: dsimms at openjdk.java.net (David Simms) Date: Wed, 28 Oct 2020 15:00:00 GMT Subject: [lworld] RFR: 8255522: [lworld] References to biased pattern remain in markWord::is_unlocked() Message-ID: * more gtest mark word tests * assert any use of "biased locking" (there are some existing "has_biased_pattern()" asserts not guarded "UseBiasedLocking") * remove biased_lock_mask_in_place from is_unlocked ------------- Commit messages: - More unguarded biased locking - 8255522: [lworld] References to biased pattern remain in markWord::is_unlocked() Changes: https://git.openjdk.java.net/valhalla/pull/245/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=245&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255522 Stats: 147 lines in 10 files changed: 134 ins; 1 del; 12 mod Patch: https://git.openjdk.java.net/valhalla/pull/245.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/245/head:pull/245 PR: https://git.openjdk.java.net/valhalla/pull/245 From dlsmith at openjdk.java.net Wed Oct 28 15:37:55 2020 From: dlsmith at openjdk.java.net (Dan Smith) Date: Wed, 28 Oct 2020 15:37:55 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes [v2] In-Reply-To: References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: On Wed, 28 Oct 2020 08:57:05 GMT, Srikanth Adayapalam wrote: >> New javac lint mode (-Xlint:synchronize) to warn about client side as well JDK internal attempts to synchronize on instances of value based classes > > Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision: > > 8254274: Incorporate review comments Marked as reviewed by dlsmith (Committer). ------------- PR: https://git.openjdk.java.net/valhalla/pull/237 From thartmann at openjdk.java.net Wed Oct 28 15:44:06 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 28 Oct 2020 15:44:06 GMT Subject: [lworld] RFR: 8255541: [lworld] Improve array layout checks in C2 compiled code [v3] In-Reply-To: References: Message-ID: > C2 should use a single bit test of the layout helper value to check for flat/null-free inline type arrays. This is a prerequisite of JDK-8255046 which will then add support for checking the corresponding bits in the mark word instead. > > Best regards, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: Moved EnableValhalla check added to the wrong place ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/244/files - new: https://git.openjdk.java.net/valhalla/pull/244/files/8f38bb8f..d407a75b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=244&range=02 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=244&range=01-02 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/valhalla/pull/244.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/244/head:pull/244 PR: https://git.openjdk.java.net/valhalla/pull/244 From dsimms at openjdk.java.net Wed Oct 28 17:33:59 2020 From: dsimms at openjdk.java.net (David Simms) Date: Wed, 28 Oct 2020 17:33:59 GMT Subject: [lworld] Integrated: Remove 32-bit builds from GH actions Message-ID: <2tQcFWn1e12YVyh5f1FzYAUEtLTt2wFYueFJm8eFGYs=.3dba46c2-ac35-4a58-a3d4-c54210d5fa78@github.com> Valhalla currently do ports ------------- Commit messages: - Comments are not enough - Disable 32-bit GH actions for Valhalla Changes: https://git.openjdk.java.net/valhalla/pull/246/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=246&range=00 Stats: 99 lines in 1 file changed: 0 ins; 99 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/246.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/246/head:pull/246 PR: https://git.openjdk.java.net/valhalla/pull/246 From dsimms at openjdk.java.net Wed Oct 28 17:33:59 2020 From: dsimms at openjdk.java.net (David Simms) Date: Wed, 28 Oct 2020 17:33:59 GMT Subject: [lworld] Integrated: Remove 32-bit builds from GH actions In-Reply-To: <2tQcFWn1e12YVyh5f1FzYAUEtLTt2wFYueFJm8eFGYs=.3dba46c2-ac35-4a58-a3d4-c54210d5fa78@github.com> References: <2tQcFWn1e12YVyh5f1FzYAUEtLTt2wFYueFJm8eFGYs=.3dba46c2-ac35-4a58-a3d4-c54210d5fa78@github.com> Message-ID: On Wed, 28 Oct 2020 17:25:42 GMT, David Simms wrote: > Valhalla currently do ports This pull request has now been integrated. Changeset: 4c7d99c6 Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/4c7d99c6 Stats: 99 lines in 1 file changed: 0 ins; 99 del; 0 mod Remove 32-bit builds from GH actions ------------- PR: https://git.openjdk.java.net/valhalla/pull/246 From shade at openjdk.java.net Wed Oct 28 18:44:53 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 28 Oct 2020 18:44:53 GMT Subject: [lworld] Integrated: Remove 32-bit builds from GH actions In-Reply-To: <2tQcFWn1e12YVyh5f1FzYAUEtLTt2wFYueFJm8eFGYs=.3dba46c2-ac35-4a58-a3d4-c54210d5fa78@github.com> References: <2tQcFWn1e12YVyh5f1FzYAUEtLTt2wFYueFJm8eFGYs=.3dba46c2-ac35-4a58-a3d4-c54210d5fa78@github.com> Message-ID: <7XSLsbGVZ0V_jq5X94grFw94uljgW3AG2iBvpeFWQjY=.9c62d44c-3138-4b3c-aac4-0d7535a74f2a@github.com> On Wed, 28 Oct 2020 17:25:42 GMT, David Simms wrote: > Valhalla currently do ports There is a filter for executed platforms, see https://github.com/openjdk/jdk/pull/284. It would be cleaner than hacking out the parts of `submit.yml`, which would set up for merge conflicts as `submit.yml` continues to change upstream. ------------- PR: https://git.openjdk.java.net/valhalla/pull/246 From rriggs at openjdk.java.net Wed Oct 28 18:56:00 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 28 Oct 2020 18:56:00 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes [v2] In-Reply-To: References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: On Wed, 28 Oct 2020 08:57:05 GMT, Srikanth Adayapalam wrote: >> New javac lint mode (-Xlint:synchronize) to warn about client side as well JDK internal attempts to synchronize on instances of value based classes > > Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision: > > 8254274: Incorporate review comments src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 265: > 263: > 264: javac.opt.Xlint.desc.synchronization=\ > 265: Warn about synchronization attempts on instances of @ValueBased classes. The annotation java.internal.ValueBased is purely internal and should not show up in error messages. The reference to value based should be to the ValueBased.html or just be a lower case value-based. ------------- PR: https://git.openjdk.java.net/valhalla/pull/237 From skuksenko at openjdk.java.net Thu Oct 29 00:46:55 2020 From: skuksenko at openjdk.java.net (Sergey Kuksenko) Date: Thu, 29 Oct 2020 00:46:55 GMT Subject: [lworld] RFR: 8255541: [lworld] Improve array layout checks in C2 compiled code In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 13:56:51 GMT, Tobias Hartmann wrote: > C2 should use a single bit test of the layout helper value to check for flat/null-free inline type arrays. This is a prerequisite of JDK-8255046 which will then add support for checking the corresponding bits in the mark word instead. > > Best regards, > Tobias Sorry, I didn't have time to make a full perf review of this patch yet. But anyway, here are preliminary performance results, for "aaload" operation: if take time (than smaller than better) of aaload as 100 - baseline (-XX:-EnableValhalla) then: -XX:+EnableValhalla -XX:+UseCompressedOops: before the PR - 126, after the PR - 110 -XX:+EnableValhalla -XX:-UseCompressedOops: before the PR - 108, after the PR - 107 I'd rather say that this PR are very nice for performance point of view. More detailed analysis is in progress. ------------- PR: https://git.openjdk.java.net/valhalla/pull/244 From sadayapalam at openjdk.java.net Thu Oct 29 06:04:20 2020 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Thu, 29 Oct 2020 06:04:20 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes [v3] In-Reply-To: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: > New javac lint mode (-Xlint:synchronize) to warn about client side as well JDK internal attempts to synchronize on instances of value based classes Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision: 8254274: Messages should refer to value-based classes and not to the internal annotation ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/237/files - new: https://git.openjdk.java.net/valhalla/pull/237/files/1a660823..6a6c67ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=237&range=02 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=237&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/237.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/237/head:pull/237 PR: https://git.openjdk.java.net/valhalla/pull/237 From sadayapalam at openjdk.java.net Thu Oct 29 06:04:21 2020 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Thu, 29 Oct 2020 06:04:21 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes [v2] In-Reply-To: References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: On Wed, 28 Oct 2020 18:53:02 GMT, Roger Riggs wrote: >> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision: >> >> 8254274: Incorporate review comments > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 265: > >> 263: >> 264: javac.opt.Xlint.desc.synchronization=\ >> 265: Warn about synchronization attempts on instances of @ValueBased classes. > > The annotation java.internal.ValueBased is purely internal and should not show up in error messages. > The reference to value based should be to the ValueBased.html or just be a lower case value-based. Good point. Fixed two places to say value-based consistently since this is the language mentioned by ValueBased.html. ------------- PR: https://git.openjdk.java.net/valhalla/pull/237 From thartmann at openjdk.java.net Thu Oct 29 06:21:50 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 29 Oct 2020 06:21:50 GMT Subject: [lworld] RFR: 8255541: [lworld] Improve array layout checks in C2 compiled code In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 00:44:28 GMT, Sergey Kuksenko wrote: >> C2 should use a single bit test of the layout helper value to check for flat/null-free inline type arrays. This is a prerequisite of JDK-8255046 which will then add support for checking the corresponding bits in the mark word instead. >> >> Best regards, >> Tobias > > Sorry, I didn't have time to make a full perf review of this patch yet. > But anyway, here are preliminary performance results, for "aaload" operation: > if take time (than smaller than better) of aaload as 100 - baseline (-XX:-EnableValhalla) then: > -XX:+EnableValhalla -XX:+UseCompressedOops: before the PR - 126, after the PR - 110 > -XX:+EnableValhalla -XX:-UseCompressedOops: before the PR - 108, after the PR - 107 > I'd rather say that this PR are very nice for performance point of view. > More detailed analysis is in progress. Thanks Sergey! ------------- PR: https://git.openjdk.java.net/valhalla/pull/244 From thartmann at openjdk.java.net Thu Oct 29 06:21:51 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 29 Oct 2020 06:21:51 GMT Subject: [lworld] Integrated: 8255541: [lworld] Improve array layout checks in C2 compiled code In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 13:56:51 GMT, Tobias Hartmann wrote: > C2 should use a single bit test of the layout helper value to check for flat/null-free inline type arrays. This is a prerequisite of JDK-8255046 which will then add support for checking the corresponding bits in the mark word instead. > > Best regards, > Tobias This pull request has now been integrated. Changeset: 756943d5 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/756943d5 Stats: 176 lines in 8 files changed: 37 ins; 76 del; 63 mod 8255541: [lworld] Improve array layout checks in C2 compiled code ------------- PR: https://git.openjdk.java.net/valhalla/pull/244 From dsimms at openjdk.java.net Thu Oct 29 08:46:16 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 29 Oct 2020 08:46:16 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge tag 'jdk-16+22' # Conflicts: # .github/workflows/submit.yml # src/hotspot/share/memory/dynamicArchive.cpp # src/hotspot/share/oops/method.cpp # src/hotspot/share/opto/parse2.cpp # src/hotspot/share/opto/runtime.cpp # src/hotspot/share/runtime/sharedRuntime.cpp # src/hotspot/share/runtime/sharedRuntime.hpp # src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java # src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ------------- Commit messages: - Merge tag 'jdk-16+22' into lworld_merge_jdk_16_22 - 8255555: Bad copyright headers in SocketChannelCompare.java SocketChannelConnectionSetup.java UnixSocketChannelReadWrite.java - 8253939: [TESTBUG] Increase coverage of the cgroups detection code - 8255554: Bad copyright header in AbstractFileSystemProvider.java - 8255457: Shenandoah: cleanup ShenandoahMarkTask - 8255441: Cleanup ciEnv/jvmciEnv::lookup_method-s - 8255014: Record Classes javax.lang.model changes, follow-up - 8245194: Unix domain socket channel implementation - 8255013: implement Record Classes as a standard feature in Java, follow-up - 8255429: Remove C2-based profiling - ... and 28 more: https://git.openjdk.java.net/valhalla/compare/756943d5...76559c92 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=247&range=00.0 - jdk: https://webrevs.openjdk.java.net/?repo=valhalla&pr=247&range=00.1 Changes: https://git.openjdk.java.net/valhalla/pull/247/files Stats: 9900 lines in 311 files changed: 6601 ins; 2246 del; 1053 mod Patch: https://git.openjdk.java.net/valhalla/pull/247.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/247/head:pull/247 PR: https://git.openjdk.java.net/valhalla/pull/247 From dsimms at openjdk.java.net Thu Oct 29 10:01:54 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 29 Oct 2020 10:01:54 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: <77qkNi-TW0FaNGoak6F6Ss312qHbgjm1S2kdzc7tik8=.e0d1e956-4029-4de2-a851-56e43e1523cd@github.com> On Thu, 29 Oct 2020 08:40:18 GMT, David Simms wrote: > Merge tag 'jdk-16+22' > > # Conflicts: > # .github/workflows/submit.yml > # src/hotspot/share/memory/dynamicArchive.cpp > # src/hotspot/share/oops/method.cpp > # src/hotspot/share/opto/parse2.cpp > # src/hotspot/share/opto/runtime.cpp > # src/hotspot/share/runtime/sharedRuntime.cpp > # src/hotspot/share/runtime/sharedRuntime.hpp > # src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java This pull request has now been integrated. Changeset: 7e616ce3 Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/7e616ce3 Stats: 9900 lines in 311 files changed: 6601 ins; 2246 del; 1053 mod Merge jdk Merge tag 'jdk-16+22' ------------- PR: https://git.openjdk.java.net/valhalla/pull/247 From jlaskey at openjdk.java.net Thu Oct 29 10:27:55 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 29 Oct 2020 10:27:55 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes [v3] In-Reply-To: References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: <6sG5NlswZGwNjyimHUPqw7qulKziuMr_MYsFIb6ALkA=.d4e8e477-bfc5-4fc3-bcf7-e74145916ebe@github.com> On Thu, 29 Oct 2020 06:04:20 GMT, Srikanth Adayapalam wrote: >> New javac lint mode (-Xlint:synchronize) to warn about client side as well JDK internal attempts to synchronize on instances of value based classes > > Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision: > > 8254274: Messages should refer to value-based classes and not to the internal annotation Wondering if keyword SYNCHRONIZATION is too broad, suggest VALUE_ SYNCHRONIZATION. Would it make sense to have a test for a class.ref type value? ------------- Marked as reviewed by jlaskey (Reviewer). PR: https://git.openjdk.java.net/valhalla/pull/237 From sadayapalam at openjdk.java.net Thu Oct 29 13:23:51 2020 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Thu, 29 Oct 2020 13:23:51 GMT Subject: RFR: 8254274: Development to add 'lint' warning for @ValueBased classes [v3] In-Reply-To: <6sG5NlswZGwNjyimHUPqw7qulKziuMr_MYsFIb6ALkA=.d4e8e477-bfc5-4fc3-bcf7-e74145916ebe@github.com> References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> <6sG5NlswZGwNjyimHUPqw7qulKziuMr_MYsFIb6ALkA=.d4e8e477-bfc5-4fc3-bcf7-e74145916ebe@github.com> Message-ID: On Thu, 29 Oct 2020 10:24:58 GMT, Jim Laskey wrote: > Wondering if keyword SYNCHRONIZATION is too broad, suggest VALUE_ SYNCHRONIZATION. Would it make sense to have a test for a class.ref type value? class.ref is a valhalla'ism - but the present work is targetting JDK16 as a precursor/preparation for Valhalla. (even though the integration first happens to jep390 branch of Valhalla repo as a temporary home). So the .ref syntax is really not available to test/need not be tested. As for the keyword, I am comfortable with it, but I will make it a point to solicit input at the next stage of review. (The accumulated cross component changes will get to a RFR when targetting jdk16) ------------- PR: https://git.openjdk.java.net/valhalla/pull/237 From sadayapalam at openjdk.java.net Thu Oct 29 13:30:54 2020 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Thu, 29 Oct 2020 13:30:54 GMT Subject: Integrated: 8254274: Development to add 'lint' warning for @ValueBased classes In-Reply-To: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> References: <4RCsO6AV4wMiexBFxfJwdLLrRr9HxmkeophfAqJtHnY=.bea59d72-b0d0-4dab-a5b8-9f66b666d134@github.com> Message-ID: On Mon, 26 Oct 2020 11:01:59 GMT, Srikanth Adayapalam wrote: > New javac lint mode (-Xlint:synchronize) to warn about client side as well JDK internal attempts to synchronize on instances of value based classes This pull request has now been integrated. Changeset: 2ac97b2f Author: Srikanth Adayapalam URL: https://git.openjdk.java.net/valhalla/commit/2ac97b2f Stats: 173 lines in 12 files changed: 171 ins; 0 del; 2 mod 8254274: Development to add 'lint' warning for @ValueBased classes Reviewed-by: dlsmith, jlaskey ------------- PR: https://git.openjdk.java.net/valhalla/pull/237 From thartmann at openjdk.java.net Thu Oct 29 13:32:03 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 29 Oct 2020 13:32:03 GMT Subject: [lworld] RFR: 8255600: [lworld] C2 compilation fails with assert: modified node was not processed by IGVN.transform_old() Message-ID: MergeMemStream might modify the MergeMem inputs. Simply put it on the worklist for now and investigate a proper fix with JDK-8247216. ------------- Commit messages: - 8255600: [lworld] C2 compilation fails with assert: modified node was not processed by IGVN.transform_old() Changes: https://git.openjdk.java.net/valhalla/pull/248/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=248&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255600 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/248.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/248/head:pull/248 PR: https://git.openjdk.java.net/valhalla/pull/248 From thartmann at openjdk.java.net Thu Oct 29 14:23:10 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 29 Oct 2020 14:23:10 GMT Subject: git: openjdk/valhalla: lworld: 8255600: [lworld] C2 compilation fails with assert: modified node was not processed by IGVN.transform_old() Message-ID: <9ebac8c4-3bd5-453e-9ab6-0c0da5bbfedd@openjdk.org> Changeset: 2b18bce3 Author: Tobias Hartmann Date: 2020-10-29 14:22:39 +0000 URL: https://git.openjdk.java.net/valhalla/commit/2b18bce3 8255600: [lworld] C2 compilation fails with assert: modified node was not processed by IGVN.transform_old() ! src/hotspot/share/opto/cfgnode.cpp From thartmann at openjdk.java.net Thu Oct 29 14:25:51 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 29 Oct 2020 14:25:51 GMT Subject: [lworld] Integrated: 8255600: [lworld] C2 compilation fails with assert: modified node was not processed by IGVN.transform_old() In-Reply-To: References: Message-ID: <7TQeAQhnyBVmzLx1uHCix-zw60toWiT-tUzpaHA-JS8=.e10d6dca-7fa5-4903-b0d9-630bde9ae221@github.com> On Thu, 29 Oct 2020 13:27:53 GMT, Tobias Hartmann wrote: > MergeMemStream might modify the MergeMem inputs. Simply put it on the worklist for now and investigate a proper fix with JDK-8247216. This pull request has now been integrated. Changeset: 2b18bce3 Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/2b18bce3 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8255600: [lworld] C2 compilation fails with assert: modified node was not processed by IGVN.transform_old() ------------- PR: https://git.openjdk.java.net/valhalla/pull/248 From dsimms at openjdk.java.net Thu Oct 29 15:13:02 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 29 Oct 2020 15:13:02 GMT Subject: RFR: Merge lworld Message-ID: Merge tag jdk-16+22 ------------- Commit messages: - Merge branch 'lworld' into type-restrictions_merge_jdk_16_22 - Merge jdk - 8255555: Bad copyright headers in SocketChannelCompare.java SocketChannelConnectionSetup.java UnixSocketChannelReadWrite.java - 8253939: [TESTBUG] Increase coverage of the cgroups detection code - 8255554: Bad copyright header in AbstractFileSystemProvider.java - 8255457: Shenandoah: cleanup ShenandoahMarkTask - 8255441: Cleanup ciEnv/jvmciEnv::lookup_method-s - 8255014: Record Classes javax.lang.model changes, follow-up - 8245194: Unix domain socket channel implementation - 8255013: implement Record Classes as a standard feature in Java, follow-up - ... and 31 more: https://git.openjdk.java.net/valhalla/compare/4c989999...b740b38d The webrevs contain the adjustments done while merging with regards to each parent branch: - type-restrictions: https://webrevs.openjdk.java.net/?repo=valhalla&pr=249&range=00.0 - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=249&range=00.1 Changes: https://git.openjdk.java.net/valhalla/pull/249/files Stats: 10175 lines in 319 files changed: 6638 ins; 2421 del; 1116 mod Patch: https://git.openjdk.java.net/valhalla/pull/249.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/249/head:pull/249 PR: https://git.openjdk.java.net/valhalla/pull/249 From dsimms at openjdk.java.net Thu Oct 29 15:59:02 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 29 Oct 2020 15:59:02 GMT Subject: RFR: Merge lworld [v2] In-Reply-To: References: Message-ID: > Merge tag jdk-16+22 David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'lworld' into type-restrictions_merge_jdk_16_22 - Merge lworld Merge lworld at tag jdk-16+21 - Merge lworld Merge jdk-16+20 - 8254254: [lworld][type-restrictions] Serviceability tests failing missing FIELDINFO_TAG_MASK Reviewed-by: lfoltan - Merge lworld Merge tag 'jdk-16+19' - 8254022: [lworld] [type-restrictions] Initial support for RestrictedField Reviewed-by: dsimms - 8253760: [type-restrictions] Static inline fields are not "erased" to the ref type - 8253312: Enable JVM experiments in specialization under an opt-in mode ------------- Changes: https://git.openjdk.java.net/valhalla/pull/249/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=249&range=01 Stats: 813 lines in 37 files changed: 638 ins; 103 del; 72 mod Patch: https://git.openjdk.java.net/valhalla/pull/249.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/249/head:pull/249 PR: https://git.openjdk.java.net/valhalla/pull/249 From dsimms at openjdk.java.net Thu Oct 29 15:59:03 2020 From: dsimms at openjdk.java.net (David Simms) Date: Thu, 29 Oct 2020 15:59:03 GMT Subject: Integrated: Merge lworld In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 15:07:41 GMT, David Simms wrote: > Merge tag jdk-16+22 This pull request has now been integrated. Changeset: 696076f2 Author: David Simms URL: https://git.openjdk.java.net/valhalla/commit/696076f2 Stats: 10175 lines in 319 files changed: 6638 ins; 2421 del; 1116 mod Merge lworld Merge tag jdk-16+22 ------------- PR: https://git.openjdk.java.net/valhalla/pull/249