From dsimms at openjdk.org Wed Dec 4 16:58:06 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 4 Dec 2024 16:58:06 GMT Subject: [lworld] RFR: 8343554: [lworld] VM crashes when running runtime/valhalla/inlinetypes/InlineOops.java with ZGC in interpreted mode Message-ID: Don't use HeapAccess for frame roots ------------- Commit messages: - 8343554: [lworld] VM crashes when running runtime/valhalla/inlinetypes/InlineOops.java with ZGC in interpreted mode Changes: https://git.openjdk.org/valhalla/pull/1313/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1313&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343554 Stats: 57 lines in 1 file changed: 38 ins; 12 del; 7 mod Patch: https://git.openjdk.org/valhalla/pull/1313.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1313/head:pull/1313 PR: https://git.openjdk.org/valhalla/pull/1313 From aboldtch at openjdk.org Thu Dec 5 06:41:56 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 5 Dec 2024 06:41:56 GMT Subject: [lworld] RFR: 8343554: [lworld] VM crashes when running runtime/valhalla/inlinetypes/InlineOops.java with ZGC in interpreted mode In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 16:52:33 GMT, David Simms wrote: > Don't use HeapAccess for frame roots src/hotspot/share/prims/whitebox.cpp line 1988: > 1986: > 1987: void do_oop(oop* o) { add_oop(*o); } > 1988: void do_oop(narrowOop* v) { add_oop(CompressedOops::decode(*v)); } I think we rarely do this directly but let RawAccess handle the load and decode. Suggestion: void do_oop(oop* o) { add_oop(RawAccess<>::oop_load(o)); } void do_oop(narrowOop* v) { add_oop(RawAccess<>::oop_load(v)); } and the most common way to write oop closures which are used in both oop and narrowOop contexts: ```c++ template void do_oop_work(T* p) { oop o = RawAccess<>::oop_load(p); // Do the work } void do_oop(oop* o) { do_oop_work(o); } void do_oop(narrowOop* v) { do_oop_work(v); } ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1313#discussion_r1870726909 From dsimms at openjdk.org Thu Dec 5 11:22:36 2024 From: dsimms at openjdk.org (David Simms) Date: Thu, 5 Dec 2024 11:22:36 GMT Subject: [lworld] RFR: 8343554: [lworld] VM crashes when running runtime/valhalla/inlinetypes/InlineOops.java with ZGC in interpreted mode [v2] In-Reply-To: References: Message-ID: > Don't use HeapAccess for frame roots David Simms has updated the pull request incrementally with one additional commit since the last revision: Clean up add_oop calls ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1313/files - new: https://git.openjdk.org/valhalla/pull/1313/files/8c0ad769..8c193000 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1313&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1313&range=00-01 Stats: 13 lines in 1 file changed: 1 ins; 7 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1313.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1313/head:pull/1313 PR: https://git.openjdk.org/valhalla/pull/1313 From dsimms at openjdk.org Thu Dec 5 11:22:37 2024 From: dsimms at openjdk.org (David Simms) Date: Thu, 5 Dec 2024 11:22:37 GMT Subject: [lworld] RFR: 8343554: [lworld] VM crashes when running runtime/valhalla/inlinetypes/InlineOops.java with ZGC in interpreted mode [v2] In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 06:39:10 GMT, Axel Boldt-Christmas wrote: >> David Simms has updated the pull request incrementally with one additional commit since the last revision: >> >> Clean up add_oop calls > > src/hotspot/share/prims/whitebox.cpp line 1988: > >> 1986: >> 1987: void do_oop(oop* o) { add_oop(*o); } >> 1988: void do_oop(narrowOop* v) { add_oop(CompressedOops::decode(*v)); } > > I think we rarely do this directly but let RawAccess handle the load and decode. > Suggestion: > > void do_oop(oop* o) { add_oop(RawAccess<>::oop_load(o)); } > void do_oop(narrowOop* v) { add_oop(RawAccess<>::oop_load(v)); } > > > and the most common way to write oop closures which are used in both oop and narrowOop contexts: > ```c++ > template > void do_oop_work(T* p) { > oop o = RawAccess<>::oop_load(p); > // Do the work > } > void do_oop(oop* o) { do_oop_work(o); } > void do_oop(narrowOop* v) { do_oop_work(v); } You are correct, I want to thank @fisk for leading me astray on this one :-) Fixed it up. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1313#discussion_r1871189212 From dsimms at openjdk.org Thu Dec 5 13:57:57 2024 From: dsimms at openjdk.org (David Simms) Date: Thu, 5 Dec 2024 13:57:57 GMT Subject: [lworld] Integrated: 8343554: [lworld] VM crashes when running runtime/valhalla/inlinetypes/InlineOops.java with ZGC in interpreted mode In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 16:52:33 GMT, David Simms wrote: > Don't use HeapAccess for frame roots This pull request has now been integrated. Changeset: 265189e2 Author: David Simms URL: https://git.openjdk.org/valhalla/commit/265189e2b311daaa8cac3d387c3a70051b1e419a Stats: 51 lines in 1 file changed: 30 ins; 10 del; 11 mod 8343554: [lworld] VM crashes when running runtime/valhalla/inlinetypes/InlineOops.java with ZGC in interpreted mode ------------- PR: https://git.openjdk.org/valhalla/pull/1313 From duke at openjdk.org Fri Dec 6 08:48:59 2024 From: duke at openjdk.org (duke) Date: Fri, 6 Dec 2024 08:48:59 GMT Subject: [lworld] Withdrawn: 8199429: [lworld] value type (re)constructors expressions value type should not be discardable In-Reply-To: References: Message-ID: On Thu, 10 Oct 2024 16:21:31 GMT, Jesper Steen M?ller wrote: > ?be discardable as per https://bugs.openjdk.org/browse/JDK-8199429 . > > This is a first stab at it, only with the manual marking on a method, and without the loading of the annotation in ClassReader. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/valhalla/pull/1274 From chagedorn at openjdk.org Fri Dec 6 17:25:12 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 6 Dec 2024 17:25:12 GMT Subject: [lworld] RFR: 8345250: [lworld] C2: Array loads and stores on inexact flat arrays cause crashes Message-ID: This PR fixes crashes that occur when trying to load/store from/to a flat array from which we statically know it is flat but we do not know the exact layout because the klass is inexact. ### The Layout of a Flat Array is only Statically Known If the Klass is Exact Currently, the code for getting the array element address in `GraphKit::array_element_address()` assumes that whenever we have an array from which we know that it is flat, then we also know the exact array layout (i.e. assume the value klass is exact): https://github.com/openjdk/valhalla/blob/5e876d607aba68e921cb8fa6a1a012acd1735825/src/hotspot/share/opto/graphKit.cpp#L1835-L1838 This does not need to be true as shown in the following test case where we have a flat array with an inexact klass/type: https://github.com/openjdk/valhalla/blob/95fc9c71bffcf5b92a4cdbfb34ad9e3149266f79/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java#L4568-L4578 ### Emit Runtime Call to Load/Store from/to the Correct Array Element Address What we actually would need for a flat array with an inexact klass is to emit a runtime call to load/store from/to the correct array element address. We cannot do better statically because we do not know the exact layout. ### Challenges However, the problem is that in `GraphKit::array_element_address()` we somehow need to bail out back to `Parse::array_load/store()` such that we can emit the runtime call there. We could use a sentinel node because we do not actually need the element address node. But this could mess with some GVN transformations in between. What we do instead is to just fall to the `else` case in `GraphKit::array_element_address()` for non-flat arrays and still construct the element address node, even though it's not needed (will be folded away later): https://github.com/openjdk/valhalla/blob/0858ce110da58ed7f1b634ae381e7c4eb0f37c3a/src/hotspot/share/opto/graphKit.cpp#L1840-L1849 ### Additionally Required Fixes 1. `TypeAryKlassPtr::cast_to_exactness()` asserts that all null-free or flat arrays are exact which is not the case as shown above. Fix: Adjust assert. 2. `ciArrayKlass::make()` assumes that all null-free arrays are concrete value classes which does not need to be the case as shown above. Fix: Add check whether the klass is an inline type (which is only true for concrete inline type klasses). 3. `Parse::array_store_check()` needs to pass `null_free` to the `gen_checkcast()` in case we have a null-free flat array that is inexact (i.e. either `Object` or an abstract value class) and thus `is_inlinetypeptr()` is false. If we don't do that, we will hit this assert with `-XX:-UncommonNullCast` that ensures that flat arrays are null-free: https://github.com/openjdk/valhalla/blob/265189e2b311daaa8cac3d387c3a70051b1e419a/src/hotspot/share/opto/parse2.cpp#L235-L237 The right/complete way to fix this would be to change `TypeAry::is_null_free()` to also handle non-exact inline types. However, this is invasive since we use this check in many places. Changing this method could have a bigger impact due to possibly having more places where we assume that only exact inline types are null-free. I filed [JDK-8345681](https://bugs.openjdk.org/browse/JDK-8345681) to revisit this. For this PR, I just implemented a point fix in `array_store_check()` for now. ### Applied some Additional Renamings and Simple Refactorings While trying to better understand the `array_load/store()`, I've applied some renamings and simple refactorings. I'm planning to do some more refactorings to reduce the size of `array_load/store()`. But I will do that separately with [JDK-8345696](https://bugs.openjdk.org/browse/JDK-8345696). Thanks, Christian ------------- Commit messages: - Fix null free - 8345250: [lworld] C2: Array loads and stores on inexact flat arrays cause crashes Changes: https://git.openjdk.org/valhalla/pull/1314/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1314&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345250 Stats: 448 lines in 7 files changed: 292 ins; 62 del; 94 mod Patch: https://git.openjdk.org/valhalla/pull/1314.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1314/head:pull/1314 PR: https://git.openjdk.org/valhalla/pull/1314 From chagedorn at openjdk.org Fri Dec 6 17:25:13 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 6 Dec 2024 17:25:13 GMT Subject: [lworld] RFR: 8345250: [lworld] C2: Array loads and stores on inexact flat arrays cause crashes In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 17:10:20 GMT, Christian Hagedorn wrote: > This PR fixes crashes that occur when trying to load/store from/to a flat array from which we statically know it is flat but we do not know the exact layout because the klass is inexact. > > ### The Layout of a Flat Array is only Statically Known If the Klass is Exact > Currently, the code for getting the array element address in `GraphKit::array_element_address()` assumes that whenever we have an array from which we know that it is flat, then we also know the exact array layout (i.e. assume the value klass is exact): > https://github.com/openjdk/valhalla/blob/5e876d607aba68e921cb8fa6a1a012acd1735825/src/hotspot/share/opto/graphKit.cpp#L1835-L1838 > > This does not need to be true as shown in the following test case where we have a flat array with an inexact klass/type: > https://github.com/openjdk/valhalla/blob/95fc9c71bffcf5b92a4cdbfb34ad9e3149266f79/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java#L4568-L4578 > > ### Emit Runtime Call to Load/Store from/to the Correct Array Element Address > What we actually would need for a flat array with an inexact klass is to emit a runtime call to load/store from/to the correct array element address. We cannot do better statically because we do not know the exact layout. > > ### Challenges > However, the problem is that in `GraphKit::array_element_address()` we somehow need to bail out back to `Parse::array_load/store()` such that we can emit the runtime call there. We could use a sentinel node because we do not actually need the element address node. But this could mess with some GVN transformations in between. What we do instead is to just fall to the `else` case in `GraphKit::array_element_address()` for non-flat arrays and still construct the element address node, even though it's not needed (will be folded away later): > https://github.com/openjdk/valhalla/blob/0858ce110da58ed7f1b634ae381e7c4eb0f37c3a/src/hotspot/share/opto/graphKit.cpp#L1840-L1849 > > ### Additionally Required Fixes > 1. `TypeAryKlassPtr::cast_to_exactness()` asserts that all null-free or flat arrays are exact which is not the case as shown above. Fix: Adjust assert. > 2. `ciArrayKlass::make()` assumes that all null-free arrays are concrete value classes which does not need to be the case as shown above. Fix: Add check whether the klass is an inline type (which is only true for concrete inline type klasses). > 3. `Parse::array_store_check()` needs to pass `null_free` to the `gen_checkcast()` in case we have a null-free flat array that is inexact (i.e. either ... src/hotspot/share/ci/ciArrayKlass.cpp line 113: > 111: assert(!null_free || !klass->is_loaded() || klass->is_inlinetype() || klass->is_abstract() || > 112: klass->is_java_lang_Object(), "only value classes are null free"); > 113: if (null_free && klass->is_loaded() && klass->is_inlinetype()) { Added `klass->is_inlinetype()` to be able to get the `InlineKlass`. src/hotspot/share/opto/graphKit.cpp line 3507: > 3505: const TypeOopPtr* toop = improved_klass_ptr_type->cast_to_exactness(false)->as_instance_type(); > 3506: bool safe_for_replace = (failure_control == nullptr); > 3507: assert(!null_free || toop->can_be_inline_type(), "must be an inline type pointer"); When we pass now `null_free == true` for inexact inline types, `is_inlinetypeptr()` is false (only true for concrete value classes). `can_be_inline_type()` is the next better thing we could check. src/hotspot/share/opto/parse2.cpp line 93: > 91: // Load from non-flat inline type array (elements can never be null) > 92: bt = T_OBJECT; > 93: } else if (!ary_t->is_not_flat()) { Swapped cases and inserted null free case further down after this case. src/hotspot/share/opto/parse2.cpp line 94: > 92: // Emit a runtime call to load the element from the flat array. > 93: inline_type = load_from_unknown_flat_array(array, array_index, element_ptr); > 94: inline_type = record_profile_for_speculation_at_array_load(inline_type); Cover missing case, other changes in `array_load()` are just renaming/refactoring src/hotspot/share/opto/parse2.cpp line 147: > 145: // Element type is unknown, and thus we cannot statically determine the exact flat array layout. Emit a > 146: // runtime call to correctly load the inline type element from the flat array. > 147: Node* inline_type = load_from_unknown_flat_array(array, array_index, element_ptr); Extracted to new method such that we can reuse this above. src/hotspot/share/opto/parse2.cpp line 267: > 265: // Emit a runtime call to store the element to the flat array. > 266: store_to_unknown_flat_array(array, array_index, stored_value_casted); > 267: } New case, other code is just refactoring in `array_store()`. src/hotspot/share/opto/parse2.cpp line 270: > 268: return; > 269: } > 270: if (array_type->is_null_free()) { `else if` can be turned into simple `if` because the other case returns. src/hotspot/share/opto/parse2.cpp line 310: > 308: inline_Klass = elemtype->inline_klass(); > 309: } > 310: if (!stopped()) { Simplified cases since both cases checked `!stopped()` before. src/hotspot/share/opto/parse2.cpp line 331: > 329: } else { > 330: // Element type is unknown, emit a runtime call since the flat array layout is not statically known. > 331: store_to_unknown_flat_array(array, array_index, null_checked_stored_value_casted); Can now call extracted method which is shared with new code inserted above. src/hotspot/share/opto/parseHelper.cpp line 272: > 270: a_e_klass = makecon(TypeKlassPtr::make(elemtype->inline_klass())); > 271: } else { > 272: // TODO: Should move to TypeAry::is_null_free() with JDK-8345681 See PR description under additional fixes point 3. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1873722653 PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1873723659 PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1873726538 PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1873724796 PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1873725380 PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1873727458 PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1873728036 PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1873728648 PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1873729253 PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1873729905 From thartmann at openjdk.org Tue Dec 10 12:56:59 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 10 Dec 2024 12:56:59 GMT Subject: [lworld] RFR: 8345250: [lworld] C2: Array loads and stores on inexact flat arrays cause crashes In-Reply-To: References: Message-ID: <_ww5JkR_dFfjLH22Yn_rBSFsjQwgHdeotW-jSqFI-zA=.5ab71c1c-13c0-4bc9-8c6c-696e4bdce6e2@github.com> On Fri, 6 Dec 2024 17:10:20 GMT, Christian Hagedorn wrote: > This PR fixes crashes that occur when trying to load/store from/to a flat array from which we statically know it is flat but we do not know the exact layout because the klass is inexact. > > ### The Layout of a Flat Array is only Statically Known If the Klass is Exact > Currently, the code for getting the array element address in `GraphKit::array_element_address()` assumes that whenever we have an array from which we know that it is flat, then we also know the exact array layout (i.e. assume the value klass is exact): > https://github.com/openjdk/valhalla/blob/5e876d607aba68e921cb8fa6a1a012acd1735825/src/hotspot/share/opto/graphKit.cpp#L1835-L1838 > > This does not need to be true as shown in the following test case where we have a flat array with an inexact klass/type: > https://github.com/openjdk/valhalla/blob/95fc9c71bffcf5b92a4cdbfb34ad9e3149266f79/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java#L4568-L4578 > > ### Emit Runtime Call to Load/Store from/to the Correct Array Element Address > What we actually would need for a flat array with an inexact klass is to emit a runtime call to load/store from/to the correct array element address. We cannot do better statically because we do not know the exact layout. > > ### Challenges > However, the problem is that in `GraphKit::array_element_address()` we somehow need to bail out back to `Parse::array_load/store()` such that we can emit the runtime call there. We could use a sentinel node because we do not actually need the element address node. But this could mess with some GVN transformations in between. What we do instead is to just fall to the `else` case in `GraphKit::array_element_address()` for non-flat arrays and still construct the element address node, even though it's not needed (will be folded away later): > https://github.com/openjdk/valhalla/blob/0858ce110da58ed7f1b634ae381e7c4eb0f37c3a/src/hotspot/share/opto/graphKit.cpp#L1840-L1849 > > ### Additionally Required Fixes > 1. `TypeAryKlassPtr::cast_to_exactness()` asserts that all null-free or flat arrays are exact which is not the case as shown above. Fix: Adjust assert. > 2. `ciArrayKlass::make()` assumes that all null-free arrays are concrete value classes which does not need to be the case as shown above. Fix: Add check whether the klass is an inline type (which is only true for concrete inline type klasses). > 3. `Parse::array_store_check()` needs to pass `null_free` to the `gen_checkcast()` in case we have a null-free flat array that is inexact (i.e. either ... Great work Christian! The fix looks good and it's nice to have better test coverage now. src/hotspot/share/opto/parse2.cpp line 203: > 201: insert_mem_bar_volatile(Op_MemBarCPUOrder, C->get_alias_index(TypeAryPtr::INLINES)); > 202: > 203: // Keep track of the information that the inline type is in flat arrays Suggestion: // Keep track of the information that the inline type is flat in arrays src/hotspot/share/opto/parseHelper.cpp line 265: > 263: // If we statically know that this is an inline type array, use precise element klass for checkcast > 264: const TypeAryPtr* arytype = _gvn.type(ary)->is_aryptr(); > 265: const TypePtr* elem_ptr = elemtype->make_ptr(); Should this be moved to the else branch? src/hotspot/share/opto/parseHelper.cpp line 274: > 272: // TODO: Should move to TypeAry::is_null_free() with JDK-8345681 > 273: TypePtr::PTR ptr = elem_ptr->ptr(); > 274: null_free = ptr == TypePtr::NotNull || ptr == TypePtr::AnyNull; Suggestion: null_free = ((ptr == TypePtr::NotNull) || (ptr == TypePtr::AnyNull)); ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1314#pullrequestreview-2492199793 PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1878032097 PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1878019806 PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1878021493 From chagedorn at openjdk.org Wed Dec 11 13:19:17 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 11 Dec 2024 13:19:17 GMT Subject: [lworld] RFR: 8345250: [lworld] C2: Array loads and stores on inexact flat arrays cause crashes [v2] In-Reply-To: References: Message-ID: > This PR fixes crashes that occur when trying to load/store from/to a flat array from which we statically know it is flat but we do not know the exact layout because the klass is inexact. > > ### The Layout of a Flat Array is only Statically Known If the Klass is Exact > Currently, the code for getting the array element address in `GraphKit::array_element_address()` assumes that whenever we have an array from which we know that it is flat, then we also know the exact array layout (i.e. assume the value klass is exact): > https://github.com/openjdk/valhalla/blob/5e876d607aba68e921cb8fa6a1a012acd1735825/src/hotspot/share/opto/graphKit.cpp#L1835-L1838 > > This does not need to be true as shown in the following test case where we have a flat array with an inexact klass/type: > https://github.com/openjdk/valhalla/blob/95fc9c71bffcf5b92a4cdbfb34ad9e3149266f79/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java#L4568-L4578 > > ### Emit Runtime Call to Load/Store from/to the Correct Array Element Address > What we actually would need for a flat array with an inexact klass is to emit a runtime call to load/store from/to the correct array element address. We cannot do better statically because we do not know the exact layout. > > ### Challenges > However, the problem is that in `GraphKit::array_element_address()` we somehow need to bail out back to `Parse::array_load/store()` such that we can emit the runtime call there. We could use a sentinel node because we do not actually need the element address node. But this could mess with some GVN transformations in between. What we do instead is to just fall to the `else` case in `GraphKit::array_element_address()` for non-flat arrays and still construct the element address node, even though it's not needed (will be folded away later): > https://github.com/openjdk/valhalla/blob/0858ce110da58ed7f1b634ae381e7c4eb0f37c3a/src/hotspot/share/opto/graphKit.cpp#L1840-L1849 > > ### Additionally Required Fixes > 1. `TypeAryKlassPtr::cast_to_exactness()` asserts that all null-free or flat arrays are exact which is not the case as shown above. Fix: Adjust assert. > 2. `ciArrayKlass::make()` assumes that all null-free arrays are concrete value classes which does not need to be the case as shown above. Fix: Add check whether the klass is an inline type (which is only true for concrete inline type klasses). > 3. `Parse::array_store_check()` needs to pass `null_free` to the `gen_checkcast()` in case we have a null-free flat array that is inexact (i.e. either ... Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1314/files - new: https://git.openjdk.org/valhalla/pull/1314/files/95fc9c71..e1266f80 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1314&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1314&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1314.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1314/head:pull/1314 PR: https://git.openjdk.org/valhalla/pull/1314 From chagedorn at openjdk.org Wed Dec 11 13:19:17 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 11 Dec 2024 13:19:17 GMT Subject: [lworld] RFR: 8345250: [lworld] C2: Array loads and stores on inexact flat arrays cause crashes [v2] In-Reply-To: References: Message-ID: On Wed, 11 Dec 2024 13:16:49 GMT, Christian Hagedorn wrote: >> This PR fixes crashes that occur when trying to load/store from/to a flat array from which we statically know it is flat but we do not know the exact layout because the klass is inexact. >> >> ### The Layout of a Flat Array is only Statically Known If the Klass is Exact >> Currently, the code for getting the array element address in `GraphKit::array_element_address()` assumes that whenever we have an array from which we know that it is flat, then we also know the exact array layout (i.e. assume the value klass is exact): >> https://github.com/openjdk/valhalla/blob/5e876d607aba68e921cb8fa6a1a012acd1735825/src/hotspot/share/opto/graphKit.cpp#L1835-L1838 >> >> This does not need to be true as shown in the following test case where we have a flat array with an inexact klass/type: >> https://github.com/openjdk/valhalla/blob/95fc9c71bffcf5b92a4cdbfb34ad9e3149266f79/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java#L4568-L4578 >> >> ### Emit Runtime Call to Load/Store from/to the Correct Array Element Address >> What we actually would need for a flat array with an inexact klass is to emit a runtime call to load/store from/to the correct array element address. We cannot do better statically because we do not know the exact layout. >> >> ### Challenges >> However, the problem is that in `GraphKit::array_element_address()` we somehow need to bail out back to `Parse::array_load/store()` such that we can emit the runtime call there. We could use a sentinel node because we do not actually need the element address node. But this could mess with some GVN transformations in between. What we do instead is to just fall to the `else` case in `GraphKit::array_element_address()` for non-flat arrays and still construct the element address node, even though it's not needed (will be folded away later): >> https://github.com/openjdk/valhalla/blob/0858ce110da58ed7f1b634ae381e7c4eb0f37c3a/src/hotspot/share/opto/graphKit.cpp#L1840-L1849 >> >> ### Additionally Required Fixes >> 1. `TypeAryKlassPtr::cast_to_exactness()` asserts that all null-free or flat arrays are exact which is not the case as shown above. Fix: Adjust assert. >> 2. `ciArrayKlass::make()` assumes that all null-free arrays are concrete value classes which does not need to be the case as shown above. Fix: Add check whether the klass is an inline type (which is only true for concrete inline type klasses). >> 3. `Parse::array_store_check()` needs to pass `null_free` to the `gen_checkcast()` in case we have a null-free ... > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > review comments Thanks a lot for your review! ------------- PR Review: https://git.openjdk.org/valhalla/pull/1314#pullrequestreview-2495629480 From chagedorn at openjdk.org Wed Dec 11 13:19:17 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 11 Dec 2024 13:19:17 GMT Subject: [lworld] RFR: 8345250: [lworld] C2: Array loads and stores on inexact flat arrays cause crashes [v2] In-Reply-To: <_ww5JkR_dFfjLH22Yn_rBSFsjQwgHdeotW-jSqFI-zA=.5ab71c1c-13c0-4bc9-8c6c-696e4bdce6e2@github.com> References: <_ww5JkR_dFfjLH22Yn_rBSFsjQwgHdeotW-jSqFI-zA=.5ab71c1c-13c0-4bc9-8c6c-696e4bdce6e2@github.com> Message-ID: On Tue, 10 Dec 2024 12:35:37 GMT, Tobias Hartmann wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > src/hotspot/share/opto/parseHelper.cpp line 265: > >> 263: // If we statically know that this is an inline type array, use precise element klass for checkcast >> 264: const TypeAryPtr* arytype = _gvn.type(ary)->is_aryptr(); >> 265: const TypePtr* elem_ptr = elemtype->make_ptr(); > > Should this be moved to the else branch? Good point, I think I've missed to update the usages below. Pushed an update accordingly. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1314#discussion_r1880173115 From thartmann at openjdk.org Wed Dec 11 13:24:57 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 11 Dec 2024 13:24:57 GMT Subject: [lworld] RFR: 8345250: [lworld] C2: Array loads and stores on inexact flat arrays cause crashes [v2] In-Reply-To: References: Message-ID: On Wed, 11 Dec 2024 13:19:17 GMT, Christian Hagedorn wrote: >> This PR fixes crashes that occur when trying to load/store from/to a flat array from which we statically know it is flat but we do not know the exact layout because the klass is inexact. >> >> ### The Layout of a Flat Array is only Statically Known If the Klass is Exact >> Currently, the code for getting the array element address in `GraphKit::array_element_address()` assumes that whenever we have an array from which we know that it is flat, then we also know the exact array layout (i.e. assume the value klass is exact): >> https://github.com/openjdk/valhalla/blob/5e876d607aba68e921cb8fa6a1a012acd1735825/src/hotspot/share/opto/graphKit.cpp#L1835-L1838 >> >> This does not need to be true as shown in the following test case where we have a flat array with an inexact klass/type: >> https://github.com/openjdk/valhalla/blob/95fc9c71bffcf5b92a4cdbfb34ad9e3149266f79/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java#L4568-L4578 >> >> ### Emit Runtime Call to Load/Store from/to the Correct Array Element Address >> What we actually would need for a flat array with an inexact klass is to emit a runtime call to load/store from/to the correct array element address. We cannot do better statically because we do not know the exact layout. >> >> ### Challenges >> However, the problem is that in `GraphKit::array_element_address()` we somehow need to bail out back to `Parse::array_load/store()` such that we can emit the runtime call there. We could use a sentinel node because we do not actually need the element address node. But this could mess with some GVN transformations in between. What we do instead is to just fall to the `else` case in `GraphKit::array_element_address()` for non-flat arrays and still construct the element address node, even though it's not needed (will be folded away later): >> https://github.com/openjdk/valhalla/blob/0858ce110da58ed7f1b634ae381e7c4eb0f37c3a/src/hotspot/share/opto/graphKit.cpp#L1840-L1849 >> >> ### Additionally Required Fixes >> 1. `TypeAryKlassPtr::cast_to_exactness()` asserts that all null-free or flat arrays are exact which is not the case as shown above. Fix: Adjust assert. >> 2. `ciArrayKlass::make()` assumes that all null-free arrays are concrete value classes which does not need to be the case as shown above. Fix: Add check whether the klass is an inline type (which is only true for concrete inline type klasses). >> 3. `Parse::array_store_check()` needs to pass `null_free` to the `gen_checkcast()` in case we have a null-free ... > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > review comments Looks good. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1314#pullrequestreview-2495657004 From chagedorn at openjdk.org Wed Dec 11 13:31:55 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 11 Dec 2024 13:31:55 GMT Subject: [lworld] RFR: 8345250: [lworld] C2: Array loads and stores on inexact flat arrays cause crashes [v2] In-Reply-To: References: Message-ID: <-HFEFXfIezcWSeT8RJV2XDOe3JFAy4LiRaALSrJ04Ec=.b9dcc8ea-f4ee-424e-8c2c-c99b71201365@github.com> On Wed, 11 Dec 2024 13:19:17 GMT, Christian Hagedorn wrote: >> This PR fixes crashes that occur when trying to load/store from/to a flat array from which we statically know it is flat but we do not know the exact layout because the klass is inexact. >> >> ### The Layout of a Flat Array is only Statically Known If the Klass is Exact >> Currently, the code for getting the array element address in `GraphKit::array_element_address()` assumes that whenever we have an array from which we know that it is flat, then we also know the exact array layout (i.e. assume the value klass is exact): >> https://github.com/openjdk/valhalla/blob/5e876d607aba68e921cb8fa6a1a012acd1735825/src/hotspot/share/opto/graphKit.cpp#L1835-L1838 >> >> This does not need to be true as shown in the following test case where we have a flat array with an inexact klass/type: >> https://github.com/openjdk/valhalla/blob/95fc9c71bffcf5b92a4cdbfb34ad9e3149266f79/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java#L4568-L4578 >> >> ### Emit Runtime Call to Load/Store from/to the Correct Array Element Address >> What we actually would need for a flat array with an inexact klass is to emit a runtime call to load/store from/to the correct array element address. We cannot do better statically because we do not know the exact layout. >> >> ### Challenges >> However, the problem is that in `GraphKit::array_element_address()` we somehow need to bail out back to `Parse::array_load/store()` such that we can emit the runtime call there. We could use a sentinel node because we do not actually need the element address node. But this could mess with some GVN transformations in between. What we do instead is to just fall to the `else` case in `GraphKit::array_element_address()` for non-flat arrays and still construct the element address node, even though it's not needed (will be folded away later): >> https://github.com/openjdk/valhalla/blob/0858ce110da58ed7f1b634ae381e7c4eb0f37c3a/src/hotspot/share/opto/graphKit.cpp#L1840-L1849 >> >> ### Additionally Required Fixes >> 1. `TypeAryKlassPtr::cast_to_exactness()` asserts that all null-free or flat arrays are exact which is not the case as shown above. Fix: Adjust assert. >> 2. `ciArrayKlass::make()` assumes that all null-free arrays are concrete value classes which does not need to be the case as shown above. Fix: Add check whether the klass is an inline type (which is only true for concrete inline type klasses). >> 3. `Parse::array_store_check()` needs to pass `null_free` to the `gen_checkcast()` in case we have a null-free ... > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > review comments Thanks Tobias! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1314#issuecomment-2535991735 From chagedorn at openjdk.org Wed Dec 11 13:31:55 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 11 Dec 2024 13:31:55 GMT Subject: [lworld] Integrated: 8345250: [lworld] C2: Array loads and stores on inexact flat arrays cause crashes In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 17:10:20 GMT, Christian Hagedorn wrote: > This PR fixes crashes that occur when trying to load/store from/to a flat array from which we statically know it is flat but we do not know the exact layout because the klass is inexact. > > ### The Layout of a Flat Array is only Statically Known If the Klass is Exact > Currently, the code for getting the array element address in `GraphKit::array_element_address()` assumes that whenever we have an array from which we know that it is flat, then we also know the exact array layout (i.e. assume the value klass is exact): > https://github.com/openjdk/valhalla/blob/5e876d607aba68e921cb8fa6a1a012acd1735825/src/hotspot/share/opto/graphKit.cpp#L1835-L1838 > > This does not need to be true as shown in the following test case where we have a flat array with an inexact klass/type: > https://github.com/openjdk/valhalla/blob/95fc9c71bffcf5b92a4cdbfb34ad9e3149266f79/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java#L4568-L4578 > > ### Emit Runtime Call to Load/Store from/to the Correct Array Element Address > What we actually would need for a flat array with an inexact klass is to emit a runtime call to load/store from/to the correct array element address. We cannot do better statically because we do not know the exact layout. > > ### Challenges > However, the problem is that in `GraphKit::array_element_address()` we somehow need to bail out back to `Parse::array_load/store()` such that we can emit the runtime call there. We could use a sentinel node because we do not actually need the element address node. But this could mess with some GVN transformations in between. What we do instead is to just fall to the `else` case in `GraphKit::array_element_address()` for non-flat arrays and still construct the element address node, even though it's not needed (will be folded away later): > https://github.com/openjdk/valhalla/blob/0858ce110da58ed7f1b634ae381e7c4eb0f37c3a/src/hotspot/share/opto/graphKit.cpp#L1840-L1849 > > ### Additionally Required Fixes > 1. `TypeAryKlassPtr::cast_to_exactness()` asserts that all null-free or flat arrays are exact which is not the case as shown above. Fix: Adjust assert. > 2. `ciArrayKlass::make()` assumes that all null-free arrays are concrete value classes which does not need to be the case as shown above. Fix: Add check whether the klass is an inline type (which is only true for concrete inline type klasses). > 3. `Parse::array_store_check()` needs to pass `null_free` to the `gen_checkcast()` in case we have a null-free flat array that is inexact (i.e. either ... This pull request has now been integrated. Changeset: c4f1714d Author: Christian Hagedorn URL: https://git.openjdk.org/valhalla/commit/c4f1714d21b61136a2451c1a0d1abe281c9cb8f8 Stats: 450 lines in 7 files changed: 292 ins; 62 del; 96 mod 8345250: [lworld] C2: Array loads and stores on inexact flat arrays cause crashes Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1314 From fparain at openjdk.org Wed Dec 11 13:48:19 2024 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 11 Dec 2024 13:48:19 GMT Subject: [lworld] RFR: 8345995: [lworld] Flat arrays need to be redesigned to support new flat layouts Message-ID: <-owOlQjyoQC0Le-Q6EaS6ZFWy7-8OrLvqkiYJpe8jLw=.2240bc95-2d23-4265-b6c9-f702e4918c12@github.com> Here's a redesign of flat arrays to support multiple flat layouts (NON_ATOMIC_FLAT, ATOMIC_FLAT, NULLABLE_ATOMIC_FLAT). The patch contains a lot of cleanup and simplification of the flat arrays access code. This patch has been tested in interpreted mode only on both x86_64 and aarch64. Unfortunately, it currently triggers a number of failures when run with JITs enabled. After a discussion with Tobias, this PR will probably not be integrated until a patch for the JITs is available. Regards, Fred ------------- Commit messages: - CDS fixes and various cleanup - Merge remote-tracking branch 'upstream/lworld' into array_ext_hdr - More flat arrays work and code cleanup Changes: https://git.openjdk.org/valhalla/pull/1315/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1315&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345995 Stats: 1556 lines in 62 files changed: 933 ins; 281 del; 342 mod Patch: https://git.openjdk.org/valhalla/pull/1315.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1315/head:pull/1315 PR: https://git.openjdk.org/valhalla/pull/1315 From fparain at openjdk.org Wed Dec 11 16:33:35 2024 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 11 Dec 2024 16:33:35 GMT Subject: [lworld] RFR: 8345995: [lworld] Flat arrays need to be redesigned to support new flat layouts [v2] In-Reply-To: <-owOlQjyoQC0Le-Q6EaS6ZFWy7-8OrLvqkiYJpe8jLw=.2240bc95-2d23-4265-b6c9-f702e4918c12@github.com> References: <-owOlQjyoQC0Le-Q6EaS6ZFWy7-8OrLvqkiYJpe8jLw=.2240bc95-2d23-4265-b6c9-f702e4918c12@github.com> Message-ID: <2tVEOQE5sGDHTw69zJTP7aKgWBLOBbKQid8ZH9bGn6k=.e25ea908-5635-4ecf-95ef-92cf3a5c4539@github.com> > Here's a redesign of flat arrays to support multiple flat layouts (NON_ATOMIC_FLAT, ATOMIC_FLAT, NULLABLE_ATOMIC_FLAT). The patch contains a lot of cleanup and simplification of the flat arrays access code. > > This patch has been tested in interpreted mode only on both x86_64 and aarch64. > > Unfortunately, it currently triggers a number of failures when run with JITs enabled. After a discussion with Tobias, this PR will probably not be integrated until a patch for the JITs is available. > > Regards, > > Fred Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge remote-tracking branch 'upstream/lworld' into array_ext_hdr - CDS fixes and various cleanup - Merge remote-tracking branch 'upstream/lworld' into array_ext_hdr - More flat arrays work and code cleanup ------------- Changes: https://git.openjdk.org/valhalla/pull/1315/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1315&range=01 Stats: 1556 lines in 62 files changed: 933 ins; 281 del; 342 mod Patch: https://git.openjdk.org/valhalla/pull/1315.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1315/head:pull/1315 PR: https://git.openjdk.org/valhalla/pull/1315 From rriggs at openjdk.org Wed Dec 11 22:09:45 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 11 Dec 2024 22:09:45 GMT Subject: [lworld] RFR: 8346035: javadoc value cleanup Message-ID: Updated javadoc for value objects when preview is enabled. Added text and decoration to highlight preview behavior of identity classes that are value classes with --enable-preview The decorations are similar to the existing preview highlights for Preview classes and methods. The updates include all of the wrapper classes, java.time, and java.util.Optional* and other classed annotated with @ValueBased. The ValueBased is updated to describe the behavior when --enable-preview. ------------- Commit messages: - 8346035: [lworld] javadoc for value objects when enable preview - Edits to javadoc to clarify use when --enable-preview. Changes: https://git.openjdk.org/valhalla/pull/1316/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1316&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346035 Stats: 412 lines in 37 files changed: 255 ins; 3 del; 154 mod Patch: https://git.openjdk.org/valhalla/pull/1316.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/valhalla/pull/1316 From liach at openjdk.org Thu Dec 12 00:12:52 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 12 Dec 2024 00:12:52 GMT Subject: [lworld] RFR: 8346035: javadoc value cleanup In-Reply-To: References: Message-ID: On Wed, 11 Dec 2024 22:02:25 GMT, Roger Riggs wrote: > Updated javadoc for value objects when preview is enabled. > > Added text and decoration to highlight preview behavior of identity classes that are value classes with --enable-preview > The decorations are similar to the existing preview highlights for Preview classes and methods. > > The updates include all of the wrapper classes, java.time, and java.util.Optional* and other classed annotated with @ValueBased. > > The ValueBased is updated to describe the behavior when --enable-preview. src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 70: > 68: {@link java.lang.IdentityException} is thrown.

> 69: > 70:

When preview features are enabled, use of value class instances for synchronization, mutexes, or with Should we include the

blocks here? src/java.base/share/classes/java/time/ZoneId.java line 167: > 165: * class; programmers should treat instances that are {@linkplain #equals(Object) equal} > 166: * as interchangeable and should not use instances for synchronization, mutexes, or > 167: * with {@linkplain java.lang.ref.Reference object references}. Should we add the preview warning with rewords, like When preview features are enabled, all implementations of {@code ZoneId} are {@linkplain Class#isValue value class}. ... ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1316#discussion_r1881083595 PR Review Comment: https://git.openjdk.org/valhalla/pull/1316#discussion_r1881181544 From fparain at openjdk.org Thu Dec 12 19:59:50 2024 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 12 Dec 2024 19:59:50 GMT Subject: [lworld] RFR: 8345995: [lworld] Flat arrays need to be redesigned to support new flat layouts [v3] In-Reply-To: <-owOlQjyoQC0Le-Q6EaS6ZFWy7-8OrLvqkiYJpe8jLw=.2240bc95-2d23-4265-b6c9-f702e4918c12@github.com> References: <-owOlQjyoQC0Le-Q6EaS6ZFWy7-8OrLvqkiYJpe8jLw=.2240bc95-2d23-4265-b6c9-f702e4918c12@github.com> Message-ID: > Here's a redesign of flat arrays to support multiple flat layouts (NON_ATOMIC_FLAT, ATOMIC_FLAT, NULLABLE_ATOMIC_FLAT). The patch contains a lot of cleanup and simplification of the flat arrays access code. > > This patch has been tested in interpreted mode only on both x86_64 and aarch64. > > Unfortunately, it currently triggers a number of failures when run with JITs enabled. After a discussion with Tobias, this PR will probably not be integrated until a patch for the JITs is available. > > Regards, > > Fred Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: Small cleanups ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1315/files - new: https://git.openjdk.org/valhalla/pull/1315/files/962bc4bb..5fe9f5f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1315&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1315&range=01-02 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1315.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1315/head:pull/1315 PR: https://git.openjdk.org/valhalla/pull/1315 From coleenp at openjdk.org Thu Dec 12 20:26:36 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 12 Dec 2024 20:26:36 GMT Subject: [lworld] RFR: 8331501: [lworld] Unsafe support for null marker Message-ID: <0C336aZdks72zcALRywvepgpEHkB4QTfAqO6dW6QBPE=.44e62abf-291f-4b95-9dd9-9aa32b73252a@github.com> Shouldn't this be getNullMarkerOffset? This was mostly implemented. Fixed the test. ------------- Commit messages: - Fix the test. - Get Field's null marker offset. Changes: https://git.openjdk.org/valhalla/pull/1317/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331501 Stats: 8 lines in 3 files changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1317.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1317/head:pull/1317 PR: https://git.openjdk.org/valhalla/pull/1317 From rriggs at openjdk.org Thu Dec 12 20:42:35 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 12 Dec 2024 20:42:35 GMT Subject: [lworld] RFR: 8346035: [lworld] javadoc for value objects when enable preview [v2] In-Reply-To: References: Message-ID: > Updated javadoc for value objects when preview is enabled. > > Added text and decoration to highlight preview behavior of identity classes that are value classes with --enable-preview > The decorations are similar to the existing preview highlights for Preview classes and methods. > > The updates include all of the wrapper classes, java.time, and java.util.Optional* and other classed annotated with @ValueBased. > > The ValueBased is updated to describe the behavior when --enable-preview. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Tidy up ValueBased.html ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1316/files - new: https://git.openjdk.org/valhalla/pull/1316/files/922d56cc..1d1e6234 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1316&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1316&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1316.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/valhalla/pull/1316 From rriggs at openjdk.org Thu Dec 12 20:42:37 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 12 Dec 2024 20:42:37 GMT Subject: [lworld] RFR: 8346035: [lworld] javadoc for value objects when enable preview [v2] In-Reply-To: References: Message-ID: On Wed, 11 Dec 2024 22:19:20 GMT, Chen Liang wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Tidy up ValueBased.html > > src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 70: > >> 68: {@link java.lang.IdentityException} is thrown.

>> 69: >> 70:

When preview features are enabled, use of value class instances for synchronization, mutexes, or with > > Should we include the > >

>
> > blocks here? In this context the preview-block looks out of place. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1316#discussion_r1882854141 From rriggs at openjdk.org Thu Dec 12 22:07:47 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 12 Dec 2024 22:07:47 GMT Subject: [lworld] RFR: 8346035: [lworld] javadoc for value objects when enable preview [v2] In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 00:09:24 GMT, Chen Liang wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Tidy up ValueBased.html > > src/java.base/share/classes/java/time/ZoneId.java line 167: > >> 165: * class; programmers should treat instances that are {@linkplain #equals(Object) equal} >> 166: * as interchangeable and should not use instances for synchronization, mutexes, or >> 167: * with {@linkplain java.lang.ref.Reference object references}. > > Should we add the preview warning with rewords, like > > When preview features are enabled, all implementations of {@code ZoneId} are {@linkplain Class#isValue value class}. ... There's more to do before ZoneId can be a Valhalla value class. Its subtype ZoneOffset has a non-final field that caches ZoneRules. So ZoneOffset can't be a value class. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1316#discussion_r1882951945 From liach at openjdk.org Thu Dec 12 22:16:07 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 12 Dec 2024 22:16:07 GMT Subject: [lworld] RFR: 8346035: [lworld] javadoc for value objects when enable preview [v2] In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 20:42:35 GMT, Roger Riggs wrote: >> Updated javadoc for value objects when preview is enabled. >> >> Added text and decoration to highlight preview behavior of identity classes that are value classes with --enable-preview >> The decorations are similar to the existing preview highlights for Preview classes and methods. >> >> The updates include all of the wrapper classes, java.time, and java.util.Optional* and other classed annotated with @ValueBased. >> >> The ValueBased is updated to describe the behavior when --enable-preview. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Tidy up ValueBased.html Thanks. Looks good to me. ------------- Marked as reviewed by liach (no project role). PR Review: https://git.openjdk.org/valhalla/pull/1316#pullrequestreview-2500880064 From fparain at openjdk.org Fri Dec 13 13:13:54 2024 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 13 Dec 2024 13:13:54 GMT Subject: [lworld] RFR: 8331501: [lworld] Unsafe support for null marker In-Reply-To: <0C336aZdks72zcALRywvepgpEHkB4QTfAqO6dW6QBPE=.44e62abf-291f-4b95-9dd9-9aa32b73252a@github.com> References: <0C336aZdks72zcALRywvepgpEHkB4QTfAqO6dW6QBPE=.44e62abf-291f-4b95-9dd9-9aa32b73252a@github.com> Message-ID: On Thu, 12 Dec 2024 20:20:26 GMT, Coleen Phillimore wrote: > Shouldn't this be getNullMarkerOffset? This was mostly implemented. Fixed the test. LGTM ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1317#pullrequestreview-2502267391 From coleenp at openjdk.org Fri Dec 13 14:37:58 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 13 Dec 2024 14:37:58 GMT Subject: [lworld] RFR: 8331501: [lworld] Unsafe support for null marker In-Reply-To: <0C336aZdks72zcALRywvepgpEHkB4QTfAqO6dW6QBPE=.44e62abf-291f-4b95-9dd9-9aa32b73252a@github.com> References: <0C336aZdks72zcALRywvepgpEHkB4QTfAqO6dW6QBPE=.44e62abf-291f-4b95-9dd9-9aa32b73252a@github.com> Message-ID: <-Z_ss09s8A6IYG4ML1FtTSV9AMAe4vrHNW_tv21PUEU=.dac13070-530d-46dd-8f6d-5de5bd503a2b@github.com> On Thu, 12 Dec 2024 20:20:26 GMT, Coleen Phillimore wrote: > Shouldn't this be getNullMarkerOffset? This was mostly implemented. Fixed the test. Thanks Fred! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1317#issuecomment-2541595133 From coleenp at openjdk.org Fri Dec 13 14:37:59 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 13 Dec 2024 14:37:59 GMT Subject: [lworld] Integrated: 8331501: [lworld] Unsafe support for null marker In-Reply-To: <0C336aZdks72zcALRywvepgpEHkB4QTfAqO6dW6QBPE=.44e62abf-291f-4b95-9dd9-9aa32b73252a@github.com> References: <0C336aZdks72zcALRywvepgpEHkB4QTfAqO6dW6QBPE=.44e62abf-291f-4b95-9dd9-9aa32b73252a@github.com> Message-ID: On Thu, 12 Dec 2024 20:20:26 GMT, Coleen Phillimore wrote: > Shouldn't this be getNullMarkerOffset? This was mostly implemented. Fixed the test. This pull request has now been integrated. Changeset: f017afc2 Author: Coleen Phillimore URL: https://git.openjdk.org/valhalla/commit/f017afc29743e2433289a19b304ebcddf3995ded Stats: 8 lines in 3 files changed: 3 ins; 0 del; 5 mod 8331501: [lworld] Unsafe support for null marker Reviewed-by: fparain ------------- PR: https://git.openjdk.org/valhalla/pull/1317 From fparain at openjdk.org Fri Dec 13 17:46:41 2024 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 13 Dec 2024 17:46:41 GMT Subject: [lworld] RFR: 8345995: [lworld] Flat arrays need to be redesigned to support new flat layouts [v4] In-Reply-To: <-owOlQjyoQC0Le-Q6EaS6ZFWy7-8OrLvqkiYJpe8jLw=.2240bc95-2d23-4265-b6c9-f702e4918c12@github.com> References: <-owOlQjyoQC0Le-Q6EaS6ZFWy7-8OrLvqkiYJpe8jLw=.2240bc95-2d23-4265-b6c9-f702e4918c12@github.com> Message-ID: > Here's a redesign of flat arrays to support multiple flat layouts (NON_ATOMIC_FLAT, ATOMIC_FLAT, NULLABLE_ATOMIC_FLAT). The patch contains a lot of cleanup and simplification of the flat arrays access code. > > This patch has been tested in interpreted mode only on both x86_64 and aarch64. > > Unfortunately, it currently triggers a number of failures when run with JITs enabled. After a discussion with Tobias, this PR will probably not be integrated until a patch for the JITs is available. > > Regards, > > Fred Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: Fix bad register usage causing mdp corruption ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1315/files - new: https://git.openjdk.org/valhalla/pull/1315/files/5fe9f5f5..048b88c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1315&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1315&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1315.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1315/head:pull/1315 PR: https://git.openjdk.org/valhalla/pull/1315 From dlsmith at openjdk.org Fri Dec 13 20:55:52 2024 From: dlsmith at openjdk.org (Dan Smith) Date: Fri, 13 Dec 2024 20:55:52 GMT Subject: [lworld] RFR: 8346035: [lworld] javadoc for value objects when enable preview [v2] In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 20:42:35 GMT, Roger Riggs wrote: >> Updated javadoc for value objects when preview is enabled. >> >> Added text and decoration to highlight preview behavior of identity classes that are value classes with --enable-preview >> The decorations are similar to the existing preview highlights for Preview classes and methods. >> >> The updates include all of the wrapper classes, java.time, and java.util.Optional* and other classed annotated with @ValueBased. >> >> The ValueBased is updated to describe the behavior when --enable-preview. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Tidy up ValueBased.html src/java.base/share/classes/java/lang/Boolean.java line 51: > 49: * class; programmers should treat instances that are {@linkplain #equals(Object) equal} > 50: * as interchangeable and should not use instances for synchronization, mutexes, or > 51: * with {@linkplain java.lang.ref.Reference object references}. We have a preview feature disclaimer for References. Is there a similar one for mutexes? (What exactly do you mean by "mutexes"? Is it distinct from "synchronization"?) src/java.base/share/classes/java/lang/Record.java line 74: > 72: * When preview features are enabled, {@code Record} is > 73: * an abstract {@linkplain Class#isValue value class}. > 74: * Subclasses of {@code Number} can be either an {@linkplain Class#isIdentity identity class} s/Number/Record/ src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 48: > 46: visible change in the behavior of the class's methods; > 47:
  • the class performs no synchronization using an instance's monitor;
    • > 48:
  • the class does not declare (or has deprecated any) accessible constructors;
    • This one is still relevant, as a concrete case of the next bullet, right? A value-based class should not let clients control identity creation. src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 68: > 66: associated monitor.

    > 67: > 68:

    When preview features are enabled, use of value class instances for synchronization, mutexes, or with A value-based class is not necessarily a value class under preview. I think this "behavior may change" disclaimer is trying to cover two cases, which should probably be identified directly: - The class may choose to allocate/cache instances differently - The class may choose to become a value class, and then [things may fail] ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1316#discussion_r1884529534 PR Review Comment: https://git.openjdk.org/valhalla/pull/1316#discussion_r1884518251 PR Review Comment: https://git.openjdk.org/valhalla/pull/1316#discussion_r1884520249 PR Review Comment: https://git.openjdk.org/valhalla/pull/1316#discussion_r1884526159 From dlsmith at openjdk.org Fri Dec 13 20:55:52 2024 From: dlsmith at openjdk.org (Dan Smith) Date: Fri, 13 Dec 2024 20:55:52 GMT Subject: [lworld] RFR: 8346035: [lworld] javadoc for value objects when enable preview [v2] In-Reply-To: References: Message-ID: <5RS_79YkRwkDnxEbYdsfgC5L53giK8KYq4Db4XLcdwQ=.04a66335-8301-4eaf-aa15-cb37bbba519c@github.com> On Fri, 13 Dec 2024 20:41:11 GMT, Dan Smith wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Tidy up ValueBased.html > > src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 48: > >> 46: visible change in the behavior of the class's methods; >> 47:

  • the class performs no synchronization using an instance's monitor;
    • >> 48:
  • the class does not declare (or has deprecated any) accessible constructors;
    • > > This one is still relevant, as a concrete case of the next bullet, right? A value-based class should not let clients control identity creation. Could maybe soften to "(or discourages use of any)"... ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1316#discussion_r1884530682 From rriggs at openjdk.org Mon Dec 16 16:22:00 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 16 Dec 2024 16:22:00 GMT Subject: [lworld] RFR: 8346035: [lworld] javadoc for value objects when enable preview [v2] In-Reply-To: <5RS_79YkRwkDnxEbYdsfgC5L53giK8KYq4Db4XLcdwQ=.04a66335-8301-4eaf-aa15-cb37bbba519c@github.com> References: <5RS_79YkRwkDnxEbYdsfgC5L53giK8KYq4Db4XLcdwQ=.04a66335-8301-4eaf-aa15-cb37bbba519c@github.com> Message-ID: On Fri, 13 Dec 2024 20:52:55 GMT, Dan Smith wrote: >> src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 48: >> >>> 46: visible change in the behavior of the class's methods; >>> 47:
  • the class performs no synchronization using an instance's monitor;
    • >>> 48:
  • the class does not declare (or has deprecated any) accessible constructors;
    • >> >> This one is still relevant, as a concrete case of the next bullet, right? A value-based class should not let clients control identity creation. > > Could maybe soften to "(or discourages use of any)"... I understood we've reversed the thinking of deprecating constructors for value classes, i.e. Integer. They don't need to be deprecated. Saying `new Integer(3)` does not give it identity (with --enable-preview). In the short term, the deprecation warning raises awareness in the non-enable-review case. This text is trying to cover two similar but not identical states, one as a recommendation for non-preview and the other for preview enabled. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1316#discussion_r1887116546 From rriggs at openjdk.org Mon Dec 16 16:53:54 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 16 Dec 2024 16:53:54 GMT Subject: [lworld] RFR: 8346035: [lworld] javadoc for value objects when enable preview [v2] In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 20:51:34 GMT, Dan Smith wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Tidy up ValueBased.html > > src/java.base/share/classes/java/lang/Boolean.java line 51: > >> 49: * class; programmers should treat instances that are {@linkplain #equals(Object) equal} >> 50: * as interchangeable and should not use instances for synchronization, mutexes, or >> 51: * with {@linkplain java.lang.ref.Reference object references}. > > We have a preview feature disclaimer for References. > > Is there a similar one for mutexes? (What exactly do you mean by "mutexes"? Is it distinct from "synchronization"?) Object.wait* and Object.notify are the most obvious APIs to add a disclaimer. IllegalMonitorStateException is thrown with the class name. IdentityException might be preferred and easier for developers to diagnose. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1316#discussion_r1887168065 From dlsmith at openjdk.org Mon Dec 16 16:53:55 2024 From: dlsmith at openjdk.org (Dan Smith) Date: Mon, 16 Dec 2024 16:53:55 GMT Subject: [lworld] RFR: 8346035: [lworld] javadoc for value objects when enable preview [v2] In-Reply-To: References: <5RS_79YkRwkDnxEbYdsfgC5L53giK8KYq4Db4XLcdwQ=.04a66335-8301-4eaf-aa15-cb37bbba519c@github.com> Message-ID: On Mon, 16 Dec 2024 16:19:26 GMT, Roger Riggs wrote: >> Could maybe soften to "(or discourages use of any)"... > > I understood we've reversed the thinking of deprecating constructors for value classes, i.e. Integer. > They don't need to be deprecated. Saying `new Integer(3)` does not give it identity (with --enable-preview). > In the short term, the deprecation warning raises awareness in the non-enable-review case. > This text is trying to cover two similar but not identical states, one as a recommendation for non-preview and the other for preview enabled. This document is primarily meant for API users who are not using preview features. The general rule, covered by the next bullet, is that a value-based (identity) class API will not expose identity creation. As applied to constructors, that means these classes shouldn't have public constructors. However, we want to allow for classes like Integer that have public constructors, but have deprecated them. In contrast, yes, a _value class_ doesn't need to worry about exposing constructors, because those don't expose any kind of identity creation anymore. After migrating Integer to be a value class, we can un-deprecate its constructors. (And thus, for now we can undo "forRemoval", since we know we don't intend to remove them.) I'd be happy to say "the class does not declare (or discourages use of any) accessible constructors;". ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1316#discussion_r1887170822 From rriggs at openjdk.org Mon Dec 16 20:08:26 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 16 Dec 2024 20:08:26 GMT Subject: [lworld] RFR: 8346035: [lworld] javadoc for value objects when enable preview [v3] In-Reply-To: References: Message-ID: > Updated javadoc for value objects when preview is enabled. > > Added text and decoration to highlight preview behavior of identity classes that are value classes with --enable-preview > The decorations are similar to the existing preview highlights for Preview classes and methods. > > The updates include all of the wrapper classes, java.time, and java.util.Optional* and other classed annotated with @ValueBased. > > The ValueBased is updated to describe the behavior when --enable-preview. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Clarified comments based on review feedback. Highlighted value object behavior on Object.notify* and Object.wait*. ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1316/files - new: https://git.openjdk.org/valhalla/pull/1316/files/1d1e6234..3d057635 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1316&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1316&range=01-02 Stats: 52 lines in 3 files changed: 44 ins; 0 del; 8 mod Patch: https://git.openjdk.org/valhalla/pull/1316.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/valhalla/pull/1316 From fparain at openjdk.org Mon Dec 16 20:36:04 2024 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 16 Dec 2024 20:36:04 GMT Subject: [lworld] RFR: 8346303: [lworld] Layout builder should not reuse gap before inherited fields Message-ID: Small fix to prevent a layout decision that can negatively impact the support of atomic layouts. ------------- Commit messages: - Don't try to reuse gap between header and inherited fields Changes: https://git.openjdk.org/valhalla/pull/1319/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1319&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346303 Stats: 13 lines in 1 file changed: 0 ins; 12 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1319.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1319/head:pull/1319 PR: https://git.openjdk.org/valhalla/pull/1319 From fparain at openjdk.org Mon Dec 16 20:39:59 2024 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 16 Dec 2024 20:39:59 GMT Subject: [lworld] Integrated: 8346303: [lworld] Layout builder should not reuse gap before inherited fields In-Reply-To: References: Message-ID: On Mon, 16 Dec 2024 20:32:01 GMT, Frederic Parain wrote: > Small fix to prevent a layout decision that can negatively impact the support of atomic layouts. This pull request has now been integrated. Changeset: 1a27c753 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/1a27c7539cb5dbecb8539807cb766969b15977b6 Stats: 13 lines in 1 file changed: 0 ins; 12 del; 1 mod 8346303: [lworld] Layout builder should not reuse gap before inherited fields ------------- PR: https://git.openjdk.org/valhalla/pull/1319 From david.lloyd at redhat.com Tue Dec 17 15:50:44 2024 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 17 Dec 2024 09:50:44 -0600 Subject: Native method binding Message-ID: With the (hopeful) ascendance of FFM over JNI, what about the idea of allowing `native` methods to be bound to `MethodHandle`s on the Java side at run time? This would allow for a much nicer experience than creating wrapper methods and would bring another level of parity with JNI, which has this capability (`RegisterNatives`). The capability could be restricted as a form of native access, and only allowed for methods in classes within the same module. What do you think? -- - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Tue Dec 17 17:02:17 2024 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 17 Dec 2024 12:02:17 -0500 Subject: Native method binding In-Reply-To: References: Message-ID: Wrong mailing list? Did you mean Panama instead of Valhalla? On Tue, Dec 17, 2024 at 10:51?AM David Lloyd wrote: > With the (hopeful) ascendance of FFM over JNI, what about the idea of > allowing `native` methods to be bound to `MethodHandle`s on the Java side > at run time? This would allow for a much nicer experience than creating > wrapper methods and would bring another level of parity with JNI, which has > this capability (`RegisterNatives`). The capability could be restricted as > a form of native access, and only allowed for methods in classes within the > same module. > > What do you think? > > -- > - DML ? he/him > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Tue Dec 17 17:11:57 2024 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 17 Dec 2024 11:11:57 -0600 Subject: Native method binding In-Reply-To: References: Message-ID: Oops, you're right. Sorry. All these clever code names... On Tue, Dec 17, 2024 at 11:02?AM David Alayachew wrote: > Wrong mailing list? Did you mean Panama instead of Valhalla? > > On Tue, Dec 17, 2024 at 10:51?AM David Lloyd > wrote: > >> With the (hopeful) ascendance of FFM over JNI, what about the idea of >> allowing `native` methods to be bound to `MethodHandle`s on the Java side >> at run time? This would allow for a much nicer experience than creating >> wrapper methods and would bring another level of parity with JNI, which has >> this capability (`RegisterNatives`). The capability could be restricted as >> a form of native access, and only allowed for methods in classes within the >> same module. >> >> What do you think? >> >> -- >> - DML ? he/him >> > -- - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Tue Dec 17 17:13:30 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 17 Dec 2024 17:13:30 GMT Subject: [lworld] RFR: 8346305: [lworld] Revert WeakHashMap POC for a value object policy Message-ID: <8P_gP_XEnO-WBkuxXhIxjbP8wf3QYBZeQ5qxL6cxWxw=.cad44c46-c1f1-44fe-acb8-fb1744ba8f2f@github.com> Remove the proof of concept for a ValuePolicy that would allow value objects to be put in WeakHashMap by using a proxy object. The feature is not being adopted at this time. Remove test/jdk/valhalla/valuetypes/WeakValuePolicyTest.java ------------- Commit messages: - 8346305: [lworld] Revert WeakHashMap POC for a value object policy Changes: https://git.openjdk.org/valhalla/pull/1320/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1320&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346305 Stats: 482 lines in 4 files changed: 1 ins; 476 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1320.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1320/head:pull/1320 PR: https://git.openjdk.org/valhalla/pull/1320 From dsimms at openjdk.org Tue Dec 17 20:07:21 2024 From: dsimms at openjdk.org (David Simms) Date: Tue, 17 Dec 2024 20:07:21 GMT Subject: [lworld] RFR: 8341844: [lworld] Test crashing in genzgc in ZBarrier::mark_from_old_slow_path(zaddress)+0x4c Message-ID: Generational zgc requires a store barrier in addition to the load barrier. load barrier followed by bulk copy isn't enough ------------- Commit messages: - 8341844: [lworld] Test crashing in genzgc in ZBarrier::mark_from_old_slow_path(zaddress)+0x4c Changes: https://git.openjdk.org/valhalla/pull/1321/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1321&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341844 Stats: 45 lines in 2 files changed: 33 ins; 5 del; 7 mod Patch: https://git.openjdk.org/valhalla/pull/1321.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1321/head:pull/1321 PR: https://git.openjdk.org/valhalla/pull/1321 From fparain at openjdk.org Tue Dec 17 20:36:01 2024 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 17 Dec 2024 20:36:01 GMT Subject: [lworld] RFR: 8346467: [lworld] Value record cannot be implicitly constructible Message-ID: <91h2f4sFymQieQujbIaHFx7RkK9Az1ZFB_LnCHZGUKQ=.fb98e789-d3d2-4edf-b096-ef60486ffbda@github.com> Small fix to support implicitly constructible value records. ------------- Commit messages: - Add j.l.Record as valid super type for implicitly constructible values Changes: https://git.openjdk.org/valhalla/pull/1322/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1322&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346467 Stats: 23 lines in 2 files changed: 22 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1322.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1322/head:pull/1322 PR: https://git.openjdk.org/valhalla/pull/1322 From eosterlund at openjdk.org Tue Dec 17 20:52:57 2024 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 17 Dec 2024 20:52:57 GMT Subject: [lworld] RFR: 8341844: [lworld] Test crashing in genzgc in ZBarrier::mark_from_old_slow_path(zaddress)+0x4c In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 20:02:03 GMT, David Simms wrote: > Generational zgc requires a store barrier in addition to the load barrier. > load barrier followed by bulk copy isn't enough Looks good. ------------- Marked as reviewed by eosterlund (no project role). PR Review: https://git.openjdk.org/valhalla/pull/1321#pullrequestreview-2510083731 From fparain at openjdk.org Tue Dec 17 21:39:50 2024 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 17 Dec 2024 21:39:50 GMT Subject: [lworld] RFR: 8341844: [lworld] Test crashing in genzgc in ZBarrier::mark_from_old_slow_path(zaddress)+0x4c In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 20:02:03 GMT, David Simms wrote: > Generational zgc requires a store barrier in addition to the load barrier. > load barrier followed by bulk copy isn't enough src/hotspot/share/gc/z/zBarrierSet.inline.hpp line 499: > 497: // 2) load and store barrier for each oop > 498: // 3) possibly raw copy for any primitive payload trailer > 499: assert(lk == NON_ATOMIC_FLAT || lk == PAYLOAD, "Cannot support layout other than NON_ATOMIC_FLAT"); // Note: PAYLOAD is incorrect, resolve when transistioned to new flattening Why is PAYLOAD incorrect here? And what about ATOMIC_FLAT? Even with ZGC, it can contain an oop. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1321#discussion_r1889258598 From dsimms at openjdk.org Wed Dec 18 08:19:55 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 18 Dec 2024 08:19:55 GMT Subject: [lworld] RFR: 8346467: [lworld] Value record cannot be implicitly constructible In-Reply-To: <91h2f4sFymQieQujbIaHFx7RkK9Az1ZFB_LnCHZGUKQ=.fb98e789-d3d2-4edf-b096-ef60486ffbda@github.com> References: <91h2f4sFymQieQujbIaHFx7RkK9Az1ZFB_LnCHZGUKQ=.fb98e789-d3d2-4edf-b096-ef60486ffbda@github.com> Message-ID: On Tue, 17 Dec 2024 20:31:45 GMT, Frederic Parain wrote: > Small fix to support implicitly constructible value records. Marked as reviewed by dsimms (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1322#pullrequestreview-2511099754 From dsimms at openjdk.org Wed Dec 18 08:24:52 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 18 Dec 2024 08:24:52 GMT Subject: [lworld] RFR: 8341844: [lworld] Test crashing in genzgc in ZBarrier::mark_from_old_slow_path(zaddress)+0x4c In-Reply-To: References: Message-ID: <7nTl_TV97A1sbDomEpOGTqBdoCdbzror1B-4vNutM-0=.705ed057-2011-4495-ac33-6896c362f47c@github.com> On Tue, 17 Dec 2024 21:37:00 GMT, Frederic Parain wrote: >> Generational zgc requires a store barrier in addition to the load barrier. >> load barrier followed by bulk copy isn't enough > > src/hotspot/share/gc/z/zBarrierSet.inline.hpp line 499: > >> 497: // 2) load and store barrier for each oop >> 498: // 3) possibly raw copy for any primitive payload trailer >> 499: assert(lk == NON_ATOMIC_FLAT || lk == PAYLOAD, "Cannot support layout other than NON_ATOMIC_FLAT"); // Note: PAYLOAD is incorrect, resolve when transistioned to new flattening > > Why is PAYLOAD incorrect here? > And what about ATOMIC_FLAT? Even with ZGC, it can contain an oop. You are correct there is a use single case under the `md->contains_oops()` condition with Z that is valid, a single oop. Will adjust ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1321#discussion_r1889807848 From dsimms at openjdk.org Wed Dec 18 11:16:10 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 18 Dec 2024 11:16:10 GMT Subject: [lworld] RFR: 8341844: [lworld] Test crashing in genzgc in ZBarrier::mark_from_old_slow_path(zaddress)+0x4c [v2] In-Reply-To: References: Message-ID: > Generational zgc requires a store barrier in addition to the load barrier. > load barrier followed by bulk copy isn't enough David Simms has updated the pull request incrementally with two additional commits since the last revision: - Correct atomicity requirement assertion - Sanity checking Xint with the pickiest GC ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1321/files - new: https://git.openjdk.org/valhalla/pull/1321/files/672d282d..94a02c6d Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1321&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1321&range=00-01 Stats: 22 lines in 2 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1321.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1321/head:pull/1321 PR: https://git.openjdk.org/valhalla/pull/1321 From fparain at openjdk.org Wed Dec 18 13:12:54 2024 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 18 Dec 2024 13:12:54 GMT Subject: [lworld] RFR: 8346467: [lworld] Value record cannot be implicitly constructible In-Reply-To: <91h2f4sFymQieQujbIaHFx7RkK9Az1ZFB_LnCHZGUKQ=.fb98e789-d3d2-4edf-b096-ef60486ffbda@github.com> References: <91h2f4sFymQieQujbIaHFx7RkK9Az1ZFB_LnCHZGUKQ=.fb98e789-d3d2-4edf-b096-ef60486ffbda@github.com> Message-ID: <4wc5Apkd858jyPV5_E6J0d9VtaMaAfP92qtHwImiSqA=.0983e318-1af8-48dd-8cc8-7231fb17871e@github.com> On Tue, 17 Dec 2024 20:31:45 GMT, Frederic Parain wrote: > Small fix to support implicitly constructible value records. Thank you for the review. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1322#issuecomment-2551280598 From fparain at openjdk.org Wed Dec 18 13:12:54 2024 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 18 Dec 2024 13:12:54 GMT Subject: [lworld] Integrated: 8346467: [lworld] Value record cannot be implicitly constructible In-Reply-To: <91h2f4sFymQieQujbIaHFx7RkK9Az1ZFB_LnCHZGUKQ=.fb98e789-d3d2-4edf-b096-ef60486ffbda@github.com> References: <91h2f4sFymQieQujbIaHFx7RkK9Az1ZFB_LnCHZGUKQ=.fb98e789-d3d2-4edf-b096-ef60486ffbda@github.com> Message-ID: <-2UGjeE9QOJB17i16OnRVJDH49eFjO62yJIJsw_COtY=.6bf61315-8f45-4c88-84fe-3798d27a9df5@github.com> On Tue, 17 Dec 2024 20:31:45 GMT, Frederic Parain wrote: > Small fix to support implicitly constructible value records. This pull request has now been integrated. Changeset: 5313fdad Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/5313fdadf30de1416022d8986f87ec7e4f925a5a Stats: 23 lines in 2 files changed: 22 ins; 0 del; 1 mod 8346467: [lworld] Value record cannot be implicitly constructible Reviewed-by: dsimms ------------- PR: https://git.openjdk.org/valhalla/pull/1322 From rriggs at openjdk.org Wed Dec 18 15:31:53 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 18 Dec 2024 15:31:53 GMT Subject: [lworld] Integrated: 8346305: [lworld] Revert WeakHashMap POC for a value object policy In-Reply-To: <8P_gP_XEnO-WBkuxXhIxjbP8wf3QYBZeQ5qxL6cxWxw=.cad44c46-c1f1-44fe-acb8-fb1744ba8f2f@github.com> References: <8P_gP_XEnO-WBkuxXhIxjbP8wf3QYBZeQ5qxL6cxWxw=.cad44c46-c1f1-44fe-acb8-fb1744ba8f2f@github.com> Message-ID: On Tue, 17 Dec 2024 17:08:50 GMT, Roger Riggs wrote: > Remove the proof of concept for a ValuePolicy that would allow value objects to be put in WeakHashMap by using a proxy object. > The feature is not being adopted at this time. > Remove test/jdk/valhalla/valuetypes/WeakValuePolicyTest.java This pull request has now been integrated. Changeset: 137b0c2e Author: Roger Riggs URL: https://git.openjdk.org/valhalla/commit/137b0c2e6ecedeba0cd64e2b0dfb8359934c28e1 Stats: 482 lines in 4 files changed: 1 ins; 476 del; 5 mod 8346305: [lworld] Revert WeakHashMap POC for a value object policy ------------- PR: https://git.openjdk.org/valhalla/pull/1320 From dsimms at openjdk.org Wed Dec 18 17:32:26 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 18 Dec 2024 17:32:26 GMT Subject: [lworld] RFR: 8341844: [lworld] Test crashing in genzgc in ZBarrier::mark_from_old_slow_path(zaddress)+0x4c [v3] In-Reply-To: References: Message-ID: > Generational zgc requires a store barrier in addition to the load barrier. > load barrier followed by bulk copy isn't enough David Simms has updated the pull request incrementally with one additional commit since the last revision: Remove dubious assert ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1321/files - new: https://git.openjdk.org/valhalla/pull/1321/files/94a02c6d..9e3434cf Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1321&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1321&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1321.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1321/head:pull/1321 PR: https://git.openjdk.org/valhalla/pull/1321 From dsimms at openjdk.org Wed Dec 18 21:36:52 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 18 Dec 2024 21:36:52 GMT Subject: [lworld] Integrated: 8341844: [lworld] Test crashing in genzgc in ZBarrier::mark_from_old_slow_path(zaddress)+0x4c In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 20:02:03 GMT, David Simms wrote: > Generational zgc requires a store barrier in addition to the load barrier. > load barrier followed by bulk copy isn't enough This pull request has now been integrated. Changeset: 896cca55 Author: David Simms URL: https://git.openjdk.org/valhalla/commit/896cca552d8e6a9ee56227192b32fb89c86b3a9a Stats: 62 lines in 3 files changed: 50 ins; 5 del; 7 mod 8341844: [lworld] Test crashing in genzgc in ZBarrier::mark_from_old_slow_path(zaddress)+0x4c Co-authored-by: Erik ?sterlund Reviewed-by: eosterlund ------------- PR: https://git.openjdk.org/valhalla/pull/1321 From dsimms at openjdk.org Wed Dec 18 21:57:46 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 18 Dec 2024 21:57:46 GMT Subject: [lworld] RFR: Merge jdk-24+22 Message-ID: Merge jdk-24+22 ------------- Commit messages: - Merge branch 'lworld' into lworld_merge_jdk_24_22 - Adjust testing - Revert "Hacked Tests" - Hacked Tests - Merge branch 'lworld' into lworld_merge_jdk_24_22 - ZGC options changed - Merge tag 'jdk-24+22' into lworld_merge_jdk_24_22 - 8342156: C2: Compilation failure with fewer arguments after JDK-8329032 - 8342642: Class loading failure due to archived map issue in ModuleLoaderMap.Mapper - 8342181: Update tests to use stronger Key and Salt size - ... and 119 more: https://git.openjdk.org/valhalla/compare/896cca55...8883b2f8 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1323&range=00.0 - jdk-24+22: https://webrevs.openjdk.org/?repo=valhalla&pr=1323&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1323/files Stats: 166145 lines in 1351 files changed: 19098 ins; 143080 del; 3967 mod Patch: https://git.openjdk.org/valhalla/pull/1323.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/valhalla/pull/1323 From dsimms at openjdk.org Thu Dec 19 08:49:59 2024 From: dsimms at openjdk.org (David Simms) Date: Thu, 19 Dec 2024 08:49:59 GMT Subject: [lworld] Integrated: Merge jdk-24+22 In-Reply-To: References: Message-ID: <4aYpVxa5qoNOHciwlxLziofTX6Wdo7OEo5KhR8CC2uw=.57e1a403-5abe-4bd0-8209-235f32613d3c@github.com> On Wed, 18 Dec 2024 21:48:23 GMT, David Simms wrote: > Merge jdk-24+22 This pull request has now been integrated. Changeset: 40bc4b6b Author: David Simms URL: https://git.openjdk.org/valhalla/commit/40bc4b6b54f34761c717b0e3faf6e45e593b7e4a Stats: 166145 lines in 1351 files changed: 19098 ins; 143080 del; 3967 mod Merge jdk-24+22 Merge jdk-24+22 ------------- PR: https://git.openjdk.org/valhalla/pull/1323 From dsimms at openjdk.org Thu Dec 19 10:26:51 2024 From: dsimms at openjdk.org (David Simms) Date: Thu, 19 Dec 2024 10:26:51 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge jdk-24+23 ------------- Commit messages: - ZGC only - Merge tag 'jdk-24+23' into lworld_merge_jdk_24_23 - 8343214: Fix encoding errors in APX New Data Destination Instructions Support - 8279016: JFR Leak Profiler is broken with Shenandoah - 8341408: Implement JEP 488: Primitive Types in Patterns, instanceof, and switch (Second Preview) - 8341834: C2 compilation fails with "bad AD file" due to Replicate - 8343068: C2: CastX2P Ideal transformation not always applied - 8339303: C2: dead node after failing to match cloned address expression - 8331341: secondary_super_cache does not scale well: C1 and interpreter - 8318442: java/net/httpclient/ManyRequests2.java fails intermittently on Linux - ... and 91 more: https://git.openjdk.org/valhalla/compare/40bc4b6b...2cd18deb The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1324&range=00.0 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1324&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1324/files Stats: 135556 lines in 784 files changed: 105963 ins; 10456 del; 19137 mod Patch: https://git.openjdk.org/valhalla/pull/1324.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1324/head:pull/1324 PR: https://git.openjdk.org/valhalla/pull/1324 From fparain at openjdk.org Thu Dec 19 20:02:21 2024 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 19 Dec 2024 20:02:21 GMT Subject: [lworld] RFR: 8346680: [lworld] Field flattening when composing value classes should be revisited Message-ID: Adjustments to flattening policy when composing atomic and non-atomic value types. ------------- Commit messages: - Fix volatile and abstract - Refine flattening policy for value composition Changes: https://git.openjdk.org/valhalla/pull/1325/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1325&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346680 Stats: 403 lines in 5 files changed: 386 ins; 7 del; 10 mod Patch: https://git.openjdk.org/valhalla/pull/1325.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1325/head:pull/1325 PR: https://git.openjdk.org/valhalla/pull/1325 From fparain at openjdk.org Thu Dec 19 20:06:53 2024 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 19 Dec 2024 20:06:53 GMT Subject: [lworld] Integrated: 8346680: [lworld] Field flattening when composing value classes should be revisited In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 19:57:21 GMT, Frederic Parain wrote: > Adjustments to flattening policy when composing atomic and non-atomic value types. This pull request has now been integrated. Changeset: 56810912 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/56810912b838ec17cbab4480afe347e9fd25881a Stats: 403 lines in 5 files changed: 386 ins; 7 del; 10 mod 8346680: [lworld] Field flattening when composing value classes should be revisited ------------- PR: https://git.openjdk.org/valhalla/pull/1325 From dsimms at openjdk.org Thu Dec 19 23:36:53 2024 From: dsimms at openjdk.org (David Simms) Date: Thu, 19 Dec 2024 23:36:53 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 10:19:45 GMT, David Simms wrote: > Merge jdk-24+23 This pull request has now been integrated. Changeset: 403393f8 Author: David Simms URL: https://git.openjdk.org/valhalla/commit/403393f80626a62545811af46f640165d3e44121 Stats: 135556 lines in 784 files changed: 105963 ins; 10456 del; 19137 mod Merge jdk Merge jdk-24+23 ------------- PR: https://git.openjdk.org/valhalla/pull/1324 From duke at openjdk.org Thu Dec 26 22:11:53 2024 From: duke at openjdk.org (duke) Date: Thu, 26 Dec 2024 22:11:53 GMT Subject: [lworld+fp16] Withdrawn: 8339494: Porting HalfFloatVector classes. In-Reply-To: <8wlNcjc8SbwzEq7Sluk9Bcg2Hw6FPdQx-T0mckR6wYc=.834597fd-30f2-45b8-9f6f-a1e66640f2eb@github.com> References: <8wlNcjc8SbwzEq7Sluk9Bcg2Hw6FPdQx-T0mckR6wYc=.834597fd-30f2-45b8-9f6f-a1e66640f2eb@github.com> Message-ID: On Tue, 3 Sep 2024 17:20:19 GMT, Jatin Bhateja wrote: > - Port existing HalfFloatVector and its concrete vector classes from vectorIntrinsics+fp16 to lworld+fp16. > - These new vector classes uses Float16 array as their backing storage. > - Idea is to enable intrinsificaiton of new HalfFloatVector operations and leverage existing Float16 auto-vectorization and backend support. > > All existing VectorAPI tests are passing with the patch. > > Best Regards, > Jatin > > Follow up work:- > a) Jtreg suite extensions to cover HalfFloatVector operations. > b) Handle Float16 lane type in vector API inline expansion layer. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/valhalla/pull/1233 From jean-noel.rouvignac at pingidentity.com Sun Dec 29 16:48:47 2024 From: jean-noel.rouvignac at pingidentity.com (=?UTF-8?Q?Jean=2DNo=C3=ABl_Rouvignac?=) Date: Sun, 29 Dec 2024 17:48:47 +0100 Subject: Current thinking about the future nullability of java.time.Duration Message-ID: Hello, I have a use case for configuration objects where I would like to use java.time.Duration to represent time intervals, timeouts, delays, etc. for example. In these configuration objects, sometimes users may not provide a value, and the configuration framework does not have a default value for it either. This is to be interpreted as "disable the feature" or "let the library decide". For this specific case, I was considering returning `null` to mean "disable the feature" or "let the library decide". java.time.Duration being marked as a value based class, I wanted to confirm that using `null` will not force significant rework in the future? i.e. java.time.Duration will not opt-in to become a null-restricted value class type (https://openjdk.org/jeps/8316779). Thanks a lot, and thanks for the huge work on Valhalla. Good luck for bringing it into mainline Java ! Jean-No?l -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.? If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjx001202 at gmail.com Sun Dec 29 19:48:39 2024 From: zjx001202 at gmail.com (Glavo) Date: Mon, 30 Dec 2024 03:48:39 +0800 Subject: Current thinking about the future nullability of java.time.Duration In-Reply-To: References: Message-ID: Hi Jean-No?l, >From what I understand, the null-restricted types are use-site specified, which means that `Duration` is not null-restricted, but `Duration!` is null-restricted, even though it is a value class. It is also worth noting that null-restricted types are not a requirement for flattening value objects. For a variable of a nullable value type, Valhalla may use a "null channel" to distinguish between null and non-null values. The null channel could be a boolean variable or something else, you can read this article[1] to learn more about it. Glavo [1]: https://cr.openjdk.org/~jrose/values/flattened-values.html On Mon, Dec 30, 2024 at 12:49?AM Jean-No?l Rouvignac < jean-noel.rouvignac at pingidentity.com> wrote: > Hello, > > I have a use case for configuration objects where I would like to > use java.time.Duration to represent time intervals, timeouts, delays, etc. > for example. > > In these configuration objects, sometimes users may not provide a value, > and the configuration framework does not have a default value for it > either. This is to be interpreted as "disable the feature" or "let the > library decide". For this specific case, I was considering returning `null` > to mean "disable the feature" or "let the library decide". > > java.time.Duration being marked as a value based class, I wanted to > confirm that using `null` will not force significant rework in the future? > i.e. java.time.Duration will not opt-in to become a null-restricted value > class type (https://openjdk.org/jeps/8316779). > > Thanks a lot, and thanks for the huge work on Valhalla. Good luck for > bringing it into mainline Java ! > > Jean-No?l > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* -------------- next part -------------- An HTML attachment was scrubbed... URL: