From coleenp at openjdk.org Fri Jan 2 14:01:01 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Jan 2026 14:01:01 GMT Subject: [lworld] RFR: 8367408: [lworld] runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot fails [v3] In-Reply-To: <0sVoepdRGolHCeuFrNJMcSeyLs_dX9Wxbh0MIV46iWI=.25ada8a3-b9b8-4ba5-825c-f330e89be863@github.com> References: <0sVoepdRGolHCeuFrNJMcSeyLs_dX9Wxbh0MIV46iWI=.25ada8a3-b9b8-4ba5-825c-f330e89be863@github.com> Message-ID: On Fri, 19 Dec 2025 20:50:01 GMT, Coleen Phillimore wrote: >> This test has failed for various reasons, but the last of the reasons was that sig_cc - calling convention adapter for scalarized parameters was null for a value class. The sig_cc adapter for valhalla won't be saved with AOT until [JDK-8373348](https://bugs.openjdk.org/browse/JDK-8373348). This change moves where they are regenerated to where the method is linked. >> >> Testing with tier1-4. in progress, and with the failed test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Removing two tests from ProblemList-enable-valhalla.txt that pass with this fix. Thank you for the reviews Matias and Fred. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1837#issuecomment-3705374426 From coleenp at openjdk.org Fri Jan 2 14:01:02 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Jan 2026 14:01:02 GMT Subject: [lworld] Integrated: 8367408: [lworld] runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot fails In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 22:46:40 GMT, Coleen Phillimore wrote: > This test has failed for various reasons, but the last of the reasons was that sig_cc - calling convention adapter for scalarized parameters was null for a value class. The sig_cc adapter for valhalla won't be saved with AOT until [JDK-8373348](https://bugs.openjdk.org/browse/JDK-8373348). This change moves where they are regenerated to where the method is linked. > > Testing with tier1-4. in progress, and with the failed test. This pull request has now been integrated. Changeset: fe500a0a Author: Coleen Phillimore URL: https://git.openjdk.org/valhalla/commit/fe500a0a90f96c8d0573cbb85c62db70c0cc73d4 Stats: 34 lines in 4 files changed: 17 ins; 17 del; 0 mod 8367408: [lworld] runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot fails Reviewed-by: matsaave, fparain ------------- PR: https://git.openjdk.org/valhalla/pull/1837 From duke at openjdk.org Fri Jan 2 17:43:02 2026 From: duke at openjdk.org (duke) Date: Fri, 2 Jan 2026 17:43:02 GMT Subject: [lworld] Withdrawn: 8371199: [lworld] Flattening of nullable elements of classes similar to j.l.Long In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 19:50:25 GMT, Quan Anh Mai wrote: > Hi, > > Currently, the layout of a nullable `j.l.Long`, if flattened, must be at least 65 bits. This exceeds the maximum size a GPR can generally hold, as well as the default object alignment of Hotspot. As a result, accessing such elements atomically require 128-bit atomic accesses, as well as mechanism from the GC to allocate overaligned objects. And even then, we will encounter the same issue, just with larger objects. > > We can observe that, a nullable element does not really have an additional bit of information, it just has an additional state (e.g. a nullable `j.l.Long` has `2^64 + 1` states, not `2^65`), and it is just unfortunate that we need a whole bit to be able to represent such an element. However, we can rely on the fact that all payload bits are irrelevant when the null marker is 0 to make a sequence of more than 1 memory access instructions look atomic. > > C1 has not been implemented yet, we will bailout the compilation when encountering such an access. I will implement this functionality later. > > Please take a look and leave your reviews, thanks a lot. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/valhalla/pull/1720 From vromero at openjdk.org Fri Jan 2 21:03:18 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 Jan 2026 21:03:18 GMT Subject: RFR: remove support for LooselyConsistentValue Message-ID: <1uCiTfUk2Sa2D6t1i1kZHF2bL_ra-smSVPfSIxKQtOU=.e49ac876-23ed-4a82-b491-c96fa47dc359@github.com> very simple PR, removing a remaining reference to interface LooselyConsistentValue ------------- Commit messages: - remove support for LooselyConsistentValue Changes: https://git.openjdk.org/valhalla/pull/1856/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1856&range=00 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1856.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1856/head:pull/1856 PR: https://git.openjdk.org/valhalla/pull/1856 From vromero at openjdk.org Fri Jan 2 21:40:36 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 Jan 2026 21:40:36 GMT Subject: RFR: remove support for LooselyConsistentValue [v2] In-Reply-To: <1uCiTfUk2Sa2D6t1i1kZHF2bL_ra-smSVPfSIxKQtOU=.e49ac876-23ed-4a82-b491-c96fa47dc359@github.com> References: <1uCiTfUk2Sa2D6t1i1kZHF2bL_ra-smSVPfSIxKQtOU=.e49ac876-23ed-4a82-b491-c96fa47dc359@github.com> Message-ID: > very simple PR, removing a remaining reference to interface LooselyConsistentValue Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'remove.support.looselyConsistentValueType' of https://github.com/vicente-romero-oracle/valhalla into remove.support.looselyConsistentValueType - remove support for LooselyConsistentValue ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1856/files - new: https://git.openjdk.org/valhalla/pull/1856/files/16f6e954..637dfff4 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1856&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1856&range=00-01 Stats: 65 lines in 1 file changed: 0 ins; 65 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1856.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1856/head:pull/1856 PR: https://git.openjdk.org/valhalla/pull/1856 From liach at openjdk.org Fri Jan 2 22:53:20 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 Jan 2026 22:53:20 GMT Subject: RFR: remove support for LooselyConsistentValue [v2] In-Reply-To: References: <1uCiTfUk2Sa2D6t1i1kZHF2bL_ra-smSVPfSIxKQtOU=.e49ac876-23ed-4a82-b491-c96fa47dc359@github.com> Message-ID: On Fri, 2 Jan 2026 21:40:36 GMT, Vicente Romero wrote: >> very simple PR, removing a remaining reference to interface LooselyConsistentValue > > Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'remove.support.looselyConsistentValueType' of https://github.com/vicente-romero-oracle/valhalla into remove.support.looselyConsistentValueType > - remove support for LooselyConsistentValue Good. ------------- Marked as reviewed by liach (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1856#pullrequestreview-3624011053 From jbhateja at openjdk.org Sat Jan 3 03:22:57 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sat, 3 Jan 2026 03:22:57 GMT Subject: RFR: remove support for LooselyConsistentValue [v2] In-Reply-To: References: <1uCiTfUk2Sa2D6t1i1kZHF2bL_ra-smSVPfSIxKQtOU=.e49ac876-23ed-4a82-b491-c96fa47dc359@github.com> Message-ID: On Fri, 2 Jan 2026 21:40:36 GMT, Vicente Romero wrote: >> very simple PR, removing a remaining reference to interface LooselyConsistentValue > > Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'remove.support.looselyConsistentValueType' of https://github.com/vicente-romero-oracle/valhalla into remove.support.looselyConsistentValueType > - remove support for LooselyConsistentValue Hi @vicente-romero-oracle , In absence of LooselyConsistentValue annotation what is the mechanism to flatten a value class null-restricted field with sizes greater than 8 bytes. lworld+vector makes heavy use of this annotation to flatten vector payloads into concrete vector classes. https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java#L461 ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1856#issuecomment-3706649223 From liach at openjdk.org Sat Jan 3 06:58:32 2026 From: liach at openjdk.org (Chen Liang) Date: Sat, 3 Jan 2026 06:58:32 GMT Subject: RFR: remove support for LooselyConsistentValue [v2] In-Reply-To: References: <1uCiTfUk2Sa2D6t1i1kZHF2bL_ra-smSVPfSIxKQtOU=.e49ac876-23ed-4a82-b491-c96fa47dc359@github.com> Message-ID: On Sat, 3 Jan 2026 03:19:53 GMT, Jatin Bhateja wrote: >> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch 'remove.support.looselyConsistentValueType' of https://github.com/vicente-romero-oracle/valhalla into remove.support.looselyConsistentValueType >> - remove support for LooselyConsistentValue > > Hi @vicente-romero-oracle , In absence of LooselyConsistentValue annotation what is the mechanism to flatten a value class null-restricted field with sizes greater than 8 bytes. lworld+vector makes heavy use of this annotation to flatten vector payloads into concrete vector classes. > https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java#L461 Hi @jatin-bhateja, this is an non-annotation interface from the old model, implemented by big flat values. The internal annotation that now marks big flat value classes is unaffected. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1856#issuecomment-3706841648 From jbhateja at openjdk.org Sat Jan 3 10:07:22 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sat, 3 Jan 2026 10:07:22 GMT Subject: RFR: remove support for LooselyConsistentValue [v2] In-Reply-To: References: <1uCiTfUk2Sa2D6t1i1kZHF2bL_ra-smSVPfSIxKQtOU=.e49ac876-23ed-4a82-b491-c96fa47dc359@github.com> Message-ID: <82Q5FYxM7KLE7CKA01J0Q6E4pmH0N2Wk_41Y3Qb8io4=.55767224-824a-4ea7-a25c-97a6316abc0a@github.com> On Fri, 2 Jan 2026 21:40:36 GMT, Vicente Romero wrote: >> very simple PR, removing a remaining reference to interface LooselyConsistentValue > > Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'remove.support.looselyConsistentValueType' of https://github.com/vicente-romero-oracle/valhalla into remove.support.looselyConsistentValueType > - remove support for LooselyConsistentValue Thanks @liach , Yes annotations are intact, just got carrier away by the subject line :-) ------------- Marked as reviewed by jbhateja (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1856#pullrequestreview-3624282913 From mchevalier at openjdk.org Mon Jan 5 08:59:09 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Mon, 5 Jan 2026 08:59:09 GMT Subject: [lworld] RFR: 8372806: [lworld] x64: save bad values instead of rfp and lr above the extension space In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 07:56:27 GMT, Marc Chevalier wrote: > That's the x86 counterpart of [JDK-8371993](https://bugs.openjdk.org/browse/JDK-8371993). > > I've added some comments, using the offsets given in `frame_x86.hpp` to make sure to put the frame start at the right place. In particular, the frame start is 2 pointer sizes under the sender's sp: > > https://github.com/openjdk/valhalla/blob/3c41c2aa442076827cb4480373a1d481e481cdf1/src/hotspot/cpu/x86/frame_x86.hpp#L61-L62 > > Unlike aarch64, with x64 we have only one copy of rbp. As with aarch64, I had to get rid of an assert that can't be checked anymore. A small price to pay. > > Now, in debug, instead of > > pop r13 > sub rsp,0x20 > push r13 > > we have > > pop r13 > sub rsp,0x20 > mov DWORD PTR [rsp-0x4],0xdeadda7a > mov DWORD PTR [rsp-0x8],0xdeadda7a > sub rsp,0x8 > > I've kept the `pop r13` to limit the difference of behavior between debug and product builds: both will overwrite `r13` with the return address, whether it's a good idea or not. > > And at runtime, on my favorite `compiler/valhalla/inlinetypes/CorrectlyRestoreRfp.java` example, instead of the stack: > > 0x7fd7345fe660: 0x000000042724f5d0 0x00007fd7345fe750 <-- rsp > 0x7fd7345fe670: 0xffffffffffffffff 0x00007fd740acc0f7 > 0x7fd7345fe680: 0x00007fd700000000 0x000000042724f5d0 > 0x7fd7345fe690: 0x000000056f517f28 0x00007fd7390002a6 > 0x7fd7345fe6a0: 0x00007fd72c90c8b3 0x0000000000000078 <-- # | sp_inc > 0x7fd7345fe6b0: 0x00007fd7345fe750 0x00007fd740541306 <-- rsp - 0x50 # rbp | return address > 0x7fd7345fe6c0: 0x000000056f49f4e0 0x000000042724f5d0 <-- # String (arg2) | Object (arg3) > 0x7fd7345fe6d0: 0x0000000000000000 0x00007fd740541306 <-- rsp - 0x70 # boolean (arg4) | return address > 0x7fd7345fe6e0: 0x00007fd740541306 0x0000000000000000 > 0x7fd7345fe6f0: 0x000000042724f5d0 0x000000056f49f4e0 > > we have > > 0x7f93cfdfe660: 0x000000042724f5d0 0x00007f93cfdfe750 <-- rsp > 0x7f93cfdfe670: 0xffffffffffffffff 0x00007f93e4acc107 > 0x7f93cfdfe680: 0x00007f9300000000 0x000000042724f5d0 > 0x7f93cfdfe690: 0x000000056f517fb0 0x00007f93dd0002a6 > 0x7f93cfdfe6a0: 0x00007f93d090c8b3 0x0000000000000078 <-- # | sp_inc > 0x7f93cfdfe6b0: 0x00007f93cfdfe750 0xdeadda7adeadda7a <-- rsp - 0x50 # rbp | >>>> bad word <<<< > 0x7f93cfdfe6c0: 0x000000056f49f540 0x000000042724f5d0 <-- # String (arg2) | Object (arg3) > 0x7f93cfdfe6d0: 0x0000000000000000 0x00007f93e4541306 <-- rsp - 0x70 # boolean (arg4) | return address > 0x7f93cfdfe6e0: 0x00007f93e4541306 0x00000... Thanks for review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1839#issuecomment-3709484743 From mchevalier at openjdk.org Mon Jan 5 08:59:10 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Mon, 5 Jan 2026 08:59:10 GMT Subject: [lworld] Integrated: 8372806: [lworld] x64: save bad values instead of rfp and lr above the extension space In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 07:56:27 GMT, Marc Chevalier wrote: > That's the x86 counterpart of [JDK-8371993](https://bugs.openjdk.org/browse/JDK-8371993). > > I've added some comments, using the offsets given in `frame_x86.hpp` to make sure to put the frame start at the right place. In particular, the frame start is 2 pointer sizes under the sender's sp: > > https://github.com/openjdk/valhalla/blob/3c41c2aa442076827cb4480373a1d481e481cdf1/src/hotspot/cpu/x86/frame_x86.hpp#L61-L62 > > Unlike aarch64, with x64 we have only one copy of rbp. As with aarch64, I had to get rid of an assert that can't be checked anymore. A small price to pay. > > Now, in debug, instead of > > pop r13 > sub rsp,0x20 > push r13 > > we have > > pop r13 > sub rsp,0x20 > mov DWORD PTR [rsp-0x4],0xdeadda7a > mov DWORD PTR [rsp-0x8],0xdeadda7a > sub rsp,0x8 > > I've kept the `pop r13` to limit the difference of behavior between debug and product builds: both will overwrite `r13` with the return address, whether it's a good idea or not. > > And at runtime, on my favorite `compiler/valhalla/inlinetypes/CorrectlyRestoreRfp.java` example, instead of the stack: > > 0x7fd7345fe660: 0x000000042724f5d0 0x00007fd7345fe750 <-- rsp > 0x7fd7345fe670: 0xffffffffffffffff 0x00007fd740acc0f7 > 0x7fd7345fe680: 0x00007fd700000000 0x000000042724f5d0 > 0x7fd7345fe690: 0x000000056f517f28 0x00007fd7390002a6 > 0x7fd7345fe6a0: 0x00007fd72c90c8b3 0x0000000000000078 <-- # | sp_inc > 0x7fd7345fe6b0: 0x00007fd7345fe750 0x00007fd740541306 <-- rsp - 0x50 # rbp | return address > 0x7fd7345fe6c0: 0x000000056f49f4e0 0x000000042724f5d0 <-- # String (arg2) | Object (arg3) > 0x7fd7345fe6d0: 0x0000000000000000 0x00007fd740541306 <-- rsp - 0x70 # boolean (arg4) | return address > 0x7fd7345fe6e0: 0x00007fd740541306 0x0000000000000000 > 0x7fd7345fe6f0: 0x000000042724f5d0 0x000000056f49f4e0 > > we have > > 0x7f93cfdfe660: 0x000000042724f5d0 0x00007f93cfdfe750 <-- rsp > 0x7f93cfdfe670: 0xffffffffffffffff 0x00007f93e4acc107 > 0x7f93cfdfe680: 0x00007f9300000000 0x000000042724f5d0 > 0x7f93cfdfe690: 0x000000056f517fb0 0x00007f93dd0002a6 > 0x7f93cfdfe6a0: 0x00007f93d090c8b3 0x0000000000000078 <-- # | sp_inc > 0x7f93cfdfe6b0: 0x00007f93cfdfe750 0xdeadda7adeadda7a <-- rsp - 0x50 # rbp | >>>> bad word <<<< > 0x7f93cfdfe6c0: 0x000000056f49f540 0x000000042724f5d0 <-- # String (arg2) | Object (arg3) > 0x7f93cfdfe6d0: 0x0000000000000000 0x00007f93e4541306 <-- rsp - 0x70 # boolean (arg4) | return address > 0x7f93cfdfe6e0: 0x00007f93e4541306 0x00000... This pull request has now been integrated. Changeset: 328cfbe6 Author: Marc Chevalier URL: https://git.openjdk.org/valhalla/commit/328cfbe659bdbc56411e2a3423ac2a3027bdc515 Stats: 158 lines in 7 files changed: 113 ins; 29 del; 16 mod 8372806: [lworld] x64: save bad values instead of rfp and lr above the extension space Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1839 From thartmann at openjdk.org Mon Jan 5 09:13:46 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 5 Jan 2026 09:13:46 GMT Subject: [lworld] RFR: 8369045: [lworld] valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v9] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 09:43:09 GMT, Damon Fenacci wrote: >> # Issue >> A few test failed intermittently with -Xcomp on Mac due to an unschedulable graph in C2: >> - valhalla/valuetypes/WeakReferenceTest.java >> - valhalla/valuetypes/ProxyTest.java >> - valhalla/valuetypes/ObjectNewInstance.java >> - valhalla/valuetypes/ObjectMethodsViaCondy.java >> >> # Causes >> >> The origin of the issue seems to be coming from strength reduction (`process_late_inline_calls_no_inline`) where we replace virtual and MH calls with direct calls. >> https://github.com/dafedafe/valhalla/blob/75e2dd95df5d847d7d6e35a23016d22705681cf4/src/hotspot/share/opto/compile.cpp#L3072 >> If the return type of the methods are not loaded, we add a call to runtime's `store_inline_type_fields_to_buf` right after the actual method call, to save the scalarized return into a oop. This happens first for the caller at parse time and then for the callee when strength-reducing the virtual call to a direct one. The return projections of the inline fields of the call are added to `store_inline_type_fields_to_buf` and its oop projection is then added as input to the other `store_inline_type_fields_to_buf` which fundamentally leaves the graph around it in an awkward state. >> >> If this happens in combination with loop unswitching it can lead to a graph not being schedulable, which is what happens in the failure of this issue, where we have: >> * a virtual call with a following `store_inline_type_fields_to_buf` (1) in a loop. >> * the loop undergoes unswitching, which creates 2 copies of the body (including a copy of the virtual call). All outputs of the new virtual call are phi-d with the one of the other path as input of the `store_inline_type_fields_to_buf`. >> * the new copy of the virtual call is later replaced with a direct call: the creation of the new direct call adds a `store_inline_type_fields_to_buf` (2) right after the direct call. All the inline type return values of the call being inlined are removed, so the phis now only have one input and are removed by a later GVN pass. >> Screenshot 2025-11-26 at 10 33 51 >> >> * this creates an issue later during GCM since the `store_inline_type_fields_to_buf` (1) call is logically not dominated by any of the 2 sides of the unswitched loop and lands in a separate dominance path of the arguments whose phis have been removed (which are still dominated by the original virtual call). >> >> # Solution >> >> The issue ha... > > Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8369045 remove more tests from problemlist Marked as reviewed by thartmann (Committer). Still good. ------------- PR Review: https://git.openjdk.org/valhalla/pull/1768#pullrequestreview-3626023101 PR Comment: https://git.openjdk.org/valhalla/pull/1768#issuecomment-3709540995 From thartmann at openjdk.org Mon Jan 5 09:14:49 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 5 Jan 2026 09:14:49 GMT Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of JDK-8365996 [v2] In-Reply-To: References: Message-ID: <7eJ34HLEDZKq-lY_-AC3ZD_h1glJZeandmTs8BRzcjE=.d25fbee8-6874-4044-b4db-cdab8d89bd09@github.com> On Fri, 19 Dec 2025 08:44:08 GMT, Marc Chevalier wrote: >> Let's proceed piece by piece. >> >> # `G1BarrierSetAssembler::g1_write_barrier_pre` in `g1BarrierSetAssembler_aarch64.cpp` >> >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp#L216-L220 >> >> `push_call_clobbered_registers`/`pop_call_clobbered_registers` should be enough around a runtime call, that's what clobbered registers are. >> >> But let's dig a bit, that will be useful later! >> >> >> push_call_clobbered_registers() >> => push_call_clobbered_registers_except(exclude = empty set) >> => push(call_clobbered_gp_registers() - exclude, sp) // with exclude = empty set >> >> So, we save at least `call_clobbered_gp_registers` which is defined as: >> >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L3614-L3620 >> >> So, we save r0-r7 and r10-r17 >> >> # `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_aarch64.cpp` >> >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp#L116-L124 >> >> Digging the history looks like it still makes sense, it doesn't look like an accident. If we remove the if-branch, tests are totally on fire. Let's keep it. >> >> # `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_x86.cpp` >> >> Same as before. But it's not even guarantee that `InlineTypePassFieldsAsArgs` is true. We can have such a backtrace: >> >> CardTableBarrierSetAssembler::oop_store_at (cardTableBarrierSetAssembler_x86.cpp:184) >> CardTableBarrierSetAssembler::store_at (cardTableBarrierSetAssembler_x86.cpp:90) >> MacroAssembler::store_heap_oop (macroAssembler_x86.cpp:5515) >> do_oop_store (templateTable_x86.cpp:148) >> (called, for instance, from TemplateTable::putfield_or_static_helper (templateTable_x86.cpp:2964)) >> >> where the last give `r8` for `tmp3`. It is not quite clear to me why we don't have a problem in mainline, because it looks like corrupting address base register is a bad idea given that we use it after. >> >> # `MacroAssembler::unpack_inline_helper` in `macroAssembler_aarch64.cpp` >> >> ## First part >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L7163-L7166 >> >> Yes, these registers are saved, as we saw above! I've added some asserts to mak... > > Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision: > > Pick the right comment again Looks good. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1824#pullrequestreview-3626027393 From dfenacci at openjdk.org Mon Jan 5 09:30:39 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 5 Jan 2026 09:30:39 GMT Subject: [lworld] RFR: 8369045: [lworld] valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v9] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 09:11:21 GMT, Tobias Hartmann wrote: >> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8369045 remove more tests from problemlist > > Still good. Thank you for your review @TobiHartmann! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1768#issuecomment-3709595272 From dfenacci at openjdk.org Mon Jan 5 11:33:08 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 5 Jan 2026 11:33:08 GMT Subject: [lworld] Integrated: 8369045: [lworld] valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph In-Reply-To: References: Message-ID: <1mFW7Drn3JqPCWjAQ_bt9_Txr49JUugcmR4ezKyUyMA=.c07440c2-d2ba-4dc3-acb7-781a270b54a1@github.com> On Tue, 2 Dec 2025 10:36:04 GMT, Damon Fenacci wrote: > # Issue > A few test failed intermittently with -Xcomp on Mac due to an unschedulable graph in C2: > - valhalla/valuetypes/WeakReferenceTest.java > - valhalla/valuetypes/ProxyTest.java > - valhalla/valuetypes/ObjectNewInstance.java > - valhalla/valuetypes/ObjectMethodsViaCondy.java > > # Causes > > The origin of the issue seems to be coming from strength reduction (`process_late_inline_calls_no_inline`) where we replace virtual and MH calls with direct calls. > https://github.com/dafedafe/valhalla/blob/75e2dd95df5d847d7d6e35a23016d22705681cf4/src/hotspot/share/opto/compile.cpp#L3072 > If the return type of the methods are not loaded, we add a call to runtime's `store_inline_type_fields_to_buf` right after the actual method call, to save the scalarized return into a oop. This happens first for the caller at parse time and then for the callee when strength-reducing the virtual call to a direct one. The return projections of the inline fields of the call are added to `store_inline_type_fields_to_buf` and its oop projection is then added as input to the other `store_inline_type_fields_to_buf` which fundamentally leaves the graph around it in an awkward state. > > If this happens in combination with loop unswitching it can lead to a graph not being schedulable, which is what happens in the failure of this issue, where we have: > * a virtual call with a following `store_inline_type_fields_to_buf` (1) in a loop. > * the loop undergoes unswitching, which creates 2 copies of the body (including a copy of the virtual call). All outputs of the new virtual call are phi-d with the one of the other path as input of the `store_inline_type_fields_to_buf`. > * the new copy of the virtual call is later replaced with a direct call: the creation of the new direct call adds a `store_inline_type_fields_to_buf` (2) right after the direct call. All the inline type return values of the call being inlined are removed, so the phis now only have one input and are removed by a later GVN pass. > Screenshot 2025-11-26 at 10 33 51 > > * this creates an issue later during GCM since the `store_inline_type_fields_to_buf` (1) call is logically not dominated by any of the 2 sides of the unswitched loop and lands in a separate dominance path of the arguments whose phis have been removed (which are still dominated by the original virtual call). > > # Solution > > The issue happens only when strength-reducing to a direct ca... This pull request has now been integrated. Changeset: 4ffaf147 Author: Damon Fenacci URL: https://git.openjdk.org/valhalla/commit/4ffaf1477da5e8236cf13a45bff0a760bcf0cea9 Stats: 73 lines in 6 files changed: 27 ins; 11 del; 35 mod 8369045: [lworld] valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1768 From thartmann at openjdk.org Mon Jan 5 12:37:53 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 5 Jan 2026 12:37:53 GMT Subject: [lworld] RFR: 8227588: [lworld] Better optimize non-flattened inline type array accesses In-Reply-To: References: Message-ID: On Thu, 25 Dec 2025 13:35:43 GMT, Quan Anh Mai wrote: > Hi, > > This PR removes all the `// TODO 8227588`. Either the problem has already been solved, or I analysed and changed the `TODO` to a more detailed issue. > > Please kindly review, thanks a lot. test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestBasicFunctionality.java line 382: > 380: @Test > 381: @IR(applyIf = {"UseArrayFlattening", "true"}, > 382: counts = {SCOPE_OBJECT, ">= 1"}) // LOAD_OF_ANY_KLASS, "<= 12"}) // TODO 8372332, 8374331 (loads should be removed) What about setting `test12` to non-(OSR)-compilable before triggering the deopt, i.e. once `!info.isWarmUp()`? This would prevent re-compilation. You can get the method via the `info` object. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1855#discussion_r2661346390 From thartmann at openjdk.org Mon Jan 5 14:02:53 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 5 Jan 2026 14:02:53 GMT Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into ciRefArrayKlass and ciFlatArrayKlass [v3] In-Reply-To: References: Message-ID: <-z0AzsWeHMmrE60SgW0_q5pEc2i60_yCL5U3T0rIewI=.15389e76-c470-47ec-a535-4b46b4f790c3@github.com> On Fri, 19 Dec 2025 03:10:43 GMT, Quan Anh Mai wrote: >> Hi, >> >> This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM. >> >> Please kindly review, thanks a lot. > > Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - wrong value is passed as flat > - remove redundant changes > - Merge branch 'lworld' into ciRefArray > - Revert "can only infer klass if exact" > > This reverts commit be6143624d30c9ebfa560dd8161aa70270c68d24. > - can only infer klass if exact > - Refactor ciObjArrayKlass to align with the VM type Looks good to me otherwise. Thanks! src/hotspot/share/opto/type.cpp line 3700: > 3698: _is_ptr_to_narrowoop = UseCompressedOops && ::is_reference_type(field_bt); > 3699: } else if (klass()->is_obj_array_klass()) { > 3700: _is_ptr_to_narrowoop = UseCompressedOops; `UseCompressedOops` is always true here, right? It's checked in line 3685. Also above. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1739#pullrequestreview-3626791751 PR Review Comment: https://git.openjdk.org/valhalla/pull/1739#discussion_r2661457384 From fparain at openjdk.org Mon Jan 5 14:31:50 2026 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 5 Jan 2026 14:31:50 GMT Subject: [lworld] RFR: 8373708: [lworld] InstanceKlass::null_marker_offset(int i) is misleading In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 21:16:36 GMT, Stefan Karlsson wrote: >> Please review this very small change to rename InstanceKlass::null_marker_offset(int i) into InstanceKlass::field_null_marker_offset(int i) to highlight the fact that the method returns the null marker offset of a given field and not the null marker offset for the current class. >> >> Thank you. >> >> Fred > > Looks good. Thanks for fixing! Thanks @stefank for the review. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1835#issuecomment-3710663861 From mcimadamore at openjdk.org Mon Jan 5 15:09:49 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Jan 2026 15:09:49 GMT Subject: RFR: remove support for LooselyConsistentValue [v2] In-Reply-To: References: <1uCiTfUk2Sa2D6t1i1kZHF2bL_ra-smSVPfSIxKQtOU=.e49ac876-23ed-4a82-b491-c96fa47dc359@github.com> Message-ID: <6cMz-_kzqm_VuBB-SHAf_9kFrus2Rw8FmWEVCU-n460=.135a1df0-2d69-478a-8627-6b8a2c673452@github.com> On Fri, 2 Jan 2026 21:40:36 GMT, Vicente Romero wrote: >> very simple PR, removing a remaining reference to interface LooselyConsistentValue > > Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'remove.support.looselyConsistentValueType' of https://github.com/vicente-romero-oracle/valhalla into remove.support.looselyConsistentValueType > - remove support for LooselyConsistentValue Marked as reviewed by mcimadamore (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1856#pullrequestreview-3627220618 From coleenp at openjdk.org Mon Jan 5 15:21:01 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 5 Jan 2026 15:21:01 GMT Subject: [lworld] RFR: 8373708: [lworld] InstanceKlass::null_marker_offset(int i) is misleading In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 20:32:27 GMT, Frederic Parain wrote: > Please review this very small change to rename InstanceKlass::null_marker_offset(int i) into InstanceKlass::field_null_marker_offset(int i) to highlight the fact that the method returns the null marker offset of a given field and not the null marker offset for the current class. > > Thank you. > > Fred Looks good! ------------- Marked as reviewed by coleenp (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1835#pullrequestreview-3627261286 From fparain at openjdk.org Mon Jan 5 15:57:09 2026 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 5 Jan 2026 15:57:09 GMT Subject: [lworld] RFR: 8373708: [lworld] InstanceKlass::null_marker_offset(int i) is misleading In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 15:17:19 GMT, Coleen Phillimore wrote: >> Please review this very small change to rename InstanceKlass::null_marker_offset(int i) into InstanceKlass::field_null_marker_offset(int i) to highlight the fact that the method returns the null marker offset of a given field and not the null marker offset for the current class. >> >> Thank you. >> >> Fred > > Looks good! Thanks @coleenp for the review. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1835#issuecomment-3710998479 From fparain at openjdk.org Mon Jan 5 15:57:11 2026 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 5 Jan 2026 15:57:11 GMT Subject: [lworld] Integrated: 8373708: [lworld] InstanceKlass::null_marker_offset(int i) is misleading In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 20:32:27 GMT, Frederic Parain wrote: > Please review this very small change to rename InstanceKlass::null_marker_offset(int i) into InstanceKlass::field_null_marker_offset(int i) to highlight the fact that the method returns the null marker offset of a given field and not the null marker offset for the current class. > > Thank you. > > Fred This pull request has now been integrated. Changeset: 90dfb439 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/90dfb4391ad964f21d2af23f978931b97e751380 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8373708: [lworld] InstanceKlass::null_marker_offset(int i) is misleading Reviewed-by: stefank, coleenp ------------- PR: https://git.openjdk.org/valhalla/pull/1835 From rriggs at openjdk.org Mon Jan 5 17:16:15 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 5 Jan 2026 17:16:15 GMT Subject: [lworld] RFR: 8373930: [lworld] Restore Objects.equals use of identity check In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 21:23:00 GMT, Roger Riggs wrote: > Revert "8366841: [lworld] Objects.equals without identity comparison". (Almost all) > Removing the condition on --enable-preview. > Correct the .equals method in test SimplValueGraphs.SimpleValue. If you are looking for something easy to get started in the new year, consider reviewing this backout restoring Object.equals to its previous implementation. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1836#issuecomment-3711335903 From vromero at openjdk.org Mon Jan 5 17:54:22 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 5 Jan 2026 17:54:22 GMT Subject: RFR: remove support for LooselyConsistentValue [v2] In-Reply-To: References: <1uCiTfUk2Sa2D6t1i1kZHF2bL_ra-smSVPfSIxKQtOU=.e49ac876-23ed-4a82-b491-c96fa47dc359@github.com> Message-ID: <56LVnl_cQaud_ALoK5GmDuIvpQ9mQaOd4BT6i3sYP1Y=.eaf2a437-09cb-4aab-beb9-0b237377aa5f@github.com> On Fri, 2 Jan 2026 21:40:36 GMT, Vicente Romero wrote: >> very simple PR, removing a remaining reference to interface LooselyConsistentValue > > Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'remove.support.looselyConsistentValueType' of https://github.com/vicente-romero-oracle/valhalla into remove.support.looselyConsistentValueType > - remove support for LooselyConsistentValue thanks for the reviews ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1856#issuecomment-3711470561 From vromero at openjdk.org Mon Jan 5 17:54:24 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 5 Jan 2026 17:54:24 GMT Subject: Integrated: remove support for LooselyConsistentValue In-Reply-To: <1uCiTfUk2Sa2D6t1i1kZHF2bL_ra-smSVPfSIxKQtOU=.e49ac876-23ed-4a82-b491-c96fa47dc359@github.com> References: <1uCiTfUk2Sa2D6t1i1kZHF2bL_ra-smSVPfSIxKQtOU=.e49ac876-23ed-4a82-b491-c96fa47dc359@github.com> Message-ID: On Fri, 2 Jan 2026 20:56:24 GMT, Vicente Romero wrote: > very simple PR, removing a remaining reference to interface LooselyConsistentValue This pull request has now been integrated. Changeset: 15db720b Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/15db720b51dd18768dc59cc691fe512e774d36b1 Stats: 67 lines in 2 files changed: 0 ins; 67 del; 0 mod remove support for LooselyConsistentValue Reviewed-by: liach, jbhateja, mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1856 From mcimadamore at openjdk.org Mon Jan 5 17:56:29 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Jan 2026 17:56:29 GMT Subject: RFR: 8374545: Drop logic for unchecked nullness conversions Message-ID: This PR removes the recursive checks for nullness conversions. We might need more warnings in the future, but of a much simpler kind, so the best way forward is to restore the code in `Types` and `Check` closer to what's in mainline, and take it from there. I've left two changes: * the sutyping test from `null` to `Foo!` still fails * a cast from `null` to `Foo!` still fails We might want to detune these as warnings (or not). ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/valhalla/pull/1857/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1857&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374545 Stats: 250 lines in 7 files changed: 3 ins; 206 del; 41 mod Patch: https://git.openjdk.org/valhalla/pull/1857.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1857/head:pull/1857 PR: https://git.openjdk.org/valhalla/pull/1857 From vromero at openjdk.org Mon Jan 5 18:09:22 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 5 Jan 2026 18:09:22 GMT Subject: RFR: 8374545: Drop logic for unchecked nullness conversions In-Reply-To: References: Message-ID: <-eWm6gWTOUf4W0ZlRPL360uV3t9ZCORbr_1FZzNQ93g=.97f269b9-9576-4a3b-8031-a48f334894c0@github.com> On Mon, 5 Jan 2026 17:48:00 GMT, Maurizio Cimadamore wrote: > This PR removes the recursive checks for nullness conversions. > We might need more warnings in the future, but of a much simpler kind, so the best way forward is to restore the code in `Types` and `Check` closer to what's in mainline, and take it from there. > > I've left two changes: > * the sutyping test from `null` to `Foo!` still fails > * a cast from `null` to `Foo!` still fails > > We might want to detune these as warnings (or not). lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1857#pullrequestreview-3627916923 From mcimadamore at openjdk.org Mon Jan 5 18:42:14 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Jan 2026 18:42:14 GMT Subject: Integrated: 8374545: Drop logic for unchecked nullness conversions In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 17:48:00 GMT, Maurizio Cimadamore wrote: > This PR removes the recursive checks for nullness conversions. > We might need more warnings in the future, but of a much simpler kind, so the best way forward is to restore the code in `Types` and `Check` closer to what's in mainline, and take it from there. > > I've left two changes: > * the sutyping test from `null` to `Foo!` still fails > * a cast from `null` to `Foo!` still fails > > We might want to detune these as warnings (or not). This pull request has now been integrated. Changeset: 8dd9ea1f Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/8dd9ea1fcff8bb5d3ce5853069754bd360fb5a7b Stats: 250 lines in 7 files changed: 3 ins; 206 del; 41 mod 8374545: Drop logic for unchecked nullness conversions Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1857 From mcimadamore at openjdk.org Mon Jan 5 19:16:34 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Jan 2026 19:16:34 GMT Subject: RFR: Remove spurious code Message-ID: This PR removes some spurious leftover code after previous cleanup rounds. ------------- Commit messages: - Remove spurious code Changes: https://git.openjdk.org/valhalla/pull/1858/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1858&range=00 Stats: 33 lines in 2 files changed: 4 ins; 23 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/1858.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1858/head:pull/1858 PR: https://git.openjdk.org/valhalla/pull/1858 From mcimadamore at openjdk.org Tue Jan 6 11:30:48 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 6 Jan 2026 11:30:48 GMT Subject: Integrated: Remove spurious code In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 19:08:38 GMT, Maurizio Cimadamore wrote: > This PR removes some spurious leftover code after previous cleanup rounds. This pull request has now been integrated. Changeset: 1768201f Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/1768201f1c60cf90217c155c0cefc8a6dc07771b Stats: 33 lines in 2 files changed: 4 ins; 23 del; 6 mod Remove spurious code ------------- PR: https://git.openjdk.org/valhalla/pull/1858 From qamai at openjdk.org Tue Jan 6 12:05:19 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 6 Jan 2026 12:05:19 GMT Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into ciRefArrayKlass and ciFlatArrayKlass [v3] In-Reply-To: <-z0AzsWeHMmrE60SgW0_q5pEc2i60_yCL5U3T0rIewI=.15389e76-c470-47ec-a535-4b46b4f790c3@github.com> References: <-z0AzsWeHMmrE60SgW0_q5pEc2i60_yCL5U3T0rIewI=.15389e76-c470-47ec-a535-4b46b4f790c3@github.com> Message-ID: <85Z-Id5SmKp5N-UP6HHfOsuflhbHwSsUgUS8n7Lg6OQ=.506f6889-7823-4c45-a09e-0646ee7621bd@github.com> On Mon, 5 Jan 2026 13:13:05 GMT, Tobias Hartmann wrote: >> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - wrong value is passed as flat >> - remove redundant changes >> - Merge branch 'lworld' into ciRefArray >> - Revert "can only infer klass if exact" >> >> This reverts commit be6143624d30c9ebfa560dd8161aa70270c68d24. >> - can only infer klass if exact >> - Refactor ciObjArrayKlass to align with the VM type > > src/hotspot/share/opto/type.cpp line 3700: > >> 3698: _is_ptr_to_narrowoop = UseCompressedOops && ::is_reference_type(field_bt); >> 3699: } else if (klass()->is_obj_array_klass()) { >> 3700: _is_ptr_to_narrowoop = UseCompressedOops; > > `UseCompressedOops` is always true here, right? It's checked in line 3685. Also above. You are right, I have removed those check. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1739#discussion_r2664699458 From qamai at openjdk.org Tue Jan 6 12:05:16 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 6 Jan 2026 12:05:16 GMT Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into ciRefArrayKlass and ciFlatArrayKlass [v4] In-Reply-To: References: Message-ID: <8bfIn8vSydy4KqoAISTGEHENjH4mY7M2NwoVvUnvGAg=.c94b1449-1b6b-41a9-b5b9-38217e18ead6@github.com> > Hi, > > This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM. > > Please kindly review, thanks a lot. Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Remove unnecessary UseCompressedOops checks - Merge branch 'lworld' into ciRefArray - wrong value is passed as flat - remove redundant changes - Merge branch 'lworld' into ciRefArray - Revert "can only infer klass if exact" This reverts commit be6143624d30c9ebfa560dd8161aa70270c68d24. - can only infer klass if exact - Refactor ciObjArrayKlass to align with the VM type ------------- Changes: https://git.openjdk.org/valhalla/pull/1739/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1739&range=03 Stats: 316 lines in 15 files changed: 110 ins; 146 del; 60 mod Patch: https://git.openjdk.org/valhalla/pull/1739.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1739/head:pull/1739 PR: https://git.openjdk.org/valhalla/pull/1739 From vromero at openjdk.org Tue Jan 6 12:34:53 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 6 Jan 2026 12:34:53 GMT Subject: RFR: 8374149: [bworld] Define and use new null checking API Message-ID: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> Definition and use of a new null checking API ------------- Commit messages: - minor changes - additional changes to Checks - Merge branch 'bworld' into JDK-8374149 - additional changes - Merge branch 'bworld' into JDK-8374149 - 8374149: [bworld] Define and use new null checking API Changes: https://git.openjdk.org/valhalla/pull/1859/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1859&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374149 Stats: 206 lines in 12 files changed: 196 ins; 0 del; 10 mod Patch: https://git.openjdk.org/valhalla/pull/1859.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1859/head:pull/1859 PR: https://git.openjdk.org/valhalla/pull/1859 From thartmann at openjdk.org Tue Jan 6 12:46:39 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Jan 2026 12:46:39 GMT Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into ciRefArrayKlass and ciFlatArrayKlass [v4] In-Reply-To: <8bfIn8vSydy4KqoAISTGEHENjH4mY7M2NwoVvUnvGAg=.c94b1449-1b6b-41a9-b5b9-38217e18ead6@github.com> References: <8bfIn8vSydy4KqoAISTGEHENjH4mY7M2NwoVvUnvGAg=.c94b1449-1b6b-41a9-b5b9-38217e18ead6@github.com> Message-ID: On Tue, 6 Jan 2026 12:05:16 GMT, Quan Anh Mai wrote: >> Hi, >> >> This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM. >> >> Please kindly review, thanks a lot. > > Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Remove unnecessary UseCompressedOops checks > - Merge branch 'lworld' into ciRefArray > - wrong value is passed as flat > - remove redundant changes > - Merge branch 'lworld' into ciRefArray > - Revert "can only infer klass if exact" > > This reverts commit be6143624d30c9ebfa560dd8161aa70270c68d24. > - can only infer klass if exact > - Refactor ciObjArrayKlass to align with the VM type Thanks, looks good! ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1739#pullrequestreview-3630763726 From thartmann at openjdk.org Tue Jan 6 14:10:22 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Jan 2026 14:10:22 GMT Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail with --enable-preview [v3] In-Reply-To: References: Message-ID: <3qK40m4t2yaK4SG7lPSaoxT3Z5kwuwy1LJjIFqhoH5g=.1a02b2fa-27fa-4589-81ab-3271c6a63532@github.com> On Fri, 19 Dec 2025 12:03:47 GMT, Marc Chevalier wrote: >> src/hotspot/share/ci/ciFlatArray.cpp line 47: >> >>> 45: } >>> 46: >>> 47: ciConstant ciFlatArray::check_constant_null_marker_cache(int off) { >> >> Do we really need a cache here? > > Maybe? I read > https://github.com/openjdk/valhalla/blob/69399cedf6fe208832a66c134d370af860154bc2/src/hotspot/share/ci/ciObject.hpp#L62-L63 > and > https://github.com/openjdk/valhalla/blob/69399cedf6fe208832a66c134d370af860154bc2/src/hotspot/share/ci/ciObject.cpp#L173-L175 > > It seems to be more a correctness thing than a performance matter. It couldn't see why I wouldn't have a similar risk. Ah, right, that makes sense! >> src/hotspot/share/ci/ciInstance.cpp line 106: >> >>> 104: // Constant value of the null marker. >>> 105: ciConstant ciInstance::null_marker_value() { >>> 106: if (!klass()->is_inlinetype()) { >> >> Should this be an assert? > > Matter of point of view. I prefer to have the semantics > > if inlinetype => get the null marker > else return invalid constant (since it doesn't make sense). > > rather than > > check is inline type > get null marker > > At call site, in the first case, I need to > > nm = inst->null_marker_value(); > nm is true? (might be false or invalid) > > in the second, I need to do > > is inst an inline type? > if so, nm = inst->null_marker_value(); > nm is true? (might be false, but not invalid) > > > I prefer the first pattern, it's rather safer, and I think a lot of the code involving ciConstant have this behavior of "you get the constant if I can, otherwise, you get invalid". Okay, fine with me! >> test/hotspot/jtreg/compiler/c2/irTests/stable/StableRefPlainTest.java line 82: >> >>> 80: @IR(counts = { IRNode.LOAD, ">0" }) >>> 81: @IR(applyIf = {"enable-valhalla", "false"}, failOn = { IRNode.MEMBAR }) >>> 82: @IR(applyIf = {"enable-valhalla", "true"}, counts = { IRNode.MEMBAR, ">0" }) >> >> This needs a comment explaining why barriers are sometimes observed. > > I agree. The problem is that you told me it's expected, but I forgot the reason. Did you remember what the problem was? :) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2665042458 PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2665038338 PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2665034327 From qamai at openjdk.org Tue Jan 6 14:14:03 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 6 Jan 2026 14:14:03 GMT Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into ciRefArrayKlass and ciFlatArrayKlass [v4] In-Reply-To: <8bfIn8vSydy4KqoAISTGEHENjH4mY7M2NwoVvUnvGAg=.c94b1449-1b6b-41a9-b5b9-38217e18ead6@github.com> References: <8bfIn8vSydy4KqoAISTGEHENjH4mY7M2NwoVvUnvGAg=.c94b1449-1b6b-41a9-b5b9-38217e18ead6@github.com> Message-ID: On Tue, 6 Jan 2026 12:05:16 GMT, Quan Anh Mai wrote: >> Hi, >> >> This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM. >> >> Please kindly review, thanks a lot. > > Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Remove unnecessary UseCompressedOops checks > - Merge branch 'lworld' into ciRefArray > - wrong value is passed as flat > - remove redundant changes > - Merge branch 'lworld' into ciRefArray > - Revert "can only infer klass if exact" > > This reverts commit be6143624d30c9ebfa560dd8161aa70270c68d24. > - can only infer klass if exact > - Refactor ciObjArrayKlass to align with the VM type Thanks a lot for your reviews! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1739#issuecomment-3714840726 From qamai at openjdk.org Tue Jan 6 14:14:05 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 6 Jan 2026 14:14:05 GMT Subject: [lworld] Integrated: 8370880: [lworld] Split ciObjArrayKlass into ciRefArrayKlass and ciFlatArrayKlass In-Reply-To: References: Message-ID: On Sat, 15 Nov 2025 10:54:41 GMT, Quan Anh Mai wrote: > Hi, > > This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM. > > Please kindly review, thanks a lot. This pull request has now been integrated. Changeset: 9aff0ae2 Author: Quan Anh Mai URL: https://git.openjdk.org/valhalla/commit/9aff0ae28ed419f4a0c9a98bbb85f44b011aac38 Stats: 316 lines in 15 files changed: 110 ins; 146 del; 60 mod 8370880: [lworld] Split ciObjArrayKlass into ciRefArrayKlass and ciFlatArrayKlass Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1739 From vromero at openjdk.org Tue Jan 6 15:09:39 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 6 Jan 2026 15:09:39 GMT Subject: RFR: 8374149: [bworld] Define and use new null checking API [v2] In-Reply-To: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> References: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> Message-ID: > Definition and use of a new null checking API Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: additional changes ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1859/files - new: https://git.openjdk.org/valhalla/pull/1859/files/08578c30..352e73a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1859&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1859&range=00-01 Stats: 43 lines in 11 files changed: 0 ins; 34 del; 9 mod Patch: https://git.openjdk.org/valhalla/pull/1859.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1859/head:pull/1859 PR: https://git.openjdk.org/valhalla/pull/1859 From vromero at openjdk.org Tue Jan 6 15:56:21 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 6 Jan 2026 15:56:21 GMT Subject: RFR: Remove spurious code In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 19:08:38 GMT, Maurizio Cimadamore wrote: > This PR removes some spurious leftover code after previous cleanup rounds. nice ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1858#issuecomment-3715236591 From qamai at openjdk.org Tue Jan 6 16:39:50 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 6 Jan 2026 16:39:50 GMT Subject: [lworld] RFR: 8227588: [lworld] Better optimize non-flattened inline type array accesses [v2] In-Reply-To: References: Message-ID: > Hi, > > This PR removes all the `// TODO 8227588`. Either the problem has already been solved, or I analysed and changed the `TODO` to a more detailed issue. > > Please kindly review, thanks a lot. Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - disable OSR compilation to avoid recompilation - Merge branch 'lworld' into 8227588 - Fix JDK-8227588 ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1855/files - new: https://git.openjdk.org/valhalla/pull/1855/files/30e85dc3..7468f715 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1855&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1855&range=00-01 Stats: 18107 lines in 675 files changed: 11696 ins; 2488 del; 3923 mod Patch: https://git.openjdk.org/valhalla/pull/1855.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1855/head:pull/1855 PR: https://git.openjdk.org/valhalla/pull/1855 From qamai at openjdk.org Tue Jan 6 17:08:00 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 6 Jan 2026 17:08:00 GMT Subject: [lworld] RFR: 8227588: [lworld] Better optimize non-flattened inline type array accesses [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 12:32:49 GMT, Tobias Hartmann wrote: >> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - disable OSR compilation to avoid recompilation >> - Merge branch 'lworld' into 8227588 >> - Fix JDK-8227588 > > test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestBasicFunctionality.java line 382: > >> 380: @Test >> 381: @IR(applyIf = {"UseArrayFlattening", "true"}, >> 382: counts = {SCOPE_OBJECT, ">= 1"}) // LOAD_OF_ANY_KLASS, "<= 12"}) // TODO 8372332, 8374331 (loads should be removed) > > What about setting `test12` to non-(OSR)-compilable before triggering the deopt, i.e. once `!info.isWarmUp()`? This would prevent re-compilation. You can get the method via the `info` object. That is a good idea! ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1855#discussion_r2665623693 From vromero at openjdk.org Tue Jan 6 17:58:04 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 6 Jan 2026 17:58:04 GMT Subject: RFR: 8374149: [bworld] Define and use new null checking API [v3] In-Reply-To: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> References: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> Message-ID: > Definition and use of a new null checking API Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: adding a flag ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1859/files - new: https://git.openjdk.org/valhalla/pull/1859/files/352e73a3..43b44fff Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1859&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1859&range=01-02 Stats: 62 lines in 12 files changed: 53 ins; 0 del; 9 mod Patch: https://git.openjdk.org/valhalla/pull/1859.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1859/head:pull/1859 PR: https://git.openjdk.org/valhalla/pull/1859 From mcimadamore at openjdk.org Tue Jan 6 18:21:26 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 6 Jan 2026 18:21:26 GMT Subject: RFR: 8374633: Bang in signatures should go before the type Message-ID: This PR tweaks signature generation so that bangs are added before the type being restricted, not after. After fixing this I realized that no test was failing :-) so I added a separate compilation test to test `ClassReader`. The test revealed some gaps in parsing of generic type test patterns with null-restriction, which I have fixed. Also, the test revealed issues with type substitution, as type substitution was not preserving the null-restrictions in the "from" types. This is also now fixed. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/valhalla/pull/1860/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1860&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374633 Stats: 121 lines in 7 files changed: 100 ins; 15 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/1860.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1860/head:pull/1860 PR: https://git.openjdk.org/valhalla/pull/1860 From vromero at openjdk.org Tue Jan 6 18:24:59 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 6 Jan 2026 18:24:59 GMT Subject: RFR: 8374633: Bang in signatures should go before the type In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 18:12:56 GMT, Maurizio Cimadamore wrote: > This PR tweaks signature generation so that bangs are added before the type being restricted, not after. > > After fixing this I realized that no test was failing :-) so I added a separate compilation test to test `ClassReader`. > The test revealed some gaps in parsing of generic type test patterns with null-restriction, which I have fixed. > > Also, the test revealed issues with type substitution, as type substitution was not preserving the null-restrictions in the "from" types. This is also now fixed. lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1860#pullrequestreview-3631994103 From mcimadamore at openjdk.org Tue Jan 6 18:30:43 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 6 Jan 2026 18:30:43 GMT Subject: Integrated: 8374633: Bang in signatures should go before the type In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 18:12:56 GMT, Maurizio Cimadamore wrote: > This PR tweaks signature generation so that bangs are added before the type being restricted, not after. > > After fixing this I realized that no test was failing :-) so I added a separate compilation test to test `ClassReader`. > The test revealed some gaps in parsing of generic type test patterns with null-restriction, which I have fixed. > > Also, the test revealed issues with type substitution, as type substitution was not preserving the null-restrictions in the "from" types. This is also now fixed. This pull request has now been integrated. Changeset: 15ad4769 Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/15ad476921b66b66c095036bc61a05a5c998ee65 Stats: 121 lines in 7 files changed: 100 ins; 15 del; 6 mod 8374633: Bang in signatures should go before the type Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1860 From vromero at openjdk.org Tue Jan 6 19:58:10 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 6 Jan 2026 19:58:10 GMT Subject: RFR: 8374149: [bworld] Define and use new null checking API [v4] In-Reply-To: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> References: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> Message-ID: > Definition and use of a new null checking API Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - Merge branch 'bworld' into JDK-8374149 - adding a flag - additional changes - minor changes - additional changes to Checks - Merge branch 'bworld' into JDK-8374149 - additional changes - Merge branch 'bworld' into JDK-8374149 - 8374149: [bworld] Define and use new null checking API ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1859/files - new: https://git.openjdk.org/valhalla/pull/1859/files/43b44fff..c305e470 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1859&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1859&range=02-03 Stats: 154 lines in 9 files changed: 104 ins; 38 del; 12 mod Patch: https://git.openjdk.org/valhalla/pull/1859.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1859/head:pull/1859 PR: https://git.openjdk.org/valhalla/pull/1859 From thartmann at openjdk.org Wed Jan 7 06:15:39 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 7 Jan 2026 06:15:39 GMT Subject: [lworld] RFR: 8227588: [lworld] Better optimize non-flattened inline type array accesses [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 16:39:50 GMT, Quan Anh Mai wrote: >> Hi, >> >> This PR removes all the `// TODO 8227588`. Either the problem has already been solved, or I analysed and changed the `TODO` to a more detailed issue. >> >> Please kindly review, thanks a lot. > > Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - disable OSR compilation to avoid recompilation > - Merge branch 'lworld' into 8227588 > - Fix JDK-8227588 Nice, looks good to me! ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1855#pullrequestreview-3633482723 From qamai at openjdk.org Wed Jan 7 07:49:14 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 7 Jan 2026 07:49:14 GMT Subject: [lworld] RFR: 8227588: [lworld] Better optimize non-flattened inline type array accesses [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 16:39:50 GMT, Quan Anh Mai wrote: >> Hi, >> >> This PR removes all the `// TODO 8227588`. Either the problem has already been solved, or I analysed and changed the `TODO` to a more detailed issue. >> >> Please kindly review, thanks a lot. > > Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - disable OSR compilation to avoid recompilation > - Merge branch 'lworld' into 8227588 > - Fix JDK-8227588 Thanks a lot for your review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1855#issuecomment-3717688606 From qamai at openjdk.org Wed Jan 7 07:49:15 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 7 Jan 2026 07:49:15 GMT Subject: [lworld] Integrated: 8227588: [lworld] Better optimize non-flattened inline type array accesses In-Reply-To: References: Message-ID: On Thu, 25 Dec 2025 13:35:43 GMT, Quan Anh Mai wrote: > Hi, > > This PR removes all the `// TODO 8227588`. Either the problem has already been solved, or I analysed and changed the `TODO` to a more detailed issue. > > Please kindly review, thanks a lot. This pull request has now been integrated. Changeset: 3ebdebfd Author: Quan Anh Mai URL: https://git.openjdk.org/valhalla/commit/3ebdebfdf7865169293a47de4b1b1dca791621e4 Stats: 12 lines in 3 files changed: 7 ins; 2 del; 3 mod 8227588: [lworld] Better optimize non-flattened inline type array accesses Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1855 From mchevalier at openjdk.org Wed Jan 7 09:48:59 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 7 Jan 2026 09:48:59 GMT Subject: [lworld] RFR: 8371726: [lworld] Re-enable verification once JDK-8371716 is solved Message-ID: Simply reverts [JDK-8367245](https://bugs.openjdk.org/browse/JDK-8367245) / 409f56a757145bf59ba17c9975c0dab2c01eef5b since the real mainline fix [JDK-8371716](https://bugs.openjdk.org/browse/JDK-8371716) / 76e79dbb3eca5589aae6852c8f55adf0759c714e landed in Valhalla with https://github.com/openjdk/valhalla/pull/1843 (merge jdk-27+3). Thanks, Marc ------------- Commit messages: - Update copyright - Revert "8367245: [lworld] C2 compilation fails with "Missed optimization opportunity in PhaseIterGVN"" Changes: https://git.openjdk.org/valhalla/pull/1861/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1861&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371726 Stats: 8 lines in 4 files changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1861.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1861/head:pull/1861 PR: https://git.openjdk.org/valhalla/pull/1861 From duke at openjdk.org Wed Jan 7 10:07:26 2026 From: duke at openjdk.org (duke) Date: Wed, 7 Jan 2026 10:07:26 GMT Subject: [lworld] RFR: 8374093: [lworld] Cleanup and polish around vgetfield/vputfield [v2] In-Reply-To: References: Message-ID: <3QnELgVjaWAMJlI6NdMJePvf3_Q6cameRsn67mSzvrQ=.b01127e2-70df-4f2a-8b6f-ab6f8041f9b0@github.com> On Fri, 19 Dec 2025 14:33:13 GMT, Joel Sikstr?m wrote: >> Hello, >> >> I've been looking at the new internal bytecodes vgetfield and vputfield and their callchains from the interpreter down to InlineKlass and have some cleanups. I've not looked at templateTable_x86 so far, only templateTable_aarch64. >> >> Some notes: >> * The `dest_is_initialized` parameter in InlineKlass::write_value_to_addr is `true` for all callers, so I've removed it and inlined `true` to the call to `copy_payload_to_addr`. >> * There seems to be an unnecessary `mark_payload_as_non_null((address)src);` in InlineKlass::copy_payload_to_addr, as the payload should already be non_null if it doesn't match `is_payload_marked_as_null` in the if-statement just above. >> >> Testing: >> * hotspot_valhalla, jdk_valhalla and tier1 > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > More cleanup @jsikstro Your change (at version d34e3efb627cac6ed98c898f5c6c27c84186dc2c) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1840#issuecomment-3718131616 From jsikstro at openjdk.org Wed Jan 7 10:07:24 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 7 Jan 2026 10:07:24 GMT Subject: [lworld] RFR: 8374093: [lworld] Cleanup and polish around vgetfield/vputfield [v3] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 16:07:30 GMT, Frederic Parain wrote: >> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'lworld' into JDK-8374093_vputgetfield_cleanups >> - More cleanup >> - 8374093: [lworld] Cleanup and polish around vgetfield/vputfield > > LGTM. > Thank you for this cleanup. Merged with the tip of lworld, no conflicts. I also re-ran hotspot_valhalla locally on my aarch64 Mac, which looks good. Thank you for the review @fparain! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1840#issuecomment-3718127258 From jsikstro at openjdk.org Wed Jan 7 10:07:22 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 7 Jan 2026 10:07:22 GMT Subject: [lworld] RFR: 8374093: [lworld] Cleanup and polish around vgetfield/vputfield [v3] In-Reply-To: References: Message-ID: > Hello, > > I've been looking at the new internal bytecodes vgetfield and vputfield and their callchains from the interpreter down to InlineKlass and have some cleanups. I've not looked at templateTable_x86 so far, only templateTable_aarch64. > > Some notes: > * The `dest_is_initialized` parameter in InlineKlass::write_value_to_addr is `true` for all callers, so I've removed it and inlined `true` to the call to `copy_payload_to_addr`. > * There seems to be an unnecessary `mark_payload_as_non_null((address)src);` in InlineKlass::copy_payload_to_addr, as the payload should already be non_null if it doesn't match `is_payload_marked_as_null` in the if-statement just above. > > Testing: > * hotspot_valhalla, jdk_valhalla and tier1 Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'lworld' into JDK-8374093_vputgetfield_cleanups - More cleanup - 8374093: [lworld] Cleanup and polish around vgetfield/vputfield ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1840/files - new: https://git.openjdk.org/valhalla/pull/1840/files/e1f1ffa6..d34e3efb Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1840&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1840&range=01-02 Stats: 18264 lines in 685 files changed: 11712 ins; 2578 del; 3974 mod Patch: https://git.openjdk.org/valhalla/pull/1840.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1840/head:pull/1840 PR: https://git.openjdk.org/valhalla/pull/1840 From chagedorn at openjdk.org Wed Jan 7 10:15:10 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 7 Jan 2026 10:15:10 GMT Subject: [lworld] RFR: 8371726: [lworld] Re-enable verification once JDK-8371716 is solved In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 09:36:56 GMT, Marc Chevalier wrote: > Simply reverts [JDK-8367245](https://bugs.openjdk.org/browse/JDK-8367245) / 409f56a757145bf59ba17c9975c0dab2c01eef5b > since the real mainline fix [JDK-8371716](https://bugs.openjdk.org/browse/JDK-8371716) / 76e79dbb3eca5589aae6852c8f55adf0759c714e landed in Valhalla with https://github.com/openjdk/valhalla/pull/1843 (merge jdk-27+3). > > Thanks, > Marc Looks good, thanks! ------------- Marked as reviewed by chagedorn (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1861#pullrequestreview-3634190515 From mchevalier at openjdk.org Wed Jan 7 10:18:32 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 7 Jan 2026 10:18:32 GMT Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of JDK-8365996 [v3] In-Reply-To: References: Message-ID: > Let's proceed piece by piece. > > # `G1BarrierSetAssembler::g1_write_barrier_pre` in `g1BarrierSetAssembler_aarch64.cpp` > > https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp#L216-L220 > > `push_call_clobbered_registers`/`pop_call_clobbered_registers` should be enough around a runtime call, that's what clobbered registers are. > > But let's dig a bit, that will be useful later! > > > push_call_clobbered_registers() > => push_call_clobbered_registers_except(exclude = empty set) > => push(call_clobbered_gp_registers() - exclude, sp) // with exclude = empty set > > So, we save at least `call_clobbered_gp_registers` which is defined as: > > https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L3614-L3620 > > So, we save r0-r7 and r10-r17 > > # `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_aarch64.cpp` and `cardTableBarrierSetAssembler_x86.cpp` > > https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp#L116-L124 > > Digging the history, it seems it was added to fix a corruption of `dst.base()`. Yet, it might not be always necessary. It's rather nicer to save where it matter that the register is not corrupted than all the way down. So, there are a few such places: > > - `gen_c2i_adapter_helper` in `sharedRuntime_x86_64.cpp` > `gen_c2i_adapter_helper` calls `store_heap_oop` that can corrupts `to.base()`. `gen_c2i_adapter_helper` is called, for instance from `gen_c2i_adapter`: > https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1069-L1070 > where we can see that `to.base()` is `r14`, which is set > https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1026 > before the loop enclosing the call to `gen_c2i_adapter_helper` > https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1036 > If we do more than one iteration of this loop when entering the `store_heap_oop` branch, `r14` is corrupted at the second call and we get a segfault. > - `generate_buffered_inline_type_adapter` in `sharedRuntime_x86_64.cpp`: same with register `rax` being corrupted in a loop. > - `pack_inline_helper` ... Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Update copyright - Merge remote-tracking branch 'origin/lworld' into JDK-8366717.testing - Fixing aarch64 - Save in more places - Lift saving rax - Pick the right comment again - Merge remote-tracking branch 'origin/lworld' into JDK-8366717.investigate - oop_store_at - assert in oop_store_at - Cleanup - ... and 8 more: https://git.openjdk.org/valhalla/compare/90dfb439...05dd65e4 ------------- Changes: https://git.openjdk.org/valhalla/pull/1824/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1824&range=02 Stats: 118 lines in 9 files changed: 35 ins; 55 del; 28 mod Patch: https://git.openjdk.org/valhalla/pull/1824.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1824/head:pull/1824 PR: https://git.openjdk.org/valhalla/pull/1824 From mchevalier at openjdk.org Wed Jan 7 10:18:34 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 7 Jan 2026 10:18:34 GMT Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of JDK-8365996 [v3] In-Reply-To: References: Message-ID: <-8MQ_f2EKHEueIG5CEEjGSzQtHQxwdJIJG-SZr7rtBA=.faaaaa96-155d-446e-b683-7a541e8513fe@github.com> On Fri, 19 Dec 2025 09:33:45 GMT, Tobias Hartmann wrote: >> That is the else-branch, right? Right now we have >> >> if (tmp3 != noreg) { >> __ mov(tmp3, dst.base()); >> store_check(masm, tmp3, dst); >> } else { >> // It's OK to corrupt the dst.base() register. >> store_check(masm, dst.base(), dst); >> } >> >> If I understand well, you're suggesting to write >> >> if (InlineTypePassFieldsAsArgs) { >> if (tmp3 != noreg) { >> __ mov(tmp3, dst.base()); >> store_check(masm, tmp3, dst); >> } else { >> // It's OK to corrupt the dst.base() register. >> store_check(masm, dst.base(), dst); >> } >> } else { >> // as mainline >> store_check(masm, dst.base(), dst); >> } >> >> but to me, it looks equivalent to >> >> >> if (InlineTypePassFieldsAsArgs && tmp3 != noreg) { >> __ mov(tmp3, dst.base()); >> store_check(masm, tmp3, dst); >> } else { >> // It's OK to corrupt the dst.base() register. >> store_check(masm, dst.base(), dst); >> } >> >> since both else-branch are identical. >> >> And this, I experimentally found that it's failing quite a lot, with backtraces as I mentioned. Is there an obvious mistake in my logic I'm missing? > > Ah, you are right. I missed the outer `if (tmp3 != noreg) {` which is Valhalla specific. As we discussed off-thread, it would be good to get a better understanding of why this fails in Valhalla. Thanks a lot! I've fixed and added an explanation of that in the the PR description. The problem is that some new Valhalla-specific code is using `store_heap_oop` that is eventually calling `CardTableBarrierSetAssembler::oop_store_at` in a loop where corrupting `dst.base()` is problematic for following loop iterations. I've added some saving rather at the level of these loops. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1824#discussion_r2667841041 From mcimadamore at openjdk.org Wed Jan 7 12:25:25 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 7 Jan 2026 12:25:25 GMT Subject: RFR: 8374149: [bworld] Define and use new null checking API [v4] In-Reply-To: References: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> Message-ID: On Tue, 6 Jan 2026 19:58:10 GMT, Vicente Romero wrote: >> Definition and use of a new null checking API > > Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge branch 'bworld' into JDK-8374149 > - adding a flag > - additional changes > - minor changes > - additional changes to Checks > - Merge branch 'bworld' into JDK-8374149 > - additional changes > - Merge branch 'bworld' into JDK-8374149 > - 8374149: [bworld] Define and use new null checking API src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 3506: > 3504: /** Make an attributed null check tree. > 3505: */ > 3506: public JCExpression makeNullCheck(JCExpression arg, boolean nullRestricted) { Note -- as we evolve the code more, it would be great if we could get rid of AST generation inside Attr (currently, we add null check AST nodes as part of attribution -- which then confuses IDEs who do not expect such changes while analyzing code). src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 145: > 143: allowValueClasses = (!preview.isPreview(Source.Feature.VALUE_CLASSES) || preview.isEnabled()) && > 144: Source.Feature.VALUE_CLASSES.allowedInSource(source); > 145: String opt = Options.instance(context).get("useRuntimeChecks"); In principle this could be simplified to: hasRuntimeChecks = target.hasRuntimeChecks() && options.getBoolean("useRuntimeChecks", true); Right? E.g. emitting an error for the case where `useRuntimeChecks` is set, but the target is not compatible doesn't seem super important? (Also, how is this hidden flag used? Do we really need it?) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1859#discussion_r2668223977 PR Review Comment: https://git.openjdk.org/valhalla/pull/1859#discussion_r2668220430 From fparain at openjdk.org Wed Jan 7 12:50:17 2026 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 7 Jan 2026 12:50:17 GMT Subject: [lworld] RFR: 8374554: [lworld] Field layout assert with UseCompactObjectHeaders Message-ID: Fix an issue in the logic processing the beginning of a field layout, abstract value class with fields were processing correctly. Add more configurations to tests in order to cover compact object headers too. Re-enabled some tests that were disabled, an extended them to cover compact object headers too. Tested with Mach5 tier 1 to 3. Thank you, Fred ------------- Commit messages: - Fix generation of layout beginning Changes: https://git.openjdk.org/valhalla/pull/1862/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1862&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374554 Stats: 243 lines in 5 files changed: 179 ins; 23 del; 41 mod Patch: https://git.openjdk.org/valhalla/pull/1862.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1862/head:pull/1862 PR: https://git.openjdk.org/valhalla/pull/1862 From jsikstro at openjdk.org Wed Jan 7 13:47:08 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 7 Jan 2026 13:47:08 GMT Subject: [lworld] Integrated: 8374093: [lworld] Cleanup and polish around vgetfield/vputfield In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 09:19:49 GMT, Joel Sikstr?m wrote: > Hello, > > I've been looking at the new internal bytecodes vgetfield and vputfield and their callchains from the interpreter down to InlineKlass and have some cleanups. I've not looked at templateTable_x86 so far, only templateTable_aarch64. > > Some notes: > * The `dest_is_initialized` parameter in InlineKlass::write_value_to_addr is `true` for all callers, so I've removed it and inlined `true` to the call to `copy_payload_to_addr`. > * There seems to be an unnecessary `mark_payload_as_non_null((address)src);` in InlineKlass::copy_payload_to_addr, as the payload should already be non_null if it doesn't match `is_payload_marked_as_null` in the if-statement just above. > > Testing: > * hotspot_valhalla, jdk_valhalla and tier1 This pull request has now been integrated. Changeset: b51d2eb2 Author: Joel Sikstr?m Committer: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/b51d2eb28ff8271f22e489dde556828e9ae4c844 Stats: 37 lines in 10 files changed: 0 ins; 4 del; 33 mod 8374093: [lworld] Cleanup and polish around vgetfield/vputfield Reviewed-by: fparain ------------- PR: https://git.openjdk.org/valhalla/pull/1840 From vromero at openjdk.org Wed Jan 7 14:37:03 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Jan 2026 14:37:03 GMT Subject: RFR: 8374149: [bworld] Define and use new null checking API [v4] In-Reply-To: References: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> Message-ID: On Wed, 7 Jan 2026 12:20:56 GMT, Maurizio Cimadamore wrote: >> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: >> >> - Merge branch 'bworld' into JDK-8374149 >> - adding a flag >> - additional changes >> - minor changes >> - additional changes to Checks >> - Merge branch 'bworld' into JDK-8374149 >> - additional changes >> - Merge branch 'bworld' into JDK-8374149 >> - 8374149: [bworld] Define and use new null checking API > > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 145: > >> 143: allowValueClasses = (!preview.isPreview(Source.Feature.VALUE_CLASSES) || preview.isEnabled()) && >> 144: Source.Feature.VALUE_CLASSES.allowedInSource(source); >> 145: String opt = Options.instance(context).get("useRuntimeChecks"); > > In principle this could be simplified to: > > > hasRuntimeChecks = target.hasRuntimeChecks() && options.getBoolean("useRuntimeChecks", true); > > > Right? E.g. emitting an error for the case where `useRuntimeChecks` is set, but the target is not compatible doesn't seem super important? (Also, how is this hidden flag used? Do we really need it?) I don't think we super need it but could be useful for testing, but I can remove it ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1859#discussion_r2668691648 From vromero at openjdk.org Wed Jan 7 15:10:27 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Jan 2026 15:10:27 GMT Subject: RFR: 8374149: [bworld] Define and use new null checking API [v5] In-Reply-To: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> References: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> Message-ID: > Definition and use of a new null checking API Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1859/files - new: https://git.openjdk.org/valhalla/pull/1859/files/c305e470..56bcb0b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1859&range=04 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1859&range=03-04 Stats: 14 lines in 1 file changed: 0 ins; 13 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1859.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1859/head:pull/1859 PR: https://git.openjdk.org/valhalla/pull/1859 From vromero at openjdk.org Wed Jan 7 15:10:30 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Jan 2026 15:10:30 GMT Subject: RFR: 8374149: [bworld] Define and use new null checking API [v4] In-Reply-To: References: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> Message-ID: On Wed, 7 Jan 2026 14:32:56 GMT, Vicente Romero wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 145: >> >>> 143: allowValueClasses = (!preview.isPreview(Source.Feature.VALUE_CLASSES) || preview.isEnabled()) && >>> 144: Source.Feature.VALUE_CLASSES.allowedInSource(source); >>> 145: String opt = Options.instance(context).get("useRuntimeChecks"); >> >> In principle this could be simplified to: >> >> >> hasRuntimeChecks = target.hasRuntimeChecks() && options.getBoolean("useRuntimeChecks", true); >> >> >> Right? E.g. emitting an error for the case where `useRuntimeChecks` is set, but the target is not compatible doesn't seem super important? (Also, how is this hidden flag used? Do we really need it?) > > I don't think we super need it but could be useful for testing, but I can remove it removed ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1859#discussion_r2668836870 From mcimadamore at openjdk.org Wed Jan 7 15:51:34 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 7 Jan 2026 15:51:34 GMT Subject: RFR: 8374149: [bworld] Define and use new null checking API [v5] In-Reply-To: References: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> Message-ID: On Wed, 7 Jan 2026 15:10:27 GMT, Vicente Romero wrote: >> Definition and use of a new null checking API > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments Looks good! ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1859#pullrequestreview-3635534525 From thartmann at openjdk.org Wed Jan 7 16:08:02 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 7 Jan 2026 16:08:02 GMT Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of JDK-8365996 [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 10:18:32 GMT, Marc Chevalier wrote: >> Let's proceed piece by piece. >> >> # `G1BarrierSetAssembler::g1_write_barrier_pre` in `g1BarrierSetAssembler_aarch64.cpp` >> >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp#L216-L220 >> >> `push_call_clobbered_registers`/`pop_call_clobbered_registers` should be enough around a runtime call, that's what clobbered registers are. >> >> But let's dig a bit, that will be useful later! >> >> >> push_call_clobbered_registers() >> => push_call_clobbered_registers_except(exclude = empty set) >> => push(call_clobbered_gp_registers() - exclude, sp) // with exclude = empty set >> >> So, we save at least `call_clobbered_gp_registers` which is defined as: >> >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L3614-L3620 >> >> So, we save r0-r7 and r10-r17 >> >> # `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_aarch64.cpp` and `cardTableBarrierSetAssembler_x86.cpp` >> >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp#L116-L124 >> >> Digging the history, it seems it was added to fix a corruption of `dst.base()`. Yet, it might not be always necessary. It's rather nicer to save where it matter that the register is not corrupted than all the way down. So, there are a few such places: >> >> - `gen_c2i_adapter_helper` in `sharedRuntime_x86_64.cpp` >> `gen_c2i_adapter_helper` calls `store_heap_oop` that can corrupts `to.base()`. `gen_c2i_adapter_helper` is called, for instance from `gen_c2i_adapter`: >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1069-L1070 >> where we can see that `to.base()` is `r14`, which is set >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1026 >> before the loop enclosing the call to `gen_c2i_adapter_helper` >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1036 >> If we do more than one iteration of this loop when entering the `store_heap_oop` branch, `r14` is corrupted at the second call and we get a segfault. >> - `generate_buffered_inline_type_adapter` in `sharedRuntime_x86_64.cpp`: sam... > > Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Update copyright > - Merge remote-tracking branch 'origin/lworld' into JDK-8366717.testing > - Fixing aarch64 > - Save in more places > - Lift saving rax > - Pick the right comment again > - Merge remote-tracking branch 'origin/lworld' into JDK-8366717.investigate > - oop_store_at > - assert in oop_store_at > - Cleanup > - ... and 8 more: https://git.openjdk.org/valhalla/compare/90dfb439...05dd65e4 Nice! Thanks for the thorough investigation. Looks good to me. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1824#pullrequestreview-3635605860 From mcimadamore at openjdk.org Wed Jan 7 16:12:18 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 7 Jan 2026 16:12:18 GMT Subject: RFR: 8374730: Add support for null restriction in j.l.r.Type Message-ID: This PR adds j.l.r.Type support for null restrictions. More specifically, a new public interface is added, namely `NullRestrictedType`, modelling types with null restrictions. Changes to the signature parsing code have been made so that instances of the new interface are generated accordingly. A new test makes sure that everything behaves correctly. Note: we should also make sure that the `AnnotatedType` hierarchy is changed to reflect the null-restriction changes, but for now that is lower priority and will be pursued in a separate PR. ------------- Commit messages: - Simplify test - Add signature parser support - Merge branch 'bworld' into add_restricted_reflect_type - Initial work Changes: https://git.openjdk.org/valhalla/pull/1863/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1863&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374730 Stats: 381 lines in 10 files changed: 375 ins; 5 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1863.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1863/head:pull/1863 PR: https://git.openjdk.org/valhalla/pull/1863 From mcimadamore at openjdk.org Wed Jan 7 16:12:19 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 7 Jan 2026 16:12:19 GMT Subject: RFR: 8374730: Add support for null restriction in j.l.r.Type In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 16:03:42 GMT, Maurizio Cimadamore wrote: > This PR adds j.l.r.Type support for null restrictions. > > More specifically, a new public interface is added, namely `NullRestrictedType`, modelling types with null restrictions. > > Changes to the signature parsing code have been made so that instances of the new interface are generated accordingly. > A new test makes sure that everything behaves correctly. > > Note: we should also make sure that the `AnnotatedType` hierarchy is changed to reflect the null-restriction changes, but for now that is lower priority and will be pursued in a separate PR. test/langtools/tools/javac/lib/combo/ComboTask.java line 206: > 204: * executes them > 205: */ > 206: public void execute(Consumer c) { I've revived the support to execute test cases from the combo test framework -- we used to have this, but somehow this method got dropped. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1863#discussion_r2669059837 From vromero at openjdk.org Wed Jan 7 16:14:50 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Jan 2026 16:14:50 GMT Subject: Integrated: Merge lworld Message-ID: <6048klRJDnMJvW8jfEI_O5eonyVh4BYRMS9qem3NGAI=.c28b5e30-8b5c-4f7c-a7b1-fd1b2270eb47@github.com> Merge lworld into bworld ------------- Commit messages: - additional changes - Merge branch 'lworld' into bworld_merge_lworld - 8374633: Bang in signatures should go before the type - Remove spurious code - 8374545: Drop logic for unchecked nullness conversions - remove support for LooselyConsistentValue - Remove parametric nullity and nullable marker - remove hidden option allowNullRestrictedTypesForValueClassesOnly - fixing regression test CheckExamples - Fixing nullability regression tests - ... and 78 more: https://git.openjdk.org/valhalla/compare/b51d2eb2...d9ba3e8b The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/valhalla/pull/1864/files Stats: 4930 lines in 79 files changed: 4823 ins; 6 del; 101 mod Patch: https://git.openjdk.org/valhalla/pull/1864.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1864/head:pull/1864 PR: https://git.openjdk.org/valhalla/pull/1864 From vromero at openjdk.org Wed Jan 7 16:14:51 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Jan 2026 16:14:51 GMT Subject: Integrated: Merge lworld In-Reply-To: <6048klRJDnMJvW8jfEI_O5eonyVh4BYRMS9qem3NGAI=.c28b5e30-8b5c-4f7c-a7b1-fd1b2270eb47@github.com> References: <6048klRJDnMJvW8jfEI_O5eonyVh4BYRMS9qem3NGAI=.c28b5e30-8b5c-4f7c-a7b1-fd1b2270eb47@github.com> Message-ID: On Wed, 7 Jan 2026 16:09:22 GMT, Vicente Romero wrote: > Merge lworld into bworld This pull request has now been integrated. Changeset: 546737c2 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/546737c2c67f213cc6657759f70adee74997cf12 Stats: 50078 lines in 1022 files changed: 33149 ins; 11490 del; 5439 mod Merge lworld ------------- PR: https://git.openjdk.org/valhalla/pull/1864 From vromero at openjdk.org Wed Jan 7 16:20:24 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Jan 2026 16:20:24 GMT Subject: Integrated: 8374149: [bworld] Define and use new null checking API In-Reply-To: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> References: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> Message-ID: On Mon, 5 Jan 2026 22:06:29 GMT, Vicente Romero wrote: > Definition and use of a new null checking API This pull request has now been integrated. Changeset: 1d9a5a6a Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/1d9a5a6a40162f2ff6a477c96c41d83946fd322e Stats: 212 lines in 13 files changed: 202 ins; 0 del; 10 mod 8374149: [bworld] Define and use new null checking API Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1859 From forax at openjdk.org Wed Jan 7 17:02:35 2026 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 7 Jan 2026 17:02:35 GMT Subject: RFR: 8374149: [bworld] Define and use new null checking API [v5] In-Reply-To: References: <8ODsnM0Y6S-Yo-BydC2MjSB-8UYj5thYvyMl6jT5q1c=.4e88cfdd-b0d8-43be-9426-9c1a022d5c36@github.com> Message-ID: <6oJq4ZIleFRcUmwH44T71bFd2klux49SAx8ZumrGiW8=.89325a3b-d6ec-44d9-befa-f9ca23e577e2@github.com> On Wed, 7 Jan 2026 15:10:27 GMT, Vicente Romero wrote: >> Definition and use of a new null checking API > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments I know this is already pushed but can NULLCHK2 be changed to NULLRESTRICTEDCHK ? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1859#issuecomment-3719832206 From vromero at openjdk.org Wed Jan 7 17:22:39 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Jan 2026 17:22:39 GMT Subject: RFR: 8374730: Add support for null restriction in j.l.r.Type In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 16:03:42 GMT, Maurizio Cimadamore wrote: > This PR adds j.l.r.Type support for null restrictions. > > More specifically, a new public interface is added, namely `NullRestrictedType`, modelling types with null restrictions. > > Changes to the signature parsing code have been made so that instances of the new interface are generated accordingly. > A new test makes sure that everything behaves correctly. > > Note: we should also make sure that the `AnnotatedType` hierarchy is changed to reflect the null-restriction changes, but for now that is lower priority and will be pursued in a separate PR. src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/NullRestrictedTypeImpl.java line 2: > 1: /* > 2: * Copyright (c) 2003, 2023, Oracle and/or its affiliates. All rights reserved. nit copyright year ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1863#discussion_r2669347245 From coleenp at openjdk.org Wed Jan 7 17:31:04 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Jan 2026 17:31:04 GMT Subject: [lworld] RFR: 8374554: [lworld] Field layout assert with UseCompactObjectHeaders In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:44:23 GMT, Frederic Parain wrote: > Fix an issue in the logic processing the beginning of a field layout, abstract value class with fields were processing correctly. > > Add more configurations to tests in order to cover compact object headers too. > Re-enabled some tests that were disabled, an extended them to cover compact object headers too. > > Tested with Mach5 tier 1 to 3. > > Thank you, > > Fred The VM code changes look good and more understandable than before. The tests should remove the cases for +COH -CompressedKlassPointers since it's not a valid combination. And can the test numbers be strings that look like enums, maybe taken from the test id? test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout/FieldAlignmentTest.java line 80: > 78: > 79: /* > 80: * @test id=NoCompressedOopsNoCompressKlassPointersCompactHeader CompactObjectHeaders only works with CompressedKlassPointers so this shouldn't be a valid combination. Or if it doesn't give an error on invocation it should. test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout/FieldAlignmentTest.java line 219: > 217: switch(args[0]) { > 218: case "0": compressedOopsArg = null; > 219: compressedKlassPointersArg = null; Can you make 1-4 an enum or descriptive string? test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout/NullMarkersTest.java line 366: > 364: compressedKlassPointersArg = "-XX:-UseCompressedClassPointers"; > 365: compactObjectHeaderArg = "-XX:+UseCompactObjectHeaders"; > 366: break; java -XX:-UseCompressedClassPointers -XX:+UseCompactObjectHeaders -cp ~/work Hello Java HotSpot(TM) 64-Bit Server VM warning: Temporarily processing option UseCompressedClassPointers; support is scheduled for removal in 27.0 Java HotSpot(TM) 64-Bit Server VM warning: Compact object headers require compressed class pointers. Disabling compact object headers. This configuration doesn't give an error, it just disables COH. So it's not useful to test. test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout/ValueFieldInheritanceTest.java line 237: > 235: case "5": compressedOopsArg = "-XX:-UseCompressedOops"; > 236: compressedKlassPointersArg = "-XX:-UseCompressedClassPointers"; > 237: compactObjectHeader = "-XX:+UseCompactObjectHeaders"; Same here. But above it's 4 and now it's 5? ------------- Changes requested by coleenp (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1862#pullrequestreview-3635937409 PR Review Comment: https://git.openjdk.org/valhalla/pull/1862#discussion_r2669346968 PR Review Comment: https://git.openjdk.org/valhalla/pull/1862#discussion_r2669357415 PR Review Comment: https://git.openjdk.org/valhalla/pull/1862#discussion_r2669378028 PR Review Comment: https://git.openjdk.org/valhalla/pull/1862#discussion_r2669381323 From vromero at openjdk.org Wed Jan 7 17:32:36 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Jan 2026 17:32:36 GMT Subject: RFR: 8374730: Add support for null restriction in j.l.r.Type In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 16:03:42 GMT, Maurizio Cimadamore wrote: > This PR adds j.l.r.Type support for null restrictions. > > More specifically, a new public interface is added, namely `NullRestrictedType`, modelling types with null restrictions. > > Changes to the signature parsing code have been made so that instances of the new interface are generated accordingly. > A new test makes sure that everything behaves correctly. > > Note: we should also make sure that the `AnnotatedType` hierarchy is changed to reflect the null-restriction changes, but for now that is lower priority and will be pursued in a separate PR. src/java.base/share/classes/java/lang/reflect/NullRestrictedType.java line 36: > 34: * > 35: *

Instances of classes that implement this interface must implement > 36: * an equals() method that equates any two null rrestricted type instances that nit: typo `rrestricted` src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/NullRestrictedTypeImpl.java line 42: > 40: } > 41: > 42: private void checkNonRestricted(Type type) { can this method be static? src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/NullRestrictedTypeImpl.java line 44: > 42: private void checkNonRestricted(Type type) { > 43: if (type instanceof NullRestrictedType) { > 44: throw new IllegalArgumentException("Already a null-rrestricted type"); typo: `rrestricted` src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/NullRestrictedTypeImpl.java line 65: > 63: * From the JavaDoc for java.lang.reflect.NullRestrictedType > 64: * "Instances of classes that implement this interface must implement > 65: * an equals() method that equates any two null rrestricted type instances that `rrestricted` test/langtools/tools/javac/nullability/NullRestrictionReflectiveTest.java line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. 2026? test/langtools/tools/javac/nullability/NullRestrictionReflectiveTest.java line 97: > 95: public void doWork() throws IOException { > 96: newCompilationTask() > 97: .withOptions(List.of("--enable-preview", "--release", "26")) should be 27, but in any case better not to wire a specific version ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1863#discussion_r2669351810 PR Review Comment: https://git.openjdk.org/valhalla/pull/1863#discussion_r2669356609 PR Review Comment: https://git.openjdk.org/valhalla/pull/1863#discussion_r2669357855 PR Review Comment: https://git.openjdk.org/valhalla/pull/1863#discussion_r2669363811 PR Review Comment: https://git.openjdk.org/valhalla/pull/1863#discussion_r2669385150 PR Review Comment: https://git.openjdk.org/valhalla/pull/1863#discussion_r2669391525 From coleenp at openjdk.org Wed Jan 7 17:34:40 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Jan 2026 17:34:40 GMT Subject: [lworld] RFR: 8374554: [lworld] Field layout assert with UseCompactObjectHeaders In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:44:23 GMT, Frederic Parain wrote: > Fix an issue in the logic processing the beginning of a field layout, abstract value class with fields were processing correctly. > > Add more configurations to tests in order to cover compact object headers too. > Re-enabled some tests that were disabled, an extended them to cover compact object headers too. > > Tested with Mach5 tier 1 to 3. > > Thank you, > > Fred Also Happy New Year! Can you update copyright headers? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1862#issuecomment-3719960068 From fparain at openjdk.org Wed Jan 7 18:16:54 2026 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 7 Jan 2026 18:16:54 GMT Subject: [lworld] RFR: 8374554: [lworld] Field layout assert with UseCompactObjectHeaders [v2] In-Reply-To: References: Message-ID: > Fix an issue in the logic processing the beginning of a field layout, abstract value class with fields were processing correctly. > > Add more configurations to tests in order to cover compact object headers too. > Re-enabled some tests that were disabled, an extended them to cover compact object headers too. > > Tested with Mach5 tier 1 to 3. > > Thank you, > > Fred Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: Fix test configurations names and options ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1862/files - new: https://git.openjdk.org/valhalla/pull/1862/files/c3b75407..e9d65e58 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1862&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1862&range=00-01 Stats: 135 lines in 3 files changed: 29 ins; 0 del; 106 mod Patch: https://git.openjdk.org/valhalla/pull/1862.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1862/head:pull/1862 PR: https://git.openjdk.org/valhalla/pull/1862 From fparain at openjdk.org Wed Jan 7 18:16:56 2026 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 7 Jan 2026 18:16:56 GMT Subject: [lworld] RFR: 8374554: [lworld] Field layout assert with UseCompactObjectHeaders In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:44:23 GMT, Frederic Parain wrote: > Fix an issue in the logic processing the beginning of a field layout, abstract value class with fields were processing correctly. > > Add more configurations to tests in order to cover compact object headers too. > Re-enabled some tests that were disabled, an extended them to cover compact object headers too. > > Tested with Mach5 tier 1 to 3. > > Thank you, > > Fred Test scenarios have been renamed and scenario 4 has been changed to keep compressed class pointers enabled. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1862#issuecomment-3720132487 From coleenp at openjdk.org Wed Jan 7 18:20:11 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Jan 2026 18:20:11 GMT Subject: [lworld] RFR: 8374554: [lworld] Field layout assert with UseCompactObjectHeaders [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 18:16:54 GMT, Frederic Parain wrote: >> Fix an issue in the logic processing the beginning of a field layout, abstract value class with fields were processing correctly. >> >> Add more configurations to tests in order to cover compact object headers too. >> Re-enabled some tests that were disabled, an extended them to cover compact object headers too. >> >> Tested with Mach5 tier 1 to 3. >> >> Thank you, >> >> Fred > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > Fix test configurations names and options I do like these enum-like values a lot. 2 comments. test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout/NullMarkersTest.java line 368: > 366: break; > 367: case "64_COOP_CCP_COH": > 368: compressedOopsArg = "-XX:-UseCompressedOops"; This should be +UseCompressedOops and the one below should be -UseCompressedOops. test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout/ValueFieldInheritanceTest.java line 226: > 224: > 225: switch(args[0]) { > 226: case "0": Should be "32". ------------- PR Review: https://git.openjdk.org/valhalla/pull/1862#pullrequestreview-3636209027 PR Review Comment: https://git.openjdk.org/valhalla/pull/1862#discussion_r2669595262 PR Review Comment: https://git.openjdk.org/valhalla/pull/1862#discussion_r2669598134 From mcimadamore at openjdk.org Wed Jan 7 18:22:49 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 7 Jan 2026 18:22:49 GMT Subject: RFR: 8374730: Add support for null restriction in j.l.r.Type [v2] In-Reply-To: References: Message-ID: > This PR adds j.l.r.Type support for null restrictions. > > More specifically, a new public interface is added, namely `NullRestrictedType`, modelling types with null restrictions. > > Changes to the signature parsing code have been made so that instances of the new interface are generated accordingly. > A new test makes sure that everything behaves correctly. > > Note: we should also make sure that the `AnnotatedType` hierarchy is changed to reflect the null-restriction changes, but for now that is lower priority and will be pursued in a separate PR. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1863/files - new: https://git.openjdk.org/valhalla/pull/1863/files/2275da75..538a4857 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1863&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1863&range=00-01 Stats: 12 lines in 4 files changed: 5 ins; 0 del; 7 mod Patch: https://git.openjdk.org/valhalla/pull/1863.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1863/head:pull/1863 PR: https://git.openjdk.org/valhalla/pull/1863 From fparain at openjdk.org Wed Jan 7 18:26:34 2026 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 7 Jan 2026 18:26:34 GMT Subject: [lworld] RFR: 8374554: [lworld] Field layout assert with UseCompactObjectHeaders [v3] In-Reply-To: References: Message-ID: > Fix an issue in the logic processing the beginning of a field layout, abstract value class with fields were processing correctly. > > Add more configurations to tests in order to cover compact object headers too. > Re-enabled some tests that were disabled, an extended them to cover compact object headers too. > > Tested with Mach5 tier 1 to 3. > > Thank you, > > Fred Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: Fixes from review ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1862/files - new: https://git.openjdk.org/valhalla/pull/1862/files/e9d65e58..4da47bf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1862&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1862&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1862.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1862/head:pull/1862 PR: https://git.openjdk.org/valhalla/pull/1862 From fparain at openjdk.org Wed Jan 7 18:26:38 2026 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 7 Jan 2026 18:26:38 GMT Subject: [lworld] RFR: 8374554: [lworld] Field layout assert with UseCompactObjectHeaders [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 18:15:09 GMT, Coleen Phillimore wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix test configurations names and options > > test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout/NullMarkersTest.java line 368: > >> 366: break; >> 367: case "64_COOP_CCP_COH": >> 368: compressedOopsArg = "-XX:-UseCompressedOops"; > > This should be +UseCompressedOops and the one below should be -UseCompressedOops. Thank you for catching that. Fixed > test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout/ValueFieldInheritanceTest.java line 226: > >> 224: >> 225: switch(args[0]) { >> 226: case "0": > > Should be "32". Fixed ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1862#discussion_r2669616210 PR Review Comment: https://git.openjdk.org/valhalla/pull/1862#discussion_r2669616517 From vromero at openjdk.org Wed Jan 7 18:30:28 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Jan 2026 18:30:28 GMT Subject: Integrated: renaming NULLCHK2 to NULLRESTRICTEDCHK In-Reply-To: <0xoHq0tR2g_DjVNR_XnwIfgeodWELZ8XAREcN5FZFKA=.44211f6c-9fff-4126-a600-ed15b88467f0@github.com> References: <0xoHq0tR2g_DjVNR_XnwIfgeodWELZ8XAREcN5FZFKA=.44211f6c-9fff-4126-a600-ed15b88467f0@github.com> Message-ID: On Wed, 7 Jan 2026 18:22:06 GMT, Vicente Romero wrote: > simple constant renaming as suggested by Remi This pull request has now been integrated. Changeset: e23d19c2 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/e23d19c20bd914d01fa4ade1c4ba26ef850d2a19 Stats: 17 lines in 9 files changed: 1 ins; 3 del; 13 mod renaming NULLCHK2 to NULLRESTRICTEDCHK ------------- PR: https://git.openjdk.org/valhalla/pull/1865 From vromero at openjdk.org Wed Jan 7 18:30:27 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Jan 2026 18:30:27 GMT Subject: Integrated: renaming NULLCHK2 to NULLRESTRICTEDCHK Message-ID: <0xoHq0tR2g_DjVNR_XnwIfgeodWELZ8XAREcN5FZFKA=.44211f6c-9fff-4126-a600-ed15b88467f0@github.com> simple constant renaming as suggested by Remi ------------- Commit messages: - renaming NULLCHK2 to NULLRESTRICTEDCHK Changes: https://git.openjdk.org/valhalla/pull/1865/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1865&range=00 Stats: 17 lines in 9 files changed: 1 ins; 3 del; 13 mod Patch: https://git.openjdk.org/valhalla/pull/1865.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1865/head:pull/1865 PR: https://git.openjdk.org/valhalla/pull/1865 From vromero at openjdk.org Wed Jan 7 18:32:02 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Jan 2026 18:32:02 GMT Subject: RFR: 8374730: Add support for null restriction in j.l.r.Type [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 18:22:49 GMT, Maurizio Cimadamore wrote: >> This PR adds j.l.r.Type support for null restrictions. >> >> More specifically, a new public interface is added, namely `NullRestrictedType`, modelling types with null restrictions. >> >> Changes to the signature parsing code have been made so that instances of the new interface are generated accordingly. >> A new test makes sure that everything behaves correctly. >> >> Note: we should also make sure that the `AnnotatedType` hierarchy is changed to reflect the null-restriction changes, but for now that is lower priority and will be pursued in a separate PR. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments looks good ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1863#pullrequestreview-3636250400 From mcimadamore at openjdk.org Wed Jan 7 18:40:01 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 7 Jan 2026 18:40:01 GMT Subject: RFR: 8374730: Add support for null restriction in j.l.r.Type [v3] In-Reply-To: References: Message-ID: <2rreTXRJWJ-WNJBkgucvNDq58NXqxv8uAzr0UGkdesI=.736c474e-cea6-4923-be88-a9bab7bb4f4c@github.com> > This PR adds j.l.r.Type support for null restrictions. > > More specifically, a new public interface is added, namely `NullRestrictedType`, modelling types with null restrictions. > > Changes to the signature parsing code have been made so that instances of the new interface are generated accordingly. > A new test makes sure that everything behaves correctly. > > Note: we should also make sure that the `AnnotatedType` hierarchy is changed to reflect the null-restriction changes, but for now that is lower priority and will be pursued in a separate PR. Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'bworld' into add_restricted_reflect_type - Address review comments - Simplify test - Add signature parser support Add test - Merge branch 'bworld' into add_restricted_reflect_type - Initial work ------------- Changes: https://git.openjdk.org/valhalla/pull/1863/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1863&range=02 Stats: 387 lines in 11 files changed: 380 ins; 5 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1863.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1863/head:pull/1863 PR: https://git.openjdk.org/valhalla/pull/1863 From mcimadamore at openjdk.org Wed Jan 7 18:40:04 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 7 Jan 2026 18:40:04 GMT Subject: Integrated: 8374730: Add support for null restriction in j.l.r.Type In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 16:03:42 GMT, Maurizio Cimadamore wrote: > This PR adds j.l.r.Type support for null restrictions. > > More specifically, a new public interface is added, namely `NullRestrictedType`, modelling types with null restrictions. > > Changes to the signature parsing code have been made so that instances of the new interface are generated accordingly. > A new test makes sure that everything behaves correctly. > > Note: we should also make sure that the `AnnotatedType` hierarchy is changed to reflect the null-restriction changes, but for now that is lower priority and will be pursued in a separate PR. This pull request has now been integrated. Changeset: b460c92c Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/b460c92c5743423e50c805eeb346678733ae18f3 Stats: 387 lines in 11 files changed: 380 ins; 5 del; 2 mod 8374730: Add support for null restriction in j.l.r.Type Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1863 From dcubed at openjdk.org Wed Jan 7 19:06:06 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 7 Jan 2026 19:06:06 GMT Subject: [lworld] RFR: 8374736: [lworld] ProblemList valhalla/valuetypes/SubstitutabilityTest.java with AOTCache Message-ID: A trivial fix to ProblemList valhalla/valuetypes/SubstitutabilityTest.java with AOTCache. ------------- Commit messages: - 8374025: [lworld] valhalla/valuetypes/SubstitutabilityTest.java fails due to argument clashes Changes: https://git.openjdk.org/valhalla/pull/1866/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1866&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374736 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1866.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1866/head:pull/1866 PR: https://git.openjdk.org/valhalla/pull/1866 From fparain at openjdk.org Wed Jan 7 19:09:26 2026 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 7 Jan 2026 19:09:26 GMT Subject: [lworld] RFR: 8374736: [lworld] ProblemList valhalla/valuetypes/SubstitutabilityTest.java with AOTCache In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 18:57:28 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList valhalla/valuetypes/SubstitutabilityTest.java with AOTCache. LGTM ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1866#pullrequestreview-3636412490 From coleenp at openjdk.org Wed Jan 7 19:12:01 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Jan 2026 19:12:01 GMT Subject: [lworld] RFR: 8374554: [lworld] Field layout assert with UseCompactObjectHeaders [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 18:26:34 GMT, Frederic Parain wrote: >> Fix an issue in the logic processing the beginning of a field layout, abstract value class with fields were processing correctly. >> >> Add more configurations to tests in order to cover compact object headers too. >> Re-enabled some tests that were disabled, an extended them to cover compact object headers too. >> >> Tested with Mach5 tier 1 to 3. >> >> Thank you, >> >> Fred > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > Fixes from review Looks good! ------------- PR Review: https://git.openjdk.org/valhalla/pull/1862#pullrequestreview-3636419438 From dcubed at openjdk.org Wed Jan 7 19:14:46 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 7 Jan 2026 19:14:46 GMT Subject: [lworld] RFR: 8374736: [lworld] ProblemList valhalla/valuetypes/SubstitutabilityTest.java with AOTCache In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 19:06:58 GMT, Frederic Parain wrote: >> A trivial fix to ProblemList valhalla/valuetypes/SubstitutabilityTest.java with AOTCache. > > LGTM @fparain - Thanks for the fast review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1866#issuecomment-3720368417 From dcubed at openjdk.org Wed Jan 7 19:16:17 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 7 Jan 2026 19:16:17 GMT Subject: [lworld] Integrated: 8374736: [lworld] ProblemList valhalla/valuetypes/SubstitutabilityTest.java with AOTCache In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 18:57:28 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList valhalla/valuetypes/SubstitutabilityTest.java with AOTCache. This pull request has now been integrated. Changeset: 8d043ea4 Author: Daniel D. Daugherty URL: https://git.openjdk.org/valhalla/commit/8d043ea49c38628dcbe0662f5f180fc40b8262c7 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8374736: [lworld] ProblemList valhalla/valuetypes/SubstitutabilityTest.java with AOTCache Reviewed-by: fparain ------------- PR: https://git.openjdk.org/valhalla/pull/1866 From duke at openjdk.org Wed Jan 7 21:44:48 2026 From: duke at openjdk.org (Nicolai Parlog) Date: Wed, 7 Jan 2026 21:44:48 GMT Subject: [valhalla-docs] RFR: Fix wrong link to JEP 401 and add background info links Message-ID: The link to JEP 401 pointed to 390. Unrelated, I also added a talk from Dan and an article from John to the list of background documents. Maybe they were intentionally left out, so no hard feelings if they're removed. ? And the GitHub editor added a trailing newline, I think. ? ------------- Commit messages: - Fix wrong link to JEP 401 and add background info links Changes: https://git.openjdk.org/valhalla-docs/pull/16/files Webrev: https://webrevs.openjdk.org/?repo=valhalla-docs&pr=16&range=00 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla-docs/pull/16.diff Fetch: git fetch https://git.openjdk.org/valhalla-docs.git pull/16/head:pull/16 PR: https://git.openjdk.org/valhalla-docs/pull/16 From mchevalier at openjdk.org Thu Jan 8 07:40:06 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 8 Jan 2026 07:40:06 GMT Subject: [lworld] RFR: 8371726: [lworld] Re-enable verification once JDK-8371716 is solved In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 09:36:56 GMT, Marc Chevalier wrote: > Simply reverts [JDK-8367245](https://bugs.openjdk.org/browse/JDK-8367245) / 409f56a757145bf59ba17c9975c0dab2c01eef5b > since the real mainline fix [JDK-8371716](https://bugs.openjdk.org/browse/JDK-8371716) / 76e79dbb3eca5589aae6852c8f55adf0759c714e landed in Valhalla with https://github.com/openjdk/valhalla/pull/1843 (merge jdk-27+3). > > Thanks, > Marc Thanks for the review @chhagedorn! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1861#issuecomment-3722497855 From mchevalier at openjdk.org Thu Jan 8 07:40:07 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 8 Jan 2026 07:40:07 GMT Subject: [lworld] Integrated: 8371726: [lworld] Re-enable verification once JDK-8371716 is solved In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 09:36:56 GMT, Marc Chevalier wrote: > Simply reverts [JDK-8367245](https://bugs.openjdk.org/browse/JDK-8367245) / 409f56a757145bf59ba17c9975c0dab2c01eef5b > since the real mainline fix [JDK-8371716](https://bugs.openjdk.org/browse/JDK-8371716) / 76e79dbb3eca5589aae6852c8f55adf0759c714e landed in Valhalla with https://github.com/openjdk/valhalla/pull/1843 (merge jdk-27+3). > > Thanks, > Marc This pull request has now been integrated. Changeset: 6aa5d278 Author: Marc Chevalier URL: https://git.openjdk.org/valhalla/commit/6aa5d2783a636ca5de8e8f39f91f4eb6a6d32d55 Stats: 8 lines in 4 files changed: 0 ins; 4 del; 4 mod 8371726: [lworld] Re-enable verification once JDK-8371716 is solved Reviewed-by: chagedorn ------------- PR: https://git.openjdk.org/valhalla/pull/1861 From mchevalier at openjdk.org Thu Jan 8 09:44:36 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 8 Jan 2026 09:44:36 GMT Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of JDK-8365996 [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 10:18:32 GMT, Marc Chevalier wrote: >> Let's proceed piece by piece. >> >> # `G1BarrierSetAssembler::g1_write_barrier_pre` in `g1BarrierSetAssembler_aarch64.cpp` >> >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp#L216-L220 >> >> `push_call_clobbered_registers`/`pop_call_clobbered_registers` should be enough around a runtime call, that's what clobbered registers are. >> >> But let's dig a bit, that will be useful later! >> >> >> push_call_clobbered_registers() >> => push_call_clobbered_registers_except(exclude = empty set) >> => push(call_clobbered_gp_registers() - exclude, sp) // with exclude = empty set >> >> So, we save at least `call_clobbered_gp_registers` which is defined as: >> >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L3614-L3620 >> >> So, we save r0-r7 and r10-r17 >> >> # `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_aarch64.cpp` and `cardTableBarrierSetAssembler_x86.cpp` >> >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp#L116-L124 >> >> Digging the history, it seems it was added to fix a corruption of `dst.base()`. Yet, it might not be always necessary. It's rather nicer to save where it matter that the register is not corrupted than all the way down. So, there are a few such places: >> >> - `gen_c2i_adapter_helper` in `sharedRuntime_x86_64.cpp` >> `gen_c2i_adapter_helper` calls `store_heap_oop` that can corrupts `to.base()`. `gen_c2i_adapter_helper` is called, for instance from `gen_c2i_adapter`: >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1069-L1070 >> where we can see that `to.base()` is `r14`, which is set >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1026 >> before the loop enclosing the call to `gen_c2i_adapter_helper` >> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1036 >> If we do more than one iteration of this loop when entering the `store_heap_oop` branch, `r14` is corrupted at the second call and we get a segfault. >> - `generate_buffered_inline_type_adapter` in `sharedRuntime_x86_64.cpp`: sam... > > Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Update copyright > - Merge remote-tracking branch 'origin/lworld' into JDK-8366717.testing > - Fixing aarch64 > - Save in more places > - Lift saving rax > - Pick the right comment again > - Merge remote-tracking branch 'origin/lworld' into JDK-8366717.investigate > - oop_store_at > - assert in oop_store_at > - Cleanup > - ... and 8 more: https://git.openjdk.org/valhalla/compare/90dfb439...05dd65e4 Thanks @TobiHartmann for review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1824#issuecomment-3723040300 From mchevalier at openjdk.org Thu Jan 8 09:47:09 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 8 Jan 2026 09:47:09 GMT Subject: [lworld] Integrated: 8366717: [lworld] Cleanup defensive fixing of JDK-8365996 In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 08:26:03 GMT, Marc Chevalier wrote: > Let's proceed piece by piece. > > # `G1BarrierSetAssembler::g1_write_barrier_pre` in `g1BarrierSetAssembler_aarch64.cpp` > > https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp#L216-L220 > > `push_call_clobbered_registers`/`pop_call_clobbered_registers` should be enough around a runtime call, that's what clobbered registers are. > > But let's dig a bit, that will be useful later! > > > push_call_clobbered_registers() > => push_call_clobbered_registers_except(exclude = empty set) > => push(call_clobbered_gp_registers() - exclude, sp) // with exclude = empty set > > So, we save at least `call_clobbered_gp_registers` which is defined as: > > https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L3614-L3620 > > So, we save r0-r7 and r10-r17 > > # `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_aarch64.cpp` and `cardTableBarrierSetAssembler_x86.cpp` > > https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp#L116-L124 > > Digging the history, it seems it was added to fix a corruption of `dst.base()`. Yet, it might not be always necessary. It's rather nicer to save where it matter that the register is not corrupted than all the way down. So, there are a few such places: > > - `gen_c2i_adapter_helper` in `sharedRuntime_x86_64.cpp` > `gen_c2i_adapter_helper` calls `store_heap_oop` that can corrupts `to.base()`. `gen_c2i_adapter_helper` is called, for instance from `gen_c2i_adapter`: > https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1069-L1070 > where we can see that `to.base()` is `r14`, which is set > https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1026 > before the loop enclosing the call to `gen_c2i_adapter_helper` > https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1036 > If we do more than one iteration of this loop when entering the `store_heap_oop` branch, `r14` is corrupted at the second call and we get a segfault. > - `generate_buffered_inline_type_adapter` in `sharedRuntime_x86_64.cpp`: same with register `rax` being corrupted in a loop. > - `pack_inline_helper` ... This pull request has now been integrated. Changeset: d8438ac7 Author: Marc Chevalier URL: https://git.openjdk.org/valhalla/commit/d8438ac789f1425030dc61403384f9fbb548ee13 Stats: 118 lines in 9 files changed: 35 ins; 55 del; 28 mod 8366717: [lworld] Cleanup defensive fixing of JDK-8365996 Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1824 From mcimadamore at openjdk.org Thu Jan 8 12:38:43 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 Jan 2026 12:38:43 GMT Subject: RFR: More parser fixes for null restricted types Message-ID: <9SAgr8DKbFwQ926XoBY1osMZVadFxU978qxSn7RFygk=.6853e8d2-b1ef-4fd0-95a7-af36fe68920d@github.com> This PR fixes a number of leftover issues in the parser: * sometimes the parser accepts `!` before the type arguments of a generic type * null restrictions parsed as part of the array type in an array creation expression are dropped on the floor * null restrictions appearing (erroneously) before an array initializer causes spurious parser errors, as parsers doesn't take bangs into account ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/valhalla/pull/1868/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1868&range=00 Stats: 58 lines in 4 files changed: 38 ins; 4 del; 16 mod Patch: https://git.openjdk.org/valhalla/pull/1868.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1868/head:pull/1868 PR: https://git.openjdk.org/valhalla/pull/1868 From coleenp at openjdk.org Thu Jan 8 13:13:56 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 Jan 2026 13:13:56 GMT Subject: [lworld] RFR: 8374554: [lworld] Field layout assert with UseCompactObjectHeaders [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 18:26:34 GMT, Frederic Parain wrote: >> Fix an issue in the logic processing the beginning of a field layout, abstract value class with fields were processing correctly. >> >> Add more configurations to tests in order to cover compact object headers too. >> Re-enabled some tests that were disabled, an extended them to cover compact object headers too. >> >> Tested with Mach5 tier 1 to 3. >> >> Thank you, >> >> Fred > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > Fixes from review Meant to approve with the last comment... ------------- Marked as reviewed by coleenp (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1862#pullrequestreview-3639357149 From fparain at openjdk.org Thu Jan 8 13:13:57 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 8 Jan 2026 13:13:57 GMT Subject: [lworld] RFR: 8374554: [lworld] Field layout assert with UseCompactObjectHeaders In-Reply-To: References: Message-ID: <87gS15qbfyWeXuRu8mdMt8CW63V5gS9jL-VosMmIWhY=.5d4e9422-2956-40fa-b6ce-4542dddbcd9f@github.com> On Wed, 7 Jan 2026 17:31:21 GMT, Coleen Phillimore wrote: >> Fix an issue in the logic processing the beginning of a field layout, abstract value class with fields were processing correctly. >> >> Add more configurations to tests in order to cover compact object headers too. >> Re-enabled some tests that were disabled, an extended them to cover compact object headers too. >> >> Tested with Mach5 tier 1 to 3. >> >> Thank you, >> >> Fred > > Also Happy New Year! Can you update copyright headers? Thanks @coleenp for the review. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1862#issuecomment-3723812971 From fparain at openjdk.org Thu Jan 8 13:13:58 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 8 Jan 2026 13:13:58 GMT Subject: [lworld] Integrated: 8374554: [lworld] Field layout assert with UseCompactObjectHeaders In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:44:23 GMT, Frederic Parain wrote: > Fix an issue in the logic processing the beginning of a field layout, abstract value class with fields were processing correctly. > > Add more configurations to tests in order to cover compact object headers too. > Re-enabled some tests that were disabled, an extended them to cover compact object headers too. > > Tested with Mach5 tier 1 to 3. > > Thank you, > > Fred This pull request has now been integrated. Changeset: 093d033c Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/093d033cab1bc618bc11512f84d5aa62fe4ab7d8 Stats: 318 lines in 5 files changed: 208 ins; 23 del; 87 mod 8374554: [lworld] Field layout assert with UseCompactObjectHeaders Reviewed-by: coleenp ------------- PR: https://git.openjdk.org/valhalla/pull/1862 From fparain at openjdk.org Thu Jan 8 13:47:39 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 8 Jan 2026 13:47:39 GMT Subject: [lworld] RFR: 8374165: [lworld] Shortcut in value copying can lead to incorrect substitutability tests Message-ID: <-jKa7m9lQO6PlIH7Gn5qDky9FM6eCoXa0w1wJ3TY2l0=.351b397e-15ff-42ec-9086-e011505588ca@github.com> Remove an optimization in value copying that could cause incorrect results with the new substitutability test method. Tested with Mach5 tier 1-3. Thank you, Fred ------------- Commit messages: - Merge remote-tracking branch 'upstream/lworld' into subst_shortcut - Remove shortcut in value copying Changes: https://git.openjdk.org/valhalla/pull/1869/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1869&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374165 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1869.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1869/head:pull/1869 PR: https://git.openjdk.org/valhalla/pull/1869 From vromero at openjdk.org Thu Jan 8 13:58:48 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 8 Jan 2026 13:58:48 GMT Subject: RFR: More parser fixes for null restricted types In-Reply-To: <9SAgr8DKbFwQ926XoBY1osMZVadFxU978qxSn7RFygk=.6853e8d2-b1ef-4fd0-95a7-af36fe68920d@github.com> References: <9SAgr8DKbFwQ926XoBY1osMZVadFxU978qxSn7RFygk=.6853e8d2-b1ef-4fd0-95a7-af36fe68920d@github.com> Message-ID: <56VYG1WXlOfsGMGKK3gI3mnkZdwIv7gTI4d0qsF1l5s=.682b88fc-455d-4e39-8caf-3acef5285b8e@github.com> On Thu, 8 Jan 2026 12:33:52 GMT, Maurizio Cimadamore wrote: > This PR fixes a number of leftover issues in the parser: > * sometimes the parser accepts `!` before the type arguments of a generic type > * null restrictions parsed as part of the array type in an array creation expression are dropped on the floor > * null restrictions appearing (erroneously) before an array initializer causes spurious parser errors, as parsers doesn't take bangs into account lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1868#pullrequestreview-3639535968 From mcimadamore at openjdk.org Thu Jan 8 14:02:34 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 Jan 2026 14:02:34 GMT Subject: RFR: More parser fixes for null restricted types [v2] In-Reply-To: <9SAgr8DKbFwQ926XoBY1osMZVadFxU978qxSn7RFygk=.6853e8d2-b1ef-4fd0-95a7-af36fe68920d@github.com> References: <9SAgr8DKbFwQ926XoBY1osMZVadFxU978qxSn7RFygk=.6853e8d2-b1ef-4fd0-95a7-af36fe68920d@github.com> Message-ID: > This PR fixes a number of leftover issues in the parser: > * sometimes the parser accepts `!` before the type arguments of a generic type > * null restrictions parsed as part of the array type in an array creation expression are dropped on the floor > * null restrictions appearing (erroneously) before an array initializer causes spurious parser errors, as parsers doesn't take bangs into account Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add better parsing logic for method references ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1868/files - new: https://git.openjdk.org/valhalla/pull/1868/files/05d64fe6..f56d1193 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1868&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1868&range=00-01 Stats: 49 lines in 3 files changed: 33 ins; 9 del; 7 mod Patch: https://git.openjdk.org/valhalla/pull/1868.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1868/head:pull/1868 PR: https://git.openjdk.org/valhalla/pull/1868 From mcimadamore at openjdk.org Thu Jan 8 15:17:36 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 Jan 2026 15:17:36 GMT Subject: RFR: More parser fixes for null restricted types [v3] In-Reply-To: <9SAgr8DKbFwQ926XoBY1osMZVadFxU978qxSn7RFygk=.6853e8d2-b1ef-4fd0-95a7-af36fe68920d@github.com> References: <9SAgr8DKbFwQ926XoBY1osMZVadFxU978qxSn7RFygk=.6853e8d2-b1ef-4fd0-95a7-af36fe68920d@github.com> Message-ID: > This PR fixes a number of leftover issues in the parser: > * sometimes the parser accepts `!` before the type arguments of a generic type > * null restrictions parsed as part of the array type in an array creation expression are dropped on the floor > * null restrictions appearing (erroneously) before an array initializer causes spurious parser errors, as parsers doesn't take bangs into account > * null restriction in method reference type qualifier leads to spurious errors > * null restriction in inner class creation expressions leads to spurious errors Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix issue with inner class creation ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1868/files - new: https://git.openjdk.org/valhalla/pull/1868/files/f56d1193..1b4f0326 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1868&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1868&range=01-02 Stats: 37 lines in 3 files changed: 32 ins; 1 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1868.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1868/head:pull/1868 PR: https://git.openjdk.org/valhalla/pull/1868 From vromero at openjdk.org Thu Jan 8 15:23:27 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 8 Jan 2026 15:23:27 GMT Subject: RFR: More parser fixes for null restricted types [v3] In-Reply-To: References: <9SAgr8DKbFwQ926XoBY1osMZVadFxU978qxSn7RFygk=.6853e8d2-b1ef-4fd0-95a7-af36fe68920d@github.com> Message-ID: On Thu, 8 Jan 2026 15:17:36 GMT, Maurizio Cimadamore wrote: >> This PR fixes a number of leftover issues in the parser: >> * sometimes the parser accepts `!` before the type arguments of a generic type >> * null restrictions parsed as part of the array type in an array creation expression are dropped on the floor >> * null restrictions appearing (erroneously) before an array initializer causes spurious parser errors, as parsers doesn't take bangs into account >> * null restriction in method reference type qualifier leads to spurious errors >> * null restriction in inner class creation expressions leads to spurious errors > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix issue with inner class creation lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1868#pullrequestreview-3639911010 From mcimadamore at openjdk.org Thu Jan 8 15:47:46 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 Jan 2026 15:47:46 GMT Subject: Integrated: More parser fixes for null restricted types In-Reply-To: <9SAgr8DKbFwQ926XoBY1osMZVadFxU978qxSn7RFygk=.6853e8d2-b1ef-4fd0-95a7-af36fe68920d@github.com> References: <9SAgr8DKbFwQ926XoBY1osMZVadFxU978qxSn7RFygk=.6853e8d2-b1ef-4fd0-95a7-af36fe68920d@github.com> Message-ID: On Thu, 8 Jan 2026 12:33:52 GMT, Maurizio Cimadamore wrote: > This PR fixes a number of leftover issues in the parser: > * sometimes the parser accepts `!` before the type arguments of a generic type > * null restrictions parsed as part of the array type in an array creation expression are dropped on the floor > * null restrictions appearing (erroneously) before an array initializer causes spurious parser errors, as parsers doesn't take bangs into account > * null restriction in method reference type qualifier leads to spurious errors > * null restriction in inner class creation expressions leads to spurious errors This pull request has now been integrated. Changeset: 0b9edcb9 Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/0b9edcb909c4df5ccc2030717ae6c9516b983791 Stats: 131 lines in 4 files changed: 99 ins; 10 del; 22 mod More parser fixes for null restricted types Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1868 From mcimadamore at openjdk.org Thu Jan 8 16:40:53 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 Jan 2026 16:40:53 GMT Subject: RFR: Fix erasure of null-restricted types Message-ID: There are two issues with erasing null-restricted types: * not all the code paths in `Types::erasure` drop null restrictions * for some types like `String`, `Types::erasure` treats erasure as a no-op ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/valhalla/pull/1870/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1870&range=00 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1870.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1870/head:pull/1870 PR: https://git.openjdk.org/valhalla/pull/1870 From vromero at openjdk.org Thu Jan 8 16:40:54 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 8 Jan 2026 16:40:54 GMT Subject: RFR: Fix erasure of null-restricted types In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 16:29:58 GMT, Maurizio Cimadamore wrote: > There are two issues with erasing null-restricted types: > * not all the code paths in `Types::erasure` drop null restrictions > * for some types like `String`, `Types::erasure` treats erasure as a no-op lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1870#pullrequestreview-3640260698 From mcimadamore at openjdk.org Thu Jan 8 16:47:23 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 Jan 2026 16:47:23 GMT Subject: Integrated: Fix erasure of null-restricted types In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 16:29:58 GMT, Maurizio Cimadamore wrote: > There are two issues with erasing null-restricted types: > * not all the code paths in `Types::erasure` drop null restrictions > * for some types like `String`, `Types::erasure` treats erasure as a no-op This pull request has now been integrated. Changeset: 1d5dfc24 Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/1d5dfc248be9734748af5054f7f7716cb3e692d9 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Fix erasure of null-restricted types Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1870 From coleenp at openjdk.org Thu Jan 8 17:12:12 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 Jan 2026 17:12:12 GMT Subject: [lworld] RFR: 8366774: [lworld] runtime/cds/TestDefaultArchiveLoading.java started failing since jdk-25+26 Message-ID: This change both enables the UseCompactObjectHeaders archives for valhalla and fixes the test that looks for the archives. Testing with tier1-3 with --enable-preview and -XX:+UseCompactObjectHeaders. ------------- Commit messages: - [lworld] Generate COH archives Changes: https://git.openjdk.org/valhalla/pull/1871/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1871&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366774 Stats: 20 lines in 4 files changed: 8 ins; 3 del; 9 mod Patch: https://git.openjdk.org/valhalla/pull/1871.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1871/head:pull/1871 PR: https://git.openjdk.org/valhalla/pull/1871 From mcimadamore at openjdk.org Thu Jan 8 19:17:23 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 Jan 2026 19:17:23 GMT Subject: RFR: Downgrade subtyping/cast failures from errors to warnings Message-ID: This PR reverts all changes to subtyping and cast conversion, meaning that assigning `null` to a null-restricted type is no longer an error. I've resurrected the lint `null` category, to issue a warning in such cases. There's some stuff left to do, as I realized that the compiler swallows null markers when emitting diagnostics. This is due to a conundrum in the diagnostic formatter calling `stripMetadata`, and that resulting in _all_ metadata (not just type annos) to be lost. ------------- Commit messages: - Remove spurious changes - Revert changes to stripMetadata & friends - Initial push Changes: https://git.openjdk.org/valhalla/pull/1872/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1872&range=00 Stats: 208 lines in 11 files changed: 138 ins; 49 del; 21 mod Patch: https://git.openjdk.org/valhalla/pull/1872.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1872/head:pull/1872 PR: https://git.openjdk.org/valhalla/pull/1872 From mcimadamore at openjdk.org Thu Jan 8 19:17:25 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 8 Jan 2026 19:17:25 GMT Subject: RFR: Downgrade subtyping/cast failures from errors to warnings In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:11:03 GMT, Maurizio Cimadamore wrote: > This PR reverts all changes to subtyping and cast conversion, meaning that assigning `null` to a null-restricted type is no longer an error. > I've resurrected the lint `null` category, to issue a warning in such cases. > > There's some stuff left to do, as I realized that the compiler swallows null markers when emitting diagnostics. This is due to a conundrum in the diagnostic formatter calling `stripMetadata`, and that resulting in _all_ metadata (not just type annos) to be lost. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4390: > 4388: compiler.warn.suspicious.nullness.conversion=\ > 4389: Suspicious nullness conversion\n\ > 4390: required: {0}!\n\ Note the `!` here -- it's an hack, since the compiler swallows it :-( ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1872#discussion_r2673551219 From heidinga at openjdk.org Thu Jan 8 19:27:57 2026 From: heidinga at openjdk.org (Dan Heidinga) Date: Thu, 8 Jan 2026 19:27:57 GMT Subject: [lworld] RFR: 8374165: [lworld] Shortcut in value copying can lead to incorrect substitutability tests In-Reply-To: <-jKa7m9lQO6PlIH7Gn5qDky9FM6eCoXa0w1wJ3TY2l0=.351b397e-15ff-42ec-9086-e011505588ca@github.com> References: <-jKa7m9lQO6PlIH7Gn5qDky9FM6eCoXa0w1wJ3TY2l0=.351b397e-15ff-42ec-9086-e011505588ca@github.com> Message-ID: On Thu, 8 Jan 2026 13:40:42 GMT, Frederic Parain wrote: > Remove an optimization in value copying that could cause incorrect results with the new substitutability test method. > > Tested with Mach5 tier 1-3. > > Thank you, > > Fred Change is straight forward and correct. Copying this comment from jbs for context in why this is the right approach: >The goal is to keep the default implementation of the substitutability test, and its companion the identity hash code method, as simple as possible. It is possible to make this implementation aware of the null-marker and its semantic, but it would make the code much more complex. Resetting a flat value by rewriting its whole content when it is nullified is a simple approach, as the code to do that is already available for values containing oops. A specialized version of the substitutability test, like the one a JIT can generate for a particular value type, can perfectly have a different approach and use the null-marker as indicators to skip comparison of some memory segments. ------------- Marked as reviewed by heidinga (no project role). PR Review: https://git.openjdk.org/valhalla/pull/1869#pullrequestreview-3640920060 From coleenp at openjdk.org Thu Jan 8 21:04:43 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 Jan 2026 21:04:43 GMT Subject: [lworld] RFR: 8374165: [lworld] Shortcut in value copying can lead to incorrect substitutability tests In-Reply-To: <-jKa7m9lQO6PlIH7Gn5qDky9FM6eCoXa0w1wJ3TY2l0=.351b397e-15ff-42ec-9086-e011505588ca@github.com> References: <-jKa7m9lQO6PlIH7Gn5qDky9FM6eCoXa0w1wJ3TY2l0=.351b397e-15ff-42ec-9086-e011505588ca@github.com> Message-ID: On Thu, 8 Jan 2026 13:40:42 GMT, Frederic Parain wrote: > Remove an optimization in value copying that could cause incorrect results with the new substitutability test method. > > Tested with Mach5 tier 1-3. > > Thank you, > > Fred Looks good. ------------- Marked as reviewed by coleenp (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1869#pullrequestreview-3641289406 From matsaave at openjdk.org Thu Jan 8 21:04:44 2026 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 8 Jan 2026 21:04:44 GMT Subject: [lworld] RFR: 8374165: [lworld] Shortcut in value copying can lead to incorrect substitutability tests In-Reply-To: <-jKa7m9lQO6PlIH7Gn5qDky9FM6eCoXa0w1wJ3TY2l0=.351b397e-15ff-42ec-9086-e011505588ca@github.com> References: <-jKa7m9lQO6PlIH7Gn5qDky9FM6eCoXa0w1wJ3TY2l0=.351b397e-15ff-42ec-9086-e011505588ca@github.com> Message-ID: On Thu, 8 Jan 2026 13:40:42 GMT, Frederic Parain wrote: > Remove an optimization in value copying that could cause incorrect results with the new substitutability test method. > > Tested with Mach5 tier 1-3. > > Thank you, > > Fred LGTM! ------------- Marked as reviewed by matsaave (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1869#pullrequestreview-3641296789 From fparain at openjdk.org Thu Jan 8 21:04:45 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 8 Jan 2026 21:04:45 GMT Subject: [lworld] RFR: 8374165: [lworld] Shortcut in value copying can lead to incorrect substitutability tests In-Reply-To: References: <-jKa7m9lQO6PlIH7Gn5qDky9FM6eCoXa0w1wJ3TY2l0=.351b397e-15ff-42ec-9086-e011505588ca@github.com> Message-ID: On Thu, 8 Jan 2026 19:24:56 GMT, Dan Heidinga wrote: >> Remove an optimization in value copying that could cause incorrect results with the new substitutability test method. >> >> Tested with Mach5 tier 1-3. >> >> Thank you, >> >> Fred > > Change is straight forward and correct. > > Copying this comment from jbs for context in why this is the right approach: >>The goal is to keep the default implementation of the substitutability test, and its companion the identity hash code method, as simple as possible. It is possible to make this implementation aware of the null-marker and its semantic, but it would make the code much more complex. Resetting a flat value by rewriting its whole content when it is nullified is a simple approach, as the code to do that is already available for values containing oops. > A specialized version of the substitutability test, like the one a JIT can generate for a particular value type, can perfectly have a different approach and use the null-marker as indicators to skip comparison of some memory segments. Thanks @DanHeidinga @coleenp for the reviews. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1869#issuecomment-3725783318 From fparain at openjdk.org Thu Jan 8 21:04:45 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 8 Jan 2026 21:04:45 GMT Subject: [lworld] Integrated: 8374165: [lworld] Shortcut in value copying can lead to incorrect substitutability tests In-Reply-To: <-jKa7m9lQO6PlIH7Gn5qDky9FM6eCoXa0w1wJ3TY2l0=.351b397e-15ff-42ec-9086-e011505588ca@github.com> References: <-jKa7m9lQO6PlIH7Gn5qDky9FM6eCoXa0w1wJ3TY2l0=.351b397e-15ff-42ec-9086-e011505588ca@github.com> Message-ID: On Thu, 8 Jan 2026 13:40:42 GMT, Frederic Parain wrote: > Remove an optimization in value copying that could cause incorrect results with the new substitutability test method. > > Tested with Mach5 tier 1-3. > > Thank you, > > Fred This pull request has now been integrated. Changeset: 13abe7d1 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/13abe7d1172a3e6a31a76756be8810b674f35ad4 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod 8374165: [lworld] Shortcut in value copying can lead to incorrect substitutability tests Reviewed-by: heidinga, coleenp, matsaave ------------- PR: https://git.openjdk.org/valhalla/pull/1869 From fparain at openjdk.org Thu Jan 8 21:26:14 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 8 Jan 2026 21:26:14 GMT Subject: [lworld] RFR: 8374810: [lworld] Generate COH archives In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 16:51:20 GMT, Coleen Phillimore wrote: > This change both enables the UseCompactObjectHeaders archives for valhalla and fixes the test that looks for the archives. Testing with tier1-3 with --enable-preview and -XX:+UseCompactObjectHeaders. Looks good to me. But I have a question that could be addressed in a different patch: why is the suffix of the archive still '_valhalla' ? Shouldn't it be '_preview' now that the "Valhalla" mode is controlled by the "--enable-preview" option? ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1871#pullrequestreview-3641372777 From vromero at openjdk.org Thu Jan 8 22:34:29 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 8 Jan 2026 22:34:29 GMT Subject: RFR: Downgrade subtyping/cast failures from errors to warnings In-Reply-To: References: Message-ID: <6Q-j44cN7LL7aNor-bKDpZ8dX4mN2Z7bTuCzu5WQJgA=.35079129-ee00-4f4b-bf58-309754b00a8e@github.com> On Thu, 8 Jan 2026 19:11:46 GMT, Maurizio Cimadamore wrote: >> This PR reverts all changes to subtyping and cast conversion, meaning that assigning `null` to a null-restricted type is no longer an error. >> I've resurrected the lint `null` category, to issue a warning in such cases. >> >> There's some stuff left to do, as I realized that the compiler swallows null markers when emitting diagnostics. This is due to a conundrum in the diagnostic formatter calling `stripMetadata`, and that resulting in _all_ metadata (not just type annos) to be lost. > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4390: > >> 4388: compiler.warn.suspicious.nullness.conversion=\ >> 4389: Suspicious nullness conversion\n\ >> 4390: required: {0}!\n\ > > Note the `!` here -- it's an hack, since the compiler swallows it :-( hehe, good one ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1872#discussion_r2674126601 From vromero at openjdk.org Thu Jan 8 22:38:40 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 8 Jan 2026 22:38:40 GMT Subject: RFR: Downgrade subtyping/cast failures from errors to warnings In-Reply-To: References: Message-ID: <5kjcO02bKBtS6VCqW9MjnnCynPtJthr6tuSKNHCK0d4=.3cfa2773-dff4-4be9-a577-6c2a65c1522a@github.com> On Thu, 8 Jan 2026 19:11:03 GMT, Maurizio Cimadamore wrote: > This PR reverts all changes to subtyping and cast conversion, meaning that assigning `null` to a null-restricted type is no longer an error. > I've resurrected the lint `null` category, to issue a warning in such cases. > > There's some stuff left to do, as I realized that the compiler swallows null markers when emitting diagnostics. This is due to a conundrum in the diagnostic formatter calling `stripMetadata`, and that resulting in _all_ metadata (not just type annos) to be lost. Marked as reviewed by vromero (Committer). lgtm ------------- PR Review: https://git.openjdk.org/valhalla/pull/1872#pullrequestreview-3641593052 Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1872#pullrequestreview-3641594052 From coleenp at openjdk.org Thu Jan 8 23:18:18 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 Jan 2026 23:18:18 GMT Subject: [lworld] RFR: 8374810: [lworld] Generate COH archives In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 16:51:20 GMT, Coleen Phillimore wrote: > This change both enables the UseCompactObjectHeaders archives for valhalla and fixes the test that looks for the archives. Testing with tier1-3 with --enable-preview and -XX:+UseCompactObjectHeaders. Thank you Fred. I think we might have to go through and rename the _valhalla in the archive to something else. I'm not sure how many files are affected so I wouldn't do that here. And we should see if everyone agrees on a new name. The _preview suffix might be good. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1871#issuecomment-3726326644 From mcimadamore at openjdk.org Fri Jan 9 09:57:24 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 09:57:24 GMT Subject: Integrated: Downgrade subtyping/cast failures from errors to warnings In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:11:03 GMT, Maurizio Cimadamore wrote: > This PR reverts all changes to subtyping and cast conversion, meaning that assigning `null` to a null-restricted type is no longer an error. > I've resurrected the lint `null` category, to issue a warning in such cases. > > There's some stuff left to do, as I realized that the compiler swallows null markers when emitting diagnostics. This is due to a conundrum in the diagnostic formatter calling `stripMetadata`, and that resulting in _all_ metadata (not just type annos) to be lost. This pull request has now been integrated. Changeset: 09204505 Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/092045052619c33bcbdee3f25d900ab8b516c4f9 Stats: 208 lines in 11 files changed: 138 ins; 49 del; 21 mod Downgrade subtyping/cast failures from errors to warnings Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1872 From qamai at openjdk.org Fri Jan 9 10:06:53 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 9 Jan 2026 10:06:53 GMT Subject: [lworld] RFR: 8372259: [lworld] Merge of 8327963 produces assertion escape.cpp "new projection should have been allocated" Message-ID: There are 2 issues here: - The markword of an allocation is set incorrectly during GraphKit::set_outputs_for_allocation - Compile::adjust_flat_array_access_aliases does not work when there is no MemNode into flat arrays, but we can have allocations, which introduce NarrowMemProjs, and in that case we need to handle it, too. This PR solves these issues, most of the changes are identation changes only. Please kindly review, thanks a lot. ------------- Commit messages: - Fix incorrect markword projection of allocations, fix Compile::adjust_flat_array_access_aliases when there is no MemNode Changes: https://git.openjdk.org/valhalla/pull/1873/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1873&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372259 Stats: 332 lines in 4 files changed: 75 ins; 82 del; 175 mod Patch: https://git.openjdk.org/valhalla/pull/1873.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1873/head:pull/1873 PR: https://git.openjdk.org/valhalla/pull/1873 From jsikstro at openjdk.org Fri Jan 9 10:32:52 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 9 Jan 2026 10:32:52 GMT Subject: [lworld] RFR: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp Message-ID: Hello, The hierarchies in oopsHierarchy.hpp are not up to date with the actual class hierarchies in the implementation. I've refered to these a couple of times and stumble on the fact that they are not accurate. I've tested that this builds locally. ------------- Commit messages: - 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp Changes: https://git.openjdk.org/valhalla/pull/1874/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1874&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374882 Stats: 6 lines in 1 file changed: 3 ins; 2 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1874.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1874/head:pull/1874 PR: https://git.openjdk.org/valhalla/pull/1874 From phubner at openjdk.org Fri Jan 9 11:04:26 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Fri, 9 Jan 2026 11:04:26 GMT Subject: [lworld] RFR: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 10:27:39 GMT, Joel Sikstr?m wrote: > Hello, > > The hierarchies in oopsHierarchy.hpp are not up to date with the actual class hierarchies in the implementation. I've refered to these a couple of times and stumble on the fact that they are not accurate. > > I've tested that this builds locally. Long overdue, thanks for doing this. Makes it clear that the `refArrayOopDesc` is a bit special. ------------- Marked as reviewed by phubner (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1874#pullrequestreview-3643445372 From jsikstro at openjdk.org Fri Jan 9 11:31:17 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 9 Jan 2026 11:31:17 GMT Subject: [lworld] RFR: 8374887: [lworld] Cleanup around vgetfield/vputfield for x86 Message-ID: Hello, This is a follow up from [JDK-8374093](https://bugs.openjdk.org/browse/JDK-8374093) cleaning up the x86 implementation as well. Testing: * hotspot_valhalla and jdk_valhalla on x86-64 ------------- Commit messages: - 8374887: [lworld] Cleanup around vgetfield/vputfield for x86 Changes: https://git.openjdk.org/valhalla/pull/1875/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1875&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374887 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1875.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1875/head:pull/1875 PR: https://git.openjdk.org/valhalla/pull/1875 From fparain at openjdk.org Fri Jan 9 12:11:32 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 9 Jan 2026 12:11:32 GMT Subject: [lworld] RFR: 8374887: [lworld] Cleanup around vgetfield/vputfield for x86 In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 11:25:35 GMT, Joel Sikstr?m wrote: > Hello, > > This is a follow up from [JDK-8374093](https://bugs.openjdk.org/browse/JDK-8374093) cleaning up the x86 implementation as well. > > Testing: > * hotspot_valhalla and jdk_valhalla on x86-64 LGTM ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1875#pullrequestreview-3643661611 From fparain at openjdk.org Fri Jan 9 12:14:36 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 9 Jan 2026 12:14:36 GMT Subject: [lworld] RFR: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 10:27:39 GMT, Joel Sikstr?m wrote: > Hello, > > The hierarchies in oopsHierarchy.hpp are not up to date with the actual class hierarchies in the implementation. I've refered to these a couple of times and stumble on the fact that they are not accurate. > > I've tested that this builds locally. src/hotspot/share/oops/oopsHierarchy.hpp line 49: > 47: typedef class objArrayOopDesc* objArrayOop; > 48: typedef class flatArrayOopDesc* flatArrayOop; > 49: typedef class refArrayOopDesc* refArrayOop; Shouldn't refArrayOopDesc be aligned with flatArrayOopDesc? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1874#discussion_r2675967813 From phubner at openjdk.org Fri Jan 9 12:14:37 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Fri, 9 Jan 2026 12:14:37 GMT Subject: [lworld] RFR: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:11:22 GMT, Frederic Parain wrote: >> Hello, >> >> The hierarchies in oopsHierarchy.hpp are not up to date with the actual class hierarchies in the implementation. I've refered to these a couple of times and stumble on the fact that they are not accurate. >> >> I've tested that this builds locally. > > src/hotspot/share/oops/oopsHierarchy.hpp line 49: > >> 47: typedef class objArrayOopDesc* objArrayOop; >> 48: typedef class flatArrayOopDesc* flatArrayOop; >> 49: typedef class refArrayOopDesc* refArrayOop; > > Shouldn't refArrayOopDesc be aligned with flatArrayOopDesc? I don't think so: `class refArrayOopDesc : public arrayOopDesc {` ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1874#discussion_r2675970685 From mcimadamore at openjdk.org Fri Jan 9 12:36:34 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 12:36:34 GMT Subject: RFR: Add checks to reject creation of non-empty null-restricted arrays w/o initializer Message-ID: This PR adds checks in `Attr` so that creation of non-empty null-restricted arrays w/o an initializer is not allowed. The code is very careful in determining situations where null-restrictions on the array element type are irrelevant, such as: * when the array size is a constant zero - `new String![0]` -- as in this case the restricted array is empty, so there's nothing to initialize * when one or more dimensions are missing - `new String![10][]` -- as in this case the outer array (of size 10) is just filled with `null`s, as the inner array lacks a size * when one or more intermediate dimensions is the constant zero - `new String[0][10]` -- as in this case nothing is really created, as the outer array is empty A test has been added to (hopefully) cover all such pesky cases. ------------- Commit messages: - Fix regression tests - Merge branch 'bworld' into restricted_array_new_attr - Initial push - Remove spurious changes - Revert changes to stripMetadata & friends - Initial push Changes: https://git.openjdk.org/valhalla/pull/1876/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1876&range=00 Stats: 56 lines in 6 files changed: 53 ins; 0 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1876.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1876/head:pull/1876 PR: https://git.openjdk.org/valhalla/pull/1876 From vromero at openjdk.org Fri Jan 9 13:47:14 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 13:47:14 GMT Subject: RFR: Add checks to reject creation of non-empty null-restricted arrays w/o initializer In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:28:59 GMT, Maurizio Cimadamore wrote: > This PR adds checks in `Attr` so that creation of non-empty null-restricted arrays w/o an initializer is not allowed. > > The code is very careful in determining situations where null-restrictions on the array element type are irrelevant, such as: > > * when the array size is a constant zero - `new String![0]` -- as in this case the restricted array is empty, so there's nothing to initialize > * when one or more dimensions are missing - `new String![10][]` -- as in this case the outer array (of size 10) is just filled with `null`s, as the inner array lacks a size > * when one or more intermediate dimensions is the constant zero - `new String[0][10]` -- as in this case nothing is really created, as the outer array is empty > > A test has been added to (hopefully) cover all such pesky cases. lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1876#pullrequestreview-3643986289 From fparain at openjdk.org Fri Jan 9 14:10:34 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 9 Jan 2026 14:10:34 GMT Subject: [lworld] RFR: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:12:23 GMT, Paul H?bner wrote: >> src/hotspot/share/oops/oopsHierarchy.hpp line 49: >> >>> 47: typedef class objArrayOopDesc* objArrayOop; >>> 48: typedef class flatArrayOopDesc* flatArrayOop; >>> 49: typedef class refArrayOopDesc* refArrayOop; >> >> Shouldn't refArrayOopDesc be aligned with flatArrayOopDesc? > > I don't think so: > `class refArrayOopDesc : public arrayOopDesc {` But : `class RefArrayKlass : public ObjArrayKlass ` So there's an unconsistency here, `refArrayOopDesc` should be a subclass of `objArrayOopDesc`. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1874#discussion_r2676322995 From phubner at openjdk.org Fri Jan 9 14:18:33 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Fri, 9 Jan 2026 14:18:33 GMT Subject: [lworld] RFR: 8374887: [lworld] Cleanup around vgetfield/vputfield for x86 In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 11:25:35 GMT, Joel Sikstr?m wrote: > Hello, > > This is a follow up from [JDK-8374093](https://bugs.openjdk.org/browse/JDK-8374093) cleaning up the x86 implementation as well. > > Testing: > * hotspot_valhalla and jdk_valhalla on x86-64 Thank you! ------------- Marked as reviewed by phubner (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1875#pullrequestreview-3644101560 From jsikstro at openjdk.org Fri Jan 9 14:42:36 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 9 Jan 2026 14:42:36 GMT Subject: [lworld] RFR: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 14:08:16 GMT, Frederic Parain wrote: >> I don't think so: >> `class refArrayOopDesc : public arrayOopDesc {` > > But : > `class RefArrayKlass : public ObjArrayKlass > ` > So there's an unconsistency here, `refArrayOopDesc` should be a subclass of `objArrayOopDesc`. I agree that it would be clearer to make `refArrayOopDesc` inherit from `objArrayOopDesc`. I'll run some tests to see if it's a simple "switch" to inherit from `objArrayOopDesc` instead. If it's a trivial change I can add it to this PR and change the hierarchy in oopsHierarchy.hpp, otherwise I suggest we should handle that in a follow-up. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1874#discussion_r2676427403 From mcimadamore at openjdk.org Fri Jan 9 15:06:08 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 15:06:08 GMT Subject: Integrated: Add checks to reject creation of non-empty null-restricted arrays w/o initializer In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:28:59 GMT, Maurizio Cimadamore wrote: > This PR adds checks in `Attr` so that creation of non-empty null-restricted arrays w/o an initializer is not allowed. > > The code is very careful in determining situations where null-restrictions on the array element type are irrelevant, such as: > > * when the array size is a constant zero - `new String![0]` -- as in this case the restricted array is empty, so there's nothing to initialize > * when one or more dimensions are missing - `new String![10][]` -- as in this case the outer array (of size 10) is just filled with `null`s, as the inner array lacks a size > * when one or more intermediate dimensions is the constant zero - `new String[0][10]` -- as in this case nothing is really created, as the outer array is empty > > A test has been added to (hopefully) cover all such pesky cases. This pull request has now been integrated. Changeset: 5a435683 Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/5a435683d9fe15631419669f8cd1249c37b0cdea Stats: 56 lines in 6 files changed: 53 ins; 0 del; 3 mod Add checks to reject creation of non-empty null-restricted arrays w/o initializer Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1876 From vromero at openjdk.org Fri Jan 9 15:18:53 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 15:18:53 GMT Subject: RFR: Generate missing null checks Message-ID: generate missing null checks like for method arguments, return arguments, etc ------------- Commit messages: - changes to test - Merge branch 'generate.missing.null.checks' of https://github.com/vicente-romero-oracle/valhalla into generate.missing.null.checks - recent changes - recent changes - Merge branch 'bworld' into generate.missing.null.checks - more changes - Merge branch 'generate.missing.null.checks' of https://github.com/vicente-romero-oracle/valhalla into generate.missing.null.checks - additional changes - additional changes - Merge branch 'bworld' into generate.missing.null.checks - ... and 1 more: https://git.openjdk.org/valhalla/compare/1d5dfc24...b676689c Changes: https://git.openjdk.org/valhalla/pull/1867/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=00 Stats: 376 lines in 6 files changed: 233 ins; 119 del; 24 mod Patch: https://git.openjdk.org/valhalla/pull/1867.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1867/head:pull/1867 PR: https://git.openjdk.org/valhalla/pull/1867 From vromero at openjdk.org Fri Jan 9 15:56:03 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 15:56:03 GMT Subject: RFR: Generate missing null checks [v2] In-Reply-To: References: Message-ID: > generate missing null checks like for method arguments, return arguments, etc Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: record patterns ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1867/files - new: https://git.openjdk.org/valhalla/pull/1867/files/b676689c..c58a9cfd Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=00-01 Stats: 9 lines in 2 files changed: 5 ins; 1 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1867.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1867/head:pull/1867 PR: https://git.openjdk.org/valhalla/pull/1867 From mcimadamore at openjdk.org Fri Jan 9 16:18:16 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 16:18:16 GMT Subject: RFR: Add alternate desugaring strategy for null-restricted arrays Message-ID: Creation of null-restricted arrays are desugared as calls into methods of the `ArrayCreation` class, as we need to set the "strict" marker on the created array. Currently the JVM doesn't support creation of null-restricted array for non-value types, so in this PR I cleaned up the `ArrayCreation` API to reflect more what javac needs. Also, according to our long term plans, `ArrayCreation` is really implemented on top of a new primitive in `Array`, which will be refined later to support creation of arrays with desired flags. The translation strategy in javac is simple -- given an array initializer `{ .. }`, we just assign the initializer to a temp variable, then wrap the initializer using a call to `ArrayCreation::copied` to obtain the new array. Then we wrap everything in a let expression, so that things compose nicely. While writing the test I realized that our combo framework failed to report compilation and execution failures. As I fixed that issue, I realized that a test I've added (`NullRestrictionReflectiveTest`) was not working correctly, as it had compilaton issues with some of the combinations and even a latent issue in signature parsing which I have now fixed. ------------- Commit messages: - Add regression test - Initial push Changes: https://git.openjdk.org/valhalla/pull/1877/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1877&range=00 Stats: 651 lines in 11 files changed: 199 ins; 385 del; 67 mod Patch: https://git.openjdk.org/valhalla/pull/1877.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1877/head:pull/1877 PR: https://git.openjdk.org/valhalla/pull/1877 From mcimadamore at openjdk.org Fri Jan 9 16:18:18 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 16:18:18 GMT Subject: RFR: Add alternate desugaring strategy for null-restricted arrays In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 16:11:11 GMT, Maurizio Cimadamore wrote: > Creation of null-restricted arrays are desugared as calls into methods of the `ArrayCreation` class, as we need to set the "strict" marker on the created array. > Currently the JVM doesn't support creation of null-restricted array for non-value types, so in this PR I cleaned up the `ArrayCreation` API to reflect more what javac needs. Also, according to our long term plans, `ArrayCreation` is really implemented on top of a new primitive in `Array`, which will be refined later to support creation of arrays with desired flags. > > The translation strategy in javac is simple -- given an array initializer `{ .. }`, we just assign the initializer to a temp variable, then wrap the initializer using a call to `ArrayCreation::copied` to obtain the new array. Then we wrap everything in a let expression, so that things compose nicely. > > While writing the test I realized that our combo framework failed to report compilation and execution failures. As I fixed that issue, I realized that a test I've added (`NullRestrictionReflectiveTest`) was not working correctly, as it had compilaton issues with some of the combinations and even a latent issue in signature parsing which I have now fixed. src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java line 600: > 598: case 'Z': > 599: case 'L': > 600: case '!': This fix is unrelated to this PR, but necessary to fix `NullRestrictionReflectiveTest` ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1877#discussion_r2676772006 From vromero at openjdk.org Fri Jan 9 16:25:37 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 16:25:37 GMT Subject: RFR: Generate missing null checks [v3] In-Reply-To: References: Message-ID: > generate missing null checks like for method arguments, return arguments, etc Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing NPE for patterns ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1867/files - new: https://git.openjdk.org/valhalla/pull/1867/files/c58a9cfd..02ba9234 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1867.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1867/head:pull/1867 PR: https://git.openjdk.org/valhalla/pull/1867 From mcimadamore at openjdk.org Fri Jan 9 16:25:42 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 16:25:42 GMT Subject: RFR: Generate missing null checks [v2] In-Reply-To: References: Message-ID: <61_cqilyXhoDHFHTZGdBojZxCOcSTfF7QXmxQURzVFg=.a9835fcc-00cb-4551-abf8-119585ea1c81@github.com> On Fri, 9 Jan 2026 15:56:03 GMT, Vicente Romero wrote: >> generate missing null checks like for method arguments, return arguments, etc > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > record patterns src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 102: > 100: /** Visitor argument: proto-type. > 101: */ > 102: private Type pt; This doesn't seem to be used? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 133: > 131: !types.isNonNullable(rhsSym.type)) { > 132: tree.rhs = translate(tree.rhs, types.erasure(tree.lhs.type)); > 133: tree.rhs = attr.makeNullCheck(tree.rhs, true); Shouldn't we use `generateNullCheckIfNeeded` always? (here and elsewhere) src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 188: > 186: public void visitReturn(JCReturn tree) { > 187: if (returnType != null && !returnType.hasTag(VOID)) { > 188: if (types.isNonNullable(returnType) && !types.isNonNullable(tree.expr.type)) { I think tree.expr.type will be erased by now? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 197: > 195: > 196: @Override > 197: public void visitLetExpr(LetExpr tree) { Why is this needed? Isn't this the default behavior? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3786: > 3784: return variableDeclarators(optFinal(0), parseType(true), stats, true).toList(); > 3785: } else { > 3786: JCExpression t = term(EXPR | TYPE | ALLOW_BANGS); Good catches! ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1867#discussion_r2676793888 PR Review Comment: https://git.openjdk.org/valhalla/pull/1867#discussion_r2676796499 PR Review Comment: https://git.openjdk.org/valhalla/pull/1867#discussion_r2676789324 PR Review Comment: https://git.openjdk.org/valhalla/pull/1867#discussion_r2676787273 PR Review Comment: https://git.openjdk.org/valhalla/pull/1867#discussion_r2676803148 From mcimadamore at openjdk.org Fri Jan 9 16:33:58 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 16:33:58 GMT Subject: RFR: Add alternate desugaring strategy for null-restricted arrays [v2] In-Reply-To: References: Message-ID: > Creation of null-restricted arrays are desugared as calls into methods of the `ArrayCreation` class, as we need to set the "strict" marker on the created array. > Currently the JVM doesn't support creation of null-restricted array for non-value types, so in this PR I cleaned up the `ArrayCreation` API to reflect more what javac needs. Also, according to our long term plans, `ArrayCreation` is really implemented on top of a new primitive in `Array`, which will be refined later to support creation of arrays with desired flags. > > The translation strategy in javac is simple -- given an array initializer `{ .. }`, we just assign the initializer to a temp variable, then wrap the initializer using a call to `ArrayCreation::copied` to obtain the new array. Then we wrap everything in a let expression, so that things compose nicely. > > While writing the test I realized that our combo framework failed to report compilation and execution failures. As I fixed that issue, I realized that a test I've added (`NullRestrictionReflectiveTest`) was not working correctly, as it had compilaton issues with some of the combinations and even a latent issue in signature parsing which I have now fixed. Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'bworld' into strict_array_trans - Add regression test Fix combo framework execution support to report compile/runtime issues - Initial push ------------- Changes: https://git.openjdk.org/valhalla/pull/1877/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1877&range=01 Stats: 649 lines in 11 files changed: 197 ins; 385 del; 67 mod Patch: https://git.openjdk.org/valhalla/pull/1877.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1877/head:pull/1877 PR: https://git.openjdk.org/valhalla/pull/1877 From vromero at openjdk.org Fri Jan 9 16:34:02 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 16:34:02 GMT Subject: RFR: Add alternate desugaring strategy for null-restricted arrays [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 16:31:13 GMT, Maurizio Cimadamore wrote: >> Creation of null-restricted arrays are desugared as calls into methods of the `ArrayCreation` class, as we need to set the "strict" marker on the created array. >> Currently the JVM doesn't support creation of null-restricted array for non-value types, so in this PR I cleaned up the `ArrayCreation` API to reflect more what javac needs. Also, according to our long term plans, `ArrayCreation` is really implemented on top of a new primitive in `Array`, which will be refined later to support creation of arrays with desired flags. >> >> The translation strategy in javac is simple -- given an array initializer `{ .. }`, we just assign the initializer to a temp variable, then wrap the initializer using a call to `ArrayCreation::copied` to obtain the new array. Then we wrap everything in a let expression, so that things compose nicely. >> >> While writing the test I realized that our combo framework failed to report compilation and execution failures. As I fixed that issue, I realized that a test I've added (`NullRestrictionReflectiveTest`) was not working correctly, as it had compilaton issues with some of the combinations and even a latent issue in signature parsing which I have now fixed. > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'bworld' into strict_array_trans > - Add regression test > Fix combo framework execution support to report compile/runtime issues > - Initial push src/java.base/share/classes/java/lang/runtime/ArrayCreation.java line 61: > 59: */ > 60: public static Object enumerated(Class componentType, int flags, Object v1) { > 61: return copied(componentType, flags, 3, new Object[] { v1 }); length should be `1` in this case src/java.base/share/classes/java/lang/runtime/ArrayCreation.java line 74: > 72: */ > 73: public static Object enumerated(Class componentType, int flags, Object v1, Object v2) { > 74: return copied(componentType, flags, 3, new Object[] { v1, v2 }); length should be `2` this time, I think src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 4304: > 4302: tree.elems = translate(tree.elems, types.elemtype(tree.type)); > 4303: if (tree.strict && tree.elems != null) { > 4304: Assert.check(types.dimensions(tree.type) == 1, "Unexpected multi-dimensional null-restricted array"); should this be a compiler error? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1877#discussion_r2676820586 PR Review Comment: https://git.openjdk.org/valhalla/pull/1877#discussion_r2676818887 PR Review Comment: https://git.openjdk.org/valhalla/pull/1877#discussion_r2676827715 From vromero at openjdk.org Fri Jan 9 16:39:20 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 16:39:20 GMT Subject: RFR: Generate missing null checks [v2] In-Reply-To: <61_cqilyXhoDHFHTZGdBojZxCOcSTfF7QXmxQURzVFg=.a9835fcc-00cb-4551-abf8-119585ea1c81@github.com> References: <61_cqilyXhoDHFHTZGdBojZxCOcSTfF7QXmxQURzVFg=.a9835fcc-00cb-4551-abf8-119585ea1c81@github.com> Message-ID: On Fri, 9 Jan 2026 16:15:39 GMT, Maurizio Cimadamore wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> record patterns > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 197: > >> 195: >> 196: @Override >> 197: public void visitLetExpr(LetExpr tree) { > > Why is this needed? Isn't this the default behavior? it was there for the pattern matching but removed it after our discussion, I forgot to update the PR, done ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1867#discussion_r2676852038 From mcimadamore at openjdk.org Fri Jan 9 16:39:35 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 16:39:35 GMT Subject: RFR: Add alternate desugaring strategy for null-restricted arrays [v3] In-Reply-To: References: Message-ID: > Creation of null-restricted arrays are desugared as calls into methods of the `ArrayCreation` class, as we need to set the "strict" marker on the created array. > Currently the JVM doesn't support creation of null-restricted array for non-value types, so in this PR I cleaned up the `ArrayCreation` API to reflect more what javac needs. Also, according to our long term plans, `ArrayCreation` is really implemented on top of a new primitive in `Array`, which will be refined later to support creation of arrays with desired flags. > > The translation strategy in javac is simple -- given an array initializer `{ .. }`, we just assign the initializer to a temp variable, then wrap the initializer using a call to `ArrayCreation::copied` to obtain the new array. Then we wrap everything in a let expression, so that things compose nicely. > > While writing the test I realized that our combo framework failed to report compilation and execution failures. As I fixed that issue, I realized that a test I've added (`NullRestrictionReflectiveTest`) was not working correctly, as it had compilaton issues with some of the combinations and even a latent issue in signature parsing which I have now fixed. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1877/files - new: https://git.openjdk.org/valhalla/pull/1877/files/0bf345a0..91b152e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1877&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1877&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1877.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1877/head:pull/1877 PR: https://git.openjdk.org/valhalla/pull/1877 From mcimadamore at openjdk.org Fri Jan 9 16:39:39 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 16:39:39 GMT Subject: RFR: Add alternate desugaring strategy for null-restricted arrays [v3] In-Reply-To: References: Message-ID: <59uSHmF1fbZVMSYLCggq4y-2dMVMrk1iOyuv_Dhsp6c=.3205f63b-64d5-4ac2-93f9-aa6dfabbe01e@github.com> On Fri, 9 Jan 2026 16:24:50 GMT, Vicente Romero wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/java.base/share/classes/java/lang/runtime/ArrayCreation.java line 74: > >> 72: */ >> 73: public static Object enumerated(Class componentType, int flags, Object v1, Object v2) { >> 74: return copied(componentType, flags, 3, new Object[] { v1, v2 }); > > length should be `2` this time, I think whoops > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 4304: > >> 4302: tree.elems = translate(tree.elems, types.elemtype(tree.type)); >> 4303: if (tree.strict && tree.elems != null) { >> 4304: Assert.check(types.dimensions(tree.type) == 1, "Unexpected multi-dimensional null-restricted array"); > > should this be a compiler error? Yes, it should be an error (in parser). But I'm just adding a sanity check (just in case) :-) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1877#discussion_r2676852438 PR Review Comment: https://git.openjdk.org/valhalla/pull/1877#discussion_r2676851627 From fparain at openjdk.org Fri Jan 9 16:39:50 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 9 Jan 2026 16:39:50 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout Message-ID: Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case. This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic. ------------- Commit messages: - Cleanups and fixes - Fix Copyright years - Fix compilation - Merge remote-tracking branch 'upstream/lworld' into flat_final - Improve tests - Merge remote-tracking branch 'upstream/lworld' into flat_final - Merge remote-tracking branch 'upstream/lworld' into flat_final - Add empty values case and some LayoutKindHelper cleanup - Merge remote-tracking branch 'upstream/lworld' into flat_final - Fix build after merge - ... and 3 more: https://git.openjdk.org/valhalla/compare/093d033c...972768c8 Changes: https://git.openjdk.org/valhalla/pull/1407/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1407&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374800 Stats: 673 lines in 16 files changed: 589 ins; 10 del; 74 mod Patch: https://git.openjdk.org/valhalla/pull/1407.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1407/head:pull/1407 PR: https://git.openjdk.org/valhalla/pull/1407 From qamai at openjdk.org Fri Jan 9 16:39:50 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 9 Jan 2026 16:39:50 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 20:49:25 GMT, Frederic Parain wrote: > Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case. > This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic. This would forbid the class which contains the `NULLABLE_NON_ATOMIC_FLAT` from being flattened into a class which contains it. I think we should only do so if the holder of the flattened strict final field should not be flattened if it is not itself a strict final field: - The holder is an identity class. - The holder is a large value class without `@LooselyConsistentValue`. This is equally valid to null-restricted field of non-`@LooselyConsistentValue`, too. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1407#issuecomment-2876555236 From vromero at openjdk.org Fri Jan 9 17:15:34 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 17:15:34 GMT Subject: RFR: Add alternate desugaring strategy for null-restricted arrays [v3] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 16:39:35 GMT, Maurizio Cimadamore wrote: >> Creation of null-restricted arrays are desugared as calls into methods of the `ArrayCreation` class, as we need to set the "strict" marker on the created array. >> Currently the JVM doesn't support creation of null-restricted array for non-value types, so in this PR I cleaned up the `ArrayCreation` API to reflect more what javac needs. Also, according to our long term plans, `ArrayCreation` is really implemented on top of a new primitive in `Array`, which will be refined later to support creation of arrays with desired flags. >> >> The translation strategy in javac is simple -- given an array initializer `{ .. }`, we just assign the initializer to a temp variable, then wrap the initializer using a call to `ArrayCreation::copied` to obtain the new array. Then we wrap everything in a let expression, so that things compose nicely. >> >> While writing the test I realized that our combo framework failed to report compilation and execution failures. As I fixed that issue, I realized that a test I've added (`NullRestrictionReflectiveTest`) was not working correctly, as it had compilaton issues with some of the combinations and even a latent issue in signature parsing which I have now fixed. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments looks good ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1877#pullrequestreview-3644840248 From mcimadamore at openjdk.org Fri Jan 9 17:19:05 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 17:19:05 GMT Subject: Integrated: Add alternate desugaring strategy for null-restricted arrays In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 16:11:11 GMT, Maurizio Cimadamore wrote: > Creation of null-restricted arrays are desugared as calls into methods of the `ArrayCreation` class, as we need to set the "strict" marker on the created array. > Currently the JVM doesn't support creation of null-restricted array for non-value types, so in this PR I cleaned up the `ArrayCreation` API to reflect more what javac needs. Also, according to our long term plans, `ArrayCreation` is really implemented on top of a new primitive in `Array`, which will be refined later to support creation of arrays with desired flags. > > The translation strategy in javac is simple -- given an array initializer `{ .. }`, we just assign the initializer to a temp variable, then wrap the initializer using a call to `ArrayCreation::copied` to obtain the new array. Then we wrap everything in a let expression, so that things compose nicely. > > While writing the test I realized that our combo framework failed to report compilation and execution failures. As I fixed that issue, I realized that a test I've added (`NullRestrictionReflectiveTest`) was not working correctly, as it had compilaton issues with some of the combinations and even a latent issue in signature parsing which I have now fixed. This pull request has now been integrated. Changeset: eff0f5d4 Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/eff0f5d456b86d34155b375846444eacacdbe180 Stats: 649 lines in 11 files changed: 197 ins; 385 del; 67 mod Add alternate desugaring strategy for null-restricted arrays Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1877 From vromero at openjdk.org Fri Jan 9 17:25:25 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 17:25:25 GMT Subject: RFR: Drop RuntimeType In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 17:18:29 GMT, Maurizio Cimadamore wrote: > This PR removes `RuntimeType`/`NullableClass` and related methods, as they are no longer used (after recent cleanup to `ArrayCreation`). lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1878#pullrequestreview-3644871467 From mcimadamore at openjdk.org Fri Jan 9 17:25:24 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 17:25:24 GMT Subject: RFR: Drop RuntimeType Message-ID: This PR removes `RuntimeType`/`NullableClass` and related methods, as they are no longer used (after recent cleanup to `ArrayCreation`). ------------- Commit messages: - Merge branch 'bworld' into drop_runtime_type - Drop RuntimeType/NullableClass - Address review comments - Merge branch 'bworld' into strict_array_trans - Add regression test - Initial push Changes: https://git.openjdk.org/valhalla/pull/1878/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1878&range=00 Stats: 250 lines in 7 files changed: 0 ins; 248 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1878.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1878/head:pull/1878 PR: https://git.openjdk.org/valhalla/pull/1878 From vromero at openjdk.org Fri Jan 9 17:31:06 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 17:31:06 GMT Subject: RFR: Generate missing null checks [v4] In-Reply-To: References: Message-ID: > generate missing null checks like for method arguments, return arguments, etc Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: - Merge branch 'bworld' into generate.missing.null.checks - addressing review comments - removing NPE for patterns - record patterns - changes to test - Merge branch 'generate.missing.null.checks' of https://github.com/vicente-romero-oracle/valhalla into generate.missing.null.checks - recent changes - recent changes - Merge branch 'bworld' into generate.missing.null.checks - more changes - ... and 5 more: https://git.openjdk.org/valhalla/compare/6937765e...ef7e0a7d ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1867/files - new: https://git.openjdk.org/valhalla/pull/1867/files/02ba9234..ef7e0a7d Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=02-03 Stats: 944 lines in 25 files changed: 391 ins; 451 del; 102 mod Patch: https://git.openjdk.org/valhalla/pull/1867.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1867/head:pull/1867 PR: https://git.openjdk.org/valhalla/pull/1867 From mcimadamore at openjdk.org Fri Jan 9 17:39:52 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 17:39:52 GMT Subject: Integrated: Drop RuntimeType In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 17:18:29 GMT, Maurizio Cimadamore wrote: > This PR removes `RuntimeType`/`NullableClass` and related methods, as they are no longer used (after recent cleanup to `ArrayCreation`). This pull request has now been integrated. Changeset: ce610d8d Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/ce610d8d0f42167905bdd6c2b95d0de2d8e0eb0f Stats: 250 lines in 7 files changed: 0 ins; 248 del; 2 mod Drop RuntimeType Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1878 From vromero at openjdk.org Fri Jan 9 18:18:40 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 18:18:40 GMT Subject: RFR: Generate missing null checks [v5] In-Reply-To: References: Message-ID: > generate missing null checks like for method arguments, return arguments, etc Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: last iteration ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1867/files - new: https://git.openjdk.org/valhalla/pull/1867/files/ef7e0a7d..b6032148 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=04 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=03-04 Stats: 31 lines in 5 files changed: 8 ins; 6 del; 17 mod Patch: https://git.openjdk.org/valhalla/pull/1867.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1867/head:pull/1867 PR: https://git.openjdk.org/valhalla/pull/1867 From mcimadamore at openjdk.org Fri Jan 9 18:27:31 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 18:27:31 GMT Subject: RFR: Generate missing null checks [v5] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 18:18:40 GMT, Vicente Romero wrote: >> generate missing null checks like for method arguments, return arguments, etc > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > last iteration src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 88: > 86: > 87: JCExpression generateNullCheckIfNeeded(JCExpression tree, JCNullableTypeExpression.NullMarker expectedNullness) { > 88: if (expectedNullness == JCNullableTypeExpression.NullMarker.NOT_NULL && !types.isNonNullable(tree.type)) { Isn't `types.isNonNullable(tree.type)` always false here? (since the type is erased) src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java line 910: > 908: tree.value.type = erasure(tree.value.type); > 909: tree.value = retype(tree.value, tree.value.type, pt); > 910: //result = generateNullCheckIfNeeded((JCExpression)result); Leftover? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1867#discussion_r2677176468 PR Review Comment: https://git.openjdk.org/valhalla/pull/1867#discussion_r2677181461 From vromero at openjdk.org Fri Jan 9 19:06:41 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 19:06:41 GMT Subject: RFR: Generate missing null checks [v6] In-Reply-To: References: Message-ID: > generate missing null checks like for method arguments, return arguments, etc Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1867/files - new: https://git.openjdk.org/valhalla/pull/1867/files/b6032148..e1f24e4e Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=05 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=04-05 Stats: 24 lines in 2 files changed: 4 ins; 12 del; 8 mod Patch: https://git.openjdk.org/valhalla/pull/1867.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1867/head:pull/1867 PR: https://git.openjdk.org/valhalla/pull/1867 From vromero at openjdk.org Fri Jan 9 19:15:46 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 19:15:46 GMT Subject: RFR: Generate missing null checks [v7] In-Reply-To: References: Message-ID: > generate missing null checks like for method arguments, return arguments, etc Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: another update ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1867/files - new: https://git.openjdk.org/valhalla/pull/1867/files/e1f24e4e..24dd2189 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=06 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=05-06 Stats: 9 lines in 1 file changed: 5 ins; 4 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1867.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1867/head:pull/1867 PR: https://git.openjdk.org/valhalla/pull/1867 From vromero at openjdk.org Fri Jan 9 19:18:01 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 19:18:01 GMT Subject: RFR: Generate missing null checks [v8] In-Reply-To: References: Message-ID: > generate missing null checks like for method arguments, return arguments, etc Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: - fix copy year - removing comment ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1867/files - new: https://git.openjdk.org/valhalla/pull/1867/files/24dd2189..1d0add25 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=07 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1867.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1867/head:pull/1867 PR: https://git.openjdk.org/valhalla/pull/1867 From vromero at openjdk.org Fri Jan 9 19:21:51 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 19:21:51 GMT Subject: RFR: Generate missing null checks [v9] In-Reply-To: References: Message-ID: > generate missing null checks like for method arguments, return arguments, etc Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: last iteration ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1867/files - new: https://git.openjdk.org/valhalla/pull/1867/files/1d0add25..dba00de9 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=08 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1867&range=07-08 Stats: 5 lines in 1 file changed: 1 ins; 4 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1867.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1867/head:pull/1867 PR: https://git.openjdk.org/valhalla/pull/1867 From vromero at openjdk.org Fri Jan 9 19:52:05 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 19:52:05 GMT Subject: Integrated: Generate missing null checks In-Reply-To: References: Message-ID: <56kX7ldHwNhTRqRUyDWzxAEJpaqjoSpmIJ_xZvLK3Jc=.556435ea-28ce-4a21-a907-8f67a484c1d6@github.com> On Thu, 8 Jan 2026 02:54:22 GMT, Vicente Romero wrote: > generate missing null checks like for method arguments, return arguments, etc This pull request has now been integrated. Changeset: 8eac2bb4 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/8eac2bb47c5a696145151ebe638e644604decd79 Stats: 360 lines in 8 files changed: 208 ins; 122 del; 30 mod Generate missing null checks ------------- PR: https://git.openjdk.org/valhalla/pull/1867 From fparain at openjdk.org Fri Jan 9 20:17:51 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 9 Jan 2026 20:17:51 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout In-Reply-To: References: Message-ID: On Tue, 13 May 2025 13:35:19 GMT, Quan Anh Mai wrote: > This would forbid the class which contains the `NULLABLE_NON_ATOMIC_FLAT` from being flattened into a class which contains it. I think we should only do so if the holder of the flattened strict final field should not be flattened if it is not itself a strict final field: > > * The holder is an identity class. > > * The holder is a large value class without `@LooselyConsistentValue`. > > > This is equally valid to null-restricted field of non-`@LooselyConsistentValue`, too. Yes, there are some restrictions where the NULLABLE_NON_ATOMIC_FLAT can be used, see the comments and the `can_use_atomic_flat` argument in the `field_layout_selection()` method. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1407#issuecomment-3730431574 From rriggs at openjdk.org Fri Jan 9 21:33:27 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Jan 2026 21:33:27 GMT Subject: [lworld] RFR: 8373930: [lworld] Restore Objects.equals use of identity check [v2] In-Reply-To: References: Message-ID: > Revert "8366841: [lworld] Objects.equals without identity comparison". (Almost all) > Removing the condition on --enable-preview. > Correct the .equals method in test SimplValueGraphs.SimpleValue. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Reverted to remove the no longer unnecessary @ForceInline. Update copyright. - Merge branch 'lworld' into 8373930-objects-equals-revert - Restore the mainline implementation of Objects.equal removing the condition on --enable-preview. Correct the .equals method of SimplValueGraphs.SimpleValue. Revert "8366841: [lworld] Objects.equals without identity comparison" ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1836/files - new: https://git.openjdk.org/valhalla/pull/1836/files/9aa1f037..2cea111f Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1836&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1836&range=00-01 Stats: 30884 lines in 467 files changed: 20759 ins; 8200 del; 1925 mod Patch: https://git.openjdk.org/valhalla/pull/1836.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1836/head:pull/1836 PR: https://git.openjdk.org/valhalla/pull/1836 From duke at openjdk.org Fri Jan 9 21:33:28 2026 From: duke at openjdk.org (Ryan Hallock) Date: Fri, 9 Jan 2026 21:33:28 GMT Subject: [lworld] RFR: 8373930: [lworld] Restore Objects.equals use of identity check [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 21:30:08 GMT, Roger Riggs wrote: >> Revert "8366841: [lworld] Objects.equals without identity comparison". (Almost all) >> Removing the condition on --enable-preview. >> Correct the .equals method in test SimplValueGraphs.SimpleValue. > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Reverted to remove the no longer unnecessary @ForceInline. > Update copyright. > - Merge branch 'lworld' into 8373930-objects-equals-revert > - Restore the mainline implementation of Objects.equal > removing the condition on --enable-preview. > Correct the .equals method of SimplValueGraphs.SimpleValue. > Revert "8366841: [lworld] Objects.equals without identity comparison" src/java.base/share/classes/java/util/Objects.java line 62: > 60: * @see Object#equals(Object) > 61: */ > 62: @ForceInline Is this still required? I thought the reasoning behind 8368884: https://github.com/openjdk/valhalla/pull/1643 was that equals was too large. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1836#discussion_r2672926785 From rriggs at openjdk.org Fri Jan 9 21:33:29 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Jan 2026 21:33:29 GMT Subject: [lworld] RFR: 8373930: [lworld] Restore Objects.equals use of identity check [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 15:57:28 GMT, Ryan Hallock wrote: >> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Reverted to remove the no longer unnecessary @ForceInline. >> Update copyright. >> - Merge branch 'lworld' into 8373930-objects-equals-revert >> - Restore the mainline implementation of Objects.equal >> removing the condition on --enable-preview. >> Correct the .equals method of SimplValueGraphs.SimpleValue. >> Revert "8366841: [lworld] Objects.equals without identity comparison" > > src/java.base/share/classes/java/util/Objects.java line 62: > >> 60: * @see Object#equals(Object) >> 61: */ >> 62: @ForceInline > > Is this still required? I thought the reasoning behind 8368884: https://github.com/openjdk/valhalla/pull/1643 was that equals was too large. Right, reverting also would remove the @ForceInline. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1836#discussion_r2677674174 From coleenp at openjdk.org Fri Jan 9 21:36:22 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 9 Jan 2026 21:36:22 GMT Subject: [lworld] RFR: 8374810: [lworld] Generate COH archives [v2] In-Reply-To: References: Message-ID: > This change both enables the UseCompactObjectHeaders archives for valhalla and fixes the test that looks for the archives. Testing with tier1-3 with --enable-preview and -XX:+UseCompactObjectHeaders. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Rename CDS archive from valhalla to preview. ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1871/files - new: https://git.openjdk.org/valhalla/pull/1871/files/486bc1f6..cccbb21f Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1871&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1871&range=00-01 Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/valhalla/pull/1871.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1871/head:pull/1871 PR: https://git.openjdk.org/valhalla/pull/1871 From coleenp at openjdk.org Fri Jan 9 21:36:23 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 9 Jan 2026 21:36:23 GMT Subject: [lworld] RFR: 8374810: [lworld] Generate COH archives In-Reply-To: References: Message-ID: <27cwEhcIV3nk1B2Ar0ER1iutNDTPnmUOnM77glaVgNc=.887abd12-c37f-467b-a33f-42c7fe316ad4@github.com> On Thu, 8 Jan 2026 16:51:20 GMT, Coleen Phillimore wrote: > This change both enables the UseCompactObjectHeaders archives for valhalla and fixes the test that looks for the archives. Testing with tier1-3 with --enable-preview and -XX:+UseCompactObjectHeaders. I was able to rename the archives with only one additional change in cdsConfig.cpp. Testing in progress with tier1-4, mostly done. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1871#issuecomment-3730640218 From dlsmith at openjdk.org Fri Jan 9 22:36:53 2026 From: dlsmith at openjdk.org (Dan Smith) Date: Fri, 9 Jan 2026 22:36:53 GMT Subject: RFR: Updated ArrayCreation factories and bootstraps Message-ID: Added revised bootstrap and factories to ArrayCreation. Threaded through modifiers as much as possible. Added a branch in Array.newInstance to create null-checked arrays where currently supported by the VM. Rewrote ArrayCreationTest to exercise all factories and bootstraps, and to make some use of modifiers. ------------- Commit messages: - fixes - Updated ArrayCreation factories and bootstraps Changes: https://git.openjdk.org/valhalla/pull/1879/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1879&range=00 Stats: 1259 lines in 4 files changed: 1037 ins; 6 del; 216 mod Patch: https://git.openjdk.org/valhalla/pull/1879.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1879/head:pull/1879 PR: https://git.openjdk.org/valhalla/pull/1879 From dlsmith at openjdk.org Fri Jan 9 22:36:53 2026 From: dlsmith at openjdk.org (Dan Smith) Date: Fri, 9 Jan 2026 22:36:53 GMT Subject: RFR: Updated ArrayCreation factories and bootstraps In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 20:29:35 GMT, Dan Smith wrote: > Added revised bootstrap and factories to ArrayCreation. Threaded through modifiers as much as possible. Added a branch in Array.newInstance to create null-checked arrays where currently supported by the VM. > > Rewrote ArrayCreationTest to exercise all factories and bootstraps, and to make some use of modifiers. src/java.base/share/classes/java/lang/reflect/Array.java line 148: > 146: if (sourceLength > 0) { > 147: Objects.checkIndex(sourceOffset, sourceLength); > 148: } else if (sourceOffset != 0) { This validation logic is confusing to me?is it ok just to call `checkFromIndexSize`? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1879#discussion_r2677539620 From mcimadamore at openjdk.org Fri Jan 9 22:36:54 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 22:36:54 GMT Subject: RFR: Updated ArrayCreation factories and bootstraps In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 20:30:34 GMT, Dan Smith wrote: >> Added revised bootstrap and factories to ArrayCreation. Threaded through modifiers as much as possible. Added a branch in Array.newInstance to create null-checked arrays where currently supported by the VM. >> >> Rewrote ArrayCreationTest to exercise all factories and bootstraps, and to make some use of modifiers. > > src/java.base/share/classes/java/lang/reflect/Array.java line 148: > >> 146: if (sourceLength > 0) { >> 147: Objects.checkIndex(sourceOffset, sourceLength); >> 148: } else if (sourceOffset != 0) { > > This validation logic is confusing to me?is it ok just to call `checkFromIndexSize`? no -- if you do that the check will fail for empty arrays (e.g. length == 0). ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1879#discussion_r2677743518 From mcimadamore at openjdk.org Fri Jan 9 22:36:54 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 9 Jan 2026 22:36:54 GMT Subject: RFR: Updated ArrayCreation factories and bootstraps In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 22:03:04 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/reflect/Array.java line 148: >> >>> 146: if (sourceLength > 0) { >>> 147: Objects.checkIndex(sourceOffset, sourceLength); >>> 148: } else if (sourceOffset != 0) { >> >> This validation logic is confusing to me?is it ok just to call `checkFromIndexSize`? > > no -- if you do that the check will fail for empty arrays (e.g. length == 0). nvm -- got confused with `checkFromToIndex` -- your code is better I agree ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1879#discussion_r2677781989 From dlsmith at openjdk.org Fri Jan 9 22:55:49 2026 From: dlsmith at openjdk.org (Dan Smith) Date: Fri, 9 Jan 2026 22:55:49 GMT Subject: Integrated: Updated ArrayCreation factories and bootstraps In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 20:29:35 GMT, Dan Smith wrote: > Added revised bootstrap and factories to ArrayCreation. Threaded through modifiers as much as possible. Added a branch in Array.newInstance to create null-checked arrays where currently supported by the VM. > > Rewrote ArrayCreationTest to exercise all factories and bootstraps, and to make some use of modifiers. This pull request has now been integrated. Changeset: 3d1701ab Author: Dan Smith URL: https://git.openjdk.org/valhalla/commit/3d1701abc58fcf3709b8e3a7c946d1679e69dfe6 Stats: 1259 lines in 4 files changed: 1037 ins; 6 del; 216 mod Updated ArrayCreation factories and bootstraps ------------- PR: https://git.openjdk.org/valhalla/pull/1879 From liach at openjdk.org Fri Jan 9 23:23:16 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 Jan 2026 23:23:16 GMT Subject: [valhalla-docs] RFR: site/_index.md: Fix JEP 401 link In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 18:28:24 GMT, Christopher Sahnwaldt wrote: > typo: link should point to 401, not 390 Marked as reviewed by liach (Committer). ------------- PR Review: https://git.openjdk.org/valhalla-docs/pull/15#pullrequestreview-3645911460 From liach at openjdk.org Fri Jan 9 23:24:51 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 Jan 2026 23:24:51 GMT Subject: [valhalla-docs] RFR: Fix wrong link to JEP 401 and add background info links In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 21:39:09 GMT, Nicolai Parlog wrote: > The link to JEP 401 pointed to 390. Unrelated, I also added a talk from Dan and an article from John to the list of background documents. Maybe they were intentionally left out, so no hard feelings if they're removed. ? And the GitHub editor added a trailing newline, I think. ? Marked as reviewed by liach (Committer). ------------- PR Review: https://git.openjdk.org/valhalla-docs/pull/16#pullrequestreview-3645912372 From dcubed at openjdk.org Fri Jan 9 23:34:31 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 9 Jan 2026 23:34:31 GMT Subject: [lworld] RFR: 8374913: [lworld] UnProblemList three tests due to JDK-8372341 Message-ID: A trivial fix to UnProblemList three tests due to JDK-8372341. ------------- Commit messages: - 8374913: [lworld] UnProblemList three tests due to JDK-8372341 Changes: https://git.openjdk.org/valhalla/pull/1880/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1880&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374913 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1880.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1880/head:pull/1880 PR: https://git.openjdk.org/valhalla/pull/1880 From vromero at openjdk.org Fri Jan 9 23:40:52 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Jan 2026 23:40:52 GMT Subject: RFR: generate null checks for intersections for which at least one component is null restricted Message-ID: javac should generate a null check for code like: class Test { public static void main(String... args) { Object s = null; Object o = (String & Runnable!) s; // NPE, cast } } the idea of the fix is to consider an intersection null restricted if at least one of its components is null restricted ------------- Commit messages: - generate null checks for intersections for which at least one component is null restricted Changes: https://git.openjdk.org/valhalla/pull/1881/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1881&range=00 Stats: 18 lines in 2 files changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1881.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1881/head:pull/1881 PR: https://git.openjdk.org/valhalla/pull/1881 From qamai at openjdk.org Sat Jan 10 11:50:01 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Sat, 10 Jan 2026 11:50:01 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 20:49:25 GMT, Frederic Parain wrote: > Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case. > This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic. I assume this PR is for flattening of nullable fields at immutable memory (strict final fields) only. But I think the same flattening can be done for null-free field, right? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1407#issuecomment-3732500553 From qamai at openjdk.org Sat Jan 10 13:32:50 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Sat, 10 Jan 2026 13:32:50 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 20:49:25 GMT, Frederic Parain wrote: > Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case. > This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic. src/hotspot/share/classfile/classFileParser.hpp line 101: > 99: _non_atomic_size_in_bytes(-1), _non_atomic_alignment(-1), > 100: _atomic_layout_size_in_bytes(-1), _nullable_atomic_layout_size_in_bytes(-1), > 101: _nullable_non_atomic_layout_size_in_bytes(-1), Do we need `nullable_non_atomic_alignment`, similar to `non_atomic_alignment`. Besides, it may be better to rename the `null_free` fields, too. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2678654545 From rriggs at openjdk.org Sat Jan 10 16:17:29 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Sat, 10 Jan 2026 16:17:29 GMT Subject: [lworld] RFR: 8374913: [lworld] UnProblemList three tests due to JDK-8372341 In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 23:27:19 GMT, Daniel D. Daugherty wrote: > A trivial fix to UnProblemList three tests due to JDK-8372341. Looks good. ------------- Marked as reviewed by rriggs (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1880#pullrequestreview-3647023822 From dcubed at openjdk.org Sat Jan 10 17:33:34 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 10 Jan 2026 17:33:34 GMT Subject: [lworld] RFR: 8374913: [lworld] UnProblemList three tests due to JDK-8372341 In-Reply-To: References: Message-ID: On Sat, 10 Jan 2026 16:13:51 GMT, Roger Riggs wrote: >> A trivial fix to UnProblemList three tests due to JDK-8372341. > > Looks good. @RogerRiggs - Thanks for the review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1880#issuecomment-3733260400 From dcubed at openjdk.org Sat Jan 10 17:36:20 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 10 Jan 2026 17:36:20 GMT Subject: [lworld] Integrated: 8374913: [lworld] UnProblemList three tests due to JDK-8372341 In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 23:27:19 GMT, Daniel D. Daugherty wrote: > A trivial fix to UnProblemList three tests due to JDK-8372341. This pull request has now been integrated. Changeset: ab311a79 Author: Daniel D. Daugherty URL: https://git.openjdk.org/valhalla/commit/ab311a79d51ae3cebdc52a0d9bd932315604dc40 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8374913: [lworld] UnProblemList three tests due to JDK-8372341 Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/valhalla/pull/1880 From dcubed at openjdk.org Sat Jan 10 19:31:32 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 10 Jan 2026 19:31:32 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode Message-ID: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> A trivial fix to ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode. ------------- Commit messages: - 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode Changes: https://git.openjdk.org/valhalla/pull/1882/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374947 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1882.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1882/head:pull/1882 PR: https://git.openjdk.org/valhalla/pull/1882 From rriggs at openjdk.org Sat Jan 10 20:30:59 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Sat, 10 Jan 2026 20:30:59 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode In-Reply-To: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: On Sat, 10 Jan 2026 19:26:44 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode. Marked as reviewed by rriggs (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1882#pullrequestreview-3647182009 From dcubed at openjdk.org Sat Jan 10 21:30:53 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 10 Jan 2026 21:30:53 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode In-Reply-To: References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: On Sat, 10 Jan 2026 20:28:35 GMT, Roger Riggs wrote: >> A trivial fix to ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode. > > Marked as reviewed by rriggs (Committer). @RogerRiggs - Thanks for the review! I'm going to hold this while I evaluate the rest of the Tier7 failures. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1882#issuecomment-3733572392 From dcubed at openjdk.org Sat Jan 10 21:43:22 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 10 Jan 2026 21:43:22 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode [v2] In-Reply-To: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: > A trivial fix to ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Update the copyright year. ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1882/files - new: https://git.openjdk.org/valhalla/pull/1882/files/ec15304f..c880b1dc Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1882.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1882/head:pull/1882 PR: https://git.openjdk.org/valhalla/pull/1882 From dcubed at openjdk.org Sat Jan 10 21:55:43 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 10 Jan 2026 21:55:43 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode [v3] In-Reply-To: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: <7lAikXpozX4oNp6BfuMbH4jvc5hTbiOyRMOtb8brRF8=.337bc177-0d0f-469f-9a33-a3971d34f329@github.com> > Trivial fixes to ProblemList various tests: > - [JDK-8374947](https://bugs.openjdk.org/browse/JDK-8374947) [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode > - [JDK-8374949](https://bugs.openjdk.org/browse/JDK-8374949) [lworld] ProblemList com/sun/jdi/EATests.java#id0 with --enable-preview Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: 8374949: [lworld] ProblemList com/sun/jdi/EATests.java#id0 with --enable-preview ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1882/files - new: https://git.openjdk.org/valhalla/pull/1882/files/c880b1dc..bd35c2e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1882.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1882/head:pull/1882 PR: https://git.openjdk.org/valhalla/pull/1882 From dcubed at openjdk.org Sat Jan 10 21:55:45 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 10 Jan 2026 21:55:45 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode [v2] In-Reply-To: References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: <8ECDsrQvGvZZxb3LQk0R24I34Kyjzj36eKHJW5bGdjc=.575b02d5-569d-41e8-aacb-f3c0f15c1027@github.com> On Sat, 10 Jan 2026 21:43:22 GMT, Daniel D. Daugherty wrote: >> Trivial fixes to ProblemList various tests: >> - [JDK-8374947](https://bugs.openjdk.org/browse/JDK-8374947) [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode >> - [JDK-8374949](https://bugs.openjdk.org/browse/JDK-8374949) [lworld] ProblemList com/sun/jdi/EATests.java#id0 with --enable-preview > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Update the copyright year. Please hold off on any reviews or re-reviews. I'm still wading thru Tier7 test failures. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1882#issuecomment-3733593478 From dcubed at openjdk.org Sat Jan 10 22:30:42 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 10 Jan 2026 22:30:42 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode [v4] In-Reply-To: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: > Trivial fixes to ProblemList various tests: > - [JDK-8374947](https://bugs.openjdk.org/browse/JDK-8374947) [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode > - [JDK-8374949](https://bugs.openjdk.org/browse/JDK-8374949) [lworld] ProblemList com/sun/jdi/EATests.java#id0 with --enable-preview Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: 8374951: [lworld] ProblemList misc jdk/jfr/event/oldobject tests that crash due to JDK-8374950 ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1882/files - new: https://git.openjdk.org/valhalla/pull/1882/files/bd35c2e7..14f05433 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=02-03 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1882.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1882/head:pull/1882 PR: https://git.openjdk.org/valhalla/pull/1882 From dcubed at openjdk.org Sat Jan 10 23:33:50 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 10 Jan 2026 23:33:50 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode [v5] In-Reply-To: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: > Trivial fixes to ProblemList various tests: > - [JDK-8374947](https://bugs.openjdk.org/browse/JDK-8374947) [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode > - [JDK-8374949](https://bugs.openjdk.org/browse/JDK-8374949) [lworld] ProblemList com/sun/jdi/EATests.java#id0 with --enable-preview > - [JDK-8374951](https://bugs.openjdk.org/browse/JDK-8374951) [lworld] ProblemList misc jdk/jfr/event/oldobject tests that crash due to JDK-8374950 > > This is a trivial test fix for when the test is run with the `--enable-preview` option: > - [JDK-8374952](https://bugs.openjdk.org/browse/JDK-8374952) [lworld] jdk/jfr/event/runtime/TestSyncOnValueBasedClassEvent.java still fails when run with --enable-preview Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: 8374952: [lworld] jdk/jfr/event/runtime/TestSyncOnValueBasedClassEvent.java still fails when run with --enable-preview ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1882/files - new: https://git.openjdk.org/valhalla/pull/1882/files/14f05433..d02bb8ac Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=04 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=03-04 Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1882.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1882/head:pull/1882 PR: https://git.openjdk.org/valhalla/pull/1882 From dcubed at openjdk.org Sun Jan 11 00:10:18 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sun, 11 Jan 2026 00:10:18 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode [v6] In-Reply-To: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: > Trivial fixes to ProblemList various tests: > - [JDK-8374947](https://bugs.openjdk.org/browse/JDK-8374947) [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode > - [JDK-8374949](https://bugs.openjdk.org/browse/JDK-8374949) [lworld] ProblemList com/sun/jdi/EATests.java#id0 with --enable-preview > - [JDK-8374951](https://bugs.openjdk.org/browse/JDK-8374951) [lworld] ProblemList misc jdk/jfr/event/oldobject tests that crash due to JDK-8374950 > - [JDK-8374955](https://bugs.openjdk.org/browse/JDK-8374955) [lworld] ProblemList compiler/ciReplay/TestInliningProtectionDomain.java with virtual threads > > This is a trivial test fix for when the test is run with the `--enable-preview` option: > - [JDK-8374952](https://bugs.openjdk.org/browse/JDK-8374952) [lworld] jdk/jfr/event/runtime/TestSyncOnValueBasedClassEvent.java still fails when run with --enable-preview Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: 8374955: [lworld] ProblemList compiler/ciReplay/TestInliningProtectionDomain.java with virtual threads ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1882/files - new: https://git.openjdk.org/valhalla/pull/1882/files/d02bb8ac..19449d89 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=05 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=04-05 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1882.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1882/head:pull/1882 PR: https://git.openjdk.org/valhalla/pull/1882 From vromero at openjdk.org Sun Jan 11 00:58:04 2026 From: vromero at openjdk.org (Vicente Romero) Date: Sun, 11 Jan 2026 00:58:04 GMT Subject: RFR: fixing bugs in NullChecksWriter Message-ID: fixing some bugs in NullChecksWriter, reported by John Rose. In particular there was no null check being generated by javac for code like: class Test { void m(String someObject) { String! x = "foo"; x = (String)someObject; // no null check generated here } public static void main(String... args) { new Test().m(null); } } ------------- Commit messages: - removing dead code - fixing bugs in NullChecksWriter Changes: https://git.openjdk.org/valhalla/pull/1883/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1883&range=00 Stats: 26 lines in 2 files changed: 11 ins; 15 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1883.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1883/head:pull/1883 PR: https://git.openjdk.org/valhalla/pull/1883 From dcubed at openjdk.org Sun Jan 11 01:11:01 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sun, 11 Jan 2026 01:11:01 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode [v7] In-Reply-To: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: > Trivial fixes to ProblemList various tests: > - [JDK-8374947](https://bugs.openjdk.org/browse/JDK-8374947) [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode > - [JDK-8374949](https://bugs.openjdk.org/browse/JDK-8374949) [lworld] ProblemList com/sun/jdi/EATests.java#id0 with --enable-preview > - [JDK-8374951](https://bugs.openjdk.org/browse/JDK-8374951) [lworld] ProblemList misc jdk/jfr/event/oldobject tests that crash due to JDK-8374950 > - [JDK-8374955](https://bugs.openjdk.org/browse/JDK-8374955) [lworld] ProblemList compiler/ciReplay/TestInliningProtectionDomain.java with virtual threads > > This is a trivial test fix for when the test is run with the `--enable-preview` option: > - [JDK-8374952](https://bugs.openjdk.org/browse/JDK-8374952) [lworld] jdk/jfr/event/runtime/TestSyncOnValueBasedClassEvent.java still fails when run with --enable-preview Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: 8374956: [lworld] two compiler/valhalla/inlinetypes/TestTearing.java subtests need longer default timeout values ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1882/files - new: https://git.openjdk.org/valhalla/pull/1882/files/19449d89..4cfb8478 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=06 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1882.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1882/head:pull/1882 PR: https://git.openjdk.org/valhalla/pull/1882 From dcubed at openjdk.org Sun Jan 11 01:32:03 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sun, 11 Jan 2026 01:32:03 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode [v8] In-Reply-To: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: > Trivial fixes to ProblemList various tests: > - [JDK-8374947](https://bugs.openjdk.org/browse/JDK-8374947) [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode > - [JDK-8374949](https://bugs.openjdk.org/browse/JDK-8374949) [lworld] ProblemList com/sun/jdi/EATests.java#id0 with --enable-preview > - [JDK-8374951](https://bugs.openjdk.org/browse/JDK-8374951) [lworld] ProblemList misc jdk/jfr/event/oldobject tests that crash due to JDK-8374950 > - [JDK-8374955](https://bugs.openjdk.org/browse/JDK-8374955) [lworld] ProblemList compiler/ciReplay/TestInliningProtectionDomain.java with virtual threads > > These are trivial test fixes; the first is for when the test is run with the `--enable-preview` option > and the second are changes to the default timeout values for a couple of sub-tests: > - [JDK-8374952](https://bugs.openjdk.org/browse/JDK-8374952) [lworld] jdk/jfr/event/runtime/TestSyncOnValueBasedClassEvent.java still fails when run with --enable-preview > - [JDK-8374956](https://bugs.openjdk.org/browse/JDK-8374956) [lworld] two compiler/valhalla/inlinetypes/TestTearing.java subtests need longer default timeout values Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: 8374960: [lworld] ProblemList runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java with --enable-preview ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1882/files - new: https://git.openjdk.org/valhalla/pull/1882/files/4cfb8478..bae2e6a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=07 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1882&range=06-07 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1882.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1882/head:pull/1882 PR: https://git.openjdk.org/valhalla/pull/1882 From dcubed at openjdk.org Sun Jan 11 01:51:45 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sun, 11 Jan 2026 01:51:45 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode [v8] In-Reply-To: References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: On Sun, 11 Jan 2026 01:32:03 GMT, Daniel D. Daugherty wrote: >> Trivial fixes to ProblemList various tests: >> - [JDK-8374947](https://bugs.openjdk.org/browse/JDK-8374947) [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode >> - [JDK-8374949](https://bugs.openjdk.org/browse/JDK-8374949) [lworld] ProblemList com/sun/jdi/EATests.java#id0 with --enable-preview >> - [JDK-8374951](https://bugs.openjdk.org/browse/JDK-8374951) [lworld] ProblemList misc jdk/jfr/event/oldobject tests that crash due to JDK-8374950 >> - [JDK-8374955](https://bugs.openjdk.org/browse/JDK-8374955) [lworld] ProblemList compiler/ciReplay/TestInliningProtectionDomain.java with virtual threads >> - [JDK-8374960](https://bugs.openjdk.org/browse/JDK-8374960) [lworld] ProblemList runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java with --enable-preview >> >> These are trivial test fixes; the first is for when the test is run with the `--enable-preview` option >> and the second are changes to the default timeout values for a couple of sub-tests: >> - [JDK-8374952](https://bugs.openjdk.org/browse/JDK-8374952) [lworld] jdk/jfr/event/runtime/TestSyncOnValueBasedClassEvent.java still fails when run with --enable-preview >> - [JDK-8374956](https://bugs.openjdk.org/browse/JDK-8374956) [lworld] two compiler/valhalla/inlinetypes/TestTearing.java subtests need longer default timeout values > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > 8374960: [lworld] ProblemList runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java with --enable-preview The remaining unhandled Tier7 failures are all in the jdb and JDI areas so I'll handle those with a different PR. @RogerRiggs - this PR is ready for re-review. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1882#issuecomment-3733815190 From vromero at openjdk.org Sun Jan 11 03:18:10 2026 From: vromero at openjdk.org (Vicente Romero) Date: Sun, 11 Jan 2026 03:18:10 GMT Subject: RFR: do not generate null checks for record patterns Message-ID: do not generate null checks for record patterns ------------- Commit messages: - do not generate null checks for record patterns Changes: https://git.openjdk.org/valhalla/pull/1884/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1884&range=00 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1884.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1884/head:pull/1884 PR: https://git.openjdk.org/valhalla/pull/1884 From jsikstro at openjdk.org Mon Jan 12 08:21:10 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 12 Jan 2026 08:21:10 GMT Subject: [lworld] RFR: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp [v2] In-Reply-To: References: Message-ID: > Hello, > > The hierarchies in oopsHierarchy.hpp are not up to date with the actual class hierarchies in the implementation. I've refered to these a couple of times and stumble on the fact that they are not accurate. > > I've tested that this builds locally. Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision: - Spelling fix for refArrayOopDesc - Make refArrayOopDesc subclass of objArrayOopDesc ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1874/files - new: https://git.openjdk.org/valhalla/pull/1874/files/94d2e61b..dbad21f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1874&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1874&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1874.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1874/head:pull/1874 PR: https://git.openjdk.org/valhalla/pull/1874 From aboldtch at openjdk.org Mon Jan 12 08:21:10 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 12 Jan 2026 08:21:10 GMT Subject: [lworld] RFR: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 08:17:31 GMT, Joel Sikstr?m wrote: >> Hello, >> >> The hierarchies in oopsHierarchy.hpp are not up to date with the actual class hierarchies in the implementation. I've refered to these a couple of times and stumble on the fact that they are not accurate. >> >> I've tested that this builds locally. > > Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision: > > - Spelling fix for refArrayOopDesc > - Make refArrayOopDesc subclass of objArrayOopDesc lgtm. ------------- Marked as reviewed by aboldtch (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1874#pullrequestreview-3649573212 From jsikstro at openjdk.org Mon Jan 12 08:21:12 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 12 Jan 2026 08:21:12 GMT Subject: [lworld] RFR: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 10:27:39 GMT, Joel Sikstr?m wrote: > Hello, > > The hierarchies in oopsHierarchy.hpp are not up to date with the actual class hierarchies in the implementation. I've refered to these a couple of times and stumble on the fact that they are not accurate. > > I've tested that this builds locally. I've ran Oracle's tier 1-4, hotspot_valhalla and jdk_valhalla with `refArrayOop` inheriting from `objArrayOop` instead, which looks good. As it is a simple "switch", I'll go ahead and do that in this PR. I also made some spelling fixes to the description of `refArrayOop`. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1874#issuecomment-3737341753 From jsikstro at openjdk.org Mon Jan 12 08:23:11 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 12 Jan 2026 08:23:11 GMT Subject: [lworld] RFR: 8374887: [lworld] Cleanup around vgetfield/vputfield for x86 In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:07:46 GMT, Frederic Parain wrote: >> Hello, >> >> This is a follow up from [JDK-8374093](https://bugs.openjdk.org/browse/JDK-8374093) cleaning up the x86 implementation as well. >> >> Testing: >> * hotspot_valhalla and jdk_valhalla on x86-64 > > LGTM Thank you for the reviews @fparain and @Arraying! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1875#issuecomment-3737349524 From duke at openjdk.org Mon Jan 12 08:23:11 2026 From: duke at openjdk.org (duke) Date: Mon, 12 Jan 2026 08:23:11 GMT Subject: [lworld] RFR: 8374887: [lworld] Cleanup around vgetfield/vputfield for x86 In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 11:25:35 GMT, Joel Sikstr?m wrote: > Hello, > > This is a follow up from [JDK-8374093](https://bugs.openjdk.org/browse/JDK-8374093) cleaning up the x86 implementation as well. > > Testing: > * hotspot_valhalla and jdk_valhalla on x86-64 @jsikstro Your change (at version 4699972a20af4a81459eeaafc75ab64fce5fb181) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1875#issuecomment-3737357038 From mcimadamore at openjdk.org Mon Jan 12 09:56:24 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 12 Jan 2026 09:56:24 GMT Subject: RFR: fixing bugs in NullChecksWriter In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 00:52:12 GMT, Vicente Romero wrote: > fixing some bugs in NullChecksWriter, reported by John Rose. In particular there was no null check being generated by javac for code like: > > > class Test { > void m(String someObject) { > String! x = "foo"; > x = (String)someObject; // no null check generated here > } > > public static void main(String... args) { > new Test().m(null); > } > } src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 1: > 1: /* visitReturn has the same issue: it checks whether the return expression has a symbol and only generates a null check if there's one. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1883#discussion_r2681542531 From mchevalier at openjdk.org Mon Jan 12 13:35:50 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Mon, 12 Jan 2026 13:35:50 GMT Subject: [lworld] RFR: 8372723: [lworld] Un-problem list TestVerifyGraphEdges.java Message-ID: Backout [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388) was done in commit 48bbc950f11113a57ea03f877bc3e526982c0eef which arrived in Valhalla in Merge jdk https://github.com/openjdk/valhalla/pull/1772, that was merged on the 8th Dec. Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress, and I obersed no failure of `TestVerifyGraphEdges.java`, while it should have been enough to observe multiple failures before. It seems fine to unproblem list then! Thanks, Marc ------------- Commit messages: - Unproblem list Changes: https://git.openjdk.org/valhalla/pull/1885/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1885&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372723 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1885.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1885/head:pull/1885 PR: https://git.openjdk.org/valhalla/pull/1885 From thartmann at openjdk.org Mon Jan 12 13:40:25 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 12 Jan 2026 13:40:25 GMT Subject: [lworld] RFR: 8372723: [lworld] Un-problem list TestVerifyGraphEdges.java In-Reply-To: References: Message-ID: <6gQWY--BObPnUCXx3QcP-EGpiHvgQBwYl9tCVFuKWeM=.af02951e-808a-44b8-886a-d3ba17a65325@github.com> On Mon, 12 Jan 2026 13:06:45 GMT, Marc Chevalier wrote: > Backout [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388) was done in commit 48bbc950f11113a57ea03f877bc3e526982c0eef > which arrived in Valhalla in Merge jdk https://github.com/openjdk/valhalla/pull/1772, that was merged on the 8th Dec. Tested with > tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress, and I obersed no failure of `TestVerifyGraphEdges.java`, > while it should have been enough to observe multiple failures before. > > It seems fine to unproblem list then! > > Thanks, > Marc Thanks for taking care of this Marc! Looks good and trivial. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1885#pullrequestreview-3650807949 From vromero at openjdk.org Mon Jan 12 14:31:59 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Jan 2026 14:31:59 GMT Subject: RFR: fixing bugs in NullChecksWriter [v2] In-Reply-To: References: Message-ID: > fixing some bugs in NullChecksWriter, reported by John Rose. In particular there was no null check being generated by javac for code like: > > > class Test { > void m(String someObject) { > String! x = "foo"; > x = (String)someObject; // no null check generated here > } > > public static void main(String... args) { > new Test().m(null); > } > } Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1883/files - new: https://git.openjdk.org/valhalla/pull/1883/files/9bd8f1a3..610e6376 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1883&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1883&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1883.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1883/head:pull/1883 PR: https://git.openjdk.org/valhalla/pull/1883 From jsikstro at openjdk.org Mon Jan 12 14:34:51 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 12 Jan 2026 14:34:51 GMT Subject: [lworld] Integrated: 8374887: [lworld] Cleanup around vgetfield/vputfield for x86 In-Reply-To: References: Message-ID: <6bXS-Oca5rbr-KdyVipm0-1HS67ovSp-PXcL9Hlrepo=.4a4de76c-563c-4345-a8cb-dab0c7e338fa@github.com> On Fri, 9 Jan 2026 11:25:35 GMT, Joel Sikstr?m wrote: > Hello, > > This is a follow up from [JDK-8374093](https://bugs.openjdk.org/browse/JDK-8374093) cleaning up the x86 implementation as well. > > Testing: > * hotspot_valhalla and jdk_valhalla on x86-64 This pull request has now been integrated. Changeset: 1ecc74b1 Author: Joel Sikstr?m Committer: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/1ecc74b13aa5316fa4edb507168f41972e71f455 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod 8374887: [lworld] Cleanup around vgetfield/vputfield for x86 Reviewed-by: fparain, phubner ------------- PR: https://git.openjdk.org/valhalla/pull/1875 From fparain at openjdk.org Mon Jan 12 14:38:49 2026 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 12 Jan 2026 14:38:49 GMT Subject: [lworld] RFR: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 08:21:10 GMT, Joel Sikstr?m wrote: >> Hello, >> >> The hierarchies in oopsHierarchy.hpp are not up to date with the actual class hierarchies in the implementation. I've refered to these a couple of times and stumble on the fact that they are not accurate. >> >> I've tested that this builds locally. > > Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision: > > - Spelling fix for refArrayOopDesc > - Make refArrayOopDesc subclass of objArrayOopDesc Thank you for the re-parenting of `refArrayOop`. Looks good to me. ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1874#pullrequestreview-3651090441 From rriggs at openjdk.org Mon Jan 12 15:01:30 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 12 Jan 2026 15:01:30 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode [v8] In-Reply-To: References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: <67k6WxKoC5NOWG2LpVUec70bvIen4O9usS6CE2R9Vr8=.445f39a9-31d8-4d3d-9f27-d897a18fdf65@github.com> On Sun, 11 Jan 2026 01:32:03 GMT, Daniel D. Daugherty wrote: >> Trivial fixes to ProblemList various tests: >> - [JDK-8374947](https://bugs.openjdk.org/browse/JDK-8374947) [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode >> - [JDK-8374949](https://bugs.openjdk.org/browse/JDK-8374949) [lworld] ProblemList com/sun/jdi/EATests.java#id0 with --enable-preview >> - [JDK-8374951](https://bugs.openjdk.org/browse/JDK-8374951) [lworld] ProblemList misc jdk/jfr/event/oldobject tests that crash due to JDK-8374950 >> - [JDK-8374955](https://bugs.openjdk.org/browse/JDK-8374955) [lworld] ProblemList compiler/ciReplay/TestInliningProtectionDomain.java with virtual threads >> - [JDK-8374960](https://bugs.openjdk.org/browse/JDK-8374960) [lworld] ProblemList runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java with --enable-preview >> >> These are trivial test fixes; the first is for when the test is run with the `--enable-preview` option >> and the second are changes to the default timeout values for a couple of sub-tests: >> - [JDK-8374952](https://bugs.openjdk.org/browse/JDK-8374952) [lworld] jdk/jfr/event/runtime/TestSyncOnValueBasedClassEvent.java still fails when run with --enable-preview >> - [JDK-8374956](https://bugs.openjdk.org/browse/JDK-8374956) [lworld] two compiler/valhalla/inlinetypes/TestTearing.java subtests need longer default timeout values > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > 8374960: [lworld] ProblemList runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java with --enable-preview Looks fine. (fyi, Valhalla has not enabled the re-review required flag) ------------- Marked as reviewed by rriggs (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1882#pullrequestreview-3651199122 From vromero at openjdk.org Mon Jan 12 15:47:45 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Jan 2026 15:47:45 GMT Subject: RFR: fixing bugs in NullChecksWriter [v3] In-Reply-To: References: Message-ID: > fixing some bugs in NullChecksWriter, reported by John Rose. In particular there was no null check being generated by javac for code like: > > > class Test { > void m(String someObject) { > String! x = "foo"; > x = (String)someObject; // no null check generated here > } > > public static void main(String... args) { > new Test().m(null); > } > } Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: bug in methodDef ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1883/files - new: https://git.openjdk.org/valhalla/pull/1883/files/610e6376..425fe84f Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1883&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1883&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1883.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1883/head:pull/1883 PR: https://git.openjdk.org/valhalla/pull/1883 From vromero at openjdk.org Mon Jan 12 15:54:50 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Jan 2026 15:54:50 GMT Subject: RFR: fixing bugs in NullChecksWriter [v4] In-Reply-To: References: Message-ID: > fixing some bugs in NullChecksWriter, reported by John Rose. In particular there was no null check being generated by javac for code like: > > > class Test { > void m(String someObject) { > String! x = "foo"; > x = (String)someObject; // no null check generated here > } > > public static void main(String... args) { > new Test().m(null); > } > } Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: adding tests for return type ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1883/files - new: https://git.openjdk.org/valhalla/pull/1883/files/425fe84f..77ae976b Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1883&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1883&range=02-03 Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1883.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1883/head:pull/1883 PR: https://git.openjdk.org/valhalla/pull/1883 From mcimadamore at openjdk.org Mon Jan 12 16:03:43 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 12 Jan 2026 16:03:43 GMT Subject: RFR: fixing bugs in NullChecksWriter [v4] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 15:54:50 GMT, Vicente Romero wrote: >> fixing some bugs in NullChecksWriter, reported by John Rose. In particular there was no null check being generated by javac for code like: >> >> >> class Test { >> void m(String someObject) { >> String! x = "foo"; >> x = (String)someObject; // no null check generated here >> } >> >> public static void main(String... args) { >> new Test().m(null); >> } >> } > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > adding tests for return type Looks good! ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1883#pullrequestreview-3651504781 From vromero at openjdk.org Mon Jan 12 16:03:44 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Jan 2026 16:03:44 GMT Subject: RFR: fixing bugs in NullChecksWriter [v4] In-Reply-To: References: Message-ID: <0y2mm5wrn3og6882S8p8dYNwPBL1VkD6mK3U9Pm4D90=.19f1a2e2-08a0-467c-a8ed-f170dfc1b4b3@github.com> On Mon, 12 Jan 2026 15:54:50 GMT, Vicente Romero wrote: >> fixing some bugs in NullChecksWriter, reported by John Rose. In particular there was no null check being generated by javac for code like: >> >> >> class Test { >> void m(String someObject) { >> String! x = "foo"; >> x = (String)someObject; // no null check generated here >> } >> >> public static void main(String... args) { >> new Test().m(null); >> } >> } > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > adding tests for return type thanks for the review ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1883#issuecomment-3739292894 From vromero at openjdk.org Mon Jan 12 16:03:46 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Jan 2026 16:03:46 GMT Subject: Integrated: fixing bugs in NullChecksWriter In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 00:52:12 GMT, Vicente Romero wrote: > fixing some bugs in NullChecksWriter, reported by John Rose. In particular there was no null check being generated by javac for code like: > > > class Test { > void m(String someObject) { > String! x = "foo"; > x = (String)someObject; // no null check generated here > } > > public static void main(String... args) { > new Test().m(null); > } > } This pull request has now been integrated. Changeset: df1d4ad0 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/df1d4ad0901ebe61e2b8ab930d3110ef6e02f06f Stats: 50 lines in 2 files changed: 32 ins; 17 del; 1 mod fixing bugs in NullChecksWriter Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1883 From fparain at openjdk.org Mon Jan 12 16:09:51 2026 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 12 Jan 2026 16:09:51 GMT Subject: [lworld] RFR: 8374810: [lworld] Generate COH archives [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 21:36:22 GMT, Coleen Phillimore wrote: >> This change both enables the UseCompactObjectHeaders archives for valhalla and fixes the test that looks for the archives. Testing with tier1-3 with --enable-preview and -XX:+UseCompactObjectHeaders. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Rename CDS archive from valhalla to preview. Thank you for the renaming of the archive. Looks good to me. ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1871#pullrequestreview-3651541636 From coleenp at openjdk.org Mon Jan 12 16:09:51 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 12 Jan 2026 16:09:51 GMT Subject: [lworld] RFR: 8374810: [lworld] Generate COH archives [v2] In-Reply-To: References: Message-ID: <-0Qr0v7nPcOiJe2AwO_ABsBTwGFmCM3aoD2B7-bpORw=.a348fb33-bc44-47f9-a1b1-a74681133592@github.com> On Fri, 9 Jan 2026 21:36:22 GMT, Coleen Phillimore wrote: >> This change both enables the UseCompactObjectHeaders archives for valhalla and fixes the test that looks for the archives. Testing with tier1-3 with --enable-preview and -XX:+UseCompactObjectHeaders. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Rename CDS archive from valhalla to preview. Thank you for reviewing, Fred, and to everyone else in discussion that agreed on the new archive name. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1871#issuecomment-3739312989 From coleenp at openjdk.org Mon Jan 12 16:09:51 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 12 Jan 2026 16:09:51 GMT Subject: [lworld] Integrated: 8374810: [lworld] Generate COH archives In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 16:51:20 GMT, Coleen Phillimore wrote: > This change both enables the UseCompactObjectHeaders archives for valhalla and fixes the test that looks for the archives. Testing with tier1-3 with --enable-preview and -XX:+UseCompactObjectHeaders. This pull request has now been integrated. Changeset: f6c9928c Author: Coleen Phillimore URL: https://git.openjdk.org/valhalla/commit/f6c9928c8629bd22a29dd359b150fcfeb4d4f0af Stats: 26 lines in 5 files changed: 8 ins; 3 del; 15 mod 8374810: [lworld] Generate COH archives Reviewed-by: fparain ------------- PR: https://git.openjdk.org/valhalla/pull/1871 From mcimadamore at openjdk.org Mon Jan 12 17:35:23 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 12 Jan 2026 17:35:23 GMT Subject: RFR: generate null checks for intersections for which at least one component is null restricted In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 23:35:35 GMT, Vicente Romero wrote: > javac should generate a null check for code like: > > > class Test { > public static void main(String... args) { > Object s = null; > Object o = (String & Runnable!) s; // NPE, cast > } > } > > the idea of the fix is to consider an intersection null restricted if at least one of its components is null restricted Looks good ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1881#pullrequestreview-3651909016 From vromero at openjdk.org Mon Jan 12 17:35:24 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Jan 2026 17:35:24 GMT Subject: RFR: generate null checks for intersections for which at least one component is null restricted In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 23:35:35 GMT, Vicente Romero wrote: > javac should generate a null check for code like: > > > class Test { > public static void main(String... args) { > Object s = null; > Object o = (String & Runnable!) s; // NPE, cast > } > } > > the idea of the fix is to consider an intersection null restricted if at least one of its components is null restricted thanks for the review ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1881#issuecomment-3739691074 From vromero at openjdk.org Mon Jan 12 17:37:31 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Jan 2026 17:37:31 GMT Subject: Integrated: generate null checks for intersections for which at least one component is null restricted In-Reply-To: References: Message-ID: <1TMozwCwMQlBgalGH7tI9sWRkZcMjkMX80vy0dkmSxw=.9973aa7c-33f8-4f0a-a6cc-51df90333c51@github.com> On Fri, 9 Jan 2026 23:35:35 GMT, Vicente Romero wrote: > javac should generate a null check for code like: > > > class Test { > public static void main(String... args) { > Object s = null; > Object o = (String & Runnable!) s; // NPE, cast > } > } > > the idea of the fix is to consider an intersection null restricted if at least one of its components is null restricted This pull request has now been integrated. Changeset: b0e093b8 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/b0e093b8b98c926e5322ad5b5ebcef767e17ab85 Stats: 18 lines in 2 files changed: 18 ins; 0 del; 0 mod generate null checks for intersections for which at least one component is null restricted Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1881 From dcubed at openjdk.org Mon Jan 12 18:33:48 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 12 Jan 2026 18:33:48 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode [v8] In-Reply-To: <67k6WxKoC5NOWG2LpVUec70bvIen4O9usS6CE2R9Vr8=.445f39a9-31d8-4d3d-9f27-d897a18fdf65@github.com> References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> <67k6WxKoC5NOWG2LpVUec70bvIen4O9usS6CE2R9Vr8=.445f39a9-31d8-4d3d-9f27-d897a18fdf65@github.com> Message-ID: On Mon, 12 Jan 2026 14:57:56 GMT, Roger Riggs wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8374960: [lworld] ProblemList runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java with --enable-preview > > Looks fine. > > (fyi, Valhalla has not enabled the re-review required flag) @RogerRiggs - Thanks for the re-review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1882#issuecomment-3739904549 From dcubed at openjdk.org Mon Jan 12 18:33:49 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 12 Jan 2026 18:33:49 GMT Subject: [lworld] Integrated: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode In-Reply-To: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: On Sat, 10 Jan 2026 19:26:44 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList various tests: > - [JDK-8374947](https://bugs.openjdk.org/browse/JDK-8374947) [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode > - [JDK-8374949](https://bugs.openjdk.org/browse/JDK-8374949) [lworld] ProblemList com/sun/jdi/EATests.java#id0 with --enable-preview > - [JDK-8374951](https://bugs.openjdk.org/browse/JDK-8374951) [lworld] ProblemList misc jdk/jfr/event/oldobject tests that crash due to JDK-8374950 > - [JDK-8374955](https://bugs.openjdk.org/browse/JDK-8374955) [lworld] ProblemList compiler/ciReplay/TestInliningProtectionDomain.java with virtual threads > - [JDK-8374960](https://bugs.openjdk.org/browse/JDK-8374960) [lworld] ProblemList runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java with --enable-preview > > These are trivial test fixes; the first is for when the test is run with the `--enable-preview` option > and the second are changes to the default timeout values for a couple of sub-tests: > - [JDK-8374952](https://bugs.openjdk.org/browse/JDK-8374952) [lworld] jdk/jfr/event/runtime/TestSyncOnValueBasedClassEvent.java still fails when run with --enable-preview > - [JDK-8374956](https://bugs.openjdk.org/browse/JDK-8374956) [lworld] two compiler/valhalla/inlinetypes/TestTearing.java subtests need longer default timeout values This pull request has now been integrated. Changeset: be451e12 Author: Daniel D. Daugherty URL: https://git.openjdk.org/valhalla/commit/be451e12b2e9494b52ae45c0518557076e360a26 Stats: 27 lines in 6 files changed: 18 ins; 0 del; 9 mod 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/valhalla/pull/1882 From vromero at openjdk.org Mon Jan 12 19:10:19 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Jan 2026 19:10:19 GMT Subject: RFR: Fix nullability signature attr tests Message-ID: fixing regression tests related to signatures with null restricted elements ------------- Commit messages: - other tests - Merge branch 'bworld' into fix.NullabilitySignatureAttrTests - additional changes - Merge branch 'bworld' into fix.NullabilitySignatureAttrTests - fix test NullabilitySignatureAttrTests.java Changes: https://git.openjdk.org/valhalla/pull/1887/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1887&range=00 Stats: 279 lines in 1 file changed: 3 ins; 237 del; 39 mod Patch: https://git.openjdk.org/valhalla/pull/1887.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1887/head:pull/1887 PR: https://git.openjdk.org/valhalla/pull/1887 From vromero at openjdk.org Mon Jan 12 20:14:02 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Jan 2026 20:14:02 GMT Subject: Integrated: Merge lworld Message-ID: <5yjkTSAHutTj0HfsG4dMfjHp_ebY04KaRbm5PKAmYAU=.7cd47bcf-129e-43b7-b3e9-8c4a0bd4fbdf@github.com> Merge branch 'lworld' into bworld_merge_lworld ------------- Commit messages: - Merge branch 'lworld' into bworld_merge_lworld - 8374810: [lworld] Generate COH archives - 8374887: [lworld] Cleanup around vgetfield/vputfield for x86 - 8374913: [lworld] UnProblemList three tests due to JDK-8372341 - 8374165: [lworld] Shortcut in value copying can lead to incorrect substitutability tests - 8374554: [lworld] Field layout assert with UseCompactObjectHeaders - 8366717: [lworld] Cleanup defensive fixing of JDK-8365996 - 8371726: [lworld] Re-enable verification once JDK-8371716 is solved - 8374736: [lworld] ProblemList valhalla/valuetypes/SubstitutabilityTest.java with AOTCache The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/valhalla/pull/1888/files Stats: 485 lines in 26 files changed: 254 ins; 92 del; 139 mod Patch: https://git.openjdk.org/valhalla/pull/1888.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1888/head:pull/1888 PR: https://git.openjdk.org/valhalla/pull/1888 From vromero at openjdk.org Mon Jan 12 20:14:03 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Jan 2026 20:14:03 GMT Subject: Integrated: Merge lworld In-Reply-To: <5yjkTSAHutTj0HfsG4dMfjHp_ebY04KaRbm5PKAmYAU=.7cd47bcf-129e-43b7-b3e9-8c4a0bd4fbdf@github.com> References: <5yjkTSAHutTj0HfsG4dMfjHp_ebY04KaRbm5PKAmYAU=.7cd47bcf-129e-43b7-b3e9-8c4a0bd4fbdf@github.com> Message-ID: On Mon, 12 Jan 2026 20:06:44 GMT, Vicente Romero wrote: > Merge branch 'lworld' into bworld_merge_lworld This pull request has now been integrated. Changeset: 24c48de4 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/24c48de4c2f216623a1c702f212cd7a8a2369fbd Stats: 485 lines in 26 files changed: 254 ins; 92 del; 139 mod Merge lworld ------------- PR: https://git.openjdk.org/valhalla/pull/1888 From dcubed at openjdk.org Mon Jan 12 21:00:47 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 12 Jan 2026 21:00:47 GMT Subject: [lworld] RFR: 8374947: [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode [v8] In-Reply-To: References: <1lUu7P40DkWs113T1gDTvhpCL4Qc31V35hf2Rr413n4=.fe2775d0-bef6-480d-926c-65407b19d4b4@github.com> Message-ID: On Sun, 11 Jan 2026 01:32:03 GMT, Daniel D. Daugherty wrote: >> Trivial fixes to ProblemList various tests: >> - [JDK-8374947](https://bugs.openjdk.org/browse/JDK-8374947) [lworld] ProblemList serviceability/sa/ClhsdbTestAllocationMerge.java in Xcomp mode >> - [JDK-8374949](https://bugs.openjdk.org/browse/JDK-8374949) [lworld] ProblemList com/sun/jdi/EATests.java#id0 with --enable-preview >> - [JDK-8374951](https://bugs.openjdk.org/browse/JDK-8374951) [lworld] ProblemList misc jdk/jfr/event/oldobject tests that crash due to JDK-8374950 >> - [JDK-8374955](https://bugs.openjdk.org/browse/JDK-8374955) [lworld] ProblemList compiler/ciReplay/TestInliningProtectionDomain.java with virtual threads >> - [JDK-8374960](https://bugs.openjdk.org/browse/JDK-8374960) [lworld] ProblemList runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java with --enable-preview >> >> These are trivial test fixes; the first is for when the test is run with the `--enable-preview` option >> and the second are changes to the default timeout values for a couple of sub-tests: >> - [JDK-8374952](https://bugs.openjdk.org/browse/JDK-8374952) [lworld] jdk/jfr/event/runtime/TestSyncOnValueBasedClassEvent.java still fails when run with --enable-preview >> - [JDK-8374956](https://bugs.openjdk.org/browse/JDK-8374956) [lworld] two compiler/valhalla/inlinetypes/TestTearing.java subtests need longer default timeout values > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > 8374960: [lworld] ProblemList runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java with --enable-preview It's probably too late for this: ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1882#issuecomment-3740457989 From amenkov at openjdk.org Mon Jan 12 21:55:43 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Jan 2026 21:55:43 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects Message-ID: Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. Added the test for value object ctor debugging, the test verifies the behaviour is expected. There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) testing: tier1..4, hs-tier5-svc ------------- Commit messages: - ObjectReferenceImp.hashCode - Merge branch 'ctor_debug' of github.com:alexmenkov/valhalla into ctor_debug - tabs - fix - IsSameObject only for value objects - tabs - fix - Merge branch 'openjdk:lworld' into lworld - Merge branch 'openjdk:lworld' into lworld - Merge branch 'openjdk:lworld' into lworld - ... and 3 more: https://git.openjdk.org/valhalla/compare/13abe7d1...f82f5be4 Changes: https://git.openjdk.org/valhalla/pull/1834/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1834&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373202 Stats: 536 lines in 6 files changed: 530 ins; 0 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/1834.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1834/head:pull/1834 PR: https://git.openjdk.org/valhalla/pull/1834 From cjplummer at openjdk.org Mon Jan 12 21:55:46 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Jan 2026 21:55:46 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 20:00:45 GMT, Alex Menkov wrote: > Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. > Added the test for value object ctor debugging, the test verifies the behaviour is expected. > There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) > > testing: tier1..4, hs-tier5-svc src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 150: > 148: public boolean equals(Object obj) { > 149: if (obj instanceof ObjectReferenceImpl other) { > 150: if (ref() == other.ref() && super.equals(obj)) { I'm wondering if the super.equals(obj) call is necessary. The way JDI is implemetned, there is a 1-to-1 relationship between the ObjectID and the ObjectReference. If the ObjectIDs match, then the ObjectRefernces instances should be one in the same. So either one of these checks should be sufficient. I don't think both are needed. src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 159: > 157: } catch (JDWPException exc) { > 158: throw exc.toJDIException(); > 159: } So the downside here is that when we don't have equality w.r.t. ObjectIDs, we do the heavyweight call over JDWP. A while back I did a scan of users of equals() in the JDI implementation and jdb, and it seemed it was always done on known subtypes (ClassLoaderReference, ThreadReference, ClassReference, etc). So I doubt in practice you would ever see two value types being compared, unless the debugger was doing it for some reason. So if you did limit this JDWP call to value types, probably it would be rare to non-existent that it would ever be called. src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c line 410: > 408: > 409: ref = commonRef_idToRef(env, id); > 410: (void)outStream_writeInt(out, objectHashCode(ref)); Interesting that the debug agent already has an objectHashCode() but there were no users of it. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632512266 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632527382 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632506961 From amenkov at openjdk.org Mon Jan 12 21:55:47 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Jan 2026 21:55:47 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 20:20:51 GMT, Chris Plummer wrote: >> Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. >> Added the test for value object ctor debugging, the test verifies the behaviour is expected. >> There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) >> >> testing: tier1..4, hs-tier5-svc > > src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 150: > >> 148: public boolean equals(Object obj) { >> 149: if (obj instanceof ObjectReferenceImpl other) { >> 150: if (ref() == other.ref() && super.equals(obj)) { > > I'm wondering if the super.equals(obj) call is necessary. The way JDI is implemetned, there is a 1-to-1 relationship between the ObjectID and the ObjectReference. If the ObjectIDs match, then the ObjectRefernces instances should be one in the same. So either one of these checks should be sufficient. I don't think both are needed. I agree that super.equals call is not necessary, just kept it as it was > src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 159: > >> 157: } catch (JDWPException exc) { >> 158: throw exc.toJDIException(); >> 159: } > > So the downside here is that when we don't have equality w.r.t. ObjectIDs, we do the heavyweight call over JDWP. A while back I did a scan of users of equals() in the JDI implementation and jdb, and it seemed it was always done on known subtypes (ClassLoaderReference, ThreadReference, ClassReference, etc). So I doubt in practice you would ever see two value types being compared, unless the debugger was doing it for some reason. So if you did limit this JDWP call to value types, probably it would be rare to non-existent that it would ever be called. agreed. Do I understand correctly that I cannot modify existing command (jdwp protocol shoul be backward compatible?) to get classes and need a new one to check if the class is value class? > src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c line 410: > >> 408: >> 409: ref = commonRef_idToRef(env, id); >> 410: (void)outStream_writeInt(out, objectHashCode(ref)); > > Interesting that the debug agent already has an objectHashCode() but there were no users of it. `ObjectReferenceImpl.hashCode()` calculates it by itself from objectID (it should call objectHashCode) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632546790 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632555234 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632560792 From amenkov at openjdk.org Mon Jan 12 21:55:48 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Jan 2026 21:55:48 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 20:35:19 GMT, Alex Menkov wrote: >> src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 150: >> >>> 148: public boolean equals(Object obj) { >>> 149: if (obj instanceof ObjectReferenceImpl other) { >>> 150: if (ref() == other.ref() && super.equals(obj)) { >> >> I'm wondering if the super.equals(obj) call is necessary. The way JDI is implemetned, there is a 1-to-1 relationship between the ObjectID and the ObjectReference. If the ObjectIDs match, then the ObjectRefernces instances should be one in the same. So either one of these checks should be sufficient. I don't think both are needed. > > I agree that super.equals call is not necessary, just kept it as it was Further research shown super.equals checks if the objects belong to the same VM, so it's required ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2683872138 From cjplummer at openjdk.org Mon Jan 12 21:55:50 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Jan 2026 21:55:50 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 20:38:46 GMT, Alex Menkov wrote: >> src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 159: >> >>> 157: } catch (JDWPException exc) { >>> 158: throw exc.toJDIException(); >>> 159: } >> >> So the downside here is that when we don't have equality w.r.t. ObjectIDs, we do the heavyweight call over JDWP. A while back I did a scan of users of equals() in the JDI implementation and jdb, and it seemed it was always done on known subtypes (ClassLoaderReference, ThreadReference, ClassReference, etc). So I doubt in practice you would ever see two value types being compared, unless the debugger was doing it for some reason. So if you did limit this JDWP call to value types, probably it would be rare to non-existent that it would ever be called. > > agreed. Do I understand correctly that I cannot modify existing command (jdwp protocol shoul be backward compatible?) to get classes and need a new one to check if the class is value class? I'm not sure what your backward compatible question is. I think we need an API to determine if a ClassType is a value type or not. This could be expensive to maintain. Probably we need to only look it up when needed and can keep it cached with the ClassType. Another option is to only try to avoid the IsSameObject callback when we are not dealing with an ObjectReferenceImpl subclass. We can make a check something like `obj.getClass() == ObjectReferenceImpl.class`. When they are not equal, then we are dealing with a subclass that we know can't be a value type. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2633578296 From amenkov at openjdk.org Mon Jan 12 21:55:51 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Jan 2026 21:55:51 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 04:34:18 GMT, Chris Plummer wrote: >> agreed. Do I understand correctly that I cannot modify existing command (jdwp protocol shoul be backward compatible?) to get classes and need a new one to check if the class is value class? > > I'm not sure what your backward compatible question is. I think we need an API to determine if a ClassType is a value type or not. This could be expensive to maintain. Probably we need to only look it up when needed and can keep it cached with the ClassType. Another option is to only try to avoid the IsSameObject callback when we are not dealing with an ObjectReferenceImpl subclass. We can make a check something like `obj.getClass() == ObjectReferenceImpl.class`. When they are not equal, then we are dealing with a subclass that we know can't be a value type. I added a check if the object is value object (implemented as a new JDWP command first, but then simplified to test modifiers - the same approach as in hotspot) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2683890387 From sspitsyn at openjdk.org Mon Jan 12 21:55:52 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 12 Jan 2026 21:55:52 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 20:00:45 GMT, Alex Menkov wrote: > Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. > Added the test for value object ctor debugging, the test verifies the behaviour is expected. > There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) > > testing: tier1..4, hs-tier5-svc src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c line 430: > 428: {isSameObjectImpl, "IsSameObject"}, > 429: {objectHashCodeImpl, "ObjectHashCode"} > 430: }; I'd suggest to keep current naming convention (just first letter is changed to capital): referenceType <=> ReferenceType disableCollection <=> DisableCollection referringObjects <=> ReferringObjects isSameObjectIs <=> SameObject objectHashCode <=> ObjectHashCode Then the existing objectHashCode needs to be renamed to something else. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632756590 From amenkov at openjdk.org Mon Jan 12 21:55:53 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Jan 2026 21:55:53 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 21:50:07 GMT, Serguei Spitsyn wrote: >> Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. >> Added the test for value object ctor debugging, the test verifies the behaviour is expected. >> There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) >> >> testing: tier1..4, hs-tier5-svc > > src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c line 430: > >> 428: {isSameObjectImpl, "IsSameObject"}, >> 429: {objectHashCodeImpl, "ObjectHashCode"} >> 430: }; > > I'd suggest to keep current naming convention (just first letter is changed to capital): > referenceType <=> ReferenceType > disableCollection <=> DisableCollection > referringObjects <=> ReferringObjects > isSameObjectIs <=> SameObject > objectHashCode <=> ObjectHashCode > Then the existing objectHashCode needs to be renamed to something else. We have isSameObject too (and it's used in many places) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632952824 From sspitsyn at openjdk.org Mon Jan 12 22:32:15 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 12 Jan 2026 22:32:15 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: <5hpmTChRrvNzzQRudMdFGshCA5UDK0I59AgcBQiQke8=.bc38ebd5-0807-42c0-abf2-0f141d0dabce@github.com> On Thu, 18 Dec 2025 20:00:45 GMT, Alex Menkov wrote: > Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. > Added the test for value object ctor debugging, the test verifies the behaviour is expected. > There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) > > testing: tier1..4, hs-tier5-svc src/java.se/share/data/jdwp/jdwp.spec line 1830: > 1828: (Error VM_DEAD) > 1829: ) > 1830: ) I wonder if the `(Error NOT_IMPLEMENTED)` should also be included. Should we also consider to introduce a command in the `CapabilitiesNew=17` command set? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2684114207 From sspitsyn at openjdk.org Mon Jan 12 22:32:17 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 12 Jan 2026 22:32:17 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 23:14:29 GMT, Alex Menkov wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c line 430: >> >>> 428: {isSameObjectImpl, "IsSameObject"}, >>> 429: {objectHashCodeImpl, "ObjectHashCode"} >>> 430: }; >> >> I'd suggest to keep current naming convention (just first letter is changed to capital): >> referenceType <=> ReferenceType >> disableCollection <=> DisableCollection >> referringObjects <=> ReferringObjects >> isSameObjectIs <=> SameObject >> objectHashCode <=> ObjectHashCode >> Then the existing objectHashCode needs to be renamed to something else. > > We have isSameObject too (and it's used in many places) Yes, the same. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2635998781 From liach at openjdk.org Mon Jan 12 23:25:07 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 12 Jan 2026 23:25:07 GMT Subject: [lworld] RFR: 8373930: [lworld] Restore Objects.equals use of identity check [v2] In-Reply-To: References: Message-ID: <5ub5YjweWmAtBzJyqPx8ZNzwd70uDgZmwbPhf2UnZso=.49295d4f-8b34-4708-807d-6b89d639a58e@github.com> On Fri, 9 Jan 2026 21:33:27 GMT, Roger Riggs wrote: >> Revert "8366841: [lworld] Objects.equals without identity comparison". (Almost all) >> Removing the condition on --enable-preview. >> Correct the .equals method in test SimplValueGraphs.SimpleValue. > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Reverted to remove the no longer unnecessary @ForceInline. > Update copyright. > - Merge branch 'lworld' into 8373930-objects-equals-revert > - Restore the mainline implementation of Objects.equal > removing the condition on --enable-preview. > Correct the .equals method of SimplValueGraphs.SimpleValue. > Revert "8366841: [lworld] Objects.equals without identity comparison" Marked as reviewed by liach (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1836#pullrequestreview-3653100511 From dcubed at openjdk.org Mon Jan 12 23:58:17 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 12 Jan 2026 23:58:17 GMT Subject: [lworld] RFR: 8375064: [lworld] ProblemList vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java on windows-x64 Message-ID: Trivial fixes to ProblemList various tests: - [JDK-8375064](https://bugs.openjdk.org/browse/JDK-8375064) [lworld] ProblemList vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java on windows-x64 - [JDK-8375071](https://bugs.openjdk.org/browse/JDK-8375071) [lworld] ProblemList vmTestbase/nsk/jdi/Accessible/modifiers/modifiers001/TestDescription.java with --enable-preview - [JDK-8375075](https://bugs.openjdk.org/browse/JDK-8375075) [lworld] ProblemList vmTestbase/nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe001/TestDescription.java with --enable-preview - [JDK-8375077](https://bugs.openjdk.org/browse/JDK-8375077) [lworld] ProblemList two JDI scenario tests failing on windows-x64 ------------- Commit messages: - 8375077: [lworld] ProblemList two JDI scenario tests failing on windows-x64 - 8375075: [lworld] ProblemList vmTestbase/nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe001/TestDescription.java with --enable-preview - 8375071: [lworld] ProblemList vmTestbase/nsk/jdi/Accessible/modifiers/modifiers001/TestDescription.java with --enable-preview - 8375062: [lworld] vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java fails to output debuggee prompt after cont cmd Changes: https://git.openjdk.org/valhalla/pull/1889/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1889&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375064 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1889.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1889/head:pull/1889 PR: https://git.openjdk.org/valhalla/pull/1889 From rriggs at openjdk.org Tue Jan 13 01:57:43 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Jan 2026 01:57:43 GMT Subject: [lworld] RFR: 8375064: [lworld] ProblemList vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java on windows-x64 In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 21:03:04 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList various tests: > - [JDK-8375064](https://bugs.openjdk.org/browse/JDK-8375064) [lworld] ProblemList vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java on windows-x64 > - [JDK-8375071](https://bugs.openjdk.org/browse/JDK-8375071) [lworld] ProblemList vmTestbase/nsk/jdi/Accessible/modifiers/modifiers001/TestDescription.java with --enable-preview > - [JDK-8375075](https://bugs.openjdk.org/browse/JDK-8375075) [lworld] ProblemList vmTestbase/nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe001/TestDescription.java with --enable-preview > - [JDK-8375077](https://bugs.openjdk.org/browse/JDK-8375077) [lworld] ProblemList two JDI scenario tests failing on windows-x64 Looks fine ------------- Marked as reviewed by rriggs (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1889#pullrequestreview-3653447726 From duke at openjdk.org Tue Jan 13 05:39:13 2026 From: duke at openjdk.org (Christopher Sahnwaldt) Date: Tue, 13 Jan 2026 05:39:13 GMT Subject: [valhalla-docs] Integrated: site/_index.md: Fix JEP 401 link In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 18:28:24 GMT, Christopher Sahnwaldt wrote: > typo: link should point to 401, not 390 This pull request has now been integrated. Changeset: 7bb7fda9 Author: Christopher Sahnwaldt Committer: Chen Liang URL: https://git.openjdk.org/valhalla-docs/commit/7bb7fda9237f7c59bbb18e189a3dbd751c35cebb Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod site/_index.md: Fix JEP 401 link Reviewed-by: liach ------------- PR: https://git.openjdk.org/valhalla-docs/pull/15 From thartmann at openjdk.org Tue Jan 13 08:57:48 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 13 Jan 2026 08:57:48 GMT Subject: [lworld] RFR: 8372259: [lworld] Merge of 8327963 produces assertion escape.cpp "new projection should have been allocated" In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 10:00:12 GMT, Quan Anh Mai wrote: > There are 2 issues here: > > - The markword of an allocation is set incorrectly during GraphKit::set_outputs_for_allocation > - Compile::adjust_flat_array_access_aliases does not work when there is no MemNode into flat arrays, but we can have allocations, which introduce NarrowMemProjs, and in that case we need to handle it, too. > > This PR solves these issues, most of the changes are identation changes only. > > Please kindly review, thanks a lot. Looks good to me! ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1873#pullrequestreview-3654645335 From mchevalier at openjdk.org Tue Jan 13 08:59:21 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Tue, 13 Jan 2026 08:59:21 GMT Subject: [lworld] RFR: 8372723: [lworld] Un-problem list TestVerifyGraphEdges.java In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 13:06:45 GMT, Marc Chevalier wrote: > Backout [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388) was done in commit 48bbc950f11113a57ea03f877bc3e526982c0eef > which arrived in Valhalla in Merge jdk https://github.com/openjdk/valhalla/pull/1772, that was merged on the 8th Dec. Tested with > tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress, and I obersed no failure of `TestVerifyGraphEdges.java`, > while it should have been enough to observe multiple failures before. > > It seems fine to unproblem list then! > > Thanks, > Marc Thanks for review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1885#issuecomment-3742971593 From mchevalier at openjdk.org Tue Jan 13 09:01:35 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Tue, 13 Jan 2026 09:01:35 GMT Subject: [lworld] Integrated: 8372723: [lworld] Un-problem list TestVerifyGraphEdges.java In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 13:06:45 GMT, Marc Chevalier wrote: > Backout [JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388) was done in commit 48bbc950f11113a57ea03f877bc3e526982c0eef > which arrived in Valhalla in Merge jdk https://github.com/openjdk/valhalla/pull/1772, that was merged on the 8th Dec. Tested with > tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress, and I obersed no failure of `TestVerifyGraphEdges.java`, > while it should have been enough to observe multiple failures before. > > It seems fine to unproblem list then! > > Thanks, > Marc This pull request has now been integrated. Changeset: 4fa8e593 Author: Marc Chevalier URL: https://git.openjdk.org/valhalla/commit/4fa8e593b4efa49aa92e245ae6e98cd6a3659bbb Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8372723: [lworld] Un-problem list TestVerifyGraphEdges.java Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1885 From mchevalier at openjdk.org Tue Jan 13 10:08:40 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Tue, 13 Jan 2026 10:08:40 GMT Subject: [lworld] RFR: 8373982: [lworld] Verification code in InlineTypeNode::has_phi_inputs does not check all field values Message-ID: This PR makes a for loop in `bool InlineTypeNode::has_phi_inputs(Node* region)` actually iterate over every field. It doesn't seem to trigger any crash in tiers tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Thanks, Marc ------------- Commit messages: - Iterate on everything Changes: https://git.openjdk.org/valhalla/pull/1892/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1892&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373982 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1892.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1892/head:pull/1892 PR: https://git.openjdk.org/valhalla/pull/1892 From mcimadamore at openjdk.org Tue Jan 13 10:09:50 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 13 Jan 2026 10:09:50 GMT Subject: RFR: Fix nullability signature attr tests In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 19:03:13 GMT, Vicente Romero wrote: > fixing regression tests related to signatures with null restricted elements Looks good ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1887#pullrequestreview-3654977073 From mcimadamore at openjdk.org Tue Jan 13 10:20:25 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 13 Jan 2026 10:20:25 GMT Subject: RFR: Attribution not setting strict array creation flag Message-ID: <_GtBB79nbLC39L_Ni6v-HY6dO6BXnUUEY3qzK0gskQQ=.2a7fde3d-d665-4a1f-90d7-195b8b7def5f@github.com> In a last minute change, I moved the code that sets the strict flag for array creation inside the logic that validates the non-nullable array creation. Since this logic only applies to arrays w/o an initializer, now all arrays with an initializer will not have the strict flag set, and their translation won't use `ArrayCreation`. ------------- Commit messages: - Drop spurious changes - Fix issue with Attr not setting strict array creation flag Changes: https://git.openjdk.org/valhalla/pull/1894/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1894&range=00 Stats: 7 lines in 1 file changed: 6 ins; 1 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1894.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1894/head:pull/1894 PR: https://git.openjdk.org/valhalla/pull/1894 From mchevalier at openjdk.org Tue Jan 13 10:24:40 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Tue, 13 Jan 2026 10:24:40 GMT Subject: [lworld] RFR: 8374116: [lworld] TestIntrinsics::test82 fails post JDK-8372634 Message-ID: Before [JDK-8372634](https://bugs.openjdk.org/browse/JDK-8372634) in `Parse::sharpen_type_after_if`, we had https://github.com/openjdk/jdk/blob/4e9525ef3619b02e905f16b89261b82c70830f3a/src/hotspot/share/opto/parse2.cpp#L1727-L1733 where `static Node* extract_obj_from_klass_load(PhaseGVN* gvn, Node* n)` can fail https://github.com/openjdk/jdk/blob/4e9525ef3619b02e905f16b89261b82c70830f3a/src/hotspot/share/opto/parse2.cpp#L1695-L1708 if `val` is not a `LoadKlass` (or narrow version of it). In this case, `obj` would be `nullptr` and then nothing is done. Now, we have https://github.com/openjdk/jdk/blob/f2e56e4c18080616e8ef275a3d9c1da824efda26/src/hotspot/share/opto/parse2.cpp#L1805-L1807 that can take this branch https://github.com/openjdk/jdk/blob/f2e56e4c18080616e8ef275a3d9c1da824efda26/src/hotspot/share/opto/parse2.cpp#L1734-L1741 where `extract_obj_from_klass_load` is unchanged, and can still fail. Yet, we have an `assert` now. That seems slightly fishy, but except in the case at hand, it doesn't mean to fire, so... it might be ok? Otherwise, replacing the return with `return (*obj) != nullptr;` would work. But in the case we have, there isn't a `Bool(CmpP(LoadKlass(obj._klass), ConP(Foo.klass)), [eq])` as written in the comment, but instead a Bool(FlatArrayCheck(Proj[mem](...), ConP), [eq]) This happens because `FlatArrayCheckNode` is a derived class from `CmpNode`. Yet, it doesn't work like a normal compare node: it's not necessarily binary, but mostly, having a constant operand doesn't allow to refine the other. So I suggest we don't even try `sharpen_type_after_if` in this case. Thanks, Marc ------------- Commit messages: - Don't sharpen types for FlarArrayCheck Changes: https://git.openjdk.org/valhalla/pull/1893/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1893&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374116 Stats: 7 lines in 2 files changed: 5 ins; 1 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1893.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1893/head:pull/1893 PR: https://git.openjdk.org/valhalla/pull/1893 From thartmann at openjdk.org Tue Jan 13 10:27:35 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 13 Jan 2026 10:27:35 GMT Subject: [lworld] RFR: 8373982: [lworld] Verification code in InlineTypeNode::has_phi_inputs does not check all field values In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 09:59:14 GMT, Marc Chevalier wrote: > This PR makes a for loop in `bool InlineTypeNode::has_phi_inputs(Node* region)` actually iterate over every field. > > It doesn't seem to trigger any crash in tiers tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. > > Thanks, > Marc Looks good and trivial. Thanks! ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1892#pullrequestreview-3655046854 From qamai at openjdk.org Tue Jan 13 10:40:23 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 13 Jan 2026 10:40:23 GMT Subject: [lworld] RFR: 8374116: [lworld] TestIntrinsics::test82 fails post JDK-8372634 In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 10:13:23 GMT, Marc Chevalier wrote: > Before [JDK-8372634](https://bugs.openjdk.org/browse/JDK-8372634) in `Parse::sharpen_type_after_if`, we had > https://github.com/openjdk/valhalla/blob/4e9525ef3619b02e905f16b89261b82c70830f3a/src/hotspot/share/opto/parse2.cpp#L1727-L1733 > where `static Node* extract_obj_from_klass_load(PhaseGVN* gvn, Node* n)` can fail > https://github.com/openjdk/valhalla/blob/4e9525ef3619b02e905f16b89261b82c70830f3a/src/hotspot/share/opto/parse2.cpp#L1695-L1708 > if `val` is not a `LoadKlass` (or narrow version of it). In this case, `obj` would be `nullptr` and then nothing is done. > > Now, we have > https://github.com/openjdk/valhalla/blob/f2e56e4c18080616e8ef275a3d9c1da824efda26/src/hotspot/share/opto/parse2.cpp#L1805-L1807 > that can take this branch > https://github.com/openjdk/valhalla/blob/f2e56e4c18080616e8ef275a3d9c1da824efda26/src/hotspot/share/opto/parse2.cpp#L1734-L1741 > where `extract_obj_from_klass_load` is unchanged, and can still fail. Yet, we have an `assert` now. That seems slightly fishy, but except in the case at hand, it doesn't mean to fire, so... it might be ok? Otherwise, replacing the return with `return (*obj) != nullptr;` would work. > > But in the case we have, there isn't a `Bool(CmpP(LoadKlass(obj._klass), ConP(Foo.klass)), [eq])` as written in the comment, but instead a > > Bool(FlatArrayCheck(Proj[mem](...), ConP), [eq]) > > This happens because `FlatArrayCheckNode` is a derived class from `CmpNode`. Yet, it doesn't work like a normal compare node: it's not necessarily binary, but mostly, having a constant operand doesn't allow to refine the other. So I suggest we don't even try `sharpen_type_after_if` in this case. > > > Thanks, > Marc LGTM ------------- Marked as reviewed by qamai (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1893#pullrequestreview-3655097776 From thartmann at openjdk.org Tue Jan 13 10:53:12 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 13 Jan 2026 10:53:12 GMT Subject: [lworld] RFR: 8374116: [lworld] TestIntrinsics::test82 fails post JDK-8372634 In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 10:13:23 GMT, Marc Chevalier wrote: > Before [JDK-8372634](https://bugs.openjdk.org/browse/JDK-8372634) in `Parse::sharpen_type_after_if`, we had > https://github.com/openjdk/valhalla/blob/4e9525ef3619b02e905f16b89261b82c70830f3a/src/hotspot/share/opto/parse2.cpp#L1727-L1733 > where `static Node* extract_obj_from_klass_load(PhaseGVN* gvn, Node* n)` can fail > https://github.com/openjdk/valhalla/blob/4e9525ef3619b02e905f16b89261b82c70830f3a/src/hotspot/share/opto/parse2.cpp#L1695-L1708 > if `val` is not a `LoadKlass` (or narrow version of it). In this case, `obj` would be `nullptr` and then nothing is done. > > Now, we have > https://github.com/openjdk/valhalla/blob/f2e56e4c18080616e8ef275a3d9c1da824efda26/src/hotspot/share/opto/parse2.cpp#L1805-L1807 > that can take this branch > https://github.com/openjdk/valhalla/blob/f2e56e4c18080616e8ef275a3d9c1da824efda26/src/hotspot/share/opto/parse2.cpp#L1734-L1741 > where `extract_obj_from_klass_load` is unchanged, and can still fail. Yet, we have an `assert` now. That seems slightly fishy, but except in the case at hand, it doesn't mean to fire, so... it might be ok? Otherwise, replacing the return with `return (*obj) != nullptr;` would work. > > But in the case we have, there isn't a `Bool(CmpP(LoadKlass(obj._klass), ConP(Foo.klass)), [eq])` as written in the comment, but instead a > > Bool(FlatArrayCheck(Proj[mem](...), ConP), [eq]) > > This happens because `FlatArrayCheckNode` is a derived class from `CmpNode`. Yet, it doesn't work like a normal compare node: it's not necessarily binary, but mostly, having a constant operand doesn't allow to refine the other. So I suggest we don't even try `sharpen_type_after_if` in this case. > > > Thanks, > Marc Looks good to me too. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1893#pullrequestreview-3655147421 From dsimms at openjdk.org Tue Jan 13 11:01:30 2026 From: dsimms at openjdk.org (David Simms) Date: Tue, 13 Jan 2026 11:01:30 GMT Subject: RFR: 8375139: [lworld] Disable jcheck in "type-classes" branch Message-ID: Relax ------------- Commit messages: - Whoops - 8375139: [lworld] Disable jcheck in "type-classes" branch Changes: https://git.openjdk.org/valhalla/pull/1895/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1895&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375139 Stats: 8 lines in 1 file changed: 2 ins; 3 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1895.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1895/head:pull/1895 PR: https://git.openjdk.org/valhalla/pull/1895 From mcimadamore at openjdk.org Tue Jan 13 11:01:30 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 13 Jan 2026 11:01:30 GMT Subject: RFR: 8375139: [lworld] Disable jcheck in "type-classes" branch In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 10:46:30 GMT, David Simms wrote: > Relax Looks good ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1895#pullrequestreview-3655172628 From dsimms at openjdk.org Tue Jan 13 11:04:16 2026 From: dsimms at openjdk.org (David Simms) Date: Tue, 13 Jan 2026 11:04:16 GMT Subject: Integrated: 8375139: [lworld] Disable jcheck in "type-classes" branch In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 10:46:30 GMT, David Simms wrote: > Relax This pull request has now been integrated. Changeset: 8f70fe40 Author: David Simms URL: https://git.openjdk.org/valhalla/commit/8f70fe409afcc45a60512c6320c2089b10a4e777 Stats: 8 lines in 1 file changed: 2 ins; 3 del; 3 mod 8375139: [lworld] Disable jcheck in "type-classes" branch Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1895 From mcimadamore at openjdk.org Tue Jan 13 11:10:56 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 13 Jan 2026 11:10:56 GMT Subject: RFR: Initial push for type classes support Message-ID: <3CiG5FS93fJ0PNzs9AZAPQSYUNvjJf1LnBHDpakfRPs=.f22ae810-6e47-479a-a656-9b9b8d281bfd@github.com> This PR contains support for an experimental type classes feature. > [!WARNING] > Given the highly experimental nature of this work, nothing is settled in stone, and the comments below are mostly provided as a general guidance on how to use what's there. For instance, given a record declaration like this: record MyInt(int x) { } We can define a new type class, for addition, using a regular interface, like so: interface Sum { X zero(); X add(X a, X b); } And then define a _witness field_ of the type class `Sum` for the type `MyInt`, using the `__witness` keyword, like so: __witness Sum SUM_MYINT = new Sum<>() { MyInt zero() { return new MyInt(0); } MyInt add(MyInt a, MyInt b) { return new MyInt(a.x + b.x); } }; (For correctness, this field should be declared either in `Sum` or in `MyInt`) Once defined, a witness can be _looked up_ using its type, like so: Sum sum = Sum.__witness; MyInt zero = sum.zero(); MyInt one = new MyInt(1); assert sum.add(zero, one).equals(one); This prototype contains other features, such as the declaration of witness methods, and the ability to perform witness lookups at runtime. For more examples, please refer to the tests under `test/langtools/tools/javac/typeClasses`. ------------- Commit messages: - Tweak copyright for modified files - Update copyright of new files - Remove trailing whitespaces - Add missing files - Merge branch 'type_classes_clean' into type-classes - Initial push Changes: https://git.openjdk.org/valhalla/pull/1886/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1886&range=00 Stats: 3205 lines in 55 files changed: 3165 ins; 1 del; 39 mod Patch: https://git.openjdk.org/valhalla/pull/1886.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1886/head:pull/1886 PR: https://git.openjdk.org/valhalla/pull/1886 From maurizio.cimadamore at oracle.com Tue Jan 13 11:13:00 2026 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 13 Jan 2026 11:13:00 +0000 Subject: type classes prototype Message-ID: <3becbfda-c447-46cd-ab16-4d4e5df4809f@oracle.com> Hi all, over the past few months we've been experimenting with an implementation of a type class feature along the lines of what Brian presented at last JVMLS [1]. This work is being added to the new "type-classes" branch as part of this PR: https://github.com/openjdk/valhalla/pull/1886 While this is all still highly experimental, and a long way from being JEP-ready, we thought it might be worth sharing it here, as doing so will enable bleeding edge hackers (such as ourselves!) to carry out further experimentation, especially in the context of providing better support for new Valhalla-based numeric types [2]. More details on how the prototype works and which features it enables will be shared in due time, as we gather more experience with this feature. In other words, this is venue for experimentation, and NOT a proposal for inclusion in the Java platform, and any feedback should be providied while keeping that in mind. Cheers Maurizio [1] - https://www.youtube.com/watch?v=Gz7Or9C0TpM [2] - https://www.youtube.com/watch?v=xCdJb_zI5us From jsikstro at openjdk.org Tue Jan 13 12:07:08 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 13 Jan 2026 12:07:08 GMT Subject: [lworld] RFR: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 11:01:58 GMT, Paul H?bner wrote: >> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision: >> >> - Spelling fix for refArrayOopDesc >> - Make refArrayOopDesc subclass of objArrayOopDesc > > Long overdue, thanks for doing this. Makes it clear that the `refArrayOopDesc` is a bit special. Thank you for the reviews @Arraying, @xmas92 and @fparain! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1874#issuecomment-3743951352 From duke at openjdk.org Tue Jan 13 12:07:10 2026 From: duke at openjdk.org (duke) Date: Tue, 13 Jan 2026 12:07:10 GMT Subject: [lworld] RFR: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 08:21:10 GMT, Joel Sikstr?m wrote: >> Hello, >> >> The hierarchies in oopsHierarchy.hpp are not up to date with the actual class hierarchies in the implementation. I've refered to these a couple of times and stumble on the fact that they are not accurate. >> >> I've tested that this builds locally. > > Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision: > > - Spelling fix for refArrayOopDesc > - Make refArrayOopDesc subclass of objArrayOopDesc @jsikstro Your change (at version dbad21f1c2c920031dbfcfe76946f4bf80694e2d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1874#issuecomment-3743956409 From qamai at openjdk.org Tue Jan 13 13:56:22 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 13 Jan 2026 13:56:22 GMT Subject: [lworld] RFR: 8372259: [lworld] Merge of 8327963 produces assertion escape.cpp "new projection should have been allocated" In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 08:54:58 GMT, Tobias Hartmann wrote: >> There are 2 issues here: >> >> - The markword of an allocation is set incorrectly during GraphKit::set_outputs_for_allocation >> - Compile::adjust_flat_array_access_aliases does not work when there is no MemNode into flat arrays, but we can have allocations, which introduce NarrowMemProjs, and in that case we need to handle it, too. >> >> This PR solves these issues, most of the changes are identation changes only. >> >> Please kindly review, thanks a lot. > > Looks good to me! @TobiHartmann Thanks a lot for your review. The failure of `TestArrays` can be reproduced on `lworld` as well. So, I think I will integrate this PR. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1873#issuecomment-3744454839 From qamai at openjdk.org Tue Jan 13 13:56:25 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 13 Jan 2026 13:56:25 GMT Subject: [lworld] Integrated: 8372259: [lworld] Merge of 8327963 produces assertion escape.cpp "new projection should have been allocated" In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 10:00:12 GMT, Quan Anh Mai wrote: > There are 2 issues here: > > - The markword of an allocation is set incorrectly during GraphKit::set_outputs_for_allocation > - Compile::adjust_flat_array_access_aliases does not work when there is no MemNode into flat arrays, but we can have allocations, which introduce NarrowMemProjs, and in that case we need to handle it, too. > > This PR solves these issues, most of the changes are identation changes only. > > Please kindly review, thanks a lot. This pull request has now been integrated. Changeset: 8e7ff7b7 Author: Quan Anh Mai URL: https://git.openjdk.org/valhalla/commit/8e7ff7b707a896edac648fd2250c1e7852593483 Stats: 332 lines in 4 files changed: 75 ins; 82 del; 175 mod 8372259: [lworld] Merge of 8327963 produces assertion escape.cpp "new projection should have been allocated" Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1873 From vromero at openjdk.org Tue Jan 13 14:27:33 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 13 Jan 2026 14:27:33 GMT Subject: RFR: Attribution not setting strict array creation flag In-Reply-To: <_GtBB79nbLC39L_Ni6v-HY6dO6BXnUUEY3qzK0gskQQ=.2a7fde3d-d665-4a1f-90d7-195b8b7def5f@github.com> References: <_GtBB79nbLC39L_Ni6v-HY6dO6BXnUUEY3qzK0gskQQ=.2a7fde3d-d665-4a1f-90d7-195b8b7def5f@github.com> Message-ID: On Tue, 13 Jan 2026 10:13:40 GMT, Maurizio Cimadamore wrote: > In a last minute change, I moved the code that sets the strict flag for array creation inside the logic that validates the non-nullable array creation. > Since this logic only applies to arrays w/o an initializer, now all arrays with an initializer will not have the strict flag set, and their translation won't use `ArrayCreation`. lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1894#pullrequestreview-3656082630 From mcimadamore at openjdk.org Tue Jan 13 14:31:43 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 13 Jan 2026 14:31:43 GMT Subject: Integrated: Attribution not setting strict array creation flag In-Reply-To: <_GtBB79nbLC39L_Ni6v-HY6dO6BXnUUEY3qzK0gskQQ=.2a7fde3d-d665-4a1f-90d7-195b8b7def5f@github.com> References: <_GtBB79nbLC39L_Ni6v-HY6dO6BXnUUEY3qzK0gskQQ=.2a7fde3d-d665-4a1f-90d7-195b8b7def5f@github.com> Message-ID: On Tue, 13 Jan 2026 10:13:40 GMT, Maurizio Cimadamore wrote: > In a last minute change, I moved the code that sets the strict flag for array creation inside the logic that validates the non-nullable array creation. > Since this logic only applies to arrays w/o an initializer, now all arrays with an initializer will not have the strict flag set, and their translation won't use `ArrayCreation`. This pull request has now been integrated. Changeset: 68c6b6ad Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/68c6b6ad93f542e661bf9df664d4d465d8d547e3 Stats: 7 lines in 1 file changed: 6 ins; 1 del; 0 mod Attribution not setting strict array creation flag Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1894 From rriggs at openjdk.org Tue Jan 13 14:35:17 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Jan 2026 14:35:17 GMT Subject: [lworld] Integrated: 8373930: [lworld] Restore Objects.equals use of identity check In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 21:23:00 GMT, Roger Riggs wrote: > Revert "8366841: [lworld] Objects.equals without identity comparison". (Almost all) > Removing the condition on --enable-preview. > Correct the .equals method in test SimplValueGraphs.SimpleValue. This pull request has now been integrated. Changeset: e961f0bb Author: Roger Riggs URL: https://git.openjdk.org/valhalla/commit/e961f0bb6de695f572d4d3e220d3f9bd7f143337 Stats: 12 lines in 2 files changed: 0 ins; 7 del; 5 mod 8373930: [lworld] Restore Objects.equals use of identity check Reviewed-by: liach ------------- PR: https://git.openjdk.org/valhalla/pull/1836 From vromero at openjdk.org Tue Jan 13 14:44:07 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 13 Jan 2026 14:44:07 GMT Subject: Integrated: Fix nullability signature attr tests In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 19:03:13 GMT, Vicente Romero wrote: > fixing regression tests related to signatures with null restricted elements This pull request has now been integrated. Changeset: ce62d388 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/ce62d388a06e6f5d6f27be0c5aff2607b74e2a56 Stats: 279 lines in 1 file changed: 3 ins; 237 del; 39 mod Fix nullability signature attr tests Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1887 From mcimadamore at openjdk.org Tue Jan 13 16:38:28 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 13 Jan 2026 16:38:28 GMT Subject: RFR: Tweak error when a null-restricted field is missing an initializer Message-ID: The logic for issuing an error when a strict (instance) field is missing an initializer relies on there being some constructor at the end of which the error is reported. But if the constructor is a default constructor, there's no valid position where to report the error. To fix this, I looked at how errors for uninitialized final fields. In case of a default constructor the error is reported against the field decl, not the constructor. I've done the same for non-nullable fields. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/valhalla/pull/1897/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1897&range=00 Stats: 47 lines in 5 files changed: 34 ins; 6 del; 7 mod Patch: https://git.openjdk.org/valhalla/pull/1897.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1897/head:pull/1897 PR: https://git.openjdk.org/valhalla/pull/1897 From jsikstro at openjdk.org Tue Jan 13 16:52:27 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 13 Jan 2026 16:52:27 GMT Subject: [lworld] Integrated: 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 10:27:39 GMT, Joel Sikstr?m wrote: > Hello, > > The hierarchies in oopsHierarchy.hpp are not up to date with the actual class hierarchies in the implementation. I've refered to these a couple of times and stumble on the fact that they are not accurate. > > I've tested that this builds locally. This pull request has now been integrated. Changeset: ac859351 Author: Joel Sikstr?m Committer: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/ac85935180bd33ffc9e3d48dfb66105d00037ca3 Stats: 11 lines in 2 files changed: 4 ins; 3 del; 4 mod 8374882: [lworld] Update hierarchies in oopsHierarchy.hpp Reviewed-by: phubner, aboldtch, fparain ------------- PR: https://git.openjdk.org/valhalla/pull/1874 From vromero at openjdk.org Tue Jan 13 17:27:41 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 13 Jan 2026 17:27:41 GMT Subject: RFR: Tweak error when a null-restricted field is missing an initializer In-Reply-To: References: Message-ID: <55nNzsQOBf4ljHnWMdeFh_fcFCu2Go78_O3CCvgrxvA=.584f50e5-94ac-452d-8c81-5af4c48db7ec@github.com> On Tue, 13 Jan 2026 16:29:30 GMT, Maurizio Cimadamore wrote: > The logic for issuing an error when a strict (instance) field is missing an initializer relies on there being some constructor at the end of which the error is reported. > > But if the constructor is a default constructor, there's no valid position where to report the error. > > To fix this, I looked at how errors for uninitialized final fields. In case of a default constructor the error is reported against the field decl, not the constructor. I've done the same for non-nullable fields. lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1897#pullrequestreview-3656995068 From mcimadamore at openjdk.org Tue Jan 13 17:30:17 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 13 Jan 2026 17:30:17 GMT Subject: Integrated: Tweak error when a null-restricted field is missing an initializer In-Reply-To: References: Message-ID: <-5F40Do3xw6rh3uQV9Hcl3bwPe_ImA9blNiLnBGKFHA=.b827ecdf-9df0-4025-845e-9d3473d0cf67@github.com> On Tue, 13 Jan 2026 16:29:30 GMT, Maurizio Cimadamore wrote: > The logic for issuing an error when a strict (instance) field is missing an initializer relies on there being some constructor at the end of which the error is reported. > > But if the constructor is a default constructor, there's no valid position where to report the error. > > To fix this, I looked at how errors for uninitialized final fields. In case of a default constructor the error is reported against the field decl, not the constructor. I've done the same for non-nullable fields. This pull request has now been integrated. Changeset: 25483b53 Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/25483b53b0dfb2d3efedd6c82927034237dd4fdd Stats: 47 lines in 5 files changed: 34 ins; 6 del; 7 mod Tweak error when a null-restricted field is missing an initializer Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1897 From dcubed at openjdk.org Tue Jan 13 17:57:02 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 13 Jan 2026 17:57:02 GMT Subject: [lworld] RFR: 8375064: [lworld] ProblemList vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java on windows-x64 In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 01:54:24 GMT, Roger Riggs wrote: >> Trivial fixes to ProblemList various tests: >> - [JDK-8375064](https://bugs.openjdk.org/browse/JDK-8375064) [lworld] ProblemList vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java on windows-x64 >> - [JDK-8375071](https://bugs.openjdk.org/browse/JDK-8375071) [lworld] ProblemList vmTestbase/nsk/jdi/Accessible/modifiers/modifiers001/TestDescription.java with --enable-preview >> - [JDK-8375075](https://bugs.openjdk.org/browse/JDK-8375075) [lworld] ProblemList vmTestbase/nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe001/TestDescription.java with --enable-preview >> - [JDK-8375077](https://bugs.openjdk.org/browse/JDK-8375077) [lworld] ProblemList two JDI scenario tests failing on windows-x64 > > Looks fine @RogerRiggs - Thanks for the review. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1889#issuecomment-3745636693 From dcubed at openjdk.org Tue Jan 13 17:57:03 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 13 Jan 2026 17:57:03 GMT Subject: [lworld] Integrated: 8375064: [lworld] ProblemList vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java on windows-x64 In-Reply-To: References: Message-ID: <6XFMHsO5_O3rU33folxsUJ-xU0IzwXwlIeLV4QIfLFY=.6f35e886-6215-42db-8483-fc7d7a7c73a2@github.com> On Mon, 12 Jan 2026 21:03:04 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList various tests: > - [JDK-8375064](https://bugs.openjdk.org/browse/JDK-8375064) [lworld] ProblemList vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java on windows-x64 > - [JDK-8375071](https://bugs.openjdk.org/browse/JDK-8375071) [lworld] ProblemList vmTestbase/nsk/jdi/Accessible/modifiers/modifiers001/TestDescription.java with --enable-preview > - [JDK-8375075](https://bugs.openjdk.org/browse/JDK-8375075) [lworld] ProblemList vmTestbase/nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe001/TestDescription.java with --enable-preview > - [JDK-8375077](https://bugs.openjdk.org/browse/JDK-8375077) [lworld] ProblemList two JDI scenario tests failing on windows-x64 This pull request has now been integrated. Changeset: 0219c392 Author: Daniel D. Daugherty URL: https://git.openjdk.org/valhalla/commit/0219c39223a6302df5b65ac9791fd4e4a56503d9 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod 8375064: [lworld] ProblemList vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java on windows-x64 8375071: [lworld] ProblemList vmTestbase/nsk/jdi/Accessible/modifiers/modifiers001/TestDescription.java with --enable-preview 8375075: [lworld] ProblemList vmTestbase/nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe001/TestDescription.java with --enable-preview 8375077: [lworld] ProblemList two JDI scenario tests failing on windows-x64 Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/valhalla/pull/1889 From darcy at openjdk.org Tue Jan 13 18:06:16 2026 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 13 Jan 2026 18:06:16 GMT Subject: RFR: 8356104: Add bfloat16 implementation for testing purposes Message-ID: Add a stand-alone Bfloat16 implementation for testing purposes. ------------- Commit messages: - JDK-8356104: Add bfloat16 implementation for testing purposes Changes: https://git.openjdk.org/valhalla/pull/1890/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1890&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356104 Stats: 4029 lines in 4 files changed: 4029 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1890.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1890/head:pull/1890 PR: https://git.openjdk.org/valhalla/pull/1890 From darcy at openjdk.org Tue Jan 13 18:13:09 2026 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 13 Jan 2026 18:13:09 GMT Subject: Integrated: 8356104: Add bfloat16 implementation for testing purposes In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 23:00:43 GMT, Joe Darcy wrote: > Add a stand-alone Bfloat16 implementation for testing purposes. This pull request has now been integrated. Changeset: c18f6a85 Author: Joe Darcy URL: https://git.openjdk.org/valhalla/commit/c18f6a85902e8654b428c08aa882f0c9dcc95355 Stats: 4029 lines in 4 files changed: 4029 ins; 0 del; 0 mod 8356104: Add bfloat16 implementation for testing purposes ------------- PR: https://git.openjdk.org/valhalla/pull/1890 From mcimadamore at openjdk.org Tue Jan 13 18:56:15 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 13 Jan 2026 18:56:15 GMT Subject: Integrated: Initial push for type classes support In-Reply-To: <3CiG5FS93fJ0PNzs9AZAPQSYUNvjJf1LnBHDpakfRPs=.f22ae810-6e47-479a-a656-9b9b8d281bfd@github.com> References: <3CiG5FS93fJ0PNzs9AZAPQSYUNvjJf1LnBHDpakfRPs=.f22ae810-6e47-479a-a656-9b9b8d281bfd@github.com> Message-ID: On Mon, 12 Jan 2026 17:58:42 GMT, Maurizio Cimadamore wrote: > This PR contains support for an experimental type classes feature. > >> [!WARNING] >> Given the highly experimental nature of this work, nothing is settled in stone, and the comments below are mostly provided as a general guidance on how to use what's there. > > For instance, given a record declaration like this: > > > record MyInt(int x) { } > > > We can define a new type class, for addition, using a regular interface, like so: > > > interface Sum { > X zero(); > X add(X a, X b); > } > > And then define a _witness field_ of the type class `Sum` for the type `MyInt`, using the `__witness` keyword, like so: > > > __witness Sum SUM_MYINT = new Sum<>() { > MyInt zero() { return new MyInt(0); } > MyInt add(MyInt a, MyInt b) { return new MyInt(a.x + b.x); } > }; > > (For correctness, this field should be declared either in `Sum` or in `MyInt`) > > Once defined, a witness can be _looked up_ using its type, like so: > > > Sum sum = Sum.__witness; > MyInt zero = sum.zero(); > MyInt one = new MyInt(1); > assert sum.add(zero, one).equals(one); > > > This prototype contains other features, such as the declaration of witness methods, and the ability to perform witness lookups at runtime. For more examples, please refer to the tests under `test/langtools/tools/javac/typeClasses`. This pull request has now been integrated. Changeset: 75a36f3f Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/75a36f3f912d869d5fcedce89844d4f41ce608a0 Stats: 3205 lines in 55 files changed: 3165 ins; 1 del; 39 mod Initial push for type classes support ------------- PR: https://git.openjdk.org/valhalla/pull/1886 From mcimadamore at openjdk.org Tue Jan 13 19:00:20 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 13 Jan 2026 19:00:20 GMT Subject: RFR: Add NULL_CHECKED flag to array creation calls Message-ID: <2IbslL7nRFlmpGwuep3jfJV3HGMwYmLH7y09eFnQC_U=.47a212e9-7694-44ad-8a96-66199ba6ce75@github.com> The synthetic calls to `ArrayCreation` for non-null array initializers should pass the `NULL_CHECKED` flag, so that the library can act accordingly. ------------- Commit messages: - Add NULL_CHECK flag to array creation calls Changes: https://git.openjdk.org/valhalla/pull/1898/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1898&range=00 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1898.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1898/head:pull/1898 PR: https://git.openjdk.org/valhalla/pull/1898 From mcimadamore at openjdk.org Tue Jan 13 19:04:41 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 13 Jan 2026 19:04:41 GMT Subject: Integrated: Add NULL_CHECKED flag to array creation calls In-Reply-To: <2IbslL7nRFlmpGwuep3jfJV3HGMwYmLH7y09eFnQC_U=.47a212e9-7694-44ad-8a96-66199ba6ce75@github.com> References: <2IbslL7nRFlmpGwuep3jfJV3HGMwYmLH7y09eFnQC_U=.47a212e9-7694-44ad-8a96-66199ba6ce75@github.com> Message-ID: On Tue, 13 Jan 2026 18:55:03 GMT, Maurizio Cimadamore wrote: > The synthetic calls to `ArrayCreation` for non-null array initializers should pass the `NULL_CHECKED` flag, so that the library can act accordingly. This pull request has now been integrated. Changeset: 73e1a6fa Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/73e1a6fa5cbf7610501ebe0d7d0193bb49e151ae Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Add NULL_CHECKED flag to array creation calls ------------- PR: https://git.openjdk.org/valhalla/pull/1898 From dcubed at openjdk.org Tue Jan 13 19:08:32 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 13 Jan 2026 19:08:32 GMT Subject: [lworld] RFR: 8375087: [lworld] ProblemList java/util/Collection/MOAT.java Message-ID: Trivial fixes to ProblemList various tests: - [JDK-8375087](https://bugs.openjdk.org/browse/JDK-8375087) [lworld] ProblemList java/util/Collection/MOAT.java A trivial fix to ProblemList java/util/Collection/MOAT.java. Note: A better fix would be to limit this to C1, but there isn't a C1 specific ProblemList. - [JDK-8375204](https://bugs.openjdk.org/browse/JDK-8375204) [lworld] ProblemList compiler/valhalla/inlinetypes/TestOopsInReturnConvention.java#c1 with AotJdk on windows-x64 This is a trivial test fix to a default timeout value: - [JDK-8375207](https://bugs.openjdk.org/browse/JDK-8375207) [lworld] java/util/ResourceBundle/modules/basic/BasicTest.java times out on windows-x64 in Xcomp mode ------------- Commit messages: - 8375207: [lworld] java/util/ResourceBundle/modules/basic/BasicTest.java times out on windows-x64 in Xcomp mode - 8375204: [lworld] ProblemList compiler/valhalla/inlinetypes/TestOopsInReturnConvention.java#c1 with AotJdk on windows-x64 - 8375087: [lworld] ProblemList java/util/Collection/MOAT.java Changes: https://git.openjdk.org/valhalla/pull/1891/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1891&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375087 Stats: 36 lines in 3 files changed: 32 ins; 0 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1891.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1891/head:pull/1891 PR: https://git.openjdk.org/valhalla/pull/1891 From vromero at openjdk.org Tue Jan 13 19:51:07 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 13 Jan 2026 19:51:07 GMT Subject: RFR: do not generate null checks for record patterns In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 03:13:16 GMT, Vicente Romero wrote: > do not generate null checks for record patterns src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 170: > 168: public void visitLetExpr(LetExpr tree) { > 169: // don't recurse inside let expressions, they are backend artifacts > 170: result = tree; offline suggestion from Jan Lahoda: this code will skip all let expressions which is too broad, as let expressions are generated also by switch expressions but could contain user code. For example there is no null check generated in this case: void main() { int i = switch (new Object()) { default -> { Object obj = null; Object! nonNull = obj; yield 0; } }; } ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1884#discussion_r2687884486 From coleenp at openjdk.org Tue Jan 13 20:10:22 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 13 Jan 2026 20:10:22 GMT Subject: [lworld] RFR: 8375087: [lworld] ProblemList java/util/Collection/MOAT.java In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 01:30:11 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList various tests: > - [JDK-8375087](https://bugs.openjdk.org/browse/JDK-8375087) [lworld] ProblemList java/util/Collection/MOAT.java > A trivial fix to ProblemList java/util/Collection/MOAT.java. > Note: A better fix would be to limit this to C1, but there isn't a C1 specific ProblemList. > - [JDK-8375204](https://bugs.openjdk.org/browse/JDK-8375204) [lworld] ProblemList compiler/valhalla/inlinetypes/TestOopsInReturnConvention.java#c1 with AotJdk on windows-x64 > > This is a trivial test fix to a default timeout value: > - [JDK-8375207](https://bugs.openjdk.org/browse/JDK-8375207) [lworld] java/util/ResourceBundle/modules/basic/BasicTest.java times out on windows-x64 in Xcomp mode Looks good! ------------- Marked as reviewed by coleenp (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1891#pullrequestreview-3657752258 From dcubed at openjdk.org Tue Jan 13 20:17:42 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 13 Jan 2026 20:17:42 GMT Subject: [lworld] RFR: 8375087: [lworld] ProblemList java/util/Collection/MOAT.java In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 20:06:49 GMT, Coleen Phillimore wrote: >> Trivial fixes to ProblemList various tests: >> - [JDK-8375087](https://bugs.openjdk.org/browse/JDK-8375087) [lworld] ProblemList java/util/Collection/MOAT.java >> A trivial fix to ProblemList java/util/Collection/MOAT.java. >> Note: A better fix would be to limit this to C1, but there isn't a C1 specific ProblemList. >> - [JDK-8375204](https://bugs.openjdk.org/browse/JDK-8375204) [lworld] ProblemList compiler/valhalla/inlinetypes/TestOopsInReturnConvention.java#c1 with AotJdk on windows-x64 >> >> This is a trivial test fix to a default timeout value: >> - [JDK-8375207](https://bugs.openjdk.org/browse/JDK-8375207) [lworld] java/util/ResourceBundle/modules/basic/BasicTest.java times out on windows-x64 in Xcomp mode > > Looks good! @coleenp - Thanks for the review! Is there a time frame where Valhalla PRs or MRs are supposed to wait before integration? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1891#issuecomment-3746390545 From dcubed at openjdk.org Tue Jan 13 20:37:56 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 13 Jan 2026 20:37:56 GMT Subject: [lworld] Integrated: 8375087: [lworld] ProblemList java/util/Collection/MOAT.java In-Reply-To: References: Message-ID: <81WTeSLi3yU1UbE822pkD9ipNBPbaAvIKkjAksSqvbc=.86ce3db0-afbb-49a0-b4dd-591ec17749f0@github.com> On Tue, 13 Jan 2026 01:30:11 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList various tests: > - [JDK-8375087](https://bugs.openjdk.org/browse/JDK-8375087) [lworld] ProblemList java/util/Collection/MOAT.java > A trivial fix to ProblemList java/util/Collection/MOAT.java. > Note: A better fix would be to limit this to C1, but there isn't a C1 specific ProblemList. > - [JDK-8375204](https://bugs.openjdk.org/browse/JDK-8375204) [lworld] ProblemList compiler/valhalla/inlinetypes/TestOopsInReturnConvention.java#c1 with AotJdk on windows-x64 > > This is a trivial test fix to a default timeout value: > - [JDK-8375207](https://bugs.openjdk.org/browse/JDK-8375207) [lworld] java/util/ResourceBundle/modules/basic/BasicTest.java times out on windows-x64 in Xcomp mode This pull request has now been integrated. Changeset: 9fd45925 Author: Daniel D. Daugherty URL: https://git.openjdk.org/valhalla/commit/9fd45925c0ebd4bde6535f8b07046a853c899317 Stats: 36 lines in 3 files changed: 32 ins; 0 del; 4 mod 8375087: [lworld] ProblemList java/util/Collection/MOAT.java Reviewed-by: coleenp ------------- PR: https://git.openjdk.org/valhalla/pull/1891 From vromero at openjdk.org Tue Jan 13 21:08:08 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 13 Jan 2026 21:08:08 GMT Subject: RFR: do not generate null checks for record patterns [v2] In-Reply-To: References: Message-ID: > do not generate null checks for record patterns Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'bworld' into do.not.generate.null.checks.for.record.patterns - do not generate null checks for record patterns ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1884/files - new: https://git.openjdk.org/valhalla/pull/1884/files/38845f27..6cd6ebf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1884&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1884&range=00-01 Stats: 890 lines in 37 files changed: 347 ins; 356 del; 187 mod Patch: https://git.openjdk.org/valhalla/pull/1884.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1884/head:pull/1884 PR: https://git.openjdk.org/valhalla/pull/1884 From darcy at openjdk.org Tue Jan 13 21:11:27 2026 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 13 Jan 2026 21:11:27 GMT Subject: RFR: 8375223: Add proper toString output to bfloat16 implementation Message-ID: Add toString() implementation that follows "shortest string" conventions. Follow-up testing to be done under JDK-8375224: Add tests for Bfloat16.toString(). ------------- Commit messages: - 8375223: Add proper toString output to bfloat16 implementation Changes: https://git.openjdk.org/valhalla/pull/1900/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1900&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375223 Stats: 159 lines in 1 file changed: 75 ins; 23 del; 61 mod Patch: https://git.openjdk.org/valhalla/pull/1900.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1900/head:pull/1900 PR: https://git.openjdk.org/valhalla/pull/1900 From fparain at openjdk.org Tue Jan 13 21:29:57 2026 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 13 Jan 2026 21:29:57 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v2] In-Reply-To: References: Message-ID: > Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case. > This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic. Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: More renaming ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1407/files - new: https://git.openjdk.org/valhalla/pull/1407/files/972768c8..91c57ec1 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1407&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1407&range=00-01 Stats: 90 lines in 11 files changed: 0 ins; 0 del; 90 mod Patch: https://git.openjdk.org/valhalla/pull/1407.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1407/head:pull/1407 PR: https://git.openjdk.org/valhalla/pull/1407 From vromero at openjdk.org Tue Jan 13 22:33:36 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 13 Jan 2026 22:33:36 GMT Subject: RFR: do not generate null checks for record patterns [v3] In-Reply-To: References: Message-ID: > do not generate null checks for record patterns Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1884/files - new: https://git.openjdk.org/valhalla/pull/1884/files/6cd6ebf8..b10490e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1884&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1884&range=01-02 Stats: 40 lines in 4 files changed: 19 ins; 20 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1884.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1884/head:pull/1884 PR: https://git.openjdk.org/valhalla/pull/1884 From sspitsyn at openjdk.org Wed Jan 14 00:50:05 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Jan 2026 00:50:05 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 20:00:45 GMT, Alex Menkov wrote: > Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. > Added the test for value object ctor debugging, the test verifies the behaviour is expected. > There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) > > testing: tier1..4, hs-tier5-svc test/jdk/com/sun/jdi/valhalla/CtorDebuggingTest.java line 218: > 216: > 217: // TestScaffold is not very good in handling multiple breakpoints. > 218: // This halper class is a listener which resumes debuggee after breakpoints. Nit: Typo: s/halper/helper/ ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2684617918 From vromero at openjdk.org Wed Jan 14 03:31:06 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 14 Jan 2026 03:31:06 GMT Subject: Integrated: Merge lworld Message-ID: Merge branch 'lworld' into lw5_merge_lworld # Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ------------- Commit messages: - white space - Merge branch 'lworld' into lw5_merge_lworld - Merge lworld - 8373670: [lworld] Relax jcheck checks - Merge - Merge - Merge lworld - Merge lworld - Merge lworld - 8347754: [lw5] fix the order of nullness markers in signatures - ... and 64 more: https://git.openjdk.org/valhalla/compare/9fd45925...40cced7e The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/valhalla/pull/1901/files Stats: 6804 lines in 102 files changed: 6680 ins; 2 del; 122 mod Patch: https://git.openjdk.org/valhalla/pull/1901.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1901/head:pull/1901 PR: https://git.openjdk.org/valhalla/pull/1901 From vromero at openjdk.org Wed Jan 14 03:31:07 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 14 Jan 2026 03:31:07 GMT Subject: Integrated: Merge lworld In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 03:15:48 GMT, Vicente Romero wrote: > Merge branch 'lworld' into lw5_merge_lworld > # Conflicts: > # src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java This pull request has now been integrated. Changeset: 2041a5a9 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/2041a5a98aa23854fba37430608eb3f452df5a58 Stats: 50911 lines in 1052 files changed: 33522 ins; 11651 del; 5738 mod Merge lworld ------------- PR: https://git.openjdk.org/valhalla/pull/1901 From cjplummer at openjdk.org Wed Jan 14 04:47:20 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Jan 2026 04:47:20 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 20:00:45 GMT, Alex Menkov wrote: > Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. > Added the test for value object ctor debugging, the test verifies the behaviour is expected. > There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) > > testing: tier1..4, hs-tier5-svc src/java.se/share/data/jdwp/jdwp.spec line 1804: > 1802: ) > 1803: ) > 1804: (Command IsSameObject=11 Are you going to add "preview API" warnings to these two APIs? src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 171: > 169: public int hashCode() { > 170: try { > 171: return JDWP.ObjectReference.ObjectHashCode.process(vm, this).hashCode; Don't we want to limit the slow path to value objects? src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java line 334: > 332: > 333: // Inline type is a concrete value class. > 334: boolean isInlined() { Why is this called isInlined()? Shouldn't it be isValueClass()? Do we want to expose it to users through ReferenceType? Should we also consider exposing a new isIdentity() API? src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java line 341: > 339: return ((modifiers & VMModifiers.IDENTITY) == 0) > 340: && ((modifiers & VMModifiers.INTERFACE) == 0) > 341: && ((modifiers & VMModifiers.ABSTRACT) == 0); ReferenceTypeImpl has isXXX() apis to check these modifiers. We should probably use them here and add isIdentity(). It's unclear to me why you have to check INTERFACE and ABSTRACT. Isn't IDENTITY enough, or do interfaces and abstract classes not have the IDENTITY bit set? test/jdk/com/sun/jdi/valhalla/CtorDebuggingTest.java line 69: > 67: import com.sun.jdi.request.EventRequestManager; > 68: > 69: public class CtorDebuggingTest extends TestScaffold { I think this test would benefit from more comments. It would be good to describe all the scenarios being tested, probably in one main comment block early on, and then for implementation of each scenario add a one line comment indicating which scenarios is being tested. test/jdk/com/sun/jdi/valhalla/CtorDebuggingTest.java line 129: > 127: } catch (IncompatibleThreadStateException ex) { > 128: System.out.println("ERROR: cannot get 'this' object: " + ex); > 129: return null; It seems this just results in the caller getting an NPE. Wouldn't it be better to just throw a RuntimeException here? test/jdk/com/sun/jdi/valhalla/CtorDebuggingTest.java line 262: > 260: } > 261: > 262: // Resumes the debuggee and go through all breackpoints until the location specified is reached. Suggestion: // Resumes the debuggee and goes through all breakpoints until the location specified is reached. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2688880160 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2688888544 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2688904914 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2688899731 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2688918832 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2688915482 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2688911651 From cjplummer at openjdk.org Wed Jan 14 04:47:22 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Jan 2026 04:47:22 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: <5hpmTChRrvNzzQRudMdFGshCA5UDK0I59AgcBQiQke8=.bc38ebd5-0807-42c0-abf2-0f141d0dabce@github.com> References: <5hpmTChRrvNzzQRudMdFGshCA5UDK0I59AgcBQiQke8=.bc38ebd5-0807-42c0-abf2-0f141d0dabce@github.com> Message-ID: On Mon, 12 Jan 2026 22:25:59 GMT, Serguei Spitsyn wrote: >> Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. >> Added the test for value object ctor debugging, the test verifies the behaviour is expected. >> There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) >> >> testing: tier1..4, hs-tier5-svc > > src/java.se/share/data/jdwp/jdwp.spec line 1830: > >> 1828: (Error VM_DEAD) >> 1829: ) >> 1830: ) > > I wonder if the `(Error NOT_IMPLEMENTED)` should also be included. Should we also consider to introduce one more field in the `CapabilitiesNew=17` command? We didn't do similar for Loom related APIs. I looked through the current canXXX list, and they all seem related to JVMTI capabilities, which don't apply to these two APIs. I think the expectation should be that the user checks the JDWP version to determine if it is implemented. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2688886477 From cjplummer at openjdk.org Wed Jan 14 04:47:23 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Jan 2026 04:47:23 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 20:41:02 GMT, Alex Menkov wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c line 410: >> >>> 408: >>> 409: ref = commonRef_idToRef(env, id); >>> 410: (void)outStream_writeInt(out, objectHashCode(ref)); >> >> Interesting that the debug agent already has an objectHashCode() but there were no users of it. > > `ObjectReferenceImpl.hashCode()` calculates it by itself from objectID (it should call objectHashCode) I'm not sure what you are referring to here. I don't see `ObjectReferenceImpl.hashCode()`. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2688908775 From mchevalier at openjdk.org Wed Jan 14 08:37:56 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 14 Jan 2026 08:37:56 GMT Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail with --enable-preview [v4] In-Reply-To: References: Message-ID: > Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time. > > There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop. > > The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have > > value class MyValue { > int x; > } > class C { > MyValue v; // assumed flat. > } > > the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset. > > I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array. > > The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That matches what we do in `void ciField::i... Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Revert a testing mistake - Forgot a flag - Improve comment - review - Merge remote-tracking branch 'origin/lworld' into JDK-8372700 - Merge remote-tracking branch 'origin/lworld' into JDK-8372700 - review - Solving conflict with myself: Merge remote-tracking branch 'lworld' into JDK-8372700 - Un-problemlist - Merge remote-tracking branch 'origin/lworld' into JDK-8372700 - ... and 11 more: https://git.openjdk.org/valhalla/compare/90dfb439...fc7bfdba ------------- Changes: https://git.openjdk.org/valhalla/pull/1826/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1826&range=03 Stats: 469 lines in 23 files changed: 444 ins; 7 del; 18 mod Patch: https://git.openjdk.org/valhalla/pull/1826.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1826/head:pull/1826 PR: https://git.openjdk.org/valhalla/pull/1826 From mchevalier at openjdk.org Wed Jan 14 08:46:14 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 14 Jan 2026 08:46:14 GMT Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail with --enable-preview [v5] In-Reply-To: References: Message-ID: > Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time. > > There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop. > > The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have > > value class MyValue { > int x; > } > class C { > MyValue v; // assumed flat. > } > > the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset. > > I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array. > > The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That matches what we do in `void ciField::i... Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge remote-tracking branch 'origin/lworld' into JDK-8372700 - Revert a testing mistake - Forgot a flag - Improve comment - review - Merge remote-tracking branch 'origin/lworld' into JDK-8372700 - Merge remote-tracking branch 'origin/lworld' into JDK-8372700 - review - Solving conflict with myself: Merge remote-tracking branch 'lworld' into JDK-8372700 - Un-problemlist - ... and 12 more: https://git.openjdk.org/valhalla/compare/9fd45925...65c47272 ------------- Changes: https://git.openjdk.org/valhalla/pull/1826/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1826&range=04 Stats: 469 lines in 23 files changed: 444 ins; 7 del; 18 mod Patch: https://git.openjdk.org/valhalla/pull/1826.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1826/head:pull/1826 PR: https://git.openjdk.org/valhalla/pull/1826 From sspitsyn at openjdk.org Wed Jan 14 08:46:36 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Jan 2026 08:46:36 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 04:22:42 GMT, Chris Plummer wrote: >> Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. >> Added the test for value object ctor debugging, the test verifies the behaviour is expected. >> There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) >> >> testing: tier1..4, hs-tier5-svc > > src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 171: > >> 169: public int hashCode() { >> 170: try { >> 171: return JDWP.ObjectReference.ObjectHashCode.process(vm, this).hashCode; > > Don't we want to limit the slow path to value objects? > We didn't do similar for Loom related APIs. I looked through the current canXXX list, and they all seem related to JVMTI capabilities, which don't apply to these two APIs. I think the expectation should be that the user checks the JDWP version to determine if it is implemented. Yes, I remember about Loom. Asked this to be sure we are in sync. I agree with your suggestion. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2689501709 From sspitsyn at openjdk.org Wed Jan 14 08:56:54 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Jan 2026 08:56:54 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 04:34:02 GMT, Chris Plummer wrote: > Why is this called isInlined()? Shouldn't it be isValueClass()? I had the same question. The `isInlined()` matches the obsolete approach. The `isValueClass()` looks better. > Do we want to expose it to users through ReferenceType? This is not clear yet. If the JDI implementation needed it then there are some chances debuggers may need it as well. We have some time to decide. Preview allows to change the API spec in the future. > Should we also consider exposing a new isIdentity() API? Not clear as well. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2689538582 From mchevalier at openjdk.org Wed Jan 14 09:18:03 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 14 Jan 2026 09:18:03 GMT Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail with --enable-preview [v6] In-Reply-To: References: Message-ID: <17lJbuMciUXOOqT7ldDkxon3PsuTlnDk8vd55L8JxJ4=.73381eda-3d7b-4ce2-9935-07cd5caf6d40@github.com> > Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time. > > There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop. > > The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have > > value class MyValue { > int x; > } > class C { > MyValue v; // assumed flat. > } > > the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset. > > I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array. > > The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That matches what we do in `void ciField::i... Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision: Update copyrights ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1826/files - new: https://git.openjdk.org/valhalla/pull/1826/files/65c47272..84e5fbb1 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1826&range=05 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1826&range=04-05 Stats: 21 lines in 21 files changed: 3 ins; 0 del; 18 mod Patch: https://git.openjdk.org/valhalla/pull/1826.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1826/head:pull/1826 PR: https://git.openjdk.org/valhalla/pull/1826 From mchevalier at openjdk.org Wed Jan 14 10:00:44 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 14 Jan 2026 10:00:44 GMT Subject: [lworld] RFR: 8373982: [lworld] Verification code in InlineTypeNode::has_phi_inputs does not check all field values In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 09:59:14 GMT, Marc Chevalier wrote: > This PR makes a for loop in `bool InlineTypeNode::has_phi_inputs(Node* region)` actually iterate over every field. > > It doesn't seem to trigger any crash in tiers tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. > > Thanks, > Marc Thanks for review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1892#issuecomment-3748724991 From mchevalier at openjdk.org Wed Jan 14 10:03:32 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 14 Jan 2026 10:03:32 GMT Subject: [lworld] Integrated: 8373982: [lworld] Verification code in InlineTypeNode::has_phi_inputs does not check all field values In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 09:59:14 GMT, Marc Chevalier wrote: > This PR makes a for loop in `bool InlineTypeNode::has_phi_inputs(Node* region)` actually iterate over every field. > > It doesn't seem to trigger any crash in tiers tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. > > Thanks, > Marc This pull request has now been integrated. Changeset: ad6f21a9 Author: Marc Chevalier URL: https://git.openjdk.org/valhalla/commit/ad6f21a96869096da67b13234b6a24ca07aea27e Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8373982: [lworld] Verification code in InlineTypeNode::has_phi_inputs does not check all field values Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1892 From mchevalier at openjdk.org Wed Jan 14 10:03:51 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 14 Jan 2026 10:03:51 GMT Subject: [lworld] RFR: 8374116: [lworld] TestIntrinsics::test82 fails post JDK-8372634 In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 10:13:23 GMT, Marc Chevalier wrote: > Before [JDK-8372634](https://bugs.openjdk.org/browse/JDK-8372634) in `Parse::sharpen_type_after_if`, we had > https://github.com/openjdk/valhalla/blob/4e9525ef3619b02e905f16b89261b82c70830f3a/src/hotspot/share/opto/parse2.cpp#L1727-L1733 > where `static Node* extract_obj_from_klass_load(PhaseGVN* gvn, Node* n)` can fail > https://github.com/openjdk/valhalla/blob/4e9525ef3619b02e905f16b89261b82c70830f3a/src/hotspot/share/opto/parse2.cpp#L1695-L1708 > if `val` is not a `LoadKlass` (or narrow version of it). In this case, `obj` would be `nullptr` and then nothing is done. > > Now, we have > https://github.com/openjdk/valhalla/blob/f2e56e4c18080616e8ef275a3d9c1da824efda26/src/hotspot/share/opto/parse2.cpp#L1805-L1807 > that can take this branch > https://github.com/openjdk/valhalla/blob/f2e56e4c18080616e8ef275a3d9c1da824efda26/src/hotspot/share/opto/parse2.cpp#L1734-L1741 > where `extract_obj_from_klass_load` is unchanged, and can still fail. Yet, we have an `assert` now. That seems slightly fishy, but except in the case at hand, it doesn't mean to fire, so... it might be ok? Otherwise, replacing the return with `return (*obj) != nullptr;` would work. > > But in the case we have, there isn't a `Bool(CmpP(LoadKlass(obj._klass), ConP(Foo.klass)), [eq])` as written in the comment, but instead a > > Bool(FlatArrayCheck(Proj[mem](...), ConP), [eq]) > > This happens because `FlatArrayCheckNode` is a derived class from `CmpNode`. Yet, it doesn't work like a normal compare node: it's not necessarily binary, but mostly, having a constant operand doesn't allow to refine the other. So I suggest we don't even try `sharpen_type_after_if` in this case. > > > Thanks, > Marc Thanks @merykitty and @TobiHartmann for reviews! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1893#issuecomment-3748729654 From mchevalier at openjdk.org Wed Jan 14 10:03:52 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 14 Jan 2026 10:03:52 GMT Subject: [lworld] Integrated: 8374116: [lworld] TestIntrinsics::test82 fails post JDK-8372634 In-Reply-To: References: Message-ID: <8MezamRat9rAriCNEnLyYUnZoqWSLsLYdsOIPOEXR1Q=.a26ce22a-65c2-4316-a34f-64fc8bbfde2a@github.com> On Tue, 13 Jan 2026 10:13:23 GMT, Marc Chevalier wrote: > Before [JDK-8372634](https://bugs.openjdk.org/browse/JDK-8372634) in `Parse::sharpen_type_after_if`, we had > https://github.com/openjdk/valhalla/blob/4e9525ef3619b02e905f16b89261b82c70830f3a/src/hotspot/share/opto/parse2.cpp#L1727-L1733 > where `static Node* extract_obj_from_klass_load(PhaseGVN* gvn, Node* n)` can fail > https://github.com/openjdk/valhalla/blob/4e9525ef3619b02e905f16b89261b82c70830f3a/src/hotspot/share/opto/parse2.cpp#L1695-L1708 > if `val` is not a `LoadKlass` (or narrow version of it). In this case, `obj` would be `nullptr` and then nothing is done. > > Now, we have > https://github.com/openjdk/valhalla/blob/f2e56e4c18080616e8ef275a3d9c1da824efda26/src/hotspot/share/opto/parse2.cpp#L1805-L1807 > that can take this branch > https://github.com/openjdk/valhalla/blob/f2e56e4c18080616e8ef275a3d9c1da824efda26/src/hotspot/share/opto/parse2.cpp#L1734-L1741 > where `extract_obj_from_klass_load` is unchanged, and can still fail. Yet, we have an `assert` now. That seems slightly fishy, but except in the case at hand, it doesn't mean to fire, so... it might be ok? Otherwise, replacing the return with `return (*obj) != nullptr;` would work. > > But in the case we have, there isn't a `Bool(CmpP(LoadKlass(obj._klass), ConP(Foo.klass)), [eq])` as written in the comment, but instead a > > Bool(FlatArrayCheck(Proj[mem](...), ConP), [eq]) > > This happens because `FlatArrayCheckNode` is a derived class from `CmpNode`. Yet, it doesn't work like a normal compare node: it's not necessarily binary, but mostly, having a constant operand doesn't allow to refine the other. So I suggest we don't even try `sharpen_type_after_if` in this case. > > > Thanks, > Marc This pull request has now been integrated. Changeset: 2d489873 Author: Marc Chevalier URL: https://git.openjdk.org/valhalla/commit/2d4898738b1b220b544499a2f49ac3d1cd2bf687 Stats: 7 lines in 2 files changed: 5 ins; 1 del; 1 mod 8374116: [lworld] TestIntrinsics::test82 fails post JDK-8372634 Reviewed-by: qamai, thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1893 From thartmann at openjdk.org Wed Jan 14 10:18:23 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 14 Jan 2026 10:18:23 GMT Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail with --enable-preview [v6] In-Reply-To: <17lJbuMciUXOOqT7ldDkxon3PsuTlnDk8vd55L8JxJ4=.73381eda-3d7b-4ce2-9935-07cd5caf6d40@github.com> References: <17lJbuMciUXOOqT7ldDkxon3PsuTlnDk8vd55L8JxJ4=.73381eda-3d7b-4ce2-9935-07cd5caf6d40@github.com> Message-ID: On Wed, 14 Jan 2026 09:18:03 GMT, Marc Chevalier wrote: >> Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time. >> >> There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop. >> >> The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have >> >> value class MyValue { >> int x; >> } >> class C { >> MyValue v; // assumed flat. >> } >> >> the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset. >> >> I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array. >> >> The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That ma... > > Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision: > > Update copyrights Great work Marc! This looks good to me. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1826#pullrequestreview-3659925642 From mcimadamore at openjdk.org Wed Jan 14 11:06:15 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 14 Jan 2026 11:06:15 GMT Subject: RFR: do not generate null checks for record patterns [v3] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 19:46:48 GMT, Vicente Romero wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> addressing review comments > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 170: > >> 168: public void visitLetExpr(LetExpr tree) { >> 169: // don't recurse inside let expressions, they are backend artifacts >> 170: result = tree; > > offline suggestion from Jan Lahoda: > > this code will skip all let expressions which is too broad, as let expressions are generated also by switch expressions but could contain user code. For example there is no null check generated in this case: > > void main() { > int i = switch (new Object()) { > default -> { > Object obj = null; > Object! nonNull = obj; > yield 0; > } > }; > } Actually, I think we can remove this visitor. Sure, javac will add an extra, redundant null check for null-restricted type test patterns, but that's not incorrect (this check will never throw NPE because, if `null`, the pattern won't match -- thanks to your changes in `TransPatterns`). I think I prefer a redundant check than having to mark all LetExpr that might need recursion (as we will surely forget some). Separately, we can work on removing redundant null checks -- e.g. for things that are co-compiled and such, in which case this will fall out for free. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1884#discussion_r2689983882 From mchevalier at openjdk.org Wed Jan 14 11:06:15 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 14 Jan 2026 11:06:15 GMT Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail with --enable-preview [v6] In-Reply-To: <17lJbuMciUXOOqT7ldDkxon3PsuTlnDk8vd55L8JxJ4=.73381eda-3d7b-4ce2-9935-07cd5caf6d40@github.com> References: <17lJbuMciUXOOqT7ldDkxon3PsuTlnDk8vd55L8JxJ4=.73381eda-3d7b-4ce2-9935-07cd5caf6d40@github.com> Message-ID: On Wed, 14 Jan 2026 09:18:03 GMT, Marc Chevalier wrote: >> Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time. >> >> There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop. >> >> The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have >> >> value class MyValue { >> int x; >> } >> class C { >> MyValue v; // assumed flat. >> } >> >> the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset. >> >> I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array. >> >> The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That ma... > > Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision: > > Update copyrights Thanks for reviews @TobiHartmann! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1826#issuecomment-3748992118 From mchevalier at openjdk.org Wed Jan 14 11:06:17 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 14 Jan 2026 11:06:17 GMT Subject: [lworld] Integrated: 8372700: [lworld] compiler/c2/irTests/stable/* fail with --enable-preview In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 12:01:36 GMT, Marc Chevalier wrote: > Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time. > > There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop. > > The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have > > value class MyValue { > int x; > } > class C { > MyValue v; // assumed flat. > } > > the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset. > > I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array. > > The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That matches what we do in `void ciField::i... This pull request has now been integrated. Changeset: c7174f5a Author: Marc Chevalier URL: https://git.openjdk.org/valhalla/commit/c7174f5ab6b7c91a59deaec6566f8eea96747716 Stats: 489 lines in 23 files changed: 447 ins; 7 del; 35 mod 8372700: [lworld] compiler/c2/irTests/stable/* fail with --enable-preview Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1826 From jlahoda at openjdk.org Wed Jan 14 14:00:24 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 14 Jan 2026 14:00:24 GMT Subject: RFR: Improving pattern handling for non-null types Message-ID: <2bntKyppM4ygMZVtWrEI2md8hhvVEnVLkFFjTEU5GZI=.6a8d32f8-b682-4bfa-86f1-990942734f50@github.com> Fixes dominance for binding/any patterns whose types have a bang, attempting to improve parsing of patterns with emoticon, ensuring correct desugaring of patterns with emoticon, adding tests. Include code done by @vicente-romero-oracle (https://github.com/openjdk/valhalla/pull/1884) ------------- Commit messages: - Cleanup. - Improving pattern handling for non-null types; includes code by Vicente. Changes: https://git.openjdk.org/valhalla/pull/1902/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1902&range=00 Stats: 205 lines in 5 files changed: 182 ins; 17 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/1902.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1902/head:pull/1902 PR: https://git.openjdk.org/valhalla/pull/1902 From vromero at openjdk.org Wed Jan 14 14:00:25 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 14 Jan 2026 14:00:25 GMT Subject: RFR: Improving pattern handling for non-null types In-Reply-To: <2bntKyppM4ygMZVtWrEI2md8hhvVEnVLkFFjTEU5GZI=.6a8d32f8-b682-4bfa-86f1-990942734f50@github.com> References: <2bntKyppM4ygMZVtWrEI2md8hhvVEnVLkFFjTEU5GZI=.6a8d32f8-b682-4bfa-86f1-990942734f50@github.com> Message-ID: On Wed, 14 Jan 2026 13:51:24 GMT, Jan Lahoda wrote: > Fixes dominance for binding/any patterns whose types have a bang, attempting to improve parsing of patterns with emoticon, ensuring correct desugaring of patterns with emoticon, adding tests. > > Include code done by @vicente-romero-oracle (https://github.com/openjdk/valhalla/pull/1884) lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1902#pullrequestreview-3660861277 From mcimadamore at openjdk.org Wed Jan 14 14:04:21 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 14 Jan 2026 14:04:21 GMT Subject: RFR: do not generate null checks for record patterns [v3] In-Reply-To: References: Message-ID: <1GE3ne1gMrNfnhBeqenOL64VGQBnJAC7fYeSHwDR73w=.8074d1ca-f458-430d-b894-26f9b2156d15@github.com> On Tue, 13 Jan 2026 22:33:36 GMT, Vicente Romero wrote: >> do not generate null checks for record patterns > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments Looks good! ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1884#pullrequestreview-3660882501 From vromero at openjdk.org Wed Jan 14 14:04:24 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 14 Jan 2026 14:04:24 GMT Subject: Withdrawn: do not generate null checks for record patterns In-Reply-To: References: Message-ID: <7oMLjSo9-DdnqHc4uwnUd_wSec65yjc3RHJXqnLS65M=.c53898a7-a6a4-4c54-9329-7bd4fb3924d8@github.com> On Sun, 11 Jan 2026 03:13:16 GMT, Vicente Romero wrote: > do not generate null checks for record patterns This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/valhalla/pull/1884 From vromero at openjdk.org Wed Jan 14 14:04:22 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 14 Jan 2026 14:04:22 GMT Subject: RFR: do not generate null checks for record patterns [v3] In-Reply-To: References: Message-ID: <-DqOsSkDjR05At7MGbDEtyajfpGPHQxF2zog1Nj1S28=.c8a43af6-4823-4424-b29b-44fc9cf7afdc@github.com> On Tue, 13 Jan 2026 22:33:36 GMT, Vicente Romero wrote: >> do not generate null checks for record patterns > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments superseded by: https://github.com/openjdk/valhalla/pull/1902 ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1884#issuecomment-3749698424 From mcimadamore at openjdk.org Wed Jan 14 14:04:43 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 14 Jan 2026 14:04:43 GMT Subject: RFR: Improving pattern handling for non-null types In-Reply-To: <2bntKyppM4ygMZVtWrEI2md8hhvVEnVLkFFjTEU5GZI=.6a8d32f8-b682-4bfa-86f1-990942734f50@github.com> References: <2bntKyppM4ygMZVtWrEI2md8hhvVEnVLkFFjTEU5GZI=.6a8d32f8-b682-4bfa-86f1-990942734f50@github.com> Message-ID: On Wed, 14 Jan 2026 13:51:24 GMT, Jan Lahoda wrote: > Fixes dominance for binding/any patterns whose types have a bang, attempting to improve parsing of patterns with emoticon, ensuring correct desugaring of patterns with emoticon, adding tests. > > Include code done by @vicente-romero-oracle (https://github.com/openjdk/valhalla/pull/1884) Looks good to me! ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1902#pullrequestreview-3660880710 From duke at openjdk.org Wed Jan 14 14:22:37 2026 From: duke at openjdk.org (duke) Date: Wed, 14 Jan 2026 14:22:37 GMT Subject: RFR: Improving pattern handling for non-null types In-Reply-To: <2bntKyppM4ygMZVtWrEI2md8hhvVEnVLkFFjTEU5GZI=.6a8d32f8-b682-4bfa-86f1-990942734f50@github.com> References: <2bntKyppM4ygMZVtWrEI2md8hhvVEnVLkFFjTEU5GZI=.6a8d32f8-b682-4bfa-86f1-990942734f50@github.com> Message-ID: On Wed, 14 Jan 2026 13:51:24 GMT, Jan Lahoda wrote: > Fixes dominance for binding/any patterns whose types have a bang, attempting to improve parsing of patterns with emoticon, ensuring correct desugaring of patterns with emoticon, adding tests. > > Include code done by @vicente-romero-oracle (https://github.com/openjdk/valhalla/pull/1884) @lahodaj Your change (at version 316a980145ccd6892f20d9b710b52d86d81bc126) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1902#issuecomment-3749785978 From jlahoda at openjdk.org Wed Jan 14 14:22:36 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 14 Jan 2026 14:22:36 GMT Subject: RFR: Improving pattern handling for non-null types In-Reply-To: <2bntKyppM4ygMZVtWrEI2md8hhvVEnVLkFFjTEU5GZI=.6a8d32f8-b682-4bfa-86f1-990942734f50@github.com> References: <2bntKyppM4ygMZVtWrEI2md8hhvVEnVLkFFjTEU5GZI=.6a8d32f8-b682-4bfa-86f1-990942734f50@github.com> Message-ID: On Wed, 14 Jan 2026 13:51:24 GMT, Jan Lahoda wrote: > Fixes dominance for binding/any patterns whose types have a bang, attempting to improve parsing of patterns with emoticon, ensuring correct desugaring of patterns with emoticon, adding tests. > > Include code done by @vicente-romero-oracle (https://github.com/openjdk/valhalla/pull/1884) Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1902#issuecomment-3749779835 From jlahoda at openjdk.org Wed Jan 14 14:49:01 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 14 Jan 2026 14:49:01 GMT Subject: Integrated: Improving pattern handling for non-null types In-Reply-To: <2bntKyppM4ygMZVtWrEI2md8hhvVEnVLkFFjTEU5GZI=.6a8d32f8-b682-4bfa-86f1-990942734f50@github.com> References: <2bntKyppM4ygMZVtWrEI2md8hhvVEnVLkFFjTEU5GZI=.6a8d32f8-b682-4bfa-86f1-990942734f50@github.com> Message-ID: On Wed, 14 Jan 2026 13:51:24 GMT, Jan Lahoda wrote: > Fixes dominance for binding/any patterns whose types have a bang, attempting to improve parsing of patterns with emoticon, ensuring correct desugaring of patterns with emoticon, adding tests. > > Include code done by @vicente-romero-oracle (https://github.com/openjdk/valhalla/pull/1884) This pull request has now been integrated. Changeset: d35a2974 Author: Jan Lahoda Committer: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/d35a29748d94d1c91f6c58273cb3cc95871f7efc Stats: 205 lines in 5 files changed: 182 ins; 17 del; 6 mod Improving pattern handling for non-null types Co-authored-by: Vicente Romero Reviewed-by: vromero, mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1902 From thartmann at openjdk.org Wed Jan 14 15:58:16 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 14 Jan 2026 15:58:16 GMT Subject: [lworld] RFR: 8365989: [lworld] Un-ProblemList MemoryAccessProviderTest.java and TestHotSpotResolvedJavaField.java Message-ID: We can un-problem list the tests because https://github.com/openjdk/valhalla/pull/1712 disabled the assert in Valhalla. Once [JDK-8350208](https://bugs.openjdk.org/browse/JDK-8350208) is merged, [JDK-8371125](https://bugs.openjdk.org/browse/JDK-8371125) will re-enable the assert. Thanks, Tobias ------------- Commit messages: - Un problem listing Changes: https://git.openjdk.org/valhalla/pull/1904/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1904&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365989 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1904.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1904/head:pull/1904 PR: https://git.openjdk.org/valhalla/pull/1904 From mchevalier at openjdk.org Wed Jan 14 16:09:19 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 14 Jan 2026 16:09:19 GMT Subject: [lworld] RFR: 8365989: [lworld] Un-ProblemList MemoryAccessProviderTest.java and TestHotSpotResolvedJavaField.java In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:50:39 GMT, Tobias Hartmann wrote: > We can un-problem list the tests because https://github.com/openjdk/valhalla/pull/1712 disabled the assert in Valhalla. Once [JDK-8350208](https://bugs.openjdk.org/browse/JDK-8350208) is merged, [JDK-8371125](https://bugs.openjdk.org/browse/JDK-8371125) will re-enable the assert. > > Thanks, > Tobias 2 fewer ProblemList at once! ------------- Marked as reviewed by mchevalier (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1904#pullrequestreview-3661536546 From fparain at openjdk.org Wed Jan 14 17:25:14 2026 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 14 Jan 2026 17:25:14 GMT Subject: [lworld] RFR: 8375328: [lworld] JNI IsSameObject function doesn't use the alternate substitutability method Message-ID: Small fix to align the implementation of JNI function IsSameObject with the implementation of `if_acmp` in the rest of the JVM. Tested locally. Fred ------------- Commit messages: - Add support for the alrternate substitutability method Changes: https://git.openjdk.org/valhalla/pull/1905/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1905&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375328 Stats: 11 lines in 2 files changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1905.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1905/head:pull/1905 PR: https://git.openjdk.org/valhalla/pull/1905 From cjplummer at openjdk.org Wed Jan 14 18:24:46 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Jan 2026 18:24:46 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: <7IymBi22WboLv9fHnpyxnox0r8z0p9TGWJgvNuFh-po=.71a8cbb2-1bd3-4c4e-beb2-86c7ab0ea356@github.com> On Thu, 18 Dec 2025 20:00:45 GMT, Alex Menkov wrote: > Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. > Added the test for value object ctor debugging, the test verifies the behaviour is expected. > There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) > > testing: tier1..4, hs-tier5-svc src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 150: > 148: public boolean equals(Object obj) { > 149: if (obj instanceof ObjectReferenceImpl other) { > 150: if (!super.equals(obj)) { // checks if the references belong to the same VM Have you considered adding a `this == obj` check at the beginning of this method. I think usually we are dealing with the same heap object, so this could be a quick check done for performance reasons. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2691548928 From heidinga at openjdk.org Wed Jan 14 18:49:47 2026 From: heidinga at openjdk.org (Dan Heidinga) Date: Wed, 14 Jan 2026 18:49:47 GMT Subject: [lworld] RFR: 8375328: [lworld] JNI IsSameObject function doesn't use the alternate substitutability method In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 17:20:04 GMT, Frederic Parain wrote: > Small fix to align the implementation of JNI function IsSameObject with the implementation of `if_acmp` in the rest of the JVM. > > Tested locally. > > Fred looks good ------------- Marked as reviewed by heidinga (no project role). PR Review: https://git.openjdk.org/valhalla/pull/1905#pullrequestreview-3662255757 From dcubed at openjdk.org Wed Jan 14 19:20:29 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 14 Jan 2026 19:20:29 GMT Subject: [lworld] RFR: 8375337: [lworld] ProblemList misc svc tests that fail due to JDK-8375332 Message-ID: A trivial fix to ProblemList misc svc tests that fail due to JDK-8375332. Please note that the test/jdk/ProblemList-coh.txt is new and this changeset includes the Makefile update to add JTREG_AUTO_PROBLEM_LISTS for it. ------------- Commit messages: - 8375337: [lworld] ProblemList misc svc tests that fail due to JDK-8375332 Changes: https://git.openjdk.org/valhalla/pull/1906/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1906&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375337 Stats: 38 lines in 2 files changed: 37 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1906.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1906/head:pull/1906 PR: https://git.openjdk.org/valhalla/pull/1906 From darcy at openjdk.org Wed Jan 14 19:32:19 2026 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 14 Jan 2026 19:32:19 GMT Subject: Integrated: 8375223: Add proper toString output to bfloat16 implementation In-Reply-To: References: Message-ID: <-wH2xUkEu_EVUJyf9uaIzuUcOlwcgrYMCeHfN1l0kTQ=.f625071d-ecec-404b-8e1a-c3f85f048c90@github.com> On Tue, 13 Jan 2026 21:03:41 GMT, Joe Darcy wrote: > Add toString() implementation that follows "shortest string" conventions. > > Follow-up testing to be done under JDK-8375224: Add tests for Bfloat16.toString(). This pull request has now been integrated. Changeset: f4bb4686 Author: Joe Darcy URL: https://git.openjdk.org/valhalla/commit/f4bb46866df6810aeba0d2fb602752ef07bf85c9 Stats: 159 lines in 1 file changed: 75 ins; 23 del; 61 mod 8375223: Add proper toString output to bfloat16 implementation Co-authored-by: Raffaello Giulietti ------------- PR: https://git.openjdk.org/valhalla/pull/1900 From coleenp at openjdk.org Wed Jan 14 20:25:54 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 14 Jan 2026 20:25:54 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v2] In-Reply-To: References: Message-ID: <7MOS5ouxv2QqlXu-s_m_LKzD5XMUeNMBTn6am-COjBU=.356e1b35-4aa2-4456-b661-563190184b40@github.com> On Tue, 13 Jan 2026 21:29:57 GMT, Frederic Parain wrote: >> Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case. >> This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic. > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > More renaming I have a couple questions and comments. Looks good as an extension to the existing field layout design. src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1212: > 1210: _null_free_non_atomic_layout_alignment = _payload_alignment; > 1211: } > 1212: if (UseNullableValueFlattening) { Could this be else if (UseNullableValueFlattening)? These are mutually exclusive iirc so the else if would make that explicit. src/hotspot/share/oops/inlineKlass.cpp line 175: > 173: case LayoutKind::NULLABLE_NON_ATOMIC_FLAT: > 174: assert(has_nullable_non_atomic_layout(), "Layout not available"); > 175: return null_free_non_atomic_alignment(); Should this be nullable_non_atomic_alignment() ? Or is it the same alignment as null_free_non_atomic_alignment? (if so pls comment why) src/hotspot/share/oops/inlineKlass.cpp line 191: > 189: break; > 190: case LayoutKind::NULL_FREE_ATOMIC_FLAT: > 191: return has_null_free_atomic_layout(); This was a good renaming. src/hotspot/share/oops/inlineKlass.hpp line 95: > 93: int _null_free_atomic_size_in_bytes; // size and alignment requirement for a null-free atomic layout, -1 if no atomic flat layout is possible > 94: int _nullable_atomic_size_in_bytes; // size and alignment requirement for a nullable layout (always atomic), -1 if no nullable flat layout is possible > 95: int _nullable_non_atomic_size_in_bytes; // size and alignment requirement for a nullable non-atomic layout, -1 if not available Here is something that I'm confused about. Does an InlineKlass have multiple possible layouts and sizes depending on the container? Is that why the InlineKlass needs to save all these size non-static data members? src/hotspot/share/oops/layoutKind.hpp line 69: > 67: // always be filled with zeros, and the default value could have its null marker set to non-zero if > 68: // it is used as a source to update a NULLABLE_ATOMIC_FLAT field. > 69: // NULLABLE_NON_ATOMIC_FLAT: this is a special layout, only used for strict final non-static fields. Because strict Can you capitalize 't' in "this" in these descriptions? ------------- PR Review: https://git.openjdk.org/valhalla/pull/1407#pullrequestreview-3662553059 PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2691869321 PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2691888393 PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2691889170 PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2691894006 PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2691902085 From coleenp at openjdk.org Wed Jan 14 20:25:56 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 14 Jan 2026 20:25:56 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v2] In-Reply-To: <7MOS5ouxv2QqlXu-s_m_LKzD5XMUeNMBTn6am-COjBU=.356e1b35-4aa2-4456-b661-563190184b40@github.com> References: <7MOS5ouxv2QqlXu-s_m_LKzD5XMUeNMBTn6am-COjBU=.356e1b35-4aa2-4456-b661-563190184b40@github.com> Message-ID: On Wed, 14 Jan 2026 20:14:07 GMT, Coleen Phillimore wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> More renaming > > src/hotspot/share/oops/inlineKlass.hpp line 95: > >> 93: int _null_free_atomic_size_in_bytes; // size and alignment requirement for a null-free atomic layout, -1 if no atomic flat layout is possible >> 94: int _nullable_atomic_size_in_bytes; // size and alignment requirement for a nullable layout (always atomic), -1 if no nullable flat layout is possible >> 95: int _nullable_non_atomic_size_in_bytes; // size and alignment requirement for a nullable non-atomic layout, -1 if not available > > Here is something that I'm confused about. Does an InlineKlass have multiple possible layouts and sizes depending on the container? Is that why the InlineKlass needs to save all these size non-static data members? Can you align the // s please? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2691895437 From amenkov at openjdk.org Wed Jan 14 20:27:14 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 14 Jan 2026 20:27:14 GMT Subject: [lworld] RFR: 8375337: [lworld] ProblemList misc svc tests that fail due to JDK-8375332 In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 19:13:28 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList misc svc tests that fail due to JDK-8375332. > > Please note that the test/jdk/ProblemList-coh.txt is new and this changeset > includes the Makefile update to add JTREG_AUTO_PROBLEM_LISTS for it. Marked as reviewed by amenkov (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1906#pullrequestreview-3662628283 From dcubed at openjdk.org Wed Jan 14 21:13:18 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 14 Jan 2026 21:13:18 GMT Subject: [lworld] RFR: 8375337: [lworld] ProblemList misc svc tests that fail due to JDK-8375332 In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 20:25:07 GMT, Alex Menkov wrote: >> A trivial fix to ProblemList misc svc tests that fail due to JDK-8375332. >> >> Please note that the test/jdk/ProblemList-coh.txt is new and this changeset >> includes the Makefile update to add JTREG_AUTO_PROBLEM_LISTS for it. > > Marked as reviewed by amenkov (Committer). @alexmenkov - Thanks for the review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1906#issuecomment-3751732256 From dcubed at openjdk.org Wed Jan 14 21:17:06 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 14 Jan 2026 21:17:06 GMT Subject: [lworld] Integrated: 8375337: [lworld] ProblemList misc svc tests that fail due to JDK-8375332 In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 19:13:28 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList misc svc tests that fail due to JDK-8375332. > > Please note that the test/jdk/ProblemList-coh.txt is new and this changeset > includes the Makefile update to add JTREG_AUTO_PROBLEM_LISTS for it. This pull request has now been integrated. Changeset: 338b8596 Author: Daniel D. Daugherty URL: https://git.openjdk.org/valhalla/commit/338b85967b6eb4bc7ff0e0e24fffc159e9d41691 Stats: 38 lines in 2 files changed: 37 ins; 0 del; 1 mod 8375337: [lworld] ProblemList misc svc tests that fail due to JDK-8375332 Reviewed-by: amenkov ------------- PR: https://git.openjdk.org/valhalla/pull/1906 From rriggs at openjdk.org Wed Jan 14 22:05:58 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 14 Jan 2026 22:05:58 GMT Subject: [lworld] RFR: 8375320: [lworld] Revert System.identityHashcode for value objects to non AltSubstitutability version Message-ID: Restore the unconditional use of value_object_hash_code_method. The Alt hashcode method based on the Unsafe.getFieldMap is not used. System.identityHashCode uses ValueObjectMethods.valueObjectHashCode() implemented using the original method-handle implementation. ------------- Commit messages: - 8375320: [lworld] Revert SystemIdentityHashcode for wrapper objects non AltSubstitutability version Changes: https://git.openjdk.org/valhalla/pull/1907/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1907&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375320 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1907.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1907/head:pull/1907 PR: https://git.openjdk.org/valhalla/pull/1907 From qamai at openjdk.org Wed Jan 14 23:45:32 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 14 Jan 2026 23:45:32 GMT Subject: [lworld] RFR: 8375196: [lworld] TestArrays triggers assert in LRG::set_num_regs Message-ID: Hi, The issue is that `PhaseMacroExpand::value_from_mem_phi` does not take into consideration flat arrays, so it incorrectly returns the whole object for a load from one of its fields. This results in a byte `Phi` with an input being an `oop`, triggering the assert during `LRG::set_num_regs` because the size of a `Phi` and its input are different. Please take a look and leave your reviews, thanks a lot. ------------- Commit messages: - Fix folding initial value from an allocation Changes: https://git.openjdk.org/valhalla/pull/1909/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1909&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375196 Stats: 97 lines in 2 files changed: 58 ins; 29 del; 10 mod Patch: https://git.openjdk.org/valhalla/pull/1909.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1909/head:pull/1909 PR: https://git.openjdk.org/valhalla/pull/1909 From amenkov at openjdk.org Thu Jan 15 00:32:10 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 Jan 2026 00:32:10 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 04:36:54 GMT, Chris Plummer wrote: >> `ObjectReferenceImpl.hashCode()` calculates it by itself from objectID (it should call objectHashCode) > > I'm not sure what you are referring to here. I don't see `ObjectReferenceImpl.hashCode()`. `hashCode()` is right after `ObjectReferenceImpl.equals()` (ObjectReferenceImpl.java line 168) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692520380 From amenkov at openjdk.org Thu Jan 15 00:32:07 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 Jan 2026 00:32:07 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: <5hpmTChRrvNzzQRudMdFGshCA5UDK0I59AgcBQiQke8=.bc38ebd5-0807-42c0-abf2-0f141d0dabce@github.com> Message-ID: On Wed, 14 Jan 2026 04:21:10 GMT, Chris Plummer wrote: >> src/java.se/share/data/jdwp/jdwp.spec line 1830: >> >>> 1828: (Error VM_DEAD) >>> 1829: ) >>> 1830: ) >> >> I wonder if the `(Error NOT_IMPLEMENTED)` should also be included. Should we also consider to introduce one more field in the `CapabilitiesNew=17` command? > > We didn't do similar for Loom related APIs. I looked through the current canXXX list, and they all seem related to JVMTI capabilities, which don't apply to these two APIs. I think the expectation should be that the user checks the JDWP version to determine if it is implemented. I see now how the "versioning" works. I added `boolean VirtualMachineImpl.canUseIsSameObject()` to check if IsSameObject/ObjectHashCode are available ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692317354 From amenkov at openjdk.org Thu Jan 15 00:32:09 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 Jan 2026 00:32:09 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 08:43:34 GMT, Serguei Spitsyn wrote: >> src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 171: >> >>> 169: public int hashCode() { >>> 170: try { >>> 171: return JDWP.ObjectReference.ObjectHashCode.process(vm, this).hashCode; >> >> Don't we want to limit the slow path to value objects? > >> We didn't do similar for Loom related APIs. I looked through the current canXXX list, and they all seem related to JVMTI capabilities, which don't apply to these two APIs. I think the expectation should be that the user checks the JDWP version to determine if it is implemented. > > Yes, I remember about Loom. Asked this to be sure we are in sync. I agree with your suggestion. > Don't we want to limit the slow path to value objects? ok >> src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java line 334: >> >>> 332: >>> 333: // Inline type is a concrete value class. >>> 334: boolean isInlined() { >> >> Why is this called isInlined()? Shouldn't it be isValueClass()? Do we want to expose it to users through ReferenceType? Should we also consider exposing a new isIdentity() API? > >> Why is this called isInlined()? Shouldn't it be isValueClass()? > > I had the same question. The `isInlined()` matches the obsolete approach. The `isValueClass()` looks better. > >> Do we want to expose it to users through ReferenceType? > > If the JDI implementation needed it then there are some chances debuggers may need it as well. We have some time to decide. Preview allows to change the API specs in the future. I have a minor preference to expose it now. It is pretty simple and clear. > >> Should we also consider exposing a new isIdentity() API? > > It would be consistent with other modifier bits. `isInlined` name (and its implementation) is consistent with hotspot code. This API if required by ObjectReferenceImpl to determine if the reference is a value object (so the class cannot be abstract or interface). To me `IsIdentity` (I think `isValue` is better) should be in `ClassType`, I'm updating ClassTypeImpl, it can be added to ClassType interface later if debuggers really need it). ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692339958 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692365585 From amenkov at openjdk.org Thu Jan 15 00:32:05 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 Jan 2026 00:32:05 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: <5kHPQPGP150SmC3IeFFycWm5FYTBed5OtzbeGkzSI0E=.4cfae6e4-5b23-48da-a0ae-580859635146@github.com> On Wed, 14 Jan 2026 04:16:31 GMT, Chris Plummer wrote: >> Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. >> Added the test for value object ctor debugging, the test verifies the behaviour is expected. >> There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) >> >> testing: tier1..4, hs-tier5-svc > > src/java.se/share/data/jdwp/jdwp.spec line 1804: > >> 1802: ) >> 1803: ) >> 1804: (Command IsSameObject=11 > > Are you going to add "preview API" warnings to these two APIs? I'm not sure it makes much sense. They are quite generic, I think about adding them to mainline in jdk 27 (but don't use by ObjectReferenceImpl.equals/hashCode) > src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 150: > >> 148: public boolean equals(Object obj) { >> 149: if (obj instanceof ObjectReferenceImpl other) { >> 150: if (!super.equals(obj)) { // checks if the references belong to the same VM > > Have you considered adding a `this == obj` check at the beginning of this method. I think usually we are dealing with the same heap object, so this could be a quick check done for performance reasons. If we decide to change this, it would be better to do it in mainline > src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java line 341: > >> 339: return ((modifiers & VMModifiers.IDENTITY) == 0) >> 340: && ((modifiers & VMModifiers.INTERFACE) == 0) >> 341: && ((modifiers & VMModifiers.ABSTRACT) == 0); > > ReferenceTypeImpl has isXXX() apis to check these modifiers. We should probably use them here and add isIdentity(). > > It's unclear to me why you have to check INTERFACE and ABSTRACT. Isn't IDENTITY enough, or do interfaces and abstract classes not have the IDENTITY bit set? value class can be abstract. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692311793 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692513236 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692508079 From amenkov at openjdk.org Thu Jan 15 00:32:11 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 Jan 2026 00:32:11 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 18:59:04 GMT, Serguei Spitsyn wrote: >> We have isSameObject too (and it's used in many places) > > Yes, the same. `isSameObject` already exists and is called at ~20 places. Functions in this file are local, just to register command handlers, so naming are not so important as for existing `isSameObject` ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692528700 From cjplummer at openjdk.org Thu Jan 15 02:25:49 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Jan 2026 02:25:49 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: <5hpmTChRrvNzzQRudMdFGshCA5UDK0I59AgcBQiQke8=.bc38ebd5-0807-42c0-abf2-0f141d0dabce@github.com> Message-ID: On Wed, 14 Jan 2026 22:39:34 GMT, Alex Menkov wrote: >> We didn't do similar for Loom related APIs. I looked through the current canXXX list, and they all seem related to JVMTI capabilities, which don't apply to these two APIs. I think the expectation should be that the user checks the JDWP version to determine if it is implemented. > > I see now how the "versioning" works. > I added `boolean VirtualMachineImpl.canUseIsSameObject()` to check if IsSameObject/ObjectHashCode are available Can you explain your "versioning" comment. My point was that by using versioning you should not need VirtualMachine.canUseIsSameObject ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692709650 From cjplummer at openjdk.org Thu Jan 15 02:25:51 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Jan 2026 02:25:51 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 22:58:16 GMT, Alex Menkov wrote: > isInlined name (and its implementation) is consistent with hotspot code. But in the case of JDI we are talking about a potentially external API. >To me IsIdentity (I think isValue is better) should be in ClassType We need to be careful of the use of "value" in JDI since we already have com.sun.jdi.Value, which peculates into all sorts of APIs like ObjectReference.getValue(Field) and BooleanValue. It doesn't help any that we also have Value.type(). ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692723345 From cjplummer at openjdk.org Thu Jan 15 02:25:53 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Jan 2026 02:25:53 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: <5kHPQPGP150SmC3IeFFycWm5FYTBed5OtzbeGkzSI0E=.4cfae6e4-5b23-48da-a0ae-580859635146@github.com> References: <5kHPQPGP150SmC3IeFFycWm5FYTBed5OtzbeGkzSI0E=.4cfae6e4-5b23-48da-a0ae-580859635146@github.com> Message-ID: On Thu, 15 Jan 2026 00:14:44 GMT, Alex Menkov wrote: >> src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java line 341: >> >>> 339: return ((modifiers & VMModifiers.IDENTITY) == 0) >>> 340: && ((modifiers & VMModifiers.INTERFACE) == 0) >>> 341: && ((modifiers & VMModifiers.ABSTRACT) == 0); >> >> ReferenceTypeImpl has isXXX() apis to check these modifiers. We should probably use them here and add isIdentity(). >> >> It's unclear to me why you have to check INTERFACE and ABSTRACT. Isn't IDENTITY enough, or do interfaces and abstract classes not have the IDENTITY bit set? > > value class can be abstract. So if you have a value class, the IDENTITY bit will not be set, but if the ABSTRCT bit is also set, the above logic produces false, even though it is value class and you want it to produce true. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692730005 From amenkov at openjdk.org Thu Jan 15 02:37:08 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 Jan 2026 02:37:08 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: <5hpmTChRrvNzzQRudMdFGshCA5UDK0I59AgcBQiQke8=.bc38ebd5-0807-42c0-abf2-0f141d0dabce@github.com> Message-ID: On Thu, 15 Jan 2026 02:11:02 GMT, Chris Plummer wrote: > Can you explain your "versioning" comment. My point was that by using versioning you should not need VirtualMachine.canUseIsSameObject `VirtualMachineImpl.canUseIsSameObject()` checks that JDWP version >= 27 (similar to `VirtualMachineImpl.mayCreateVirtualThreads()` which checks that version >= 19 and some other VirtualMachineImpl methods) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692749774 From amenkov at openjdk.org Thu Jan 15 02:51:27 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 Jan 2026 02:51:27 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 02:17:54 GMT, Chris Plummer wrote: >> `isInlined` name (and its implementation) is consistent with hotspot code. >> This API if required by ObjectReferenceImpl to determine if the reference is a value object (so the class cannot be abstract or interface). >> To me `IsIdentity` (I think `isValue` is better) should be in `ClassType`, I'm updating ClassTypeImpl, it can be added to ClassType interface later if debuggers really need it). > >> isInlined name (and its implementation) is consistent with hotspot code. > But in the case of JDI we are talking about a potentially external API. > >>To me IsIdentity (I think isValue is better) should be in ClassType > We need to be careful of the use of "value" in JDI since we already have com.sun.jdi.Value, which peculates into all sorts of APIs like ObjectReference.getValue(Field) and BooleanValue. It doesn't help any that we also have Value.type(). ClassType laready has `isEnum()`, so `isValue` looks more consistent. Maybe `isValueClass`? Anyway it's not too important now (while it's internal API) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692781368 From cjplummer at openjdk.org Thu Jan 15 04:46:04 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Jan 2026 04:46:04 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: <5hpmTChRrvNzzQRudMdFGshCA5UDK0I59AgcBQiQke8=.bc38ebd5-0807-42c0-abf2-0f141d0dabce@github.com> Message-ID: On Thu, 15 Jan 2026 02:33:23 GMT, Alex Menkov wrote: >> Can you explain your "versioning" comment. My point was that by using versioning you should not need VirtualMachine.canUseIsSameObject > >> Can you explain your "versioning" comment. My point was that by using versioning you should not need VirtualMachine.canUseIsSameObject > > `VirtualMachineImpl.canUseIsSameObject()` checks that JDWP version >= 27 (similar to > `VirtualMachineImpl.mayCreateVirtualThreads()` which checks that version >= 19 and some other VirtualMachineImpl methods) Ok, but those are private APIs. My point is that there is no need for a public canUseIsSameObject(). ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2692978046 From vromero at openjdk.org Thu Jan 15 05:52:55 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 15 Jan 2026 05:52:55 GMT Subject: RFR: add use site null checks Message-ID: Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them ------------- Commit messages: - generate by default - add use site null checks Changes: https://git.openjdk.org/valhalla/pull/1910/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=00 Stats: 155 lines in 2 files changed: 147 ins; 0 del; 8 mod Patch: https://git.openjdk.org/valhalla/pull/1910.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1910/head:pull/1910 PR: https://git.openjdk.org/valhalla/pull/1910 From thartmann at openjdk.org Thu Jan 15 06:00:38 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 15 Jan 2026 06:00:38 GMT Subject: [lworld] RFR: 8365989: [lworld] Un-ProblemList MemoryAccessProviderTest.java and TestHotSpotResolvedJavaField.java In-Reply-To: References: Message-ID: <5J-kDUPzheNhGLpwZCoxnP45MK-mw6EhBtPb3oKa6Jc=.22bc3765-7ca6-4759-9956-988b4c6c0027@github.com> On Wed, 14 Jan 2026 15:50:39 GMT, Tobias Hartmann wrote: > We can un-problem list the tests because https://github.com/openjdk/valhalla/pull/1712 disabled the assert in Valhalla. Once [JDK-8350208](https://bugs.openjdk.org/browse/JDK-8350208) is merged, [JDK-8371125](https://bugs.openjdk.org/browse/JDK-8371125) will re-enable the assert. > > Thanks, > Tobias Yes, getting there :) Thanks for the review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1904#issuecomment-3753014051 From thartmann at openjdk.org Thu Jan 15 06:00:38 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 15 Jan 2026 06:00:38 GMT Subject: [lworld] Integrated: 8365989: [lworld] Un-ProblemList MemoryAccessProviderTest.java and TestHotSpotResolvedJavaField.java In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:50:39 GMT, Tobias Hartmann wrote: > We can un-problem list the tests because https://github.com/openjdk/valhalla/pull/1712 disabled the assert in Valhalla. Once [JDK-8350208](https://bugs.openjdk.org/browse/JDK-8350208) is merged, [JDK-8371125](https://bugs.openjdk.org/browse/JDK-8371125) will re-enable the assert. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 5fb17768 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/5fb17768282b28467a236c3fd583e7eb61d3034c Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8365989: [lworld] Un-ProblemList MemoryAccessProviderTest.java and TestHotSpotResolvedJavaField.java Reviewed-by: mchevalier ------------- PR: https://git.openjdk.org/valhalla/pull/1904 From thartmann at openjdk.org Thu Jan 15 06:30:12 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 15 Jan 2026 06:30:12 GMT Subject: [lworld] RFR: 8375196: [lworld] TestArrays triggers assert in LRG::set_num_regs In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 23:38:13 GMT, Quan Anh Mai wrote: > Hi, > > The issue is that `PhaseMacroExpand::value_from_mem_phi` does not take into consideration flat arrays, so it incorrectly returns the whole object for a load from one of its fields. This results in a byte `Phi` with an input being an `oop`, triggering the assert during `LRG::set_num_regs` because the size of a `Phi` and its input are different. > > Please take a look and leave your reviews, thanks a lot. Nice, thanks for fixing this! src/hotspot/share/opto/macro.cpp line 489: > 487: // Cannot look through init_value if it is an oop > 488: if (!init_value->is_InlineType()) { > 489: return nullptr; I think I asked this before in another PR but I forgot in which context: Shouldn't `init_value` always be an `InlineTypeNode`? I think you then pointed by to my `TODO 8350865 [...]` comment in `LibraryCallKit::inline_newArray`. Once we fixed that, this check could go away. I think we have a few more such checks. Could you adapt the TODO in `LibraryCallKit::inline_newArray` with a reminder to update all those? ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1909#pullrequestreview-3664117101 PR Review Comment: https://git.openjdk.org/valhalla/pull/1909#discussion_r2693143839 From qamai at openjdk.org Thu Jan 15 07:06:34 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 15 Jan 2026 07:06:34 GMT Subject: [lworld] RFR: 8375196: [lworld] TestArrays triggers assert in LRG::set_num_regs [v2] In-Reply-To: References: Message-ID: <8xYc-H-wIOzYgwvkOhZlINWfhvNuIKjJG02zFEulJXI=.8388740b-6cc9-4d08-9427-beedc226019c@github.com> > Hi, > > The issue is that `PhaseMacroExpand::value_from_mem_phi` does not take into consideration flat arrays, so it incorrectly returns the whole object for a load from one of its fields. This results in a byte `Phi` with an input being an `oop`, triggering the assert during `LRG::set_num_regs` because the size of a `Phi` and its input are different. > > Please take a look and leave your reviews, thanks a lot. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: Add reminder at LibraryCallKit::inline_newArray ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1909/files - new: https://git.openjdk.org/valhalla/pull/1909/files/718c0d02..45b98d92 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1909&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1909&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1909.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1909/head:pull/1909 PR: https://git.openjdk.org/valhalla/pull/1909 From qamai at openjdk.org Thu Jan 15 07:06:36 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 15 Jan 2026 07:06:36 GMT Subject: [lworld] RFR: 8375196: [lworld] TestArrays triggers assert in LRG::set_num_regs [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 06:26:19 GMT, Tobias Hartmann wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> Add reminder at LibraryCallKit::inline_newArray > > src/hotspot/share/opto/macro.cpp line 489: > >> 487: // Cannot look through init_value if it is an oop >> 488: if (!init_value->is_InlineType()) { >> 489: return nullptr; > > I think I asked this before in another PR but I forgot in which context: Shouldn't `init_value` always be an `InlineTypeNode`? I think you then pointed by to my `TODO 8350865 [...]` comment in `LibraryCallKit::inline_newArray`. Once we fixed that, this check could go away. I think we have a few more such checks. Could you adapt the TODO in `LibraryCallKit::inline_newArray` with a reminder to update all those? That's right, I have added a reminder in that method. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1909#discussion_r2693209537 From thartmann at openjdk.org Thu Jan 15 07:53:18 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 15 Jan 2026 07:53:18 GMT Subject: [lworld] RFR: 8375366: [lworld] AcmpTest.java fails with OutOfMemoryError in stress-valhalla-StressG1 Message-ID: <8KPao_ELqBH94fcAzN9460OSXch_FppP_8eYOx3K9Os=.3d1ba3b8-0016-4826-a1b8-b2509592990d@github.com> We run the test with limited heap size in internal testing and it fails with an OutOfMemoryError because it pre-generates a large number of test cases and stores them in an ArrayList. Let's just execute the test cases directly instead. Thanks, Tobias ------------- Commit messages: - 8375366 Changes: https://git.openjdk.org/valhalla/pull/1911/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1911&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375366 Stats: 19 lines in 1 file changed: 0 ins; 9 del; 10 mod Patch: https://git.openjdk.org/valhalla/pull/1911.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1911/head:pull/1911 PR: https://git.openjdk.org/valhalla/pull/1911 From thartmann at openjdk.org Thu Jan 15 08:31:35 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 15 Jan 2026 08:31:35 GMT Subject: [lworld] RFR: 8375196: [lworld] TestArrays triggers assert in LRG::set_num_regs [v2] In-Reply-To: <8xYc-H-wIOzYgwvkOhZlINWfhvNuIKjJG02zFEulJXI=.8388740b-6cc9-4d08-9427-beedc226019c@github.com> References: <8xYc-H-wIOzYgwvkOhZlINWfhvNuIKjJG02zFEulJXI=.8388740b-6cc9-4d08-9427-beedc226019c@github.com> Message-ID: On Thu, 15 Jan 2026 07:06:34 GMT, Quan Anh Mai wrote: >> Hi, >> >> The issue is that `PhaseMacroExpand::value_from_mem_phi` does not take into consideration flat arrays, so it incorrectly returns the whole object for a load from one of its fields. This results in a byte `Phi` with an input being an `oop`, triggering the assert during `LRG::set_num_regs` because the size of a `Phi` and its input are different. >> >> Please take a look and leave your reviews, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > Add reminder at LibraryCallKit::inline_newArray Thanks! ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1909#pullrequestreview-3664430347 From mcimadamore at openjdk.org Thu Jan 15 09:45:42 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 15 Jan 2026 09:45:42 GMT Subject: RFR: add use site null checks In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 05:46:52 GMT, Vicente Romero wrote: > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 194: > 192: private List newArgs(Symbol.MethodSymbol msym, List actualArgs) { > 193: List declaredArgTypes = msym.type.asMethodType().argtypes; > 194: int externalArgsLength = msym.externalType(types).getParameterTypes().size() - declaredArgTypes.size(); Maybe calling this `prefixArgs` is more true to what this is (e.g. these are arguments added by Lower that should never be null. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1910#discussion_r2693671927 From mcimadamore at openjdk.org Thu Jan 15 09:55:58 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 15 Jan 2026 09:55:58 GMT Subject: RFR: add use site null checks In-Reply-To: References: Message-ID: <8Cny4Isa98j1tZhxgSgNhzTPgLhNsJouCYqJJiA4zB4=.cc4a28fe-ba03-4441-a60c-28fcf527989d@github.com> On Thu, 15 Jan 2026 05:46:52 GMT, Vicente Romero wrote: > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 204: > 202: } > 203: Type formalArgType = declaredArgTypes.head; > 204: if (msym.isVarArgs() && formalArgType == varArgsArg) { I think this check can misfire. Some types are shared -- e.g. syms.stringType, so you might get `==` in "wrong" places. That said, here `varArgsArg` is an array type, and for that we might always get a fresh instance... so it might work. It also looks like there might be a potential problem here -- this code runs _after_ varargs translation has occurred. Meaning that for varargs, we only see a javac-created array and we can check the variadic elements. But again, the plan here would be to disallow `C!...` so this is ok. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1910#discussion_r2693697618 From mcimadamore at openjdk.org Thu Jan 15 09:55:59 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 15 Jan 2026 09:55:59 GMT Subject: RFR: add use site null checks In-Reply-To: <8Cny4Isa98j1tZhxgSgNhzTPgLhNsJouCYqJJiA4zB4=.cc4a28fe-ba03-4441-a60c-28fcf527989d@github.com> References: <8Cny4Isa98j1tZhxgSgNhzTPgLhNsJouCYqJJiA4zB4=.cc4a28fe-ba03-4441-a60c-28fcf527989d@github.com> Message-ID: On Thu, 15 Jan 2026 09:50:23 GMT, Maurizio Cimadamore wrote: >> Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 204: > >> 202: } >> 203: Type formalArgType = declaredArgTypes.head; >> 204: if (msym.isVarArgs() && formalArgType == varArgsArg) { > > I think this check can misfire. Some types are shared -- e.g. syms.stringType, so you might get `==` in "wrong" places. That said, here `varArgsArg` is an array type, and for that we might always get a fresh instance... so it might work. > > It also looks like there might be a potential problem here -- this code runs _after_ varargs translation has occurred. Meaning that for varargs, we only see a javac-created array and we can check the variadic elements. > > But again, the plan here would be to disallow `C!...` so this is ok. Question, now that I read through all the code... I wonder if we could do this more simply: * take the list of actual arguments * skip the first P prefix arguments * drop the last variadic array (if the method is variadic) * then do a loop and check what remains against the "source-like" formal types ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1910#discussion_r2693704826 From mcimadamore at openjdk.org Thu Jan 15 10:01:58 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 15 Jan 2026 10:01:58 GMT Subject: RFR: add use site null checks In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 05:46:52 GMT, Vicente Romero wrote: > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them test/langtools/tools/javac/nullability/RuntimeNullChecks.java line 222: > 220: """ > 221: class Test { > 222: class Inner { All these tests are trying inner classes. That said, I don't think these invocation will actually have an "interesting" external type. In fact, I believe to test `externalType` you need to have constructor calls, as that's the primary case where we add prefix parameters. Also, there's no test for varargs calls. I suggest to add: * method call * constructor call/plain * constructor call/inner And, for all these, we should have a varargs and non-varargs flavors. Maybe this needs its own test? (as I write this I realize that, while for methods you can use override to test use site checks, for constructor calls you can't -- you need a separate compilation test there, I think) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1910#discussion_r2693725642 From sjohanss at openjdk.org Thu Jan 15 11:05:42 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 15 Jan 2026 11:05:42 GMT Subject: [lworld] RFR: 8375374: [lworld] Remove some traces of Message-ID: <4Ton9HHm6gq48yW7uqqtStNsj7XHvbWbpBqqQIHlZ4E=.221aa49d-76cd-4936-b2da-348dfccc35f4@github.com> Please review this small change to remove a few traces still left of no longer used ``. After this change, the only reference left to `` is in `verifierTests.jcod` used by the test `VerifierInlineTypes`. I'm uncertain how to handle that so I will leave that to someone else, but filed [JDK-8375373](https://bugs.openjdk.org/browse/JDK-8375373) to keep track of it. ------------- Commit messages: - 8375374: [lworld] Remove some traces of Changes: https://git.openjdk.org/valhalla/pull/1912/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1912&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375374 Stats: 13 lines in 5 files changed: 0 ins; 8 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1912.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1912/head:pull/1912 PR: https://git.openjdk.org/valhalla/pull/1912 From qamai at openjdk.org Thu Jan 15 11:15:22 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 15 Jan 2026 11:15:22 GMT Subject: [lworld] RFR: 8375366: [lworld] AcmpTest.java fails with OutOfMemoryError in stress-valhalla-StressG1 In-Reply-To: <8KPao_ELqBH94fcAzN9460OSXch_FppP_8eYOx3K9Os=.3d1ba3b8-0016-4826-a1b8-b2509592990d@github.com> References: <8KPao_ELqBH94fcAzN9460OSXch_FppP_8eYOx3K9Os=.3d1ba3b8-0016-4826-a1b8-b2509592990d@github.com> Message-ID: <-QmEwiyYd2UzLDmVOZTfBCzXU1gnBvoV8HZhwI8eU7A=.53ead743-5380-4ebf-876a-22d14ef9b1f0@github.com> On Thu, 15 Jan 2026 07:46:20 GMT, Tobias Hartmann wrote: > We run the test with limited heap size in internal testing and it fails with an OutOfMemoryError because it pre-generates a large number of test cases and stores them in an ArrayList. Let's just execute the test cases directly instead. > > Thanks, > Tobias LGTM, not sure why it was written like that ------------- Marked as reviewed by qamai (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1911#pullrequestreview-3665115390 From thartmann at openjdk.org Thu Jan 15 11:20:43 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 15 Jan 2026 11:20:43 GMT Subject: [lworld] RFR: 8375366: [lworld] AcmpTest.java fails with OutOfMemoryError in stress-valhalla-StressG1 In-Reply-To: <8KPao_ELqBH94fcAzN9460OSXch_FppP_8eYOx3K9Os=.3d1ba3b8-0016-4826-a1b8-b2509592990d@github.com> References: <8KPao_ELqBH94fcAzN9460OSXch_FppP_8eYOx3K9Os=.3d1ba3b8-0016-4826-a1b8-b2509592990d@github.com> Message-ID: On Thu, 15 Jan 2026 07:46:20 GMT, Tobias Hartmann wrote: > We run the test with limited heap size in internal testing and it fails with an OutOfMemoryError because it pre-generates a large number of test cases and stores them in an ArrayList. Let's just execute the test cases directly instead. > > Thanks, > Tobias Thanks Quan Anh! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1911#issuecomment-3754237811 From mcimadamore at openjdk.org Thu Jan 15 11:21:47 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 15 Jan 2026 11:21:47 GMT Subject: RFR: Disable null-restricted varargs Message-ID: It should not be possible to use a null-restricted varargs element type, the parser should reject that combination. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/valhalla/pull/1913/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1913&range=00 Stats: 13 lines in 4 files changed: 11 ins; 1 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1913.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1913/head:pull/1913 PR: https://git.openjdk.org/valhalla/pull/1913 From mcimadamore at openjdk.org Thu Jan 15 11:40:06 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 15 Jan 2026 11:40:06 GMT Subject: RFR: Disable null-restricted varargs [v2] In-Reply-To: References: Message-ID: > It should not be possible to use a null-restricted varargs element type, the parser should reject that combination. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add tests for varargs record component ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1913/files - new: https://git.openjdk.org/valhalla/pull/1913/files/657f3d58..25918b7b Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1913&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1913&range=00-01 Stats: 7 lines in 3 files changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1913.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1913/head:pull/1913 PR: https://git.openjdk.org/valhalla/pull/1913 From mchevalier at openjdk.org Thu Jan 15 12:01:33 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 15 Jan 2026 12:01:33 GMT Subject: [lworld] RFR: 8375366: [lworld] AcmpTest.java fails with OutOfMemoryError in stress-valhalla-StressG1 In-Reply-To: <8KPao_ELqBH94fcAzN9460OSXch_FppP_8eYOx3K9Os=.3d1ba3b8-0016-4826-a1b8-b2509592990d@github.com> References: <8KPao_ELqBH94fcAzN9460OSXch_FppP_8eYOx3K9Os=.3d1ba3b8-0016-4826-a1b8-b2509592990d@github.com> Message-ID: On Thu, 15 Jan 2026 07:46:20 GMT, Tobias Hartmann wrote: > We run the test with limited heap size in internal testing and it fails with an OutOfMemoryError because it pre-generates a large number of test cases and stores them in an ArrayList. Let's just execute the test cases directly instead. > > Thanks, > Tobias Marked as reviewed by mchevalier (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1911#pullrequestreview-3665267234 From jsikstro at openjdk.org Thu Jan 15 12:05:54 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 15 Jan 2026 12:05:54 GMT Subject: [lworld] RFR: 8375434: [lworld] Cleanup null-marker check for InlineKlass::read_payload_from_addr Message-ID: Hello, Right now we check the null-marker for the NULLABLE_ATOMIC_FLAT LayoutKind twice, both before and after allocating a heap instance. The first check returns nullptr early if the null-marker is set, as we don't have to allocate an object on the heap if we are going to return nullptr anyways. The other check is redundant, since if the null-marker is not set, the source object is non-null, which means the destination (res) object is non-null as well after copying, so the code inside it is unreachable. Testing: * Oracle's tier1-4, hotspot_valhalla, jdk_valhalla * I also added a `gurantee` for the removed code and ran through hotspot_valhalla and jdk_valhalla locally. ------------- Commit messages: - 8375434: [lworld] Cleanup null-marker check for InlineKlass::read_payload_from_addr Changes: https://git.openjdk.org/valhalla/pull/1914/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1914&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375434 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1914.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1914/head:pull/1914 PR: https://git.openjdk.org/valhalla/pull/1914 From thartmann at openjdk.org Thu Jan 15 12:16:42 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 15 Jan 2026 12:16:42 GMT Subject: [lworld] RFR: 8375366: [lworld] AcmpTest.java fails with OutOfMemoryError in stress-valhalla-StressG1 In-Reply-To: <8KPao_ELqBH94fcAzN9460OSXch_FppP_8eYOx3K9Os=.3d1ba3b8-0016-4826-a1b8-b2509592990d@github.com> References: <8KPao_ELqBH94fcAzN9460OSXch_FppP_8eYOx3K9Os=.3d1ba3b8-0016-4826-a1b8-b2509592990d@github.com> Message-ID: On Thu, 15 Jan 2026 07:46:20 GMT, Tobias Hartmann wrote: > We run the test with limited heap size in internal testing and it fails with an OutOfMemoryError because it pre-generates a large number of test cases and stores them in an ArrayList. Let's just execute the test cases directly instead. > > Thanks, > Tobias Thanks for the review Marc! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1911#issuecomment-3754433138 From thartmann at openjdk.org Thu Jan 15 12:16:43 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 15 Jan 2026 12:16:43 GMT Subject: [lworld] Integrated: 8375366: [lworld] AcmpTest.java fails with OutOfMemoryError in stress-valhalla-StressG1 In-Reply-To: <8KPao_ELqBH94fcAzN9460OSXch_FppP_8eYOx3K9Os=.3d1ba3b8-0016-4826-a1b8-b2509592990d@github.com> References: <8KPao_ELqBH94fcAzN9460OSXch_FppP_8eYOx3K9Os=.3d1ba3b8-0016-4826-a1b8-b2509592990d@github.com> Message-ID: On Thu, 15 Jan 2026 07:46:20 GMT, Tobias Hartmann wrote: > We run the test with limited heap size in internal testing and it fails with an OutOfMemoryError because it pre-generates a large number of test cases and stores them in an ArrayList. Let's just execute the test cases directly instead. > > Thanks, > Tobias This pull request has now been integrated. Changeset: f838c795 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/f838c795c691929e1af1c0344cc83f0c2bd82375 Stats: 19 lines in 1 file changed: 0 ins; 9 del; 10 mod 8375366: [lworld] AcmpTest.java fails with OutOfMemoryError in stress-valhalla-StressG1 Reviewed-by: qamai, mchevalier ------------- PR: https://git.openjdk.org/valhalla/pull/1911 From fparain at openjdk.org Thu Jan 15 12:50:55 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 15 Jan 2026 12:50:55 GMT Subject: [lworld] RFR: 8375374: [lworld] Remove some traces of In-Reply-To: <4Ton9HHm6gq48yW7uqqtStNsj7XHvbWbpBqqQIHlZ4E=.221aa49d-76cd-4936-b2da-348dfccc35f4@github.com> References: <4Ton9HHm6gq48yW7uqqtStNsj7XHvbWbpBqqQIHlZ4E=.221aa49d-76cd-4936-b2da-348dfccc35f4@github.com> Message-ID: <77uGymf2iw1b-49gyQL_8ZNJHWHh7p8ba3hm_Vy2nCw=.ec2f969c-05c3-4f07-b27f-aa5790324e01@github.com> On Thu, 15 Jan 2026 10:56:41 GMT, Stefan Johansson wrote: > Please review this small change to remove a few traces still left of no longer used ``. > > After this change, the only reference left to `` is in `verifierTests.jcod` used by the test `VerifierInlineTypes`. I'm uncertain how to handle that so I will leave that to someone else, but filed [JDK-8375373](https://bugs.openjdk.org/browse/JDK-8375373) to keep track of it. Looks good to me. ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1912#pullrequestreview-3665444011 From sjohanss at openjdk.org Thu Jan 15 13:26:23 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 15 Jan 2026 13:26:23 GMT Subject: [lworld] RFR: 8375374: [lworld] Remove some traces of [v2] In-Reply-To: <4Ton9HHm6gq48yW7uqqtStNsj7XHvbWbpBqqQIHlZ4E=.221aa49d-76cd-4936-b2da-348dfccc35f4@github.com> References: <4Ton9HHm6gq48yW7uqqtStNsj7XHvbWbpBqqQIHlZ4E=.221aa49d-76cd-4936-b2da-348dfccc35f4@github.com> Message-ID: > Please review this small change to remove a few traces still left of no longer used ``. > > After this change, the only reference left to `` is in `verifierTests.jcod` used by the test `VerifierInlineTypes`. I'm uncertain how to handle that so I will leave that to someone else, but filed [JDK-8375373](https://bugs.openjdk.org/browse/JDK-8375373) to keep track of it. Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: Remove verifier test files no longer needed ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1912/files - new: https://git.openjdk.org/valhalla/pull/1912/files/0b6fa2d7..45c99880 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1912&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1912&range=00-01 Stats: 1713 lines in 2 files changed: 0 ins; 1713 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1912.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1912/head:pull/1912 PR: https://git.openjdk.org/valhalla/pull/1912 From fparain at openjdk.org Thu Jan 15 13:26:23 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 15 Jan 2026 13:26:23 GMT Subject: [lworld] RFR: 8375374: [lworld] Remove some traces of [v2] In-Reply-To: References: <4Ton9HHm6gq48yW7uqqtStNsj7XHvbWbpBqqQIHlZ4E=.221aa49d-76cd-4936-b2da-348dfccc35f4@github.com> Message-ID: On Thu, 15 Jan 2026 13:21:45 GMT, Stefan Johansson wrote: >> Please review this small change to remove a few traces still left of no longer used ``. >> >> After this change, the only reference left to `` is in `verifierTests.jcod` used by the test `VerifierInlineTypes`. I'm uncertain how to handle that so I will leave that to someone else, but filed [JDK-8375373](https://bugs.openjdk.org/browse/JDK-8375373) to keep track of it. > > Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: > > Remove verifier test files no longer needed Still looks good. ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1912#pullrequestreview-3665601982 From qamai at openjdk.org Thu Jan 15 13:34:46 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 15 Jan 2026 13:34:46 GMT Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 22:02:07 GMT, Chen Liang wrote: > Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case. src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1786: > 1784: V x) { > 1785: Object[] array = newSpecialArray(valueType, 2, layout); > 1786: return compareAndSetFlatValueAsBytes(array, o, offset, layout, valueType, expected, x) ? x : array[0]; This method should return `array[0]` in all cases. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1734#discussion_r2694405998 From vromero at openjdk.org Thu Jan 15 13:38:04 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 15 Jan 2026 13:38:04 GMT Subject: RFR: Disable null-restricted varargs [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 11:40:06 GMT, Maurizio Cimadamore wrote: >> It should not be possible to use a null-restricted varargs element type, the parser should reject that combination. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add tests for varargs record component looks good ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1913#pullrequestreview-3665673299 From fparain at openjdk.org Thu Jan 15 13:56:46 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 15 Jan 2026 13:56:46 GMT Subject: [lworld] RFR: 8375434: [lworld] Cleanup null-marker check for InlineKlass::read_payload_from_addr In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 11:58:34 GMT, Joel Sikstr?m wrote: > Hello, > > Right now we check the null-marker for the NULLABLE_ATOMIC_FLAT LayoutKind twice, both before and after allocating a heap instance. The first check returns nullptr early if the null-marker is set, as we don't have to allocate an object on the heap if we are going to return nullptr anyways. The other check is redundant, since if the null-marker is not set, the source object is non-null, which means the destination (res) object is non-null as well after copying, so the code inside it is unreachable. > > Testing: > * Oracle's tier1-4, hotspot_valhalla, jdk_valhalla > * I also added a `gurantee` for the removed code and ran through hotspot_valhalla and jdk_valhalla locally. The second check is needed because the source value might have been mutated between the first null-marker check and the value copying, and we don't want to have heap allocated instances being equivalent to a 'null' value. Here's the scenario: - thread 1 starts to read a nullable flat value, it checks that the value is not marked as null, then proceeds to copy the value but is preempted - thread 2 updates the nullable flat value by writing 'null' to it, which means setting the null-marker to zero, but also resetting all the other fields - thread 1 resumes its read, allocate the heap instance, and copy the payload Now, the problem is that there's a heap allocated instance with a payload that has been reset, which means fields contents might not be valid for this class. We don't want to have to check the null-marker each time we access a heap buffered value, we want to preserve the invariant that all heap buffered values are valid values for the class. So, the null marker is checked a second time in the heap allocated instance, and if it is zeroed, meaning the payload written to the instance is equivalent to null, then the instance is discarded. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1914#issuecomment-3754996915 From thartmann at openjdk.org Thu Jan 15 14:07:51 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 15 Jan 2026 14:07:51 GMT Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects In-Reply-To: References: Message-ID: <6S1W_2ZwdggJtewwgX8yv2KnTXVnNasqkShkaeCbv0g=.0495de95-edbd-4276-8bdd-70db5e306f46@github.com> On Wed, 12 Nov 2025 22:02:07 GMT, Chen Liang wrote: > Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case. @liach Please un-problem list `VarHandleTestMethodHandleAccessValue.java` now that [JDK-8367346](https://bugs.openjdk.org/browse/JDK-8367346) was closed as duplicate. Thanks. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1734#issuecomment-3755057474 From mcimadamore at openjdk.org Thu Jan 15 14:22:59 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 15 Jan 2026 14:22:59 GMT Subject: Integrated: Disable null-restricted varargs In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 11:14:49 GMT, Maurizio Cimadamore wrote: > It should not be possible to use a null-restricted varargs element type, the parser should reject that combination. This pull request has now been integrated. Changeset: 7dff1a63 Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/7dff1a630857f8236b7f9f4f33dd987b219457c6 Stats: 19 lines in 4 files changed: 17 ins; 1 del; 1 mod Disable null-restricted varargs Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1913 From jsikstro at openjdk.org Thu Jan 15 15:00:24 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 15 Jan 2026 15:00:24 GMT Subject: [lworld] RFR: 8375434: [lworld] Cleanup null-marker check for InlineKlass::read_payload_from_addr In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 13:53:59 GMT, Frederic Parain wrote: >> Hello, >> >> Right now we check the null-marker for the NULLABLE_ATOMIC_FLAT LayoutKind twice, both before and after allocating a heap instance. The first check returns nullptr early if the null-marker is set, as we don't have to allocate an object on the heap if we are going to return nullptr anyways. The other check is redundant, since if the null-marker is not set, the source object is non-null, which means the destination (res) object is non-null as well after copying, so the code inside it is unreachable. >> >> Testing: >> * Oracle's tier1-4, hotspot_valhalla, jdk_valhalla >> * I also added a `gurantee` for the removed code and ran through hotspot_valhalla and jdk_valhalla locally. > > The second check is needed because the source value might have been mutated between the first null-marker check and the value copying, and we don't want to have heap allocated instances being equivalent to a 'null' value. > Here's the scenario: > - thread 1 starts to read a nullable flat value, it checks that the value is not marked as null, then proceeds to copy the value but is preempted > - thread 2 updates the nullable flat value by writing 'null' to it, which means setting the null-marker to zero, but also resetting all the other fields > - thread 1 resumes its read, allocate the heap instance, and copy the payload > > Now, the problem is that there's a heap allocated instance with a payload that has been reset, which means fields contents might not be valid for this class. We don't want to have to check the null-marker each time we access a heap buffered value, we want to preserve the invariant that all heap buffered values are valid values for the class. So, the null marker is checked a second time in the heap allocated instance, and if it is zeroed, meaning the payload written to the instance is equivalent to null, then the instance is discarded. @fparain I see, thank you for the example and explanation! As this was not immediately clear to me (and others), maybe I can move the direction of this PR to add a brief comment explaining why the additional null-marker check in the end is needed here? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1914#issuecomment-3755264785 From fparain at openjdk.org Thu Jan 15 15:05:47 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 15 Jan 2026 15:05:47 GMT Subject: [lworld] RFR: 8375434: [lworld] Cleanup null-marker check for InlineKlass::read_payload_from_addr In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 11:58:34 GMT, Joel Sikstr?m wrote: > Hello, > > Right now we check the null-marker for the NULLABLE_ATOMIC_FLAT LayoutKind twice, both before and after allocating a heap instance. The first check returns nullptr early if the null-marker is set, as we don't have to allocate an object on the heap if we are going to return nullptr anyways. The other check is redundant, since if the null-marker is not set, the source object is non-null, which means the destination (res) object is non-null as well after copying, so the code inside it is unreachable. > > Testing: > * Oracle's tier1-4, hotspot_valhalla, jdk_valhalla > * I also added a `gurantee` for the removed code and ran through hotspot_valhalla and jdk_valhalla locally. Adding a comment to explain the rational of the second null-marker check is a good idea. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1914#issuecomment-3755298238 From jsikstro at openjdk.org Thu Jan 15 16:10:58 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 15 Jan 2026 16:10:58 GMT Subject: [lworld] RFR: 8375434: [lworld] Add comment for null-check in InlineKlass::read_payload_from_addr [v2] In-Reply-To: References: Message-ID: > Hello, > > Right now we check the null-marker for the NULLABLE_ATOMIC_FLAT LayoutKind twice, both before and after allocating a heap instance. The first check returns nullptr early if the null-marker is set, as we don't have to allocate an object on the heap if we are going to return nullptr anyways. The other check is redundant, since if the null-marker is not set, the source object is non-null, which means the destination (res) object is non-null as well after copying, so the code inside it is unreachable. > > Testing: > * Oracle's tier1-4, hotspot_valhalla, jdk_valhalla > * I also added a `gurantee` for the removed code and ran through hotspot_valhalla and jdk_valhalla locally. Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Add comment ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1914/files - new: https://git.openjdk.org/valhalla/pull/1914/files/705b1416..c4776d84 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1914&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1914&range=00-01 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1914.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1914/head:pull/1914 PR: https://git.openjdk.org/valhalla/pull/1914 From david.simms at oracle.com Thu Jan 15 16:17:27 2026 From: david.simms at oracle.com (David Simms) Date: Thu, 15 Jan 2026 17:17:27 +0100 Subject: CFV: New Valhalla Committer: Serguei Spitsyn Message-ID: |Voting for *Serguei Spitsyn* [1] is now closed. Yes: *7* Veto: 0 Abstain: *0 * According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. *David Simms* [1] https://mail.openjdk.org/pipermail/valhalla-dev/2025-December/016571.html| -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.simms at oracle.com Thu Jan 15 16:23:52 2026 From: david.simms at oracle.com (David Simms) Date: Thu, 15 Jan 2026 17:23:52 +0100 Subject: CFV: New Valhalla Committer: Chris Plummer Message-ID: |I hereby nominate *Chris Plummer* to *Valhalla* Committer. Chris is a long time member of the OpenJDK project, with over 400 commits in the mainline[1]. Votes are due by 29th of December, 18:00z. Only current *Valhalla* Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. *David Simms* [1] https://github.com/search?q=committer-name%3A%22Chris+Plummer%22+repo%3Aopenjdk%2Fjdk+&type=commits [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote| -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.simms at oracle.com Thu Jan 15 16:24:32 2026 From: david.simms at oracle.com (David Simms) Date: Thu, 15 Jan 2026 17:24:32 +0100 Subject: Result: CFV: New Valhalla Committer: Serguei Spitsyn In-Reply-To: References: Message-ID: <18d9f357-fb4b-4ce1-b4de-ea83958577f7@oracle.com> On 2026-01-15 17:17, David Simms wrote: > |Voting for *Serguei Spitsyn* [1] is now closed. Yes: *7* Veto: 0 > Abstain: *0 * According to the Bylaws definition of Lazy Consensus, > this is sufficient to approve the nomination. *David Simms* [1] > https://mail.openjdk.org/pipermail/valhalla-dev/2025-December/016571.html| > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.simms at oracle.com Thu Jan 15 16:24:55 2026 From: david.simms at oracle.com (David Simms) Date: Thu, 15 Jan 2026 17:24:55 +0100 Subject: CFV: New Valhalla Committer: Chris Plummer In-Reply-To: References: Message-ID: Vote: yes On 2026-01-15 17:23, David Simms wrote: > |I hereby nominate *Chris Plummer* to *Valhalla* Committer. Chris is a > long time member of the OpenJDK project, with over 400 commits in the > mainline[1]. Votes are due by 29th of December, 18:00z. Only current > *Valhalla* Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [3]. *David Simms* [1] > https://github.com/search?q=committer-name%3A%22Chris+Plummer%22+repo%3Aopenjdk%2Fjdk+&type=commits > [2] https://openjdk.org/census [3] > https://openjdk.org/projects/#committer-vote| > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fparain at openjdk.org Thu Jan 15 16:39:33 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 15 Jan 2026 16:39:33 GMT Subject: [lworld] RFR: 8375434: [lworld] Add comment for null-check in InlineKlass::read_payload_from_addr [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 16:10:58 GMT, Joel Sikstr?m wrote: >> Hello, >> >> Update: There is nothing wrong with the logic. I added a comment to clarify why the second null-marker check is needed. Thanks. >> >> ~~Right now we check the null-marker for the NULLABLE_ATOMIC_FLAT LayoutKind twice, both before and after allocating a heap instance. The first check returns nullptr early if the null-marker is set, as we don't have to allocate an object on the heap if we are going to return nullptr anyways. The other check is redundant, since if the null-marker is not set, the source object is non-null, which means the destination (res) object is non-null as well after copying, so the code inside it is unreachable.~~ >> >> Testing: >> * Oracle's tier1-4, hotspot_valhalla, jdk_valhalla >> * I also added a `gurantee` for the removed code and ran through hotspot_valhalla and jdk_valhalla locally. > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Add comment Looks good to me. ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1914#pullrequestreview-3666556072 From rriggs at openjdk.org Thu Jan 15 17:38:08 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 17:38:08 GMT Subject: [lworld] RFR: 8375320: [lworld] Revert System.identityHashcode for value objects to non AltSubstitutability version In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 21:57:37 GMT, Roger Riggs wrote: > Restore the unconditional use of value_object_hash_code_method. > The Alt hashcode method based on the Unsafe.getFieldMap is not used. > System.identityHashCode uses ValueObjectMethods.valueObjectHashCode() implemented using the original method-handle implementation. A quick review would get this broken change reverted. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1907#issuecomment-3756067323 From rriggs at openjdk.org Thu Jan 15 17:42:39 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 17:42:39 GMT Subject: [lworld] RFR: 8375320: [lworld] Revert System.identityHashcode for value objects to non AltSubstitutability version In-Reply-To: References: Message-ID: <2U4un-Lr0xvjPnZkxtBMkOM28KbqUdLTyTVG5k3Cidk=.f342daf2-f555-47f0-9601-781b86120efc@github.com> On Wed, 14 Jan 2026 21:57:37 GMT, Roger Riggs wrote: > Restore the unconditional use of value_object_hash_code_method. > The Alt hashcode method based on the Unsafe.getFieldMap is not used. > System.identityHashCode uses ValueObjectMethods.valueObjectHashCode() implemented using the original method-handle implementation. Can be integrated by anyone after approval. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1907#issuecomment-3756084146 From darcy at openjdk.org Thu Jan 15 17:59:27 2026 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 15 Jan 2026 17:59:27 GMT Subject: RFR: 8338533: Prototype unsigned int as a library type Message-ID: In-progress snapshot of an unsigned int class; tests to follow. ------------- Commit messages: - Appease jcheck. - Checkpoint. - Checkpoint. - Merge branch 'type-classes' into JDK-8338533 - JDK-8338533: Prototype unsigned int as a library type Changes: https://git.openjdk.org/valhalla/pull/1915/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1915&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338533 Stats: 498 lines in 1 file changed: 498 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1915.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1915/head:pull/1915 PR: https://git.openjdk.org/valhalla/pull/1915 From vromero at openjdk.org Thu Jan 15 18:30:36 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 15 Jan 2026 18:30:36 GMT Subject: RFR: add use site null checks [v2] In-Reply-To: References: Message-ID: > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1910/files - new: https://git.openjdk.org/valhalla/pull/1910/files/edbec5f5..598a2158 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=00-01 Stats: 29 lines in 1 file changed: 13 ins; 4 del; 12 mod Patch: https://git.openjdk.org/valhalla/pull/1910.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1910/head:pull/1910 PR: https://git.openjdk.org/valhalla/pull/1910 From dcubed at openjdk.org Thu Jan 15 19:18:39 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 15 Jan 2026 19:18:39 GMT Subject: [lworld] RFR: 8375353: [lworld] compiler/valhalla/inlinetypes/TestOnStackReplacement.java#id3 times out Message-ID: Trivial fix to ProblemList a test: [JDK-8375474](https://bugs.openjdk.org/browse/JDK-8375474) [lworld] ProblemList sun/tools/jhsdb/JStackStressTest.java on macosx-aarch64 This is a trivial test fix to a default timeout value: [JDK-8375353](https://bugs.openjdk.org/browse/JDK-8375353) [lworld] compiler/valhalla/inlinetypes/TestOnStackReplacement.java#id3 times out ------------- Commit messages: - 8375474: [lworld] ProblemList sun/tools/jhsdb/JStackStressTest.java on macosx-aarch64 - 8375353: [lworld] compiler/valhalla/inlinetypes/TestOnStackReplacement.java#id3 times out Changes: https://git.openjdk.org/valhalla/pull/1908/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1908&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375353 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1908.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1908/head:pull/1908 PR: https://git.openjdk.org/valhalla/pull/1908 From fparain at openjdk.org Thu Jan 15 19:18:40 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 15 Jan 2026 19:18:40 GMT Subject: [lworld] RFR: 8375353: [lworld] compiler/valhalla/inlinetypes/TestOnStackReplacement.java#id3 times out In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 23:27:50 GMT, Daniel D. Daugherty wrote: > Trivial fix to ProblemList a test: > > [JDK-8375474](https://bugs.openjdk.org/browse/JDK-8375474) [lworld] ProblemList sun/tools/jhsdb/JStackStressTest.java on macosx-aarch64 > > This is a trivial test fix to a default timeout value: > > [JDK-8375353](https://bugs.openjdk.org/browse/JDK-8375353) [lworld] compiler/valhalla/inlinetypes/TestOnStackReplacement.java#id3 times out Marked as reviewed by fparain (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1908#pullrequestreview-3667172543 From dcubed at openjdk.org Thu Jan 15 19:25:40 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 15 Jan 2026 19:25:40 GMT Subject: [lworld] RFR: 8375353: [lworld] compiler/valhalla/inlinetypes/TestOnStackReplacement.java#id3 times out In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 19:13:30 GMT, Frederic Parain wrote: >> Trivial fix to ProblemList a test: >> >> [JDK-8375474](https://bugs.openjdk.org/browse/JDK-8375474) [lworld] ProblemList sun/tools/jhsdb/JStackStressTest.java on macosx-aarch64 >> >> This is a trivial test fix to a default timeout value: >> >> [JDK-8375353](https://bugs.openjdk.org/browse/JDK-8375353) [lworld] compiler/valhalla/inlinetypes/TestOnStackReplacement.java#id3 times out > > Marked as reviewed by fparain (Committer). @fparain - Thanks for the fast review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1908#issuecomment-3756490911 From dcubed at openjdk.org Thu Jan 15 19:25:41 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 15 Jan 2026 19:25:41 GMT Subject: [lworld] Integrated: 8375353: [lworld] compiler/valhalla/inlinetypes/TestOnStackReplacement.java#id3 times out In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 23:27:50 GMT, Daniel D. Daugherty wrote: > Trivial fix to ProblemList a test: > > [JDK-8375474](https://bugs.openjdk.org/browse/JDK-8375474) [lworld] ProblemList sun/tools/jhsdb/JStackStressTest.java on macosx-aarch64 > > This is a trivial test fix to a default timeout value: > > [JDK-8375353](https://bugs.openjdk.org/browse/JDK-8375353) [lworld] compiler/valhalla/inlinetypes/TestOnStackReplacement.java#id3 times out This pull request has now been integrated. Changeset: 2adef08e Author: Daniel D. Daugherty URL: https://git.openjdk.org/valhalla/commit/2adef08edad4328bb5d631e3b00078a1509a0df7 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod 8375353: [lworld] compiler/valhalla/inlinetypes/TestOnStackReplacement.java#id3 times out Reviewed-by: fparain ------------- PR: https://git.openjdk.org/valhalla/pull/1908 From amenkov at openjdk.org Thu Jan 15 20:28:25 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 Jan 2026 20:28:25 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: <5kHPQPGP150SmC3IeFFycWm5FYTBed5OtzbeGkzSI0E=.4cfae6e4-5b23-48da-a0ae-580859635146@github.com> Message-ID: On Thu, 15 Jan 2026 02:21:20 GMT, Chris Plummer wrote: >> value class can be abstract. > > So if you have a value class, the IDENTITY bit will not be set, but if the ABSTRCT bit is also set, the above logic produces false, even though it is value class and you want it to produce true. Inline type is a _concrete_ value class (i.e. InstanceKlass). so for abstract classes `false` is expected. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2695841290 From cjplummer at openjdk.org Thu Jan 15 20:32:05 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Jan 2026 20:32:05 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects In-Reply-To: References: <5kHPQPGP150SmC3IeFFycWm5FYTBed5OtzbeGkzSI0E=.4cfae6e4-5b23-48da-a0ae-580859635146@github.com> Message-ID: On Thu, 15 Jan 2026 20:25:14 GMT, Alex Menkov wrote: >> So if you have a value class, the IDENTITY bit will not be set, but if the ABSTRCT bit is also set, the above logic produces false, even though it is value class and you want it to produce true. > > Inline type is a _concrete_ value class (i.e. InstanceKlass). so for abstract classes `false` is expected. The terminology is confusing. Are you saying that "inline type" != "value class"? If so, then please explain the difference between the two. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2695853914 From lois.foltan at oracle.com Thu Jan 15 20:57:15 2026 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 15 Jan 2026 20:57:15 +0000 Subject: CFV: New Valhalla Committer: Chris Plummer In-Reply-To: References: Message-ID: Vote: yes Lois From: valhalla-dev on behalf of David Simms Date: Thursday, January 15, 2026 at 11:24?AM To: valhalla-dev at openjdk.java.net Subject: CFV: New Valhalla Committer: Chris Plummer I hereby nominate Chris Plummer to Valhalla Committer. Chris is a long time member of the OpenJDK project, with over 400 commits in the mainline[1]. Votes are due by 29th of December, 18:00z. Only current Valhalla Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. David Simms [1] https://github.com/search?q=committer-name%3A%22Chris+Plummer%22+repo%3Aopenjdk%2Fjdk+&type=commits [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.org Thu Jan 15 21:26:13 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 15 Jan 2026 21:26:13 GMT Subject: RFR: Fixing null restricted types for fields/methods in compact source files. Message-ID: The null restricted types don't seem to be supported for top-level fields/methods in compact source files: $ cat /tmp/Compact.java String! s = ""; void main() { } $ ./build/linux-x86_64-server-release/jdk/bin/javac --enable-preview --source 27 /tmp/Compact.java /tmp/Compact.java:1: error: null restriction not supported in this type context String! s = ""; ^ 1 error This is a simple patch to fix that (removing the `unannotatedType(boolean)` method, as that is no longer used, to my knowledge. But it can be preserved, if preferred. ------------- Commit messages: - Fixing null restricted types for fields/methods in compact source files. Changes: https://git.openjdk.org/valhalla/pull/1916/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1916&range=00 Stats: 23 lines in 2 files changed: 18 ins; 4 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1916.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1916/head:pull/1916 PR: https://git.openjdk.org/valhalla/pull/1916 From frederic.parain at oracle.com Thu Jan 15 22:03:41 2026 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 15 Jan 2026 17:03:41 -0500 Subject: CFV: New Valhalla Committer: Chris Plummer In-Reply-To: References: Message-ID: Vote: yes Fred On 1/15/26 11:23, David Simms wrote: > |I hereby nominate *Chris Plummer* to *Valhalla* Committer. Chris is a > long time member of the OpenJDK project, with over 400 commits in the > mainline[1]. Votes are due by 29th of December, 18:00z. Only current > *Valhalla* Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [3]. *David Simms* [1] > https://github.com/search?q=committer-name%3A%22Chris+Plummer%22+repo%3Aopenjdk%2Fjdk+&type=commits > [2] https://openjdk.org/census [3] > https://openjdk.org/projects/#committer-vote| > > From darcy at openjdk.org Thu Jan 15 22:27:07 2026 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 15 Jan 2026 22:27:07 GMT Subject: Integrated: 8338533: Prototype unsigned int as a library type In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 17:41:20 GMT, Joe Darcy wrote: > In-progress snapshot of an unsigned int class; tests to follow. This pull request has now been integrated. Changeset: 8b9e3b3f Author: Joe Darcy URL: https://git.openjdk.org/valhalla/commit/8b9e3b3fddacbc483e461b93d34f9c81c7b7d41f Stats: 498 lines in 1 file changed: 498 ins; 0 del; 0 mod 8338533: Prototype unsigned int as a library type ------------- PR: https://git.openjdk.org/valhalla/pull/1915 From amenkov at openjdk.org Fri Jan 16 00:01:54 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 16 Jan 2026 00:01:54 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v2] In-Reply-To: References: Message-ID: > Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. > Added the test for value object ctor debugging, the test verifies the behaviour is expected. > There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) > > testing: tier1..4, hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: ClassTypeImpl.isValueClass, VirtualMachineImpl.canUseIsSameObject ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1834/files - new: https://git.openjdk.org/valhalla/pull/1834/files/f82f5be4..e74a4cff Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1834&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1834&range=00-01 Stats: 37 lines in 4 files changed: 21 ins; 11 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1834.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1834/head:pull/1834 PR: https://git.openjdk.org/valhalla/pull/1834 From vromero at openjdk.org Fri Jan 16 00:05:18 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 00:05:18 GMT Subject: RFR: add use site null checks [v3] In-Reply-To: References: Message-ID: > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: adding tests ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1910/files - new: https://git.openjdk.org/valhalla/pull/1910/files/598a2158..a87ffd65 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=01-02 Stats: 287 lines in 1 file changed: 217 ins; 68 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1910.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1910/head:pull/1910 PR: https://git.openjdk.org/valhalla/pull/1910 From amenkov at openjdk.org Fri Jan 16 00:11:15 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 16 Jan 2026 00:11:15 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v2] In-Reply-To: References: <5kHPQPGP150SmC3IeFFycWm5FYTBed5OtzbeGkzSI0E=.4cfae6e4-5b23-48da-a0ae-580859635146@github.com> Message-ID: On Thu, 15 Jan 2026 20:29:46 GMT, Chris Plummer wrote: >> Inline type is a _concrete_ value class (i.e. InstanceKlass). so for abstract classes `false` is expected. > > The terminology is confusing. Are you saying that "inline type" != "value class"? If so, then please explain the difference between the two. inline type is always value class, but the opposite is not correct (abstract value class is not inlined type) The idea is any object's type is concrete class. It's not important here as we check type of the existing object (i.e. we cannot get abstract class) I updated the fix moving the functionality to ClassTypeImpl (still working on the test update) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2696406620 From vromero at openjdk.org Fri Jan 16 01:24:47 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 01:24:47 GMT Subject: RFR: add use site null checks [v4] In-Reply-To: References: Message-ID: > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1910/files - new: https://git.openjdk.org/valhalla/pull/1910/files/a87ffd65..c88297a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1910.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1910/head:pull/1910 PR: https://git.openjdk.org/valhalla/pull/1910 From vromero at openjdk.org Fri Jan 16 01:30:26 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 01:30:26 GMT Subject: RFR: add use site null checks [v5] In-Reply-To: References: Message-ID: > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: minor code changes ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1910/files - new: https://git.openjdk.org/valhalla/pull/1910/files/c88297a9..06453d99 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=04 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=03-04 Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1910.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1910/head:pull/1910 PR: https://git.openjdk.org/valhalla/pull/1910 From vromero at openjdk.org Fri Jan 16 01:32:54 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 01:32:54 GMT Subject: RFR: add use site null checks [v6] In-Reply-To: References: Message-ID: > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: code changes ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1910/files - new: https://git.openjdk.org/valhalla/pull/1910/files/06453d99..ece0ee79 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=05 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=04-05 Stats: 9 lines in 1 file changed: 2 ins; 3 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1910.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1910/head:pull/1910 PR: https://git.openjdk.org/valhalla/pull/1910 From vromero at openjdk.org Fri Jan 16 01:37:05 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 01:37:05 GMT Subject: RFR: add use site null checks [v7] In-Reply-To: References: Message-ID: > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: changes to tests ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1910/files - new: https://git.openjdk.org/valhalla/pull/1910/files/ece0ee79..8460cc06 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=06 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1910.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1910/head:pull/1910 PR: https://git.openjdk.org/valhalla/pull/1910 From qamai at openjdk.org Fri Jan 16 02:44:05 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 16 Jan 2026 02:44:05 GMT Subject: [lworld] RFR: 8375196: [lworld] TestArrays triggers assert in LRG::set_num_regs [v2] In-Reply-To: <8xYc-H-wIOzYgwvkOhZlINWfhvNuIKjJG02zFEulJXI=.8388740b-6cc9-4d08-9427-beedc226019c@github.com> References: <8xYc-H-wIOzYgwvkOhZlINWfhvNuIKjJG02zFEulJXI=.8388740b-6cc9-4d08-9427-beedc226019c@github.com> Message-ID: <4zjsDtjbWIZTNpupxJ6bmpqDKu_c9nNLZVdLPJh2PPY=.2ddce80c-e257-4fc7-9cb5-7efd989bc6c6@github.com> On Thu, 15 Jan 2026 07:06:34 GMT, Quan Anh Mai wrote: >> Hi, >> >> The issue is that `PhaseMacroExpand::value_from_mem_phi` does not take into consideration flat arrays, so it incorrectly returns the whole object for a load from one of its fields. This results in a byte `Phi` with an input being an `oop`, triggering the assert during `LRG::set_num_regs` because the size of a `Phi` and its input are different. >> >> Please take a look and leave your reviews, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > Add reminder at LibraryCallKit::inline_newArray Thanks very much for your review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1909#issuecomment-3757844929 From qamai at openjdk.org Fri Jan 16 02:45:37 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 16 Jan 2026 02:45:37 GMT Subject: [lworld] Integrated: 8375196: [lworld] TestArrays triggers assert in LRG::set_num_regs In-Reply-To: References: Message-ID: <_6sRYbiSdufJUEkPECYbjN90DCyyVfbRww1M92Ako6o=.2a41466c-b466-4eb8-adee-06c340672628@github.com> On Wed, 14 Jan 2026 23:38:13 GMT, Quan Anh Mai wrote: > Hi, > > The issue is that `PhaseMacroExpand::value_from_mem_phi` does not take into consideration flat arrays, so it incorrectly returns the whole object for a load from one of its fields. This results in a byte `Phi` with an input being an `oop`, triggering the assert during `LRG::set_num_regs` because the size of a `Phi` and its input are different. > > Please take a look and leave your reviews, thanks a lot. This pull request has now been integrated. Changeset: c2b08c8c Author: Quan Anh Mai URL: https://git.openjdk.org/valhalla/commit/c2b08c8ca133afe5dfef391519196760a1840807 Stats: 100 lines in 3 files changed: 61 ins; 29 del; 10 mod 8375196: [lworld] TestArrays triggers assert in LRG::set_num_regs Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1909 From cjplummer at openjdk.org Fri Jan 16 03:29:27 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 16 Jan 2026 03:29:27 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 00:01:54 GMT, Alex Menkov wrote: >> Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. >> Added the test for value object ctor debugging, the test verifies the behaviour is expected. >> There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) >> >> testing: tier1..4, hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > ClassTypeImpl.isValueClass, VirtualMachineImpl.canUseIsSameObject src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 177: > 175: @Override > 176: public int hashCode() { > 177: if (isValueObject() && vm.canUseIsSameObject()) { I don't see how this logic can be correct for value objects if vm.canUseIsSameObject() returns false. We still have a value object in that case. Is using Long.hashCode(ref()) the right thing to do? Same thing applies to equals() above. I think if a JVM supports value objects then the debug agent has to support IsSameObject and HashCode. The version check should really only be in regard to whether or not value objects are supported in general by the JVM, because if they are they have to be supported by the debug agent. src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java line 839: > 837: > 838: public boolean canUseIsSameObject() { > 839: return versionInfo().jdwpMajor >=27; Missing a space before 27. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2696713262 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2696713888 From darcy at openjdk.org Fri Jan 16 05:06:48 2026 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 16 Jan 2026 05:06:48 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces Message-ID: A refinement of some earlier ideas on the numerics modeling interfaces to inform further discussions. This is a "lumpy" rather than "splitty" design in terms of favoring a smaller number of interfaces with more functionality rather than a larger number of interfaces making smaller distinctions. Various design comments and to-do's noted in the code. ------------- Commit messages: - Appease jcheck some more. - Appease jcheck - 8338529: Initial iteration of numerics modeling interfaces Changes: https://git.openjdk.org/valhalla/pull/1917/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1917&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338529 Stats: 592 lines in 4 files changed: 592 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1917.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1917/head:pull/1917 PR: https://git.openjdk.org/valhalla/pull/1917 From vromero at openjdk.org Fri Jan 16 05:22:59 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 05:22:59 GMT Subject: RFR: add the NullRestricted annotation to null restricted fields of value classes Message-ID: null restricted fields of value classes should be annotated, temporarily, with the @NullRestricted annotation ------------- Commit messages: - add the NullRestricted annotation to null restricted fields of value classes Changes: https://git.openjdk.org/valhalla/pull/1918/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1918&range=00 Stats: 68 lines in 8 files changed: 22 ins; 15 del; 31 mod Patch: https://git.openjdk.org/valhalla/pull/1918.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1918/head:pull/1918 PR: https://git.openjdk.org/valhalla/pull/1918 From vromero at openjdk.org Fri Jan 16 05:23:00 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 05:23:00 GMT Subject: RFR: add the NullRestricted annotation to null restricted fields of value classes In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 05:16:11 GMT, Vicente Romero wrote: > null restricted fields of value classes should be annotated, temporarily, with the @NullRestricted annotation I have modified some valhalla tests to make sure that the fix works. But these tests modifications are shown as an example only, we could keep them or remove them before integration ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1918#issuecomment-3758215196 From liach at openjdk.org Fri Jan 16 05:56:33 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 16 Jan 2026 05:56:33 GMT Subject: RFR: add the NullRestricted annotation to null restricted fields of value classes In-Reply-To: References: Message-ID: <_1vj6Hyzg-TO85UvtIzoM_WJwZM6_9xNCuiUjhjwCbI=.ac4a89b8-60d1-4c8e-84f6-f0929e4c0c1d@github.com> On Fri, 16 Jan 2026 05:16:11 GMT, Vicente Romero wrote: > null restricted fields of value classes should be annotated, temporarily, with the @NullRestricted annotation Can't we update classFileParser to accept the new flag? I can do so for you. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1918#issuecomment-3758299749 From tobias.hartmann at oracle.com Fri Jan 16 07:17:47 2026 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 16 Jan 2026 08:17:47 +0100 Subject: CFV: New Valhalla Committer: Chris Plummer In-Reply-To: References: Message-ID: <7277289f-4463-47d7-b918-919a0a072f6c@oracle.com> Vote: yes Best regards, Tobias On 1/15/26 17:23, David Simms wrote: > |I hereby nominate *Chris Plummer* to *Valhalla* Committer. Chris is a long time member of the OpenJDK project, with over 400 commits in the mainline[1]. Votes are due by 29th of December, 18:00z. Only current *Valhalla* Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. *David Simms* [1] https://github.com/search?q=committer-name%3A%22Chris+Plummer%22+repo%3Aopenjdk%2Fjdk+&type=commits [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote| > > From thartmann at openjdk.org Fri Jan 16 07:23:43 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 Jan 2026 07:23:43 GMT Subject: [lworld] RFR: 8375320: [lworld] Revert System.identityHashcode for value objects to non AltSubstitutability version In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 21:57:37 GMT, Roger Riggs wrote: > Restore the unconditional use of value_object_hash_code_method. > The Alt hashcode method based on the Unsafe.getFieldMap is not used. > System.identityHashCode uses ValueObjectMethods.valueObjectHashCode() implemented using the original method-handle implementation. Marked as reviewed by thartmann (Committer). Looks good. Fixed title mismatch. ------------- PR Review: https://git.openjdk.org/valhalla/pull/1907#pullrequestreview-3669297211 PR Comment: https://git.openjdk.org/valhalla/pull/1907#issuecomment-3758522743 PR Comment: https://git.openjdk.org/valhalla/pull/1907#issuecomment-3758526524 From rriggs at openjdk.org Fri Jan 16 07:35:22 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 16 Jan 2026 07:35:22 GMT Subject: [lworld] Integrated: 8375320: [lworld] Revert System.identityHashcode for value objects to non AltSubstitutability version In-Reply-To: References: Message-ID: <2ZogBQbRAk7Gy6MD-XXFV_D6xd6Hi95-gPHiMI9S4G4=.6e8d989c-25bf-4262-abab-39335bc4065f@github.com> On Wed, 14 Jan 2026 21:57:37 GMT, Roger Riggs wrote: > Restore the unconditional use of value_object_hash_code_method. > The Alt hashcode method based on the Unsafe.getFieldMap is not used. > System.identityHashCode uses ValueObjectMethods.valueObjectHashCode() implemented using the original method-handle implementation. This pull request has now been integrated. Changeset: fa448d1c Author: Roger Riggs Committer: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/fa448d1cef70a6452aa45eb6a3853a12ec934005 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8375320: [lworld] Revert System.identityHashcode for value objects to non AltSubstitutability version Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1907 From thartmann at openjdk.org Fri Jan 16 08:36:20 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 Jan 2026 08:36:20 GMT Subject: [lworld] RFR: 8375499: [lworld] IR framework tests fail with UseAltSubstitutabilityMethod Message-ID: TestLWorld.java and TestLWorldProfiling.java fail if `-XX:+UseAltSubstitutabilityMethod` is the default because they expect the substitutability test method to be named "isSubstitutable" and not "isSubstitutableAlt". Thanks, Tobias ------------- Commit messages: - JDK-8375499 Changes: https://git.openjdk.org/valhalla/pull/1919/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1919&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375499 Stats: 49 lines in 2 files changed: 0 ins; 0 del; 49 mod Patch: https://git.openjdk.org/valhalla/pull/1919.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1919/head:pull/1919 PR: https://git.openjdk.org/valhalla/pull/1919 From serguei.spitsyn at oracle.com Fri Jan 16 08:43:32 2026 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Fri, 16 Jan 2026 08:43:32 +0000 Subject: CFV: New Valhalla Committer: Chris Plummer In-Reply-To: References: Message-ID: Vote: yes Confidential- Oracle Internal -------------- next part -------------- An HTML attachment was scrubbed... URL: From phubner at openjdk.org Fri Jan 16 09:15:14 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Fri, 16 Jan 2026 09:15:14 GMT Subject: [lworld] RFR: 8375434: [lworld] Add comment for null-check in InlineKlass::read_payload_from_addr [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 16:10:58 GMT, Joel Sikstr?m wrote: >> Hello, >> >> Update: There is nothing wrong with the logic. I added a comment to clarify why the second null-marker check is needed. Thanks. >> >> ~~Right now we check the null-marker for the NULLABLE_ATOMIC_FLAT LayoutKind twice, both before and after allocating a heap instance. The first check returns nullptr early if the null-marker is set, as we don't have to allocate an object on the heap if we are going to return nullptr anyways. The other check is redundant, since if the null-marker is not set, the source object is non-null, which means the destination (res) object is non-null as well after copying, so the code inside it is unreachable.~~ >> >> Testing: >> * Oracle's tier1-4, hotspot_valhalla, jdk_valhalla >> * ~~I also added a `gurantee` for the removed code and ran through hotspot_valhalla and jdk_valhalla locally.~~ > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Add comment Looks good, thanks for adding the comment. ------------- Marked as reviewed by phubner (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1914#pullrequestreview-3669684131 From chagedorn at openjdk.org Fri Jan 16 09:24:52 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 16 Jan 2026 09:24:52 GMT Subject: [lworld] RFR: 8375499: [lworld] IR framework tests fail with UseAltSubstitutabilityMethod In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 08:28:21 GMT, Tobias Hartmann wrote: > TestLWorld.java and TestLWorldProfiling.java fail if `-XX:+UseAltSubstitutabilityMethod` is the default because they expect the substitutability test method to be named "isSubstitutable" and not "isSubstitutableAlt". > > Thanks, > Tobias Looks good! ------------- Marked as reviewed by chagedorn (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1919#pullrequestreview-3669724431 From thartmann at openjdk.org Fri Jan 16 09:24:52 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 Jan 2026 09:24:52 GMT Subject: [lworld] RFR: 8375499: [lworld] IR framework tests fail with UseAltSubstitutabilityMethod In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 08:28:21 GMT, Tobias Hartmann wrote: > TestLWorld.java and TestLWorldProfiling.java fail if `-XX:+UseAltSubstitutabilityMethod` is the default because they expect the substitutability test method to be named "isSubstitutable" and not "isSubstitutableAlt". > > Thanks, > Tobias Thanks for the review, Christian! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1919#issuecomment-3758934360 From thartmann at openjdk.org Fri Jan 16 09:33:07 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 Jan 2026 09:33:07 GMT Subject: [lworld] Integrated: 8375499: [lworld] IR framework tests fail with UseAltSubstitutabilityMethod In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 08:28:21 GMT, Tobias Hartmann wrote: > TestLWorld.java and TestLWorldProfiling.java fail if `-XX:+UseAltSubstitutabilityMethod` is the default because they expect the substitutability test method to be named "isSubstitutable" and not "isSubstitutableAlt". > > Thanks, > Tobias This pull request has now been integrated. Changeset: 3a5baa9f Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/3a5baa9f7cca4f852b12c1d9c2f19accc7664072 Stats: 49 lines in 2 files changed: 0 ins; 0 del; 49 mod 8375499: [lworld] IR framework tests fail with UseAltSubstitutabilityMethod Reviewed-by: chagedorn ------------- PR: https://git.openjdk.org/valhalla/pull/1919 From mcimadamore at openjdk.org Fri Jan 16 10:01:05 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 16 Jan 2026 10:01:05 GMT Subject: RFR: add the NullRestricted annotation to null restricted fields of value classes In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 05:16:11 GMT, Vicente Romero wrote: > null restricted fields of value classes should be annotated, temporarily, with the @NullRestricted annotation Looks very good! ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1918#pullrequestreview-3669945706 From mcimadamore at openjdk.org Fri Jan 16 10:01:05 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 16 Jan 2026 10:01:05 GMT Subject: RFR: add the NullRestricted annotation to null restricted fields of value classes In-Reply-To: <_1vj6Hyzg-TO85UvtIzoM_WJwZM6_9xNCuiUjhjwCbI=.ac4a89b8-60d1-4c8e-84f6-f0929e4c0c1d@github.com> References: <_1vj6Hyzg-TO85UvtIzoM_WJwZM6_9xNCuiUjhjwCbI=.ac4a89b8-60d1-4c8e-84f6-f0929e4c0c1d@github.com> Message-ID: On Fri, 16 Jan 2026 05:52:35 GMT, Chen Liang wrote: > Can't we update classFileParser to accept the new flag? I can do so for you. Eventually yes -- this is an interim tweak ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1918#issuecomment-3759146642 From sjohanss at openjdk.org Fri Jan 16 10:12:01 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 16 Jan 2026 10:12:01 GMT Subject: [lworld] RFR: 8375374: [lworld] Remove some traces of [v2] In-Reply-To: References: <4Ton9HHm6gq48yW7uqqtStNsj7XHvbWbpBqqQIHlZ4E=.221aa49d-76cd-4936-b2da-348dfccc35f4@github.com> Message-ID: <1LxS4zidnY0JElxYY8nf2UuTXW0fXhd6asbiRs2DpLw=.70e64ab0-ada9-4801-800e-614ca967e5be@github.com> On Thu, 15 Jan 2026 13:21:45 GMT, Frederic Parain wrote: >> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove verifier test files no longer needed > > Still looks good. Thanks for the review @fparain ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1912#issuecomment-3759204542 From duke at openjdk.org Fri Jan 16 10:12:03 2026 From: duke at openjdk.org (duke) Date: Fri, 16 Jan 2026 10:12:03 GMT Subject: [lworld] RFR: 8375374: [lworld] Remove some traces of [v2] In-Reply-To: References: <4Ton9HHm6gq48yW7uqqtStNsj7XHvbWbpBqqQIHlZ4E=.221aa49d-76cd-4936-b2da-348dfccc35f4@github.com> Message-ID: On Thu, 15 Jan 2026 13:26:23 GMT, Stefan Johansson wrote: >> Please review this small change to remove a few traces still left of no longer used ``. >> >> After this change, the only reference left to `` is in `verifierTests.jcod` used by the test `VerifierInlineTypes`. I'm uncertain how to handle that so I will leave that to someone else, but filed [JDK-8375373](https://bugs.openjdk.org/browse/JDK-8375373) to keep track of it. > > Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: > > Remove verifier test files no longer needed @kstefanj Your change (at version 45c99880ee09670406eaaea7011ad76b446dfe3d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1912#issuecomment-3759213027 From mcimadamore at openjdk.org Fri Jan 16 10:30:05 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 16 Jan 2026 10:30:05 GMT Subject: RFR: add use site null checks [v7] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 01:37:05 GMT, Vicente Romero wrote: >> Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > changes to tests Looks good src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 219: > 217: actualArgsTmp = actualArgsTmp.tail; > 218: } > 219: // now add the last vararg argument if applicable Maybe add in the comment that no check is needed here, and that this is already translated by Lower into an array test/langtools/tools/javac/nullability/RuntimeNullChecks.java line 507: > 505: > 506: @Test > 507: public void testClientSideChecksSepCompilation(Path base) throws Exception { Nice tests! ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1910#pullrequestreview-3670098723 PR Review Comment: https://git.openjdk.org/valhalla/pull/1910#discussion_r2697911024 PR Review Comment: https://git.openjdk.org/valhalla/pull/1910#discussion_r2697918823 From sjohanss at openjdk.org Fri Jan 16 10:30:31 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 16 Jan 2026 10:30:31 GMT Subject: [lworld] Integrated: 8375374: [lworld] Remove some traces of In-Reply-To: <4Ton9HHm6gq48yW7uqqtStNsj7XHvbWbpBqqQIHlZ4E=.221aa49d-76cd-4936-b2da-348dfccc35f4@github.com> References: <4Ton9HHm6gq48yW7uqqtStNsj7XHvbWbpBqqQIHlZ4E=.221aa49d-76cd-4936-b2da-348dfccc35f4@github.com> Message-ID: On Thu, 15 Jan 2026 10:56:41 GMT, Stefan Johansson wrote: > Please review this small change to remove a few traces still left of no longer used ``. > > After this change, the only reference left to `` is in `verifierTests.jcod` used by the test `VerifierInlineTypes`. I'm uncertain how to handle that so I will leave that to someone else, but filed [JDK-8375373](https://bugs.openjdk.org/browse/JDK-8375373) to keep track of it. This pull request has now been integrated. Changeset: 3b522185 Author: Stefan Johansson Committer: Paul H?bner URL: https://git.openjdk.org/valhalla/commit/3b5221857639b8447fff5a5f6a9f264dbc284e27 Stats: 1726 lines in 7 files changed: 0 ins; 1721 del; 5 mod 8375374: [lworld] Remove some traces of 8375373: [lworld] Remove test VerifierInlineTypes Reviewed-by: fparain ------------- PR: https://git.openjdk.org/valhalla/pull/1912 From thartmann at openjdk.org Fri Jan 16 10:52:33 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 Jan 2026 10:52:33 GMT Subject: [lworld] RFR: 8375526: [lworld] Missing newline in fieldDescriptor::print_on_for Message-ID: There is a missing newline in the output of `fieldDescriptor::print_on_for`. Without the fix: "Executing pp" java.lang.Runtime$Version {0x00000007ffd0c9e0} - klass: 'java/lang/Runtime$Version' - flags: - ---- fields (total size 5 words): - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000007ffd0ca08} (0xfffa1941) - private final value 'pre' 'Ljava/util/Optional;' @16 Flat inline type field 'java/util/Optional': null - private final value 'build' 'Ljava/util/Optional;' @24 Flat inline type field 'java/util/Optional': null - private final value 'optional' 'Ljava/util/Optional;' @32 Flat inline type field 'java/util/Optional': null$1 = (void *) 0x0 With the fix: "Executing pp" java.lang.Runtime$Version {0x00000007ffd0ced8} - klass: 'java/lang/Runtime$Version' - flags: - ---- fields (total size 5 words): - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000007ffd0cf00} (0xfffa19e0) - private final value 'pre' 'Ljava/util/Optional;' @16 Flat inline type field 'java/util/Optional': null - private final value 'build' 'Ljava/util/Optional;' @24 Flat inline type field 'java/util/Optional': null - private final value 'optional' 'Ljava/util/Optional;' @32 Flat inline type field 'java/util/Optional': null Thanks, Tobias ------------- Commit messages: - JDK-8375526 Changes: https://git.openjdk.org/valhalla/pull/1920/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1920&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375526 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1920.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1920/head:pull/1920 PR: https://git.openjdk.org/valhalla/pull/1920 From mcimadamore at openjdk.org Fri Jan 16 11:14:54 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 16 Jan 2026 11:14:54 GMT Subject: RFR: Fix RichDiagnosticFormatter not to strip metadata when computing where clauses Message-ID: <9gBBb5K-u2ug1VKXNTQAPFhBWm5mrqSvaZWgq4aA0dQ=.4b073b79-1faf-40de-b108-18550329856b@github.com> The rich diagnostic formatter computes a list of "where clauses" -- that is, extra diagnostics that are meant to explain what the types in the main diagnostic are. At some [point](https://bugs.openjdk.org/browse/JDK-8291643) it was decided to strip type annotations from the types in the diagnostics, to eliminate some noise. This created some issues: * the logic to (pre)compute where clauses had to be adjusted to also strip metadata, otherwise discrepancies could lead to types not being found in the where clause table at the time of emitting references to them * the preprocessing logic uses Type::toString to compare whether two where clauses types are the same -- this check is too fragile and sometimes leads to duplicated where clauses (esp. for intersection types) In addition to these general issues, calling `stripMetadata` unconditionally in `AbstractDiagnosticFormatter`, also means that we cannot correctly render null-restricted types. While we could do something to re-add the null-restriction after stripping, this silent coupling between `AbstractDiagnosticFormatter` and pre-processing of where clauses in `RichDiagnosticFormatter` is problematic, and an obstable to improve the treatment of null-restricted types. The solution is to avoid string-y comparison when populating where clauses. All comparison should occur either by symbol (e.g. type variables, captured types), or by `Types::isSameType` (for intersection type). Note that, since symbols are more stable, and since `isSameType` ignores metadata, we no longer need metadata stripping when computing and/or searching for where clauses. To make the code more robust I've centralized all the logic corresponding to populating and searching where clauses inside the already-existing `WhereClauses` class. This allows the code to control how de-duplication of similarly named (but different) type-variables should occur, etc. It also leads to slightly improved client code. This means we can now tweak `AbstractDiagnosticFormatter` to restore null-restriction after stripping. And this will now have no effect on the correctness of the rich formatter. I've also added a separate regression test to make sure that there's only one intersection where clause generated in cases where we have two intersection types with the same component types, but different annotations. Since the annotations are stripped, this leads (before this PR) to redundant where clauses with same content. ------------- Commit messages: - Add intersection test - Encapsulate code more - Initial push Changes: https://git.openjdk.org/valhalla/pull/1921/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1921&range=00 Stats: 220 lines in 7 files changed: 133 ins; 53 del; 34 mod Patch: https://git.openjdk.org/valhalla/pull/1921.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1921/head:pull/1921 PR: https://git.openjdk.org/valhalla/pull/1921 From mcimadamore at openjdk.org Fri Jan 16 11:14:55 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 16 Jan 2026 11:14:55 GMT Subject: RFR: Fix RichDiagnosticFormatter not to strip metadata when computing where clauses In-Reply-To: <9gBBb5K-u2ug1VKXNTQAPFhBWm5mrqSvaZWgq4aA0dQ=.4b073b79-1faf-40de-b108-18550329856b@github.com> References: <9gBBb5K-u2ug1VKXNTQAPFhBWm5mrqSvaZWgq4aA0dQ=.4b073b79-1faf-40de-b108-18550329856b@github.com> Message-ID: On Fri, 16 Jan 2026 11:05:37 GMT, Maurizio Cimadamore wrote: > The rich diagnostic formatter computes a list of "where clauses" -- that is, extra diagnostics that are meant to explain what the types in the main diagnostic are. > > At some [point](https://bugs.openjdk.org/browse/JDK-8291643) it was decided to strip type annotations from the types in the diagnostics, to eliminate some noise. This created some issues: > > * the logic to (pre)compute where clauses had to be adjusted to also strip metadata, otherwise discrepancies could lead to types not being found in the where clause table at the time of emitting references to them > * the preprocessing logic uses Type::toString to compare whether two where clauses types are the same -- this check is too fragile and sometimes leads to duplicated where clauses (esp. for intersection types) > > In addition to these general issues, calling `stripMetadata` unconditionally in `AbstractDiagnosticFormatter`, also means that we cannot correctly render null-restricted types. While we could do something to re-add the null-restriction after stripping, this silent coupling between `AbstractDiagnosticFormatter` and pre-processing of where clauses in `RichDiagnosticFormatter` is problematic, and an obstable to improve the treatment of null-restricted types. > > The solution is to avoid string-y comparison when populating where clauses. All comparison should occur either by symbol (e.g. type variables, captured types), or by `Types::isSameType` (for intersection type). Note that, since symbols are more stable, and since `isSameType` ignores metadata, we no longer need metadata stripping when computing and/or searching for where clauses. > > To make the code more robust I've centralized all the logic corresponding to populating and searching where clauses inside the already-existing `WhereClauses` class. This allows the code to control how de-duplication of similarly named (but different) type-variables should occur, etc. It also leads to slightly improved client code. > > This means we can now tweak `AbstractDiagnosticFormatter` to restore null-restriction after stripping. And this will now have no effect on the correctness of the rich formatter. > > I've also added a separate regression test to make sure that there's only one intersection where clause generated in cases where we have two intersection types with the same component types, but different annotations. Since the annotations are stripped, this leads (before this PR) to redundant where clauses with same content. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4390: > 4388: compiler.warn.suspicious.nullness.conversion=\ > 4389: Suspicious nullness conversion\n\ > 4390: required: {0}\n\ Removing this hack is really the goal of this PR -- now all null-restricted types are rendered correctly in the formatter machinery. In fact -- see some changes in the raw diagnostics in some negative tests, where null-restriction now (correctly) appear. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1921#discussion_r2698079635 From mchevalier at openjdk.org Fri Jan 16 11:16:47 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Fri, 16 Jan 2026 11:16:47 GMT Subject: [lworld] RFR: 8375526: [lworld] Missing newline in fieldDescriptor::print_on_for In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 10:47:00 GMT, Tobias Hartmann wrote: > There is a missing newline in the output of `fieldDescriptor::print_on_for`. > > Without the fix: > > "Executing pp" > java.lang.Runtime$Version > {0x00000007ffd0c9e0} - klass: 'java/lang/Runtime$Version' - flags: > > - ---- fields (total size 5 words): > - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000007ffd0ca08} (0xfffa1941) > - private final value 'pre' 'Ljava/util/Optional;' @16 Flat inline type field 'java/util/Optional': null - private final value 'build' 'Ljava/util/Optional;' @24 Flat inline type field 'java/util/Optional': null - private final value 'optional' 'Ljava/util/Optional;' @32 Flat inline type field 'java/util/Optional': null$1 = (void *) 0x0 > > > With the fix: > > "Executing pp" > java.lang.Runtime$Version > {0x00000007ffd0ced8} - klass: 'java/lang/Runtime$Version' - flags: > > - ---- fields (total size 5 words): > - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000007ffd0cf00} (0xfffa19e0) > - private final value 'pre' 'Ljava/util/Optional;' @16 Flat inline type field 'java/util/Optional': null > - private final value 'build' 'Ljava/util/Optional;' @24 Flat inline type field 'java/util/Optional': null > - private final value 'optional' 'Ljava/util/Optional;' @32 Flat inline type field 'java/util/Optional': null > > > Thanks, > Tobias Good. Trivial. ------------- Marked as reviewed by mchevalier (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1920#pullrequestreview-3670378200 From thartmann at openjdk.org Fri Jan 16 11:51:40 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 Jan 2026 11:51:40 GMT Subject: [lworld] RFR: 8375526: [lworld] Missing newline in fieldDescriptor::print_on_for In-Reply-To: References: Message-ID: <3-VIjmBJ9oSiS0uzeC-rJxQFzra2BTiz959G_kSubSs=.6abb03fd-5249-4ee8-b0bb-324eca1807c5@github.com> On Fri, 16 Jan 2026 10:47:00 GMT, Tobias Hartmann wrote: > There is a missing newline in the output of `fieldDescriptor::print_on_for`. > > Without the fix: > > "Executing pp" > java.lang.Runtime$Version > {0x00000007ffd0c9e0} - klass: 'java/lang/Runtime$Version' - flags: > > - ---- fields (total size 5 words): > - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000007ffd0ca08} (0xfffa1941) > - private final value 'pre' 'Ljava/util/Optional;' @16 Flat inline type field 'java/util/Optional': null - private final value 'build' 'Ljava/util/Optional;' @24 Flat inline type field 'java/util/Optional': null - private final value 'optional' 'Ljava/util/Optional;' @32 Flat inline type field 'java/util/Optional': null$1 = (void *) 0x0 > > > With the fix: > > "Executing pp" > java.lang.Runtime$Version > {0x00000007ffd0ced8} - klass: 'java/lang/Runtime$Version' - flags: > > - ---- fields (total size 5 words): > - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000007ffd0cf00} (0xfffa19e0) > - private final value 'pre' 'Ljava/util/Optional;' @16 Flat inline type field 'java/util/Optional': null > - private final value 'build' 'Ljava/util/Optional;' @24 Flat inline type field 'java/util/Optional': null > - private final value 'optional' 'Ljava/util/Optional;' @32 Flat inline type field 'java/util/Optional': null > > > Thanks, > Tobias Thanks Marc! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1920#issuecomment-3759679556 From thartmann at openjdk.org Fri Jan 16 11:53:16 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 Jan 2026 11:53:16 GMT Subject: [lworld] Integrated: 8375526: [lworld] Missing newline in fieldDescriptor::print_on_for In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 10:47:00 GMT, Tobias Hartmann wrote: > There is a missing newline in the output of `fieldDescriptor::print_on_for`. > > Without the fix: > > "Executing pp" > java.lang.Runtime$Version > {0x00000007ffd0c9e0} - klass: 'java/lang/Runtime$Version' - flags: > > - ---- fields (total size 5 words): > - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000007ffd0ca08} (0xfffa1941) > - private final value 'pre' 'Ljava/util/Optional;' @16 Flat inline type field 'java/util/Optional': null - private final value 'build' 'Ljava/util/Optional;' @24 Flat inline type field 'java/util/Optional': null - private final value 'optional' 'Ljava/util/Optional;' @32 Flat inline type field 'java/util/Optional': null$1 = (void *) 0x0 > > > With the fix: > > "Executing pp" > java.lang.Runtime$Version > {0x00000007ffd0ced8} - klass: 'java/lang/Runtime$Version' - flags: > > - ---- fields (total size 5 words): > - private final value 'version' 'Ljava/util/List;' @12 a 'java/util/ImmutableCollections$List12'{0x00000007ffd0cf00} (0xfffa19e0) > - private final value 'pre' 'Ljava/util/Optional;' @16 Flat inline type field 'java/util/Optional': null > - private final value 'build' 'Ljava/util/Optional;' @24 Flat inline type field 'java/util/Optional': null > - private final value 'optional' 'Ljava/util/Optional;' @32 Flat inline type field 'java/util/Optional': null > > > Thanks, > Tobias This pull request has now been integrated. Changeset: 0619ddce Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/0619ddce6c815d5aa49eb76ed0088d373cdd7a81 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8375526: [lworld] Missing newline in fieldDescriptor::print_on_for Reviewed-by: mchevalier ------------- PR: https://git.openjdk.org/valhalla/pull/1920 From vromero at openjdk.org Fri Jan 16 13:32:56 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 13:32:56 GMT Subject: RFR: add the NullRestricted annotation to null restricted fields of value classes In-Reply-To: References: <_1vj6Hyzg-TO85UvtIzoM_WJwZM6_9xNCuiUjhjwCbI=.ac4a89b8-60d1-4c8e-84f6-f0929e4c0c1d@github.com> Message-ID: On Fri, 16 Jan 2026 09:57:22 GMT, Maurizio Cimadamore wrote: > Can't we update classFileParser to accept the new flag? I can do so for you. sure that would be great, thanks ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1918#issuecomment-3760037672 From vromero at openjdk.org Fri Jan 16 13:38:33 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 13:38:33 GMT Subject: RFR: add the NullRestricted annotation to null restricted fields of value classes In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 05:16:11 GMT, Vicente Romero wrote: > null restricted fields of value classes should be annotated, temporarily, with the @NullRestricted annotation thanks for the reviews ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1918#issuecomment-3760052509 From vromero at openjdk.org Fri Jan 16 13:38:34 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 13:38:34 GMT Subject: Integrated: add the NullRestricted annotation to null restricted fields of value classes In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 05:16:11 GMT, Vicente Romero wrote: > null restricted fields of value classes should be annotated, temporarily, with the @NullRestricted annotation This pull request has now been integrated. Changeset: ab1e4545 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/ab1e45457ece5f3ce67baf0b844fb107b3845065 Stats: 68 lines in 8 files changed: 22 ins; 15 del; 31 mod add the NullRestricted annotation to null restricted fields of value classes Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1918 From rriggs at openjdk.org Fri Jan 16 13:48:39 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 16 Jan 2026 13:48:39 GMT Subject: [lworld] RFR: 8375319: [lworld] System.identityHashCode wrong for Wrapper classes with -XX:+UseAltSubstitutabilityMethod Message-ID: <8iAhgZQMfG0hrwJGEH_lhG9htUwHGigvq5-gER869cY=.0abe126f-cfc1-4208-86dc-ee6dcfd10244@github.com> For all value classes, including the wrapper classes, seed the AltHashCode implementation on the SALT value. ------------- Commit messages: - 8375319: [lworld] System.identityHashCode wrong for Wrapper classes with -XX:+UseAltSubstitutabilityMethod Changes: https://git.openjdk.org/valhalla/pull/1924/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1924&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375319 Stats: 26 lines in 1 file changed: 13 ins; 12 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1924.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1924/head:pull/1924 PR: https://git.openjdk.org/valhalla/pull/1924 From mchevalier at openjdk.org Fri Jan 16 13:49:22 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Fri, 16 Jan 2026 13:49:22 GMT Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed: bad cast Message-ID: Some code added by [JDK-8372700](https://bugs.openjdk.org/browse/JDK-8372700) can compute the constant value of a field of a (flatten) element in a flat array. We get a crash when the element of the array is known to be `null`, and so the field doesn't exist. So, let's just check in `ciConstant ciFlatArray::field_value(int index, ciField* field)` whether we get a null constant before interpreting it as a `ciInstance` and trying to retrieve a field from there. This should be enough since a `ciObject` is (directly) derived by `ciNullObject`, `ciInstance` and `ciArray`. Since we are looking up a value of a flat array, an element cannot be a `ciArray` (arrays have identities and can't be contained in a flat array). After looking up whether the flat array element is null, the `obj->as_instance()` cast acts as an assert, should we ever add another derived class from `ciObject`. In case of a null array element, `field_value` simply returns an invalid `ciConstant`. Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks good. Thanks, Marc ------------- Commit messages: - Shield against null Changes: https://git.openjdk.org/valhalla/pull/1923/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1923&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375441 Stats: 25 lines in 2 files changed: 15 ins; 5 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1923.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1923/head:pull/1923 PR: https://git.openjdk.org/valhalla/pull/1923 From mchevalier at openjdk.org Fri Jan 16 13:57:00 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Fri, 16 Jan 2026 13:57:00 GMT Subject: [lworld] RFR: 8374006: [lworld] Improve field accessor methods in InlineTypeNode Message-ID: This PR remove from `InlineTypeNode` the methods: int field_offset(uint index) const; uint field_index(int offset) const; ciType* field_type(uint index) const; bool field_is_flat(uint index) const; bool field_is_null_free(uint index) const; bool field_is_volatile(uint index) const; int field_null_marker_offset(uint index) const; in favor of a single ciField* field(uint index) const; from which we directly access the various properties we are interested in. I've called it `field` as suggested in the original discussion. I've started with `declared_nonstatic_field_at` to be consistent with `ciInstanceKlass` and to avoid ambiguity wrt which kind of fields we are talking about, but this name is rather long... Since we are only talking about the declared fields, and we have no easy getter for `nonstatic_field_at`, then I think it's ok to have a shorter name. Also, in the context of a `InlineTypeNode`, the "non-static" part of the long name seems rather redundant. The other question is what we should do with asserts? Methods `field_is_flat`, `field_is_null_free` and `field_is_volatile` had the assert assert(!field->is_flat() || field->type()->is_inlinetype(), "must be an inline type"); and `field_null_marker_offset` had assert(field->is_flat(), "must be an inline type"); I've tried to propagate them to the call-site of such functions, and where it makes a bit of sense, and not subsumed by surrounding `if()` and `assert`. Let me know if it seems unnecessary or not well-placed in some cases. Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks fine, but it doesn't seem too risky. Thanks, Marc ------------- Commit messages: - Cleanup - InlineTypeNode::field(uint) const Changes: https://git.openjdk.org/valhalla/pull/1922/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1922&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374006 Stats: 134 lines in 4 files changed: 36 ins; 39 del; 59 mod Patch: https://git.openjdk.org/valhalla/pull/1922.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1922/head:pull/1922 PR: https://git.openjdk.org/valhalla/pull/1922 From fparain at openjdk.org Fri Jan 16 13:58:07 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 16 Jan 2026 13:58:07 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 20:13:29 GMT, Frederic Parain wrote: > This would forbid the class which contains the `NULLABLE_NON_ATOMIC_FLAT` from being flattened into a class which contains it. I think we should only do so if the holder of the flattened strict final field should not be flattened if it is not itself a strict final field: > > * The holder is an identity class. > > * The holder is a large value class without `@LooselyConsistentValue`. > > > This is equally valid to null-restricted field of non-`@LooselyConsistentValue`, too. Yes, there are some restrictions where the NULLABLE_NON_ATOMIC_FLAT can be used, see the comments and the `can_use_atomic_flat` argument in the `field_layout_selection()` method. > I assume this PR is for flattening of nullable fields at immutable memory (strict final fields) only. But I think the same flattening can be done for null-free field, right? Strict final null-free fields could also be flattened without having to be concerned about atomicity, but null-freeness is not part of JEP 401. So this case is not supported in this PR. It can be added later when the null-restriction JEP has been finalized. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1407#issuecomment-3760127181 From fparain at openjdk.org Fri Jan 16 14:04:41 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 16 Jan 2026 14:04:41 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v2] In-Reply-To: <7MOS5ouxv2QqlXu-s_m_LKzD5XMUeNMBTn6am-COjBU=.356e1b35-4aa2-4456-b661-563190184b40@github.com> References: <7MOS5ouxv2QqlXu-s_m_LKzD5XMUeNMBTn6am-COjBU=.356e1b35-4aa2-4456-b661-563190184b40@github.com> Message-ID: On Wed, 14 Jan 2026 20:12:01 GMT, Coleen Phillimore wrote: > Should this be nullable_non_atomic_alignment() ? Or is it the same alignment as null_free_non_atomic_alignment? (if so pls comment why) Nullable non-atomic layouts have the same alignment constraint as null_free_non_atomic layouts. Null-free non atomic layouts have an alignment constraint based on the constraints of individual fields inside the layout. The addition of the null marker, which is currently encoded with a byte, just adds the weakest alignment constraint to the set of constraints to be considered, so it has no effect, and the end results for nullable-non-atomic layouts is the same as for null-free-non-atomic layouts. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2698632128 From vromero at openjdk.org Fri Jan 16 14:06:26 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 14:06:26 GMT Subject: RFR: add use site null checks [v8] In-Reply-To: References: Message-ID: <9n14Aa0GHcPWvL9wxtpKEY4wI1Qjgf4VSw1XQ9Sg1QU=.841f75c3-c9e8-4277-a864-e25eddac8096@github.com> > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: - another change - adding a comment ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1910/files - new: https://git.openjdk.org/valhalla/pull/1910/files/8460cc06..7fc61058 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=07 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=06-07 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1910.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1910/head:pull/1910 PR: https://git.openjdk.org/valhalla/pull/1910 From vromero at openjdk.org Fri Jan 16 14:09:32 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 14:09:32 GMT Subject: RFR: add use site null checks [v9] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 14:06:25 GMT, Vicente Romero wrote: >> Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them > > Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: > > - Apply suggestion from @vicente-romero-oracle > - last change src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 221: > 219: /* now add the last vararg argument if applicable, no checks are needed here as varargs can't be > 220: * null restricted. Also note that at this point the vararg arguments have already been translated > 221: * by Lower into an array. This is not true for signature polymorphic methods but we have already Suggestion: * by Lower into an array. This is not true for signature polymorphic methods, but we have already ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1910#discussion_r2698649582 From fparain at openjdk.org Fri Jan 16 14:11:51 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 16 Jan 2026 14:11:51 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v2] In-Reply-To: References: <7MOS5ouxv2QqlXu-s_m_LKzD5XMUeNMBTn6am-COjBU=.356e1b35-4aa2-4456-b661-563190184b40@github.com> Message-ID: On Wed, 14 Jan 2026 20:14:40 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/inlineKlass.hpp line 95: >> >>> 93: int _null_free_atomic_size_in_bytes; // size and alignment requirement for a null-free atomic layout, -1 if no atomic flat layout is possible >>> 94: int _nullable_atomic_size_in_bytes; // size and alignment requirement for a nullable layout (always atomic), -1 if no nullable flat layout is possible >>> 95: int _nullable_non_atomic_size_in_bytes; // size and alignment requirement for a nullable non-atomic layout, -1 if not available >> >> Here is something that I'm confused about. Does an InlineKlass have multiple possible layouts and sizes depending on the container? Is that why the InlineKlass needs to save all these size non-static data members? > > Can you align the // s please? > Here is something that I'm confused about. Does an InlineKlass have multiple possible layouts and sizes depending on the container? Is that why the InlineKlass needs to save all these size non-static data members? An InlineKlass supports a set of layout according to its own characteristics (number of fields, atomicity, etc.). When computing the layout of a container with a value field, the JVM looks at the characteristics of the field (static, final , strict, null-free, etc.) and the layouts available for this InlineKlass and selects the best one that satisfies all requirements. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2698655768 From vromero at openjdk.org Fri Jan 16 14:09:31 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 14:09:31 GMT Subject: RFR: add use site null checks [v9] In-Reply-To: References: Message-ID: > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: - Apply suggestion from @vicente-romero-oracle - last change ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1910/files - new: https://git.openjdk.org/valhalla/pull/1910/files/7fc61058..51bb31c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=08 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1910.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1910/head:pull/1910 PR: https://git.openjdk.org/valhalla/pull/1910 From mcimadamore at openjdk.org Fri Jan 16 14:19:58 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 16 Jan 2026 14:19:58 GMT Subject: RFR: add use site null checks [v9] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 14:09:31 GMT, Vicente Romero wrote: >> Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them > > Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: > > - Apply suggestion from @vicente-romero-oracle > - last change Marked as reviewed by mcimadamore (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1910#pullrequestreview-3671089329 From fparain at openjdk.org Fri Jan 16 14:20:32 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 16 Jan 2026 14:20:32 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v3] In-Reply-To: References: Message-ID: > Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case. > This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic. Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: Fix coding style ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1407/files - new: https://git.openjdk.org/valhalla/pull/1407/files/91c57ec1..7654118f Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1407&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1407&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/valhalla/pull/1407.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1407/head:pull/1407 PR: https://git.openjdk.org/valhalla/pull/1407 From fparain at openjdk.org Fri Jan 16 14:20:36 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 16 Jan 2026 14:20:36 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v2] In-Reply-To: <7MOS5ouxv2QqlXu-s_m_LKzD5XMUeNMBTn6am-COjBU=.356e1b35-4aa2-4456-b661-563190184b40@github.com> References: <7MOS5ouxv2QqlXu-s_m_LKzD5XMUeNMBTn6am-COjBU=.356e1b35-4aa2-4456-b661-563190184b40@github.com> Message-ID: On Wed, 14 Jan 2026 20:16:57 GMT, Coleen Phillimore wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> More renaming > > src/hotspot/share/oops/layoutKind.hpp line 69: > >> 67: // always be filled with zeros, and the default value could have its null marker set to non-zero if >> 68: // it is used as a source to update a NULLABLE_ATOMIC_FLAT field. >> 69: // NULLABLE_NON_ATOMIC_FLAT: this is a special layout, only used for strict final non-static fields. Because strict > > Can you capitalize 't' in "this" in these descriptions? Fixed ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2698683327 From vromero at openjdk.org Fri Jan 16 14:22:10 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 14:22:10 GMT Subject: RFR: add use site null checks [v10] In-Reply-To: References: Message-ID: > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - merge with bworld - Apply suggestion from @vicente-romero-oracle - last change - another change - adding a comment - changes to tests - code changes - minor code changes - removing comments - adding tests - ... and 3 more: https://git.openjdk.org/valhalla/compare/ab1e4545...cc8582f7 ------------- Changes: https://git.openjdk.org/valhalla/pull/1910/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=09 Stats: 317 lines in 2 files changed: 308 ins; 0 del; 9 mod Patch: https://git.openjdk.org/valhalla/pull/1910.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1910/head:pull/1910 PR: https://git.openjdk.org/valhalla/pull/1910 From vromero at openjdk.org Fri Jan 16 14:23:55 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 14:23:55 GMT Subject: RFR: add use site null checks [v11] In-Reply-To: References: Message-ID: <-b26Q74Yz7vXeU9iiW8Ydm12I81PK_p-WUH0NjAFHlw=.6851bef2-ec82-47eb-b6dd-2f1e338d75f6@github.com> > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: minor change ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1910/files - new: https://git.openjdk.org/valhalla/pull/1910/files/cc8582f7..6a4d1480 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=10 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1910&range=09-10 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1910.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1910/head:pull/1910 PR: https://git.openjdk.org/valhalla/pull/1910 From duke at openjdk.org Fri Jan 16 14:39:43 2026 From: duke at openjdk.org (David Beaumont) Date: Fri, 16 Jan 2026 14:39:43 GMT Subject: [lworld] RFR: 8362252: [lworld] Possible synchronization issue in jdk/internal/jimage/ImageReader.java In-Reply-To: References: <6Tx7jSFas_nHB9RZY4Rsx6O6_P4jFZQvuQIMRVnU-3I=.c886f94e-8a39-491b-aa96-2d717f5a2073@github.com> Message-ID: On Thu, 18 Dec 2025 21:11:49 GMT, Roger Riggs wrote: >> Tidying up syncrhonization around shared image. > > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 416: > >> 414: OPEN_FILES.put(key, sharedReader); >> 415: } else if (sharedReader.getByteOrder() != byteOrder) { >> 416: throw new IOException("\"" + sharedReader.getName() + "\" is not an image file"); > > Its pre-existing, but ... > Testing the byteOrder and then throwing an exception that says it is not an Image file doesn't make sense. That's a very good point. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1828#discussion_r2698753659 From roger.riggs at oracle.com Fri Jan 16 14:45:45 2026 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 16 Jan 2026 09:45:45 -0500 Subject: CFV: New Valhalla Committer: Chris Plummer In-Reply-To: References: Message-ID: <28354fc0-ea4d-488e-be5e-5199607a3bf0@oracle.com> Vote: Yes On 1/15/26 11:23 AM, David Simms wrote: > |I hereby nominate *Chris Plummer* to *Valhalla* Committer.| -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Fri Jan 16 14:46:56 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 16 Jan 2026 14:46:56 GMT Subject: [lworld] RFR: 8375319: [lworld] System.identityHashCode wrong for Wrapper classes with -XX:+UseAltSubstitutabilityMethod [v2] In-Reply-To: <8iAhgZQMfG0hrwJGEH_lhG9htUwHGigvq5-gER869cY=.0abe126f-cfc1-4208-86dc-ee6dcfd10244@github.com> References: <8iAhgZQMfG0hrwJGEH_lhG9htUwHGigvq5-gER869cY=.0abe126f-cfc1-4208-86dc-ee6dcfd10244@github.com> Message-ID: > For all value classes, including the wrapper classes, seed the AltHashCode implementation on the SALT value. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Re-enable the Alt hashcode implementation to be used with -XX:+UseAltSubstitutabilityMethod - Merge branch 'lworld' into 8375319-hashcode-add-salt - 8375319: [lworld] System.identityHashCode wrong for Wrapper classes with -XX:+UseAltSubstitutabilityMethod Seed the AltHashCode implementation on the SALT value. ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1924/files - new: https://git.openjdk.org/valhalla/pull/1924/files/57bdfebd..4beb1006 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1924&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1924&range=00-01 Stats: 1938 lines in 19 files changed: 99 ins; 1762 del; 77 mod Patch: https://git.openjdk.org/valhalla/pull/1924.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1924/head:pull/1924 PR: https://git.openjdk.org/valhalla/pull/1924 From thartmann at openjdk.org Fri Jan 16 14:46:56 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 Jan 2026 14:46:56 GMT Subject: [lworld] RFR: 8375319: [lworld] System.identityHashCode wrong for Wrapper classes with -XX:+UseAltSubstitutabilityMethod [v2] In-Reply-To: References: <8iAhgZQMfG0hrwJGEH_lhG9htUwHGigvq5-gER869cY=.0abe126f-cfc1-4208-86dc-ee6dcfd10244@github.com> Message-ID: On Fri, 16 Jan 2026 14:43:28 GMT, Roger Riggs wrote: >> For all value classes, including the wrapper classes, seed the AltHashCode implementation on the SALT value. > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Re-enable the Alt hashcode implementation to be used with -XX:+UseAltSubstitutabilityMethod > - Merge branch 'lworld' into 8375319-hashcode-add-salt > - 8375319: [lworld] System.identityHashCode wrong for Wrapper classes with -XX:+UseAltSubstitutabilityMethod > Seed the AltHashCode implementation on the SALT value. Looks good to me. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1924#pullrequestreview-3671201104 From vromero at openjdk.org Fri Jan 16 14:55:08 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 14:55:08 GMT Subject: RFR: add use site null checks [v11] In-Reply-To: <-b26Q74Yz7vXeU9iiW8Ydm12I81PK_p-WUH0NjAFHlw=.6851bef2-ec82-47eb-b6dd-2f1e338d75f6@github.com> References: <-b26Q74Yz7vXeU9iiW8Ydm12I81PK_p-WUH0NjAFHlw=.6851bef2-ec82-47eb-b6dd-2f1e338d75f6@github.com> Message-ID: On Fri, 16 Jan 2026 14:23:55 GMT, Vicente Romero wrote: >> Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > minor change thanks for the suggestions and comments ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1910#issuecomment-3760368515 From vromero at openjdk.org Fri Jan 16 14:55:10 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 14:55:10 GMT Subject: Integrated: add use site null checks In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 05:46:52 GMT, Vicente Romero wrote: > Adding use site null checks for method invocations. They are added by default but if option: `noUseSiteNullChecks` is passed, the compiler won't generate them This pull request has now been integrated. Changeset: 44101e99 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/44101e99c49716cc0d4f4a97ebb0ec3922dd6b94 Stats: 320 lines in 2 files changed: 310 ins; 0 del; 10 mod add use site null checks Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1910 From rriggs at openjdk.org Fri Jan 16 14:57:52 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 16 Jan 2026 14:57:52 GMT Subject: [lworld] Integrated: 8375319: [lworld] System.identityHashCode wrong for Wrapper classes with -XX:+UseAltSubstitutabilityMethod In-Reply-To: <8iAhgZQMfG0hrwJGEH_lhG9htUwHGigvq5-gER869cY=.0abe126f-cfc1-4208-86dc-ee6dcfd10244@github.com> References: <8iAhgZQMfG0hrwJGEH_lhG9htUwHGigvq5-gER869cY=.0abe126f-cfc1-4208-86dc-ee6dcfd10244@github.com> Message-ID: On Fri, 16 Jan 2026 13:43:09 GMT, Roger Riggs wrote: > For all value classes, including the wrapper classes, seed the AltHashCode implementation on the SALT value. This pull request has now been integrated. Changeset: a3e60b81 Author: Roger Riggs URL: https://git.openjdk.org/valhalla/commit/a3e60b817d8173ac64c299c5c222ced0e70cb362 Stats: 28 lines in 2 files changed: 14 ins; 12 del; 2 mod 8375319: [lworld] System.identityHashCode wrong for Wrapper classes with -XX:+UseAltSubstitutabilityMethod Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1924 From jlahoda at openjdk.org Fri Jan 16 15:51:33 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 16 Jan 2026 15:51:33 GMT Subject: RFR: Support for null-restricted types in JShell Message-ID: Base on mcimadamore's idea of desugaring like: String! str = init; => class JShellClass { public static class Holder { public static String! str = init; } static Object do_it$() { return Holder.str; } } ------------- Commit messages: - Adding tests. - Support for JShell, as suggested by mcimadamore. Changes: https://git.openjdk.org/valhalla/pull/1925/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1925&range=00 Stats: 117 lines in 5 files changed: 73 ins; 23 del; 21 mod Patch: https://git.openjdk.org/valhalla/pull/1925.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1925/head:pull/1925 PR: https://git.openjdk.org/valhalla/pull/1925 From mcimadamore at openjdk.org Fri Jan 16 16:13:07 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 16 Jan 2026 16:13:07 GMT Subject: RFR: Support for null-restricted types in JShell In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 15:45:02 GMT, Jan Lahoda wrote: > Base on mcimadamore's idea of desugaring like: > > String! str = init; > => > class JShellClass { > public static class Holder { > public static String! str = init; > } > static Object do_it$() { > return Holder.str; > } > } Looks good -- thanks! ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1925#pullrequestreview-3671624529 From mcimadamore at openjdk.org Fri Jan 16 16:53:15 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 16 Jan 2026 16:53:15 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 04:51:29 GMT, Joe Darcy wrote: > A refinement of some earlier ideas on the numerics modeling interfaces to inform further discussions. > > This is a "lumpy" rather than "splitty" design in terms of favoring a smaller number of interfaces with more functionality rather than a larger number of interfaces making smaller distinctions. > > Various design comments and to-do's noted in the code. src/java.base/share/classes/java/lang/Orderable.java line 95: > 93: * @param op2 the second operand > 94: */ > 95: OC min(OC op1, OC op2); Should this be a default method? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1917#discussion_r2699247551 From duke at openjdk.org Fri Jan 16 16:57:56 2026 From: duke at openjdk.org (duke) Date: Fri, 16 Jan 2026 16:57:56 GMT Subject: RFR: Support for null-restricted types in JShell In-Reply-To: References: Message-ID: <4NmNNPElFdT_XrcVG8weAtYCzOq1KL1niMmi31Jc-3c=.7fe77aaf-6b57-435c-8466-f06315803d01@github.com> On Fri, 16 Jan 2026 15:45:02 GMT, Jan Lahoda wrote: > Base on mcimadamore's idea of desugaring like: > > String! str = init; > => > class JShellClass { > public static class Holder { > public static String! str = init; > } > static Object do_it$() { > return Holder.str; > } > } @lahodaj Your change (at version 428b5f7e2dd4078b9c7419eccd99da7d4df6e088) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1925#issuecomment-3760940417 From duke at openjdk.org Fri Jan 16 17:03:08 2026 From: duke at openjdk.org (duke) Date: Fri, 16 Jan 2026 17:03:08 GMT Subject: RFR: Fixing null restricted types for fields/methods in compact source files. In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 21:21:32 GMT, Jan Lahoda wrote: > The null restricted types don't seem to be supported for top-level fields/methods in compact source files: > > $ cat /tmp/Compact.java > String! s = ""; > void main() { > } > $ ./build/linux-x86_64-server-release/jdk/bin/javac --enable-preview --source 27 /tmp/Compact.java > /tmp/Compact.java:1: error: null restriction not supported in this type context > String! s = ""; > ^ > 1 error > > > This is a simple patch to fix that (removing the `unannotatedType(boolean)` method, as that is no longer used, to my knowledge. But it can be preserved, if preferred. @lahodaj Your change (at version 6c387da1065879ffcb0cb6141511eeae9cb9749a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1916#issuecomment-3760959988 From mcimadamore at openjdk.org Fri Jan 16 17:03:07 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 16 Jan 2026 17:03:07 GMT Subject: RFR: Fixing null restricted types for fields/methods in compact source files. In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 21:21:32 GMT, Jan Lahoda wrote: > The null restricted types don't seem to be supported for top-level fields/methods in compact source files: > > $ cat /tmp/Compact.java > String! s = ""; > void main() { > } > $ ./build/linux-x86_64-server-release/jdk/bin/javac --enable-preview --source 27 /tmp/Compact.java > /tmp/Compact.java:1: error: null restriction not supported in this type context > String! s = ""; > ^ > 1 error > > > This is a simple patch to fix that (removing the `unannotatedType(boolean)` method, as that is no longer used, to my knowledge. But it can be preserved, if preferred. Good catch! ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1916#pullrequestreview-3671821138 From chen.l.liang at oracle.com Fri Jan 16 17:22:32 2026 From: chen.l.liang at oracle.com (Chen Liang) Date: Fri, 16 Jan 2026 17:22:32 +0000 Subject: CFV: New Valhalla Committer: Chris Plummer In-Reply-To: References: Message-ID: Hi David, is the due date in this mail correct? I assume it should be 29th of January, 2026. If that is the correct date, then I cast a vote: Vote: yes Chen Liang Confidential- Oracle Internal ________________________________ From: valhalla-dev on behalf of David Simms Sent: Thursday, January 15, 2026 10:23 AM To: valhalla-dev at openjdk.java.net Subject: CFV: New Valhalla Committer: Chris Plummer I hereby nominate Chris Plummer to Valhalla Committer. Chris is a long time member of the OpenJDK project, with over 400 commits in the mainline[1]. Votes are due by 29th of December, 18:00z. Only current Valhalla Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. David Simms [1] https://github.com/search?q=committer-name%3A%22Chris+Plummer%22+repo%3Aopenjdk%2Fjdk+&type=commits [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From fparain at openjdk.org Fri Jan 16 17:45:06 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 16 Jan 2026 17:45:06 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v2] In-Reply-To: <7MOS5ouxv2QqlXu-s_m_LKzD5XMUeNMBTn6am-COjBU=.356e1b35-4aa2-4456-b661-563190184b40@github.com> References: <7MOS5ouxv2QqlXu-s_m_LKzD5XMUeNMBTn6am-COjBU=.356e1b35-4aa2-4456-b661-563190184b40@github.com> Message-ID: <8zilcjgdfbiDPMuteFclCxePuJL_9-KXtM-vblbALfk=.c5f4637d-692a-4d71-af34-e6c74b3ddde0@github.com> On Wed, 14 Jan 2026 20:05:40 GMT, Coleen Phillimore wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> More renaming > > src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1212: > >> 1210: _null_free_non_atomic_layout_alignment = _payload_alignment; >> 1211: } >> 1212: if (UseNullableValueFlattening) { > > Could this be else if (UseNullableValueFlattening)? These are mutually exclusive iirc so the else if would make that explicit. They are not mutually exclusive. Each layout can be enabled/disabled individually, mostly for testing/debugging purpose. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2699412900 From darcy at openjdk.org Fri Jan 16 18:21:24 2026 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 16 Jan 2026 18:21:24 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 16:50:30 GMT, Maurizio Cimadamore wrote: >> A refinement of some earlier ideas on the numerics modeling interfaces to inform further discussions. >> >> This is a "lumpy" rather than "splitty" design in terms of favoring a smaller number of interfaces with more functionality rather than a larger number of interfaces making smaller distinctions. >> >> Various design comments and to-do's noted in the code. > > src/java.base/share/classes/java/lang/Orderable.java line 95: > >> 93: * @param op2 the second operand >> 94: */ >> 95: OC min(OC op1, OC op2); > > Should this be a default method? I wasn't sure if min/max should be included in the interface. I think it depends what role any non-operator methods have in interfaces intended for witnesses. However, as long as the methods are here, they could be default methods, yes. To acknowledge some feedback received on a different channel, if the OC type variable were required to extend Comparable, then all the lessThan, greaterThan, etc. method could have default methods written in terms of the results of compareTo. However, if we want to move away from Comparable, then extended its usage here probably isn't a good idea. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1917#discussion_r2699523484 From coleenp at openjdk.org Fri Jan 16 19:06:45 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 16 Jan 2026 19:06:45 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 14:20:32 GMT, Frederic Parain wrote: >> Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case. >> This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic. > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > Fix coding style Looks good! ------------- Marked as reviewed by coleenp (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1407#pullrequestreview-3672298838 From coleenp at openjdk.org Fri Jan 16 19:06:48 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 16 Jan 2026 19:06:48 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v2] In-Reply-To: <8zilcjgdfbiDPMuteFclCxePuJL_9-KXtM-vblbALfk=.c5f4637d-692a-4d71-af34-e6c74b3ddde0@github.com> References: <7MOS5ouxv2QqlXu-s_m_LKzD5XMUeNMBTn6am-COjBU=.356e1b35-4aa2-4456-b661-563190184b40@github.com> <8zilcjgdfbiDPMuteFclCxePuJL_9-KXtM-vblbALfk=.c5f4637d-692a-4d71-af34-e6c74b3ddde0@github.com> Message-ID: On Fri, 16 Jan 2026 17:41:39 GMT, Frederic Parain wrote: >> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1212: >> >>> 1210: _null_free_non_atomic_layout_alignment = _payload_alignment; >>> 1211: } >>> 1212: if (UseNullableValueFlattening) { >> >> Could this be else if (UseNullableValueFlattening)? These are mutually exclusive iirc so the else if would make that explicit. > > They are not mutually exclusive. Each layout can be enabled/disabled individually, mostly for testing/debugging purpose. okay. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2699643418 From jlahoda at openjdk.org Fri Jan 16 19:08:48 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 16 Jan 2026 19:08:48 GMT Subject: Integrated: Fixing null restricted types for fields/methods in compact source files. In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 21:21:32 GMT, Jan Lahoda wrote: > The null restricted types don't seem to be supported for top-level fields/methods in compact source files: > > $ cat /tmp/Compact.java > String! s = ""; > void main() { > } > $ ./build/linux-x86_64-server-release/jdk/bin/javac --enable-preview --source 27 /tmp/Compact.java > /tmp/Compact.java:1: error: null restriction not supported in this type context > String! s = ""; > ^ > 1 error > > > This is a simple patch to fix that (removing the `unannotatedType(boolean)` method, as that is no longer used, to my knowledge. But it can be preserved, if preferred. This pull request has now been integrated. Changeset: 1c920be6 Author: Jan Lahoda Committer: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/1c920be6b1437741b7ec5f7f1bcbaa89e524cbaf Stats: 23 lines in 2 files changed: 18 ins; 4 del; 1 mod Fixing null restricted types for fields/methods in compact source files. Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1916 From jlahoda at openjdk.org Fri Jan 16 19:09:51 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 16 Jan 2026 19:09:51 GMT Subject: Integrated: Support for null-restricted types in JShell In-Reply-To: References: Message-ID: <3-RVa_yqGXvJbOruoRUG5BB6QhMmEomY8r57rYJPS_A=.b8e0e4da-4cc4-46e4-991e-e28ef9798969@github.com> On Fri, 16 Jan 2026 15:45:02 GMT, Jan Lahoda wrote: > Base on mcimadamore's idea of desugaring like: > > String! str = init; > => > class JShellClass { > public static class Holder { > public static String! str = init; > } > static Object do_it$() { > return Holder.str; > } > } This pull request has now been integrated. Changeset: 12ea2fa7 Author: Jan Lahoda Committer: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/12ea2fa726e6eb7b2906ac4af5a7455f1c57282a Stats: 117 lines in 5 files changed: 73 ins; 23 del; 21 mod Support for null-restricted types in JShell Co-authored-by: Maurizio Cimadamore Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1925 From darcy at openjdk.org Fri Jan 16 19:15:43 2026 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 16 Jan 2026 19:15:43 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v2] In-Reply-To: References: Message-ID: > A refinement of some earlier ideas on the numerics modeling interfaces to inform further discussions. > > This is a "lumpy" rather than "splitty" design in terms of favoring a smaller number of interfaces with more functionality rather than a larger number of interfaces making smaller distinctions. > > Various design comments and to-do's noted in the code. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Improve divide specifications. ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1917/files - new: https://git.openjdk.org/valhalla/pull/1917/files/0b633368..9a508b04 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1917&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1917&range=00-01 Stats: 49 lines in 2 files changed: 47 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1917.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1917/head:pull/1917 PR: https://git.openjdk.org/valhalla/pull/1917 From matsaave at openjdk.org Fri Jan 16 19:20:23 2026 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 16 Jan 2026 19:20:23 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod Message-ID: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. ------------- Commit messages: - More cleanup - Cleanup - Merge branch 'lworld' into substitutability_cds - Changed SubstitutabilityTest - Regenerate acmp_maps at runtime with metadata copy - Test fixes and exclude inline klasses from dynamic archive - Unproblemlist SubstitutabilityTest - Merge branch 'lworld' into substitutability_cds - Allow heap dumping for statics in value classes - Exclude null_reset from heap verifier checks - ... and 1 more: https://git.openjdk.org/valhalla/compare/a3e60b81...9386c4a9 Changes: https://git.openjdk.org/valhalla/pull/1903/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1903&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374729 Stats: 121 lines in 13 files changed: 93 ins; 21 del; 7 mod Patch: https://git.openjdk.org/valhalla/pull/1903.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1903/head:pull/1903 PR: https://git.openjdk.org/valhalla/pull/1903 From coleenp at openjdk.org Fri Jan 16 19:55:31 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 16 Jan 2026 19:55:31 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod In-Reply-To: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: On Wed, 14 Jan 2026 15:05:24 GMT, Matias Saavedra Silva wrote: > The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. > > Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. > > Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. This looks good but I have a couple of small comments. src/hotspot/share/cds/aotConstantPoolResolver.cpp line 324: > 322: is_static = " *** static"; > 323: break; > 324: if you restore this blank line, there are no changes to aotConstantPoolResolver.cpp. src/hotspot/share/cds/cdsHeapVerifier.cpp line 312: > 310: // Any concrete value class will have a field ".null_reset" which holds an > 311: // all-zero instance of the value class so it will not change between > 312: // dump time and runtime. I'm not sure how this comment about the .null_reset value applies in this if statement? It doesn't seem related to the LIMITATION comment above and there doesn't seem to be anything special done for null reset here either. src/hotspot/share/cds/heapShared.cpp line 2004: > 2002: Symbol* name = subgraph_k->name(); > 2003: > 2004: if (subgraph_k->is_identity_class() && This seems like it's changed the meaning of this if statement. if it's an instance_klass or not an identity class, then it'll miss an instance klass of with the name Foo that shouldn't be archived. Is this the whitelist of klass types of heap objects that are archived in the heap? src/hotspot/share/classfile/classFileParser.cpp line 5558: > 5556: map_h->int_at_put(i * 2 + 2, _layout_info->_nonoop_acmp_map->at(i).second); > 5557: > 5558: _acmp_maps_array->at_put(i * 2 + 1, _layout_info->_nonoop_acmp_map->at(i).first); Suggestion: // Also store acmp maps as metadata for regeneration when using dynamic archive or AOT training data. _acmp_maps_array->at_put(i * 2 + 1, _layout_info->_nonoop_acmp_map->at(i).first); src/hotspot/share/classfile/classFileParser.cpp line 5571: > 5569: > 5570: // Clear out this field so it doesn't get deallocated by the destructor > 5571: _acmp_maps_array = nullptr; This is right. It didn't look necessary but it is if oopFactory::new_intArray() throws an OOM. You could remove this field from ClassFileParser and this handling, and make it a local variable if you reverse lines 5549 and 5550. src/hotspot/share/oops/instanceKlass.cpp line 3142: > 3140: constants()->restore_unshareable_info(CHECK); > 3141: > 3142: // restore acmp_maps java array from the version stored in metadata Can you capitalize Restore and end the sentence with a period? ------------- PR Review: https://git.openjdk.org/valhalla/pull/1903#pullrequestreview-3672423018 PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2699775490 PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2699732522 PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2699744867 PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2699754083 PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2699757647 PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2699770231 From vromero at openjdk.org Fri Jan 16 20:15:38 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 20:15:38 GMT Subject: RFR: add use site null checks for fields Message-ID: generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations [1] https://github.com/openjdk/valhalla/pull/1910 ------------- Commit messages: - minor fix - add use site null checks for fields Changes: https://git.openjdk.org/valhalla/pull/1926/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=00 Stats: 42 lines in 3 files changed: 38 ins; 0 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1926.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1926/head:pull/1926 PR: https://git.openjdk.org/valhalla/pull/1926 From fparain at openjdk.org Fri Jan 16 20:20:16 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 16 Jan 2026 20:20:16 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod In-Reply-To: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: On Wed, 14 Jan 2026 15:05:24 GMT, Matias Saavedra Silva wrote: > The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. > > Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. > > Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. src/hotspot/share/cds/heapShared.cpp line 826: > 824: // Only concrete value classes need the null_reset field > 825: InlineKlass* ilk = InlineKlass::cast(k); > 826: if (ilk->has_nullable_atomic_layout()) { If PR https://github.com/openjdk/valhalla/pull/1407 is pushed before this PR, this test will have to be changed to if (ilk->supports_nullable_layouts()) { ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2699848641 From fparain at openjdk.org Fri Jan 16 20:39:17 2026 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 16 Jan 2026 20:39:17 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod In-Reply-To: References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: On Fri, 16 Jan 2026 19:44:03 GMT, Coleen Phillimore wrote: >> The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. >> >> Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. >> >> Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. > > src/hotspot/share/classfile/classFileParser.cpp line 5571: > >> 5569: >> 5570: // Clear out this field so it doesn't get deallocated by the destructor >> 5571: _acmp_maps_array = nullptr; > > This is right. It didn't look necessary but it is if oopFactory::new_intArray() throws an OOM. > > You could remove this field from ClassFileParser and this handling, and make it a local variable if you reverse lines 5549 and 5550. +1 to use a local variable. It looks weird to have this _acmp_maps_array field in ClassFilerParser whose content's ownership is not transferred to the InstanceKlass using the apply_parsed_class_metadata() method. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2699890402 From darcy at openjdk.org Fri Jan 16 20:50:42 2026 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 16 Jan 2026 20:50:42 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v3] In-Reply-To: References: Message-ID: > A refinement of some earlier ideas on the numerics modeling interfaces to inform further discussions. > > This is a "lumpy" rather than "splitty" design in terms of favoring a smaller number of interfaces with more functionality rather than a larger number of interfaces making smaller distinctions. > > Various design comments and to-do's noted in the code. Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Add default methods. - Respond to review feedback; add default methods. ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1917/files - new: https://git.openjdk.org/valhalla/pull/1917/files/9a508b04..1a1713ec Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1917&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1917&range=01-02 Stats: 93 lines in 2 files changed: 76 ins; 0 del; 17 mod Patch: https://git.openjdk.org/valhalla/pull/1917.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1917/head:pull/1917 PR: https://git.openjdk.org/valhalla/pull/1917 From darcy at openjdk.org Fri Jan 16 20:50:44 2026 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 16 Jan 2026 20:50:44 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v3] In-Reply-To: References: Message-ID: <4Y-hsfy5bCqFQ3AsZeoek5rgBBn-EOHKZlC4awYnBfc=.a161a05b-e3ba-40b5-a844-93df1bbfe700@github.com> On Fri, 16 Jan 2026 18:17:10 GMT, Joe Darcy wrote: > I wasn't sure if min/max should be included in the interface. I think it depends what role any non-operator methods have in interfaces intended for witnesses. > > However, as long as the methods are here, they could be default methods, yes. > > To acknowledge some feedback received on a different channel, if the OC type variable were required to extend Comparable, then all the lessThan, greaterThan, etc. method could have default methods written in terms of the results of compareTo. However, if we want to move away from Comparable, then extended its usage here probably isn't a good idea. PS Pushed another changeset refactoring to have less than be the base operation and using default methods for the rest. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1917#discussion_r2699924593 From matsaave at openjdk.org Fri Jan 16 21:06:17 2026 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 16 Jan 2026 21:06:17 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod In-Reply-To: References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: On Fri, 16 Jan 2026 19:34:52 GMT, Coleen Phillimore wrote: >> The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. >> >> Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. >> >> Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. > > src/hotspot/share/cds/cdsHeapVerifier.cpp line 312: > >> 310: // Any concrete value class will have a field ".null_reset" which holds an >> 311: // all-zero instance of the value class so it will not change between >> 312: // dump time and runtime. > > I'm not sure how this comment about the .null_reset value applies in this if statement? It doesn't seem related to the LIMITATION comment above and there doesn't seem to be anything special done for null reset here either. Without the if statement, we'd see an error stating that a class has a static field whose value may differ between dumptime and runtime, specifically referring to `.null_reset`. This is currently the only case to cause any issues so I figured mentioning it in a comment would be useful. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2699958125 From matsaave at openjdk.org Fri Jan 16 21:17:56 2026 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 16 Jan 2026 21:17:56 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v2] In-Reply-To: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: > The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. > > Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. > > Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Coleen and Fred comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1903/files - new: https://git.openjdk.org/valhalla/pull/1903/files/9386c4a9..4a035702 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1903&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1903&range=00-01 Stats: 19 lines in 4 files changed: 2 ins; 9 del; 8 mod Patch: https://git.openjdk.org/valhalla/pull/1903.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1903/head:pull/1903 PR: https://git.openjdk.org/valhalla/pull/1903 From coleenp at openjdk.org Fri Jan 16 21:29:51 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 16 Jan 2026 21:29:51 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v2] In-Reply-To: References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: <5tWaVxUyEd9Tg1BtzdFtUcvYXfYb7RodMd-pUQQQyXM=.927e3611-47bb-475d-85db-c8a089f93a0d@github.com> On Fri, 16 Jan 2026 19:39:17 GMT, Coleen Phillimore wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Coleen and Fred comments > > src/hotspot/share/cds/heapShared.cpp line 2004: > >> 2002: Symbol* name = subgraph_k->name(); >> 2003: >> 2004: if (subgraph_k->is_identity_class() && > > This seems like it's changed the meaning of this if statement. if it's an instance_klass or not an identity class, then it'll miss an instance klass of with the name Foo that shouldn't be archived. Is this the whitelist of klass types of heap objects that are archived in the heap? I read this as 'inline' not 'identity' but it says 'identity'. nvm. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2700011637 From amenkov at openjdk.org Fri Jan 16 22:07:17 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 16 Jan 2026 22:07:17 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v3] In-Reply-To: References: Message-ID: > Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. > Added the test for value object ctor debugging, the test verifies the behaviour is expected. > There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) > > testing: tier1..4, hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: test update ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1834/files - new: https://git.openjdk.org/valhalla/pull/1834/files/e74a4cff..34c9c2bd Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1834&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1834&range=01-02 Stats: 37 lines in 1 file changed: 23 ins; 1 del; 13 mod Patch: https://git.openjdk.org/valhalla/pull/1834.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1834/head:pull/1834 PR: https://git.openjdk.org/valhalla/pull/1834 From amenkov at openjdk.org Fri Jan 16 22:11:21 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 16 Jan 2026 22:11:21 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v4] In-Reply-To: References: Message-ID: > Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. > Added the test for value object ctor debugging, the test verifies the behaviour is expected. > There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) > > testing: tier1..4, hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: space ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1834/files - new: https://git.openjdk.org/valhalla/pull/1834/files/34c9c2bd..55ba1462 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1834&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1834&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1834.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1834/head:pull/1834 PR: https://git.openjdk.org/valhalla/pull/1834 From vromero at openjdk.org Fri Jan 16 22:12:06 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 22:12:06 GMT Subject: RFR: add use site null checks for fields [v2] In-Reply-To: References: Message-ID: > generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations > > [1] https://github.com/openjdk/valhalla/pull/1910 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: updated code ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1926/files - new: https://git.openjdk.org/valhalla/pull/1926/files/895ba42a..0fd2f2d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=00-01 Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1926.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1926/head:pull/1926 PR: https://git.openjdk.org/valhalla/pull/1926 From amenkov at openjdk.org Fri Jan 16 22:23:08 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 16 Jan 2026 22:23:08 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 03:19:45 GMT, Chris Plummer wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> ClassTypeImpl.isValueClass, VirtualMachineImpl.canUseIsSameObject > > src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 177: > >> 175: @Override >> 176: public int hashCode() { >> 177: if (isValueObject() && vm.canUseIsSameObject()) { > > I don't see how this logic can be correct for value objects if vm.canUseIsSameObject() returns false. We still have a value object in that case. Is using Long.hashCode(ref()) the right thing to do? Same thing applies to equals() above. I think if a JVM supports value objects then the debug agent has to support IsSameObject and HashCode. The version check should really only be in regard to whether or not value objects are supported in general by the JVM, because if they are they have to be supported by the debug agent. We should execute jdwp command only when it's available (vm.canUseIsSameObject returns true) and the object is value object. Note that isValueObject() may not work for old releases, so we need to check both conditions here or move version check to ClassTypeImpl.isValueClass ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2700160016 From vromero at openjdk.org Fri Jan 16 22:24:23 2026 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Jan 2026 22:24:23 GMT Subject: RFR: add use site null checks for fields [v3] In-Reply-To: References: Message-ID: > generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations > > [1] https://github.com/openjdk/valhalla/pull/1910 Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: - remove unused field - code changes ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1926/files - new: https://git.openjdk.org/valhalla/pull/1926/files/0fd2f2d9..bf2bd482 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=01-02 Stats: 47 lines in 1 file changed: 15 ins; 21 del; 11 mod Patch: https://git.openjdk.org/valhalla/pull/1926.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1926/head:pull/1926 PR: https://git.openjdk.org/valhalla/pull/1926 From amenkov at openjdk.org Fri Jan 16 22:25:45 2026 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 16 Jan 2026 22:25:45 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v4] In-Reply-To: References: Message-ID: <9Ml5XmhHl5qRZ65qx14CiP5uDEeEtGRvS_j9xk9cpkI=.7fae03f4-1c15-4067-82df-498cc20c4b8a@github.com> On Wed, 14 Jan 2026 04:43:46 GMT, Chris Plummer wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> space > > test/jdk/com/sun/jdi/valhalla/CtorDebuggingTest.java line 69: > >> 67: import com.sun.jdi.request.EventRequestManager; >> 68: >> 69: public class CtorDebuggingTest extends TestScaffold { > > I think this test would benefit from more comments. It would be good to describe all the scenarios being tested, probably in one main comment block early on, and then for implementation of each scenario add a one line comment indicating which scenarios is being tested. Added some comments ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2700169775 From liach at openjdk.org Fri Jan 16 23:10:52 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 16 Jan 2026 23:10:52 GMT Subject: RFR: add use site null checks for fields [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:24:23 GMT, Vicente Romero wrote: >> generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations >> >> [1] https://github.com/openjdk/valhalla/pull/1910 > > Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: > > - remove unused field > - code changes Marked as reviewed by liach (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1926#pullrequestreview-3673119009 From jrose at openjdk.org Sat Jan 17 00:03:45 2026 From: jrose at openjdk.org (John R Rose) Date: Sat, 17 Jan 2026 00:03:45 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v3] In-Reply-To: <4Y-hsfy5bCqFQ3AsZeoek5rgBBn-EOHKZlC4awYnBfc=.a161a05b-e3ba-40b5-a844-93df1bbfe700@github.com> References: <4Y-hsfy5bCqFQ3AsZeoek5rgBBn-EOHKZlC4awYnBfc=.a161a05b-e3ba-40b5-a844-93df1bbfe700@github.com> Message-ID: On Fri, 16 Jan 2026 20:47:13 GMT, Joe Darcy wrote: >> I wasn't sure if min/max should be included in the interface. I think it depends what role any non-operator methods have in interfaces intended for witnesses. >> >> However, as long as the methods are here, they could be default methods, yes. >> >> To acknowledge some feedback received on a different channel, if the OC type variable were required to extend Comparable, then all the lessThan, greaterThan, etc. method could have default methods written in terms of the results of compareTo. However, if we want to move away from Comparable, then extended its usage here probably isn't a good idea. > >> I wasn't sure if min/max should be included in the interface. I think it depends what role any non-operator methods have in interfaces intended for witnesses. >> >> However, as long as the methods are here, they could be default methods, yes. >> >> To acknowledge some feedback received on a different channel, if the OC type variable were required to extend Comparable, then all the lessThan, greaterThan, etc. method could have default methods written in terms of the results of compareTo. However, if we want to move away from Comparable, then extended its usage here probably isn't a good idea. > > PS Pushed another changeset refactoring to have less than be the base operation and using default methods for the rest. I?m not sure what the intended design rules are here, but for anything algebraic, fewer axioms are much better than more (murkily related) axioms. Having many abstract interface points is the same as many axioms ? the witnesses each have their own story for each API point independently. The default method approach is very wise, and the body of the default should be in an implnote in the docs. It amounts to a proof that shows how to (e.g.) deduce min and max from lower-level axioms. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1917#discussion_r2700355622 From jrose at openjdk.org Sat Jan 17 00:06:58 2026 From: jrose at openjdk.org (John R Rose) Date: Sat, 17 Jan 2026 00:06:58 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 20:50:42 GMT, Joe Darcy wrote: >> A refinement of some earlier ideas on the numerics modeling interfaces to inform further discussions. >> >> This is a "lumpy" rather than "splitty" design in terms of favoring a smaller number of interfaces with more functionality rather than a larger number of interfaces making smaller distinctions. >> >> Various design comments and to-do's noted in the code. > > Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: > > - Add default methods. > - Respond to review feedback; add default methods. I would prefer to see the ordering part tolerating partial orders (NaNs), and then factor the ordering part on top of both ints and floats. Also, in the name of reducing primitives, I think a `compare(x,y)` method is the correct primitive. It would return one of "lt", "gt", "eq", and (only for FP orders) "uo". All the others, up to min/max, can be built on top as default methods, even if they also end up hardwired to an override, for efficiency. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1917#issuecomment-3762263924 From liach at openjdk.org Sat Jan 17 00:17:58 2026 From: liach at openjdk.org (Chen Liang) Date: Sat, 17 Jan 2026 00:17:58 GMT Subject: RFR: Minor cleanup, preview and since Message-ID: Add a preview feature for the NR jep, other stylistic cleanup ------------- Commit messages: - Minor cleanup, preview and since Changes: https://git.openjdk.org/valhalla/pull/1927/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1927&range=00 Stats: 15 lines in 4 files changed: 8 ins; 2 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1927.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1927/head:pull/1927 PR: https://git.openjdk.org/valhalla/pull/1927 From jrose at openjdk.org Sat Jan 17 00:27:09 2026 From: jrose at openjdk.org (John R Rose) Date: Sat, 17 Jan 2026 00:27:09 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 20:50:42 GMT, Joe Darcy wrote: >> A refinement of some earlier ideas on the numerics modeling interfaces to inform further discussions. >> >> This is a "lumpy" rather than "splitty" design in terms of favoring a smaller number of interfaces with more functionality rather than a larger number of interfaces making smaller distinctions. >> >> Various design comments and to-do's noted in the code. > > Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: > > - Add default methods. > - Respond to review feedback; add default methods. interface Orderable { enum Order { LT, GT, EQ, UO }; //or use a couple int-bits /** Return LT if x definitely precedes y. * Return GT if y definitely precedes x. * Return EQ if x and y are equivalent in this particular order * Return UO otherwise * Conformance rules are as follows. * Symmetry: If order(x,y)==LT (resp. GT, EQ, UO) then also order(y,x)==GT (resp. LT, EQ, UO) * Reflexivity: Always order(x,y)==EQ or UO, never GT or LT. * Transitivity: If order(x,y)==LT or EQ and order(y,z)==LT or EQ, then order(x,z)==LT or EQ, but cannot be EQ if both previous were EQ. */ abstract Order order(T x, T y); // This is enough to drive a sort algorithm with care, even though it?s just partial. /** * Returns true if this order never reports UO for any input. * True for integers and anything comparable or having a comparator. * False for FP types (because of NaN elements). * False for partially ordered data types, if not totalized. */ abstract boolean isTotal(); /** * If this returns true for two x and y, then order(x,y) is not UO. */ default boolean isTotal(T x) { return isTotal() || order(x,x) != UO; } // Could do similar query to detect the less interesting case of // orders which are coarser than operator==, but that?s only // true with +0.0 vs. -0.0. default boolean lt(T x, T y) { return order(x,y) == LT; } default boolean le(T x, T y) { return lt(x,y) || eq(x,y); } //... and so forth for gt, ge, eq, ne default boolean min(T x, T y) { return lt(x,y) ? x : y; } //... and so forth } ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1917#issuecomment-3762325873 From liach at openjdk.org Sat Jan 17 00:34:53 2026 From: liach at openjdk.org (Chen Liang) Date: Sat, 17 Jan 2026 00:34:53 GMT Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 22:02:07 GMT, Chen Liang wrote: > Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case. Should I keep TestCompareAndExchange any more? I don't know what's the best way to create a C2 test for this. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1734#issuecomment-3762352873 From liach at openjdk.org Sat Jan 17 00:36:52 2026 From: liach at openjdk.org (Chen Liang) Date: Sat, 17 Jan 2026 00:36:52 GMT Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects [v2] In-Reply-To: References: Message-ID: > Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Fixes, VHTMHAV now passes - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas - A test - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas - Attempt to fix garbage cas ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1734/files - new: https://git.openjdk.org/valhalla/pull/1734/files/88965da5..0b95903f Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1734&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1734&range=00-01 Stats: 156018 lines in 2665 files changed: 100722 ins; 38303 del; 16993 mod Patch: https://git.openjdk.org/valhalla/pull/1734.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1734/head:pull/1734 PR: https://git.openjdk.org/valhalla/pull/1734 From vromero at openjdk.org Sat Jan 17 00:57:25 2026 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 17 Jan 2026 00:57:25 GMT Subject: RFR: add use site null checks for fields [v4] In-Reply-To: References: Message-ID: > generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations > > [1] https://github.com/openjdk/valhalla/pull/1910 Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: - minor change - adding a test ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1926/files - new: https://git.openjdk.org/valhalla/pull/1926/files/bf2bd482..190a1348 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=02-03 Stats: 97 lines in 1 file changed: 92 ins; 0 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1926.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1926/head:pull/1926 PR: https://git.openjdk.org/valhalla/pull/1926 From darcy at openjdk.org Sat Jan 17 01:04:11 2026 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 17 Jan 2026 01:04:11 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v3] In-Reply-To: References: <4Y-hsfy5bCqFQ3AsZeoek5rgBBn-EOHKZlC4awYnBfc=.a161a05b-e3ba-40b5-a844-93df1bbfe700@github.com> Message-ID: On Sat, 17 Jan 2026 00:00:12 GMT, John R Rose wrote: > I?m not sure what the intended design rules are here, but for anything algebraic, fewer axioms are much better than more (murkily related) axioms. Having many abstract interface points is the same as many axioms ? the witnesses each have their own story for each API point independently. > > The default method approach is very wise, and the body of the default should be in an implnote in the docs. It amounts to a proof that shows how to (e.g.) deduce min and max from lower-level axioms. To be precise, for a default method in an interface (unless various special conditions hold*), there should be an impl*Spec* tag (not implNote) that at least documents the general logic and calls to other methods of the interface used in the default method's body. Replicating the full body of the method in the implSpec tag can be acceptable, especially if it is a one-liner, but it is not requited in general. We have multiple examples of this kind of using the JDK APIs, including in javax.lang.model where I'm one of the maintainers. The implSpec tags I included in the changeset to Orderable for it to have default methods follow the general conventions of tag usage for that situation in the JDK. Thanks and HTH. (* The special conditions where an implSpec tag on a default method can be skipped include cases like a default method of a sealed interface where there will be no implementations outside of the shared maintenance domain of the interface.) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1917#discussion_r2700485813 From vromero at openjdk.org Sat Jan 17 01:15:22 2026 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 17 Jan 2026 01:15:22 GMT Subject: RFR: add use site null checks for fields [v5] In-Reply-To: References: Message-ID: > generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations > > [1] https://github.com/openjdk/valhalla/pull/1910 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: changes to test ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1926/files - new: https://git.openjdk.org/valhalla/pull/1926/files/190a1348..5f2f235f Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=04 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=03-04 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1926.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1926/head:pull/1926 PR: https://git.openjdk.org/valhalla/pull/1926 From darcy at openjdk.org Sat Jan 17 01:15:22 2026 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 17 Jan 2026 01:15:22 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v3] In-Reply-To: References: <4Y-hsfy5bCqFQ3AsZeoek5rgBBn-EOHKZlC4awYnBfc=.a161a05b-e3ba-40b5-a844-93df1bbfe700@github.com> Message-ID: On Sat, 17 Jan 2026 01:00:41 GMT, Joe Darcy wrote: > I?m not sure what the intended design rules are here, but for anything algebraic, fewer axioms are much better than more (murkily related) axioms. Having many abstract interface points is the same as many axioms ? the witnesses each have their own story for each API point independently. > > The default method approach is very wise, and the body of the default should be in an implnote in the docs. It amounts to a proof that shows how to (e.g.) deduce min and max from lower-level axioms. One of the implicit design question here is "are these the interfaces that allow operator overloading?" or "are these the interfaces that declare various algebraic properties?" Since many of the numerical types of possible interest are closer to, say, floating-point-like types that have few algebraic properties rather than integer-like types that have more, I don't want to preclude floating-point-like types from participating in operator overloading because of their lack of strong algebraic properties. Matrices/vectors would also fall closer to floating-point-like rather than integer-like and I would not want to preclude matrices/vectors from benefiting from operators. I included a slide in my 2025 JVMLS talk on numerics speculating that a future refinement of these kinds of interfaces could include an idiom to indicate "yes, this type actually obeys the ring axioms" or "... the field axioms", etc., but that is not included in this early "lumpy" iteration. I would fully expect some evolution of the set of interfaces, what methods go where, the set of interfaces, etc. as we can more experience using these trial types with type classes. Thanks. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1917#discussion_r2700497372 From iklam at openjdk.org Sat Jan 17 05:04:51 2026 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 17 Jan 2026 05:04:51 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v2] In-Reply-To: References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: On Fri, 16 Jan 2026 21:17:56 GMT, Matias Saavedra Silva wrote: >> The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. >> >> Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. >> >> Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Coleen and Fred comments src/hotspot/share/oops/instanceKlass.cpp line 3152: > 3150: } > 3151: java_mirror()->obj_field_put(_acmp_maps_offset, map_h()); > 3152: } Is it necessary to restore `null_reset_value()` as well? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2700643477 From dsimms at openjdk.org Sat Jan 17 12:03:15 2026 From: dsimms at openjdk.org (David Simms) Date: Sat, 17 Jan 2026 12:03:15 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge jdk-27+4 ------------- Commit messages: - Merge branch 'lworld' into lworld_merge_jdk_27_4 - Adjust testing - Merge tag 'jdk-27+4' into lworld_merge_jdk_27_4 - 8373833: "error.cert.not.found" and "error.explicit-sign-no-cert" errors duplicate each other - 8374308: ImageBufferCache has no effect and can be removed - 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG - 8374544: Add SleepyCat diagnostics for all platforms - 8374555: No need for visible input warning in s.s.u.Password when not reading from System.in - 8374190: Convert ConcurrentHashTable atomic lists to use Atomic - 6562639: Wrong pixel bounds from TextLayout with white font - ... and 111 more: https://git.openjdk.org/valhalla/compare/a3e60b81...970129c8 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1928&range=00.0 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1928&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1928/files Stats: 22912 lines in 2476 files changed: 5548 ins; 2614 del; 14750 mod Patch: https://git.openjdk.org/valhalla/pull/1928.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1928/head:pull/1928 PR: https://git.openjdk.org/valhalla/pull/1928 From brian.goetz at oracle.com Sat Jan 17 14:03:00 2026 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 17 Jan 2026 09:03:00 -0500 Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v3] In-Reply-To: References: <4Y-hsfy5bCqFQ3AsZeoek5rgBBn-EOHKZlC4awYnBfc=.a161a05b-e3ba-40b5-a844-93df1bbfe700@github.com> Message-ID: <57e067c3-a633-4396-8243-1443f0554825@oracle.com> Overall I agree with the direction that while we should be _inspired by_ algebraic structures, we should not slavishly adhere to them, because these are not platonic numbers, and they fail to obey the algebraic axioms in all sorts of ways. I think we can borrow much hard-won experience from our friends in the Haskell community.? For example, `Num a` defines both (+) and (*), and suggests the existence of additive and multiplicative identities, but appeals not to ring-ness but to something more like "be reasonable".? Specifically, it says "looks like a ring, lots of Nums are rings, but actually requiring it would be too restrictive."? And despite the seeming complexity of the Haskell numeric tower, there is much (sensible) lumping going on in the base Num class.? (All of these properties seem like candidates for shameless stealing.) Haskell also relegates the algebraic structure (ring, monoid, etc) to a different corner of the field (heh), separate from the types describing numerics, and doesn't attempt to use symbolic operators, instead using nominal functions like `mzero`. The point about implementing both `Num` and `Ord` is one of those "obvious not obvious" statements; given that an ordered ring includes additional axioms above the union of the ring and ordering axioms, it would not be reasonable to expect "witnesses Ord" and "witnesses Ring" to mean "witnesses OrderedRing".? Instead, one would need an OrderedRing type class, which extends Ord and Eq, and adds additional laws. > The Haskell Report defines no laws for |Num > |. > However, |(|+ > |)| > and |(|* > |)| > are customarily expected to define a ring and have the following > properties: > > *Associativity of |(|+ > |)|* > |(x + y) + z| = |x + (y + z)| > *Commutativity of |(|+ > |)|* > |x + y| = |y + x| > *||fromInteger > | > 0| is the additive identity* > |x + fromInteger 0| = |x| > *|negate > | > gives the additive inverse* > |x + negate x| = |fromInteger 0| > *Associativity of |(|* > |)|* > |(x * y) * z| = |x * (y * z)| > *||fromInteger > | > 1| is the multiplicative identity* > |x * fromInteger 1| = |x| and |fromInteger 1 * x| = |x| > *Distributivity of |(|* > |)| > with respect to |(|+ > |)|* > |a * (b + c)| = |(a * b) + (a * c)| and |(b + c) * a| = |(b * a) + > (c * a)| > *Coherence with |toInteger|* > if the type also implements |Integral > |, > then |fromInteger > | > is a left inverse for |toInteger > |, > i.e. |fromInteger (toInteger i) == i| > > Note that it /isn't/ customarily expected that a type instance of both > |Num > | > and |Ord > | > implement an ordered ring. Indeed, in |base| only |Integer > | > and |Rational > | > do. > > One of the implicit design question here is "are these the interfaces that allow operator overloading?" or "are these the interfaces that declare various algebraic properties?" > > Since many of the numerical types of possible interest are closer to, say, floating-point-like types that have few algebraic properties rather than integer-like types that have more, I don't want to preclude floating-point-like types from participating in operator overloading because of their lack of strong algebraic properties. Matrices/vectors would also fall closer to floating-point-like rather than integer-like and I would not want to preclude matrices/vectors from benefiting from operators. > > I included a slide in my 2025 JVMLS talk on numerics speculating that a future refinement of these kinds of interfaces could include an idiom to indicate "yes, this type actually obeys the ring axioms" or "... the field axioms", etc., but that is not included in this early "lumpy" iteration. > > I would fully expect some evolution of the set of interfaces, what methods go where, the set of interfaces, etc. as we can more experience using these trial types with type classes. > > Thanks. > > ------------- > > PR Review Comment:https://git.openjdk.org/valhalla/pull/1917#discussion_r2700497372 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsimms at openjdk.org Sat Jan 17 14:16:55 2026 From: dsimms at openjdk.org (David Simms) Date: Sat, 17 Jan 2026 14:16:55 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 11:56:54 GMT, David Simms wrote: > Merge jdk-27+4 This pull request has now been integrated. Changeset: e10b1db1 Author: David Simms URL: https://git.openjdk.org/valhalla/commit/e10b1db180cbe41214a112d63fe5a526c4d1d981 Stats: 22912 lines in 2476 files changed: 5548 ins; 2614 del; 14750 mod Merge Merge jdk-27+4 ------------- PR: https://git.openjdk.org/valhalla/pull/1928 From dsimms at openjdk.org Sat Jan 17 14:25:18 2026 From: dsimms at openjdk.org (David Simms) Date: Sat, 17 Jan 2026 14:25:18 GMT Subject: git: openjdk/valhalla: lworld: 119 new changesets Message-ID: <8c3a52fd-8e19-4316-8142-688b0888c8fd@openjdk.org> Changeset: 2ba423db Branch: lworld Author: Roland Westrelin Date: 2025-12-18 10:36:16 +0000 URL: https://git.openjdk.org/valhalla/commit/2ba423db9925355348106fc9fcf84450123d2605 8370200: Crash: assert(outer->outcnt() >= phis + 2 - be_loads && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis Reviewed-by: rcastanedalo, dlunden, dfenacci ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp + test/hotspot/jtreg/compiler/c2/TestReplaceNarrowPhiWithBottomPhi.java + test/hotspot/jtreg/compiler/loopstripmining/TestMismatchedMemoryPhis.java Changeset: 2c0d9a79 Branch: lworld Author: Galder Zamarre?o Committer: Roland Westrelin Date: 2025-12-18 11:45:26 +0000 URL: https://git.openjdk.org/valhalla/commit/2c0d9a79b8197d88a104bd77026dd45b83a11f8a 8373396: Min and Max Ideal missing AddNode::Ideal optimisations Reviewed-by: epeter, roland ! src/hotspot/share/opto/addnode.cpp + test/hotspot/jtreg/compiler/igvn/TestMinMaxIdeal.java Changeset: 629e4ac6 Branch: lworld Author: Volkan Yazici Date: 2025-12-18 12:46:02 +0000 URL: https://git.openjdk.org/valhalla/commit/629e4ac6f45c87898f6a014f28a443c800413869 8372661: Add a null-safe static factory method to "jdk.test.lib.net.SimpleSSLContext" Reviewed-by: dfuchs, weijun ! test/lib/jdk/test/lib/net/SimpleSSLContext.java Changeset: 3258e4da Branch: lworld Author: Raffaello Giulietti Date: 2025-12-18 13:09:42 +0000 URL: https://git.openjdk.org/valhalla/commit/3258e4dafa85b2347c7640b0fd87197959cabea2 8373068: Revisit details of Float16 to decimal conversion algorithm Reviewed-by: darcy ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java Changeset: b848ddf6 Branch: lworld Author: Yasumasa Suenaga Date: 2025-12-18 13:15:36 +0000 URL: https://git.openjdk.org/valhalla/commit/b848ddf6d3bf4e76d409b03be7f36199dadb2c5f 8373110: jstack --mixed frames are broken on macOS after JDK-8371194 Reviewed-by: cjplummer, kevinw ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java Changeset: 7a7e7c9a Branch: lworld Author: Daniel Jeli?ski Date: 2025-12-18 13:17:44 +0000 URL: https://git.openjdk.org/valhalla/commit/7a7e7c9ae11cb124c14d5d2d3b7e2f5649205106 8373877: QUIC connections are removed too early Reviewed-by: dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/quic/ConnectionTerminatorImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicConnectionImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java ! test/jdk/java/net/httpclient/quic/StatelessResetReceiptTest.java Changeset: 0b271240 Branch: lworld Author: Dan Smith Date: 2025-12-18 17:21:41 +0000 URL: https://git.openjdk.org/valhalla/commit/0b2712400b55d4a512db225d090c2f06f01f7f1f 8373909: JSpec and ToolGuide taglets use incorrect relative path Reviewed-by: liach, hannesw ! make/Docs.gmk ! make/jdk/src/classes/build/tools/taglet/JSpec.java ! make/jdk/src/classes/build/tools/taglet/ToolGuide.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java Changeset: 6cbfc769 Branch: lworld Author: Dan Smith Date: 2025-12-18 19:31:33 +0000 URL: https://git.openjdk.org/valhalla/commit/6cbfc7691f8d3171cf223977b0b94e5f25fed93d 8370249: Test jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails due to JVMS/JLS links after JDK-8349681 Reviewed-by: liach ! test/docs/ProblemList.txt Changeset: 8a93658e Branch: lworld Author: Nityanand Rai Committer: Paul Hohensee Date: 2025-12-18 21:15:44 +0000 URL: https://git.openjdk.org/valhalla/commit/8a93658e87e2e2f344d7dbfa6f916bd28175d013 8371284: GenShen: Avoid unnecessary card marking Reviewed-by: wkemper, shade, ysr ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp Changeset: f88cbfb8 Branch: lworld Author: Dan Smith Date: 2025-12-18 21:40:06 +0000 URL: https://git.openjdk.org/valhalla/commit/f88cbfb8c6b320f773f8d8c3cdf2598d117c5521 8374044: Docs build fails: Cannot determine current path Reviewed-by: dholmes ! make/Docs.gmk Changeset: 62316465 Branch: lworld Author: Kim Barrett Date: 2025-12-19 00:01:55 +0000 URL: https://git.openjdk.org/valhalla/commit/623164651cd35870aa438a3f6d546994f3d1753c 8373208: Make Atomic class template constant initializable Reviewed-by: stefank, dholmes ! src/hotspot/share/runtime/atomic.hpp Changeset: f0add885 Branch: lworld Author: David Holmes Date: 2025-12-19 01:54:10 +0000 URL: https://git.openjdk.org/valhalla/commit/f0add8854501f13b611220804dcb54d118c43717 8373837: "assert(thread->is_VM_thread() || thread->is_Java_thread()) failed: Must be VMThread or JavaThread" on macosx-aarch64-26 Reviewed-by: fbredberg, coleenp ! src/hotspot/os/posix/signals_posix.cpp Changeset: 360777c3 Branch: lworld Author: SendaoYan Date: 2025-12-19 02:22:06 +0000 URL: https://git.openjdk.org/valhalla/commit/360777c3ad8fe5bfeb2af15ce1b89e04d4397b9f 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64 Reviewed-by: dholmes, aph ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp ! test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: e72f205a Branch: lworld Author: Roland Westrelin Date: 2025-12-19 08:31:04 +0000 URL: https://git.openjdk.org/valhalla/commit/e72f205ae312b15ebab0cbeedb73bbf86e485251 8373524: C2: no reachable node should have no use Reviewed-by: chagedorn, mhaessig ! src/hotspot/share/opto/cfgnode.cpp + test/hotspot/jtreg/compiler/igvn/TestNodeWithNoUseAfterPhiIdeal.java Changeset: 5eb87749 Branch: lworld Author: Hamlin Li Date: 2025-12-19 09:19:46 +0000 URL: https://git.openjdk.org/valhalla/commit/5eb8774909bd250c7ff8cfc56506a949b547bda2 8373998: RISC-V: simple optimization of ConvHF2F Co-authored-by: Fei Yang Reviewed-by: fyang, dzhang ! src/hotspot/cpu/riscv/riscv.ad Changeset: 45cf0420 Branch: lworld Author: Jaikiran Pai Date: 2025-12-19 09:30:41 +0000 URL: https://git.openjdk.org/valhalla/commit/45cf042099aa64a94574d21cce0bdde215abf07b 8374082: net_util.c should use logical && when setting IPv6_available Reviewed-by: alanb ! src/java.base/share/native/libnet/net_util.c Changeset: 53e77d21 Branch: lworld Author: Stefan Karlsson Date: 2025-12-19 10:52:43 +0000 URL: https://git.openjdk.org/valhalla/commit/53e77d21c2308daad7d4aecf05da56609ed0291c 8373801: Adopt arraycopy OopCopyResult from the lworld branch Reviewed-by: jsikstro, tschatzl, aboldtch ! src/hotspot/share/gc/shared/barrierSet.hpp ! src/hotspot/share/gc/shared/barrierSet.inline.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/z/zBarrierSet.hpp ! src/hotspot/share/gc/z/zBarrierSet.inline.hpp ! src/hotspot/share/oops/access.hpp ! src/hotspot/share/oops/access.inline.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/oops/objArrayKlass.cpp Changeset: 14c93b2a Branch: lworld Author: Volkan Yazici Date: 2025-12-19 12:57:57 +0000 URL: https://git.openjdk.org/valhalla/commit/14c93b2afbf0135e872866c7f8468d9ce6df1e0d 8373537: Migrate "test/jdk/com/sun/net/httpserver/" to null-safe "SimpleSSLContext" methods Reviewed-by: dfuchs ! test/jdk/com/sun/net/httpserver/HttpsParametersClientAuthTest.java ! test/jdk/com/sun/net/httpserver/SANTest.java ! test/jdk/com/sun/net/httpserver/SelCacheTest.java ! test/jdk/com/sun/net/httpserver/Test1.java ! test/jdk/com/sun/net/httpserver/Test12.java ! test/jdk/com/sun/net/httpserver/Test13.java ! test/jdk/com/sun/net/httpserver/Test6a.java ! test/jdk/com/sun/net/httpserver/Test7a.java ! test/jdk/com/sun/net/httpserver/Test8a.java ! test/jdk/com/sun/net/httpserver/Test9.java ! test/jdk/com/sun/net/httpserver/Test9a.java ! test/jdk/com/sun/net/httpserver/bugs/HandlerConnectionClose.java ! test/jdk/com/sun/net/httpserver/simpleserver/HttpsServerAlertTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/HttpsServerTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java Changeset: 45642acf Branch: lworld Author: Alexey Semenyuk Date: 2025-12-19 13:03:21 +0000 URL: https://git.openjdk.org/valhalla/commit/45642acf1b290306509375e58bde8f6c9cd1b308 8373710: Improve jpackage error reporting Reviewed-by: almatvee ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/SigningIdentityBuilder.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Main.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/model/WinApplicationMixin.java ! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java Changeset: b5ac8f83 Branch: lworld Author: Christoph Langer Date: 2025-12-19 13:34:31 +0000 URL: https://git.openjdk.org/valhalla/commit/b5ac8f83682ddb9623a1b43bd62f309b2961a504 8373246: JDK-8351842 broke native debugging on Linux Reviewed-by: erikj, stuefe ! make/Bundles.gmk ! make/CreateJmods.gmk ! make/autoconf/jdk-options.m4 Changeset: dca55b43 Branch: lworld Author: Matthias Baesken Date: 2025-12-19 14:28:04 +0000 URL: https://git.openjdk.org/valhalla/commit/dca55b43664bb9f15ebd7b5f674e1a64b5c17c02 8371420: Still sporadic failures of gc/TestAlwaysPreTouchBehavior.java# on Linux after JDK-8359104 Reviewed-by: mdoerr, ayang ! test/hotspot/jtreg/gc/TestAlwaysPreTouchBehavior.java Changeset: 6c9999ca Branch: lworld Author: Matthias Baesken Date: 2025-12-19 14:37:42 +0000 URL: https://git.openjdk.org/valhalla/commit/6c9999ca8d0722bfb3a945dd4bea666eb4a028cc 8373984: Check for macos 11 in CGraphicsDevice.m can be removed Reviewed-by: prr, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m Changeset: 821e9ff9 Branch: lworld Author: Jorn Vernee Date: 2025-12-19 17:38:30 +0000 URL: https://git.openjdk.org/valhalla/commit/821e9ff965cad52cdd26c08785312db49bcce539 8372493: [asan] java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java triggers heap-use-after-free Reviewed-by: liach ! test/jdk/java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java ! test/jdk/java/foreign/sharedclosejvmti/libSharedCloseAgent.cpp Changeset: 23fc21a3 Branch: lworld Author: Coleen Phillimore Date: 2025-12-19 17:45:14 +0000 URL: https://git.openjdk.org/valhalla/commit/23fc21a3e2db11e24568d4c47e52efc6947e956b 8374052: Use java/util/Calendar in ReplaceCriticalClasses.java test Reviewed-by: iklam ! test/hotspot/jtreg/runtime/cds/serviceability/ReplaceCriticalClasses.java Changeset: c1ad393e Branch: lworld Author: William Kemper Date: 2025-12-19 18:01:22 +0000 URL: https://git.openjdk.org/valhalla/commit/c1ad393e25c253c9b4e09824bf5fceee134e08c0 8374048: Genshen: Backout fix for missed cancellation notice Reviewed-by: kdnilsen, ysr ! src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp Changeset: 400d8cfb Branch: lworld Author: Mikhail Yankelevich Date: 2025-12-19 18:02:13 +0000 URL: https://git.openjdk.org/valhalla/commit/400d8cfb6914982e636b23bacf810ef61fc90ee1 8373793: TestDynamicStore.java '/manual' disables use of '/timeout' Reviewed-by: weijun ! test/jdk/sun/security/krb5/config/native/TestDynamicStore.java Changeset: 0a70da46 Branch: lworld Author: Kim Barrett Date: 2025-12-19 22:37:09 +0000 URL: https://git.openjdk.org/valhalla/commit/0a70da46f6fe98711f6f4b8b4e49e8ee3e4cb59e 8372564: Convert StringDedup to use Atomic Reviewed-by: tschatzl, aboldtch, iwalulya ! src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.cpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.hpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupStorageUse.cpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupStorageUse.hpp Changeset: 2d092840 Branch: lworld Author: Alexander Matveev Date: 2025-12-19 23:19:27 +0000 URL: https://git.openjdk.org/valhalla/commit/2d0928406027a848cf2d2d0574024970b8fb535c 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil Reviewed-by: asemenyuk ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java Changeset: fe5911c7 Branch: lworld Author: Prasanta Sadhukhan Date: 2025-12-21 05:25:10 +0000 URL: https://git.openjdk.org/valhalla/commit/fe5911c7695283cb76b3d95877138b0b15bc0ba4 8373946: Synth ProgressBarUI implementation confuses background painting with border painting Reviewed-by: prr, kizune, azvegint ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java - test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java + test/jdk/javax/swing/plaf/nimbus/TestNimbusProgressBarBorder.java Changeset: 8ab7d3b8 Branch: lworld Author: Quan Anh Mai Date: 2025-12-21 15:15:49 +0000 URL: https://git.openjdk.org/valhalla/commit/8ab7d3b89f656e5c2882e19065f01fcc434161d2 8374078: C2_MacroAssembler::verify_int_in_range has incorrect early return condition Reviewed-by: kvn, dlong ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp Changeset: 25e87144 Branch: lworld Author: David Holmes Date: 2025-12-22 01:28:07 +0000 URL: https://git.openjdk.org/valhalla/commit/25e87144c20fcf5aca99b92f061a0051096c2605 8369515: Deadlock between JVMTI and JNI ReleasePrimitiveArrayCritical Co-authored-by: Richard Reingruber Reviewed-by: rrich, fbredberg, pchilanomate ! src/hotspot/share/runtime/javaThread.cpp Changeset: 9435d5b8 Branch: lworld Author: Alexander Zvegintsev Date: 2025-12-22 02:36:13 +0000 URL: https://git.openjdk.org/valhalla/commit/9435d5b89ca08595f0f2f8d029c00bc6d1f30104 8346154: [XWayland] Some tests fail intermittently in the CI, but not locally Reviewed-by: serb, prr ! test/jdk/java/awt/Choice/PopupPosTest/PopupPosTest.java ! test/jdk/java/awt/Focus/ClearLwQueueBreakTest/ClearLwQueueBreakTest.java ! test/jdk/java/awt/Frame/FrameSetMinimumSizeTest.java ! test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java ! test/jdk/java/awt/LightweightComponent/LightWeightTabFocus/LightWeightTabFocus.java ! test/jdk/java/awt/Modal/ToFront/DialogToFrontModeless1Test.java Changeset: 3579c752 Branch: lworld Author: Matthias Baesken Date: 2025-12-22 07:57:31 +0000 URL: https://git.openjdk.org/valhalla/commit/3579c752bcf2c160de47ec748c8b649b0028826a 8373876: StackWalkNativeToJava print more output in case of failures Reviewed-by: dholmes, mdoerr ! test/hotspot/jtreg/runtime/ErrorHandling/StackWalkNativeToJava.java Changeset: e6c3ebe2 Branch: lworld Author: Stefan Karlsson Date: 2025-12-22 09:32:22 +0000 URL: https://git.openjdk.org/valhalla/commit/e6c3ebe27b0dd4cbf1885d79ea50acb208e364fa 8374145: Remove legacy locking remnants from markWord Reviewed-by: aboldtch, kbarrett, coleenp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/oops/markWord.hpp Changeset: 551e6562 Branch: lworld Author: Stefan Karlsson Date: 2025-12-22 09:55:38 +0000 URL: https://git.openjdk.org/valhalla/commit/551e656218f18fa815d42e6035f85e907c6d66a4 8374113: Taughtological if check in Reflection::array_set Reviewed-by: fparain, liach ! src/hotspot/share/runtime/reflection.cpp Changeset: 2715f5e6 Branch: lworld Author: Stefan Karlsson Date: 2025-12-22 10:16:14 +0000 URL: https://git.openjdk.org/valhalla/commit/2715f5e698b49cd67faa233a3188e6a69ddb80c0 8374151: Cleanup minor markWord function disorder Reviewed-by: rcastanedalo, dholmes ! src/hotspot/share/oops/markWord.hpp Changeset: a61a1d32 Branch: lworld Author: Damon Fenacci Date: 2025-12-22 12:49:30 +0000 URL: https://git.openjdk.org/valhalla/commit/a61a1d32a2bbf227081b9da6d101071ceb73076a 8373525: C2: assert(_base == Long) failed: Not a Long Reviewed-by: chagedorn, mhaessig ! src/hotspot/share/opto/addnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestValidTypeInOverflowProtection.java Changeset: 9715e6da Branch: lworld Author: Jie Fu Date: 2025-12-22 15:15:20 +0000 URL: https://git.openjdk.org/valhalla/commit/9715e6da8355a103d9066bd15ce68b4773cbadcb 8374178: Missing include in systemDictionary.cpp after JDK-8365526 Reviewed-by: kbarrett, dholmes ! src/hotspot/share/classfile/systemDictionary.cpp Changeset: 72505420 Branch: lworld Author: Chris Plummer Date: 2025-12-22 19:28:10 +0000 URL: https://git.openjdk.org/valhalla/commit/72505420ca22c2ba1584f9d401ff0a1047b8c79b 8374038: JDI EventRequestManager javadoc has unrendered @link tags inside an @code block Reviewed-by: kevinw, amenkov ! src/jdk.jdi/share/classes/com/sun/jdi/request/EventRequestManager.java Changeset: 4b8eda30 Branch: lworld Author: Ioi Lam Date: 2025-12-22 19:43:55 +0000 URL: https://git.openjdk.org/valhalla/commit/4b8eda30474b99a9f1065e5cea9d8c2fb859bab2 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep Reviewed-by: naoto ! test/jdk/ProblemList-AotJdk.txt Changeset: ecb42341 Branch: lworld Author: Chen Liang Date: 2025-12-23 00:12:55 +0000 URL: https://git.openjdk.org/valhalla/commit/ecb42341a94326b1ee85ddd7b9ebadce8c952b99 8373447: Suspicious sign extension after integer promotion in imageDecompressor.cpp Reviewed-by: alanb ! src/java.base/share/native/libjimage/imageDecompressor.cpp Changeset: a0094f52 Branch: lworld Author: Alexey Semenyuk Date: 2025-12-23 04:39:50 +0000 URL: https://git.openjdk.org/valhalla/commit/a0094f529a6cf7e1e28a20d5033a9a1405f49d9f 8374216: Assorted changes to jpackage without functional impact Reviewed-by: almatvee ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxBundlingEnvironment.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundlingEnvironment.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DefaultBundlingEnvironment.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/LauncherBuilder.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/LauncherFromOptions.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/PackagingPipeline.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpecMapperOptionScope.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardBundlingOperation.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Application.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/BundleSpec.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/BundlingOperationDescriptor.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Package.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/IdentityWrapper.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/SetBuilder.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinBundlingEnvironment.java = src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromOptions.java ! test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/JUnitUtilsTest.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MsiDatabase.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java ! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionsValidationFailTest.java ! test/jdk/tools/jpackage/junit/tools/jdk/jpackage/test/JUnitUtils.java ! test/jdk/tools/jpackage/share/BasicTest.java ! test/jdk/tools/jpackage/share/InOutPathTest.java Changeset: e1d81c09 Branch: lworld Author: Hao Sun Date: 2025-12-23 08:08:25 +0000 URL: https://git.openjdk.org/valhalla/commit/e1d81c0946364a266a006481a8fbbac24c7e6c6a 8373122: JFR build failure with CDS disabled due to -Werror=unused-function after JDK-8365400 Reviewed-by: mgronlun, jiefu, fandreuzzi ! src/hotspot/share/jfr/support/jfrClassDefineEvent.cpp Changeset: 40755afd Branch: lworld Author: Aleksei Efimov Date: 2025-12-23 12:37:34 +0000 URL: https://git.openjdk.org/valhalla/commit/40755afdf9061d65dfd039a9707445188bc04303 8373808: Refactor java/net/httpclient qpack and hpack tests to use JUnit Reviewed-by: djelinski ! test/jdk/java/net/httpclient/http2/HpackBinaryTestDriver.java ! test/jdk/java/net/httpclient/http2/HpackCircularBufferDriver.java ! test/jdk/java/net/httpclient/http2/HpackDecoderDriver.java ! test/jdk/java/net/httpclient/http2/HpackEncoderDriver.java ! test/jdk/java/net/httpclient/http2/HpackHeaderTableDriver.java ! test/jdk/java/net/httpclient/http2/HpackHuffmanDriver.java ! test/jdk/java/net/httpclient/http2/HpackTestHelper.java ! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/BinaryPrimitivesTest.java ! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/CircularBufferTest.java ! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/DecoderTest.java ! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/EncoderTest.java ! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/HeaderTableTest.java ! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/HuffmanTest.java ! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/SimpleHeaderTableTest.java ! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/TestHelper.java ! test/jdk/java/net/httpclient/qpack/BlockingDecodingTest.java ! test/jdk/java/net/httpclient/qpack/DecoderSectionSizeLimitTest.java ! test/jdk/java/net/httpclient/qpack/DecoderTest.java ! test/jdk/java/net/httpclient/qpack/DynamicTableFieldLineRepresentationTest.java ! test/jdk/java/net/httpclient/qpack/DynamicTableTest.java ! test/jdk/java/net/httpclient/qpack/EncoderDecoderConnectionTest.java ! test/jdk/java/net/httpclient/qpack/EncoderDecoderConnector.java ! test/jdk/java/net/httpclient/qpack/EncoderDecoderTest.java ! test/jdk/java/net/httpclient/qpack/EncoderTest.java ! test/jdk/java/net/httpclient/qpack/EntriesEvictionTest.java ! test/jdk/java/net/httpclient/qpack/FieldSectionPrefixTest.java ! test/jdk/java/net/httpclient/qpack/IntegerReaderMaxValuesTest.java ! test/jdk/java/net/httpclient/qpack/StaticTableFieldsTest.java ! test/jdk/java/net/httpclient/qpack/StringLengthLimitsTest.java ! test/jdk/java/net/httpclient/qpack/TablesIndexerTest.java ! test/jdk/java/net/httpclient/qpack/UnacknowledgedInsertionTest.java Changeset: f1c50412 Branch: lworld Author: Jie Fu Date: 2025-12-23 14:31:29 +0000 URL: https://git.openjdk.org/valhalla/commit/f1c50412f0ded30f88720e9489e3ff4dd347ffa3 8374200: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails with common prefix metrics Reviewed-by: dholmes ! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java Changeset: be2ac088 Branch: lworld Author: Sergey Bylokhov Date: 2025-12-23 18:33:56 +0000 URL: https://git.openjdk.org/valhalla/commit/be2ac088e86f2be59f26997003cd02bad16672a0 8373967: [macos] User interactions with List do not trigger ItemEvent after programmatic change Reviewed-by: azvegint ! src/java.desktop/macosx/classes/sun/lwawt/LWListPeer.java + test/jdk/java/awt/List/NoEvents/MixProgrammaticUserChange.java Changeset: 8d80bac1 Branch: lworld Author: Kevin Walls Date: 2025-12-23 19:20:46 +0000 URL: https://git.openjdk.org/valhalla/commit/8d80bac1ec2f5eb66619c9e269d7c44612e1d04c 8374296: Comment clean up in os_linux.cpp Reviewed-by: mdoerr ! src/hotspot/os/linux/os_linux.cpp Changeset: 61cb6d74 Branch: lworld Author: Kevin Walls Date: 2025-12-23 20:47:55 +0000 URL: https://git.openjdk.org/valhalla/commit/61cb6d740807f8ef356d88c0328d05be1a33a8c1 8374232: Comment cleanup in diagnosticCommand.cpp Reviewed-by: cjplummer ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: f5249db9 Branch: lworld Author: Serguei Spitsyn Date: 2025-12-23 22:21:58 +0000 URL: https://git.openjdk.org/valhalla/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b 8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed Reviewed-by: cjplummer, amenkov ! src/hotspot/share/runtime/mountUnmountDisabler.cpp ! src/hotspot/share/runtime/mountUnmountDisabler.hpp Changeset: 72e1e157 Branch: lworld Author: Damon Nguyen Date: 2025-12-24 00:05:12 +0000 URL: https://git.openjdk.org/valhalla/commit/72e1e15779c3d7846f267c0dfd98191b99a55548 8373474: 2 Unintentional format string defect groups in jabswitch.cpp Reviewed-by: aivanov, prr, azvegint ! src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp Changeset: a59dbc51 Branch: lworld Author: Damon Nguyen Date: 2025-12-24 00:05:27 +0000 URL: https://git.openjdk.org/valhalla/commit/a59dbc5105b04234c501aa03474b82481658e5b5 8373475: Unintentional format string in logString of AccessInfo.cpp Reviewed-by: aivanov, prr, azvegint ! src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp Changeset: 4a0f7e42 Branch: lworld Author: Wang Haomin Committer: Jayathirth D V Date: 2025-12-24 09:06:39 +0000 URL: https://git.openjdk.org/valhalla/commit/4a0f7e4294d2ccc2d2bf460bea87b342fe934d03 8374321: Fix undefined reference to 'png_init_filter_functions_lsx' after 8371914 Reviewed-by: jiefu, jdv ! make/modules/java.desktop/lib/ClientLibraries.gmk Changeset: f23b958e Branch: lworld Author: Nizar Benalla Date: 2025-12-24 14:31:54 +0000 URL: https://git.openjdk.org/valhalla/commit/f23b958eca5c1b9f4e22b897ede6a07ed9224c5f 8373446: Update --release 26 symbol information for JDK 26 build 29 Reviewed-by: iris, liach + src/jdk.compiler/share/data/symbols/jdk.management-Q.sym.txt ! src/jdk.compiler/share/data/symbols/symbols Changeset: 6ade3480 Branch: lworld Author: Nizar Benalla Date: 2025-12-24 14:38:08 +0000 URL: https://git.openjdk.org/valhalla/commit/6ade34804f175b5dd1bf78515b78e5444d8be7f5 8374177: Update @since of HotSpotAOTCacheMXBean after JDK-8373607 Reviewed-by: alanb, iklam ! src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java Changeset: 98b7792a Branch: lworld Author: Nizar Benalla Date: 2025-12-24 14:47:04 +0000 URL: https://git.openjdk.org/valhalla/commit/98b7792a072380978b09fda4ec194f333d2ce7e3 8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27 Reviewed-by: liach ! test/jdk/ProblemList.txt Changeset: 73a8629c Branch: lworld Author: Sergey Bylokhov Date: 2025-12-25 01:25:29 +0000 URL: https://git.openjdk.org/valhalla/commit/73a8629c5b52b678febcc9d339e01ebcc5277909 8374310: Update copyright year to 2025 for client-libs in files where it was missed Reviewed-by: jdv, aivanov ! src/java.desktop/aix/classes/sun/awt/X11InputMethod.java ! src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java ! src/java.desktop/macosx/classes/apple/laf/JRSUIFocus.java ! src/java.desktop/macosx/classes/apple/laf/JRSUIState.java ! src/java.desktop/macosx/classes/apple/laf/JRSUIStateFactory.java ! src/java.desktop/macosx/classes/apple/laf/JRSUIUtils.java ! src/java.desktop/macosx/classes/com/apple/eawt/ApplicationBeanInfo.java ! src/java.desktop/macosx/classes/com/apple/eawt/FullScreenAdapter.java ! src/java.desktop/macosx/classes/com/apple/eawt/MacQuitResponse.java ! src/java.desktop/macosx/classes/com/apple/eawt/_AppDockIconHandler.java ! src/java.desktop/macosx/classes/com/apple/eawt/_AppEventHandler.java ! src/java.desktop/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java ! src/java.desktop/macosx/classes/com/apple/eawt/_AppMiscHandlers.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/FullScreenEvent.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/GestureAdapter.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/GestureHandler.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/GesturePhaseEvent.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/MagnificationEvent.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/RotationEvent.java ! src/java.desktop/macosx/classes/com/apple/eawt/event/SwipeEvent.java ! src/java.desktop/macosx/classes/com/apple/eio/FileManager.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonCheckBoxUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonRadioUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonToggleUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaCaret.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxRendererInternal.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaEditorPaneUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileView.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFocus.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFocusHandler.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFonts.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaGroupBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaHighlighter.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaIcon.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameManager.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFramePaneUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaLabelUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaListUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuBarBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuBarUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuItemUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaNativeResources.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaOptionPaneUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaPainter.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaPanelUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaPopupMenuSeparatorUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaPopupMenuUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaProgressBarUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaScrollPaneUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaScrollRegionBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaSliderUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaSpinnerUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaSplitPaneDividerUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaSplitPaneUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneContrastUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneTabState.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTableUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTextAreaUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldFormattedUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldSearch.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTextPaneUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTextPasswordFieldUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaToolBarSeparatorUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaToolBarUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaToolTipUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTreeUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtilControlSize.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java ! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuBar.java ! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuItem.java ! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java ! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuPropertyListener.java ! src/java.desktop/macosx/classes/com/apple/laf/ScreenPopupFactory.java ! src/java.desktop/macosx/classes/sun/awt/CGraphicsConfig.java ! src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/java.desktop/macosx/classes/sun/awt/PlatformGraphicsInfo.java ! src/java.desktop/macosx/classes/sun/font/CCompositeGlyphMapper.java ! src/java.desktop/macosx/classes/sun/font/CFont.java ! src/java.desktop/macosx/classes/sun/font/CFontConfiguration.java ! src/java.desktop/macosx/classes/sun/font/CFontManager.java ! src/java.desktop/macosx/classes/sun/font/CStrikeDisposer.java ! src/java.desktop/macosx/classes/sun/font/NativeFont.java ! src/java.desktop/macosx/classes/sun/font/NativeStrike.java ! src/java.desktop/macosx/classes/sun/java2d/CRenderer.java ! src/java.desktop/macosx/classes/sun/java2d/CompositeCRenderer.java ! src/java.desktop/macosx/classes/sun/java2d/DataBufferNIOInt.java ! src/java.desktop/macosx/classes/sun/java2d/IntegerNIORaster.java ! src/java.desktop/macosx/classes/sun/java2d/MacOSFlags.java ! src/java.desktop/macosx/classes/sun/java2d/OSXOffScreenSurfaceData.java ! src/java.desktop/macosx/classes/sun/java2d/OSXSurfaceData.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLBlitLoops.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLBufImgOps.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLDrawImage.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLLayer.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLMaskBlit.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLMaskFill.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLPaints.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderQueue.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderer.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceDataProxy.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLTextRenderer.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLVolatileSurfaceManager.java ! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLLayer.java ! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java ! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java ! src/java.desktop/macosx/classes/sun/lwawt/LWKeyboardFocusManagerPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/LWLightweightFramePeer.java ! src/java.desktop/macosx/classes/sun/lwawt/LWMouseInfoPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibleText.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CCheckboxMenuItem.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CCustomCursor.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CImage.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CInputMethod.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CInputMethodDescriptor.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CMouseDragGestureRecognizer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformLWComponent.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformLWWindow.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CSystemTray.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CViewPlatformEmbeddedFrame.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/macosx/classes/sun/print/PlatformPrinterJobProxy.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/DnDUtilities.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m ! src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriter.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/java.desktop/share/classes/java/awt/Dialog.java ! src/java.desktop/share/classes/java/awt/EventQueue.java ! src/java.desktop/share/classes/java/awt/Font.java ! src/java.desktop/share/classes/java/awt/GraphicsEnvironment.java ! src/java.desktop/share/classes/java/awt/HeadlessException.java ! src/java.desktop/share/classes/java/awt/KeyboardFocusManager.java ! src/java.desktop/share/classes/java/awt/Polygon.java ! src/java.desktop/share/classes/java/awt/PrintJob.java ! src/java.desktop/share/classes/java/awt/SystemTray.java ! src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html ! src/java.desktop/share/classes/java/awt/doc-files/Modality.html ! src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java ! src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java ! src/java.desktop/share/classes/java/awt/image/LookupOp.java ! src/java.desktop/share/classes/java/awt/image/MultiPixelPackedSampleModel.java ! src/java.desktop/share/classes/java/awt/image/SampleModel.java ! src/java.desktop/share/classes/java/awt/image/SinglePixelPackedSampleModel.java ! src/java.desktop/share/classes/java/beans/Beans.java ! src/java.desktop/share/classes/java/beans/DesignMode.java ! src/java.desktop/share/classes/javax/imageio/ImageReader.java ! src/java.desktop/share/classes/javax/imageio/ImageWriter.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java ! src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java ! src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageInputStream.java ! src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java ! src/java.desktop/share/classes/javax/imageio/stream/ImageInputStreamImpl.java ! src/java.desktop/share/classes/javax/imageio/stream/MemoryCacheImageInputStream.java ! src/java.desktop/share/classes/javax/imageio/stream/package-info.java ! src/java.desktop/share/classes/javax/swing/Action.java ! src/java.desktop/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/JEditorPane.java ! src/java.desktop/share/classes/javax/swing/JFileChooser.java ! src/java.desktop/share/classes/javax/swing/JOptionPane.java ! src/java.desktop/share/classes/javax/swing/JRootPane.java ! src/java.desktop/share/classes/javax/swing/JViewport.java ! src/java.desktop/share/classes/javax/swing/RootPaneContainer.java ! src/java.desktop/share/classes/javax/swing/SwingPaintEventDispatcher.java ! src/java.desktop/share/classes/javax/swing/SwingUtilities.java ! src/java.desktop/share/classes/javax/swing/Timer.java ! src/java.desktop/share/classes/javax/swing/ToolTipManager.java ! src/java.desktop/share/classes/javax/swing/UIManager.java ! src/java.desktop/share/classes/javax/swing/package-info.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDefaultLookup.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synth.dtd ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html ! src/java.desktop/share/classes/javax/swing/text/StringContent.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/Entity.java ! src/java.desktop/share/classes/sun/awt/AppContext.java ! src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java ! src/java.desktop/share/classes/sun/awt/SunToolkit.java ! src/java.desktop/share/classes/sun/awt/image/ByteInterleavedRaster.java ! src/java.desktop/share/classes/sun/awt/image/SunVolatileImage.java ! src/java.desktop/share/classes/sun/awt/image/SurfaceManager.java ! src/java.desktop/share/classes/sun/awt/util/PerformanceLogger.java ! src/java.desktop/share/classes/sun/font/FileFont.java ! src/java.desktop/share/classes/sun/font/FontManager.java ! src/java.desktop/share/classes/sun/font/SunFontManager.java ! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/opengl/OGLGraphicsConfig.java ! src/java.desktop/share/classes/sun/java2d/pipe/BufferedContext.java ! src/java.desktop/share/classes/sun/print/PathGraphics.java ! src/java.desktop/share/classes/sun/swing/FilePane.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/java.desktop/share/conf/psfontj2d.properties ! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.c ! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h ! src/java.desktop/share/native/libawt/java2d/SurfaceData.h ! src/java.desktop/share/native/libawt/java2d/loops/Blit.c ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c ! src/java.desktop/unix/classes/sun/awt/FcFontManager.java ! src/java.desktop/unix/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/InfoWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java ! src/java.desktop/unix/classes/sun/awt/X11/MotifDnDConstants.java ! src/java.desktop/unix/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java ! src/java.desktop/unix/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java ! src/java.desktop/unix/classes/sun/awt/X11/Native.java ! src/java.desktop/unix/classes/sun/awt/X11/UnsafeXDisposerRecord.java ! src/java.desktop/unix/classes/sun/awt/X11/WindowDimensions.java ! src/java.desktop/unix/classes/sun/awt/X11/WindowPropertyGetter.java ! src/java.desktop/unix/classes/sun/awt/X11/XAWTLookAndFeel.java ! src/java.desktop/unix/classes/sun/awt/X11/XAWTXSettings.java ! src/java.desktop/unix/classes/sun/awt/X11/XAtom.java ! src/java.desktop/unix/classes/sun/awt/X11/XAtomList.java ! src/java.desktop/unix/classes/sun/awt/X11/XAwtState.java ! src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XButtonPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XCanvasPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XCheckboxPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XChoicePeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XClipboard.java ! src/java.desktop/unix/classes/sun/awt/X11/XContentWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XCreateWindowParams.java ! src/java.desktop/unix/classes/sun/awt/X11/XCustomCursor.java ! src/java.desktop/unix/classes/sun/awt/X11/XDataTransferer.java ! src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XDesktopPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XDialogPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XDnDConstants.java ! src/java.desktop/unix/classes/sun/awt/X11/XDnDDragSourceProtocol.java ! src/java.desktop/unix/classes/sun/awt/X11/XDnDDropTargetProtocol.java ! src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XDragSourceProtocol.java ! src/java.desktop/unix/classes/sun/awt/X11/XDropTargetContextPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbedChildProxy.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbedClientHelper.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbedServerTester.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbeddedFrame.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbeddingContainer.java ! src/java.desktop/unix/classes/sun/awt/X11/XErrorHandler.java ! src/java.desktop/unix/classes/sun/awt/X11/XException.java ! src/java.desktop/unix/classes/sun/awt/X11/XFocusProxyWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XFontPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XGlobalCursorManager.java ! src/java.desktop/unix/classes/sun/awt/X11/XHorizontalScrollbar.java ! src/java.desktop/unix/classes/sun/awt/X11/XIconWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XInputMethod.java ! src/java.desktop/unix/classes/sun/awt/X11/XInputMethodDescriptor.java ! src/java.desktop/unix/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XLabelPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XLightweightFramePeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XListPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java ! src/java.desktop/unix/classes/sun/awt/X11/XMenuBarPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XMenuItemPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XMenuPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XMenuWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XMouseDragGestureRecognizer.java ! src/java.desktop/unix/classes/sun/awt/X11/XNETProtocol.java ! src/java.desktop/unix/classes/sun/awt/X11/XPanelPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XPopupMenuPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XPropertyCache.java ! src/java.desktop/unix/classes/sun/awt/X11/XQueryTree.java ! src/java.desktop/unix/classes/sun/awt/X11/XRepaintArea.java ! src/java.desktop/unix/classes/sun/awt/X11/XRootWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XScrollPanePeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XScrollbar.java ! src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XSelection.java ! src/java.desktop/unix/classes/sun/awt/X11/XSystemTrayPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XToolkitThreadBlockedHandler.java ! src/java.desktop/unix/classes/sun/awt/X11/XTranslateCoordinates.java ! src/java.desktop/unix/classes/sun/awt/X11/XTrayIconPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XVerticalScrollbar.java ! src/java.desktop/unix/classes/sun/awt/X11/XWINProtocol.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindowAttributesData.java ! src/java.desktop/unix/classes/sun/awt/X11/XWrapperBase.java ! src/java.desktop/unix/classes/sun/awt/X11/XlibUtil.java ! src/java.desktop/unix/classes/sun/awt/X11CustomCursor.java ! src/java.desktop/unix/classes/sun/awt/X11FontManager.java ! src/java.desktop/unix/classes/sun/awt/X11GraphicsConfig.java ! src/java.desktop/unix/classes/sun/awt/X11GraphicsEnvironment.java ! src/java.desktop/unix/classes/sun/awt/X11InputMethod.java ! src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java ! src/java.desktop/unix/classes/sun/awt/X11InputMethodDescriptor.java ! src/java.desktop/unix/classes/sun/awt/XSettings.java ! src/java.desktop/unix/classes/sun/font/DelegateStrike.java ! src/java.desktop/unix/classes/sun/font/DoubleByteEncoder.java ! src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java ! src/java.desktop/unix/classes/sun/font/FontConfigManager.java ! src/java.desktop/unix/classes/sun/font/MFontConfiguration.java ! src/java.desktop/unix/classes/sun/font/NativeFont.java ! src/java.desktop/unix/classes/sun/font/NativeStrike.java ! src/java.desktop/unix/classes/sun/font/NativeStrikeDisposer.java ! src/java.desktop/unix/classes/sun/font/X11Dingbats.java ! src/java.desktop/unix/classes/sun/font/X11GB18030_0.java ! src/java.desktop/unix/classes/sun/font/X11GB18030_1.java ! src/java.desktop/unix/classes/sun/font/X11GB2312.java ! src/java.desktop/unix/classes/sun/font/X11GBK.java ! src/java.desktop/unix/classes/sun/font/X11Johab.java ! src/java.desktop/unix/classes/sun/font/X11KSC5601.java ! src/java.desktop/unix/classes/sun/font/X11SunUnicode_0.java ! src/java.desktop/unix/classes/sun/font/X11TextRenderer.java ! src/java.desktop/unix/classes/sun/font/XMap.java ! src/java.desktop/unix/classes/sun/font/XRGlyphCache.java ! src/java.desktop/unix/classes/sun/font/XRGlyphCacheEntry.java ! src/java.desktop/unix/classes/sun/font/XRTextRenderer.java ! src/java.desktop/unix/classes/sun/java2d/opengl/GLXGraphicsConfig.java ! src/java.desktop/unix/classes/sun/java2d/opengl/GLXSurfaceData.java ! src/java.desktop/unix/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java ! src/java.desktop/unix/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/java.desktop/unix/classes/sun/java2d/x11/X11PMBlitLoops.java ! src/java.desktop/unix/classes/sun/java2d/x11/X11Renderer.java ! src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java ! src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceDataProxy.java ! src/java.desktop/unix/classes/sun/java2d/x11/X11VolatileSurfaceManager.java ! src/java.desktop/unix/classes/sun/java2d/xr/DirtyRegion.java ! src/java.desktop/unix/classes/sun/java2d/xr/GrowableByteArray.java ! src/java.desktop/unix/classes/sun/java2d/xr/GrowableEltArray.java ! src/java.desktop/unix/classes/sun/java2d/xr/GrowablePointArray.java ! src/java.desktop/unix/classes/sun/java2d/xr/GrowableRectArray.java ! src/java.desktop/unix/classes/sun/java2d/xr/MaskTile.java ! src/java.desktop/unix/classes/sun/java2d/xr/MaskTileManager.java ! src/java.desktop/unix/classes/sun/java2d/xr/MutableInteger.java ! src/java.desktop/unix/classes/sun/java2d/xr/XIDGenerator.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRBackendNative.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRColor.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRCompositeManager.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRDrawImage.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRDrawLine.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRGraphicsConfig.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRMaskBlit.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRMaskFill.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRMaskImage.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRPMBlitLoops.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRPaints.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRRenderer.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRSolidSrcPict.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRSurfaceData.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRSurfaceDataProxy.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRUtils.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRVolatileSurfaceManager.java ! src/java.desktop/unix/classes/sun/java2d/xr/XcbRequestCounter.java ! src/java.desktop/unix/classes/sun/print/AttributeClass.java ! src/java.desktop/unix/classes/sun/print/CUPSPrinter.java ! src/java.desktop/unix/classes/sun/print/IPPPrintService.java ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/unix/classes/sun/print/UnixPrintService.java ! src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h ! src/java.desktop/unix/native/common/awt/fontpath.c ! src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c ! src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/AnimationController.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/TMSchema.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsBorders.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsCheckBoxUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsClassicLookAndFeel.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopIconUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopPaneUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsEditorPaneUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLabelUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuBarUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsOptionPaneUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPasswordFieldUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPopupMenuSeparatorUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPopupMenuUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPopupWindow.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsScrollBarUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsScrollPaneUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSeparatorUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSliderUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSpinnerUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSplitPaneDivider.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSplitPaneUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTabbedPaneUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTextAreaUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTextFieldUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTextPaneUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTextUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsToggleButtonUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsToolBarSeparatorUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsToolBarUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java ! src/java.desktop/windows/classes/sun/awt/PlatformGraphicsInfo.java ! src/java.desktop/windows/classes/sun/awt/Win32ColorModel24.java ! src/java.desktop/windows/classes/sun/awt/Win32FontManager.java ! src/java.desktop/windows/classes/sun/awt/Win32GraphicsConfig.java ! src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java ! src/java.desktop/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/java.desktop/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WDataTransferer.java ! src/java.desktop/windows/classes/sun/awt/windows/WDefaultFontCharset.java ! src/java.desktop/windows/classes/sun/awt/windows/WDesktopProperties.java ! src/java.desktop/windows/classes/sun/awt/windows/WDragSourceContextPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/java.desktop/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java ! src/java.desktop/windows/classes/sun/awt/windows/WLabelPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WLightweightFramePeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WMouseInfoPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WPopupMenuPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WScrollbarPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WTrayIconPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WingDings.java ! src/java.desktop/windows/classes/sun/font/NativeFont.java ! src/java.desktop/windows/classes/sun/font/NativeStrike.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DBlitLoops.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DBufImgOps.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DContext.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DDrawImage.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DMaskBlit.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DMaskFill.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DPaints.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DRenderQueue.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DRenderer.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DSurfaceData.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DSurfaceDataProxy.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DTextRenderer.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DVolatileSurfaceManager.java ! src/java.desktop/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java ! src/java.desktop/windows/classes/sun/java2d/opengl/WGLSurfaceData.java ! src/java.desktop/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java ! src/java.desktop/windows/classes/sun/java2d/windows/GDIBlitLoops.java ! src/java.desktop/windows/classes/sun/java2d/windows/GDIRenderer.java ! src/java.desktop/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java ! src/java.desktop/windows/classes/sun/print/PlatformPrinterJobProxy.java ! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/sun/print/Win32MediaTray.java ! src/java.desktop/windows/classes/sun/print/Win32PrintJob.java ! src/java.desktop/windows/classes/sun/print/Win32PrintService.java ! src/java.desktop/windows/classes/sun/swing/plaf/windows/ClassicSortArrowIcon.java ! src/java.desktop/windows/native/libawt/windows/awt_Dialog.h ! src/java.desktop/windows/native/libawt/windows/awt_GDIObject.cpp ! src/java.desktop/windows/native/libawt/windows/awt_InputMethod.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Mlib.cpp ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_new.cpp ! test/jdk/java/awt/Choice/ChoiceLocationTest/ChoiceLocationTest.java ! test/jdk/java/awt/Dialog/CloseDialog/CloseDialogTest.java ! test/jdk/java/awt/Focus/ChoiceFocus/ChoiceFocus.java ! test/jdk/java/awt/Frame/GetGraphicsStressTest/GetGraphicsStressTest.java ! test/jdk/java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java ! test/jdk/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.java ! test/jdk/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.java ! test/jdk/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java ! test/jdk/java/awt/Modal/PrintDialogsTest/Test.java ! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java ! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java ! test/jdk/java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java ! test/jdk/java/awt/TextArea/TextAreaCursorTest/HoveringAndDraggingTest.java ! test/jdk/java/awt/TextArea/TextScrollTest.java ! test/jdk/java/awt/datatransfer/DragUnicodeBetweenJVMTest/DragUnicodeBetweenJVMTest.java ! test/jdk/java/awt/datatransfer/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java ! test/jdk/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java ! test/jdk/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.java ! test/jdk/java/awt/dnd/URIListBetweenJVMsTest/URIListBetweenJVMsTest.java ! test/jdk/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.java ! test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java ! test/jdk/java/awt/event/MouseEvent/MenuDragMouseEventAbsoluteCoordsTest/MenuDragMouseEventAbsoluteCoordsTest.java ! test/jdk/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.java ! test/jdk/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.java ! test/jdk/java/awt/event/helpers/lwcomponents/LWButton.java ! test/jdk/java/awt/font/GlyphVector/GetGlyphCharIndexTest.java ! test/jdk/java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java ! test/jdk/java/awt/im/8041990/bug8041990.java ! test/jdk/java/awt/im/PinyinIMCapsTest.java ! test/jdk/java/awt/im/PinyinIMCommaTest.java ! test/jdk/java/awt/im/PinyinIMFullstopTest.java ! test/jdk/java/awt/image/AffineTransformOp/AffineTxOpSizeTest.java ! test/jdk/java/awt/image/DrawImage/TiledImage.java ! test/jdk/java/awt/print/Dialog/DialogOrient.java ! test/jdk/java/awt/print/PrinterJob/PageDialogTest.java ! test/jdk/java/awt/print/PrinterJob/PrintDialog.java ! test/jdk/java/awt/print/PrinterJob/PrintDialogCancel.java ! test/jdk/java/awt/print/PrinterJob/ThinLines.java ! test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java ! test/jdk/java/awt/regtesthelpers/AbstractTest.java ! test/jdk/java/awt/regtesthelpers/Util.java ! test/jdk/java/awt/regtesthelpers/process/ProcessCommunicator.java ! test/jdk/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java ! test/jdk/javax/sound/midi/Sequencer/Looping.java ! test/jdk/javax/sound/midi/SysexMessage/SendRawSysexMessage.java ! test/jdk/javax/sound/midi/spi/MidiDeviceProvider/ExpectedNPEOnNull.java ! test/jdk/javax/sound/midi/spi/MidiDeviceProvider/FakeInfo.java ! test/jdk/javax/sound/midi/spi/MidiDeviceProvider/UnsupportedInfo.java ! test/jdk/javax/sound/sampled/Clip/ClipFlushCrash.java ! test/jdk/javax/sound/sampled/Clip/IsRunningHang.java ! test/jdk/javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java ! test/jdk/javax/sound/sampled/DataLine/LongFramePosition.java ! test/jdk/javax/sound/sampled/DirectAudio/bug6372428.java ! test/jdk/javax/sound/sampled/LinuxBlock/PlaySine.java ! test/jdk/javax/swing/JOptionPane/bug4174551.java ! test/jdk/javax/swing/JTextArea/4697612/bug4697612.java ! test/jdk/javax/swing/text/html/parser/Parser/6990651/bug6990651.java ! test/jdk/javax/swing/text/html/parser/Parser/8078268/bug8078268.java ! test/jdk/sun/java2d/marlin/ClipShapeTest.java ! test/jdk/sun/java2d/marlin/CrashNaNTest.java ! test/jdk/sun/java2d/marlin/CrashPaintTest.java ! test/jdk/sun/java2d/marlin/TextClipErrorTest.java Changeset: 534c33d0 Branch: lworld Author: Sergey Bylokhov Date: 2025-12-25 07:25:40 +0000 URL: https://git.openjdk.org/valhalla/commit/534c33d0ef7daa0d0d5b56a1101b4c9d47a48049 8374323: Update copyright year to 2025 for the build system in files where it was missed Reviewed-by: erikj ! .github/actions/build-jtreg/action.yml ! .github/actions/get-bundles/action.yml ! .github/actions/get-gtest/action.yml ! .github/actions/get-jtreg/action.yml ! .github/actions/get-msys2/action.yml ! .github/actions/upload-bundles/action.yml ! .github/workflows/build-alpine-linux.yml ! .github/workflows/build-cross-compile.yml ! .github/workflows/build-linux.yml ! .github/workflows/build-macos.yml ! .github/workflows/build-windows.yml ! .github/workflows/main.yml ! .github/workflows/test.yml ! make/RunTestsPrebuiltSpec.gmk ! make/autoconf/bootcycle-spec.gmk.template ! make/autoconf/buildjdk-spec.gmk.template ! make/autoconf/compare.sh.template ! make/autoconf/hotspot.m4 ! make/autoconf/lib-bundled.m4 ! make/autoconf/platform.m4 ! make/devkit/createWindowsDevkit.sh ! make/jdk/src/classes/build/tools/pandocfilter/PandocFilter.java ! make/jdk/src/classes/build/tools/taglet/JSpec.java ! make/jdk/src/classes/build/tools/taglet/ToolGuide.java ! make/langtools/tools/propertiesparser/parser/Message.java ! make/scripts/compare-logger.sh ! make/scripts/compare.sh Changeset: 3e6170c5 Branch: lworld Author: Sergey Bylokhov Date: 2025-12-26 03:46:40 +0000 URL: https://git.openjdk.org/valhalla/commit/3e6170c5be95f92a209c58928be487e8a9f97287 8374354: Update copyright year to 2025 for jdk.javadoc in files where it was missed Reviewed-by: liach ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyles.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/LinkTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/Content.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/ContentBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/Entity.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/RawHtml.java Changeset: e65ace10 Branch: lworld Author: Daniel Gredler Date: 2025-12-26 11:58:48 +0000 URL: https://git.openjdk.org/valhalla/commit/e65ace10e3c40d6fef4e9997311d88c900e84ced 6517125: FontStrike.getGlyphVectorOutline() not used Reviewed-by: prr, serb ! src/java.desktop/macosx/classes/sun/font/CStrike.java ! src/java.desktop/macosx/classes/sun/font/NativeStrike.java ! src/java.desktop/share/classes/sun/font/CompositeStrike.java ! src/java.desktop/share/classes/sun/font/FileFontStrike.java ! src/java.desktop/share/classes/sun/font/FontStrike.java ! src/java.desktop/unix/classes/sun/font/DelegateStrike.java ! src/java.desktop/unix/classes/sun/font/NativeStrike.java ! src/java.desktop/windows/classes/sun/font/NativeStrike.java Changeset: ac07a41d Branch: lworld Author: Sergey Bylokhov Date: 2025-12-26 19:12:55 +0000 URL: https://git.openjdk.org/valhalla/commit/ac07a41de9877aec3e9d5e7a23b0583038a7956d 8374360: Update copyright year to 2025 for test/jdk/jdk/jfr in files where it was missed Reviewed-by: egahlin ! test/jdk/jdk/jfr/api/consumer/TestRecordedClass.java ! test/jdk/jdk/jfr/api/consumer/TestRecordedFrameType.java ! test/jdk/jdk/jfr/api/consumer/TestRecordingFileSanitization.java ! test/jdk/jdk/jfr/api/consumer/TestRecordingFileWrite.java ! test/jdk/jdk/jfr/api/consumer/log/TestContent.java ! test/jdk/jdk/jfr/api/consumer/log/TestDiskOnOff.java ! test/jdk/jdk/jfr/api/consumer/log/TestDynamicStart.java ! test/jdk/jdk/jfr/api/consumer/log/TestMemoryDiskTransition.java ! test/jdk/jdk/jfr/api/consumer/log/TestMemoryOnly.java ! test/jdk/jdk/jfr/api/consumer/log/TestSystemEvents.java ! test/jdk/jdk/jfr/api/consumer/log/TestTruncation.java ! test/jdk/jdk/jfr/api/consumer/log/TestUserEvents.java ! test/jdk/jdk/jfr/api/consumer/log/TestVerbosity.java ! test/jdk/jdk/jfr/api/consumer/log/TestWithStreaming.java ! test/jdk/jdk/jfr/api/consumer/recordingstream/TestDump.java ! test/jdk/jdk/jfr/api/consumer/recordingstream/TestRecordingName.java ! test/jdk/jdk/jfr/api/consumer/streaming/TestBaseRepositoryAfterStart.java ! test/jdk/jdk/jfr/api/consumer/streaming/TestBaseRepositoryBeforeStart.java ! test/jdk/jdk/jfr/api/consumer/streaming/TestBaseRepositoryLastModified.java ! test/jdk/jdk/jfr/api/consumer/streaming/TestBaseRepositoryMultipleProcesses.java ! test/jdk/jdk/jfr/api/recording/dump/TestDumpDevNull.java ! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEvent.java ! test/jdk/jdk/jfr/event/compiler/TestCompilerQueueUtilization.java ! test/jdk/jdk/jfr/event/gc/detailed/TestG1InvalidHeapRegionTypeChangeEvent.java ! test/jdk/jdk/jfr/event/gc/detailed/TestGCCPUTimeEvent.java ! test/jdk/jdk/jfr/event/gc/detailed/TestGCHeapMemoryPoolUsageEvent.java ! test/jdk/jdk/jfr/event/gc/heapsummary/HeapSummaryEventAllGcs.java ! test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java ! test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java ! test/jdk/jdk/jfr/event/runtime/TestDeprecatedEvent.java ! test/jdk/jdk/jfr/event/runtime/TestDirectBufferStatisticsEvent.java ! test/jdk/jdk/jfr/event/runtime/TestFinalizerStatisticsEvent.java ! test/jdk/jdk/jfr/event/runtime/TestNativeLibraryLoadEvent.java ! test/jdk/jdk/jfr/event/security/TestInitialSecurityPropertyEvent.java ! test/jdk/jdk/jfr/event/security/TestSecurityProviderServiceEvent.java ! test/jdk/jdk/jfr/jcmd/TestJcmdConfigureReadOnly.java ! test/jdk/jdk/jfr/jcmd/TestJcmdOptionSpecifiedOnce.java ! test/jdk/jdk/jfr/jcmd/TestJcmdStartGeneratedFilename.java ! test/jdk/jdk/jfr/jcmd/TestJcmdViewMissingData.java ! test/jdk/jdk/jfr/jmx/streaming/TestClose.java ! test/jdk/jdk/jfr/jmx/streaming/TestDelegated.java ! test/jdk/jdk/jfr/jmx/streaming/TestDumpOrder.java ! test/jdk/jdk/jfr/jmx/streaming/TestMetadataEvent.java ! test/jdk/jdk/jfr/jmx/streaming/TestMultipleChunks.java ! test/jdk/jdk/jfr/jmx/streaming/TestNew.java ! test/jdk/jdk/jfr/jmx/streaming/TestRotate.java ! test/jdk/jdk/jfr/jmx/streaming/TestSetSettings.java ! test/jdk/jdk/jfr/jmx/streaming/TestStart.java ! test/jdk/jdk/jfr/jmx/streaming/TestStop.java ! test/jdk/jdk/jfr/jvm/TestChunkIntegrity.java ! test/jdk/jdk/jfr/jvm/TestFatEvent.java ! test/jdk/jdk/jfr/jvm/TestHiddenWait.java ! test/jdk/jdk/jfr/jvm/TestLongStringsInPool.java ! test/jdk/jdk/jfr/jvm/TestVerifyInstrumentation.java ! test/jdk/jdk/jfr/startupargs/TestPreserveRepository.java ! test/jdk/jdk/jfr/startupargs/TestStartHelp.java ! test/jdk/jdk/jfr/startupargs/TestStartupOptionSpecifiedOnce.java ! test/jdk/jdk/jfr/threading/TestStringPoolVirtualThreadPinning.java ! test/jdk/jdk/jfr/tool/TestConfigure.java ! test/jdk/jdk/jfr/tool/TestView.java Changeset: e7f9132e Branch: lworld Author: Alexey Ivanov Date: 2025-12-26 20:12:15 +0000 URL: https://git.openjdk.org/valhalla/commit/e7f9132e8992ac281d1e4777a9664d1c8b817f4f 8374345: Restore the original copyright year in ExtremeFontSizeTest.java Reviewed-by: serb, syan ! test/jdk/java/awt/FontMetrics/ExtremeFontSizeTest.java Changeset: 5c694eab Branch: lworld Author: Sergey Bylokhov Date: 2025-12-27 04:45:56 +0000 URL: https://git.openjdk.org/valhalla/commit/5c694eab0f48045d2f71d0cd5ab53c1daddaa963 8374363: Update copyright year to 2025 for test/micro in files where it was missed Reviewed-by: phh ! test/micro/org/openjdk/bench/java/lang/foreign/AllocFromSliceTest.java ! test/micro/org/openjdk/bench/java/util/ImmutableColls.java ! test/micro/org/openjdk/bench/vm/compiler/MergeStoreBench.java ! test/micro/org/openjdk/bench/vm/gc/systemgc/AllDead.java ! test/micro/org/openjdk/bench/vm/gc/systemgc/AllLive.java ! test/micro/org/openjdk/bench/vm/gc/systemgc/DifferentObjectSizesArray.java ! test/micro/org/openjdk/bench/vm/gc/systemgc/DifferentObjectSizesHashMap.java ! test/micro/org/openjdk/bench/vm/gc/systemgc/DifferentObjectSizesTreeMap.java ! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfDeadFirstPart.java ! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfDeadInterleaved.java ! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfDeadInterleavedChunks.java ! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfDeadSecondPart.java ! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfHashedHalfDead.java ! test/micro/org/openjdk/bench/vm/gc/systemgc/NoObjects.java ! test/micro/org/openjdk/bench/vm/gc/systemgc/OneBigObject.java Changeset: 2886c3b6 Branch: lworld Author: Sergey Bylokhov Date: 2025-12-27 04:56:04 +0000 URL: https://git.openjdk.org/valhalla/commit/2886c3b68a8d4b098f7d093f0406d2a15e5910dc 8374358: Update copyright year to 2025 for test/hotspot in files where it was missed Reviewed-by: phh ! test/hotspot/jtreg/TEST.quick-groups ! test/hotspot/jtreg/applications/jcstress/TestGenerator.java ! test/hotspot/jtreg/compiler/c2/Test7005594.java ! test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndLoadKlass.java ! test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndNonExactAllocate.java ! test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndNullableLoads.java ! test/hotspot/jtreg/compiler/c2/irTests/TestPhiDuplicatedConversion.java ! test/hotspot/jtreg/compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java ! test/hotspot/jtreg/compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java ! test/hotspot/jtreg/compiler/escapeAnalysis/TestReduceAllocationAndNonReduciblePhi.java ! test/hotspot/jtreg/compiler/intrinsics/bmi/BMITestRunner.java ! test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxIntrinsics.java ! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseMD5IntrinsicsOptionOnSupportedCPU.java ! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseMD5IntrinsicsOptionOnUnsupportedCPU.java ! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java ! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java ! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java ! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java ! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java ! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java ! test/hotspot/jtreg/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForUnsupportedCPU.java ! test/hotspot/jtreg/compiler/jvmci/TestUncaughtErrorInCompileMethod.java ! test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventListener.java ! test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java ! test/hotspot/jtreg/compiler/lib/compile_framework/CompileFramework.java ! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/VMInfo.java ! test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFrameworkSocket.java ! test/hotspot/jtreg/compiler/loopopts/TestMissingSkeletonPredicateForIfNode.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestGeneralizedReductions.java ! test/hotspot/jtreg/compiler/profiling/TestTypeProfiling.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorReinterpret.java ! test/hotspot/jtreg/compiler/vectorization/TestBufferVectorization.java ! test/hotspot/jtreg/compiler/vectorization/TestOptionVectorizeIR.java ! test/hotspot/jtreg/compiler/vectorization/TestRoundVectFloat.java ! test/hotspot/jtreg/compiler/vectorization/TestRoundVectRiscv64.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicBooleanOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicByteOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicDoubleOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicIntOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopLiveOutNodesTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopRangeStrideTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/MultipleLoopsTest.java ! test/hotspot/jtreg/gc/arguments/TestMinInitialErgonomics.java ! test/hotspot/jtreg/gc/arguments/TestParallelGCErgo.java ! test/hotspot/jtreg/gc/g1/TestHumongousConcurrentStartUndo.java ! test/hotspot/jtreg/gc/g1/TestMixedGCLiveThreshold.java ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryDataRunner.java ! test/hotspot/jtreg/gc/g1/plab/TestPLABEvacuationFailure.java ! test/hotspot/jtreg/gc/g1/plab/lib/PLABUtils.java ! test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java ! test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java ! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithG1.java ! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithParallel.java ! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithSerial.java ! test/hotspot/jtreg/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java ! test/hotspot/jtreg/runtime/ErrorHandling/ShowRegistersOnAssertTest.java ! test/hotspot/jtreg/runtime/ErrorHandling/StackWalkNativeToJava.java ! test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java ! test/hotspot/jtreg/runtime/NMT/JcmdWithNMTDisabled.java ! test/hotspot/jtreg/runtime/StackGap/TestStackGap.java ! test/hotspot/jtreg/runtime/StackGuardPages/TestStackGuardPages.java ! test/hotspot/jtreg/runtime/TLS/TestTLS.java ! test/hotspot/jtreg/runtime/Thread/TooSmallStackSize.java ! test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java ! test/hotspot/jtreg/runtime/cds/appcds/LotsOfJRTClasses.java ! test/hotspot/jtreg/runtime/cds/appcds/SignedJar.java ! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/BadLookupSwitch.jcod ! test/hotspot/jtreg/runtime/jni/atExit/libatExit.c ! test/hotspot/jtreg/runtime/jni/checked/TestLargeUTF8Length.java ! test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java ! test/hotspot/jtreg/runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java ! test/hotspot/jtreg/runtime/verifier/TraceClassRes.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbAttach.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbAttachDifferentJVMs.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbClasses.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbField.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbHistory.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbJdis.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbJstack.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintAs.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbPstack.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbSource.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbTestAllocationMerge.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbThread.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbVmStructsDump.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbWhere.java ! test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java ! test/hotspot/jtreg/serviceability/sa/TestClassDump.java ! test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java ! test/hotspot/jtreg/serviceability/sa/TestCpoolForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestDebugInfoDecode.java ! test/hotspot/jtreg/serviceability/sa/TestDefaultMethods.java ! test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java ! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSize.java ! test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSizeForInterface.java ! test/hotspot/jtreg/serviceability/sa/TestIntConstant.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackUpcall.java ! test/hotspot/jtreg/serviceability/sa/TestJmapCore.java ! test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java ! test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java ! test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java ! test/hotspot/jtreg/serviceability/sa/TestSysProps.java ! test/hotspot/jtreg/serviceability/sa/TestType.java ! test/hotspot/jtreg/serviceability/sa/UniqueVtableTest.java ! test/hotspot/jtreg/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbTestConnectArgument.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DisableRegistryTest.java ! test/hotspot/jtreg/testlibrary/ctw/Makefile ! test/hotspot/jtreg/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java ! test/hotspot/jtreg/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java ! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/visitors/ByteCodeVisitor.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestBadFormat.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/flag/TestCompilePhaseCollector.java ! test/hotspot/jtreg/testlibrary_tests/verify/tests/TestVerify.java ! test/hotspot/jtreg/vmTestbase/gc/vector/LinearListLow/TestDescription.java ! test/hotspot/jtreg/vmTestbase/jit/removal_candidates.txt ! test/hotspot/jtreg/vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach010/attach010Agent00.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/ma10t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001.java ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/GC.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/TestDebuggerType1.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/runner/ThreadsRunner.java ! test/hotspot/jtreg/vmTestbase/nsk/share/test/Stresser.java ! test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress007.cpp ! test/hotspot/jtreg/vmTestbase/vm/jit/LongTransitions/JniArmHFTestGenerator.java.txt Changeset: 9512a43e Branch: lworld Author: Sergey Bylokhov Date: 2025-12-27 07:02:41 +0000 URL: https://git.openjdk.org/valhalla/commit/9512a43e82652be7294338c11cc9ffb0f0324b92 8374365: Update copyright year to 2025 for test/jdk in files where it was missed Reviewed-by: phh ! test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java ! test/jdk/java/beans/Introspector/4520754/Test4520754.java ! test/jdk/java/beans/Performance/TestIntrospector.java ! test/jdk/java/beans/PropertyChangeSupport/Test4682386.java ! test/jdk/java/foreign/TestMemoryAlignment.java ! test/jdk/java/foreign/TestUpcallStructScope.java ! test/jdk/java/foreign/libTest4BAlignedDouble.c ! test/jdk/java/foreign/libTestUpcallStructScope.c ! test/jdk/java/io/File/libGetXSpace.c ! test/jdk/java/io/pathNames/win32/DriveOnly.java ! test/jdk/java/lang/Class/getEnclosingClass/EnclosingClass.java ! test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java ! test/jdk/java/lang/Class/getEnclosingClass/common/TestMe.java ! test/jdk/java/lang/ProcessBuilder/FDLeakTest/exeFDLeakTester.c ! test/jdk/java/lang/ScopedValue/ManyBindings.java ! test/jdk/java/lang/ScopedValue/ScopedValueAPI.java ! test/jdk/java/lang/System/PropertyTest.java ! test/jdk/java/lang/System/i18nEnvArg.java ! test/jdk/java/lang/module/ClassFileVersionsTest.java ! test/jdk/java/lang/module/ModuleDescriptorTest.java ! test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java ! test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java ! test/jdk/java/net/URL/OpenStream.java ! test/jdk/java/net/httpclient/altsvc/altsvc-dns-hosts.txt ! test/jdk/java/nio/channels/FileChannel/directio/DirectIOTest.java ! test/jdk/java/nio/channels/FileChannel/directio/libDirectIO.c ! test/jdk/java/nio/file/Path/UriImportExport.java ! test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java ! test/jdk/java/nio/file/spi/CustomSystemClassLoader.java ! test/jdk/java/nio/file/spi/SetDefaultProvider.java ! test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java ! test/jdk/java/time/tck/java/time/TCKInstant.java ! test/jdk/java/util/Collections/T5078378.java ! test/jdk/java/util/List/ListFactories.java ! test/jdk/java/util/Locale/LocaleProvidersFormat.java ! test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java ! test/jdk/java/util/concurrent/Executors/AutoShutdown.java ! test/jdk/java/util/concurrent/forkjoin/Starvation.java ! test/jdk/java/util/concurrent/locks/StampedLock/OOMEInStampedLock.java ! test/jdk/java/util/regex/TestCases.txt ! test/jdk/java/util/stream/GathererTest.java ! test/jdk/java/util/zip/CloseInflaterDeflaterTest.java ! test/jdk/java/util/zip/DeflaterClose.java ! test/jdk/java/util/zip/InflaterClose.java ! test/jdk/java/util/zip/TotalInOut.java ! test/jdk/javax/management/security/HashedPasswordFileTest.java ! test/jdk/javax/net/ssl/SSLSocket/Tls13PacketSize.java ! test/jdk/javax/net/ssl/Stapling/StapleEnableProps.java ! test/jdk/jdk/incubator/vector/gen-template.sh ! test/jdk/jdk/incubator/vector/templates/Unit-header.template ! test/jdk/jdk/internal/platform/docker/TestSystemMetrics.java ! test/jdk/jdk/internal/platform/docker/TestUseContainerSupport.java ! test/jdk/jdk/modules/etc/DefaultModules.java ! test/jdk/jni/nullCaller/NullCallerTest.java ! test/jdk/performance/client/SwingMark/src/AbstractSwingTest.java ! test/jdk/performance/client/SwingMark/src/JMTest_01.java ! test/jdk/performance/client/SwingMark/src/JMTest_02.java ! test/jdk/performance/client/SwingMark/src/JMTest_03.java ! test/jdk/performance/client/SwingMark/src/JMTest_04.java ! test/jdk/performance/client/SwingMark/src/JMTest_05.java ! test/jdk/performance/client/SwingMark/src/MenuTest.java ! test/jdk/performance/client/SwingMark/src/TypingTest.java ! test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/button/resources/ButtonDemo.html ! test/jdk/sun/awt/font/TestArabicHebrew.java ! test/jdk/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java ! test/jdk/tools/jimage/ImageReaderDuplicateChildNodesTest.java ! test/jdk/tools/jlink/SnippetsTest.java ! test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/JavaAppDescTest.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Annotations.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AppImageFile.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/RunnablePackageTest.java ! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/DefaultBundlingEnvironmentTest.java ! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/OverridableResourceTest.java ! test/jdk/tools/jpackage/windows/WinRenameTest.java ! test/jdk/tools/launcher/JniInvocationTest.java Changeset: 5e685f6f Branch: lworld Author: Anjian Wen Date: 2025-12-28 09:13:09 +0000 URL: https://git.openjdk.org/valhalla/commit/5e685f6f2c7872a4239ef0c0a0afa60f4526529e 8374351: RISC-V: Small refactoring for crypto macro-assembler routines Reviewed-by: fyang, fjiang ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp Changeset: 078e71f4 Branch: lworld Author: Kirill Shirokov Committer: Xiaolong Peng Date: 2025-12-29 21:09:41 +0000 URL: https://git.openjdk.org/valhalla/commit/078e71f4a3d68d298ab3c383e46d18912e1de7db 8344345: test/hotspot/gtest/x86/x86-asmtest.py has trailing whitespaces Reviewed-by: phh, lmesnik ! test/hotspot/gtest/x86/x86-asmtest.py Changeset: 92c6799b Branch: lworld Author: Sergey Bylokhov Date: 2025-12-29 21:20:59 +0000 URL: https://git.openjdk.org/valhalla/commit/92c6799b401eb786949e88cd7142002b2a875ce0 8374361: Update copyright year to 2025 for jdk.hotspot.agent in files where it was missed Reviewed-by: phh ! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/Debugger.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/StackValueCollection.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/linux_amd64/LinuxAMD64JavaThreadPDAccess.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/AnnotatedMemoryPanel.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp Changeset: 08450f2c Branch: lworld Author: Sergey Bylokhov Date: 2025-12-30 07:01:49 +0000 URL: https://git.openjdk.org/valhalla/commit/08450f2c4d447c42a2ca8222d162ae3d2d25268a 8374326: Update copyright year to 2025 for jdk.jpackage in files where it was missed Reviewed-by: phh ! src/jdk.jpackage/linux/native/libapplauncher/LinuxLauncherLib.cpp ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgInstallerScripts.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/ResourceLocator.java ! src/jdk.jpackage/share/native/applauncher/PackageFile.cpp ! src/jdk.jpackage/share/native/common/Dll.h ! src/jdk.jpackage/share/native/common/app.cpp ! src/jdk.jpackage/share/native/common/tstrings.cpp ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixLauncherAsService.java ! src/jdk.jpackage/windows/native/common/MsiUtils.h ! src/jdk.jpackage/windows/native/libjpackage/VersionInfo.cpp ! src/jdk.jpackage/windows/native/libmsica/Version.cpp ! src/jdk.jpackage/windows/native/libmsica/Version.h ! src/jdk.jpackage/windows/native/libmsica/libmsica.cpp Changeset: e4e923a1 Branch: lworld Author: Martin Doerr Date: 2025-12-30 09:49:05 +0000 URL: https://git.openjdk.org/valhalla/commit/e4e923a1ffc8ff059c983c7e9201d0ee3273482d 8374195: TestReplaceNarrowPhiWithBottomPhi fails on ppc64 platforms in (fast)debug Reviewed-by: mbaesken, jbechberger ! test/hotspot/jtreg/compiler/c2/TestReplaceNarrowPhiWithBottomPhi.java Changeset: a6462d64 Branch: lworld Author: Sergey Bylokhov Date: 2025-12-30 12:08:36 +0000 URL: https://git.openjdk.org/valhalla/commit/a6462d641cba004829f9136df22f3d953c0e0c5d 8374316: Update copyright year to 2025 for hotspot in files where it was missed Reviewed-by: kbarrett ! src/hotspot/cpu/aarch64/assembler_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad ! src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp ! src/hotspot/cpu/aarch64/methodHandles_aarch64.hpp ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/smallRegisterMap_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp ! src/hotspot/cpu/arm/assembler_arm_32.hpp ! src/hotspot/cpu/arm/c1_Defs_arm.hpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.hpp ! src/hotspot/cpu/arm/continuationFreezeThaw_arm.inline.hpp ! src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.hpp ! src/hotspot/cpu/arm/interp_masm_arm.hpp ! src/hotspot/cpu/arm/matcher_arm.hpp ! src/hotspot/cpu/arm/smallRegisterMap_arm.inline.hpp ! src/hotspot/cpu/arm/stackChunkFrameStream_arm.inline.hpp ! src/hotspot/cpu/arm/stubRoutines_arm.hpp ! src/hotspot/cpu/arm/vmreg_arm.hpp ! src/hotspot/cpu/arm/vmreg_arm.inline.hpp ! src/hotspot/cpu/ppc/c1_Defs_ppc.hpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.hpp ! src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp ! src/hotspot/cpu/ppc/continuationHelper_ppc.inline.hpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.hpp ! src/hotspot/cpu/ppc/gc/shared/cardTableBarrierSetAssembler_ppc.hpp ! src/hotspot/cpu/ppc/smallRegisterMap_ppc.inline.hpp ! src/hotspot/cpu/ppc/stackChunkFrameStream_ppc.inline.hpp ! src/hotspot/cpu/riscv/assembler_riscv.inline.hpp ! src/hotspot/cpu/riscv/c1_Defs_riscv.hpp ! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.hpp ! src/hotspot/cpu/riscv/codeBuffer_riscv.hpp ! src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp ! src/hotspot/cpu/riscv/continuationHelper_riscv.inline.hpp ! src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.hpp ! src/hotspot/cpu/riscv/gc/shared/cardTableBarrierSetAssembler_riscv.hpp ! src/hotspot/cpu/riscv/gc/z/z_riscv.ad ! src/hotspot/cpu/riscv/interp_masm_riscv.hpp ! src/hotspot/cpu/riscv/javaFrameAnchor_riscv.hpp ! src/hotspot/cpu/riscv/matcher_riscv.hpp ! src/hotspot/cpu/riscv/methodHandles_riscv.hpp ! src/hotspot/cpu/riscv/riscv_b.ad ! src/hotspot/cpu/riscv/smallRegisterMap_riscv.inline.hpp ! src/hotspot/cpu/riscv/stackChunkFrameStream_riscv.inline.hpp ! src/hotspot/cpu/riscv/stubRoutines_riscv.hpp ! src/hotspot/cpu/s390/assembler_s390.inline.hpp ! src/hotspot/cpu/s390/c1_Defs_s390.hpp ! src/hotspot/cpu/s390/c1_FrameMap_s390.hpp ! src/hotspot/cpu/s390/continuationFreezeThaw_s390.inline.hpp ! src/hotspot/cpu/s390/disassembler_s390.cpp ! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.hpp ! src/hotspot/cpu/s390/gc/shared/cardTableBarrierSetAssembler_s390.hpp ! src/hotspot/cpu/s390/interp_masm_s390.hpp ! src/hotspot/cpu/s390/javaFrameAnchor_s390.hpp ! src/hotspot/cpu/s390/matcher_s390.hpp ! src/hotspot/cpu/s390/smallRegisterMap_s390.inline.hpp ! src/hotspot/cpu/s390/stackChunkFrameStream_s390.inline.hpp ! src/hotspot/cpu/s390/stubRoutines_s390.hpp ! src/hotspot/cpu/x86/assembler_x86.inline.hpp ! src/hotspot/cpu/x86/c1_Defs_x86.hpp ! src/hotspot/cpu/x86/c1_FrameMap_x86.hpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.hpp ! src/hotspot/cpu/x86/c1_LinearScan_x86.hpp ! src/hotspot/cpu/x86/continuationHelper_x86.inline.hpp ! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp ! src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.hpp ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.hpp ! src/hotspot/cpu/x86/gc/z/z_x86_64.ad ! src/hotspot/cpu/x86/icache_x86.hpp ! src/hotspot/cpu/x86/interpreterRT_x86.hpp ! src/hotspot/cpu/x86/matcher_x86.hpp ! src/hotspot/cpu/x86/methodHandles_x86.hpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp ! src/hotspot/cpu/x86/peephole_x86_64.hpp ! src/hotspot/cpu/x86/rdtsc_x86.hpp ! src/hotspot/cpu/x86/smallRegisterMap_x86.inline.hpp ! src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/zero/assembler_zero.inline.hpp ! src/hotspot/cpu/zero/continuationFreezeThaw_zero.inline.hpp ! src/hotspot/cpu/zero/icache_zero.hpp ! src/hotspot/cpu/zero/smallRegisterMap_zero.inline.hpp ! src/hotspot/cpu/zero/stackChunkFrameStream_zero.inline.hpp ! src/hotspot/cpu/zero/stubRoutines_zero.hpp ! src/hotspot/os/aix/libodm_aix.cpp ! src/hotspot/os/aix/libperfstat_aix.hpp ! src/hotspot/os/aix/osThread_aix.hpp ! src/hotspot/os/aix/os_aix.hpp ! src/hotspot/os/linux/gc/z/zSyscall_linux.hpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/os/linux/os_linux.inline.hpp ! src/hotspot/os/linux/procMapsParser.hpp ! src/hotspot/os/posix/include/jvm_md.h ! src/hotspot/os/posix/signals_posix.hpp ! src/hotspot/os/posix/threadLocalStorage_posix.cpp ! src/hotspot/os/windows/gc/z/zSyscall_windows.hpp ! src/hotspot/os/windows/os_windows.hpp ! src/hotspot/os/windows/safefetch_windows.hpp ! src/hotspot/os_cpu/bsd_aarch64/icache_bsd_aarch64.hpp ! src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S ! src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S ! src/hotspot/os_cpu/linux_aarch64/icache_linux_aarch64.hpp ! src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S ! src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S ! src/hotspot/os_cpu/linux_ppc/gc/z/zSyscall_linux_ppc.hpp ! src/hotspot/os_cpu/linux_riscv/orderAccess_linux_riscv.hpp ! src/hotspot/os_cpu/windows_aarch64/icache_windows_aarch64.hpp ! src/hotspot/share/adlc/adlc.hpp ! src/hotspot/share/adlc/adlparse.hpp ! src/hotspot/share/asm/assembler.hpp ! src/hotspot/share/c1/c1_Canonicalizer.hpp ! src/hotspot/share/c1/c1_Defs.hpp ! src/hotspot/share/c1/c1_GraphBuilder.hpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_InstructionPrinter.hpp ! src/hotspot/share/c1/c1_LinearScan.hpp ! src/hotspot/share/c1/c1_Optimizer.hpp ! src/hotspot/share/c1/c1_RangeCheckElimination.hpp ! src/hotspot/share/cds/aotClassLinker.hpp ! src/hotspot/share/cds/aotMappedHeapLoader.inline.hpp ! src/hotspot/share/cds/aotStreamedHeapLoader.hpp ! src/hotspot/share/cds/aotThread.cpp ! src/hotspot/share/cds/lambdaFormInvokers.inline.hpp ! src/hotspot/share/ci/bcEscapeAnalyzer.hpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciInstance.hpp ! src/hotspot/share/ci/ciMetadata.hpp ! src/hotspot/share/ci/ciTypeFlow.hpp ! src/hotspot/share/ci/ciUtilities.inline.hpp ! src/hotspot/share/classfile/bytecodeAssembler.hpp ! src/hotspot/share/classfile/classLoaderDataGraph.hpp ! src/hotspot/share/classfile/classLoaderStats.hpp ! src/hotspot/share/classfile/defaultMethods.hpp ! src/hotspot/share/classfile/javaClassesImpl.hpp ! src/hotspot/share/classfile/vmClasses.hpp ! src/hotspot/share/code/codeBehaviours.hpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/compiledIC.hpp ! src/hotspot/share/code/dependencyContext.hpp ! src/hotspot/share/compiler/abstractCompiler.hpp ! src/hotspot/share/compiler/compileLog.hpp ! src/hotspot/share/compiler/compiler_globals.hpp ! src/hotspot/share/compiler/directivesParser.hpp ! src/hotspot/share/compiler/disassembler.hpp ! src/hotspot/share/compiler/methodMatcher.hpp ! src/hotspot/share/compiler/oopMap.hpp ! src/hotspot/share/compiler/oopMap.inline.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp ! src/hotspot/share/gc/g1/g1Allocator.hpp ! src/hotspot/share/gc/g1/g1Allocator.inline.hpp ! src/hotspot/share/gc/g1/g1AnalyticsSequences.inline.hpp ! src/hotspot/share/gc/g1/g1CardSet.inline.hpp ! src/hotspot/share/gc/g1/g1CardSetMemory.inline.hpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1CollectionSet.inline.hpp ! src/hotspot/share/gc/g1/g1CollectionSetCandidates.hpp ! src/hotspot/share/gc/g1/g1CollectionSetCandidates.inline.hpp ! src/hotspot/share/gc/g1/g1CollectionSetChooser.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.inline.hpp ! src/hotspot/share/gc/g1/g1EdenRegions.hpp ! src/hotspot/share/gc/g1/g1EvacStats.hpp ! src/hotspot/share/gc/g1/g1FullGCResetMetadataTask.hpp ! src/hotspot/share/gc/g1/g1FullGCScope.hpp ! src/hotspot/share/gc/g1/g1HeapRegionAttr.hpp ! src/hotspot/share/gc/g1/g1IHOPControl.hpp ! src/hotspot/share/gc/g1/g1MonitoringSupport.hpp ! src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.hpp ! src/hotspot/share/gc/g1/g1ParallelCleaning.hpp ! src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp ! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.hpp ! src/hotspot/share/gc/g1/g1RegionsOnNodes.hpp ! src/hotspot/share/gc/g1/g1RootProcessor.hpp ! src/hotspot/share/gc/g1/g1ServiceThread.hpp ! src/hotspot/share/gc/g1/g1SurvivorRegions.hpp ! src/hotspot/share/gc/g1/g1Trace.hpp ! src/hotspot/share/gc/g1/g1VMOperations.hpp ! src/hotspot/share/gc/parallel/objectStartArray.hpp ! src/hotspot/share/gc/parallel/parallel_globals.hpp ! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.hpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp ! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp ! src/hotspot/share/gc/parallel/psMemoryPool.hpp ! src/hotspot/share/gc/parallel/psOldGen.hpp ! src/hotspot/share/gc/parallel/psPromotionLAB.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.hpp ! src/hotspot/share/gc/parallel/psScavenge.hpp ! src/hotspot/share/gc/parallel/psVMOperations.hpp ! src/hotspot/share/gc/parallel/psVirtualspace.hpp ! src/hotspot/share/gc/parallel/psYoungGen.hpp ! src/hotspot/share/gc/parallel/spaceCounters.hpp ! src/hotspot/share/gc/parallel/vmStructs_parallelgc.hpp ! src/hotspot/share/gc/serial/cSpaceCounters.hpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/serialVMOperations.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.inline.hpp ! src/hotspot/share/gc/shared/adaptiveSizePolicy.hpp ! src/hotspot/share/gc/shared/barrierSet.hpp ! src/hotspot/share/gc/shared/barrierSetConfig.hpp ! src/hotspot/share/gc/shared/barrierSetConfig.inline.hpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp ! src/hotspot/share/gc/shared/collectedHeap.inline.hpp ! src/hotspot/share/gc/shared/collectorCounters.hpp ! src/hotspot/share/gc/shared/gcArguments.hpp ! src/hotspot/share/gc/shared/gcCause.hpp ! src/hotspot/share/gc/shared/gcHeapSummary.hpp ! src/hotspot/share/gc/shared/gcLocker.hpp ! src/hotspot/share/gc/shared/gcLogPrecious.hpp ! src/hotspot/share/gc/shared/gcPolicyCounters.hpp ! src/hotspot/share/gc/shared/gcThreadLocalData.hpp ! src/hotspot/share/gc/shared/gcTrace.hpp ! src/hotspot/share/gc/shared/gcVMOperations.hpp ! src/hotspot/share/gc/shared/genArguments.hpp ! src/hotspot/share/gc/shared/hSpaceCounters.hpp ! src/hotspot/share/gc/shared/oopStorage.hpp ! src/hotspot/share/gc/shared/parallelCleaning.hpp ! src/hotspot/share/gc/shared/partialArraySplitter.hpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp ! src/hotspot/share/gc/shared/scavengableNMethods.hpp ! src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupStat.hpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupThread.hpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/gc/shared/vmStructs_gc.hpp ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/gc/z/zArguments.hpp ! src/hotspot/share/gc/z/zBarrier.hpp ! src/hotspot/share/gc/z/zBarrierSet.hpp ! src/hotspot/share/gc/z/zBarrierSetNMethod.hpp ! src/hotspot/share/gc/z/zGeneration.hpp ! src/hotspot/share/gc/z/zGlobals.hpp ! src/hotspot/share/gc/z/zHeapIterator.hpp ! src/hotspot/share/gc/z/zMark.hpp ! src/hotspot/share/gc/z/zMark.inline.hpp ! src/hotspot/share/gc/z/zMarkContext.hpp ! src/hotspot/share/gc/z/zMarkContext.inline.hpp ! src/hotspot/share/gc/z/zNMethod.hpp ! src/hotspot/share/gc/z/zNMethodTableIteration.hpp ! src/hotspot/share/gc/z/zPageTable.hpp ! src/hotspot/share/gc/z/zRemembered.hpp ! src/hotspot/share/gc/z/zStat.hpp ! src/hotspot/share/gc/z/zThreadLocalData.hpp ! src/hotspot/share/gc/z/zUncoloredRoot.hpp ! src/hotspot/share/include/jmm.h ! src/hotspot/share/include/jvm_io.h ! src/hotspot/share/interpreter/bytecode.hpp ! src/hotspot/share/interpreter/bytecode.inline.hpp ! src/hotspot/share/interpreter/bytecodeHistogram.hpp ! src/hotspot/share/interpreter/bytecodeStream.hpp ! src/hotspot/share/interpreter/bytecodeTracer.hpp ! src/hotspot/share/interpreter/interpreter.hpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/interpreter/templateInterpreter.hpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.inline.hpp ! src/hotspot/share/interpreter/zero/zeroInterpreter.hpp ! src/hotspot/share/interpreter/zero/zeroInterpreterGenerator.hpp ! src/hotspot/share/jfr/leakprofiler/chains/dfsClosure.hpp ! src/hotspot/share/jfr/leakprofiler/chains/edgeQueue.hpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/eventEmitter.hpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp ! src/hotspot/share/jfr/leakprofiler/sampling/objectSample.hpp ! src/hotspot/share/jfr/metadata/jfrSerializer.hpp ! src/hotspot/share/jfr/recorder/jfrEventSetting.hpp ! src/hotspot/share/jfr/recorder/stacktrace/jfrStackFilterRegistry.hpp ! src/hotspot/share/jfr/recorder/storage/jfrStorageUtils.hpp ! src/hotspot/share/jfr/recorder/stringpool/jfrStringPoolWriter.hpp ! src/hotspot/share/jfr/support/jfrDeprecationEventWriter.hpp ! src/hotspot/share/jfr/support/jfrDeprecationManager.hpp ! src/hotspot/share/jfr/support/jfrObjectAllocationSample.hpp ! src/hotspot/share/jfr/support/jfrStackTraceMark.hpp ! src/hotspot/share/jfr/utilities/jfrBigEndian.hpp ! src/hotspot/share/jfr/utilities/jfrDoublyLinkedList.hpp ! src/hotspot/share/jfr/utilities/jfrEpochQueue.inline.hpp ! src/hotspot/share/jfr/utilities/jfrRelation.hpp ! src/hotspot/share/jfr/writers/jfrMemoryWriterHost.hpp ! src/hotspot/share/jfr/writers/jfrMemoryWriterHost.inline.hpp ! src/hotspot/share/jfr/writers/jfrStreamWriterHost.inline.hpp ! src/hotspot/share/jvmci/jvmci.hpp ! src/hotspot/share/jvmci/jvmciEnv.hpp ! src/hotspot/share/jvmci/jvmci_globals.hpp ! src/hotspot/share/jvmci/vmSymbols_jvmci.hpp ! src/hotspot/share/libadt/vectset.hpp ! src/hotspot/share/logging/log.hpp ! src/hotspot/share/logging/logConfiguration.hpp ! src/hotspot/share/logging/logDecorators.hpp ! src/hotspot/share/memory/heapInspection.hpp ! src/hotspot/share/memory/iterator.hpp ! src/hotspot/share/memory/memoryReserver.hpp ! src/hotspot/share/memory/metaspace/metablock.inline.hpp ! src/hotspot/share/memory/resourceArea.inline.hpp ! src/hotspot/share/nmt/mallocHeader.hpp ! src/hotspot/share/nmt/mallocHeader.inline.hpp ! src/hotspot/share/nmt/nativeCallStackPrinter.hpp ! src/hotspot/share/oops/access.hpp ! src/hotspot/share/oops/access.inline.hpp ! src/hotspot/share/oops/instanceClassLoaderKlass.hpp ! src/hotspot/share/oops/instanceMirrorKlass.hpp ! src/hotspot/share/oops/instanceRefKlass.hpp ! src/hotspot/share/oops/instanceStackChunkKlass.hpp ! src/hotspot/share/oops/metadata.hpp ! src/hotspot/share/oops/oopCast.inline.hpp ! src/hotspot/share/oops/oopHandle.inline.hpp ! src/hotspot/share/oops/stackChunkOop.hpp ! src/hotspot/share/oops/weakHandle.inline.hpp ! src/hotspot/share/opto/callGenerator.hpp ! src/hotspot/share/opto/countbitsnode.hpp ! src/hotspot/share/opto/escape.hpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/idealKit.hpp ! src/hotspot/share/opto/indexSet.hpp ! src/hotspot/share/opto/intrinsicnode.hpp ! src/hotspot/share/opto/multnode.hpp ! src/hotspot/share/opto/stringopts.hpp ! src/hotspot/share/opto/superwordVTransformBuilder.hpp ! src/hotspot/share/prims/foreignGlobals.inline.hpp ! src/hotspot/share/prims/jvmtiAgent.hpp ! src/hotspot/share/prims/jvmtiEventController.inline.hpp ! src/hotspot/share/prims/jvmtiImpl.hpp ! src/hotspot/share/prims/jvmtiTagMapTable.hpp ! src/hotspot/share/prims/jvmtiThreadState.inline.hpp ! src/hotspot/share/prims/methodHandles.hpp ! src/hotspot/share/prims/vectorSupport.hpp ! src/hotspot/share/prims/vmstorage.hpp ! src/hotspot/share/runtime/continuationHelper.inline.hpp ! src/hotspot/share/runtime/continuationJavaClasses.hpp ! src/hotspot/share/runtime/continuationWrapper.inline.hpp ! src/hotspot/share/runtime/flags/flagSetting.hpp ! src/hotspot/share/runtime/flags/jvmFlagLookup.hpp ! src/hotspot/share/runtime/handles.hpp ! src/hotspot/share/runtime/handles.inline.hpp ! src/hotspot/share/runtime/icache.hpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/java.hpp ! src/hotspot/share/runtime/jfieldIDWorkaround.hpp ! src/hotspot/share/runtime/monitorDeflationThread.hpp ! src/hotspot/share/runtime/notificationThread.hpp ! src/hotspot/share/runtime/park.hpp ! src/hotspot/share/runtime/perfDataTypes.hpp ! src/hotspot/share/runtime/safefetch.hpp ! src/hotspot/share/runtime/safepoint.hpp ! src/hotspot/share/runtime/safepointVerifiers.hpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/smallRegisterMap.inline.hpp ! src/hotspot/share/runtime/stackChunkFrameStream.hpp ! src/hotspot/share/runtime/stackChunkFrameStream.inline.hpp ! src/hotspot/share/runtime/stackWatermark.hpp ! src/hotspot/share/runtime/threadIdentifier.hpp ! src/hotspot/share/runtime/vframe.hpp ! src/hotspot/share/runtime/vmOperations.hpp ! src/hotspot/share/services/gcNotifier.hpp ! src/hotspot/share/services/threadIdTable.hpp ! src/hotspot/share/utilities/elfFile.hpp ! src/hotspot/share/utilities/macros.hpp ! src/hotspot/share/utilities/nativeCallStack.hpp ! src/hotspot/share/utilities/numberSeq.hpp ! src/hotspot/share/utilities/objectBitSet.hpp ! src/hotspot/share/utilities/objectBitSet.inline.hpp ! src/hotspot/share/utilities/resizableHashTable.hpp ! src/hotspot/share/utilities/ticks.hpp ! test/hotspot/jtreg/compiler/c2/cr7200264/TestIntVect.java ! test/hotspot/jtreg/compiler/c2/irTests/LShiftINodeIdealizationTests.java ! test/hotspot/jtreg/compiler/c2/irTests/LShiftLNodeIdealizationTests.java ! test/hotspot/jtreg/compiler/c2/irTests/RShiftINodeIdealizationTests.java ! test/hotspot/jtreg/compiler/c2/irTests/RShiftLNodeIdealizationTests.java ! test/hotspot/jtreg/compiler/c2/irTests/TestConv2BExpansion.java ! test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java ! test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java ! test/hotspot/jtreg/compiler/c2/irTests/TestLongRangeChecks.java ! test/hotspot/jtreg/compiler/c2/irTests/TestMinMaxIdentities.java ! test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java ! test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/AllocationMergesTests.java ! test/hotspot/jtreg/compiler/ciReplay/InliningBase.java ! test/hotspot/jtreg/compiler/compilercontrol/commands/OptionTest.java ! test/hotspot/jtreg/compiler/escapeAnalysis/TestFindInstMemRecursion.java ! test/hotspot/jtreg/compiler/escapeAnalysis/TestIterativeEA.java ! test/hotspot/jtreg/compiler/gcbarriers/TestZGCBarrierElision.java ! test/hotspot/jtreg/compiler/intrinsics/TestCompareUnsigned.java ! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestMultiplyToLen.java ! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestShift.java ! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestSquareToLen.java ! test/hotspot/jtreg/compiler/intrinsics/bmi/verifycode/BlsiTestI.java ! test/hotspot/jtreg/compiler/intrinsics/bmi/verifycode/BlsmskTestI.java ! test/hotspot/jtreg/compiler/intrinsics/bmi/verifycode/BlsrTestI.java ! test/hotspot/jtreg/compiler/intrinsics/klass/CastNullCheckDroppingsTest.java ! test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java ! test/hotspot/jtreg/compiler/jsr292/MHInlineTest.java ! test/hotspot/jtreg/compiler/jsr292/patches/java.base/java/lang/invoke/MethodHandleHelper.java ! test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java ! test/hotspot/jtreg/compiler/loopopts/TestLoopPredicationDivZeroCheck.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestCyclicDependency.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestScheduleReordersScalarMemops.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestUnorderedReductionPartialVectorization.java ! test/hotspot/jtreg/compiler/predicates/assertion/TestTemplateWithoutOpaqueLoopNodes.java ! test/hotspot/jtreg/compiler/splitif/TestSplitDivisionThroughPhi.java ! test/hotspot/jtreg/compiler/unsafe/OpaqueAccesses.java ! test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java ! test/hotspot/jtreg/compiler/vectorization/TestReverseBitsVector.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopArrayIndexComputeTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java ! test/hotspot/jtreg/compiler/whitebox/CompilerWhiteBoxTest.java ! test/hotspot/jtreg/gc/TestPLABAdaptToMinTLABSize.java ! test/hotspot/jtreg/gc/arguments/TestMinAndInitialSurvivorRatioFlags.java ! test/hotspot/jtreg/gc/arguments/TestNewRatioFlag.java ! test/hotspot/jtreg/gc/arguments/TestNewSizeFlags.java ! test/hotspot/jtreg/gc/arguments/TestSurvivorRatioFlag.java ! test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java ! test/hotspot/jtreg/gc/g1/pinnedobjs/TestPinnedOldObjectsEvacuation.java ! test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java ! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java ! test/hotspot/jtreg/gtest/AsyncLogGtest.java ! test/hotspot/jtreg/gtest/CompressedKlassGtest.java ! test/hotspot/jtreg/gtest/MetaspaceGtests.java ! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/hotspot/jtreg/runtime/CommandLine/VMOptionWarning.java ! test/hotspot/jtreg/runtime/ErrorHandling/UncaughtNativeExceptionTest.java ! test/hotspot/jtreg/runtime/ErrorHandling/libNativeException.c ! test/hotspot/jtreg/runtime/NMT/MallocRoundingReportTest.java ! test/hotspot/jtreg/runtime/NMT/MallocTestType.java ! test/hotspot/jtreg/runtime/NMT/MallocTrackingVerify.java ! test/hotspot/jtreg/runtime/NMT/ThreadedMallocTestType.java ! test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java ! test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java ! test/hotspot/jtreg/runtime/cds/ServiceLoaderTest.java ! test/hotspot/jtreg/runtime/cds/SharedStringsDedup.java ! test/hotspot/jtreg/runtime/cds/SharedStringsRunAuto.java ! test/hotspot/jtreg/runtime/cds/appcds/CreateAOTCacheVerifyError.java ! test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleWithCustomImageTest.java ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/PrintSharedArchiveAndExit.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/NestHostOldInf.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/PrintSharedArchiveAndExit.java ! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/src/com.foos/module-info.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsUtils.java ! test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintAll.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/server/ServerMemoryMXBean.java Changeset: 3fd7bde3 Branch: lworld Author: Sergey Bylokhov Date: 2025-12-31 07:21:32 +0000 URL: https://git.openjdk.org/valhalla/commit/3fd7bde31b965e027df423b3c2b5e1f360397195 8374378: Update copyright year to 2025 for jdk.internal.vm.ci in files where it was missed Reviewed-by: phh ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/BytecodeFrame.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/VirtualObject.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/site/Site.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledCode.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledCodeStream.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledNmethod.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJavaType.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotObjectConstant.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotObjectConstantImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaFieldImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaType.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedObjectType.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotSpeculationLog.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/VMField.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ConstantPool.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/EncodedSpeculationReason.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaMethod.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaType.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/JVMCIServiceLocator.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java Changeset: 36d2c277 Branch: lworld Author: Sergey Bylokhov Date: 2025-12-31 09:13:32 +0000 URL: https://git.openjdk.org/valhalla/commit/36d2c277c47767ba22208e2e49c46001642bd4f5 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 Reviewed-by: jpai ! src/java.base/aix/classes/sun/nio/ch/AixPollPort.java ! src/java.base/share/classes/com/sun/crypto/provider/RSACipher.java ! src/java.base/share/classes/java/lang/CharacterData00.java.template ! src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template ! src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java ! src/java.base/share/classes/java/lang/CharacterDataUndefined.java ! src/java.base/share/classes/java/lang/ThreadBuilders.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/ref/Cleaner.java ! src/java.base/share/classes/java/lang/ref/PhantomReference.java ! src/java.base/share/classes/java/lang/ref/SoftReference.java ! src/java.base/share/classes/java/lang/ref/WeakReference.java ! src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java ! src/java.base/share/classes/java/net/Authenticator.java ! src/java.base/share/classes/java/net/doc-files/net-properties.html ! src/java.base/share/classes/java/nio/charset/Charset-X-Coder.java.template ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/util/Collection.java ! src/java.base/share/classes/java/util/WeakHashMap.java ! src/java.base/share/classes/java/util/jar/JarInputStream.java ! src/java.base/share/classes/java/util/jar/JarVerifier.java ! src/java.base/share/classes/java/util/stream/GathererOp.java ! src/java.base/share/classes/java/util/zip/GZIPOutputStream.java ! src/java.base/share/classes/java/util/zip/snippet-files/Snippets.java ! src/java.base/share/classes/javax/security/auth/Subject.java ! src/java.base/share/classes/jdk/internal/ValueBased.java ! src/java.base/share/classes/jdk/internal/access/JavaUtilConcurrentTLRAccess.java ! src/java.base/share/classes/jdk/internal/classfile/components/snippet-files/PackageSnippets.java ! src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java ! src/java.base/share/classes/jdk/internal/foreign/abi/VMStorage.java ! src/java.base/share/classes/jdk/internal/icu/impl/Norm2AllModes.java ! src/java.base/share/classes/jdk/internal/icu/impl/UBiDiProps.java ! src/java.base/share/classes/jdk/internal/icu/impl/UCharacterProperty.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java ! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template ! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java ! src/java.base/share/classes/sun/net/www/MimeTable.java ! src/java.base/share/classes/sun/nio/ch/ThreadPool.java ! src/java.base/share/classes/sun/nio/fs/AbstractPoller.java ! src/java.base/share/classes/sun/nio/fs/Cancellable.java ! src/java.base/share/classes/sun/nio/fs/PollingWatchService.java ! src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java ! src/java.base/share/classes/sun/security/rsa/RSAPadding.java ! src/java.base/share/classes/sun/security/ssl/CertStatusExtension.java ! src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java ! src/java.base/share/classes/sun/security/ssl/CertificateStatus.java ! src/java.base/share/classes/sun/security/ssl/CookieExtension.java ! src/java.base/share/classes/sun/security/ssl/DHServerKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/ECPointFormatsExtension.java ! src/java.base/share/classes/sun/security/ssl/EncryptedExtensions.java ! src/java.base/share/classes/sun/security/ssl/ExtendedMasterSecretExtension.java ! src/java.base/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/java.base/share/classes/sun/security/ssl/HelloRequest.java ! src/java.base/share/classes/sun/security/ssl/HelloVerifyRequest.java ! src/java.base/share/classes/sun/security/ssl/MaxFragExtension.java ! src/java.base/share/classes/sun/security/ssl/NamedGroup.java ! src/java.base/share/classes/sun/security/ssl/PredefinedDHParameterSpecs.java ! src/java.base/share/classes/sun/security/ssl/PskKeyExchangeModesExtension.java ! src/java.base/share/classes/sun/security/ssl/RSAServerKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java ! src/java.base/share/classes/sun/security/ssl/ServerHelloDone.java ! src/java.base/share/classes/sun/security/ssl/ServerNameExtension.java ! src/java.base/unix/classes/java/lang/ProcessImpl.java ! src/java.base/unix/classes/sun/nio/ch/FileKey.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileKey.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileStore.java ! src/java.base/unix/native/jspawnhelper/jspawnhelper.c ! src/java.base/unix/native/launcher/relauncher.c ! src/java.base/unix/native/libjava/locale_str.h ! src/java.base/unix/native/libnet/Inet4AddressImpl.c ! src/java.base/unix/native/libnet/NetworkInterface.c ! src/java.base/unix/native/libnet/net_util_md.h ! src/java.base/windows/classes/java/lang/ProcessImpl.java ! src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! src/java.base/windows/classes/sun/nio/ch/PipeImpl.java ! src/java.base/windows/native/launcher/relauncher.c ! src/java.base/windows/native/libnet/NTLMAuthSequence.c Changeset: c6246d58 Branch: lworld Author: Sergey Bylokhov Date: 2025-12-31 10:04:45 +0000 URL: https://git.openjdk.org/valhalla/commit/c6246d58f72942b66cb0632186366f0b99402306 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed Reviewed-by: jpai ! test/benchmarks/micros-javac/src/main/java/org/openjdk/bench/langtools/javac/GroupJavacBenchmark.java ! test/benchmarks/micros-javac/src/main/java/org/openjdk/bench/langtools/javac/JavacBenchmark.java ! test/benchmarks/micros-javac/src/main/java/org/openjdk/bench/langtools/javac/SingleJavacBenchmark.java ! test/failure_handler/src/share/conf/mac.properties ! test/jaxp/javax/xml/jaxp/unittest/validation/ValidationTest.java ! test/jdk/java/lang/StringBuffer/ECoreIndexOf.java ! test/jdk/java/lang/Thread/virtual/YieldQueuing.java ! test/jdk/javax/management/mxbean/MXBeanInteropTest1.java ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java ! test/jdk/jdk/jfr/event/profiling/BaseTestFullStackTrace.java ! test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleNative.java ! test/jdk/jdk/jfr/event/profiling/TestCPUTimeSamplingLongPeriod.java ! test/langtools/jdk/javadoc/doclet/testHtmlLandmarkRegions/TestHtmlLandmarkRegions.java ! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownLinks.java ! test/langtools/jdk/javadoc/doclet/testRelativeLinks/pkg/C.java ! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTagWithModule.java ! test/langtools/jdk/javadoc/doclet/testTitleInHref/TestTitleInHref.java ! test/langtools/jdk/javadoc/tool/modules/Modules.java ! test/langtools/jdk/jshell/Compiler.java ! test/langtools/jdk/jshell/HighlightUITest.java ! test/langtools/jdk/jshell/Presets.java ! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java ! test/langtools/tools/jnativescan/TestMissingSystemClass.java ! test/langtools/tools/jnativescan/cases/classpath/missingsystem/App.java ! test/langtools/tools/lib/toolbox/JavacTask.java ! test/langtools/tools/lib/types/TypeHarness.java ! test/lib/jdk/test/lib/NetworkConfiguration.java ! test/lib/jdk/test/lib/SA/SATestUtils.java ! test/lib/jdk/test/lib/containers/docker/DockerRunOptions.java ! test/lib/jdk/test/lib/helpers/ClassFileInstaller.java ! test/lib/jdk/test/whitebox/code/CodeBlob.java ! test/make/autoconf/test.m4 ! test/micro/org/openjdk/bench/java/lang/FPComparison.java ! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayCriticalXorOpImpl.java ! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayElementsXorOpImpl.java ! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayForeignXorOpCriticalImpl.java ! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayForeignXorOpImpl.java ! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayForeignXorOpInitImpl.java ! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayRegionXorOpImpl.java ! test/micro/org/openjdk/bench/java/lang/foreign/xor/XorOp.java ! test/micro/org/openjdk/bench/java/lang/foreign/xor/libjnitest.c ! test/micro/org/openjdk/bench/vm/compiler/ArrayFill.java ! test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java ! test/micro/org/openjdk/bench/vm/compiler/VectorAliasing.java ! test/micro/org/openjdk/bench/vm/compiler/VectorReduction2.java Changeset: 97f4f003 Branch: lworld Author: Kevin Walls Date: 2025-12-31 15:50:17 +0000 URL: https://git.openjdk.org/valhalla/commit/97f4f003f4de19596de7f3d40295506edaaa30af 8373917: test/hotspot/jtreg/vmTestbase/nsk/monitoring: -iterations setting misused in tests Reviewed-by: lmesnik ! test/hotspot/jtreg/vmTestbase/nsk/share/runner/RunParams.java Changeset: a1a75ab6 Branch: lworld Author: Kevin Walls Date: 2025-12-31 16:26:09 +0000 URL: https://git.openjdk.org/valhalla/commit/a1a75ab6d1ca25fc88be75239670f5a011ea3053 8373642: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java failed Reviewed-by: cjplummer, syan ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters001/CollectionCounters001.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters005/TestDescription.java Changeset: 2447e071 Branch: lworld Author: Sergey Bylokhov Date: 2025-12-31 17:13:17 +0000 URL: https://git.openjdk.org/valhalla/commit/2447e07137b809aec9bdbb97f89b52488f5c02de 8374355: Update copyright year to 2025 for demo in files where it was missed Reviewed-by: aivanov ! src/demo/share/java2d/J2DBench/Makefile ! src/demo/share/java2d/J2DBench/build.xml ! src/demo/share/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java ! src/demo/share/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethodDescriptor.java ! src/demo/share/jfc/J2Ddemo/java2d/RunWindow.java ! src/demo/share/jfc/J2Ddemo/java2d/Tools.java ! src/demo/share/jfc/Stylepad/HelloWorld.java ! src/demo/share/jfc/SwingSet2/SwingSet2.java ! src/demo/share/jfc/SwingSet2/resources/swingset_de.properties Changeset: 2d1be8a9 Branch: lworld Author: Sergey Bylokhov Date: 2025-12-31 17:15:34 +0000 URL: https://git.openjdk.org/valhalla/commit/2d1be8a9e66fe82b60f7a22fd7796f0e54e60a5f 8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed Reviewed-by: aivanov ! src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java ! src/java.base/share/classes/java/lang/invoke/CallSite.java ! src/java.base/share/classes/sun/util/locale/UnicodeLocaleExtension.java ! src/java.base/share/native/libjava/VirtualThread.c ! src/java.base/share/native/libverify/check_code.c ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java ! src/java.compiler/share/classes/javax/tools/StandardLocation.java ! src/java.logging/share/classes/java/util/logging/ConsoleHandler.java ! src/java.management/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java ! src/java.management/share/classes/sun/management/MemoryImpl.java ! src/java.naming/share/classes/com/sun/jndi/ldap/DefaultResponseControlFactory.java ! src/java.naming/share/classes/javax/naming/ldap/PagedResultsControl.java ! src/java.rmi/share/classes/sun/rmi/log/LogInputStream.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/java.sql/share/classes/java/sql/Statement.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ICONST.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LDC.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ReferenceType.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_de.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegularExpression.java ! src/jdk.compiler/share/classes/com/sun/source/tree/UsesTree.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorSpecies.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/package-info.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap ! src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/util/InetAddressConverter.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/ExpressionExecuter.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/ExpressionResolver.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options ! src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c ! src/jdk.jdwp.agent/windows/native/libjdwp/proc_md.h ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ConstantMap.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/Dispatcher.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/FieldBuilder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/QueryResolver.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Query.java ! src/jdk.jfr/share/man/jfr.md ! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties ! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties ! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_ja.properties ! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_zh_CN.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Snippets.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ModuleDescriptorBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripJavaDebugAttributesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/IOContext.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties ! src/jdk.jshell/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java ! src/jdk.jshell/share/classes/jdk/jshell/OuterWrapMap.java ! src/jdk.jshell/share/classes/jdk/jshell/SnippetMaps.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java ! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/FreeInteractiveLayoutManager.java ! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalLayoutManager.java ! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/LayoutGraph.java ! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/LayoutMover.java ! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/LayoutNode.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/actions/EnableFreeLayoutAction.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/widgets/LineWidget.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogParser.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/MakeNotEntrantEvent.java Changeset: 481ef1de Branch: lworld Author: Sergey Bylokhov Date: 2025-12-31 17:53:43 +0000 URL: https://git.openjdk.org/valhalla/commit/481ef1de7a2721adfb8a48bb56513e617347c122 8374352: Update copyright year to 2025 for test/langtools/tools/javac/ in files where it was missed Reviewed-by: aivanov ! test/langtools/tools/javac/6457284/T6457284.java ! test/langtools/tools/javac/OverrideChecks/InterfaceImplements.java ! test/langtools/tools/javac/OverrideChecks/InterfaceOverride.java ! test/langtools/tools/javac/OverrideChecks/T6326485.java ! test/langtools/tools/javac/T4093617/T4093617.java ! test/langtools/tools/javac/T5092545.java ! test/langtools/tools/javac/T5105890.java ! test/langtools/tools/javac/T6180021/AbstractSub.java ! test/langtools/tools/javac/T6180021/Sub.java ! test/langtools/tools/javac/T6231246/T6231246.java ! test/langtools/tools/javac/T6266772.java ! test/langtools/tools/javac/T6358024.java ! test/langtools/tools/javac/T6358166.java ! test/langtools/tools/javac/T6361619.java ! test/langtools/tools/javac/T6395974.java ! test/langtools/tools/javac/T6397286.java ! test/langtools/tools/javac/T6458823/T6458823.java ! test/langtools/tools/javac/TryWithResources/InterruptedExceptionTest.java ! test/langtools/tools/javac/TryWithResources/TwrAvoidNullCheck.java ! test/langtools/tools/javac/TryWithResources/TwrSimpleClose.java ! test/langtools/tools/javac/annotations/crash_empty_enum_const/CrashEmptyEnumConstructorTest.java ! test/langtools/tools/javac/annotations/pos/AnnotationMethods.java ! test/langtools/tools/javac/api/6400303/T6400303.java ! test/langtools/tools/javac/api/6406133/T6406133.java ! test/langtools/tools/javac/api/6410643/T6410643.java ! test/langtools/tools/javac/api/6411310/T6411310.java ! test/langtools/tools/javac/api/6411333/T6411333.java ! test/langtools/tools/javac/api/6412656/T6412656.java ! test/langtools/tools/javac/api/6415780/T6415780.java ! test/langtools/tools/javac/api/6418694/T6418694.java ! test/langtools/tools/javac/api/6420409/T6420409.java ! test/langtools/tools/javac/api/6421111/T6421111.java ! test/langtools/tools/javac/api/6421756/T6421756.java ! test/langtools/tools/javac/api/6422215/T6422215.java ! test/langtools/tools/javac/api/6422327/T6422327.java ! test/langtools/tools/javac/api/6423003/T6423003.java ! test/langtools/tools/javac/api/6431257/T6431257.java ! test/langtools/tools/javac/api/6437999/T6437999.java ! test/langtools/tools/javac/api/6440333/T6440333.java ! test/langtools/tools/javac/api/6440528/T6440528.java ! test/langtools/tools/javac/api/6452876/T6452876.java ! test/langtools/tools/javac/api/6468404/T6468404.java ! test/langtools/tools/javac/api/6471599/Main.java ! test/langtools/tools/javac/api/6731573/T6731573.java ! test/langtools/tools/javac/api/7086261/T7086261.java ! test/langtools/tools/javac/api/8007344/Test.java ! test/langtools/tools/javac/api/DiagSpans.java ! test/langtools/tools/javac/api/Sibling.java ! test/langtools/tools/javac/api/T6257235.java ! test/langtools/tools/javac/api/T6258271.java ! test/langtools/tools/javac/api/T6265137.java ! test/langtools/tools/javac/api/T6306137.java ! test/langtools/tools/javac/api/T6357331.java ! test/langtools/tools/javac/api/T6358786.java ! test/langtools/tools/javac/api/T6397104.java ! test/langtools/tools/javac/api/T6400205.java ! test/langtools/tools/javac/api/T6400207.java ! test/langtools/tools/javac/api/T6407011.java ! test/langtools/tools/javac/api/TestEvalExpression.java ! test/langtools/tools/javac/api/TestGetTree.java ! test/langtools/tools/javac/api/TestJavacTask.java ! test/langtools/tools/javac/api/TestJavacTaskScanner.java ! test/langtools/tools/javac/api/TestOperators.java ! test/langtools/tools/javac/api/TestResolveIdent.java ! test/langtools/tools/javac/api/TestTreePath.java ! test/langtools/tools/javac/api/guide/Test.java ! test/langtools/tools/javac/api/taskListeners/EventsBalancedTest.java ! test/langtools/tools/javac/boxing/T6348760.java ! test/langtools/tools/javac/cast/5043020/T5043020.java ! test/langtools/tools/javac/cast/6302214/T6302214a.java ! test/langtools/tools/javac/diags/ArgTypeCompilerFactory.java ! test/langtools/tools/javac/diags/CheckResourceKeys.java ! test/langtools/tools/javac/diags/examples/AttemptToSynchronizeOnInstanceOfVbc.java ! test/langtools/tools/javac/diags/examples/ImportModule.java ! test/langtools/tools/javac/diags/examples/ImportModuleDoesNotRead/module-info.java ! test/langtools/tools/javac/diags/examples/ImportModuleDoesNotReadUnnamed.java ! test/langtools/tools/javac/diags/examples/ImportModuleNotFound.java ! test/langtools/tools/javac/diags/examples/ReturnBeforeSuperclassInit.java ! test/langtools/tools/javac/diags/examples/TryResourceThrowsInterruptedExc.java ! test/langtools/tools/javac/enum/6424358/T6424358.java ! test/langtools/tools/javac/enum/OkFinal.java ! test/langtools/tools/javac/enum/T5075242.java ! test/langtools/tools/javac/fatalErrors/ImproveFatalErrorHandling.java ! test/langtools/tools/javac/generics/5086027/T5086027pos.java ! test/langtools/tools/javac/generics/6192945/Method.java ! test/langtools/tools/javac/generics/6207386/Test.java ! test/langtools/tools/javac/generics/6227936/T6227936.java ! test/langtools/tools/javac/generics/6245699/T6245699c.java ! test/langtools/tools/javac/generics/6292765/T6292765.java ! test/langtools/tools/javac/generics/6332204/T6332204.java ! test/langtools/tools/javac/generics/6413682/TestPos.java ! test/langtools/tools/javac/generics/T6391995.java ! test/langtools/tools/javac/generics/inference/5073060/T5073060a.java ! test/langtools/tools/javac/generics/inference/5081782/Pos.java ! test/langtools/tools/javac/generics/inference/6215213/T6215213.java ! test/langtools/tools/javac/generics/inference/6278587/T6278587.java ! test/langtools/tools/javac/generics/inference/6302954/T6456971.java ! test/langtools/tools/javac/generics/inference/6359106/T6359106.java ! test/langtools/tools/javac/generics/rawOverride/AttributeSet.java ! test/langtools/tools/javac/generics/rawOverride/T6178365.java ! test/langtools/tools/javac/generics/typevars/4856983/T4856983.java ! test/langtools/tools/javac/generics/typevars/5060485/Method.java ! test/langtools/tools/javac/generics/typevars/5060485/Pos.java ! test/langtools/tools/javac/generics/wildcards/6330931/T6330931.java ! test/langtools/tools/javac/generics/wildcards/T5097548.java ! test/langtools/tools/javac/generics/wildcards/T5097548b.java ! test/langtools/tools/javac/jvm/6397652/T6397652.java ! test/langtools/tools/javac/lambda/LambdaExpr02.java ! test/langtools/tools/javac/lib/DPrinter.java ! test/langtools/tools/javac/modules/AddModulesTest.java ! test/langtools/tools/javac/modules/ConvenientAccessErrorsTest.java ! test/langtools/tools/javac/modules/EdgeCases.java ! test/langtools/tools/javac/modules/QueryBeforeEnter.java ! test/langtools/tools/javac/multicatch/Pos10.java ! test/langtools/tools/javac/overload/T4494762.java ! test/langtools/tools/javac/patterns/Domination.java ! test/langtools/tools/javac/patterns/PrettyTest.java ! test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java ! test/langtools/tools/javac/patterns/T8332463a.java ! test/langtools/tools/javac/patterns/T8332463b.java ! test/langtools/tools/javac/positions/T6402077.java ! test/langtools/tools/javac/positions/T6404194.java ! test/langtools/tools/javac/positions/TreeEndPosTest.java ! test/langtools/tools/javac/processing/6348499/T6348499.java ! test/langtools/tools/javac/processing/6359313/T6359313.java ! test/langtools/tools/javac/processing/6413690/T6413690.java ! test/langtools/tools/javac/processing/6414633/T6414633.java ! test/langtools/tools/javac/processing/6430209/T6430209.java ! test/langtools/tools/javac/processing/T6439826.java ! test/langtools/tools/javac/processing/T8142931.java ! test/langtools/tools/javac/processing/errors/TestReturnCode.java ! test/langtools/tools/javac/processing/filer/TestPackageInfo.java ! test/langtools/tools/javac/processing/model/6194785/T6194785.java ! test/langtools/tools/javac/processing/model/LocalInAnonymous.java ! test/langtools/tools/javac/processing/model/testgetallmembers/Main.java ! test/langtools/tools/javac/processing/options/TestNoteOnImplicitProcessing.java ! test/langtools/tools/javac/processing/options/Xprint.java ! test/langtools/tools/javac/processing/rounds/CompleteOnClosed.java ! test/langtools/tools/javac/scope/6225935/T6225935.java ! test/langtools/tools/javac/scope/6225935/T6381787.java ! test/langtools/tools/javac/scope/6225935/Test.java ! test/langtools/tools/javac/scope/6392998/T6392998.java ! test/langtools/tools/javac/sealed/SealedDiffConfigurationsTest.java ! test/langtools/tools/javac/sym/ElementStructureTest.java ! test/langtools/tools/javac/tree/VarTree.java ! test/langtools/tools/javac/types/UnknownTypeTest.java ! test/langtools/tools/javac/unicode/FirstChar.java ! test/langtools/tools/javac/unit/T6198196.java ! test/langtools/tools/javac/unit/util/convert/EnclosingCandidates.java ! test/langtools/tools/javac/unit/util/list/AbstractList.java ! test/langtools/tools/javac/unit/util/list/FromArray.java ! test/langtools/tools/javac/util/filemanager/TestName.java Changeset: 96e5c270 Branch: lworld Author: Michael McMahon Date: 2025-12-31 22:05:31 +0000 URL: https://git.openjdk.org/valhalla/commit/96e5c270b4ca0ad2b47ef3c090cbbfe4661bfc22 8373893: Refactor networking http server tests to use JUnit Reviewed-by: djelinski ! test/jdk/com/sun/net/httpserver/BasicAuthenticatorRealm.java ! test/jdk/com/sun/net/httpserver/CreateHttpServerTest.java ! test/jdk/com/sun/net/httpserver/DateFormatterTest.java ! test/jdk/com/sun/net/httpserver/FilterTest.java ! test/jdk/com/sun/net/httpserver/HeadersTest.java ! test/jdk/com/sun/net/httpserver/HttpContextTest.java ! test/jdk/com/sun/net/httpserver/HttpPrincipalTest.java ! test/jdk/com/sun/net/httpserver/HttpServerProviderTest.java ! test/jdk/com/sun/net/httpserver/InputNotRead.java ! test/jdk/com/sun/net/httpserver/UnmodifiableHeadersTest.java ! test/jdk/com/sun/net/httpserver/bugs/BasicAuthenticatorExceptionCheck.java ! test/jdk/com/sun/net/httpserver/simpleserver/CommandLineNegativeTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePortNotSpecifiedTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePositiveTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/FileServerHandlerTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/HttpsServerAlertTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/HttpsServerTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/IdempotencyAndCommutativityTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/MapToPathTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/OutputFilterTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/RequestTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/ServerMimeTypesResolutionTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/SimpleFileServerTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java ! test/jdk/com/sun/net/httpserver/simpleserver/ZipFileSystemTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/CommandLineNegativeTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/CommandLinePortNotSpecifiedTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/CommandLinePositiveTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java Changeset: 752f46d6 Branch: lworld Author: Eunbin Son Committer: Alan Bateman Date: 2026-01-01 07:49:30 +0000 URL: https://git.openjdk.org/valhalla/commit/752f46d66250dd44e1b13bbdbd86c70a33be3ac2 8374373: Typo in VirtualThreadSchedulerMXBean.setParallelism javadoc Reviewed-by: alanb ! src/jdk.management/share/classes/jdk/management/VirtualThreadSchedulerMXBean.java Changeset: d9bd300c Branch: lworld Author: Alan Bateman Date: 2026-01-01 07:49:49 +0000 URL: https://git.openjdk.org/valhalla/commit/d9bd300c6eddfd30a83e53e7ae03c47ea43a9e08 8374382: (aio) AsynchronousFileChannel writes wrong content using heap ByteBuffer when position != 0 Reviewed-by: jpai ! src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java + test/jdk/java/nio/channels/AsynchronousFileChannel/BufferPositions.java Changeset: 65af6bcb Branch: lworld Author: Kim Barrett Date: 2026-01-02 09:27:40 +0000 URL: https://git.openjdk.org/valhalla/commit/65af6bcb8f74484436b0331032260f2a646f203f 8374371: Failed assertion in G1HeapRegion gtest Reviewed-by: tschatzl, iwalulya ! test/hotspot/gtest/gc/g1/test_heapRegion.cpp Changeset: 2ea3c00e Branch: lworld Author: Prasanta Sadhukhan Date: 2026-01-02 09:48:40 +0000 URL: https://git.openjdk.org/valhalla/commit/2ea3c00e4f2a6e8c0a55039aee6fdfc8194a70a7 4337898: Serializing DefaultTableCellRenderer changes colors Reviewed-by: azvegint ! src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java + test/jdk/javax/swing/DefaultTableCellRenderer/DefRendererSerialize.java Changeset: 05d2f7f4 Branch: lworld Author: Prasanta Sadhukhan Date: 2026-01-02 09:53:04 +0000 URL: https://git.openjdk.org/valhalla/commit/05d2f7f4080f5cc6d3eef97878806e28773d6f70 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test Reviewed-by: serb, aivanov, dnguyen ! test/jdk/javax/swing/JMenuItem/MenuItemTest/bug6197830.java Changeset: efb79dc6 Branch: lworld Author: Kim Barrett Date: 2026-01-02 10:19:17 +0000 URL: https://git.openjdk.org/valhalla/commit/efb79dc6b4907ecf4e1bab3c393ee5cd5fe911a8 8374444: Fix simple -Wzero-as-null-pointer-constant warnings Reviewed-by: aboldtch ! src/hotspot/share/cds/aotMappedHeapWriter.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/opto/vectorization.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! test/hotspot/gtest/nmt/test_regions_tree.cpp Changeset: 34395124 Branch: lworld Author: Artur Barashev Date: 2026-01-02 13:28:15 +0000 URL: https://git.openjdk.org/valhalla/commit/34395124018c434b0bad534cb6f85452466fd404 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket Reviewed-by: djelinski, mpowers, ascarpino ! src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java Changeset: 2daf12ed Branch: lworld Author: Francesco Andreuzzi Date: 2026-01-02 14:51:37 +0000 URL: https://git.openjdk.org/valhalla/commit/2daf12edd24e641d4d7706d582994c2b3fe95e87 8374465: Spurious dot in documentation for JVMTI ClassLoad Reviewed-by: kbarrett ! src/hotspot/share/prims/jvmti.xml Changeset: 53824cf2 Branch: lworld Author: Leonid Mesnik Date: 2026-01-03 02:52:53 +0000 URL: https://git.openjdk.org/valhalla/commit/53824cf2a97adbc25d32bec0acaff24d105081f9 8343809: Add requires tag to mark tests that are incompatible with exploded image Reviewed-by: alanb, dholmes ! test/hotspot/jtreg/TEST.ROOT ! test/hotspot/jtreg/runtime/getSysPackage/GetSysPkgTest.java ! test/hotspot/jtreg/runtime/modules/ModulesSymLink.java ! test/hotspot/jtreg/runtime/modules/PatchModule/PatchModuleTraceCL.java ! test/jtreg-ext/requires/VMProps.java Changeset: 6eaabed5 Branch: lworld Author: Xiaohong Gong Date: 2026-01-05 01:54:31 +0000 URL: https://git.openjdk.org/valhalla/commit/6eaabed55ca4670d8c317f0a4323ccea4dd0b9ca 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently Reviewed-by: jiefu, jbhateja, erfang, qamai ! test/hotspot/jtreg/compiler/vectorapi/TestVectorOperationsWithPartialSize.java Changeset: 16303822 Branch: lworld Author: Matthias Baesken Date: 2026-01-05 08:27:37 +0000 URL: https://git.openjdk.org/valhalla/commit/163038222a371c07aff8bce50eee55bb389104d0 8373704: Improve "SocketException: Protocol family unavailable" message Reviewed-by: lucy, jpai ! src/java.base/unix/native/libnet/net_util_md.c ! src/java.base/windows/native/libnet/net_util_md.c Changeset: e676c9de Branch: lworld Author: Aleksey Shipilev Date: 2026-01-05 09:35:50 +0000 URL: https://git.openjdk.org/valhalla/commit/e676c9de3da3b820081cde1b11c0df3129787130 8357258: x86: Improve receiver type profiling reliability Reviewed-by: kvn, vlivanov ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.hpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/oops/methodData.hpp Changeset: eee58545 Branch: lworld Author: Daisuke Yamazaki Committer: Sean Mullan Date: 2026-01-05 13:19:32 +0000 URL: https://git.openjdk.org/valhalla/commit/eee58545c8342fc39b3bec5b38da6c01d92d05f2 8366058: Outdated comment in WinCAPISeedGenerator Reviewed-by: mullan ! src/java.base/windows/native/libjava/WinCAPISeedGenerator.c Changeset: 6ae3e064 Branch: lworld Author: Roland Westrelin Date: 2026-01-05 14:02:41 +0000 URL: https://git.openjdk.org/valhalla/commit/6ae3e064352a56c5be140fba1ad6d040219432b0 8373508: C2: sinking CreateEx out of loop breaks the graph Reviewed-by: chagedorn, dlong ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/loopopts/TestCreateExSunkOutOfLoop.java + test/hotspot/jtreg/compiler/loopopts/TestCreateExSunkOutOfLoop2.java Changeset: 4458cab4 Branch: lworld Author: Beno?t Maillard Date: 2026-01-05 14:39:38 +0000 URL: https://git.openjdk.org/valhalla/commit/4458cab4b0063f39333392321f542d0aa0db490d 8367627: C2: Missed Ideal() optimization opportunity with MemBar Reviewed-by: chagedorn, epeter ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/node.cpp + test/hotspot/jtreg/compiler/c2/igvn/TestMissingOptMemBarRemovePrecedentEdge.java Changeset: 27dbdec2 Branch: lworld Author: Naoto Sato Date: 2026-01-05 17:16:35 +0000 URL: https://git.openjdk.org/valhalla/commit/27dbdec297fc8030812f7290a7601b6a99defb46 8374217: Remove IO.java test from AOT ProblemList Reviewed-by: jpai, iklam ! test/jdk/ProblemList-AotJdk.txt ! test/jdk/java/lang/IO/IO.java Changeset: 5fd095fb Branch: lworld Author: Patricio Chilano Mateo Date: 2026-01-05 19:16:40 +0000 URL: https://git.openjdk.org/valhalla/commit/5fd095fb9b8f1d2000760519d42d7d0068b82651 8372591: assert(!current->cont_fastpath() || freeze.check_valid_fast_path()) failed Reviewed-by: dholmes, alanb, rrich, fyang ! src/hotspot/share/runtime/sharedRuntime.cpp + test/jdk/jdk/internal/vm/Continuation/OSRWithManyLocals.java Changeset: fa8ea6b3 Branch: lworld Author: Alex Menkov Date: 2026-01-05 19:55:54 +0000 URL: https://git.openjdk.org/valhalla/commit/fa8ea6b32d463a84affa529d37cfb97280503fc6 8374168: Resolve disabled warnings in JDWP agent Reviewed-by: cjplummer, sspitsyn, erikj ! make/modules/jdk.jdwp.agent/Lib.gmk ! src/jdk.jdwp.agent/share/native/libjdwp/EventRequestImpl.c ! src/jdk.jdwp.agent/share/native/libjdwp/SDE.c ! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c ! src/jdk.jdwp.agent/share/native/libjdwp/error_messages.c ! src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c ! src/jdk.jdwp.agent/share/native/libjdwp/inStream.c ! src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c ! src/jdk.jdwp.agent/share/native/libjdwp/utf_util.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.h Changeset: de81d389 Branch: lworld Author: David Holmes Date: 2026-01-05 20:09:49 +0000 URL: https://git.openjdk.org/valhalla/commit/de81d38995356a2e8528a419ebd445e79cd136d1 8374456: JVM crashes with "assert(resolved_method->method_holder()->is_linked()) failed: must be linked" when run with large value for PreallocatedOutOfMemoryErrorCount Reviewed-by: coleenp ! src/hotspot/share/runtime/globals.hpp Changeset: d063c954 Branch: lworld Author: Aleksey Shipilev Date: 2026-01-06 07:40:36 +0000 URL: https://git.openjdk.org/valhalla/commit/d063c9546b4a500f4c76fcd01442c2b7281f6d65 8374507: GHA: Limit debug symbols generation to conserve disk space Reviewed-by: erikj ! .github/workflows/build-alpine-linux.yml ! .github/workflows/build-cross-compile.yml ! .github/workflows/build-linux.yml ! .github/workflows/build-macos.yml ! .github/workflows/build-windows.yml Changeset: 2fbc4162 Branch: lworld Author: Fabian Meumertzheim Committer: Alan Bateman Date: 2026-01-06 08:09:42 +0000 URL: https://git.openjdk.org/valhalla/commit/2fbc4162e808f14b6114499f49db3e6ef1590f24 8374441: (fs) FileSystemProvider.readAttributesIfExists throws "Not a directory" when element in path is not directory should return null for ENOTDIR (unix) Reviewed-by: alanb ! src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java ! test/jdk/java/nio/file/Files/NotADirectory.java Changeset: 2cb228e1 Branch: lworld Author: Emanuel Peter Date: 2026-01-06 08:51:40 +0000 URL: https://git.openjdk.org/valhalla/commit/2cb228e142369ec73d768d8a69653a984b1c5908 8374489: Template Library: need to tag Float16.float16ToRawShortBits as having non-deterministic result because of multiple NaN bit patterns Reviewed-by: chagedorn, kvn ! test/hotspot/jtreg/compiler/lib/template_framework/library/Operations.java Changeset: 3a80c639 Branch: lworld Author: Volkan Yazici Date: 2026-01-06 10:21:14 +0000 URL: https://git.openjdk.org/valhalla/commit/3a80c639d804a0697b8eb477fe4c96407709449b 8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe "SimpleSSLContext" methods Reviewed-by: jpai ! test/jdk/java/net/httpclient/ALPNProxyFailureTest.java ! test/jdk/java/net/httpclient/AbstractNoBody.java ! test/jdk/java/net/httpclient/AbstractThrowingPublishers.java ! test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java ! test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java ! test/jdk/java/net/httpclient/AggregateRequestBodyTest.java ! test/jdk/java/net/httpclient/AltServiceUsageTest.java ! test/jdk/java/net/httpclient/AsFileDownloadTest.java ! test/jdk/java/net/httpclient/AsyncExecutorShutdown.java ! test/jdk/java/net/httpclient/AsyncShutdownNow.java ! test/jdk/java/net/httpclient/AuthFilterCacheTest.java ! test/jdk/java/net/httpclient/BasicAuthTest.java ! test/jdk/java/net/httpclient/BasicHTTP2Test.java ! test/jdk/java/net/httpclient/BasicHTTP3Test.java ! test/jdk/java/net/httpclient/BasicRedirectTest.java ! test/jdk/java/net/httpclient/BufferSize1Test.java ! test/jdk/java/net/httpclient/CancelRequestTest.java ! test/jdk/java/net/httpclient/CancelStreamedBodyTest.java ! test/jdk/java/net/httpclient/CancelledPartialResponseTest.java ! test/jdk/java/net/httpclient/CancelledResponse.java ! test/jdk/java/net/httpclient/CancelledResponse2.java ! test/jdk/java/net/httpclient/ConcurrentResponses.java ! test/jdk/java/net/httpclient/ContentLengthHeaderTest.java ! test/jdk/java/net/httpclient/CookieHeaderTest.java ! test/jdk/java/net/httpclient/CustomRequestPublisher.java ! test/jdk/java/net/httpclient/CustomResponseSubscriber.java ! test/jdk/java/net/httpclient/DependentActionsTest.java ! test/jdk/java/net/httpclient/DependentPromiseActionsTest.java ! test/jdk/java/net/httpclient/DigestEchoClient.java ! test/jdk/java/net/httpclient/DurationOverflowTest.java ! test/jdk/java/net/httpclient/EmptyAuthenticate.java ! test/jdk/java/net/httpclient/EncodedCharsInURI.java ! test/jdk/java/net/httpclient/EscapedOctetsInURI.java ! test/jdk/java/net/httpclient/ExecutorShutdown.java ! test/jdk/java/net/httpclient/ExpectContinue.java ! test/jdk/java/net/httpclient/FileChannelPublisherTest.java ! test/jdk/java/net/httpclient/FilePublisherTest.java ! test/jdk/java/net/httpclient/FlowAdapterPublisherTest.java ! test/jdk/java/net/httpclient/FlowAdapterSubscriberTest.java ! test/jdk/java/net/httpclient/ForbiddenHeadTest.java ! test/jdk/java/net/httpclient/GZIPInputStreamTest.java ! test/jdk/java/net/httpclient/HeadTest.java ! test/jdk/java/net/httpclient/HeadersLowerCaseTest.java ! test/jdk/java/net/httpclient/HttpClientAuthRetryLimitTest.java ! test/jdk/java/net/httpclient/HttpClientBuilderTest.java ! test/jdk/java/net/httpclient/HttpClientClose.java ! test/jdk/java/net/httpclient/HttpClientLocalAddrTest.java ! test/jdk/java/net/httpclient/HttpClientSNITest.java ! test/jdk/java/net/httpclient/HttpClientShutdown.java ! test/jdk/java/net/httpclient/HttpGetInCancelledFuture.java ! test/jdk/java/net/httpclient/HttpRedirectTest.java ! test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java ! test/jdk/java/net/httpclient/HttpResponseLimitingTest.java ! test/jdk/java/net/httpclient/HttpSlowServerTest.java ! test/jdk/java/net/httpclient/HttpVersionsTest.java ! test/jdk/java/net/httpclient/HttpsTunnelAuthTest.java ! test/jdk/java/net/httpclient/HttpsTunnelTest.java ! test/jdk/java/net/httpclient/ISO_8859_1_Test.java ! test/jdk/java/net/httpclient/IdleConnectionTimeoutTest.java ! test/jdk/java/net/httpclient/ImmutableFlowItems.java ! test/jdk/java/net/httpclient/ImmutableSSLSessionTest.java ! test/jdk/java/net/httpclient/InvalidInputStreamSubscriptionRequest.java ! test/jdk/java/net/httpclient/InvalidSSLContextTest.java ! test/jdk/java/net/httpclient/InvalidSubscriptionRequest.java ! test/jdk/java/net/httpclient/LargeResponseTest.java ! test/jdk/java/net/httpclient/LightWeightHttpServer.java ! test/jdk/java/net/httpclient/LineBodyHandlerTest.java ! test/jdk/java/net/httpclient/ManyRequests.java ! test/jdk/java/net/httpclient/ManyRequestsLegacy.java ! test/jdk/java/net/httpclient/MappingResponseSubscriber.java ! test/jdk/java/net/httpclient/MaxStreams.java ! test/jdk/java/net/httpclient/NonAsciiCharsInURI.java ! test/jdk/java/net/httpclient/PathSubscriber/BodyHandlerOfFileDownloadTest.java ! test/jdk/java/net/httpclient/PathSubscriber/BodyHandlerOfFileTest.java ! test/jdk/java/net/httpclient/PathSubscriber/BodySubscriberOfFileTest.java ! test/jdk/java/net/httpclient/PlainConnectionLockTest.java ! test/jdk/java/net/httpclient/ProxySelectorTest.java ! test/jdk/java/net/httpclient/ProxyTest.java ! test/jdk/java/net/httpclient/RedirectMethodChange.java ! test/jdk/java/net/httpclient/RedirectTimeoutTest.java ! test/jdk/java/net/httpclient/RedirectWithCookie.java ! test/jdk/java/net/httpclient/Response1xxTest.java ! test/jdk/java/net/httpclient/Response204V2Test.java ! test/jdk/java/net/httpclient/ResponseBodyBeforeError.java ! test/jdk/java/net/httpclient/ResponsePublisher.java ! test/jdk/java/net/httpclient/RetryWithCookie.java ! test/jdk/java/net/httpclient/ServerCloseTest.java ! test/jdk/java/net/httpclient/ShortResponseBody.java ! test/jdk/java/net/httpclient/ShutdownNow.java ! test/jdk/java/net/httpclient/SmokeTest.java ! test/jdk/java/net/httpclient/SpecialHeadersTest.java ! test/jdk/java/net/httpclient/SplitResponse.java ! test/jdk/java/net/httpclient/StreamingBody.java ! test/jdk/java/net/httpclient/TimeoutBasic.java ! test/jdk/java/net/httpclient/TimeoutResponseTestSupport.java ! test/jdk/java/net/httpclient/TlsContextTest.java ! test/jdk/java/net/httpclient/UnauthorizedTest.java ! test/jdk/java/net/httpclient/UnknownBodyLengthTest.java ! test/jdk/java/net/httpclient/UserAuthWithAuthenticator.java ! test/jdk/java/net/httpclient/UserCookieTest.java ! test/jdk/java/net/httpclient/http2/BadHeadersTest.java ! test/jdk/java/net/httpclient/http2/BasicTest.java ! test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java ! test/jdk/java/net/httpclient/http2/ConnectionReuseTest.java ! test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java ! test/jdk/java/net/httpclient/http2/ErrorTest.java ! test/jdk/java/net/httpclient/http2/FixedThreadPoolTest.java ! test/jdk/java/net/httpclient/http2/H2GoAwayTest.java ! test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java ! test/jdk/java/net/httpclient/http2/NoBodyTest.java ! test/jdk/java/net/httpclient/http2/ProxyTest2.java ! test/jdk/java/net/httpclient/http2/SimpleGet.java ! test/jdk/java/net/httpclient/http2/StreamFlowControlTest.java ! test/jdk/java/net/httpclient/http2/UserInfoTest.java ! test/jdk/java/net/httpclient/http3/BadCipherSuiteErrorTest.java ! test/jdk/java/net/httpclient/http3/GetHTTP3Test.java ! test/jdk/java/net/httpclient/http3/H3BadHeadersTest.java ! test/jdk/java/net/httpclient/http3/H3BasicTest.java ! test/jdk/java/net/httpclient/http3/H3ConcurrentPush.java ! test/jdk/java/net/httpclient/http3/H3ConnectionPoolTest.java ! test/jdk/java/net/httpclient/http3/H3DataLimitsTest.java ! test/jdk/java/net/httpclient/http3/H3ErrorHandlingTest.java ! test/jdk/java/net/httpclient/http3/H3FixedThreadPoolTest.java ! test/jdk/java/net/httpclient/http3/H3GoAwayTest.java ! test/jdk/java/net/httpclient/http3/H3HeaderSizeLimitTest.java ! test/jdk/java/net/httpclient/http3/H3HeadersEncoding.java ! test/jdk/java/net/httpclient/http3/H3IdleExceedsQuicIdleTimeout.java ! test/jdk/java/net/httpclient/http3/H3ImplicitPushCancel.java ! test/jdk/java/net/httpclient/http3/H3InsertionsLimitTest.java ! test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java ! test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java ! test/jdk/java/net/httpclient/http3/H3MaxInitialTimeoutTest.java ! test/jdk/java/net/httpclient/http3/H3MemoryHandlingTest.java ! test/jdk/java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java ! test/jdk/java/net/httpclient/http3/H3ProxyTest.java ! test/jdk/java/net/httpclient/http3/H3PushCancel.java ! test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java ! test/jdk/java/net/httpclient/http3/H3QuicVTTest.java ! test/jdk/java/net/httpclient/http3/H3RedirectTest.java ! test/jdk/java/net/httpclient/http3/H3RequestRejectedTest.java ! test/jdk/java/net/httpclient/http3/H3ServerPush.java ! test/jdk/java/net/httpclient/http3/H3ServerPushCancel.java ! test/jdk/java/net/httpclient/http3/H3ServerPushTest.java ! test/jdk/java/net/httpclient/http3/H3ServerPushWithDiffTypes.java ! test/jdk/java/net/httpclient/http3/H3SimpleGet.java ! test/jdk/java/net/httpclient/http3/H3SimplePost.java ! test/jdk/java/net/httpclient/http3/H3SimpleTest.java ! test/jdk/java/net/httpclient/http3/H3StopSendingTest.java ! test/jdk/java/net/httpclient/http3/H3StreamLimitReachedTest.java ! test/jdk/java/net/httpclient/http3/H3Timeout.java ! test/jdk/java/net/httpclient/http3/H3UserInfoTest.java ! test/jdk/java/net/httpclient/http3/HTTP3NoBodyTest.java ! test/jdk/java/net/httpclient/http3/Http3ExpectContinueTest.java ! test/jdk/java/net/httpclient/http3/PostHTTP3Test.java ! test/jdk/java/net/httpclient/http3/StopSendingTest.java ! test/jdk/java/net/httpclient/http3/StreamLimitTest.java ! test/jdk/java/net/httpclient/quic/KeyUpdateTest.java ! test/jdk/java/net/httpclient/quic/PacketLossTest.java ! test/jdk/java/net/httpclient/quic/QuicRequestResponseTest.java ! test/jdk/java/net/httpclient/quic/StatelessResetReceiptTest.java ! test/jdk/java/net/httpclient/quic/VersionNegotiationTest.java ! test/jdk/java/net/httpclient/quic/tls/QuicTLSEngineBadParametersTest.java ! test/jdk/java/net/httpclient/quic/tls/QuicTLSEngineFailedALPNTest.java ! test/jdk/java/net/httpclient/quic/tls/QuicTLSEngineMissingParametersTest.java ! test/jdk/java/net/httpclient/websocket/HandshakeUrlEncodingTest.java ! test/jdk/java/net/httpclient/websocket/WSHandshakeExceptionTest.java ! test/jdk/java/net/httpclient/websocket/WebSocketProxyTest.java ! test/jdk/java/net/httpclient/whitebox/AltSvcFrameTest.java ! test/jdk/java/net/httpclient/whitebox/AltSvcRegistryTest.java ! test/jdk/java/net/httpclient/whitebox/FlowTestDriver.java ! test/jdk/java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java ! test/jdk/java/net/httpclient/whitebox/SSLFlowDelegateTestDriver.java ! test/jdk/java/net/httpclient/whitebox/SSLTubeTestDriver.java ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/AbstractSSLTubeTest.java ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLFlowDelegateTest.java ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLTubeTest.java - test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java + test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java Changeset: 938bbd5b Branch: lworld Author: Christian Hagedorn Date: 2026-01-06 10:23:45 +0000 URL: https://git.openjdk.org/valhalla/commit/938bbd5b604e990514b64a0451ed1bceb07eb23b 8374518: C1: Remove dead LinearScanStatistic::Counter::counter_fpu_stack Reviewed-by: thartmann, mdoerr ! src/hotspot/share/c1/c1_LinearScan.hpp + test/hotspot/jtreg/compiler/c1/TestCITimeCountLinearScan.java Changeset: 5df183be Branch: lworld Author: Johny Jose Committer: Sean Coffey Date: 2026-01-06 10:36:41 +0000 URL: https://git.openjdk.org/valhalla/commit/5df183be6c484d8f9635fac149caf5e2079c5561 8373476: (tz) Update Timezone Data to 2025c Reviewed-by: coffeys, naoto ! src/java.base/share/data/tzdata/VERSION ! src/java.base/share/data/tzdata/africa ! src/java.base/share/data/tzdata/antarctica ! src/java.base/share/data/tzdata/asia ! src/java.base/share/data/tzdata/australasia ! src/java.base/share/data/tzdata/europe ! src/java.base/share/data/tzdata/iso3166.tab ! src/java.base/share/data/tzdata/leapseconds ! src/java.base/share/data/tzdata/northamerica ! src/java.base/share/data/tzdata/southamerica ! test/jdk/java/util/TimeZone/TimeZoneData/VERSION Changeset: 532a0a65 Branch: lworld Author: Fernando Guallini Date: 2026-01-06 10:53:27 +0000 URL: https://git.openjdk.org/valhalla/commit/532a0a65b130e1fbe74ccbd16cdeed258cc2c245 8372950: Pem.pemEncoded should cache the Pattern Reviewed-by: ascarpino ! src/java.base/share/classes/sun/security/util/Pem.java Changeset: df5b49e6 Branch: lworld Author: Dingli Zhang Date: 2026-01-06 12:49:16 +0000 URL: https://git.openjdk.org/valhalla/commit/df5b49e604d3204c6383484ba3807d39abd0b0f1 8374525: RISC-V: Several masked float16 vector operations are not supported Reviewed-by: fjiang, fyang ! src/hotspot/cpu/riscv/riscv_v.ad Changeset: e27309f1 Branch: lworld Author: Kim Barrett Date: 2026-01-06 15:00:45 +0000 URL: https://git.openjdk.org/valhalla/commit/e27309f10d32695972f468df17b2535d36a746a2 8374350: Convert hotspot gtests to use Atomic Reviewed-by: aboldtch, iwalulya ! test/hotspot/gtest/cds/test_archiveWorkers.cpp ! test/hotspot/gtest/gc/g1/test_g1BatchedGangTask.cpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp ! test/hotspot/gtest/gc/g1/test_stressCommitUncommit.cpp ! test/hotspot/gtest/gc/shared/test_bufferNodeAllocator.cpp ! test/hotspot/gtest/utilities/test_concurrentHashtable.cpp ! test/hotspot/gtest/utilities/test_globalCounter_nested.cpp ! test/hotspot/gtest/utilities/test_singleWriterSynchronizer.cpp ! test/hotspot/gtest/utilities/test_waitBarrier.cpp Changeset: 32144282 Branch: lworld Author: Kim Barrett Date: 2026-01-06 15:05:29 +0000 URL: https://git.openjdk.org/valhalla/commit/3214428203642e986c47eabc29ebdea93016b2c5 8374446: Fix -Wzero-as-null-pointer-constant warnings in test_compressedKlass.cpp Reviewed-by: dholmes ! test/hotspot/gtest/oops/test_compressedKlass.cpp Changeset: c611da25 Branch: lworld Author: Leonid Mesnik Date: 2026-01-06 15:48:53 +0000 URL: https://git.openjdk.org/valhalla/commit/c611da257f69e9c9b178b85cb705a4b0a42545ac 8374483: Eliminate :serviceability_ttf_virtual group and mark svc non-virtual tests with requires Reviewed-by: syan, dholmes ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/breakpoint01.java ! test/hotspot/jtreg/serviceability/jvmti/events/ClassLoad/classload01/classload01.java ! test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/classprep01.java ! test/hotspot/jtreg/serviceability/jvmti/events/MethodEntry/mentry02/mentry02.java ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorWaited/monitorwaited01/monitorwaited01.java ! test/hotspot/jtreg/serviceability/jvmti/negative/thrinfo02/thrinfo02.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadInfo/thrinfo01/thrinfo01.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/BoundVThreadTest/BoundVThreadTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/ContinuationTest/ContinuationTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResumeAll/SuspendResumeAll.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTLSTest/VThreadTLSTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/VThreadTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadUnsupportedTest/VThreadUnsupportedTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/WaitNotifySuspendedVThreadTest/WaitNotifySuspendedVThreadTest.java Changeset: 136ac0d1 Branch: lworld Author: Naoto Sato Date: 2026-01-06 16:28:33 +0000 URL: https://git.openjdk.org/valhalla/commit/136ac0d10b92df8875f36c717e85595740b50ed2 8374433: java/util/Locale/PreserveTagCase.java does not run any tests Reviewed-by: iris, joehw, jlu ! test/jdk/java/util/Locale/PreserveTagCase.java Changeset: 3f652159 Branch: lworld Author: Daniel Gredler Date: 2026-01-06 16:52:21 +0000 URL: https://git.openjdk.org/valhalla/commit/3f6521596014510b75318b53ef4aef6b01056545 8374340: FontRenderContext instance variables should be final Reviewed-by: aivanov, aturbanov, prr, serb ! src/java.desktop/share/classes/java/awt/font/FontRenderContext.java Changeset: 62181b63 Branch: lworld Author: Daniel Gredler Date: 2026-01-06 17:56:43 +0000 URL: https://git.openjdk.org/valhalla/commit/62181b6363926968298ed37ac7780ee6d5ef0916 6562639: Wrong pixel bounds from TextLayout with white font Reviewed-by: serb, prr ! src/java.desktop/share/classes/java/awt/font/TextLine.java + test/jdk/java/awt/font/TextLayout/TestGetPixelBoundsWithColors.java Changeset: cdbc493a Branch: lworld Author: Kim Barrett Date: 2026-01-06 17:57:02 +0000 URL: https://git.openjdk.org/valhalla/commit/cdbc493a6d93a0da0db987245daa7b1d00cc8add 8374190: Convert ConcurrentHashTable atomic lists to use Atomic Reviewed-by: dholmes, iwalulya ! src/hotspot/share/utilities/concurrentHashTable.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp Changeset: fbc59ac0 Branch: lworld Author: Weijun Wang Date: 2026-01-06 18:05:27 +0000 URL: https://git.openjdk.org/valhalla/commit/fbc59ac0a1248066e9fbcfde3bd6a8eb4d60992c 8374555: No need for visible input warning in s.s.u.Password when not reading from System.in Reviewed-by: coffeys, hchao ! src/java.base/share/classes/sun/security/util/Password.java + test/jdk/sun/security/util/Password/EmptyIn.java Changeset: f1e0e0c2 Branch: lworld Author: Roger Riggs Date: 2026-01-06 18:07:43 +0000 URL: https://git.openjdk.org/valhalla/commit/f1e0e0c25ec62a543b9cbfabd630fc4ef17a8b5c 8374544: Add SleepyCat diagnostics for all platforms Reviewed-by: jpai ! test/jdk/java/lang/RuntimeTests/exec/SleepyCat.java = test/jdk/java/lang/RuntimeTests/exec/TEST.properties Changeset: 53300b4a Branch: lworld Author: Justin Lu Date: 2026-01-06 19:24:43 +0000 URL: https://git.openjdk.org/valhalla/commit/53300b4ac12240ea08227386412bfb90650c0aee 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG 8373829: Refactor test/jdk/java/time/tck tests to use JUnit over TestNG Reviewed-by: naoto = test/jdk/java/time/nonjunit/java/time/chrono/HijrahConfigCheck.java = test/jdk/java/time/nonjunit/java/time/chrono/HijrahConfigTest.java = test/jdk/java/time/nonjunit/java/time/chrono/hijrah-config-Hijrah-test_islamic-test.properties = test/jdk/java/time/nonjunit/java/time/zone/CustomZoneNameTest.java = test/jdk/java/time/nonjunit/java/time/zone/zoneProvider/META-INF/services/java.time.zone.ZoneRulesProvider = test/jdk/java/time/nonjunit/java/time/zone/zoneProvider/META-INF/services/java.util.spi.TimeZoneNameProvider = test/jdk/java/time/nonjunit/java/time/zone/zoneProvider/custom/CustomTimeZoneNameProvider.java = test/jdk/java/time/nonjunit/java/time/zone/zoneProvider/custom/CustomZoneRulesProvider.java ! test/jdk/java/time/tck/TEST.properties ! test/jdk/java/time/tck/java/time/AbstractDateTimeTest.java ! test/jdk/java/time/tck/java/time/AbstractTCKTest.java ! test/jdk/java/time/tck/java/time/TCKClock.java ! test/jdk/java/time/tck/java/time/TCKClock_Fixed.java ! test/jdk/java/time/tck/java/time/TCKClock_Offset.java ! test/jdk/java/time/tck/java/time/TCKClock_System.java ! test/jdk/java/time/tck/java/time/TCKClock_Tick.java ! test/jdk/java/time/tck/java/time/TCKDayOfWeek.java ! test/jdk/java/time/tck/java/time/TCKDuration.java ! test/jdk/java/time/tck/java/time/TCKInstant.java ! test/jdk/java/time/tck/java/time/TCKLocalDate.java ! test/jdk/java/time/tck/java/time/TCKLocalDateTime.java ! test/jdk/java/time/tck/java/time/TCKLocalTime.java ! test/jdk/java/time/tck/java/time/TCKMonth.java ! test/jdk/java/time/tck/java/time/TCKMonthDay.java ! test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java ! test/jdk/java/time/tck/java/time/TCKOffsetTime.java ! test/jdk/java/time/tck/java/time/TCKPeriod.java ! test/jdk/java/time/tck/java/time/TCKYear.java ! test/jdk/java/time/tck/java/time/TCKYearMonth.java ! test/jdk/java/time/tck/java/time/TCKZoneId.java ! test/jdk/java/time/tck/java/time/TCKZoneOffset.java ! test/jdk/java/time/tck/java/time/TCKZonedDateTime.java ! test/jdk/java/time/tck/java/time/TestIsoChronology.java ! test/jdk/java/time/tck/java/time/chrono/TCKChronoLocalDate.java ! test/jdk/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java ! test/jdk/java/time/tck/java/time/chrono/TCKChronoPeriod.java ! test/jdk/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/jdk/java/time/tck/java/time/chrono/TCKChronology.java ! test/jdk/java/time/tck/java/time/chrono/TCKHijrahChronology.java ! test/jdk/java/time/tck/java/time/chrono/TCKHijrahEra.java ! test/jdk/java/time/tck/java/time/chrono/TCKIsoChronology.java ! test/jdk/java/time/tck/java/time/chrono/TCKIsoEra.java ! test/jdk/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/jdk/java/time/tck/java/time/chrono/TCKJapaneseEra.java ! test/jdk/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/jdk/java/time/tck/java/time/chrono/TCKMinguoEra.java ! test/jdk/java/time/tck/java/time/chrono/TCKTestServiceLoader.java ! test/jdk/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java ! test/jdk/java/time/tck/java/time/chrono/TCKThaiBuddhistEra.java ! test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java ! test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTimeSerialization.java ! test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoZonedDateTimeSerialization.java ! test/jdk/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java ! test/jdk/java/time/tck/java/time/chrono/serial/TCKCopticSerialization.java ! test/jdk/java/time/tck/java/time/chrono/serial/TCKEraSerialization.java ! test/jdk/java/time/tck/java/time/format/TCKChronoPrinterParser.java ! test/jdk/java/time/tck/java/time/format/TCKDTFParsedInstant.java ! test/jdk/java/time/tck/java/time/format/TCKDateTimeFormatter.java ! test/jdk/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/jdk/java/time/tck/java/time/format/TCKDateTimeFormatters.java ! test/jdk/java/time/tck/java/time/format/TCKDateTimeParseResolver.java ! test/jdk/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java ! test/jdk/java/time/tck/java/time/format/TCKDecimalStyle.java ! test/jdk/java/time/tck/java/time/format/TCKFormatStyle.java ! test/jdk/java/time/tck/java/time/format/TCKInstantPrinterParser.java ! test/jdk/java/time/tck/java/time/format/TCKLocalizedFieldParser.java ! test/jdk/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java ! test/jdk/java/time/tck/java/time/format/TCKLocalizedOffsetIdPrinterParser.java ! test/jdk/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java ! test/jdk/java/time/tck/java/time/format/TCKOffsetPrinterParser.java ! test/jdk/java/time/tck/java/time/format/TCKPadPrinterParser.java ! test/jdk/java/time/tck/java/time/format/TCKResolverStyle.java ! test/jdk/java/time/tck/java/time/format/TCKSignStyle.java ! test/jdk/java/time/tck/java/time/format/TCKTextStyle.java ! test/jdk/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java ! test/jdk/java/time/tck/java/time/serial/TCKClockSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKDurationSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKInstantSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKLocalDateSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKMonthDaySerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKPeriodSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKYearMonthSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKYearSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKZoneIdSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java ! test/jdk/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java ! test/jdk/java/time/tck/java/time/temporal/TCKChronoField.java ! test/jdk/java/time/tck/java/time/temporal/TCKChronoUnit.java ! test/jdk/java/time/tck/java/time/temporal/TCKIsoFields.java ! test/jdk/java/time/tck/java/time/temporal/TCKJulianFields.java ! test/jdk/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java ! test/jdk/java/time/tck/java/time/temporal/TCKWeekFields.java ! test/jdk/java/time/tck/java/time/temporal/serial/TCKChronoFieldSerialization.java ! test/jdk/java/time/tck/java/time/temporal/serial/TCKChronoUnitSerialization.java ! test/jdk/java/time/tck/java/time/temporal/serial/TCKJulianFieldsSerialization.java ! test/jdk/java/time/tck/java/time/temporal/serial/TCKValueRangeSerialization.java ! test/jdk/java/time/tck/java/time/temporal/serial/TCKWeekFieldsSerialization.java ! test/jdk/java/time/tck/java/time/zone/TCKFixedZoneRules.java ! test/jdk/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/jdk/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/jdk/java/time/tck/java/time/zone/TCKZoneRules.java ! test/jdk/java/time/tck/java/time/zone/TCKZoneRulesProvider.java ! test/jdk/java/time/tck/java/time/zone/serial/TCKFixedZoneRulesSerialization.java ! test/jdk/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java ! test/jdk/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java ! test/jdk/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java ! test/jdk/java/time/test/TEST.properties ! test/jdk/java/time/test/java/time/AbstractTest.java ! test/jdk/java/time/test/java/time/TestClock_Fixed.java ! test/jdk/java/time/test/java/time/TestClock_Offset.java ! test/jdk/java/time/test/java/time/TestClock_System.java ! test/jdk/java/time/test/java/time/TestClock_Tick.java ! test/jdk/java/time/test/java/time/TestDuration.java ! test/jdk/java/time/test/java/time/TestInstant.java ! test/jdk/java/time/test/java/time/TestInstantSource.java ! test/jdk/java/time/test/java/time/TestLocalDate.java ! test/jdk/java/time/test/java/time/TestLocalDateTime.java ! test/jdk/java/time/test/java/time/TestLocalTime.java ! test/jdk/java/time/test/java/time/TestMonthDay.java ! test/jdk/java/time/test/java/time/TestOffsetDateTime.java ! test/jdk/java/time/test/java/time/TestOffsetDateTime_instants.java ! test/jdk/java/time/test/java/time/TestOffsetTime.java ! test/jdk/java/time/test/java/time/TestPeriod.java ! test/jdk/java/time/test/java/time/TestYear.java ! test/jdk/java/time/test/java/time/TestYearMonth.java ! test/jdk/java/time/test/java/time/TestZoneId.java ! test/jdk/java/time/test/java/time/TestZoneOffset.java ! test/jdk/java/time/test/java/time/TestZonedDateTime.java ! test/jdk/java/time/test/java/time/chrono/TestChronoLocalDate.java ! test/jdk/java/time/test/java/time/chrono/TestChronologyPerf.java ! test/jdk/java/time/test/java/time/chrono/TestEraDisplayName.java ! test/jdk/java/time/test/java/time/chrono/TestExampleCode.java ! test/jdk/java/time/test/java/time/chrono/TestIsoChronoImpl.java ! test/jdk/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java ! test/jdk/java/time/test/java/time/chrono/TestJapaneseChronology.java ! test/jdk/java/time/test/java/time/chrono/TestServiceLoader.java ! test/jdk/java/time/test/java/time/chrono/TestThaiBuddhistChronoImpl.java ! test/jdk/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java ! test/jdk/java/time/test/java/time/format/AbstractTestPrinterParser.java ! test/jdk/java/time/test/java/time/format/TestCharLiteralParser.java ! test/jdk/java/time/test/java/time/format/TestCharLiteralPrinter.java ! test/jdk/java/time/test/java/time/format/TestDateTimeFormatter.java ! test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java ! test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilderWithLocale.java ! test/jdk/java/time/test/java/time/format/TestDateTimeParsing.java ! test/jdk/java/time/test/java/time/format/TestDateTimeTextProvider.java ! test/jdk/java/time/test/java/time/format/TestDateTimeTextProviderWithLocale.java ! test/jdk/java/time/test/java/time/format/TestDecimalStyle.java ! test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java ! test/jdk/java/time/test/java/time/format/TestLocalizedOffsetPrinterParser.java ! test/jdk/java/time/test/java/time/format/TestLocalizedPattern.java ! test/jdk/java/time/test/java/time/format/TestNarrowMonthNamesAndDayNames.java ! test/jdk/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/jdk/java/time/test/java/time/format/TestNumberParser.java ! test/jdk/java/time/test/java/time/format/TestNumberPrinter.java ! test/jdk/java/time/test/java/time/format/TestPadPrinterDecorator.java ! test/jdk/java/time/test/java/time/format/TestReducedParser.java ! test/jdk/java/time/test/java/time/format/TestReducedPrinter.java ! test/jdk/java/time/test/java/time/format/TestSettingsParser.java ! test/jdk/java/time/test/java/time/format/TestStringLiteralParser.java ! test/jdk/java/time/test/java/time/format/TestStringLiteralPrinter.java ! test/jdk/java/time/test/java/time/format/TestTextParser.java ! test/jdk/java/time/test/java/time/format/TestTextParserWithLocale.java ! test/jdk/java/time/test/java/time/format/TestTextPrinter.java ! test/jdk/java/time/test/java/time/format/TestTextPrinterWithLocale.java ! test/jdk/java/time/test/java/time/format/TestUTCParse.java ! test/jdk/java/time/test/java/time/format/TestUnicodeExtension.java ! test/jdk/java/time/test/java/time/format/TestZoneOffsetParser.java ! test/jdk/java/time/test/java/time/format/TestZoneOffsetPrinter.java ! test/jdk/java/time/test/java/time/format/TestZoneTextPrinterParser.java ! test/jdk/java/time/test/java/time/temporal/TestChronoField.java ! test/jdk/java/time/test/java/time/temporal/TestChronoUnit.java ! test/jdk/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java ! test/jdk/java/time/test/java/time/temporal/TestDateTimeValueRange.java ! test/jdk/java/time/test/java/time/temporal/TestIsoFields.java ! test/jdk/java/time/test/java/time/temporal/TestIsoWeekFields.java ! test/jdk/java/time/test/java/time/temporal/TestJulianFields.java ! test/jdk/java/time/test/java/time/zone/TestFixedZoneRules.java ! test/jdk/java/time/test/java/time/zone/TestMutableZoneRules.java ! test/jdk/java/time/test/java/time/zone/TestZoneRules.java ! test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java ! test/jdk/java/time/test/java/util/TestFormatter.java Changeset: 7c979c14 Branch: lworld Author: David Beaumont Committer: Roger Riggs Date: 2026-01-06 19:54:49 +0000 URL: https://git.openjdk.org/valhalla/commit/7c979c148724ab7de650593caa22df8405d740e5 8374308: ImageBufferCache has no effect and can be removed Reviewed-by: alanb, rriggs ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java - src/java.base/share/classes/jdk/internal/jimage/ImageBufferCache.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java ! src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java Changeset: 6b3c1e0f Branch: lworld Author: Alexey Semenyuk Date: 2026-01-06 23:56:59 +0000 URL: https://git.openjdk.org/valhalla/commit/6b3c1e0f786a889d2ac25c8bd05f4d83e666425f 8373833: "error.cert.not.found" and "error.explicit-sign-no-cert" errors duplicate each other Reviewed-by: almatvee ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/SigningIdentityBuilder.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties ! test/jdk/tools/jpackage/share/ErrorTest.java Changeset: e10b1db1 Branch: lworld Author: David Simms Date: 2026-01-17 14:14:21 +0000 URL: https://git.openjdk.org/valhalla/commit/e10b1db180cbe41214a112d63fe5a526c4d1d981 Merge Merge jdk-27+4 ! .github/workflows/build-cross-compile.yml ! .github/workflows/build-linux.yml ! .github/workflows/build-macos.yml ! .github/workflows/build-windows.yml ! .github/workflows/main.yml ! make/Docs.gmk ! make/RunTestsPrebuiltSpec.gmk ! make/autoconf/hotspot.m4 ! make/autoconf/jdk-options.m4 ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp ! src/hotspot/cpu/ppc/continuationHelper_ppc.inline.hpp ! src/hotspot/cpu/riscv/continuationHelper_riscv.inline.hpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/continuationHelper_x86.inline.hpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/c1/c1_Canonicalizer.hpp ! src/hotspot/share/c1/c1_GraphBuilder.hpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_InstructionPrinter.hpp ! src/hotspot/share/c1/c1_RangeCheckElimination.hpp ! src/hotspot/share/cds/aotMappedHeapWriter.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciMetadata.hpp ! src/hotspot/share/ci/ciTypeFlow.hpp ! src/hotspot/share/classfile/classLoaderDataGraph.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/code/compiledIC.hpp ! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp ! src/hotspot/share/gc/shared/barrierSet.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp ! src/hotspot/share/gc/shared/collectedHeap.inline.hpp ! src/hotspot/share/gc/z/zBarrier.hpp ! src/hotspot/share/gc/z/zBarrierSet.hpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/memory/heapInspection.hpp ! src/hotspot/share/oops/access.hpp ! src/hotspot/share/oops/access.inline.hpp ! src/hotspot/share/oops/markWord.hpp ! src/hotspot/share/oops/methodData.hpp ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/callGenerator.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/escape.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/idealKit.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/multnode.hpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/prims/jvmtiTagMapTable.hpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/handles.hpp ! src/hotspot/share/runtime/handles.inline.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/jfieldIDWorkaround.hpp ! src/hotspot/share/runtime/reflection.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/stackChunkFrameStream.hpp ! src/hotspot/share/runtime/stackChunkFrameStream.inline.hpp ! src/hotspot/share/runtime/vmOperations.hpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/ref/PhantomReference.java ! src/java.base/share/classes/java/lang/ref/SoftReference.java ! src/java.base/share/classes/java/lang/ref/WeakReference.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java ! src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java ! src/java.base/share/native/libverify/check_code.c ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java ! test/hotspot/gtest/oops/test_markWord.cpp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/compiler/gcbarriers/TestZGCBarrierElision.java ! test/hotspot/jtreg/compiler/intrinsics/bmi/BMITestRunner.java ! test/hotspot/jtreg/runtime/ErrorHandling/UncaughtNativeExceptionTest.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java ! test/jdk/ProblemList-AotJdk.txt ! test/jdk/ProblemList.txt ! test/jdk/java/lang/module/ClassFileVersionsTest.java ! test/jdk/java/lang/module/ModuleDescriptorTest.java ! test/jtreg-ext/requires/VMProps.java ! test/langtools/tools/javac/patterns/PrettyTest.java ! test/lib/jdk/test/lib/NetworkConfiguration.java ! test/lib/jdk/test/lib/containers/docker/DockerRunOptions.java ! test/lib/jdk/test/whitebox/WhiteBox.java ! .github/workflows/build-cross-compile.yml ! .github/workflows/build-linux.yml ! .github/workflows/build-macos.yml ! .github/workflows/build-windows.yml ! .github/workflows/main.yml ! make/Docs.gmk ! make/RunTestsPrebuiltSpec.gmk ! make/autoconf/hotspot.m4 ! make/autoconf/jdk-options.m4 ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp ! src/hotspot/cpu/ppc/continuationHelper_ppc.inline.hpp ! src/hotspot/cpu/riscv/continuationHelper_riscv.inline.hpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/continuationHelper_x86.inline.hpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/c1/c1_Canonicalizer.hpp ! src/hotspot/share/c1/c1_GraphBuilder.hpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_InstructionPrinter.hpp ! src/hotspot/share/c1/c1_RangeCheckElimination.hpp ! src/hotspot/share/cds/aotMappedHeapWriter.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciMetadata.hpp ! src/hotspot/share/ci/ciTypeFlow.hpp ! src/hotspot/share/classfile/classLoaderDataGraph.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/code/compiledIC.hpp ! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp ! src/hotspot/share/gc/shared/barrierSet.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp ! src/hotspot/share/gc/shared/collectedHeap.inline.hpp ! src/hotspot/share/gc/z/zBarrier.hpp ! src/hotspot/share/gc/z/zBarrierSet.hpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/memory/heapInspection.hpp ! src/hotspot/share/oops/access.hpp ! src/hotspot/share/oops/access.inline.hpp ! src/hotspot/share/oops/markWord.hpp ! src/hotspot/share/oops/methodData.hpp ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/callGenerator.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/escape.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/idealKit.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/multnode.hpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/prims/jvmtiTagMapTable.hpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/handles.hpp ! src/hotspot/share/runtime/handles.inline.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/jfieldIDWorkaround.hpp ! src/hotspot/share/runtime/reflection.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/stackChunkFrameStream.hpp ! src/hotspot/share/runtime/stackChunkFrameStream.inline.hpp ! src/hotspot/share/runtime/vmOperations.hpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/ref/PhantomReference.java ! src/java.base/share/classes/java/lang/ref/SoftReference.java ! src/java.base/share/classes/java/lang/ref/WeakReference.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java ! src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java ! src/java.base/share/native/libverify/check_code.c ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java ! test/hotspot/gtest/oops/test_markWord.cpp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/compiler/gcbarriers/TestZGCBarrierElision.java ! test/hotspot/jtreg/compiler/intrinsics/bmi/BMITestRunner.java ! test/hotspot/jtreg/runtime/ErrorHandling/UncaughtNativeExceptionTest.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java ! test/jdk/ProblemList-AotJdk.txt ! test/jdk/ProblemList.txt ! test/jdk/java/lang/module/ClassFileVersionsTest.java ! test/jdk/java/lang/module/ModuleDescriptorTest.java ! test/jtreg-ext/requires/VMProps.java ! test/langtools/tools/javac/patterns/PrettyTest.java ! test/lib/jdk/test/lib/NetworkConfiguration.java ! test/lib/jdk/test/lib/containers/docker/DockerRunOptions.java ! test/lib/jdk/test/whitebox/WhiteBox.java From duke at openjdk.org Sun Jan 18 19:07:27 2026 From: duke at openjdk.org (Nicolai Parlog) Date: Sun, 18 Jan 2026 19:07:27 GMT Subject: [valhalla-docs] RFR: Fix wrong link to JEP 401 and add background info links In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 21:39:09 GMT, Nicolai Parlog wrote: > The link to JEP 401 pointed to 390. Unrelated, I also added a talk from Dan and an article from John to the list of background documents. Maybe they were intentionally left out, so no hard feelings if they're removed. ? And the GitHub editor added a trailing newline, I think. ? The important change (fixing the JEP link) was made in 7bb7fda, so I'll close this PR. ------------- PR Comment: https://git.openjdk.org/valhalla-docs/pull/16#issuecomment-3765614228 From duke at openjdk.org Sun Jan 18 19:07:28 2026 From: duke at openjdk.org (Nicolai Parlog) Date: Sun, 18 Jan 2026 19:07:28 GMT Subject: [valhalla-docs] Withdrawn: Fix wrong link to JEP 401 and add background info links In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 21:39:09 GMT, Nicolai Parlog wrote: > The link to JEP 401 pointed to 390. Unrelated, I also added a talk from Dan and an article from John to the list of background documents. Maybe they were intentionally left out, so no hard feelings if they're removed. ? And the GitHub editor added a trailing newline, I think. ? This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/valhalla-docs/pull/16 From liach at openjdk.org Mon Jan 19 04:18:57 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 Jan 2026 04:18:57 GMT Subject: RFR: add use site null checks for fields [v5] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 01:15:22 GMT, Vicente Romero wrote: >> generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations >> >> [1] https://github.com/openjdk/valhalla/pull/1910 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > changes to test Marked as reviewed by liach (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1926#pullrequestreview-3676187257 From tommy.ludwig at broadcom.com Mon Jan 19 07:50:47 2026 From: tommy.ludwig at broadcom.com (Tommy Ludwig) Date: Mon, 19 Jan 2026 16:50:47 +0900 Subject: Value objects performance with libraries Message-ID: In the "Value Object Performance" section of the Project Valhalla Value Objects page[1], it has a bullet point reading: > Older class files that use a migrated value class may not be fully optimized. For best performance, compile all classes that refer to a value class with --enable-preview. Does that mean applications using libraries compiled targeting older versions of Java will miss out on some possible optimizations even if they're using JDK classes that are migrated value classes? I see some more explanation in JEP 401 at the end of this section[2]. > If a value class V is not listed by the LoadableDescriptors attribute in, e.g., C.class, then when C is loaded, the JVM may not know that V is a value class. A field of type V may be encoded like any other field, storing pointers to objects in memory instead of flattened references. A method with a parameter of type V may not be JIT-compiled to accept scalarized calls, forcing callers to allocate objects on the heap and pass pointers to them. > In practice, this means that if a class V was migrated to become a value class, other classes that were compiled against an older version of V should be recompiled for optimal performance. On both pages, the word "may" is used. Could someone provide clarification on what the necessary condition is for the optimizations? If the value class V is loaded before class C where it is used, will the optimizations be possible even without the LoadableDescriptors attribute? If so, would it be fruitful for applications (or application frameworks) to eagerly load known value classes early? It seems like that may help performance in applications using libraries that have not released a new version yet that is compiled targeting a version of Java with value types. I also noticed in Frederic Parain's JVMLS talk on Value Classes Heap Flattening, he mentions at this point[3] that there is special handling of JDK migrated value classes, so they can be optimized even if class files are lacking the LoadableDescriptors attribute. This seems like important information that is missing mention in JEP 401, and I think it would be worth adding it. [1] https://openjdk.org/projects/valhalla/value-objects#value-object-performance [2] https://openjdk.org/jeps/401#When-flattening-and-scalarization-can-occur [3] https://youtu.be/NF4CpL_EWFI?si=yO-Xtw--YvcwNIiS&t=998 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5466 bytes Desc: S/MIME Cryptographic Signature URL: From jsikstro at openjdk.org Mon Jan 19 09:01:46 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 19 Jan 2026 09:01:46 GMT Subject: [lworld] RFR: 8375434: [lworld] Add comment for null-check in InlineKlass::read_payload_from_addr In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:03:29 GMT, Frederic Parain wrote: >> Hello, >> >> Update: There is nothing wrong with the logic. I added a comment to clarify why the second null-marker check is needed. Thanks. >> >> ~~Right now we check the null-marker for the NULLABLE_ATOMIC_FLAT LayoutKind twice, both before and after allocating a heap instance. The first check returns nullptr early if the null-marker is set, as we don't have to allocate an object on the heap if we are going to return nullptr anyways. The other check is redundant, since if the null-marker is not set, the source object is non-null, which means the destination (res) object is non-null as well after copying, so the code inside it is unreachable.~~ >> >> Testing: >> * Oracle's tier1-4, hotspot_valhalla, jdk_valhalla >> * ~~I also added a `gurantee` for the removed code and ran through hotspot_valhalla and jdk_valhalla locally.~~ > > Adding a comment to explain the rational of the second null-marker check is a good idea. Thank you for the reviews @fparain @Arraying! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1914#issuecomment-3767189673 From duke at openjdk.org Mon Jan 19 09:06:25 2026 From: duke at openjdk.org (duke) Date: Mon, 19 Jan 2026 09:06:25 GMT Subject: [lworld] RFR: 8375434: [lworld] Add comment for null-check in InlineKlass::read_payload_from_addr [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 16:10:58 GMT, Joel Sikstr?m wrote: >> Hello, >> >> Update: There is nothing wrong with the logic. I added a comment to clarify why the second null-marker check is needed. Thanks. >> >> ~~Right now we check the null-marker for the NULLABLE_ATOMIC_FLAT LayoutKind twice, both before and after allocating a heap instance. The first check returns nullptr early if the null-marker is set, as we don't have to allocate an object on the heap if we are going to return nullptr anyways. The other check is redundant, since if the null-marker is not set, the source object is non-null, which means the destination (res) object is non-null as well after copying, so the code inside it is unreachable.~~ >> >> Testing: >> * Oracle's tier1-4, hotspot_valhalla, jdk_valhalla >> * ~~I also added a `gurantee` for the removed code and ran through hotspot_valhalla and jdk_valhalla locally.~~ > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Add comment @jsikstro Your change (at version c4776d84ccea1ee3c4202b1a83b866fca6dcda4d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1914#issuecomment-3767203321 From jsikstro at openjdk.org Mon Jan 19 09:12:26 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 19 Jan 2026 09:12:26 GMT Subject: [lworld] Integrated: 8375434: [lworld] Add comment for null-check in InlineKlass::read_payload_from_addr In-Reply-To: References: Message-ID: <86bphSwt_aS_TA-RfatfMj99k7tGV400NmTJ_-V_Gt0=.cb18c1fd-da65-42e3-b4b1-4ec8d3a26705@github.com> On Thu, 15 Jan 2026 11:58:34 GMT, Joel Sikstr?m wrote: > Hello, > > Update: There is nothing wrong with the logic. I added a comment to clarify why the second null-marker check is needed. Thanks. > > ~~Right now we check the null-marker for the NULLABLE_ATOMIC_FLAT LayoutKind twice, both before and after allocating a heap instance. The first check returns nullptr early if the null-marker is set, as we don't have to allocate an object on the heap if we are going to return nullptr anyways. The other check is redundant, since if the null-marker is not set, the source object is non-null, which means the destination (res) object is non-null as well after copying, so the code inside it is unreachable.~~ > > Testing: > * Oracle's tier1-4, hotspot_valhalla, jdk_valhalla > * ~~I also added a `gurantee` for the removed code and ran through hotspot_valhalla and jdk_valhalla locally.~~ This pull request has now been integrated. Changeset: a4fb7ebd Author: Joel Sikstr?m Committer: Paul H?bner URL: https://git.openjdk.org/valhalla/commit/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548 Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod 8375434: [lworld] Add comment for null-check in InlineKlass::read_payload_from_addr Reviewed-by: fparain, phubner ------------- PR: https://git.openjdk.org/valhalla/pull/1914 From thartmann at openjdk.org Mon Jan 19 09:14:58 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 19 Jan 2026 09:14:58 GMT Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects [v2] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 00:36:52 GMT, Chen Liang wrote: >> Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Fixes, VHTMHAV now passes > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas > - A test > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas > - Attempt to fix garbage cas Thanks. I just discussed with @chhagedorn offline and we think that it's sufficient to have `VarHandleTestMethodHandleAccessValue.java` as regression test that you now un-problem listed. You can remove `TestCompareAndExchange`. Please verify though that `VarHandleTestMethodHandleAccessValue.java` now passes. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1734#issuecomment-3767243374 From mcimadamore at openjdk.org Mon Jan 19 10:26:30 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 19 Jan 2026 10:26:30 GMT Subject: RFR: add use site null checks for fields [v5] In-Reply-To: References: Message-ID: <2DfeJCwO0TnZeIkRAMzpKFVmSJScparBPSRQHx1FPIw=.c0992801-53cf-4ed4-94c9-e61438ceba2f@github.com> On Sat, 17 Jan 2026 01:15:22 GMT, Vicente Romero wrote: >> generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations >> >> [1] https://github.com/openjdk/valhalla/pull/1910 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > changes to test src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 165: > 163: sym.owner.kind == TYP && > 164: sym.kind == VAR && > 165: !isInThisSameCompUnit(sym) && I note that, for fields use site checks, we're checking that the field access is pointing to a field in a different compilation unit. But for method calls use-site we don't look for this and always (for now) emit the use site check. I wonder if for now we should err on the side of always generating the checks, and then come back later and (in one shot) relax the translation strategy to omit the checks in cases where they are provably unnecessary. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 179: > 177: > 178: private Symbol outermostType(Symbol sym) { > 179: Symbol prev = null; Doesn't `sym.outermostClass()` work? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1926#discussion_r2704143541 PR Review Comment: https://git.openjdk.org/valhalla/pull/1926#discussion_r2704135873 From duke at openjdk.org Mon Jan 19 11:43:22 2026 From: duke at openjdk.org (=?UTF-8?B?SmVhbi1Ob8OrbA==?= Rouvignac) Date: Mon, 19 Jan 2026 11:43:22 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 20:50:42 GMT, Joe Darcy wrote: >> A refinement of some earlier ideas on the numerics modeling interfaces to inform further discussions. >> >> This is a "lumpy" rather than "splitty" design in terms of favoring a smaller number of interfaces with more functionality rather than a larger number of interfaces making smaller distinctions. >> >> Various design comments and to-do's noted in the code. > > Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: > > - Add default methods. > - Respond to review feedback; add default methods. src/java.base/share/classes/java/lang/Numerical.java line 29: > 27: > 28: /** > 29: * Indicates a type supports the basic binary arithmetic operations of Suggestion: * Indicates a type that supports the basic binary arithmetic operations of ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1917#discussion_r2704407202 From qamai at openjdk.org Mon Jan 19 12:14:44 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 19 Jan 2026 12:14:44 GMT Subject: [lworld] RFR: 8375602: [lworld] Test verifiers should verify the equivalence of the objects if possible Message-ID: Hi, There are numerous tests of which verifiers assert that the hash value of 2 objects are equal to verify that those objects are equal. As `acmp` has become more mature, this PR updates those to verify that 2 objects are equal. This is more straightforward and it produces a nicer debug message in case of failures. A side effect of this PR is that it helps reproduce [JDK-8372824](https://bugs.openjdk.org/browse/JDK-8372824) in a consistent manner with `-XX:+UnlockExperimentalVMOptions -XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. Please take a look and leave your reviews, thanks a lot. ------------- Commit messages: - Test verifiers should check the equivalence of the objects Changes: https://git.openjdk.org/valhalla/pull/1929/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1929&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375602 Stats: 324 lines in 11 files changed: 10 ins; 24 del; 290 mod Patch: https://git.openjdk.org/valhalla/pull/1929.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1929/head:pull/1929 PR: https://git.openjdk.org/valhalla/pull/1929 From dsimms at openjdk.org Mon Jan 19 12:36:15 2026 From: dsimms at openjdk.org (David Simms) Date: Mon, 19 Jan 2026 12:36:15 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge jdk-27+5 ------------- Commit messages: - Adjust for 8374698 - New initialization warning - Merge tag 'jdk-27+5' into lworld_merge_jdk_27_5 - 8354853: Clean up x86 registers after 32-bit x86 removal - 8373134: C2: Min/Max users of Min/Max uses should be enqueued for GVN - 8371762: Incorrect use of checked_cast in Arguments::process_settings_file - 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages - 8374879: NMethodRelocationTest fails with -Xcomp after 8369150 - 8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests - 8374432: TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure fails run with -Xcomp - ... and 106 more: https://git.openjdk.org/valhalla/compare/e10b1db1...b7cdc3a4 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1930&range=00.0 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1930&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1930/files Stats: 38281 lines in 650 files changed: 23947 ins; 8900 del; 5434 mod Patch: https://git.openjdk.org/valhalla/pull/1930.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1930/head:pull/1930 PR: https://git.openjdk.org/valhalla/pull/1930 From dsimms at openjdk.org Mon Jan 19 12:42:41 2026 From: dsimms at openjdk.org (David Simms) Date: Mon, 19 Jan 2026 12:42:41 GMT Subject: [lworld] RFR: Merge jdk [v2] In-Reply-To: References: Message-ID: > Merge jdk-27+5 David Simms has updated the pull request incrementally with one additional commit since the last revision: Explicit super call is more correct ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1930/files - new: https://git.openjdk.org/valhalla/pull/1930/files/b7cdc3a4..69332ef6 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1930&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1930&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1930.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1930/head:pull/1930 PR: https://git.openjdk.org/valhalla/pull/1930 From vromero at openjdk.org Mon Jan 19 12:45:13 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 19 Jan 2026 12:45:13 GMT Subject: RFR: add use site null checks for fields [v5] In-Reply-To: <2DfeJCwO0TnZeIkRAMzpKFVmSJScparBPSRQHx1FPIw=.c0992801-53cf-4ed4-94c9-e61438ceba2f@github.com> References: <2DfeJCwO0TnZeIkRAMzpKFVmSJScparBPSRQHx1FPIw=.c0992801-53cf-4ed4-94c9-e61438ceba2f@github.com> Message-ID: On Mon, 19 Jan 2026 10:21:07 GMT, Maurizio Cimadamore wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> changes to test > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 179: > >> 177: >> 178: private Symbol outermostType(Symbol sym) { >> 179: Symbol prev = null; > > Doesn't `sym.outermostClass()` work? it work but at the end it does a cast to ClassSymbol, unfortunately some fields can have TypeSymbol as its outermost class. This is use in Symtab, an anonymous class of TypeSymbol and the build was failing ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1926#discussion_r2704628434 From vromero at openjdk.org Mon Jan 19 12:54:52 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 19 Jan 2026 12:54:52 GMT Subject: RFR: add use site null checks for fields [v5] In-Reply-To: <2DfeJCwO0TnZeIkRAMzpKFVmSJScparBPSRQHx1FPIw=.c0992801-53cf-4ed4-94c9-e61438ceba2f@github.com> References: <2DfeJCwO0TnZeIkRAMzpKFVmSJScparBPSRQHx1FPIw=.c0992801-53cf-4ed4-94c9-e61438ceba2f@github.com> Message-ID: On Mon, 19 Jan 2026 10:23:31 GMT, Maurizio Cimadamore wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> changes to test > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 165: > >> 163: sym.owner.kind == TYP && >> 164: sym.kind == VAR && >> 165: !isInThisSameCompUnit(sym) && > > I note that, for fields use site checks, we're checking that the field access is pointing to a field in a different compilation unit. But for method calls use-site we don't look for this and always (for now) emit the use site check. I wonder if for now we should err on the side of always generating the checks, and then come back later and (in one shot) relax the translation strategy to omit the checks in cases where they are provably unnecessary. we can do that or just add the same check to methods. I didn't think about this for the method's case. Seems like a very minimal `optimization` that should be there since the beginning. I could add the same for methods as part of this PR ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1926#discussion_r2704654985 From chagedorn at openjdk.org Mon Jan 19 14:58:48 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 19 Jan 2026 14:58:48 GMT Subject: [lworld] RFR: 8375548: [lworld] C2: Compiler replay does not work due to not creating ObjArrayKlass objects with ArrayProperties::DEFAULT Message-ID: When using compiler replay with `--enable-preview` with array store/load profiling, we only create `ObjArrayKlass` objects instead of subclass objects (i.e. `RefArrayKlass` or `FlatArrayKlass`). The reason is that we are directly resolving klasses with `SystemDirectory::resolve_or_fail()`: https://github.com/openjdk/valhalla/blob/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548/src/hotspot/share/ci/ciReplay.cpp#L557 This method will call `InstanceKlass::array_klass()` at some point which directly creates an `ObjArrayKlass` object. This let's the replayed compilation fail when trying to speculate on an value class array which expects a subclass of `ObjArrayKlass`. The fix I propose is to make sure that we are always creating subclass objects by explicitly using `ArrayProperties::DEFAULT` when parsing an `ArrayKlass` during replay compilation. I added a compiler replay test which triggers the same assert as shown in the report. Thanks, Christian ------------- Commit messages: - 8375548: [lworld] C2: Compiler replay fails with an assertion due to not loading object array klasses with ArrayProperties::DEFAULT Changes: https://git.openjdk.org/valhalla/pull/1931/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1931&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375548 Stats: 88 lines in 2 files changed: 88 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1931.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1931/head:pull/1931 PR: https://git.openjdk.org/valhalla/pull/1931 From thartmann at openjdk.org Mon Jan 19 15:31:09 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 19 Jan 2026 15:31:09 GMT Subject: [lworld] RFR: 8375548: [lworld] C2: Compiler replay does not work due to not creating ObjArrayKlass objects with ArrayProperties::DEFAULT In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 14:51:48 GMT, Christian Hagedorn wrote: > When using compiler replay with `--enable-preview` with array store/load profiling, we only create `ObjArrayKlass` objects instead of subclass objects (i.e. `RefArrayKlass` or `FlatArrayKlass`). The reason is that we are directly resolving klasses with `SystemDirectory::resolve_or_fail()`: > https://github.com/openjdk/valhalla/blob/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548/src/hotspot/share/ci/ciReplay.cpp#L557 > > This method will call `InstanceKlass::array_klass()` at some point which directly creates an `ObjArrayKlass` object. This let's the replayed compilation fail when trying to speculate on an value class array which expects a subclass of `ObjArrayKlass`. > > The fix I propose is to make sure that we are always creating subclass objects by explicitly using `ArrayProperties::DEFAULT` when parsing an `ArrayKlass` during replay compilation. > > I added a compiler replay test which triggers the same assert as shown in the report. > > Thanks, > Christian src/hotspot/share/ci/ciReplay.cpp line 562: > 560: // Create ref or flat array klass. > 561: k = ObjArrayKlass::cast(k)->klass_with_properties(ArrayKlass::ArrayProperties::DEFAULT, THREAD); > 562: } This will always create the default refined klass. Shouldn't we keep track of which refined klass was actually referenced in the replay file and then create that particular one here? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1931#discussion_r2705210950 From jlahoda at openjdk.org Mon Jan 19 15:50:25 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 19 Jan 2026 15:50:25 GMT Subject: RFR: Fixing completion detection for null-restricted variables and fixing behavior for incorrect null-restricted variables without an initializer. Message-ID: Fixing behavior in two cases: - `String! str = ""` (i.e. missing semicolon) should work. This is achieved by fixing the completion analysis to report the snippet as `COMPLETE_WITH_SEMI`. - `String! str` (i.e. missing initializer). This should produce an error saying initializer is required, achieved by not using the null initializer in this case. ------------- Commit messages: - Adding more tests. - Fixing completion detection for null-restricted variables and fixing behavior for incorrect null-restricted variables without an initializer. Changes: https://git.openjdk.org/valhalla/pull/1932/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1932&range=00 Stats: 51 lines in 5 files changed: 44 ins; 0 del; 7 mod Patch: https://git.openjdk.org/valhalla/pull/1932.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1932/head:pull/1932 PR: https://git.openjdk.org/valhalla/pull/1932 From liach at openjdk.org Mon Jan 19 16:53:24 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 Jan 2026 16:53:24 GMT Subject: RFR: Classfile signature bang support Message-ID: Support parsing ! signatures in ClassFile API. ------------- Commit messages: - Classfile signature bang support Changes: https://git.openjdk.org/valhalla/pull/1933/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1933&range=00 Stats: 248 lines in 4 files changed: 212 ins; 4 del; 32 mod Patch: https://git.openjdk.org/valhalla/pull/1933.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1933/head:pull/1933 PR: https://git.openjdk.org/valhalla/pull/1933 From mcimadamore at openjdk.org Mon Jan 19 17:53:34 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 19 Jan 2026 17:53:34 GMT Subject: RFR: add use site null checks for fields [v5] In-Reply-To: References: <2DfeJCwO0TnZeIkRAMzpKFVmSJScparBPSRQHx1FPIw=.c0992801-53cf-4ed4-94c9-e61438ceba2f@github.com> Message-ID: On Mon, 19 Jan 2026 12:51:08 GMT, Vicente Romero wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 165: >> >>> 163: sym.owner.kind == TYP && >>> 164: sym.kind == VAR && >>> 165: !isInThisSameCompUnit(sym) && >> >> I note that, for fields use site checks, we're checking that the field access is pointing to a field in a different compilation unit. But for method calls use-site we don't look for this and always (for now) emit the use site check. I wonder if for now we should err on the side of always generating the checks, and then come back later and (in one shot) relax the translation strategy to omit the checks in cases where they are provably unnecessary. > > we can do that or just add the same check to methods. I didn't think about this for the method's case. Seems like a very minimal `optimization` that should be there since the beginning. I could add the same for methods as part of this PR I'm fine with adding more use-site method optimizations in a follow up PR. >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 179: >> >>> 177: >>> 178: private Symbol outermostType(Symbol sym) { >>> 179: Symbol prev = null; >> >> Doesn't `sym.outermostClass()` work? > > it work but at the end it does a cast to ClassSymbol, unfortunately some fields can have TypeSymbol as its outermost class. This is use in Symtab, an anonymous class of TypeSymbol and the build was failing Ugh -- for now let's add a comment that `outermostClass` was considered and then discarded for the reasons you mention. That said -- the anon class you talk about is (I think) `noSymbol`. I wonder why we're trying to call `outrmostType` on `noSymbol`. That symbol has kind `NIL`. So I wonder what is really going on here? Are we trying to use this visitor on code that has errors? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1926#discussion_r2705669144 PR Review Comment: https://git.openjdk.org/valhalla/pull/1926#discussion_r2705667576 From liach at openjdk.org Mon Jan 19 17:57:26 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 Jan 2026 17:57:26 GMT Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects [v3] In-Reply-To: References: Message-ID: > Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas - Remove test as permitted - Fixes, VHTMHAV now passes - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas - A test - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas - Attempt to fix garbage cas ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1734/files - new: https://git.openjdk.org/valhalla/pull/1734/files/0b95903f..c1659649 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1734&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1734&range=01-02 Stats: 23028 lines in 2478 files changed: 5555 ins; 2720 del; 14753 mod Patch: https://git.openjdk.org/valhalla/pull/1734.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1734/head:pull/1734 PR: https://git.openjdk.org/valhalla/pull/1734 From liach at openjdk.org Mon Jan 19 19:24:56 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 Jan 2026 19:24:56 GMT Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects [v3] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 17:57:26 GMT, Chen Liang wrote: >> Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas > - Remove test as permitted > - Fixes, VHTMHAV now passes > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas > - A test > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas > - Attempt to fix garbage cas Ran the VarHandleTestMethodHandleAccessValue test again with no failure. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1734#issuecomment-3769783637 From chen.l.liang at oracle.com Mon Jan 19 19:59:13 2026 From: chen.l.liang at oracle.com (Chen Liang) Date: Mon, 19 Jan 2026 19:59:13 +0000 Subject: Value objects performance with libraries In-Reply-To: References: Message-ID: > Does that mean applications using libraries compiled targeting older versions of Java will miss out on some possible optimizations even if they're using JDK classes that are migrated value classes? Yes, in general, the text you've quoted are talking about the object layout optimizations provided by final value class-typed fields. > If the value class V is loaded before class C where it is used, will the optimizations be possible even without the LoadableDescriptors attribute? If so, would it be fruitful for applications (or application frameworks) to eagerly load known value classes early? Yes, loading these value classes before the classes that declare fields of these value class types is a viable approach to ensure optimal layout. The reason such early loading are not default but must be opt-in from newly-compiled class files is that this affects custom class loaders. You might also notice incompatibility or behavioral change in your application if you perform eager loading. Regards, Chen Liang ________________________________ From: valhalla-dev on behalf of Tommy Ludwig Sent: Monday, January 19, 2026 1:50 AM To: valhalla-dev at openjdk.org Subject: Value objects performance with libraries In the "Value Object Performance" section of the Project Valhalla Value Objects page[1], it has a bullet point reading: > Older class files that use a migrated value class may not be fully optimized. For best performance, compile all classes that refer to a value class with --enable-preview. Does that mean applications using libraries compiled targeting older versions of Java will miss out on some possible optimizations even if they're using JDK classes that are migrated value classes? I see some more explanation in JEP 401 at the end of this section[2]. > If a value class V is not listed by the LoadableDescriptors attribute in, e.g., C.class, then when C is loaded, the JVM may not know that V is a value class. A field of type V may be encoded like any other field, storing pointers to objects in memory instead of flattened references. A method with a parameter of type V may not be JIT-compiled to accept scalarized calls, forcing callers to allocate objects on the heap and pass pointers to them. > In practice, this means that if a class V was migrated to become a value class, other classes that were compiled against an older version of V should be recompiled for optimal performance. On both pages, the word "may" is used. Could someone provide clarification on what the necessary condition is for the optimizations? If the value class V is loaded before class C where it is used, will the optimizations be possible even without the LoadableDescriptors attribute? If so, would it be fruitful for applications (or application frameworks) to eagerly load known value classes early? It seems like that may help performance in applications using libraries that have not released a new version yet that is compiled targeting a version of Java with value types. I also noticed in Frederic Parain's JVMLS talk on Value Classes Heap Flattening, he mentions at this point[3] that there is special handling of JDK migrated value classes, so they can be optimized even if class files are lacking the LoadableDescriptors attribute. This seems like important information that is missing mention in JEP 401, and I think it would be worth adding it. [1] https://openjdk.org/projects/valhalla/value-objects#value-object-performance [2] https://openjdk.org/jeps/401#When-flattening-and-scalarization-can-occur [3] https://youtu.be/NF4CpL_EWFI?si=yO-Xtw--YvcwNIiS&t=998 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.org Mon Jan 19 20:05:52 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 19 Jan 2026 20:05:52 GMT Subject: RFR: add use site null checks for fields [v5] In-Reply-To: References: <2DfeJCwO0TnZeIkRAMzpKFVmSJScparBPSRQHx1FPIw=.c0992801-53cf-4ed4-94c9-e61438ceba2f@github.com> Message-ID: On Mon, 19 Jan 2026 17:49:08 GMT, Maurizio Cimadamore wrote: >> it work but at the end it does a cast to ClassSymbol, unfortunately some fields can have TypeSymbol as its outermost class. This is use in Symtab, an anonymous class of TypeSymbol and the build was failing > > Ugh -- for now let's add a comment that `outermostClass` was considered and then discarded for the reasons you mention. > > That said -- the anon class you talk about is (I think) `noSymbol`. I wonder why we're trying to call `outrmostType` on `noSymbol`. That symbol has kind `NIL`. So I wonder what is really going on here? Are we trying to use this visitor on code that has errors? Turns out that the reason why using `outermostClass` was failing is that the logic here is trying to add null checks for `array.length` -- which the compiler models as a "fake" field access on the fictional Array class (whose owner is `noSymbol`). We shouldn't attempt to check such fields -- in part because this isn't even a proper declared field, but also because only non nullable fields are the issue. This problem is easily avoided by first checking for non nullable type _then_ calling `outermostClass` ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1926#discussion_r2705950660 From vromero at openjdk.org Mon Jan 19 20:12:58 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 19 Jan 2026 20:12:58 GMT Subject: RFR: add use site null checks for fields [v6] In-Reply-To: References: Message-ID: > generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations > > [1] https://github.com/openjdk/valhalla/pull/1910 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: using Symbol::outermostClass ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1926/files - new: https://git.openjdk.org/valhalla/pull/1926/files/5f2f235f..fdddd288 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=05 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=04-05 Stats: 12 lines in 1 file changed: 0 ins; 9 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1926.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1926/head:pull/1926 PR: https://git.openjdk.org/valhalla/pull/1926 From mcimadamore at openjdk.org Mon Jan 19 20:13:03 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 19 Jan 2026 20:13:03 GMT Subject: RFR: add use site null checks for fields [v5] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 01:15:22 GMT, Vicente Romero wrote: >> generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations >> >> [1] https://github.com/openjdk/valhalla/pull/1910 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > changes to test src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 176: > 174: private boolean isInThisSameCompUnit(Symbol sym) { > 175: return env.toplevel.getTypeDecls().stream().anyMatch(tree -> TreeInfo.symbolFor(tree) == outermostType(sym)); > 176: } Btw, a cheaper check here could be to get `env.enclClass` and call `outermostClass` on its symbol, then compare it with the `outermostClass` of the accessed field symbol and check if they are the same. It should work well, but it will not handle auxiliary classes well (as an aux class is not "nested" in the toplevel class) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1926#discussion_r2705957460 From vromero at openjdk.org Mon Jan 19 20:15:27 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 19 Jan 2026 20:15:27 GMT Subject: RFR: add use site null checks for fields [v7] In-Reply-To: References: Message-ID: > generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations > > [1] https://github.com/openjdk/valhalla/pull/1910 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: let optimizations for later on ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1926/files - new: https://git.openjdk.org/valhalla/pull/1926/files/fdddd288..2273b040 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=06 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=05-06 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1926.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1926/head:pull/1926 PR: https://git.openjdk.org/valhalla/pull/1926 From vromero at openjdk.org Mon Jan 19 20:26:36 2026 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 19 Jan 2026 20:26:36 GMT Subject: RFR: add use site null checks for fields [v8] In-Reply-To: References: Message-ID: > generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations > > [1] https://github.com/openjdk/valhalla/pull/1910 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: minor change ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1926/files - new: https://git.openjdk.org/valhalla/pull/1926/files/2273b040..27a45c8a Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=07 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=06-07 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1926.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1926/head:pull/1926 PR: https://git.openjdk.org/valhalla/pull/1926 From dsimms at openjdk.org Tue Jan 20 09:30:23 2026 From: dsimms at openjdk.org (David Simms) Date: Tue, 20 Jan 2026 09:30:23 GMT Subject: [lworld] RFR: Merge jdk [v3] In-Reply-To: References: Message-ID: > Merge jdk-27+5 David Simms has updated the pull request incrementally with one additional commit since the last revision: Patch 8374639 ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1930/files - new: https://git.openjdk.org/valhalla/pull/1930/files/69332ef6..12a93eaf Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1930&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1930&range=01-02 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1930.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1930/head:pull/1930 PR: https://git.openjdk.org/valhalla/pull/1930 From paul.hubner at oracle.com Tue Jan 20 09:34:46 2026 From: paul.hubner at oracle.com (Paul Hubner) Date: Tue, 20 Jan 2026 09:34:46 +0000 Subject: CFV: New Valhalla Committer: Chris Plummer In-Reply-To: References: Message-ID: Vote: yes Paul ________________________________ From: valhalla-dev on behalf of David Simms Sent: Thursday, January 15, 2026 5:23 PM To: valhalla-dev at openjdk.java.net Subject: CFV: New Valhalla Committer: Chris Plummer I hereby nominate Chris Plummer to Valhalla Committer. Chris is a long time member of the OpenJDK project, with over 400 commits in the mainline[1]. Votes are due by 29th of December, 18:00z. Only current Valhalla Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. David Simms [1] https://github.com/search?q=committer-name%3A%22Chris+Plummer%22+repo%3Aopenjdk%2Fjdk+&type=commits [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From thartmann at openjdk.org Tue Jan 20 11:05:08 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 20 Jan 2026 11:05:08 GMT Subject: [lworld] RFR: 8375602: [lworld] Test verifiers should verify the equivalence of the objects if possible In-Reply-To: References: Message-ID: <6oqZ5vbrTHaSgLRNldYjQfZJG7qtPPnj9o6Dz_waIeE=.ebbc2be6-5080-4c29-8f88-e784bbfcb003@github.com> On Mon, 19 Jan 2026 12:08:04 GMT, Quan Anh Mai wrote: > Hi, > > There are numerous tests of which verifiers assert that the hash value of 2 objects are equal to verify that those objects are equal. As `acmp` has become more mature, this PR updates those to verify that 2 objects are equal. This is more straightforward and it produces a nicer debug message in case of failures. I changed the order of some asserts that are changed or nearby. This is because the argument order of assert is `(expected, actual)`, and the assertion message would be `expected: ..., but was: ...`, so changing the order to the correct one gives us a more intuitive message. > > A side effect of this PR is that it helps reproduce [JDK-8372824](https://bugs.openjdk.org/browse/JDK-8372824) in a consistent manner with `-XX:+UnlockExperimentalVMOptions -XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. > > Please take a look and leave your reviews, thanks a lot. Nice cleanup, looks good to me! Some tests might need copyright updates. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1929#pullrequestreview-3681624350 From mchevalier at openjdk.org Tue Jan 20 11:12:58 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Tue, 20 Jan 2026 11:12:58 GMT Subject: [lworld] RFR: 8374122: [lworld] compiler/c2/cmove/TestScalarConditionalMoveCmpObj.java fails with ir mismatches when preview enabled, post jdk-27+3 Message-ID: <51t14OlYhVki-vjsZyxhiY1QGQv_wltoNGeCyzlIuAA=.72589c33-90f7-4dfc-9c13-73b2923c9925@github.com> The test `TestScalarConditionalMoveCmpObj.java` tests whether code such as r[i] = (a[i] != b[i]) ? cc : dd; where `a` and `b` are `Object[]` gives a `CMoveNode`. Without Valhalla, we get a simple `If -> If(True|False) -> Region` diamond diamond that is simplified as a CMove. cmove Only this simple shape is simplified: https://github.com/openjdk/valhalla/blob/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548/src/hotspot/share/opto/loopopts.cpp#L723-L730 But with Valhalla, since operands could be value objects, the logic is a lot more complex: are pointer equal? If not, are one of both operands null? If both aren't null, are the operand the same class? If so... All being eventually concluded with a call to `isSubstitutable`. This can't be simplified as a `CMove` (or not easily). Even warm up isn't enough: while `a[i]` and `b[i]` are guessed to be exactly `Object`, this still requires a more complex logic than a diamond. Schematically: are pointers equal? If not, is lhs null (that is enough to conclude they are different objects)? If so, trap; if not, is lhs of the speculated (non-value) type? If so, they are different; if not, trap. That is too complicated to make a `CMove`. A solution is to make sure we can prove, rather than speculate, that operands are not value objects. Instead of making `a` and `b` arrays of `Object` that can be value types at runtime, we make them arrays of a non-abstract non-value type. This cannot be derived into a value class, so it's fine. And the test pass again! I've also done a bit of side fixup in these tests: fixing package name and call `init` on the arrays used for the `int` flavor of the test (method `private static void TestScalarConditionalMoveCmpObj::init(int[] a)` was suspiciously unused). Thanks, Marc ------------- Commit messages: - Unproblem-list - copyright - Use another class so C2 knows it's not a value class Changes: https://git.openjdk.org/valhalla/pull/1934/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1934&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374122 Stats: 29 lines in 4 files changed: 10 ins; 1 del; 18 mod Patch: https://git.openjdk.org/valhalla/pull/1934.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1934/head:pull/1934 PR: https://git.openjdk.org/valhalla/pull/1934 From qamai at openjdk.org Tue Jan 20 11:17:16 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 20 Jan 2026 11:17:16 GMT Subject: [lworld] RFR: 8375602: [lworld] Test verifiers should verify the equivalence of the objects if possible In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 12:08:04 GMT, Quan Anh Mai wrote: > Hi, > > There are numerous tests of which verifiers assert that the hash value of 2 objects are equal to verify that those objects are equal. As `acmp` has become more mature, this PR updates those to verify that 2 objects are equal. This is more straightforward and it produces a nicer debug message in case of failures. I changed the order of some asserts that are changed or nearby. This is because the argument order of assert is `(expected, actual)`, and the assertion message would be `expected: ..., but was: ...`, so changing the order to the correct one gives us a more intuitive message. > > A side effect of this PR is that it helps reproduce [JDK-8372824](https://bugs.openjdk.org/browse/JDK-8372824) in a consistent manner with `-XX:+UnlockExperimentalVMOptions -XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. > > Please take a look and leave your reviews, thanks a lot. Thanks for your approval. I have updated the copyright year of the changed files. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1929#issuecomment-3772340592 From qamai at openjdk.org Tue Jan 20 11:17:14 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 20 Jan 2026 11:17:14 GMT Subject: [lworld] RFR: 8375602: [lworld] Test verifiers should verify the equivalence of the objects if possible [v2] In-Reply-To: References: Message-ID: > Hi, > > There are numerous tests of which verifiers assert that the hash value of 2 objects are equal to verify that those objects are equal. As `acmp` has become more mature, this PR updates those to verify that 2 objects are equal. This is more straightforward and it produces a nicer debug message in case of failures. I changed the order of some asserts that are changed or nearby. This is because the argument order of assert is `(expected, actual)`, and the assertion message would be `expected: ..., but was: ...`, so changing the order to the correct one gives us a more intuitive message. > > A side effect of this PR is that it helps reproduce [JDK-8372824](https://bugs.openjdk.org/browse/JDK-8372824) in a consistent manner with `-XX:+UnlockExperimentalVMOptions -XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. > > Please take a look and leave your reviews, thanks a lot. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: copyright year ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1929/files - new: https://git.openjdk.org/valhalla/pull/1929/files/19bac703..674656de Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1929&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1929&range=00-01 Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/valhalla/pull/1929.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1929/head:pull/1929 PR: https://git.openjdk.org/valhalla/pull/1929 From qamai at openjdk.org Tue Jan 20 11:17:17 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 20 Jan 2026 11:17:17 GMT Subject: [lworld] Integrated: 8375602: [lworld] Test verifiers should verify the equivalence of the objects if possible In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 12:08:04 GMT, Quan Anh Mai wrote: > Hi, > > There are numerous tests of which verifiers assert that the hash value of 2 objects are equal to verify that those objects are equal. As `acmp` has become more mature, this PR updates those to verify that 2 objects are equal. This is more straightforward and it produces a nicer debug message in case of failures. I changed the order of some asserts that are changed or nearby. This is because the argument order of assert is `(expected, actual)`, and the assertion message would be `expected: ..., but was: ...`, so changing the order to the correct one gives us a more intuitive message. > > A side effect of this PR is that it helps reproduce [JDK-8372824](https://bugs.openjdk.org/browse/JDK-8372824) in a consistent manner with `-XX:+UnlockExperimentalVMOptions -XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. > > Please take a look and leave your reviews, thanks a lot. This pull request has now been integrated. Changeset: 4c6f9021 Author: Quan Anh Mai URL: https://git.openjdk.org/valhalla/commit/4c6f902108bdede867574fbdda53da66ea2cb363 Stats: 332 lines in 11 files changed: 10 ins; 24 del; 298 mod 8375602: [lworld] Test verifiers should verify the equivalence of the objects if possible Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1929 From qamai at openjdk.org Tue Jan 20 11:18:33 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 20 Jan 2026 11:18:33 GMT Subject: [lworld] RFR: 8374122: [lworld] compiler/c2/cmove/TestScalarConditionalMoveCmpObj.java fails with ir mismatches when preview enabled, post jdk-27+3 In-Reply-To: <51t14OlYhVki-vjsZyxhiY1QGQv_wltoNGeCyzlIuAA=.72589c33-90f7-4dfc-9c13-73b2923c9925@github.com> References: <51t14OlYhVki-vjsZyxhiY1QGQv_wltoNGeCyzlIuAA=.72589c33-90f7-4dfc-9c13-73b2923c9925@github.com> Message-ID: On Tue, 20 Jan 2026 08:49:02 GMT, Marc Chevalier wrote: > The test `TestScalarConditionalMoveCmpObj.java` tests whether code such as > > r[i] = (a[i] != b[i]) ? cc : dd; > > where `a` and `b` are `Object[]` gives a `CMoveNode`. Without Valhalla, we get a simple `If -> If(True|False) -> Region` diamond > > diamond > > that is simplified as a CMove. > > cmove > > Only this simple shape is simplified: > > https://github.com/openjdk/valhalla/blob/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548/src/hotspot/share/opto/loopopts.cpp#L723-L730 > > But with Valhalla, since operands could be value objects, the logic is a lot more complex: are pointer equal? If not, are one of both operands null? If both aren't null, are the operand the same class? If so... All being eventually concluded with a call to `isSubstitutable`. This can't be simplified as a `CMove` (or not easily). > > Even warm up isn't enough: while `a[i]` and `b[i]` are guessed to be exactly `Object`, this still requires a more complex logic than a diamond. Schematically: are pointers equal? If not, is lhs null (that is enough to conclude they are different objects)? If so, trap; if not, is lhs of the speculated (non-value) type? If so, they are different; if not, trap. That is too complicated to make a `CMove`. > > A solution is to make sure we can prove, rather than speculate, that operands are not value objects. Instead of making `a` and `b` arrays of `Object` that can be value types at runtime, we make them arrays of a non-abstract non-value type. This cannot be derived into a value class, so it's fine. And the test pass again! > > I've also done a bit of side fixup in these tests: fixing package name and call `init` on the arrays used for the `int` flavor of the test (method `private static void TestScalarConditionalMoveCmpObj::init(int[] a)` was suspiciously unused). > > > Thanks, > Marc LGTM ------------- Marked as reviewed by qamai (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1934#pullrequestreview-3681670715 From qamai at openjdk.org Tue Jan 20 11:34:58 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 20 Jan 2026 11:34:58 GMT Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed: bad cast In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 13:31:16 GMT, Marc Chevalier wrote: > Some code added by [JDK-8372700](https://bugs.openjdk.org/browse/JDK-8372700) can compute the constant value of a field of a (flatten) element in a flat array. We get a crash when the element of the array is known to be `null`, and so the field doesn't exist. > > So, let's just check in `ciConstant ciFlatArray::field_value(int index, ciField* field)` whether we get a null constant before interpreting it as a `ciInstance` and trying to retrieve a field from there. This should be enough since a `ciObject` is (directly) derived by `ciNullObject`, `ciInstance` and `ciArray`. Since we are looking up a value of a flat array, an element cannot be a `ciArray` (arrays have identities and can't be contained in a flat array). After looking up whether the flat array element is null, the `obj->as_instance()` cast acts as an assert, should we ever add another derived class from `ciObject`. > > In case of a null array element, `field_value` simply returns an invalid `ciConstant`. > > Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks good. > > Thanks, > Marc src/hotspot/share/ci/ciFlatArray.cpp line 136: > 134: > 135: ciConstant ciFlatArray::field_value(int index, ciField* field) { > 136: auto get_field_from_object_constant = [field](const ciConstant& v) -> ciConstant { I don't really agree with this fix, `ciFlatArray::field_value` should be dumber, it is the caller who knows that we do not fold the load if the element is `null`, the callee should just return the field as it is. src/hotspot/share/opto/type.cpp line 414: > 412: > 413: if (con.is_valid() && // not a mismatched access > 414: !con.is_null_or_zero()) { // not a default value This is incorrect, the value is not constant if the element of the array is `null`, not if the field we retrieved is `null`. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2707955712 PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2707940249 From qamai at openjdk.org Tue Jan 20 11:35:26 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 20 Jan 2026 11:35:26 GMT Subject: [lworld] RFR: 8374006: [lworld] Improve field accessor methods in InlineTypeNode In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 13:15:54 GMT, Marc Chevalier wrote: > This PR remove from `InlineTypeNode` the methods: > > int field_offset(uint index) const; > uint field_index(int offset) const; > ciType* field_type(uint index) const; > bool field_is_flat(uint index) const; > bool field_is_null_free(uint index) const; > bool field_is_volatile(uint index) const; > int field_null_marker_offset(uint index) const; > > in favor of a single > > ciField* field(uint index) const; > > from which we directly access the various properties we are interested in. > > I've called it `field` as suggested in the original discussion. I've started with `declared_nonstatic_field_at` to be consistent with `ciInstanceKlass` and to avoid ambiguity wrt which kind of fields we are talking about, but this name is rather long... Since we are only talking about the declared fields, and we have no easy getter for `nonstatic_field_at`, then I think it's ok to have a shorter name. Also, in the context of a `InlineTypeNode`, the "non-static" part of the long name seems rather redundant. > > The other question is what we should do with asserts? Methods `field_is_flat`, `field_is_null_free` and `field_is_volatile` had the assert > > assert(!field->is_flat() || field->type()->is_inlinetype(), "must be an inline type"); > > and `field_null_marker_offset` had > > assert(field->is_flat(), "must be an inline type"); > > > I've tried to propagate them to the call-site of such functions, and where it makes a bit of sense, and not subsumed by surrounding `if()` and `assert`. Let me know if it seems unnecessary or not well-placed in some cases. > > Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks fine, but it doesn't seem too risky. > > Thanks, > Marc LGTM ------------- Marked as reviewed by qamai (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1922#pullrequestreview-3681730613 From thartmann at openjdk.org Tue Jan 20 12:00:05 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 20 Jan 2026 12:00:05 GMT Subject: [lworld] RFR: 8374122: [lworld] compiler/c2/cmove/TestScalarConditionalMoveCmpObj.java fails with ir mismatches when preview enabled, post jdk-27+3 In-Reply-To: <51t14OlYhVki-vjsZyxhiY1QGQv_wltoNGeCyzlIuAA=.72589c33-90f7-4dfc-9c13-73b2923c9925@github.com> References: <51t14OlYhVki-vjsZyxhiY1QGQv_wltoNGeCyzlIuAA=.72589c33-90f7-4dfc-9c13-73b2923c9925@github.com> Message-ID: On Tue, 20 Jan 2026 08:49:02 GMT, Marc Chevalier wrote: > The test `TestScalarConditionalMoveCmpObj.java` tests whether code such as > > r[i] = (a[i] != b[i]) ? cc : dd; > > where `a` and `b` are `Object[]` gives a `CMoveNode`. Without Valhalla, we get a simple `If -> If(True|False) -> Region` diamond > > diamond > > that is simplified as a CMove. > > cmove > > Only this simple shape is simplified: > > https://github.com/openjdk/valhalla/blob/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548/src/hotspot/share/opto/loopopts.cpp#L723-L730 > > But with Valhalla, since operands could be value objects, the logic is a lot more complex: are pointer equal? If not, are one of both operands null? If both aren't null, are the operand the same class? If so... All being eventually concluded with a call to `isSubstitutable`. This can't be simplified as a `CMove` (or not easily). > > Even warm up isn't enough: while `a[i]` and `b[i]` are guessed to be exactly `Object`, this still requires a more complex logic than a diamond. Schematically: are pointers equal? If not, is lhs null (that is enough to conclude they are different objects)? If so, trap; if not, is lhs of the speculated (non-value) type? If so, they are different; if not, trap. That is too complicated to make a `CMove`. > > A solution is to make sure we can prove, rather than speculate, that operands are not value objects. Instead of making `a` and `b` arrays of `Object` that can be value types at runtime, we make them arrays of a non-abstract non-value type. This cannot be derived into a value class, so it's fine. And the test pass again! > > I've also done a bit of side fixup in these tests: fixing package name and call `init` on the arrays used for the `int` flavor of the test (method `private static void TestScalarConditionalMoveCmpObj::init(int[] a)` was suspiciously unused). > > > Thanks, > Marc Looks good to me too! ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1934#pullrequestreview-3681826020 From thartmann at openjdk.org Tue Jan 20 12:08:17 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 20 Jan 2026 12:08:17 GMT Subject: [lworld] RFR: 8374006: [lworld] Improve field accessor methods in InlineTypeNode In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 13:15:54 GMT, Marc Chevalier wrote: > This PR remove from `InlineTypeNode` the methods: > > int field_offset(uint index) const; > uint field_index(int offset) const; > ciType* field_type(uint index) const; > bool field_is_flat(uint index) const; > bool field_is_null_free(uint index) const; > bool field_is_volatile(uint index) const; > int field_null_marker_offset(uint index) const; > > in favor of a single > > ciField* field(uint index) const; > > from which we directly access the various properties we are interested in. > > I've called it `field` as suggested in the original discussion. I've started with `declared_nonstatic_field_at` to be consistent with `ciInstanceKlass` and to avoid ambiguity wrt which kind of fields we are talking about, but this name is rather long... Since we are only talking about the declared fields, and we have no easy getter for `nonstatic_field_at`, then I think it's ok to have a shorter name. Also, in the context of a `InlineTypeNode`, the "non-static" part of the long name seems rather redundant. > > The other question is what we should do with asserts? Methods `field_is_flat`, `field_is_null_free` and `field_is_volatile` had the assert > > assert(!field->is_flat() || field->type()->is_inlinetype(), "must be an inline type"); > > and `field_null_marker_offset` had > > assert(field->is_flat(), "must be an inline type"); > > > I've tried to propagate them to the call-site of such functions, and where it makes a bit of sense, and not subsumed by surrounding `if()` and `assert`. Let me know if it seems unnecessary or not well-placed in some cases. > > Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks fine, but it doesn't seem too risky. > > Thanks, > Marc Nice cleanup! Looks good to me. Some files might need copyright updates though. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1922#pullrequestreview-3681856159 From mchevalier at openjdk.org Tue Jan 20 12:56:08 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Tue, 20 Jan 2026 12:56:08 GMT Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed: bad cast In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 11:30:38 GMT, Quan Anh Mai wrote: >> Some code added by [JDK-8372700](https://bugs.openjdk.org/browse/JDK-8372700) can compute the constant value of a field of a (flatten) element in a flat array. We get a crash when the element of the array is known to be `null`, and so the field doesn't exist. >> >> So, let's just check in `ciConstant ciFlatArray::field_value(int index, ciField* field)` whether we get a null constant before interpreting it as a `ciInstance` and trying to retrieve a field from there. This should be enough since a `ciObject` is (directly) derived by `ciNullObject`, `ciInstance` and `ciArray`. Since we are looking up a value of a flat array, an element cannot be a `ciArray` (arrays have identities and can't be contained in a flat array). After looking up whether the flat array element is null, the `obj->as_instance()` cast acts as an assert, should we ever add another derived class from `ciObject`. >> >> In case of a null array element, `field_value` simply returns an invalid `ciConstant`. >> >> Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks good. >> >> Thanks, >> Marc > > src/hotspot/share/ci/ciFlatArray.cpp line 136: > >> 134: >> 135: ciConstant ciFlatArray::field_value(int index, ciField* field) { >> 136: auto get_field_from_object_constant = [field](const ciConstant& v) -> ciConstant { > > I don't really agree with this fix, `ciFlatArray::field_value` should be dumber, it is the caller who knows that we do not fold the load if the element is `null`, the callee should just return the field as it is. I fear I don't understand. Let's say, I have a flat array `MyValue[] arr` where `MyValue` is a value class with a single field `f`. Let's also assume `arr[0] == null`, `arr.field_value(0, f)` (assuming the `ci...` versions of it with matching names) tries to get the constant value of the field `f` of `arr[0]`, and `arr[0].f` is not null, it's rather undefined. It's not about stability and folding. On the other hand, if `arr[0]` is not null, but `arr[0].f` is null, `arr.field_value(0, f)` already returns `null` (the `ciConstant` that means that). Am I missing something? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2708233184 From mchevalier at openjdk.org Tue Jan 20 13:02:24 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Tue, 20 Jan 2026 13:02:24 GMT Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed: bad cast In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 11:25:59 GMT, Quan Anh Mai wrote: >> Some code added by [JDK-8372700](https://bugs.openjdk.org/browse/JDK-8372700) can compute the constant value of a field of a (flatten) element in a flat array. We get a crash when the element of the array is known to be `null`, and so the field doesn't exist. >> >> So, let's just check in `ciConstant ciFlatArray::field_value(int index, ciField* field)` whether we get a null constant before interpreting it as a `ciInstance` and trying to retrieve a field from there. This should be enough since a `ciObject` is (directly) derived by `ciNullObject`, `ciInstance` and `ciArray`. Since we are looking up a value of a flat array, an element cannot be a `ciArray` (arrays have identities and can't be contained in a flat array). After looking up whether the flat array element is null, the `obj->as_instance()` cast acts as an assert, should we ever add another derived class from `ciObject`. >> >> In case of a null array element, `field_value` simply returns an invalid `ciConstant`. >> >> Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks good. >> >> Thanks, >> Marc > > src/hotspot/share/opto/type.cpp line 414: > >> 412: >> 413: if (con.is_valid() && // not a mismatched access >> 414: !con.is_null_or_zero()) { // not a default value > > This is incorrect, the value is not constant if the element of the array is `null`, not if the field we retrieved is `null`. I think you're correct. While being sound, we might miss opportunities where the value is actually constant but we discard it. `con.is_value()` already is enough to make sure the array element is not null (and constant). ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2708249153 From qamai at openjdk.org Tue Jan 20 13:08:03 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 20 Jan 2026 13:08:03 GMT Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed: bad cast In-Reply-To: References: Message-ID: <9W3_n3NgGCOz84Mp-zLZd02fktXLE5JeYrzO536Nacc=.77989015-de29-44e2-bfa0-b2ba27121dc9@github.com> On Tue, 20 Jan 2026 12:54:01 GMT, Marc Chevalier wrote: >> src/hotspot/share/ci/ciFlatArray.cpp line 136: >> >>> 134: >>> 135: ciConstant ciFlatArray::field_value(int index, ciField* field) { >>> 136: auto get_field_from_object_constant = [field](const ciConstant& v) -> ciConstant { >> >> I don't really agree with this fix, `ciFlatArray::field_value` should be dumber, it is the caller who knows that we do not fold the load if the element is `null`, the callee should just return the field as it is. > > I fear I don't understand. Let's say, I have a flat array `MyValue[] arr` where `MyValue` is a value class with a single field `f`. Let's also assume `arr[0] == null`, `arr.field_value(0, f)` (assuming the `ci...` versions of it with matching names) tries to get the constant value of the field `f` of `arr[0]`, and `arr[0].f` is not null, it's rather undefined. It's not about stability and folding. On the other hand, if `arr[0]` is not null, but `arr[0].f` is null, `arr.field_value(0, f)` already returns `null` (the `ciConstant` that means that). > > Am I missing something? That is only true from the Java perspective. From the VM perspective, a flat array would be something like (C++ pseudocode): class MyValuePayload { oop* f; bool null_marker; }; MyValuePayload* arr = new MyValuePayload[n]; Then, it is clear that even if `arr[0].null_marker == false`, `arr[0].f` is still defined and has a value (which should be `nullptr`). ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2708268808 From mcimadamore at openjdk.org Tue Jan 20 14:22:51 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 20 Jan 2026 14:22:51 GMT Subject: RFR: add use site null checks for fields [v8] In-Reply-To: References: Message-ID: <3tb86lTg8EJL7Ec4bbVTvAUSe3eRtAZg9o1i0qW0j3o=.711a162f-c444-407f-888d-d3fee9b51977@github.com> On Mon, 19 Jan 2026 20:26:36 GMT, Vicente Romero wrote: >> generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations >> >> [1] https://github.com/openjdk/valhalla/pull/1910 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > minor change Marked as reviewed by mcimadamore (Committer). src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 94: > 92: > 93: Env env; > 94: Symbol.ClassSymbol currentClass; Style: maybe import class symbol? ------------- PR Review: https://git.openjdk.org/valhalla/pull/1926#pullrequestreview-3682434138 PR Review Comment: https://git.openjdk.org/valhalla/pull/1926#discussion_r2708563686 From coleenp at openjdk.org Tue Jan 20 15:12:52 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 20 Jan 2026 15:12:52 GMT Subject: [lworld] RFR: 8375328: [lworld] JNI IsSameObject function doesn't use the alternate substitutability method In-Reply-To: References: Message-ID: <4QQd_MRPk32VsB4eyiDeREYs4hN2RhyOR7R1ae7YAKg=.80f83b87-e95d-4b29-88d8-22521f39f351@github.com> On Wed, 14 Jan 2026 17:20:04 GMT, Frederic Parain wrote: > Small fix to align the implementation of JNI function IsSameObject with the implementation of `if_acmp` in the rest of the JVM. > > Tested locally. > > Fred Looks good. Did we run tier1-4 with -XX:+UseAltS*M ? ------------- Marked as reviewed by coleenp (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1905#pullrequestreview-3682686083 From mchevalier at openjdk.org Tue Jan 20 15:27:00 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Tue, 20 Jan 2026 15:27:00 GMT Subject: [lworld] RFR: 8375441: [lworld] C2: assert(is_instance()) failed: bad cast In-Reply-To: <9W3_n3NgGCOz84Mp-zLZd02fktXLE5JeYrzO536Nacc=.77989015-de29-44e2-bfa0-b2ba27121dc9@github.com> References: <9W3_n3NgGCOz84Mp-zLZd02fktXLE5JeYrzO536Nacc=.77989015-de29-44e2-bfa0-b2ba27121dc9@github.com> Message-ID: <-AeBLmdjJ0l3F6sineGBFK5x7AZ8Sw2-Wpe1Rgso40c=.b14d892c-3cde-4b69-9cdc-8322c0f978e8@github.com> On Tue, 20 Jan 2026 13:04:15 GMT, Quan Anh Mai wrote: >> I fear I don't understand. Let's say, I have a flat array `MyValue[] arr` where `MyValue` is a value class with a single field `f`. Let's also assume `arr[0] == null`, `arr.field_value(0, f)` (assuming the `ci...` versions of it with matching names) tries to get the constant value of the field `f` of `arr[0]`, and `arr[0].f` is not null, it's rather undefined. It's not about stability and folding. On the other hand, if `arr[0]` is not null, but `arr[0].f` is null, `arr.field_value(0, f)` already returns `null` (the `ciConstant` that means that). >> >> Am I missing something? > > That is only true from the Java perspective. From the VM perspective, a flat array would be something like (C++ pseudocode): > > class MyValuePayload { > oop* f; > bool null_marker; > }; > > MyValuePayload* arr = new MyValuePayload[n]; > > Then, it is clear that even if `arr[0].null_marker == false`, `arr[0].f` is still defined and has a value (which should be `nullptr`). As discussed offline, I'm trying change that. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1923#discussion_r2708846928 From vromero at openjdk.org Tue Jan 20 15:30:41 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 Jan 2026 15:30:41 GMT Subject: RFR: add use site null checks for fields [v9] In-Reply-To: References: Message-ID: > generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations > > [1] https://github.com/openjdk/valhalla/pull/1910 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: adding import ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1926/files - new: https://git.openjdk.org/valhalla/pull/1926/files/27a45c8a..bd5937c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=08 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1926&range=07-08 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1926.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1926/head:pull/1926 PR: https://git.openjdk.org/valhalla/pull/1926 From vromero at openjdk.org Tue Jan 20 15:30:43 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 Jan 2026 15:30:43 GMT Subject: RFR: add use site null checks for fields [v8] In-Reply-To: References: Message-ID: <1ZrCXkKwGuH1UvUW7EauAEzGhT8DKT-fUpvdI17MgAc=.468a8949-2dbb-4f98-a132-4c3d7baefb2a@github.com> On Mon, 19 Jan 2026 20:26:36 GMT, Vicente Romero wrote: >> generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations >> >> [1] https://github.com/openjdk/valhalla/pull/1910 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > minor change thanks for the comments and suggestions! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1926#issuecomment-3773445089 From vromero at openjdk.org Tue Jan 20 15:30:44 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 Jan 2026 15:30:44 GMT Subject: Integrated: add use site null checks for fields In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 20:07:59 GMT, Vicente Romero wrote: > generate null checks for field use sites depending on a compiler option, see also [1] which did a similar thing for method invocations > > [1] https://github.com/openjdk/valhalla/pull/1910 This pull request has now been integrated. Changeset: 67758d3b Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/67758d3bda6e0abdb9d5fe9e0d8c5f84176518b1 Stats: 140 lines in 3 files changed: 130 ins; 0 del; 10 mod add use site null checks for fields Reviewed-by: liach, mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1926 From qamai at openjdk.org Tue Jan 20 15:52:13 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 20 Jan 2026 15:52:13 GMT Subject: [lworld] RFR: 8372824: [lworld] C2 hits "Unexpected argument type" assertion with --enable-preview Message-ID: Since I overrode `MyValue1::equals` in #1929 , `TestIntrinsics` has failed with `-XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. The failed test is this one: // Value class array creation via reflection @Test public void test51(int len) { Object[] va = (Object[])Array.newInstance(MyValue1.class, len); for (int i = 0; i < len; ++i) { Asserts.assertEQ(va[i], null); } } During parsing, `Array::newInstance` is not inlined, so `va` is of type `Object[]` and `va[i]` is of type `Object`. `Asserts.assertEQ` calls `va[i].equals(null)` which resolves to a `CallJavaDynamic` with its receiver of type `Object`, which is passed in as an oop. During incremental inline, It is revealed that `va` is a `MyValue1[]` and `va[i]` is of type `MyValue1`. This allows the devirtualization of `va[i]::equals`. Since this is a method call on a value object, the calling convention changes, which leads to the assert because the input is an oop. I relaxed the assert a little bit to allow changing of the calling convention due to devirtualization. Please take a look and leave your review, thansk a lot. ------------- Commit messages: - Fix assert due to devirtualized methods Changes: https://git.openjdk.org/valhalla/pull/1935/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1935&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372824 Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1935.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1935/head:pull/1935 PR: https://git.openjdk.org/valhalla/pull/1935 From qamai at openjdk.org Tue Jan 20 15:58:52 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 20 Jan 2026 15:58:52 GMT Subject: [lworld] RFR: 8372824: [lworld] C2 hits "Unexpected argument type" assertion with --enable-preview [v2] In-Reply-To: References: Message-ID: > Since I overrode `MyValue1::equals` in #1929 , `TestIntrinsics` has failed with `-XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. The failed test is this one: > > // Value class array creation via reflection > @Test > public void test51(int len) { > Object[] va = (Object[])Array.newInstance(MyValue1.class, len); > for (int i = 0; i < len; ++i) { > Asserts.assertEQ(va[i], null); > } > } > > During parsing, `Array::newInstance` is not inlined, so `va` is of type `Object[]` and `va[i]` is of type `Object`. `Asserts.assertEQ` calls `va[i].equals(null)` which resolves to a `CallJavaDynamic` with its receiver of type `Object`, which is passed in as an oop. During incremental inline, It is revealed that `va` is a `MyValue1[]` and `va[i]` is of type `MyValue1`. This allows the devirtualization of `va[i]::equals`. Since this is a method call on a value object, the calling convention changes, which leads to the assert because the input is an oop. > > I relaxed the assert a little bit to allow changing of the calling convention due to devirtualization. > > Please take a look and leave your review, thansk a lot. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: Unproblemlist ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1935/files - new: https://git.openjdk.org/valhalla/pull/1935/files/b9994691..5000c519 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1935&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1935&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1935.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1935/head:pull/1935 PR: https://git.openjdk.org/valhalla/pull/1935 From thartmann at openjdk.org Tue Jan 20 16:25:15 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 20 Jan 2026 16:25:15 GMT Subject: [lworld] RFR: 8372824: [lworld] C2 hits "Unexpected argument type" assertion with --enable-preview [v2] In-Reply-To: References: Message-ID: <2p52uxSLjznAupFdtLAyW0KIBY1NPtmviIxqXPcif8U=.e2830af3-59d3-4732-9dd8-98e99bdad478@github.com> On Tue, 20 Jan 2026 15:58:52 GMT, Quan Anh Mai wrote: >> Since I overrode `MyValue1::equals` in #1929 , `TestIntrinsics` has failed with `-XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. The failed test is this one: >> >> // Value class array creation via reflection >> @Test >> public void test51(int len) { >> Object[] va = (Object[])Array.newInstance(MyValue1.class, len); >> for (int i = 0; i < len; ++i) { >> Asserts.assertEQ(va[i], null); >> } >> } >> >> During parsing, `Array::newInstance` is not inlined, so `va` is of type `Object[]` and `va[i]` is of type `Object`. `Asserts.assertEQ` calls `va[i].equals(null)` which resolves to a `CallJavaDynamic` with its receiver of type `Object`, which is passed in as an oop. During incremental inline, It is revealed that `va` is a `MyValue1[]` and `va[i]` is of type `MyValue1`. This allows the devirtualization of `va[i]::equals`. Since this is a method call on a value object, the calling convention changes, which leads to the assert because the input is an oop. >> >> I relaxed the assert a little bit to allow changing of the calling convention due to devirtualization. >> >> Please take a look and leave your review, thansk a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > Unproblemlist src/hotspot/share/opto/graphKit.cpp line 1960: > 1958: // scalarized receiver instead. > 1959: assert(arg_idx == 0 && !call->method()->is_static(), "must be the receiver"); > 1960: arg = InlineTypeNode::make_from_oop(this, arg, t->inline_klass()); So this is post-parse call-devirtualization, i.e. [JDK-8257211](https://bugs.openjdk.org/browse/JDK-8257211), right? Could we assert `call->generator()->is_virtual_late_inline()` here? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1935#discussion_r2709104941 From fparain at openjdk.org Tue Jan 20 16:40:10 2026 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 20 Jan 2026 16:40:10 GMT Subject: [lworld] RFR: 8375328: [lworld] JNI IsSameObject function doesn't use the alternate substitutability method In-Reply-To: <4QQd_MRPk32VsB4eyiDeREYs4hN2RhyOR7R1ae7YAKg=.80f83b87-e95d-4b29-88d8-22521f39f351@github.com> References: <4QQd_MRPk32VsB4eyiDeREYs4hN2RhyOR7R1ae7YAKg=.80f83b87-e95d-4b29-88d8-22521f39f351@github.com> Message-ID: On Tue, 20 Jan 2026 15:08:49 GMT, Coleen Phillimore wrote: > Looks good. Did we run tier1-4 with -XX:+UseAltS*M ? We need JDK-837472 to be in before being able to run all these tiers reliably with the alternate substitutability method. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1905#issuecomment-3773862008 From fparain at openjdk.org Tue Jan 20 16:40:12 2026 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 20 Jan 2026 16:40:12 GMT Subject: [lworld] RFR: 8375328: [lworld] JNI IsSameObject function doesn't use the alternate substitutability method In-Reply-To: References: Message-ID: <-BTHeEbogdyH7R3CCF9RCgJGJoU_a4AYRTnqDZGDIhc=.601cf9de-4d5f-4ff7-8375-e194f6dbaaad@github.com> On Wed, 14 Jan 2026 18:46:30 GMT, Dan Heidinga wrote: >> Small fix to align the implementation of JNI function IsSameObject with the implementation of `if_acmp` in the rest of the JVM. >> >> Tested locally. >> >> Fred > > looks good Thanks @DanHeidinga @coleenp for your reviews. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1905#issuecomment-3773863373 From fparain at openjdk.org Tue Jan 20 16:44:25 2026 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 20 Jan 2026 16:44:25 GMT Subject: [lworld] Integrated: 8375328: [lworld] JNI IsSameObject function doesn't use the alternate substitutability method In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 17:20:04 GMT, Frederic Parain wrote: > Small fix to align the implementation of JNI function IsSameObject with the implementation of `if_acmp` in the rest of the JVM. > > Tested locally. > > Fred This pull request has now been integrated. Changeset: a4464150 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/a446415038f526d97e4333e6866a5b7acce004cd Stats: 11 lines in 2 files changed: 10 ins; 0 del; 1 mod 8375328: [lworld] JNI IsSameObject function doesn't use the alternate substitutability method Reviewed-by: heidinga, coleenp ------------- PR: https://git.openjdk.org/valhalla/pull/1905 From vromero at openjdk.org Tue Jan 20 16:54:48 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 Jan 2026 16:54:48 GMT Subject: RFR: Fixing completion detection for null-restricted variables and fixing behavior for incorrect null-restricted variables without an initializer. In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 15:42:46 GMT, Jan Lahoda wrote: > Fixing behavior in two cases: > - `String! str = ""` (i.e. missing semicolon) should work. This is achieved by fixing the completion analysis to report the snippet as `COMPLETE_WITH_SEMI`. > - `String! str` (i.e. missing initializer). This should produce an error saying initializer is required, achieved by not using the null initializer in this case. lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1932#pullrequestreview-3683215479 From mcimadamore at openjdk.org Tue Jan 20 16:54:49 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 20 Jan 2026 16:54:49 GMT Subject: RFR: Fixing completion detection for null-restricted variables and fixing behavior for incorrect null-restricted variables without an initializer. In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 15:42:46 GMT, Jan Lahoda wrote: > Fixing behavior in two cases: > - `String! str = ""` (i.e. missing semicolon) should work. This is achieved by fixing the completion analysis to report the snippet as `COMPLETE_WITH_SEMI`. > - `String! str` (i.e. missing initializer). This should produce an error saying initializer is required, achieved by not using the null initializer in this case. Looks good! ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1932#pullrequestreview-3683216630 From jsikstro at openjdk.org Tue Jan 20 18:04:53 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 20 Jan 2026 18:04:53 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime Message-ID: Hello, Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. Testing: * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug ------------- Commit messages: - 8375719: [lworld] Move reads of flat fields entirely to the runtime Changes: https://git.openjdk.org/valhalla/pull/1936/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1936&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375719 Stats: 125 lines in 7 files changed: 12 ins; 97 del; 16 mod Patch: https://git.openjdk.org/valhalla/pull/1936.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1936/head:pull/1936 PR: https://git.openjdk.org/valhalla/pull/1936 From coleenp at openjdk.org Tue Jan 20 18:36:15 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 20 Jan 2026 18:36:15 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v2] In-Reply-To: References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: On Fri, 16 Jan 2026 21:17:56 GMT, Matias Saavedra Silva wrote: >> The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. >> >> Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. >> >> Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Coleen and Fred comments Mostly good, but one thing needs to be changed. src/hotspot/share/classfile/classFileParser.cpp line 5549: > 5547: int acmp_map_size = nonoop_acmp_map_size + oop_acmp_map_size + 1; > 5548: > 5549: Array* acmp_maps_array = MetadataFactory::new_array(loader_data(), acmp_map_size, CHECK); It's actually really important that this line is after 5550. with a comment like: // Create metadata after potential OOM so this does not have to be cleaned up in the ClassFileParser destructor. ------------- Changes requested by coleenp (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1903#pullrequestreview-3672834837 PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2709597602 From coleenp at openjdk.org Tue Jan 20 18:36:18 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 20 Jan 2026 18:36:18 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v2] In-Reply-To: References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: On Fri, 16 Jan 2026 21:02:07 GMT, Matias Saavedra Silva wrote: >> src/hotspot/share/cds/cdsHeapVerifier.cpp line 312: >> >>> 310: // Any concrete value class will have a field ".null_reset" which holds an >>> 311: // all-zero instance of the value class so it will not change between >>> 312: // dump time and runtime. >> >> I'm not sure how this comment about the .null_reset value applies in this if statement? It doesn't seem related to the LIMITATION comment above and there doesn't seem to be anything special done for null reset here either. > > Without the if statement, we'd see an error stating that a class has a static field whose value may differ between dumptime and runtime, specifically referring to `.null_reset`. This is currently the only case to cause any issues so I figured mentioning it in a comment would be useful. ok ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2700055309 From darcy at openjdk.org Tue Jan 20 18:41:40 2026 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 20 Jan 2026 18:41:40 GMT Subject: RFR: 8335451: Prototype support for an exact integer arithmetic type Message-ID: The Math class has support for "exact" forms of int and long add, subtract, multiply, and divide that throw exceptions instead of wrapping around in a two's complement sense. This nested class in Integer prototype what adding type-level support for that functionality would look like. ------------- Commit messages: - 8335451: Prototype support for an exact integer arithmetic type Changes: https://git.openjdk.org/valhalla/pull/1937/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1937&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335451 Stats: 426 lines in 1 file changed: 425 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1937.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1937/head:pull/1937 PR: https://git.openjdk.org/valhalla/pull/1937 From qamai at openjdk.org Tue Jan 20 19:05:33 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 20 Jan 2026 19:05:33 GMT Subject: [lworld] RFR: 8372824: [lworld] C2 hits "Unexpected argument type" assertion with --enable-preview [v2] In-Reply-To: <2p52uxSLjznAupFdtLAyW0KIBY1NPtmviIxqXPcif8U=.e2830af3-59d3-4732-9dd8-98e99bdad478@github.com> References: <2p52uxSLjznAupFdtLAyW0KIBY1NPtmviIxqXPcif8U=.e2830af3-59d3-4732-9dd8-98e99bdad478@github.com> Message-ID: On Tue, 20 Jan 2026 16:23:08 GMT, Tobias Hartmann wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> Unproblemlist > > src/hotspot/share/opto/graphKit.cpp line 1960: > >> 1958: // scalarized receiver instead. >> 1959: assert(arg_idx == 0 && !call->method()->is_static(), "must be the receiver"); >> 1960: arg = InlineTypeNode::make_from_oop(this, arg, t->inline_klass()); > > So this is post-parse call-devirtualization, i.e. [JDK-8257211](https://bugs.openjdk.org/browse/JDK-8257211), right? Could we assert `call->generator()->is_virtual_late_inline()` here? Unfortunately, the `CallNode` here does not have a generator, because it is created just above. Checking `is_late_inline` does not work either, because we are too deep handling now. `LateInlineVirtualCallGenerator::do_late_inline_check` calls into `Compile::call_generator` to find the replacement. This method, after deciding that it does not want to inline the callee, will create a `PredictedCallGenerator` with the fast path being a `DirectCallGenerator`. And this `DirectCallGenerator` is the one calling the method we are in, and this subclass of `CallGenerator` does not return `true` for `is_late_inline()`. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1935#discussion_r2709698942 From vromero at openjdk.org Tue Jan 20 19:05:44 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 Jan 2026 19:05:44 GMT Subject: RFR: Minor cleanup, preview and since In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 23:07:33 GMT, Chen Liang wrote: > Add a preview feature for the NR jep, other stylistic cleanup lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1927#pullrequestreview-3683837897 From liach at openjdk.org Tue Jan 20 19:11:23 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 19:11:23 GMT Subject: RFR: Minor cleanup, preview and since In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 23:07:33 GMT, Chen Liang wrote: > Add a preview feature for the NR jep, other stylistic cleanup Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1927#issuecomment-3774506311 From liach at openjdk.org Tue Jan 20 19:14:36 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 19:14:36 GMT Subject: Integrated: Minor cleanup, preview and since In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 23:07:33 GMT, Chen Liang wrote: > Add a preview feature for the NR jep, other stylistic cleanup This pull request has now been integrated. Changeset: a30f3876 Author: Chen Liang URL: https://git.openjdk.org/valhalla/commit/a30f387618e7fd5df3fd5371fb472e895c1c9af2 Stats: 15 lines in 4 files changed: 8 ins; 2 del; 5 mod Minor cleanup, preview and since Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1927 From vromero at openjdk.org Tue Jan 20 19:21:39 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 Jan 2026 19:21:39 GMT Subject: RFR: Classfile signature bang support In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 16:46:29 GMT, Chen Liang wrote: > Support parsing ! signatures in ClassFile API. src/java.base/share/classes/java/lang/classfile/Signature.java line 277: > 275: @Override > 276: default ClassTypeSig nullUnmarked() { > 277: return nullMarker(NullMarker.UNMARKED); question: why not using the same terminology as used in javac: CHECKED == NOT_NULL UNMARKED == UNSPECIFIED? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2709752015 From cjplummer at openjdk.org Tue Jan 20 19:43:21 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Jan 2026 19:43:21 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v4] In-Reply-To: <5kHPQPGP150SmC3IeFFycWm5FYTBed5OtzbeGkzSI0E=.4cfae6e4-5b23-48da-a0ae-580859635146@github.com> References: <5kHPQPGP150SmC3IeFFycWm5FYTBed5OtzbeGkzSI0E=.4cfae6e4-5b23-48da-a0ae-580859635146@github.com> Message-ID: On Wed, 14 Jan 2026 22:36:54 GMT, Alex Menkov wrote: >> src/java.se/share/data/jdwp/jdwp.spec line 1804: >> >>> 1802: ) >>> 1803: ) >>> 1804: (Command IsSameObject=11 >> >> Are you going to add "preview API" warnings to these two APIs? > > I'm not sure it makes much sense. > They are quite generic, I think about adding them to mainline in jdk 27 (but don't use by ObjectReferenceImpl.equals/hashCode) They might be generic, but they serve no useful purpose outside of valhalla support. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2709774103 From cjplummer at openjdk.org Tue Jan 20 19:43:23 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Jan 2026 19:43:23 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:19:33 GMT, Alex Menkov wrote: >> src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 177: >> >>> 175: @Override >>> 176: public int hashCode() { >>> 177: if (isValueObject() && vm.canUseIsSameObject()) { >> >> I don't see how this logic can be correct for value objects if vm.canUseIsSameObject() returns false. We still have a value object in that case. Is using Long.hashCode(ref()) the right thing to do? Same thing applies to equals() above. I think if a JVM supports value objects then the debug agent has to support IsSameObject and HashCode. The version check should really only be in regard to whether or not value objects are supported in general by the JVM, because if they are they have to be supported by the debug agent. > > We should execute jdwp command only when it's available (vm.canUseIsSameObject returns true) and the object is value object. > Note that isValueObject() may not work for old releases, so we need to check both conditions here or move version check to ClassTypeImpl.isValueClass If the JVM supports value objects, the debug agent has to support IsSameObject and ObjectHashCode. I don't see how we can have a functional JDWP and JDI otherwise. The logic above is proving that. It allows for the impossible to support situation where isValueObject() can return true, yet IsSameObject is not supported, meaning we can't properly compute the hash code. If IsValueObject returns true, the invariant should be that IsSameObject is supported. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2709790985 From cjplummer at openjdk.org Tue Jan 20 19:43:27 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Jan 2026 19:43:27 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v4] In-Reply-To: References: Message-ID: <_TqrlmObzXPz-24qqejrNLFGtnak42tC_AJ_UfFofgI=.a5c818c1-7bb9-46a2-b4c7-18e535b5c265@github.com> On Fri, 16 Jan 2026 22:11:21 GMT, Alex Menkov wrote: >> Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. >> Added the test for value object ctor debugging, the test verifies the behaviour is expected. >> There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) >> >> testing: tier1..4, hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > space test/jdk/com/sun/jdi/valhalla/CtorDebuggingTest.java line 84: > 82: - all 3 references exists; > 83: - there are references for 1 and 3 breakpoints. > 84: These comment lines should all start with a "*". ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2709809770 From coleenp at openjdk.org Tue Jan 20 20:33:51 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 20 Jan 2026 20:33:51 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 17:56:00 GMT, Joel Sikstr?m wrote: > Hello, > > Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). > > The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. > > I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. > > Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. > > As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. > > Testing: > * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug I have a small request, but otherwise this looks great. Thank you for doing this! src/hotspot/share/interpreter/interpreterRuntime.cpp line 246: > 244: // If the field is nullable and is marked null, return early. > 245: if (LayoutKindHelper::is_nullable_flat(lk) && > 246: field_klass->is_payload_marked_as_null(cast_from_oop

(obj) + offset)) { I wonder if there's a way to ask this and have the address calculation be hidden in InstanceKlass, like find_field_from_offset ? So we don't have to know here if the offset includes the header or not? Or even just add a is_payload_marked_as_null(oop, offset) to hide the calculation inside of inlineKlass.inline.hpp? ------------- Marked as reviewed by coleenp (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1936#pullrequestreview-3684143613 PR Review Comment: https://git.openjdk.org/valhalla/pull/1936#discussion_r2709956745 From darcy at openjdk.org Tue Jan 20 20:56:54 2026 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 20 Jan 2026 20:56:54 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v4] In-Reply-To: References: Message-ID: > A refinement of some earlier ideas on the numerics modeling interfaces to inform further discussions. > > This is a "lumpy" rather than "splitty" design in terms of favoring a smaller number of interfaces with more functionality rather than a larger number of interfaces making smaller distinctions. > > Various design comments and to-do's noted in the code. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add apiNote on closure under different operations, etc. ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1917/files - new: https://git.openjdk.org/valhalla/pull/1917/files/1a1713ec..7620d79d Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1917&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1917&range=02-03 Stats: 53 lines in 1 file changed: 33 ins; 7 del; 13 mod Patch: https://git.openjdk.org/valhalla/pull/1917.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1917/head:pull/1917 PR: https://git.openjdk.org/valhalla/pull/1917 From darcy at openjdk.org Tue Jan 20 21:00:42 2026 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 20 Jan 2026 21:00:42 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v4] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:56:54 GMT, Joe Darcy wrote: >> A refinement of some earlier ideas on the numerics modeling interfaces to inform further discussions. >> >> This is a "lumpy" rather than "splitty" design in terms of favoring a smaller number of interfaces with more functionality rather than a larger number of interfaces making smaller distinctions. >> >> Various design comments and to-do's noted in the code. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add apiNote on closure under different operations, etc. >From experience working on https://github.com/openjdk/valhalla/pull/1937, pushed another changeset to this PR discussion closure properties of different operations and how they are expected to be documented. In other words, if value is not returned for a particular combination of operands, the expectation is that an ArithmeticException will be thrown and the conditions under which that exception would be thrown should be documented in the numerical type. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1917#issuecomment-3774913598 From liach at openjdk.org Tue Jan 20 21:05:29 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 21:05:29 GMT Subject: [lworld] RFR: 8375740: [lworld] javap prints "value class" while class flags indicate ACC_IDENTITY Message-ID: Seems like an oversight where "value" is added unconditionally. I changed the behavior to add "identity" for preview identity classes, which was never printed before (because identity is not a source modifier) Testing: langtools/tools/javap + javac ------------- Commit messages: - 8375740: [lworld] javap prints "value class" while class flags indicate ACC_IDENTITY Changes: https://git.openjdk.org/valhalla/pull/1938/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1938&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375740 Stats: 47 lines in 2 files changed: 36 ins; 0 del; 11 mod Patch: https://git.openjdk.org/valhalla/pull/1938.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1938/head:pull/1938 PR: https://git.openjdk.org/valhalla/pull/1938 From liach at openjdk.org Tue Jan 20 21:23:41 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 21:23:41 GMT Subject: RFR: Classfile signature bang support [v2] In-Reply-To: References: Message-ID: > Support parsing ! signatures in ClassFile API. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Review, various cleanup - Merge branch 'bworld' of https://github.com/openjdk/valhalla into feature/cf-bang-sig - Classfile signature bang support ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1933/files - new: https://git.openjdk.org/valhalla/pull/1933/files/b256fe21..335464c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1933&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1933&range=00-01 Stats: 211 lines in 11 files changed: 164 ins; 2 del; 45 mod Patch: https://git.openjdk.org/valhalla/pull/1933.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1933/head:pull/1933 PR: https://git.openjdk.org/valhalla/pull/1933 From liach at openjdk.org Tue Jan 20 21:47:31 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 21:47:31 GMT Subject: RFR: Classfile signature bang support [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 19:17:48 GMT, Vicente Romero wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Review, various cleanup >> - Merge branch 'bworld' of https://github.com/openjdk/valhalla into feature/cf-bang-sig >> - Classfile signature bang support > > src/java.base/share/classes/java/lang/classfile/Signature.java line 277: > >> 275: @Override >> 276: default ClassTypeSig nullUnmarked() { >> 277: return nullMarker(NullMarker.UNMARKED); > > question: why not using the same terminology as used in javac: > > CHECKED == NOT_NULL > UNMARKED == UNSPECIFIED? Done. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2710177032 From matsaave at openjdk.org Tue Jan 20 21:52:00 2026 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 20 Jan 2026 21:52:00 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v2] In-Reply-To: References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: <4SSixvS4VDNmMSTEv5JmsNOUwfksruV6ea_76XUjS9A=.0b0fe76b-5006-4052-a083-85b42e3a1732@github.com> On Sat, 17 Jan 2026 05:01:42 GMT, Ioi Lam wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Coleen and Fred comments > > src/hotspot/share/oops/instanceKlass.cpp line 3152: > >> 3150: } >> 3151: java_mirror()->obj_field_put(_acmp_maps_offset, map_h()); >> 3152: } > > Is it necessary to restore `null_reset_value()` as well? The null reset value is generated in `InstanceKlass:initialize()` so we don't need to regenerate it here. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2710191425 From matsaave at openjdk.org Tue Jan 20 22:12:30 2026 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 20 Jan 2026 22:12:30 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v3] In-Reply-To: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: <3kO8uoUMvn_WPrzVersSRQbcPjSg-Df4aFGE-w-idNM=.76bc6f06-66c4-4c1d-99c9-3e76bead8601@github.com> > The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. > > Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. > > Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'lworld' into substitutability_cds - Coleen comments and new test - Coleen and Fred comments - More cleanup - Cleanup - Merge branch 'lworld' into substitutability_cds - Changed SubstitutabilityTest - Regenerate acmp_maps at runtime with metadata copy - Test fixes and exclude inline klasses from dynamic archive - Unproblemlist SubstitutabilityTest - ... and 4 more: https://git.openjdk.org/valhalla/compare/a4464150...760217c4 ------------- Changes: https://git.openjdk.org/valhalla/pull/1903/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1903&range=02 Stats: 214 lines in 13 files changed: 174 ins; 32 del; 8 mod Patch: https://git.openjdk.org/valhalla/pull/1903.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1903/head:pull/1903 PR: https://git.openjdk.org/valhalla/pull/1903 From vromero at openjdk.org Tue Jan 20 23:52:04 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 Jan 2026 23:52:04 GMT Subject: [lworld] RFR: 8375740: [lworld] javap prints "value class" while class flags indicate ACC_IDENTITY In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:58:46 GMT, Chen Liang wrote: > Seems like an oversight where "value" is added unconditionally. I changed the behavior to add "identity" for preview identity classes, which was never printed before (because identity is not a source modifier) > > Testing: langtools/tools/javap + javac lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1938#pullrequestreview-3684756207 From vromero at openjdk.org Tue Jan 20 23:58:14 2026 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 Jan 2026 23:58:14 GMT Subject: [lworld] RFR: 8375740: [lworld] javap prints "value class" while class flags indicate ACC_IDENTITY In-Reply-To: References: Message-ID: <-CpUYC_HJjFBMuaE21-arWzC79MVW2gu3UsmqZr3Oqo=.ed307a9e-a6a9-4f78-a72b-ac77036ceb52@github.com> On Tue, 20 Jan 2026 20:58:46 GMT, Chen Liang wrote: > Seems like an oversight where "value" is added unconditionally. I changed the behavior to add "identity" for preview identity classes, which was never printed before (because identity is not a source modifier) > > Testing: langtools/tools/javap + javac src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java line 825: > 823: Set classModifers = getModifiers(flagSet); > 824: // ACC_IDENTITY is not a source modifier > 825: classModifers.add(flagSet.contains(AccessFlag.IDENTITY) ? "identity" : "value"); nit, I would say probably better to print nothing if the class is identity and print `value` if it is a value class ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1938#discussion_r2710473329 From liach at openjdk.org Wed Jan 21 00:02:11 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 00:02:11 GMT Subject: [lworld] RFR: 8375740: [lworld] javap prints "value class" while class flags indicate ACC_IDENTITY [v2] In-Reply-To: References: Message-ID: > Seems like an oversight where "value" is added unconditionally. I changed the behavior to add "identity" for preview identity classes, which was never printed before (because identity is not a source modifier) > > Testing: langtools/tools/javap + javac Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Don't emit spurious identity ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1938/files - new: https://git.openjdk.org/valhalla/pull/1938/files/c06db063..50d7b76f Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1938&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1938&range=00-01 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1938.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1938/head:pull/1938 PR: https://git.openjdk.org/valhalla/pull/1938 From vromero at openjdk.org Wed Jan 21 00:10:15 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 21 Jan 2026 00:10:15 GMT Subject: [lworld] RFR: 8375740: [lworld] javap prints "value class" while class flags indicate ACC_IDENTITY [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 00:02:11 GMT, Chen Liang wrote: >> Seems like an oversight where "value" is added unconditionally. I changed the behavior to add "identity" for preview identity classes, which was never printed before (because identity is not a source modifier) >> >> Testing: langtools/tools/javap + javac > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Don't emit spurious identity lgtm ------------- Marked as reviewed by vromero (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1938#pullrequestreview-3684791995 From liach at openjdk.org Wed Jan 21 00:10:16 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 00:10:16 GMT Subject: [lworld] RFR: 8375740: [lworld] javap prints "value class" while class flags indicate ACC_IDENTITY [v2] In-Reply-To: References: Message-ID: <261N8hBa2hfGV7w3VqoVVqizm5Iu_zx5REc3-lohTeo=.d31dc1a3-b2d9-402c-951c-0b645a109e05@github.com> On Wed, 21 Jan 2026 00:02:11 GMT, Chen Liang wrote: >> Seems like an oversight where "value" is added unconditionally. I changed the behavior to add "identity" for preview identity classes, which was never printed before (because identity is not a source modifier) >> >> Testing: langtools/tools/javap + javac > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Don't emit spurious identity Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1938#issuecomment-3775521263 From liach at openjdk.org Wed Jan 21 00:10:17 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 00:10:17 GMT Subject: [lworld] Integrated: 8375740: [lworld] javap prints "value class" while class flags indicate ACC_IDENTITY In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:58:46 GMT, Chen Liang wrote: > Seems like an oversight where "value" is added unconditionally. I changed the behavior to add "identity" for preview identity classes, which was never printed before (because identity is not a source modifier) > > Testing: langtools/tools/javap + javac This pull request has now been integrated. Changeset: fa557ef3 Author: Chen Liang URL: https://git.openjdk.org/valhalla/commit/fa557ef342086c240a4a2b5356fcd7b4affbd2bb Stats: 48 lines in 2 files changed: 37 ins; 0 del; 11 mod 8375740: [lworld] javap prints "value class" while class flags indicate ACC_IDENTITY Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1938 From vromero at openjdk.org Wed Jan 21 00:50:20 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 21 Jan 2026 00:50:20 GMT Subject: RFR: add different flavors to the useSiteNullChecks compiler option Message-ID: Changing the option to indicate if use site null checks should be emitted for fields and methods. The option has be renamed to: `useSiteNullChecks` with sub-options to indicate if no use site checks should be generated, or if it should be generated only for methods or for methods and fields. The default is generating the checks for fields and methods ------------- Commit messages: - add different flavors to the useSiteNullChecks compiler option Changes: https://git.openjdk.org/valhalla/pull/1939/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1939&range=00 Stats: 67 lines in 2 files changed: 49 ins; 0 del; 18 mod Patch: https://git.openjdk.org/valhalla/pull/1939.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1939/head:pull/1939 PR: https://git.openjdk.org/valhalla/pull/1939 From sspitsyn at openjdk.org Wed Jan 21 04:35:56 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Jan 2026 04:35:56 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v4] In-Reply-To: References: Message-ID: <7c1fSsXikm7zrthFQ43slnIasPaH4ST1B8u19wBnhnI=.a0af2fdd-d66b-47b4-a305-f462dfe4f852@github.com> On Fri, 16 Jan 2026 22:11:21 GMT, Alex Menkov wrote: >> Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects. >> Added the test for value object ctor debugging, the test verifies the behaviour is expected. >> There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it) >> >> testing: tier1..4, hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > space src/java.se/share/data/jdwp/jdwp.spec line 1830: > 1828: (Error VM_DEAD) > 1829: ) > 1830: ) As we discussed, "since" is needed and with possible preview comment (check what we had for Loom preview). src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 170: > 168: throw exc.toJDIException(); > 169: } > 170: } Nit: The lines 164, 177 can be simplified a little bit with move of the renamed `vm.canUseIsSameObject()` check equivalent to the `isValueClass()`. src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java line 841: > 839: return versionInfo().jdwpMajor >= 27; > 840: } > 841: Nit: We may want to generalize this with something like 'maySupportValueClasses()'. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2710915871 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2710925978 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2710919494 From cjplummer at openjdk.org Wed Jan 21 04:45:26 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 21 Jan 2026 04:45:26 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v4] In-Reply-To: <7c1fSsXikm7zrthFQ43slnIasPaH4ST1B8u19wBnhnI=.a0af2fdd-d66b-47b4-a305-f462dfe4f852@github.com> References: <7c1fSsXikm7zrthFQ43slnIasPaH4ST1B8u19wBnhnI=.a0af2fdd-d66b-47b4-a305-f462dfe4f852@github.com> Message-ID: <-NlCRLnhE4pno9y9Ghm0SR1bjp3Df7nDmJ9SJpa24Gs=.1d8ff7e7-71d8-4767-a22c-45b5328b3379@github.com> On Wed, 21 Jan 2026 04:31:41 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> space > > src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 170: > >> 168: throw exc.toJDIException(); >> 169: } >> 170: } > > Nit: The lines 164, 177 can be simplified a little bit with move of the renamed `vm.canUseIsSameObject()` check equivalent to the `isValueClass()`. If Valhalla is not supported on the target VM, there is no way for isValueClass() or isValueObject() to ever return true. If Valhalla is supported, they can return true, and we have to assume that JDWP and the debug agent support Valhalla also. We can't have Valhalla support in the JVM and not also have it in JDWP and the debug agent. The debugger/JDI will break if isValueObject() returns false for a value object. > src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java line 841: > >> 839: return versionInfo().jdwpMajor >= 27; >> 840: } >> 841: > > Nit: We may want to generalize this with something like 'maySupportValueClasses()'. I'm not so sure this API is really even needed. I don't believe the current calls to it are valid. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2710939565 PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2710942102 From aboldtch at openjdk.org Wed Jan 21 06:55:13 2026 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 21 Jan 2026 06:55:13 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:25:55 GMT, Coleen Phillimore wrote: >> Hello, >> >> Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). >> >> The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. >> >> I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. >> >> Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. >> >> As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. >> >> Testing: >> * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug > > src/hotspot/share/interpreter/interpreterRuntime.cpp line 246: > >> 244: // If the field is nullable and is marked null, return early. >> 245: if (LayoutKindHelper::is_nullable_flat(lk) && >> 246: field_klass->is_payload_marked_as_null(cast_from_oop
(obj) + offset)) { > > I wonder if there's a way to ask this and have the address calculation be hidden in InstanceKlass, like find_field_from_offset ? So we don't have to know here if the offset includes the header or not? Or even just add a is_payload_marked_as_null(oop, offset) to hide the calculation inside of inlineKlass.inline.hpp? I am working on trying to create something for representing an InlineKlass payload in the runtime code. It achives exactly this. Current work in progress: https://github.com/openjdk/valhalla/commit/5df331779cbb6e83493260d41dcdcd97a67ab495 ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1936#discussion_r2711197739 From phubner at openjdk.org Wed Jan 21 08:59:38 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Wed, 21 Jan 2026 08:59:38 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 17:56:00 GMT, Joel Sikstr?m wrote: > Hello, > > Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). > > The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. > > I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. > > Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. > > As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. > > Testing: > * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug Looks good, just one quick question. src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 263: > 261: pop(obj); > 262: bind(slow_path); > 263: call_VM(obj, CAST_FROM_FN_PTR(address, InterpreterRuntime::read_flat_field), In your writeup you mention `call_VM_leaf` is called, but I only see references to `call_VM` in the code yet the comments say `call_VM_leaf`. Do we/did we `call_VM_leaf` at any point? ------------- Marked as reviewed by phubner (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1936#pullrequestreview-3685996335 PR Review Comment: https://git.openjdk.org/valhalla/pull/1936#discussion_r2711541494 From jsikstro at openjdk.org Wed Jan 21 09:20:55 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 21 Jan 2026 09:20:55 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime In-Reply-To: References: Message-ID: <7-xxixtfccTxGfcqi9kMaz8-8DfmExQZ20fOW6Jdo-4=.3456006c-6f0c-43ce-a216-ad1a73fcda47@github.com> On Wed, 21 Jan 2026 08:47:25 GMT, Paul H?bner wrote: >> Hello, >> >> Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). >> >> The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. >> >> I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. >> >> Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. >> >> As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. >> >> Testing: >> * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug > > src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 263: > >> 261: pop(obj); >> 262: bind(slow_path); >> 263: call_VM(obj, CAST_FROM_FN_PTR(address, InterpreterRuntime::read_flat_field), > > In your writeup you mention `call_VM_leaf` is called, but I only see references to `call_VM` in the code yet the comments say `call_VM_leaf`. Do we/did we `call_VM_leaf` at any point? The call to `call_VM_leaf` is in the copy-path: MacroAssembler::flat_field_copy BarrierSetAssembler::flat_field_copy call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSetRuntime::value_copy), ...) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1936#discussion_r2711662366 From jsikstro at openjdk.org Wed Jan 21 09:26:07 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 21 Jan 2026 09:26:07 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 06:48:16 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/interpreter/interpreterRuntime.cpp line 246: >> >>> 244: // If the field is nullable and is marked null, return early. >>> 245: if (LayoutKindHelper::is_nullable_flat(lk) && >>> 246: field_klass->is_payload_marked_as_null(cast_from_oop
(obj) + offset)) { >> >> I wonder if there's a way to ask this and have the address calculation be hidden in InstanceKlass, like find_field_from_offset ? So we don't have to know here if the offset includes the header or not? Or even just add a is_payload_marked_as_null(oop, offset) to hide the calculation inside of inlineKlass.inline.hpp? > > I am working on trying to create something for representing an InlineKlass payload in the runtime code. It achives exactly this. Current work in progress: https://github.com/openjdk/valhalla/commit/5df331779cbb6e83493260d41dcdcd97a67ab495 Then I suggest we can hold off on this until Axel's patch is ready. I see he also takes care of similar casts + offsets in InlineKlass.cpp which is nice. https://github.com/openjdk/valhalla/blob/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548/src/hotspot/share/oops/inlineKlass.cpp#L238-L247 ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1936#discussion_r2711673147 From jsikstro at openjdk.org Wed Jan 21 10:29:00 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 21 Jan 2026 10:29:00 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime [v2] In-Reply-To: References: Message-ID: <9Js4ZkBRiPayzIUPN5Vc7j_qxdCrPRLnObZ9LV2UJmM=.8712a38a-0013-4edc-97cf-ac066c60d7ef@github.com> > Hello, > > Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). > > The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. > > I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. > > Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. > > As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. > > Testing: > * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Dont handle:ize obj in InterpreterRuntime::read_flat_field ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1936/files - new: https://git.openjdk.org/valhalla/pull/1936/files/61c1f4cf..469258ee Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1936&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1936&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1936.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1936/head:pull/1936 PR: https://git.openjdk.org/valhalla/pull/1936 From jsikstro at openjdk.org Wed Jan 21 10:29:00 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 21 Jan 2026 10:29:00 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 17:56:00 GMT, Joel Sikstr?m wrote: > Hello, > > Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). > > The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. > > I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. > > Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. > > As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. > > Testing: > * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug I removed the Handle from `InterpreterRuntime::read_flat_field` since we don't need it here because we aren't using the object after the call to `read_payload_from_addr`. There is a Handle inside `read_payload_from_addr`, just before allocating the buffered object, which is enough. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1936#issuecomment-3777325705 From phubner at openjdk.org Wed Jan 21 10:34:26 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Wed, 21 Jan 2026 10:34:26 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime [v2] In-Reply-To: <9Js4ZkBRiPayzIUPN5Vc7j_qxdCrPRLnObZ9LV2UJmM=.8712a38a-0013-4edc-97cf-ac066c60d7ef@github.com> References: <9Js4ZkBRiPayzIUPN5Vc7j_qxdCrPRLnObZ9LV2UJmM=.8712a38a-0013-4edc-97cf-ac066c60d7ef@github.com> Message-ID: On Wed, 21 Jan 2026 10:29:00 GMT, Joel Sikstr?m wrote: >> Hello, >> >> Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). >> >> The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. >> >> I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. >> >> Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. >> >> As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. >> >> Testing: >> * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Dont handle:ize obj in InterpreterRuntime::read_flat_field Marked as reviewed by phubner (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1936#pullrequestreview-3686475611 From phubner at openjdk.org Wed Jan 21 10:34:28 2026 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Wed, 21 Jan 2026 10:34:28 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime [v2] In-Reply-To: <7-xxixtfccTxGfcqi9kMaz8-8DfmExQZ20fOW6Jdo-4=.3456006c-6f0c-43ce-a216-ad1a73fcda47@github.com> References: <7-xxixtfccTxGfcqi9kMaz8-8DfmExQZ20fOW6Jdo-4=.3456006c-6f0c-43ce-a216-ad1a73fcda47@github.com> Message-ID: On Wed, 21 Jan 2026 09:18:44 GMT, Joel Sikstr?m wrote: >> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 263: >> >>> 261: pop(obj); >>> 262: bind(slow_path); >>> 263: call_VM(obj, CAST_FROM_FN_PTR(address, InterpreterRuntime::read_flat_field), >> >> In your writeup you mention `call_VM_leaf` is called, but I only see references to `call_VM` in the code yet the comments say `call_VM_leaf`. Do we/did we `call_VM_leaf` at any point? > > The call to `call_VM_leaf` is in the copy-path: > > > MacroAssembler::flat_field_copy > BarrierSetAssembler::flat_field_copy > call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSetRuntime::value_copy), ...) Makes sense, thank you for clarifying. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1936#discussion_r2711945980 From mcimadamore at openjdk.org Wed Jan 21 10:35:31 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 21 Jan 2026 10:35:31 GMT Subject: RFR: add different flavors to the useSiteNullChecks compiler option In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 00:43:37 GMT, Vicente Romero wrote: > Changing the option to indicate if use site null checks should be emitted for fields and methods. The option has be renamed to: `useSiteNullChecks` with sub-options to indicate if no use site checks should be generated, or if it should be generated only for methods or for methods and fields. The default is generating the checks for fields and methods Looks good -- I left a stylistic/cleanup suggestion src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 95: > 93: } else { > 94: useSiteNullChecks = switch (opt) { > 95: case "none" -> UseSiteNullChecks.NONE; You could make the code a bit tighter by moving the names like "none" etc. inside the Enum (e.g. each constant has its own name). Then you can have an enum factory that takes a String (the javac option value) and returns the corresponding enum, if any is found. We use that pattern elsewhere in javac ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1939#pullrequestreview-3686477700 PR Review Comment: https://git.openjdk.org/valhalla/pull/1939#discussion_r2711947688 From thartmann at openjdk.org Wed Jan 21 11:32:05 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 21 Jan 2026 11:32:05 GMT Subject: [lworld] RFR: 8372824: [lworld] C2 hits "Unexpected argument type" assertion with --enable-preview [v2] In-Reply-To: References: <2p52uxSLjznAupFdtLAyW0KIBY1NPtmviIxqXPcif8U=.e2830af3-59d3-4732-9dd8-98e99bdad478@github.com> Message-ID: On Tue, 20 Jan 2026 19:01:14 GMT, Quan Anh Mai wrote: >> src/hotspot/share/opto/graphKit.cpp line 1960: >> >>> 1958: // scalarized receiver instead. >>> 1959: assert(arg_idx == 0 && !call->method()->is_static(), "must be the receiver"); >>> 1960: arg = InlineTypeNode::make_from_oop(this, arg, t->inline_klass()); >> >> So this is post-parse call-devirtualization, i.e. [JDK-8257211](https://bugs.openjdk.org/browse/JDK-8257211), right? Could we assert `call->generator()->is_virtual_late_inline()` here? > > Unfortunately, the `CallNode` here does not have a generator, because it is created just above. Checking `is_late_inline` does not work either, because we are too deep handling now. `LateInlineVirtualCallGenerator::do_late_inline_check` calls into `Compile::call_generator` to find the replacement. This method, after deciding that it does not want to inline the callee, will create a `PredictedCallGenerator` with the fast path being a `DirectCallGenerator`. And this `DirectCallGenerator` is the one calling the method we are in, and this subclass of `CallGenerator` does not return `true` for `is_late_inline()`. Ah, too bad. What about `Compile::strength_reduction` that @dafedafe introduced with https://github.com/openjdk/valhalla/pull/1768? I think it would just be nice to have a strong assert here because these kind of asserts helped in the past to catch cases where we failed to scalarize early. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1935#discussion_r2712152107 From duke at openjdk.org Wed Jan 21 13:17:28 2026 From: duke at openjdk.org (duke) Date: Wed, 21 Jan 2026 13:17:28 GMT Subject: RFR: Fixing completion detection for null-restricted variables and fixing behavior for incorrect null-restricted variables without an initializer. In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 15:42:46 GMT, Jan Lahoda wrote: > Fixing behavior in two cases: > - `String! str = ""` (i.e. missing semicolon) should work. This is achieved by fixing the completion analysis to report the snippet as `COMPLETE_WITH_SEMI`. > - `String! str` (i.e. missing initializer). This should produce an error saying initializer is required, achieved by not using the null initializer in this case. @lahodaj Your change (at version 8eefe1bb2f8e57f901cea8e62d1005335ee68217) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1932#issuecomment-3778084339 From fparain at openjdk.org Wed Jan 21 13:27:57 2026 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 21 Jan 2026 13:27:57 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v3] In-Reply-To: <3kO8uoUMvn_WPrzVersSRQbcPjSg-Df4aFGE-w-idNM=.76bc6f06-66c4-4c1d-99c9-3e76bead8601@github.com> References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> <3kO8uoUMvn_WPrzVersSRQbcPjSg-Df4aFGE-w-idNM=.76bc6f06-66c4-4c1d-99c9-3e76bead8601@github.com> Message-ID: On Tue, 20 Jan 2026 22:12:30 GMT, Matias Saavedra Silva wrote: >> The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. >> >> Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. >> >> Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. > > Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'lworld' into substitutability_cds > - Coleen comments and new test > - Coleen and Fred comments > - More cleanup > - Cleanup > - Merge branch 'lworld' into substitutability_cds > - Changed SubstitutabilityTest > - Regenerate acmp_maps at runtime with metadata copy > - Test fixes and exclude inline klasses from dynamic archive > - Unproblemlist SubstitutabilityTest > - ... and 4 more: https://git.openjdk.org/valhalla/compare/a4464150...760217c4 LGTM ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1903#pullrequestreview-3687230576 From vromero at openjdk.org Wed Jan 21 14:28:11 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 21 Jan 2026 14:28:11 GMT Subject: RFR: add different flavors to the useSiteNullChecks compiler option [v2] In-Reply-To: References: Message-ID: > Changing the option to indicate if use site null checks should be emitted for fields and methods. The option has be renamed to: `useSiteNullChecks` with sub-options to indicate if no use site checks should be generated, or if it should be generated only for methods or for methods and fields. The default is generating the checks for fields and methods Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: - removing unused variable - addressing review comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1939/files - new: https://git.openjdk.org/valhalla/pull/1939/files/c3fbd863..f804e6d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1939&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1939&range=00-01 Stats: 38 lines in 1 file changed: 23 ins; 13 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1939.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1939/head:pull/1939 PR: https://git.openjdk.org/valhalla/pull/1939 From vromero at openjdk.org Wed Jan 21 14:28:12 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 21 Jan 2026 14:28:12 GMT Subject: RFR: add different flavors to the useSiteNullChecks compiler option [v2] In-Reply-To: References: Message-ID: <2qbrb_jpBGDQ6CRmwHlUqpgvFbWN9GcvTWw05gX60Wg=.834cd687-0311-4dbe-8c5b-5a8d2043cb28@github.com> On Wed, 21 Jan 2026 10:31:14 GMT, Maurizio Cimadamore wrote: >> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: >> >> - removing unused variable >> - addressing review comments > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/NullChecksWriter.java line 95: > >> 93: } else { >> 94: useSiteNullChecks = switch (opt) { >> 95: case "none" -> UseSiteNullChecks.NONE; > > You could make the code a bit tighter by moving the names like "none" etc. inside the Enum (e.g. each constant has its own name). Then you can have an enum factory that takes a String (the javac option value) and returns the corresponding enum, if any is found. We use that pattern elsewhere in javac sure, done ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1939#discussion_r2712812178 From liach at openjdk.org Wed Jan 21 15:07:40 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 15:07:40 GMT Subject: [lworld] RFR: 8351362: [lworld] Post-process @Strict annotation for testing Message-ID: Introduce a test-only `@StrictInit` annotation for injecting `ACC_STRICT_INIT` to class files. ------------- Commit messages: - Extra diff - Tweak approach - Junk - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/strict-processor - Merge branch 'test/strict-processor' of github.com:liach/valhalla into test/strict-processor - Rollback to the jdk internal strict annotation - Revert back to the jdk internal strict - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/strict-processor - Fix a bug and enhance tests - Add very primitive super rewrite functionality - ... and 3 more: https://git.openjdk.org/valhalla/compare/fa557ef3...ca1885eb Changes: https://git.openjdk.org/valhalla/pull/1940/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1940&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351362 Stats: 479 lines in 4 files changed: 479 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1940.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1940/head:pull/1940 PR: https://git.openjdk.org/valhalla/pull/1940 From vromero at openjdk.org Wed Jan 21 15:13:45 2026 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 21 Jan 2026 15:13:45 GMT Subject: Integrated: add different flavors to the useSiteNullChecks compiler option In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 00:43:37 GMT, Vicente Romero wrote: > Changing the option to indicate if use site null checks should be emitted for fields and methods. The option has be renamed to: `useSiteNullChecks` with sub-options to indicate if no use site checks should be generated, or if it should be generated only for methods or for methods and fields. The default is generating the checks for fields and methods This pull request has now been integrated. Changeset: 4f31dc35 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/4f31dc35ea8c7904f41f0981493895740dad799e Stats: 77 lines in 2 files changed: 59 ins; 0 del; 18 mod add different flavors to the useSiteNullChecks compiler option Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1939 From matsaave at openjdk.org Wed Jan 21 15:18:50 2026 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 21 Jan 2026 15:18:50 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v4] In-Reply-To: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: > The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. > > Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. > > Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Fixed copyright ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1903/files - new: https://git.openjdk.org/valhalla/pull/1903/files/760217c4..ef0b75e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1903&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1903&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1903.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1903/head:pull/1903 PR: https://git.openjdk.org/valhalla/pull/1903 From coleenp at openjdk.org Wed Jan 21 15:18:51 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 21 Jan 2026 15:18:51 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v4] In-Reply-To: References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: On Wed, 21 Jan 2026 15:14:36 GMT, Matias Saavedra Silva wrote: >> The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. >> >> Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. >> >> Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Fixed copyright Thank you! Nice work!! ------------- Marked as reviewed by coleenp (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1903#pullrequestreview-3687759199 From matsaave at openjdk.org Wed Jan 21 15:18:52 2026 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 21 Jan 2026 15:18:52 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v4] In-Reply-To: References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: On Wed, 21 Jan 2026 15:11:02 GMT, Coleen Phillimore wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed copyright > > Thank you! Nice work!! Thank you for the reviews @coleenp, @fparain, and @iklam! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1903#issuecomment-3778680903 From coleenp at openjdk.org Wed Jan 21 15:18:58 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 21 Jan 2026 15:18:58 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v3] In-Reply-To: <3kO8uoUMvn_WPrzVersSRQbcPjSg-Df4aFGE-w-idNM=.76bc6f06-66c4-4c1d-99c9-3e76bead8601@github.com> References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> <3kO8uoUMvn_WPrzVersSRQbcPjSg-Df4aFGE-w-idNM=.76bc6f06-66c4-4c1d-99c9-3e76bead8601@github.com> Message-ID: On Tue, 20 Jan 2026 22:12:30 GMT, Matias Saavedra Silva wrote: >> The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. >> >> Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. >> >> Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. > > Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'lworld' into substitutability_cds > - Coleen comments and new test > - Coleen and Fred comments > - More cleanup > - Cleanup > - Merge branch 'lworld' into substitutability_cds > - Changed SubstitutabilityTest > - Regenerate acmp_maps at runtime with metadata copy > - Test fixes and exclude inline klasses from dynamic archive > - Unproblemlist SubstitutabilityTest > - ... and 4 more: https://git.openjdk.org/valhalla/compare/a4464150...760217c4 test/hotspot/jtreg/runtime/cds/appcds/test-classes/NullableFlatFieldApp.java line 2: > 1: /* > 2: * Copyright (c) 2024, 2025, Oracle and/or its affiliates. All rights reserved. Can you fix the copyright to just 2026 since it appears to be a new test? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2712996484 From matsaave at openjdk.org Wed Jan 21 15:19:01 2026 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 21 Jan 2026 15:19:01 GMT Subject: [lworld] Integrated: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod In-Reply-To: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: On Wed, 14 Jan 2026 15:05:24 GMT, Matias Saavedra Silva wrote: > The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. > > Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. > > Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. This pull request has now been integrated. Changeset: 8f8398ed Author: Matias Saavedra Silva URL: https://git.openjdk.org/valhalla/commit/8f8398ed6822ebda78c17230555e3ae210e3aacb Stats: 215 lines in 13 files changed: 174 ins; 32 del; 9 mod 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod Reviewed-by: coleenp, fparain ------------- PR: https://git.openjdk.org/valhalla/pull/1903 From qamai at openjdk.org Wed Jan 21 15:39:54 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 21 Jan 2026 15:39:54 GMT Subject: [lworld] RFR: 8372824: [lworld] C2 hits "Unexpected argument type" assertion with --enable-preview [v3] In-Reply-To: References: Message-ID: > Since I overrode `MyValue1::equals` in #1929 , `TestIntrinsics` has failed with `-XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. The failed test is this one: > > // Value class array creation via reflection > @Test > public void test51(int len) { > Object[] va = (Object[])Array.newInstance(MyValue1.class, len); > for (int i = 0; i < len; ++i) { > Asserts.assertEQ(va[i], null); > } > } > > During parsing, `Array::newInstance` is not inlined, so `va` is of type `Object[]` and `va[i]` is of type `Object`. `Asserts.assertEQ` calls `va[i].equals(null)` which resolves to a `CallJavaDynamic` with its receiver of type `Object`, which is passed in as an oop. During incremental inline, It is revealed that `va` is a `MyValue1[]` and `va[i]` is of type `MyValue1`. This allows the devirtualization of `va[i]::equals`. Since this is a method call on a value object, the calling convention changes, which leads to the assert because the input is an oop. > > I relaxed the assert a little bit to allow changing of the calling convention due to devirtualization. > > Please take a look and leave your review, thansk a lot. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: assert that we are during devirtualization of calls ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1935/files - new: https://git.openjdk.org/valhalla/pull/1935/files/5000c519..147fa71e Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1935&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1935&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1935.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1935/head:pull/1935 PR: https://git.openjdk.org/valhalla/pull/1935 From qamai at openjdk.org Wed Jan 21 15:43:31 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 21 Jan 2026 15:43:31 GMT Subject: [lworld] RFR: 8372824: [lworld] C2 hits "Unexpected argument type" assertion with --enable-preview [v4] In-Reply-To: References: Message-ID: > Since I overrode `MyValue1::equals` in #1929 , `TestIntrinsics` has failed with `-XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. The failed test is this one: > > // Value class array creation via reflection > @Test > public void test51(int len) { > Object[] va = (Object[])Array.newInstance(MyValue1.class, len); > for (int i = 0; i < len; ++i) { > Asserts.assertEQ(va[i], null); > } > } > > During parsing, `Array::newInstance` is not inlined, so `va` is of type `Object[]` and `va[i]` is of type `Object`. `Asserts.assertEQ` calls `va[i].equals(null)` which resolves to a `CallJavaDynamic` with its receiver of type `Object`, which is passed in as an oop. During incremental inline, It is revealed that `va` is a `MyValue1[]` and `va[i]` is of type `MyValue1`. This allows the devirtualization of `va[i]::equals`. Since this is a method call on a value object, the calling convention changes, which leads to the assert because the input is an oop. > > I relaxed the assert a little bit to allow changing of the calling convention due to devirtualization. > > Please take a look and leave your review, thansk a lot. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: assert that we are during devirtualization of calls ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1935/files - new: https://git.openjdk.org/valhalla/pull/1935/files/147fa71e..f3f230f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1935&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1935&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1935.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1935/head:pull/1935 PR: https://git.openjdk.org/valhalla/pull/1935 From qamai at openjdk.org Wed Jan 21 15:43:32 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 21 Jan 2026 15:43:32 GMT Subject: [lworld] RFR: 8372824: [lworld] C2 hits "Unexpected argument type" assertion with --enable-preview [v2] In-Reply-To: References: <2p52uxSLjznAupFdtLAyW0KIBY1NPtmviIxqXPcif8U=.e2830af3-59d3-4732-9dd8-98e99bdad478@github.com> Message-ID: <7LoUoZ7EHqXIqPf03FqWSFXa4sqo_Sy7rNt9f-5HttU=.3d964268-4d89-4a7b-8c0d-8b5b14ef1307@github.com> On Wed, 21 Jan 2026 11:29:18 GMT, Tobias Hartmann wrote: >> Unfortunately, the `CallNode` here does not have a generator, because it is created just above. Checking `is_late_inline` does not work either, because we are too deep handling now. `LateInlineVirtualCallGenerator::do_late_inline_check` calls into `Compile::call_generator` to find the replacement. This method, after deciding that it does not want to inline the callee, will create a `PredictedCallGenerator` with the fast path being a `DirectCallGenerator`. And this `DirectCallGenerator` is the one calling the method we are in, and this subclass of `CallGenerator` does not return `true` for `is_late_inline()`. > > Ah, too bad. What about `Compile::strength_reduction` that @dafedafe introduced with https://github.com/openjdk/valhalla/pull/1768? I think it would just be nice to have a strong assert here because these kind of asserts helped in the past to catch cases where we failed to scalarize early. Thanks for the pointer, I have added some asserts that we are during call devirtualization, not during parsing. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1935#discussion_r2713148087 From mcimadamore at openjdk.org Wed Jan 21 15:58:32 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 21 Jan 2026 15:58:32 GMT Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects [v3] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 17:57:26 GMT, Chen Liang wrote: >> Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas > - Remove test as permitted > - Fixes, VHTMHAV now passes > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas > - A test > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas > - Attempt to fix garbage cas The code changes look good (a test would be good tho). I left some comments to try and clarify the docs. src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2873: > 2871: // (see VarHandles::isAtomicFlat). > 2872: > 2873: // array 0: witness (to translate to object), 1: x (to translate to raw) This comment is hard to read, for a number of reasons: * it uses 0/1, but then the code uses `base`/`base + scale` (understandably so) * translate to object/translate to raw -- yes, `x` starts off as a value object and we use the array to derive its "raw" representation, whereas witness is always a "raw" value, and stored into the array so we can get it back "as a value". But since this is finicky logic, all this should be spelled out more. * the caller can "capture the witness" -- maybe "observe" the (last) witness would be more correct? * "we must witness the raw value instead of the value object" -- well, even the old code was witnessing a raw value (of sort) -- the issue is how you compute such a raw value. The fix in this PR is that the raw value is accessed directly from memory (e.g. the content of `o` at offset `offset`). E.g. it feels like you are "overloading" what "raw" means -- in some cases you mean "raw == numeric, or !value", in other cases you mean "raw as in -- as accessed from memory" ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1734#pullrequestreview-3688009476 PR Review Comment: https://git.openjdk.org/valhalla/pull/1734#discussion_r2713216128 From mcimadamore at openjdk.org Wed Jan 21 16:01:33 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 21 Jan 2026 16:01:33 GMT Subject: RFR: Classfile signature bang support [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 21:23:41 GMT, Chen Liang wrote: >> Support parsing ! signatures in ClassFile API. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Review, various cleanup > - Merge branch 'bworld' of https://github.com/openjdk/valhalla into feature/cf-bang-sig > - Classfile signature bang support src/java.base/share/classes/java/lang/classfile/ClassSignature.java line 84: > 82: * @param superclassSignature the superclass > 83: * @param superinterfaceSignatures the interfaces > 84: * @throws IllegalArgumentException if any signature has null marker Suggestion: * @throws IllegalArgumentException if any signature has null markers src/java.base/share/classes/java/lang/classfile/ClassSignature.java line 96: > 94: * @param superclassSignature the superclass > 95: * @param superinterfaceSignatures the interfaces > 96: * @throws IllegalArgumentException if any signature has null marker Suggestion: * @throws IllegalArgumentException if any signature has null markers src/java.base/share/classes/java/lang/classfile/MethodSignature.java line 136: > 134: * @param arguments signatures for the method parameters > 135: * @throws IllegalArgumentException if any of {@code arguments} is void or > 136: * any of the exceptions signatures has null marker Suggestion: * any of the exceptions signatures has null markers ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2713228222 PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2713228897 PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2713229939 From thartmann at openjdk.org Wed Jan 21 16:08:00 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 21 Jan 2026 16:08:00 GMT Subject: [lworld] RFR: 8372824: [lworld] C2 hits "Unexpected argument type" assertion with --enable-preview [v4] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 15:43:31 GMT, Quan Anh Mai wrote: >> Since I overrode `MyValue1::equals` in #1929 , `TestIntrinsics` has failed with `-XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. The failed test is this one: >> >> // Value class array creation via reflection >> @Test >> public void test51(int len) { >> Object[] va = (Object[])Array.newInstance(MyValue1.class, len); >> for (int i = 0; i < len; ++i) { >> Asserts.assertEQ(va[i], null); >> } >> } >> >> During parsing, `Array::newInstance` is not inlined, so `va` is of type `Object[]` and `va[i]` is of type `Object`. `Asserts.assertEQ` calls `va[i].equals(null)` which resolves to a `CallJavaDynamic` with its receiver of type `Object`, which is passed in as an oop. During incremental inline, It is revealed that `va` is a `MyValue1[]` and `va[i]` is of type `MyValue1`. This allows the devirtualization of `va[i]::equals`. Since this is a method call on a value object, the calling convention changes, which leads to the assert because the input is an oop. >> >> I relaxed the assert a little bit to allow changing of the calling convention due to devirtualization. >> >> Please take a look and leave your review, thansk a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > assert that we are during devirtualization of calls Great! That looks good to me. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1935#pullrequestreview-3688050846 From mcimadamore at openjdk.org Wed Jan 21 16:12:23 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 21 Jan 2026 16:12:23 GMT Subject: RFR: Classfile signature bang support [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:02:05 GMT, Maurizio Cimadamore wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Review, various cleanup >> - Merge branch 'bworld' of https://github.com/openjdk/valhalla into feature/cf-bang-sig >> - Classfile signature bang support > > src/java.base/share/classes/java/lang/classfile/Signature.java line 295: > >> 293: >> 294: /** >> 295: * {@return a class or interface signature without an outer type} > > Maybe we should say that, by default, the returned signature is NOT null marked? Same for other sig factories (like ArrayType, Typevar) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2713251579 From mcimadamore at openjdk.org Wed Jan 21 16:12:22 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 21 Jan 2026 16:12:22 GMT Subject: RFR: Classfile signature bang support [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 21:23:41 GMT, Chen Liang wrote: >> Support parsing ! signatures in ClassFile API. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Review, various cleanup > - Merge branch 'bworld' of https://github.com/openjdk/valhalla into feature/cf-bang-sig > - Classfile signature bang support Looks good - I've left some doc notes and some test comments src/java.base/share/classes/java/lang/classfile/Signature.java line 295: > 293: > 294: /** > 295: * {@return a class or interface signature without an outer type} Maybe we should say that, by default, the returned signature is NOT null marked? src/java.base/share/classes/jdk/internal/classfile/impl/SignaturesImpl.java line 212: > 210: boolean end = match(';'); > 211: if (end || match('.')) { > 212: t = new ClassTypeSigImpl(RefTypeSig.NullMarker.UNSPECIFIED, Optional.ofNullable(t), className, null2Empty(argTypes)); Why not going through the `of` factory? test/jdk/jdk/classfile/SignaturesTest.java line 409: > 407: <:Ljava/lang/Object;>Ljava/lang/Object; > 408: <>Ljava/lang/Object; > 409: !Ljava/lang/Object; Why is this "bad" ? test/jdk/jdk/classfile/SignaturesTest.java line 411: > 409: !Ljava/lang/Object; > 410: Ljava/lang/Object;!Ljava/lang/Runnable; > 411: <>Ljava/lang/Object; This test line seems repeated? Or did you want to add a `!` here? ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1933#pullrequestreview-3688086862 PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2713246252 PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2713269249 PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2713278798 PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2713275824 From liach at openjdk.org Wed Jan 21 16:18:36 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 16:18:36 GMT Subject: RFR: Classfile signature bang support [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:07:23 GMT, Maurizio Cimadamore wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Review, various cleanup >> - Merge branch 'bworld' of https://github.com/openjdk/valhalla into feature/cf-bang-sig >> - Classfile signature bang support > > src/java.base/share/classes/jdk/internal/classfile/impl/SignaturesImpl.java line 212: > >> 210: boolean end = match(';'); >> 211: if (end || match('.')) { >> 212: t = new ClassTypeSigImpl(RefTypeSig.NullMarker.UNSPECIFIED, Optional.ofNullable(t), className, null2Empty(argTypes)); > > Why not going through the `of` factory? I think the old code tries to avoid defensive copy of `argTypes` to save some resources. > test/jdk/jdk/classfile/SignaturesTest.java line 409: > >> 407: <:Ljava/lang/Object;>Ljava/lang/Object; >> 408: <>Ljava/lang/Object; >> 409: !Ljava/lang/Object; > > Why is this "bad" ? This is a "bad" class signature; class signature is `superclass [interfaces]` so this is using a `!` type in a superclass. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2713303450 PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2713299796 From coleenp at openjdk.org Wed Jan 21 18:09:40 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 21 Jan 2026 18:09:40 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 09:21:40 GMT, Joel Sikstr?m wrote: >> I am working on trying to create something for representing an InlineKlass payload in the runtime code. It achives exactly this. Current work in progress: https://github.com/openjdk/valhalla/commit/5df331779cbb6e83493260d41dcdcd97a67ab495 > > Then I suggest we can hold off on this until Axel's patch is ready. I see he also takes care of similar casts + offsets in InlineKlass.cpp which is nice. > https://github.com/openjdk/valhalla/blob/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548/src/hotspot/share/oops/inlineKlass.cpp#L238-L247 I don't know if it this should wait for Axel's patch, which I imagine is more extensive. I think you could push this first. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1936#discussion_r2713746115 From fparain at openjdk.org Wed Jan 21 18:42:02 2026 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 21 Jan 2026 18:42:02 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime [v2] In-Reply-To: <9Js4ZkBRiPayzIUPN5Vc7j_qxdCrPRLnObZ9LV2UJmM=.8712a38a-0013-4edc-97cf-ac066c60d7ef@github.com> References: <9Js4ZkBRiPayzIUPN5Vc7j_qxdCrPRLnObZ9LV2UJmM=.8712a38a-0013-4edc-97cf-ac066c60d7ef@github.com> Message-ID: On Wed, 21 Jan 2026 10:29:00 GMT, Joel Sikstr?m wrote: >> Hello, >> >> Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). >> >> The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. >> >> I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. >> >> Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. >> >> As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. >> >> Testing: >> * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Dont handle:ize obj in InterpreterRuntime::read_flat_field src/hotspot/cpu/x86/interp_masm_x86.cpp line 1171: > 1169: > 1170: movptr(tmp1, Address(entry, ResolvedFieldEntry::field_holder_offset())); > 1171: get_inline_type_field_klass(tmp1, tmp2, field_klass); This was the last place where get_inline_type_field_klass() was used, so this method can be removed from the MacroAssembler class. Note that get_inline_type_field_klass() was not used in the aarch64 implementation of read_flat_field(), but the get_inline_type_field_klass() method still exists in the aarch64 MacroAssembler. This dead code could be removed too. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1936#discussion_r2713809965 From fparain at openjdk.org Wed Jan 21 19:15:08 2026 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 21 Jan 2026 19:15:08 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v4] In-Reply-To: References: Message-ID: > Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case. > This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic. Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Fix to work with JDK-8374729 - Merge remote-tracking branch 'upstream/lworld' into flat_final - Fix coding style - More renaming - Cleanups and fixes - Fix Copyright years - Fix compilation - Merge remote-tracking branch 'upstream/lworld' into flat_final - Improve tests - Merge remote-tracking branch 'upstream/lworld' into flat_final - ... and 7 more: https://git.openjdk.org/valhalla/compare/8f8398ed...eab559d6 ------------- Changes: https://git.openjdk.org/valhalla/pull/1407/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1407&range=03 Stats: 760 lines in 22 files changed: 589 ins; 10 del; 161 mod Patch: https://git.openjdk.org/valhalla/pull/1407.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1407/head:pull/1407 PR: https://git.openjdk.org/valhalla/pull/1407 From coleenp at openjdk.org Wed Jan 21 19:22:23 2026 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 21 Jan 2026 19:22:23 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v4] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:15:08 GMT, Frederic Parain wrote: >> Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case. >> This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic. > > Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Fix to work with JDK-8374729 > - Merge remote-tracking branch 'upstream/lworld' into flat_final > - Fix coding style > - More renaming > - Cleanups and fixes > - Fix Copyright years > - Fix compilation > - Merge remote-tracking branch 'upstream/lworld' into flat_final > - Improve tests > - Merge remote-tracking branch 'upstream/lworld' into flat_final > - ... and 7 more: https://git.openjdk.org/valhalla/compare/8f8398ed...eab559d6 Looks good! ------------- Marked as reviewed by coleenp (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1407#pullrequestreview-3688989799 From liach at openjdk.org Wed Jan 21 19:43:05 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 19:43:05 GMT Subject: [lworld] RFR: 8351362: [lworld] Post-process @Strict annotation for testing [v2] In-Reply-To: References: Message-ID: > Introduce a test-only `@StrictInit` annotation for injecting `ACC_STRICT_INIT` to class files. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Open up methods for potential migration ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1940/files - new: https://git.openjdk.org/valhalla/pull/1940/files/ca1885eb..b422482a Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1940&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1940&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1940.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1940/head:pull/1940 PR: https://git.openjdk.org/valhalla/pull/1940 From duke at openjdk.org Wed Jan 21 20:20:28 2026 From: duke at openjdk.org (David Beaumont) Date: Wed, 21 Jan 2026 20:20:28 GMT Subject: [lworld] RFR: 8376029: [lworld] Remove dead code related to preview mode Message-ID: Remove dead code and make functions private. ------------- Commit messages: - Remove dead code and make functions private Changes: https://git.openjdk.org/valhalla/pull/1941/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1941&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376029 Stats: 21 lines in 2 files changed: 2 ins; 11 del; 8 mod Patch: https://git.openjdk.org/valhalla/pull/1941.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1941/head:pull/1941 PR: https://git.openjdk.org/valhalla/pull/1941 From liach at openjdk.org Wed Jan 21 20:27:43 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 20:27:43 GMT Subject: RFR: Classfile signature bang support [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:03:19 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/classfile/Signature.java line 295: >> >>> 293: >>> 294: /** >>> 295: * {@return a class or interface signature without an outer type} >> >> Maybe we should say that, by default, the returned signature is NOT null marked? > > Same for other sig factories (like ArrayType, Typevar) Done for all ref type sig factories. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2714207881 From liach at openjdk.org Wed Jan 21 20:27:37 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 20:27:37 GMT Subject: RFR: Classfile signature bang support [v3] In-Reply-To: References: Message-ID: > Support parsing ! signatures in ClassFile API. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Maurizio reviews ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1933/files - new: https://git.openjdk.org/valhalla/pull/1933/files/335464c6..37617697 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1933&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1933&range=01-02 Stats: 26 lines in 4 files changed: 12 ins; 0 del; 14 mod Patch: https://git.openjdk.org/valhalla/pull/1933.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1933/head:pull/1933 PR: https://git.openjdk.org/valhalla/pull/1933 From liach at openjdk.org Wed Jan 21 20:27:41 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 20:27:41 GMT Subject: RFR: Classfile signature bang support [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 21:23:41 GMT, Chen Liang wrote: >> Support parsing ! signatures in ClassFile API. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Review, various cleanup > - Merge branch 'bworld' of https://github.com/openjdk/valhalla into feature/cf-bang-sig > - Classfile signature bang support Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1933#issuecomment-3780999990 From liach at openjdk.org Wed Jan 21 20:27:48 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 20:27:48 GMT Subject: Integrated: Classfile signature bang support In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 16:46:29 GMT, Chen Liang wrote: > Support parsing ! signatures in ClassFile API. This pull request has now been integrated. Changeset: b9f91bd9 Author: Chen Liang URL: https://git.openjdk.org/valhalla/commit/b9f91bd93bbdb02e81ed8c7ae1bcf3dea93781df Stats: 291 lines in 5 files changed: 250 ins; 4 del; 37 mod Classfile signature bang support Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1933 From liach at openjdk.org Wed Jan 21 20:27:46 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 20:27:46 GMT Subject: RFR: Classfile signature bang support [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:08:56 GMT, Maurizio Cimadamore wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Review, various cleanup >> - Merge branch 'bworld' of https://github.com/openjdk/valhalla into feature/cf-bang-sig >> - Classfile signature bang support > > test/jdk/jdk/classfile/SignaturesTest.java line 411: > >> 409: !Ljava/lang/Object; >> 410: Ljava/lang/Object;!Ljava/lang/Runnable; >> 411: <>Ljava/lang/Object; > > This test line seems repeated? Or did you want to add a `!` here? Replaced with `Ljava/lang/Object;` which tries to represent ``, currently illegal ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1933#discussion_r2714210432 From liach at openjdk.org Wed Jan 21 22:13:13 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 22:13:13 GMT Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects [v4] In-Reply-To: References: Message-ID: > Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Comment update ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1734/files - new: https://git.openjdk.org/valhalla/pull/1734/files/c1659649..312b0427 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1734&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1734&range=02-03 Stats: 22 lines in 1 file changed: 0 ins; 1 del; 21 mod Patch: https://git.openjdk.org/valhalla/pull/1734.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1734/head:pull/1734 PR: https://git.openjdk.org/valhalla/pull/1734 From liach at openjdk.org Wed Jan 21 22:17:57 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 22:17:57 GMT Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects [v4] In-Reply-To: References: Message-ID: <0Pd5AS3iD9h8WZoIXGbWVWQHcW0LlxuhVhg2hYbFv6I=.2f83727d-6c16-4a4c-9704-7c5c556a9f6a@github.com> On Wed, 21 Jan 2026 22:13:13 GMT, Chen Liang wrote: >> Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Comment update I have updated the comment. Please help proofread again. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1734#issuecomment-3781403400 From darcy at openjdk.org Wed Jan 21 22:23:33 2026 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 21 Jan 2026 22:23:33 GMT Subject: RFR: 8338529: Initial iteration of numerics modeling interfaces [v3] In-Reply-To: References: Message-ID: <1uB0NSRxiiAyezWEYmcNjWmZ_wU73SaNfkt66T2rC2Y=.a466401e-34af-4e82-a646-ff78d9176a79@github.com> On Sat, 17 Jan 2026 00:03:51 GMT, John R Rose wrote: > I would prefer to see the ordering part tolerating partial orders (NaNs), and then factor the ordering part on top of both ints and floats. > > Also, in the name of reducing primitives, I think a `compare(x,y)` method is the correct primitive. It would return one of "lt", "gt", "eq", and (only for FP orders) "uo". All the others, up to min/max, can be built on top as default methods, even if they also end up hardwired to an override, for efficiency. To make progress on getting experience using type classes, I'm going to push the current state of the PR. Reconsidering how ordering is handled be done as future work, along with other refinements of the modeling interfaces. Thanks. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1917#issuecomment-3781419094 From darcy at openjdk.org Wed Jan 21 22:26:32 2026 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 21 Jan 2026 22:26:32 GMT Subject: Integrated: 8338529: Initial iteration of numerics modeling interfaces In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 04:51:29 GMT, Joe Darcy wrote: > A refinement of some earlier ideas on the numerics modeling interfaces to inform further discussions. > > This is a "lumpy" rather than "splitty" design in terms of favoring a smaller number of interfaces with more functionality rather than a larger number of interfaces making smaller distinctions. > > Various design comments and to-do's noted in the code. This pull request has now been integrated. Changeset: 7a8dc9c6 Author: Joe Darcy URL: https://git.openjdk.org/valhalla/commit/7a8dc9c66e2220b83c3003355dff2270fa2ee338 Stats: 741 lines in 4 files changed: 741 ins; 0 del; 0 mod 8338529: Initial iteration of numerics modeling interfaces ------------- PR: https://git.openjdk.org/valhalla/pull/1917 From sspitsyn at openjdk.org Thu Jan 22 02:06:50 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Jan 2026 02:06:50 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v4] In-Reply-To: <-NlCRLnhE4pno9y9Ghm0SR1bjp3Df7nDmJ9SJpa24Gs=.1d8ff7e7-71d8-4767-a22c-45b5328b3379@github.com> References: <7c1fSsXikm7zrthFQ43slnIasPaH4ST1B8u19wBnhnI=.a0af2fdd-d66b-47b4-a305-f462dfe4f852@github.com> <-NlCRLnhE4pno9y9Ghm0SR1bjp3Df7nDmJ9SJpa24Gs=.1d8ff7e7-71d8-4767-a22c-45b5328b3379@github.com> Message-ID: On Wed, 21 Jan 2026 04:40:12 GMT, Chris Plummer wrote: >> src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java line 170: >> >>> 168: throw exc.toJDIException(); >>> 169: } >>> 170: } >> >> Nit: The lines 164, 177 can be simplified a little bit with move of the renamed `vm.canUseIsSameObject()` check equivalent to the `isValueClass()`. > > If Valhalla is not supported on the target VM, there is no way for isValueClass() or isValueObject() to ever return true. If Valhalla is supported, they can return true, and we have to assume that JDWP and the debug agent support Valhalla also. We can't have Valhalla support in the JVM and not also have it in JDWP and the debug agent. The debugger/JDI will break if isValueObject() returns false for a value object. We had a private discussion with Alex on this. The `canUseIsSameObject()` equivalent is needed to make sure the Hotspot version is >= 27. The bit `(modifiers & VMModifiers.IDENTITY)` is reused by the Valhalla in jdk 27 preview. The bit was used for different purposes in `jdk versions < 27`. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2715033620 From cjplummer at openjdk.org Thu Jan 22 02:37:56 2026 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 22 Jan 2026 02:37:56 GMT Subject: [lworld] RFR: 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects [v4] In-Reply-To: References: <7c1fSsXikm7zrthFQ43slnIasPaH4ST1B8u19wBnhnI=.a0af2fdd-d66b-47b4-a305-f462dfe4f852@github.com> <-NlCRLnhE4pno9y9Ghm0SR1bjp3Df7nDmJ9SJpa24Gs=.1d8ff7e7-71d8-4767-a22c-45b5328b3379@github.com> Message-ID: On Thu, 22 Jan 2026 02:04:09 GMT, Serguei Spitsyn wrote: >> If Valhalla is not supported on the target VM, there is no way for isValueClass() or isValueObject() to ever return true. If Valhalla is supported, they can return true, and we have to assume that JDWP and the debug agent support Valhalla also. We can't have Valhalla support in the JVM and not also have it in JDWP and the debug agent. The debugger/JDI will break if isValueObject() returns false for a value object. > > We had a private discussion with Alex on this before you've added this comment. The `canUseIsSameObject()` or its equivalent is needed to make sure the Hotspot version is >= 27. The bit `(modifiers & VMModifiers.IDENTITY)` is reused by the Valhalla in jdk 27 preview. In `jdk versions < 27` this bit was used for different purposes. Ok, so isValueClass() should check the JDK version, but I don't think we need checks for the availability of IsSameObject or ObjectHashCode because they won't end up being used if the JVM does not support value classes because isValueClass() will always return false in that case. This is true even with JDK 27 when not using --enable-preview. We may also want to have the debug agent return an error if IsSameObject or ObjectHashCode are called and the JVM is not being run with --enable-preview. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2715083221 From qamai at openjdk.org Thu Jan 22 04:05:35 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 22 Jan 2026 04:05:35 GMT Subject: [lworld] RFR: 8372824: [lworld] C2 hits "Unexpected argument type" assertion with --enable-preview [v4] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 15:43:31 GMT, Quan Anh Mai wrote: >> Since I overrode `MyValue1::equals` in #1929 , `TestIntrinsics` has failed with `-XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. The failed test is this one: >> >> // Value class array creation via reflection >> @Test >> public void test51(int len) { >> Object[] va = (Object[])Array.newInstance(MyValue1.class, len); >> for (int i = 0; i < len; ++i) { >> Asserts.assertEQ(va[i], null); >> } >> } >> >> During parsing, `Array::newInstance` is not inlined, so `va` is of type `Object[]` and `va[i]` is of type `Object`. `Asserts.assertEQ` calls `va[i].equals(null)` which resolves to a `CallJavaDynamic` with its receiver of type `Object`, which is passed in as an oop. During incremental inline, It is revealed that `va` is a `MyValue1[]` and `va[i]` is of type `MyValue1`. This allows the devirtualization of `va[i]::equals`. Since this is a method call on a value object, the calling convention changes, which leads to the assert because the input is an oop. >> >> I relaxed the assert a little bit to allow changing of the calling convention due to devirtualization. >> >> Please take a look and leave your review, thansk a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > assert that we are during devirtualization of calls Thanks very much for your approval! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1935#issuecomment-3782394090 From qamai at openjdk.org Thu Jan 22 04:05:36 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 22 Jan 2026 04:05:36 GMT Subject: [lworld] Integrated: 8372824: [lworld] C2 hits "Unexpected argument type" assertion with --enable-preview In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 15:43:42 GMT, Quan Anh Mai wrote: > Since I overrode `MyValue1::equals` in #1929 , `TestIntrinsics` has failed with `-XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0`. The failed test is this one: > > // Value class array creation via reflection > @Test > public void test51(int len) { > Object[] va = (Object[])Array.newInstance(MyValue1.class, len); > for (int i = 0; i < len; ++i) { > Asserts.assertEQ(va[i], null); > } > } > > During parsing, `Array::newInstance` is not inlined, so `va` is of type `Object[]` and `va[i]` is of type `Object`. `Asserts.assertEQ` calls `va[i].equals(null)` which resolves to a `CallJavaDynamic` with its receiver of type `Object`, which is passed in as an oop. During incremental inline, It is revealed that `va` is a `MyValue1[]` and `va[i]` is of type `MyValue1`. This allows the devirtualization of `va[i]::equals`. Since this is a method call on a value object, the calling convention changes, which leads to the assert because the input is an oop. > > I relaxed the assert a little bit to allow changing of the calling convention due to devirtualization. > > Please take a look and leave your review, thansk a lot. This pull request has now been integrated. Changeset: d16ef895 Author: Quan Anh Mai URL: https://git.openjdk.org/valhalla/commit/d16ef895ef04054fe307853b4d75cbe91f807019 Stats: 17 lines in 2 files changed: 12 ins; 2 del; 3 mod 8372824: [lworld] C2 hits "Unexpected argument type" assertion with --enable-preview Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1935 From darcy at openjdk.org Thu Jan 22 05:51:52 2026 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 22 Jan 2026 05:51:52 GMT Subject: RFR: 8376040: Add prototype "textbook complex" class Message-ID: First cut at a version of complex numbers using the textbook algorithms for the arithmetic operations. This version is intended for prototyping and _not_ for production use. ------------- Commit messages: - Appease jcheck. - 8376040: Add prototype "textbook complex" class Changes: https://git.openjdk.org/valhalla/pull/1942/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1942&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376040 Stats: 446 lines in 1 file changed: 446 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1942.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1942/head:pull/1942 PR: https://git.openjdk.org/valhalla/pull/1942 From darcy at openjdk.org Thu Jan 22 05:51:52 2026 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 22 Jan 2026 05:51:52 GMT Subject: RFR: 8376040: Add prototype "textbook complex" class In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 00:35:05 GMT, Joe Darcy wrote: > First cut at a version of complex numbers using the textbook algorithms for the arithmetic operations. This version is intended for prototyping and _not_ for production use. Since the HTML markup in the javadoc for the arithmetic methods is hard to read, here is a copy and past of the rendered text: public static ComplexTextbook add(ComplexTextbook addend, ComplexTextbook augend) Addition operation, binary "+". Implementation Requirements: The computed sum is equivalent to (a + c) + i?(b + d). public static ComplexTextbook subtract(ComplexTextbook minuend, ComplexTextbook subtrahend) Subtraction operation, binary "-". Implementation Requirements: The computed difference is equivalent to (a ? c) + i?(b ? d). public static ComplexTextbook multiply(ComplexTextbook multiplier, ComplexTextbook multiplicand) Multiplication operation, "*". API Note: WARNING: while simple, the calculation technique used by this method is subject to spurious underflow and overflow as well as inaccurate component-wise results. Implementation Requirements: The computed product is calculated by (ac ? bd) + i?(ad + bc) public static ComplexTextbook divide(ComplexTextbook dividend, ComplexTextbook divisor) Division operation, "/". API Note: TODO: Bad numerical things can happen warning... Implementation Requirements: The computed quotient is calculated by (ac + bd)/(c? + d?) + i*(bc ? ad)/(c? + d?) ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1942#issuecomment-3782608915 From jsikstro at openjdk.org Thu Jan 22 09:04:33 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 22 Jan 2026 09:04:33 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime [v3] In-Reply-To: References: Message-ID: > Hello, > > Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). > > The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. > > I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. > > Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. > > As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. > > Testing: > * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Remove unused MacroAssembler::get_inline_type_field_klass ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1936/files - new: https://git.openjdk.org/valhalla/pull/1936/files/469258ee..9c6990b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1936&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1936&range=01-02 Stats: 16 lines in 4 files changed: 0 ins; 16 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1936.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1936/head:pull/1936 PR: https://git.openjdk.org/valhalla/pull/1936 From jsikstro at openjdk.org Thu Jan 22 09:04:36 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 22 Jan 2026 09:04:36 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime [v3] In-Reply-To: References: <9Js4ZkBRiPayzIUPN5Vc7j_qxdCrPRLnObZ9LV2UJmM=.8712a38a-0013-4edc-97cf-ac066c60d7ef@github.com> Message-ID: On Wed, 21 Jan 2026 18:22:27 GMT, Frederic Parain wrote: >> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused MacroAssembler::get_inline_type_field_klass > > src/hotspot/cpu/x86/interp_masm_x86.cpp line 1171: > >> 1169: >> 1170: movptr(tmp1, Address(entry, ResolvedFieldEntry::field_holder_offset())); >> 1171: get_inline_type_field_klass(tmp1, tmp2, field_klass); > > This was the last place where get_inline_type_field_klass() was used, so this method can be removed from the MacroAssembler class. > Note that get_inline_type_field_klass() was not used in the aarch64 implementation of read_flat_field(), but the get_inline_type_field_klass() method still exists in the aarch64 MacroAssembler. This dead code could be removed too. Good catch! I've removed `get_inline_type_field_klass` in both aarch64 and x86 implementations in a new commit. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1936#discussion_r2715937324 From jsikstro at openjdk.org Thu Jan 22 09:04:38 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 22 Jan 2026 09:04:38 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 18:05:50 GMT, Coleen Phillimore wrote: >> Then I suggest we can hold off on this until Axel's patch is ready. I see he also takes care of similar casts + offsets in InlineKlass.cpp which is nice. >> https://github.com/openjdk/valhalla/blob/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548/src/hotspot/share/oops/inlineKlass.cpp#L238-L247 > > I don't know if it this should wait for Axel's patch, which I imagine is more extensive. I think you could push this first. Sorry, I meant holding off on addressing the casts ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1936#discussion_r2715925596 From dsimms at openjdk.org Thu Jan 22 09:30:40 2026 From: dsimms at openjdk.org (David Simms) Date: Thu, 22 Jan 2026 09:30:40 GMT Subject: [lworld] RFR: Merge jdk [v4] In-Reply-To: References: Message-ID: > Merge jdk-27+5 David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 119 commits: - Merge branch 'lworld' into lworld_merge_jdk_27_5 - Patch 8374639 - Explicit super call is more correct - Adjust for 8374698 - New initialization warning - Merge tag 'jdk-27+5' into lworld_merge_jdk_27_5 Added tag jdk-27+5 for changeset f6d26c6b - 8354853: Clean up x86 registers after 32-bit x86 removal Reviewed-by: aph, shade, mchevalier - 8373134: C2: Min/Max users of Min/Max uses should be enqueued for GVN Reviewed-by: epeter, bmaillard, dlong - 8371762: Incorrect use of checked_cast in Arguments::process_settings_file Reviewed-by: dholmes, kbarrett - 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages Reviewed-by: asemenyuk - ... and 109 more: https://git.openjdk.org/valhalla/compare/d16ef895...1e34ff10 ------------- Changes: https://git.openjdk.org/valhalla/pull/1930/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1930&range=03 Stats: 38287 lines in 650 files changed: 23952 ins; 8900 del; 5435 mod Patch: https://git.openjdk.org/valhalla/pull/1930.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1930/head:pull/1930 PR: https://git.openjdk.org/valhalla/pull/1930 From dsimms at openjdk.org Thu Jan 22 10:07:42 2026 From: dsimms at openjdk.org (David Simms) Date: Thu, 22 Jan 2026 10:07:42 GMT Subject: [lworld] RFR: Merge jdk [v5] In-Reply-To: References: Message-ID: > Merge jdk-27+5 David Simms has updated the pull request incrementally with one additional commit since the last revision: Adjust testing ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1930/files - new: https://git.openjdk.org/valhalla/pull/1930/files/1e34ff10..75f8656c Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1930&range=04 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1930&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1930.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1930/head:pull/1930 PR: https://git.openjdk.org/valhalla/pull/1930 From rgiulietti at openjdk.org Thu Jan 22 10:47:26 2026 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 22 Jan 2026 10:47:26 GMT Subject: RFR: 8376040: Add prototype "textbook complex" class In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 00:35:05 GMT, Joe Darcy wrote: > First cut at a version of complex numbers using the textbook algorithms for the arithmetic operations. This version is intended for prototyping and _not_ for production use. src/java.base/share/classes/java/lang/ComplexTextbook.java line 195: > 193: } else { > 194: return false; > 195: } Suggestion: return that instanceof ComplexTextbook c && real == c.real && imag == c.imag; src/java.base/share/classes/java/lang/ComplexTextbook.java line 393: > 391: double b = c.imag; > 392: return StrictMath.hypot(a, b); > 393: } Since we have `abs()`, is there a reason for not having `theta()` (or `arg()`, or whatever)? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1942#discussion_r2716308811 PR Review Comment: https://git.openjdk.org/valhalla/pull/1942#discussion_r2716328488 From duke at openjdk.org Thu Jan 22 10:55:35 2026 From: duke at openjdk.org (David Beaumont) Date: Thu, 22 Jan 2026 10:55:35 GMT Subject: [lworld] RFR: 8362252: [lworld] Possible synchronization issue in jdk/internal/jimage/ImageReader.java In-Reply-To: References: <6Tx7jSFas_nHB9RZY4Rsx6O6_P4jFZQvuQIMRVnU-3I=.c886f94e-8a39-491b-aa96-2d717f5a2073@github.com> Message-ID: On Thu, 18 Dec 2025 13:54:26 GMT, David Beaumont wrote: >> Tidying up syncrhonization around shared image. > > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 444: > >> 442: nodes.clear(); >> 443: } >> 444: super.close(); > > I will double check if moving this outside the synchronization of OPEN_FILES is an issue. > The underlying BasicImageReader using a file channel, which is close (with locking) in this close() method. > The vague worry I have is that now the outter OPEN_FILES lock isn't held, we can get a race where the same file has a file channel being closed as a new one is being opened, and I'm not 100% sure I know if that's safe. > Moving this back into the OPEN_FILES lock is possible, but leaves this code doing more work with the locks held, which I'm inclined to avoid if possible. Roger, I'd still want a confirmation of the safety around channel opening/closing on the same underlying file. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1828#discussion_r2716374433 From duke at openjdk.org Thu Jan 22 10:58:26 2026 From: duke at openjdk.org (David Beaumont) Date: Thu, 22 Jan 2026 10:58:26 GMT Subject: [lworld] RFR: 8362252: [lworld] Possible synchronization issue in jdk/internal/jimage/ImageReader.java [v2] In-Reply-To: <6Tx7jSFas_nHB9RZY4Rsx6O6_P4jFZQvuQIMRVnU-3I=.c886f94e-8a39-491b-aa96-2d717f5a2073@github.com> References: <6Tx7jSFas_nHB9RZY4Rsx6O6_P4jFZQvuQIMRVnU-3I=.c886f94e-8a39-491b-aa96-2d717f5a2073@github.com> Message-ID: > Tidying up syncrhonization around shared image. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: tweak error message ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1828/files - new: https://git.openjdk.org/valhalla/pull/1828/files/77d9b300..a535e672 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1828&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1828&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1828.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1828/head:pull/1828 PR: https://git.openjdk.org/valhalla/pull/1828 From rgiulietti at openjdk.org Thu Jan 22 11:02:11 2026 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 22 Jan 2026 11:02:11 GMT Subject: RFR: 8376040: Add prototype "textbook complex" class In-Reply-To: References: Message-ID: <4m46POkRriJ2qn2s93sJXqsQrof-kfdrIIIIZ5OJXXk=.27327830-ccf6-47e9-baa8-9d85eff06111@github.com> On Thu, 22 Jan 2026 00:35:05 GMT, Joe Darcy wrote: > First cut at a version of complex numbers using the textbook algorithms for the arithmetic operations. This version is intended for prototyping and _not_ for production use. src/java.base/share/classes/java/lang/ComplexTextbook.java line 116: > 114: public double imag() { // better as a static method? > 115: return imag; > 116: } Besides being shorter and unambiguous, `re()` and `im()` are the standard names used in maths AFAIK. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1942#discussion_r2716403264 From dsimms at openjdk.org Thu Jan 22 11:14:04 2026 From: dsimms at openjdk.org (David Simms) Date: Thu, 22 Jan 2026 11:14:04 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: <9lWj1FLFE4s0RrOc50nAYnusb5svtWyUbbc19R6rcXU=.43aaec6a-b142-432f-a031-009090cb4a80@github.com> On Mon, 19 Jan 2026 12:26:13 GMT, David Simms wrote: > Merge jdk-27+5 This pull request has now been integrated. Changeset: 420c62ce Author: David Simms URL: https://git.openjdk.org/valhalla/commit/420c62cedd5124ce403c327dfa72d93f3a49db8b Stats: 38288 lines in 650 files changed: 23953 ins; 8900 del; 5435 mod Merge Merge jdk-27+5 ------------- PR: https://git.openjdk.org/valhalla/pull/1930 From mchevalier at openjdk.org Thu Jan 22 12:59:45 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 22 Jan 2026 12:59:45 GMT Subject: [lworld] RFR: 8374006: [lworld] Improve field accessor methods in InlineTypeNode [v2] In-Reply-To: References: Message-ID: > This PR remove from `InlineTypeNode` the methods: > > int field_offset(uint index) const; > uint field_index(int offset) const; > ciType* field_type(uint index) const; > bool field_is_flat(uint index) const; > bool field_is_null_free(uint index) const; > bool field_is_volatile(uint index) const; > int field_null_marker_offset(uint index) const; > > in favor of a single > > ciField* field(uint index) const; > > from which we directly access the various properties we are interested in. > > I've called it `field` as suggested in the original discussion. I've started with `declared_nonstatic_field_at` to be consistent with `ciInstanceKlass` and to avoid ambiguity wrt which kind of fields we are talking about, but this name is rather long... Since we are only talking about the declared fields, and we have no easy getter for `nonstatic_field_at`, then I think it's ok to have a shorter name. Also, in the context of a `InlineTypeNode`, the "non-static" part of the long name seems rather redundant. > > The other question is what we should do with asserts? Methods `field_is_flat`, `field_is_null_free` and `field_is_volatile` had the assert > > assert(!field->is_flat() || field->type()->is_inlinetype(), "must be an inline type"); > > and `field_null_marker_offset` had > > assert(field->is_flat(), "must be an inline type"); > > > I've tried to propagate them to the call-site of such functions, and where it makes a bit of sense, and not subsumed by surrounding `if()` and `assert`. Let me know if it seems unnecessary or not well-placed in some cases. > > Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks fine, but it doesn't seem too risky. > > Thanks, > Marc Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision: Copyright ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1922/files - new: https://git.openjdk.org/valhalla/pull/1922/files/d4ce5d50..4ecd309c Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1922&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1922&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1922.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1922/head:pull/1922 PR: https://git.openjdk.org/valhalla/pull/1922 From mchevalier at openjdk.org Thu Jan 22 13:01:34 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 22 Jan 2026 13:01:34 GMT Subject: [lworld] Integrated: 8374122: [lworld] compiler/c2/cmove/TestScalarConditionalMoveCmpObj.java fails with ir mismatches when preview enabled, post jdk-27+3 In-Reply-To: <51t14OlYhVki-vjsZyxhiY1QGQv_wltoNGeCyzlIuAA=.72589c33-90f7-4dfc-9c13-73b2923c9925@github.com> References: <51t14OlYhVki-vjsZyxhiY1QGQv_wltoNGeCyzlIuAA=.72589c33-90f7-4dfc-9c13-73b2923c9925@github.com> Message-ID: On Tue, 20 Jan 2026 08:49:02 GMT, Marc Chevalier wrote: > The test `TestScalarConditionalMoveCmpObj.java` tests whether code such as > > r[i] = (a[i] != b[i]) ? cc : dd; > > where `a` and `b` are `Object[]` gives a `CMoveNode`. Without Valhalla, we get a simple `If -> If(True|False) -> Region` diamond > > diamond > > that is simplified as a CMove. > > cmove > > Only this simple shape is simplified: > > https://github.com/openjdk/valhalla/blob/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548/src/hotspot/share/opto/loopopts.cpp#L723-L730 > > But with Valhalla, since operands could be value objects, the logic is a lot more complex: are pointer equal? If not, are one of both operands null? If both aren't null, are the operand the same class? If so... All being eventually concluded with a call to `isSubstitutable`. This can't be simplified as a `CMove` (or not easily). > > Even warm up isn't enough: while `a[i]` and `b[i]` are guessed to be exactly `Object`, this still requires a more complex logic than a diamond. Schematically: are pointers equal? If not, is lhs null (that is enough to conclude they are different objects)? If so, trap; if not, is lhs of the speculated (non-value) type? If so, they are different; if not, trap. That is too complicated to make a `CMove`. > > A solution is to make sure we can prove, rather than speculate, that operands are not value objects. Instead of making `a` and `b` arrays of `Object` that can be value types at runtime, we make them arrays of a non-abstract non-value type. This cannot be derived into a value class, so it's fine. And the test pass again! > > I've also done a bit of side fixup in these tests: fixing package name and call `init` on the arrays used for the `int` flavor of the test (method `private static void TestScalarConditionalMoveCmpObj::init(int[] a)` was suspiciously unused). > > > Thanks, > Marc This pull request has now been integrated. Changeset: eec9726b Author: Marc Chevalier URL: https://git.openjdk.org/valhalla/commit/eec9726b509de9bc2e4196c98730037731e96ae8 Stats: 29 lines in 4 files changed: 10 ins; 1 del; 18 mod 8374122: [lworld] compiler/c2/cmove/TestScalarConditionalMoveCmpObj.java fails with ir mismatches when preview enabled, post jdk-27+3 Reviewed-by: qamai, thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1934 From mchevalier at openjdk.org Thu Jan 22 13:01:33 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 22 Jan 2026 13:01:33 GMT Subject: [lworld] RFR: 8374122: [lworld] compiler/c2/cmove/TestScalarConditionalMoveCmpObj.java fails with ir mismatches when preview enabled, post jdk-27+3 In-Reply-To: <51t14OlYhVki-vjsZyxhiY1QGQv_wltoNGeCyzlIuAA=.72589c33-90f7-4dfc-9c13-73b2923c9925@github.com> References: <51t14OlYhVki-vjsZyxhiY1QGQv_wltoNGeCyzlIuAA=.72589c33-90f7-4dfc-9c13-73b2923c9925@github.com> Message-ID: On Tue, 20 Jan 2026 08:49:02 GMT, Marc Chevalier wrote: > The test `TestScalarConditionalMoveCmpObj.java` tests whether code such as > > r[i] = (a[i] != b[i]) ? cc : dd; > > where `a` and `b` are `Object[]` gives a `CMoveNode`. Without Valhalla, we get a simple `If -> If(True|False) -> Region` diamond > > diamond > > that is simplified as a CMove. > > cmove > > Only this simple shape is simplified: > > https://github.com/openjdk/valhalla/blob/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548/src/hotspot/share/opto/loopopts.cpp#L723-L730 > > But with Valhalla, since operands could be value objects, the logic is a lot more complex: are pointer equal? If not, are one of both operands null? If both aren't null, are the operand the same class? If so... All being eventually concluded with a call to `isSubstitutable`. This can't be simplified as a `CMove` (or not easily). > > Even warm up isn't enough: while `a[i]` and `b[i]` are guessed to be exactly `Object`, this still requires a more complex logic than a diamond. Schematically: are pointers equal? If not, is lhs null (that is enough to conclude they are different objects)? If so, trap; if not, is lhs of the speculated (non-value) type? If so, they are different; if not, trap. That is too complicated to make a `CMove`. > > A solution is to make sure we can prove, rather than speculate, that operands are not value objects. Instead of making `a` and `b` arrays of `Object` that can be value types at runtime, we make them arrays of a non-abstract non-value type. This cannot be derived into a value class, so it's fine. And the test pass again! > > I've also done a bit of side fixup in these tests: fixing package name and call `init` on the arrays used for the `int` flavor of the test (method `private static void TestScalarConditionalMoveCmpObj::init(int[] a)` was suspiciously unused). > > > Thanks, > Marc Thanks @merykitty and @TobiHartmann for reviews! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1934#issuecomment-3784264876 From thartmann at openjdk.org Thu Jan 22 13:04:54 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 22 Jan 2026 13:04:54 GMT Subject: [lworld] RFR: 8374006: [lworld] Improve field accessor methods in InlineTypeNode [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 12:59:45 GMT, Marc Chevalier wrote: >> This PR remove from `InlineTypeNode` the methods: >> >> int field_offset(uint index) const; >> uint field_index(int offset) const; >> ciType* field_type(uint index) const; >> bool field_is_flat(uint index) const; >> bool field_is_null_free(uint index) const; >> bool field_is_volatile(uint index) const; >> int field_null_marker_offset(uint index) const; >> >> in favor of a single >> >> ciField* field(uint index) const; >> >> from which we directly access the various properties we are interested in. >> >> I've called it `field` as suggested in the original discussion. I've started with `declared_nonstatic_field_at` to be consistent with `ciInstanceKlass` and to avoid ambiguity wrt which kind of fields we are talking about, but this name is rather long... Since we are only talking about the declared fields, and we have no easy getter for `nonstatic_field_at`, then I think it's ok to have a shorter name. Also, in the context of a `InlineTypeNode`, the "non-static" part of the long name seems rather redundant. >> >> The other question is what we should do with asserts? Methods `field_is_flat`, `field_is_null_free` and `field_is_volatile` had the assert >> >> assert(!field->is_flat() || field->type()->is_inlinetype(), "must be an inline type"); >> >> and `field_null_marker_offset` had >> >> assert(field->is_flat(), "must be an inline type"); >> >> >> I've tried to propagate them to the call-site of such functions, and where it makes a bit of sense, and not subsumed by surrounding `if()` and `assert`. Let me know if it seems unnecessary or not well-placed in some cases. >> >> Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks fine, but it doesn't seem too risky. >> >> Thanks, >> Marc > > Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision: > > Copyright Marked as reviewed by thartmann (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1922#pullrequestreview-3692333438 From mchevalier at openjdk.org Thu Jan 22 13:04:55 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 22 Jan 2026 13:04:55 GMT Subject: [lworld] RFR: 8374006: [lworld] Improve field accessor methods in InlineTypeNode [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 12:59:45 GMT, Marc Chevalier wrote: >> This PR remove from `InlineTypeNode` the methods: >> >> int field_offset(uint index) const; >> uint field_index(int offset) const; >> ciType* field_type(uint index) const; >> bool field_is_flat(uint index) const; >> bool field_is_null_free(uint index) const; >> bool field_is_volatile(uint index) const; >> int field_null_marker_offset(uint index) const; >> >> in favor of a single >> >> ciField* field(uint index) const; >> >> from which we directly access the various properties we are interested in. >> >> I've called it `field` as suggested in the original discussion. I've started with `declared_nonstatic_field_at` to be consistent with `ciInstanceKlass` and to avoid ambiguity wrt which kind of fields we are talking about, but this name is rather long... Since we are only talking about the declared fields, and we have no easy getter for `nonstatic_field_at`, then I think it's ok to have a shorter name. Also, in the context of a `InlineTypeNode`, the "non-static" part of the long name seems rather redundant. >> >> The other question is what we should do with asserts? Methods `field_is_flat`, `field_is_null_free` and `field_is_volatile` had the assert >> >> assert(!field->is_flat() || field->type()->is_inlinetype(), "must be an inline type"); >> >> and `field_null_marker_offset` had >> >> assert(field->is_flat(), "must be an inline type"); >> >> >> I've tried to propagate them to the call-site of such functions, and where it makes a bit of sense, and not subsumed by surrounding `if()` and `assert`. Let me know if it seems unnecessary or not well-placed in some cases. >> >> Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks fine, but it doesn't seem too risky. >> >> Thanks, >> Marc > > Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision: > > Copyright Thanks both for reviews! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1922#issuecomment-3784283863 From mchevalier at openjdk.org Thu Jan 22 13:04:56 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 22 Jan 2026 13:04:56 GMT Subject: [lworld] Integrated: 8374006: [lworld] Improve field accessor methods in InlineTypeNode In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 13:15:54 GMT, Marc Chevalier wrote: > This PR remove from `InlineTypeNode` the methods: > > int field_offset(uint index) const; > uint field_index(int offset) const; > ciType* field_type(uint index) const; > bool field_is_flat(uint index) const; > bool field_is_null_free(uint index) const; > bool field_is_volatile(uint index) const; > int field_null_marker_offset(uint index) const; > > in favor of a single > > ciField* field(uint index) const; > > from which we directly access the various properties we are interested in. > > I've called it `field` as suggested in the original discussion. I've started with `declared_nonstatic_field_at` to be consistent with `ciInstanceKlass` and to avoid ambiguity wrt which kind of fields we are talking about, but this name is rather long... Since we are only talking about the declared fields, and we have no easy getter for `nonstatic_field_at`, then I think it's ok to have a shorter name. Also, in the context of a `InlineTypeNode`, the "non-static" part of the long name seems rather redundant. > > The other question is what we should do with asserts? Methods `field_is_flat`, `field_is_null_free` and `field_is_volatile` had the assert > > assert(!field->is_flat() || field->type()->is_inlinetype(), "must be an inline type"); > > and `field_null_marker_offset` had > > assert(field->is_flat(), "must be an inline type"); > > > I've tried to propagate them to the call-site of such functions, and where it makes a bit of sense, and not subsumed by surrounding `if()` and `assert`. Let me know if it seems unnecessary or not well-placed in some cases. > > Tested with tier1,tier2,tier3,hs-precheckin-comp,hs-comp-stress,valhalla-comp-stress. Looks fine, but it doesn't seem too risky. > > Thanks, > Marc This pull request has now been integrated. Changeset: 3330d016 Author: Marc Chevalier URL: https://git.openjdk.org/valhalla/commit/3330d0164cd9b06585eebb7af05896fdb2f6f5fd Stats: 138 lines in 4 files changed: 36 ins; 39 del; 63 mod 8374006: [lworld] Improve field accessor methods in InlineTypeNode Reviewed-by: qamai, thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1922 From fparain at openjdk.org Thu Jan 22 13:14:01 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 22 Jan 2026 13:14:01 GMT Subject: [lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout In-Reply-To: References: Message-ID: <8dwGgKHP1g94e4sxbdDDWYBnCITc0c7_d-7zmIHdIdM=.8edbad6a-438d-4eb7-9ba6-83142b18f5a2@github.com> On Sat, 10 Jan 2026 11:46:30 GMT, Quan Anh Mai wrote: >> Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case. >> This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic. > > I assume this PR is for flattening of nullable fields at immutable memory (strict final fields) only. But I think the same flattening can be done for null-free field, right? Thanks @merykitty @coleenp for your comments and reviews. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1407#issuecomment-3784346564 From fparain at openjdk.org Thu Jan 22 13:17:29 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 22 Jan 2026 13:17:29 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime [v3] In-Reply-To: References: Message-ID: <6fQIL89Kxz675vHHY5_BsAypDUn8dpFsDzfhcOBtLR4=.66c0ada3-b5e3-458e-b963-344f85613a1a@github.com> On Thu, 22 Jan 2026 09:04:33 GMT, Joel Sikstr?m wrote: >> Hello, >> >> Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). >> >> The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. >> >> I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. >> >> Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. >> >> As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. >> >> Testing: >> * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused MacroAssembler::get_inline_type_field_klass Looks good to me. Thank you for the cleanup. ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1936#pullrequestreview-3692395531 From fparain at openjdk.org Thu Jan 22 13:17:31 2026 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 22 Jan 2026 13:17:31 GMT Subject: [lworld] Integrated: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 20:49:25 GMT, Frederic Parain wrote: > Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case. > This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic. This pull request has now been integrated. Changeset: 0c01b973 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/0c01b9734abc1ff8af4c0f79c85746fcb8debf43 Stats: 760 lines in 22 files changed: 589 ins; 10 del; 161 mod 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout Reviewed-by: coleenp ------------- PR: https://git.openjdk.org/valhalla/pull/1407 From jsikstro at openjdk.org Thu Jan 22 13:31:01 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 22 Jan 2026 13:31:01 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 09:04:33 GMT, Joel Sikstr?m wrote: >> Hello, >> >> Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). >> >> The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. >> >> I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. >> >> Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. >> >> As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. >> >> Testing: >> * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused MacroAssembler::get_inline_type_field_klass Thank you for the reviews @coleen, @Arraying, @fparain! I reran hotspot_valhalla and jdk_valhalla on both aarch64 and x86, and also did some manual testing in lldb to see that the new nullable+marked as null check works as intended. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1936#issuecomment-3784417812 From duke at openjdk.org Thu Jan 22 13:31:01 2026 From: duke at openjdk.org (duke) Date: Thu, 22 Jan 2026 13:31:01 GMT Subject: [lworld] RFR: 8375719: [lworld] Move reads of flat fields entirely to the runtime [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 09:04:33 GMT, Joel Sikstr?m wrote: >> Hello, >> >> Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). >> >> The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. >> >> I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. >> >> Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. >> >> As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. >> >> Testing: >> * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused MacroAssembler::get_inline_type_field_klass @jsikstro Your change (at version 9c6990b395d0dc705951443a28c03b13377f58fa) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1936#issuecomment-3784422237 From jsikstro at openjdk.org Thu Jan 22 13:34:31 2026 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 22 Jan 2026 13:34:31 GMT Subject: [lworld] Integrated: 8375719: [lworld] Move reads of flat fields entirely to the runtime In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 17:56:00 GMT, Joel Sikstr?m wrote: > Hello, > > Today much of the reading of flattened values in the interpreter is implemented both in the platform-specific templateTable_XX.cpp files, and also in the runtime via InterpreterRuntime::read_flat_field. The reason we have both is becuase the interpreterlet implements a fast-path for null-free types, which attempts to allocate the buffered object inside the thread's TLAB, before moving on to copy the src payload to the buffered objected. The copying is done in the VM via a call_VM_leaf call, which notably does not safepoint-poll (nor allow anything that might GC for example). > > The slow-path in the interpreterlet calls into the VM via a call_VM, which notably safepoint-point polls upon exit. The slow-path is taken when 1) the src payload is nullable or 2) the fast-path TLAB allocation fails. > > I propose we redesign the dance around when and how to enter the VM by having the logic of reading a flat field exclusively inside the runtime and thus always entering the VM. This approach allows us to have one canonical way to read flat fields, without having effectively duplicate code in interpreterlets (for all supported platforms) and inside the runtime. A benefit from this is that it becomes easier for porters to port the Valhalla changes to their platform(s) and later on maintain that port, which is a plus. > > Since all objects are NULLABLE in JEP 401 (disregarding F&F interface), all reads of flat fields are already entering the VM via the "slow-path". This means that this change only has a practical effect on null-free/null-restricted fields. I think we should consider if having a fast-path is worth it or not when that time comes, although I anticipate that it doesn't make much difference since the copy is always done in the VM anyway. > > As a small optimization, I've added a check for nullable and marked-as-null before entering the VM. > > Testing: > * hotspot_valhalla, jdk_valhalla and Oracle's tier1-4 on linux-x64-debug and linux-aarch64-debug This pull request has now been integrated. Changeset: b2f45e0f Author: Joel Sikstr?m Committer: Paul H?bner URL: https://git.openjdk.org/valhalla/commit/b2f45e0f857fb32bdc36e7b93346ebc967b74736 Stats: 140 lines in 11 files changed: 11 ins; 113 del; 16 mod 8375719: [lworld] Move reads of flat fields entirely to the runtime Reviewed-by: coleenp, phubner, fparain ------------- PR: https://git.openjdk.org/valhalla/pull/1936 From chagedorn at openjdk.org Thu Jan 22 14:42:47 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 22 Jan 2026 14:42:47 GMT Subject: [lworld] RFR: 8375548: [lworld] C2: Support value class arrays with compiler replay [v2] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 15:26:57 GMT, Tobias Hartmann wrote: >> Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - support value class arrays >> - Merge branch 'lworld' into JDK-8375548 >> - Revert "8375548: [lworld] C2: Compiler replay fails with an assertion due to not loading object array klasses with ArrayProperties::DEFAULT" >> >> This reverts commit 0cdb2549427a02c6d77adbbf29ba5ed1d1d38293. >> - 8375548: [lworld] C2: Compiler replay fails with an assertion due to not loading object array klasses with ArrayProperties::DEFAULT > > src/hotspot/share/ci/ciReplay.cpp line 562: > >> 560: // Create ref or flat array klass. >> 561: k = ObjArrayKlass::cast(k)->klass_with_properties(ArrayKlass::ArrayProperties::DEFAULT, THREAD); >> 562: } > > This will always create the default refined klass. Shouldn't we keep track of which refined klass was actually referenced in the replay file and then create that particular one here? Good point! I reverted this fix and added proper support for value class arrays by dumping the array properties to the replay file. I've also added some more extended testing. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1931#discussion_r2717175099 From chagedorn at openjdk.org Thu Jan 22 14:42:44 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 22 Jan 2026 14:42:44 GMT Subject: [lworld] RFR: 8375548: [lworld] C2: Support value class arrays with compiler replay [v2] In-Reply-To: References: Message-ID: > When using compiler replay with `--enable-preview` with array store/load profiling, we only create `ObjArrayKlass` objects instead of subclass objects (i.e. `RefArrayKlass` or `FlatArrayKlass`). The reason is that we are directly resolving klasses with `SystemDirectory::resolve_or_fail()`: > https://github.com/openjdk/valhalla/blob/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548/src/hotspot/share/ci/ciReplay.cpp#L557 > > This method will call `InstanceKlass::array_klass()` at some point which directly creates an `ObjArrayKlass` object. This let's the replayed compilation fail when trying to speculate on an value class array which expects a subclass of `ObjArrayKlass`. > > The fix I propose is to make sure that we are always creating subclass objects by explicitly using `ArrayProperties::DEFAULT` when parsing an `ArrayKlass` during replay compilation. > > I added a compiler replay test which triggers the same assert as shown in the report. > > Thanks, > Christian Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - support value class arrays - Merge branch 'lworld' into JDK-8375548 - Revert "8375548: [lworld] C2: Compiler replay fails with an assertion due to not loading object array klasses with ArrayProperties::DEFAULT" This reverts commit 0cdb2549427a02c6d77adbbf29ba5ed1d1d38293. - 8375548: [lworld] C2: Compiler replay fails with an assertion due to not loading object array klasses with ArrayProperties::DEFAULT ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1931/files - new: https://git.openjdk.org/valhalla/pull/1931/files/0cdb2549..a7c28865 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1931&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1931&range=00-01 Stats: 1216 lines in 39 files changed: 678 ins; 186 del; 352 mod Patch: https://git.openjdk.org/valhalla/pull/1931.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1931/head:pull/1931 PR: https://git.openjdk.org/valhalla/pull/1931 From chagedorn at openjdk.org Thu Jan 22 14:42:49 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 22 Jan 2026 14:42:49 GMT Subject: [lworld] RFR: 8375548: [lworld] C2: Support value class arrays with compiler replay [v2] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 14:37:08 GMT, Christian Hagedorn wrote: >> When using compiler replay with `--enable-preview` with array store/load profiling, we only create `ObjArrayKlass` objects instead of subclass objects (i.e. `RefArrayKlass` or `FlatArrayKlass`). The reason is that we are directly resolving klasses with `SystemDirectory::resolve_or_fail()`: >> https://github.com/openjdk/valhalla/blob/a4fb7ebd5af316d3e99d10bffb44d5be3aab5548/src/hotspot/share/ci/ciReplay.cpp#L557 >> >> This method will call `InstanceKlass::array_klass()` at some point which directly creates an `ObjArrayKlass` object. This let's the replayed compilation fail when trying to speculate on an value class array which expects a subclass of `ObjArrayKlass`. >> >> The fix I propose is to make sure that we are always creating subclass objects by explicitly using `ArrayProperties::DEFAULT` when parsing an `ArrayKlass` during replay compilation. >> >> I added a compiler replay test which triggers the same assert as shown in the report. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - support value class arrays > - Merge branch 'lworld' into JDK-8375548 > - Revert "8375548: [lworld] C2: Compiler replay fails with an assertion due to not loading object array klasses with ArrayProperties::DEFAULT" > > This reverts commit 0cdb2549427a02c6d77adbbf29ba5ed1d1d38293. > - 8375548: [lworld] C2: Compiler replay fails with an assertion due to not loading object array klasses with ArrayProperties::DEFAULT test/hotspot/jtreg/compiler/ciReplay/TestUnresolvedClasses.java line 2: > 1: /* > 2: * Copyright (c) 2021, 2026, Oracle and/or its affiliates. All rights reserved. I've shared some code with this class which already did some of the things required for the new tests. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1931#discussion_r2717178378 From mcimadamore at openjdk.org Thu Jan 22 15:46:14 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 22 Jan 2026 15:46:14 GMT Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects [v4] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 22:13:13 GMT, Chen Liang wrote: >> Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Comment update Marked as reviewed by mcimadamore (Committer). src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2867: > 2865: @ForceInline > 2866: private boolean compareAndSetFlatValueAsBytes(Object[] array, Object o, long offset, int layout, Class valueType, Object expected, Object x) { > 2867: // We can convert between a value object and a binary value (of suitable size) using array elements. Great! Thanks! ------------- PR Review: https://git.openjdk.org/valhalla/pull/1734#pullrequestreview-3693138969 PR Review Comment: https://git.openjdk.org/valhalla/pull/1734#discussion_r2717467838 From dcubed at openjdk.org Thu Jan 22 16:22:08 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 22 Jan 2026 16:22:08 GMT Subject: [lworld] RFR: 8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod [v4] In-Reply-To: References: <18xNdgxhEUkY__n7lLLnoNvTOHHU76Bph6Kx2Cvr1Ns=.a33db0f6-cfca-41c7-816c-93f0a8f2780c@github.com> Message-ID: On Wed, 21 Jan 2026 15:18:50 GMT, Matias Saavedra Silva wrote: >> The alternate substitutability method relies on an injected Java object "acmp_maps" which is currently not being archived and thus leads to crashes attempting to run with a CDS archive. The issue stems from inline klasses being archived and thus loaded at dumptime while the acmp_maps oops is generated in the class file parser, leading this oop to be absent at runtime. >> >> Additionally, the other injected static field "null_reset" was not being archived either, so both of these fields are properly stored in the archived heap. In the case of CDS/AOT configurations where the heap is not dumped, acmp_maps is regenerated at class loading using a copy of the array stored in metadata. >> >> Tests and APIs are updated to conform to the new output generated by the use of acmp_maps and remove some test cases which target the old substitutability method. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Fixed copyright test/jdk/ProblemList-AotJdk.txt line 47: > 45: java/util/Locale/UseOldISOCodesTest.java 0000000 generic-all > 46: > 47: valhalla/valuetypes/SubstitutabilityTest.java 8374025 generic-all @matias9927 - Why did this PR remove this entry? The bugID for this PR is 8374729, but the entry is for 8374025 and has introduced faillures in Tier5. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1903#discussion_r2717626253 From shade at openjdk.org Thu Jan 22 16:38:00 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 16:38:00 GMT Subject: [lworld] RFR: 8376103: [lworld] Basic Zero support Message-ID: On the way to stabilizing Valhalla for inclusion into mainline, we want to have Zero builds at least buildable and lightly runnable, e.g. for creating their own CDS archives. There is likely to be some bugtail to pass all the tests, this is out of scope for this basic support. We need to pull some fixes from mainline to make this work going smoother. I have also enabled Zero Hotspot build in GHA back to keep it buildable. Additional testing: - [x] Linux x86_64 zero fastdebug, build works - [x] Linux x86_64 zero fastdebug, bootcycle build works ------------- Commit messages: - Build works - Basic Zero build is working Changes: https://git.openjdk.org/valhalla/pull/1943/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1943&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376103 Stats: 48 lines in 7 files changed: 30 ins; 0 del; 18 mod Patch: https://git.openjdk.org/valhalla/pull/1943.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1943/head:pull/1943 PR: https://git.openjdk.org/valhalla/pull/1943 From shade at openjdk.org Thu Jan 22 16:43:16 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 16:43:16 GMT Subject: [lworld] RFR: 8376105: [lworld] Handle "lworld" branch GHA dry-runs Message-ID: <7_ywgjPGb_996mLa_Svo21ibt58b2_e0Szsc0tvtMsc=.7f2ff168-8d9f-4edc-b5ac-daff1575dd75@github.com> Noticed that [JDK-8343546](https://bugs.openjdk.org/browse/JDK-8343546) filter does not work well with "lworld": a full test run is still running when on "lworld" sync in personal fork happens. We just need to filter "lworld" as well. Additional testing: - [ ] GHA ------------- Commit messages: - Fix Changes: https://git.openjdk.org/valhalla/pull/1945/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1945&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376105 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1945.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1945/head:pull/1945 PR: https://git.openjdk.org/valhalla/pull/1945 From shade at openjdk.org Thu Jan 22 16:57:23 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Jan 2026 16:57:23 GMT Subject: [lworld] RFR: 8376103: [lworld] Basic Zero support In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 13:49:59 GMT, Aleksey Shipilev wrote: > On the way to stabilizing Valhalla for inclusion into mainline, we want to have Zero builds at least buildable and lightly runnable, e.g. for creating their own CDS archives. There is likely to be some bugtail to pass all the tests, this is out of scope for this basic support. We need to pull some fixes from mainline to make this work going smoother. > > I have also enabled Zero Hotspot build in GHA back to keep it buildable. > > Additional testing: > - [x] Linux x86_64 zero fastdebug, build works > - [x] Linux x86_64 zero fastdebug, bootcycle build works For reference, Zero enters the new allocation path from here: #8 0x00007ffff6f9e065 in JavaThread::check_for_valid_safepoint_state (this=this at entry=0x7ffff002c570) #9 0x00007ffff7198d1a in MemAllocator::Allocation::check_for_valid_allocation_state (this=) #10 MemAllocator::Allocation::verify_before (this=) at /home/shade/trunks/shipilev-valhalla/src/hotspot/share/gc/shared/memAllocator.cpp:146 #11 0x00007ffff719b2a2 in MemAllocator::Allocation::Allocation (obj_ptr=0x7ffff7b42388, allocator=..., this=0x7ffff7b42310) #12 MemAllocator::allocate (this=this at entry=0x7ffff7b42390) at /home/shade/trunks/shipilev-valhalla/src/hotspot/share/gc/shared/memAllocator.cpp:353 #13 0x00007ffff6f11a4a in CollectedHeap::obj_allocate (__the_thread__=0x7ffff002c570, size=, klass=0x7ffec7065e00, this=) #14 InstanceKlass::allocate_instance (this=this at entry=0x7ffec7065e00, __the_thread__=__the_thread__ at entry=0x7ffff002c570) #15 0x00007ffff6f05c13 in InlineKlass::allocate_instance (this=this at entry=0x7ffec7065e00, __the_thread__=__the_thread__ at entry=0x7ffff002c570) #16 0x00007ffff6f065e4 in InlineKlass::read_payload_from_addr (this=this at entry=0x7ffec7065e00, src=..., offset=offset at entry=384, #17 0x00007ffff697914e in flatArrayOopDesc::obj_at (__the_thread__=0x7ffff002c570, index=, this=) #18 flatArrayOopDesc::obj_at (index=, this=) #19 objArrayOopDesc::obj_at (this=, index=) at /home/shade/trunks/shipilev-valhalla/src/hotspot/share/oops/objArrayOop.inline.hpp:52 #20 0x00007ffff6a0e88e in BytecodeInterpreter::run (istate=) #21 0x00007ffff76e401d in ZeroInterpreter::main_loop (recurse=recurse at entry=0, __the_thread__=__the_thread__ at entry=0x7ffff002c570) #22 0x00007ffff76e4f54 in ZeroInterpreter::normal_entry (method=, UNUSED=, __the_thread__=0x7ffff002c570) #23 0x00007ffff76e407c in ZeroEntry::invoke (__the_thread__=0x7ffff002c570, method=, this= some of the null checks javac generates are redundant and can be removed ------------- Commit messages: - regression tests - remove redundant null checks - Merge branch 'bworld' into remove.redundant.null.checks - remove redundant null checks Changes: https://git.openjdk.org/valhalla/pull/1947/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1947&range=00 Stats: 126 lines in 2 files changed: 111 ins; 0 del; 15 mod Patch: https://git.openjdk.org/valhalla/pull/1947.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1947/head:pull/1947 PR: https://git.openjdk.org/valhalla/pull/1947 From vromero at openjdk.org Thu Jan 22 18:13:39 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 22 Jan 2026 18:13:39 GMT Subject: RFR: Remove redundant null checks [v2] In-Reply-To: References: Message-ID: > some of the null checks javac generates are redundant and can be removed Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: another change ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1947/files - new: https://git.openjdk.org/valhalla/pull/1947/files/4e9c69a3..be0e41e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1947&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1947&range=00-01 Stats: 13 lines in 2 files changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1947.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1947/head:pull/1947 PR: https://git.openjdk.org/valhalla/pull/1947 From vromero at openjdk.org Thu Jan 22 18:17:54 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 22 Jan 2026 18:17:54 GMT Subject: RFR: Remove redundant null checks [v3] In-Reply-To: References: Message-ID: > some of the null checks javac generates are redundant and can be removed Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: minor change ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1947/files - new: https://git.openjdk.org/valhalla/pull/1947/files/be0e41e7..81ffbfb0 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1947&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1947&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1947.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1947/head:pull/1947 PR: https://git.openjdk.org/valhalla/pull/1947 From mcimadamore at openjdk.org Thu Jan 22 18:32:33 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 22 Jan 2026 18:32:33 GMT Subject: RFR: [type-classes] Initial work to enable type-classes mediated operator support Message-ID: <6GCcbpp5vaAWFPXCnxvlGICxl3p7ncKly-5vBew0fz0=.61b7e08f-d2d5-4849-b420-ab189cc3cd9a@github.com> This PR adds experimental support for type-class based operator resolution. This means that it is possible to define classes that "witness" some numerical type class, like so: record Box(int i) { __witness Integral INTEGRAL = ... } Then, we can start using `Box` in e.g. binary operations, like so: Box one = new Box(1); Box two = new Box(1); one + two // three In order to support type-class mediated operator resolution, we needed to add a new kind of operator helper in `Operators`. These new operator helpers (one for unary operators, one for binary operators) wrap some method in one of the standard numeric classes -- for instance, type class `+` is realized through `Numerical::add`, and so forth. There's a new kind of operator symbol, namely `TypeClassOperatorSymbol` which is used to store the type of the operation as well as the method symbol in charge of performing the operation. To resolve an operator, we basically have to prove that a witness for the corresponding class, parameterized by the operand type exists. E.g. in the above, we need to find a witness for `Numerical`. During lowering, we emit such witness, and call the correct operator method on it. Note that support for assignment operators is also provided -- `Lower` already has logic to lower some assignment operators into plain binary operations, so we just leverage that support to translate type-class based assignment ops. ------------- Commit messages: - Minor fixes - Merge branch 'type-classes' into op_overloading - Shuffle comment table in Operators - Cleanup code - Merge branch 'op_overloading' into joe_type_class_hierarchy - Initial push - Appease jcheck some more. - Appease jcheck - 8338529: Initial iteration of numerics modeling interfaces Changes: https://git.openjdk.org/valhalla/pull/1948/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1948&range=00 Stats: 563 lines in 10 files changed: 504 ins; 2 del; 57 mod Patch: https://git.openjdk.org/valhalla/pull/1948.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1948/head:pull/1948 PR: https://git.openjdk.org/valhalla/pull/1948 From liach at openjdk.org Thu Jan 22 18:33:20 2026 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 Jan 2026 18:33:20 GMT Subject: [lworld] RFR: 8376105: [lworld] Handle "lworld" branch GHA dry-runs In-Reply-To: <7_ywgjPGb_996mLa_Svo21ibt58b2_e0Szsc0tvtMsc=.7f2ff168-8d9f-4edc-b5ac-daff1575dd75@github.com> References: <7_ywgjPGb_996mLa_Svo21ibt58b2_e0Szsc0tvtMsc=.7f2ff168-8d9f-4edc-b5ac-daff1575dd75@github.com> Message-ID: <2uSmJZSZEVsQ3hPYMJyhs0yXaQRmqu0IUGXl-7Fj2JY=.421c76e2-6011-414d-bec2-6bb02aea6144@github.com> On Thu, 22 Jan 2026 16:33:24 GMT, Aleksey Shipilev wrote: > Noticed that [JDK-8343546](https://bugs.openjdk.org/browse/JDK-8343546) filter does not work well with "lworld": a full test run is still running when on "lworld" sync in personal fork happens. We just need to filter "lworld" as well. > > Additional testing: > - [ ] GHA Note that there are other branches like `type-classes`, `bworld`, `lworld+vector`, all of which have meaningful development content. I wonder if we should have a better way addressing the cache requirements. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1945#issuecomment-3786033364 From liach at openjdk.org Thu Jan 22 18:48:41 2026 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 Jan 2026 18:48:41 GMT Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects [v5] In-Reply-To: References: Message-ID: > Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'lworld' into fix/unsafe-flat-cas - Comment update - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas - Remove test as permitted - Fixes, VHTMHAV now passes - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas - A test - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas - Attempt to fix garbage cas ------------- Changes: https://git.openjdk.org/valhalla/pull/1734/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1734&range=04 Stats: 81 lines in 2 files changed: 37 ins; 15 del; 29 mod Patch: https://git.openjdk.org/valhalla/pull/1734.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1734/head:pull/1734 PR: https://git.openjdk.org/valhalla/pull/1734 From vromero at openjdk.org Thu Jan 22 19:34:13 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 22 Jan 2026 19:34:13 GMT Subject: RFR: Remove redundant null checks [v4] In-Reply-To: References: Message-ID: <5lBFtUrSA5L_P6f9Nec6KZdkteDYhWB1pTemgwTqScs=.e67ec09c-475b-42fc-89de-b4ebbb643053@github.com> > some of the null checks javac generates are redundant and can be removed Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: adding more tests ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1947/files - new: https://git.openjdk.org/valhalla/pull/1947/files/81ffbfb0..64e65e71 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1947&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1947&range=02-03 Stats: 68 lines in 1 file changed: 26 ins; 20 del; 22 mod Patch: https://git.openjdk.org/valhalla/pull/1947.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1947/head:pull/1947 PR: https://git.openjdk.org/valhalla/pull/1947 From duke at openjdk.org Thu Jan 22 20:36:31 2026 From: duke at openjdk.org (David Beaumont) Date: Thu, 22 Jan 2026 20:36:31 GMT Subject: [lworld] RFR: 8376088: [lworld] value class creation in CompileJavaModules.gmk leaves unnecessary files Message-ID: <-_GVmIAxDHcOH3tubawSxchVnrIIJIxBO21eDMl-hRY=.21b8e350-560f-464d-8309-16a276b5b391@github.com> This is a tidying up of the value class generation and management. It solves JDK-8376088, but also simplifies the two-step process for creating the `META-INF/preview` class files. Short description of changes: 1. Remove JAR file creation (no longer needed, this is the proximal fix for JDK-8376088). 2. Stop adding the "intermediate" target for the compilation to the TARGETS list (rely on the subsequent move). 3. Move directories directly from the output directory to the preview directory (does not move marker files). 4. Make the marker file appear alongside other markers for the module compilation. 5. Rename marker file to be consistent with other sibling marker files. The marker files in `build/linux-x64/jdk/modules/java.base/` are now: _the.java.base_batch _the.java.base_batch.cmdline _the.java.base_batch.filelist _the.java.base_batch.log _the.java.base_batch.modfiles _the.java.base_batch.modfiles.fixed _the.java.base.config_vardeps _the.java.base_internalapi _the.java.base-javacserver.conf _the.java.base_pubapi _the.java.base.valueclasses <-- moved/renamed mark file _the.java.base.vardeps I've added a couple of notes where there could be choices about the implementation. ------------- Commit messages: - Tidying makefile related to value classes Changes: https://git.openjdk.org/valhalla/pull/1949/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1949&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376088 Stats: 40 lines in 1 file changed: 9 ins; 20 del; 11 mod Patch: https://git.openjdk.org/valhalla/pull/1949.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1949/head:pull/1949 PR: https://git.openjdk.org/valhalla/pull/1949 From duke at openjdk.org Thu Jan 22 20:39:17 2026 From: duke at openjdk.org (David Beaumont) Date: Thu, 22 Jan 2026 20:39:17 GMT Subject: [lworld] RFR: 8376088: [lworld] value class creation in CompileJavaModules.gmk leaves unnecessary files In-Reply-To: <-_GVmIAxDHcOH3tubawSxchVnrIIJIxBO21eDMl-hRY=.21b8e350-560f-464d-8309-16a276b5b391@github.com> References: <-_GVmIAxDHcOH3tubawSxchVnrIIJIxBO21eDMl-hRY=.21b8e350-560f-464d-8309-16a276b5b391@github.com> Message-ID: <8BmqCZdc1gHdguvhzk11mrJWUiajKys7cBZoRvmndFY=.54a6373b-1dc1-4d43-9c18-8f25712aa75e@github.com> On Thu, 22 Jan 2026 20:31:23 GMT, David Beaumont wrote: > This is a tidying up of the value class generation and management. > It solves JDK-8376088, but also simplifies the two-step process for creating the `META-INF/preview` class files. > > Short description of changes: > 1. Remove JAR file creation (no longer needed, this is the proximal fix for JDK-8376088). > 2. Stop adding the "intermediate" target for the compilation to the TARGETS list (rely on the subsequent move). > 3. Move directories directly from the output directory to the preview directory (does not move marker files). > 4. Make the marker file appear alongside other markers for the module compilation. > 5. Rename marker file to be consistent with other sibling marker files. > > The marker files in `build/linux-x64/jdk/modules/java.base/` are now: > > > _the.java.base_batch > _the.java.base_batch.cmdline > _the.java.base_batch.filelist > _the.java.base_batch.log > _the.java.base_batch.modfiles > _the.java.base_batch.modfiles.fixed > _the.java.base.config_vardeps > _the.java.base_internalapi > _the.java.base-javacserver.conf > _the.java.base_pubapi > _the.java.base.valueclasses <-- moved/renamed mark file > _the.java.base.vardeps > > > I've added a couple of notes where there could be choices about the implementation. make/CompileJavaModules.gmk line 174: > 172: )) > 173: > 174: # Don't add '$($(MODULE)-$(VALUECLASSES_STR))' to TARGETS (it's transient). I think this is a technically correct statement, but I'm happy to clarify it. The intent is to "hide" the intermediate state and just see this as the valueclasses target doing one action. make/CompileJavaModules.gmk line 182: > 180: $(MODULE_OUTPUTDIR)/_the.java.base.valueclasses: $($(MODULE)-$(VALUECLASSES_STR)) > 181: $(MKDIR) -p $(@D)/META-INF/preview > 182: $(MV) $(TEMP_OUTPUTDIR)/$(MODULE)/*/ $(@D)/META-INF/preview This could also be a `$(CP) -r` (with slight adjustment), but I'd want to still avoid copying the marker files. The root module directory shouldn't contain any files we care about, so using '*/' suffix just copies directories and ignores marker files. I *think* that because TARGETS doesn't have the compilation marker added to it, once the compilation marker files are created, they only serve to support other targets that depend upon them, which is only the valueclasses target. If however, the Java compilation macro does have side effects visible to the rest of the build, this might not be a safe assumption. Please let me know if you think I've made an error here, and what your preferences are. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1949#discussion_r2718535383 PR Review Comment: https://git.openjdk.org/valhalla/pull/1949#discussion_r2718546548 From duke at openjdk.org Thu Jan 22 20:48:26 2026 From: duke at openjdk.org (David Beaumont) Date: Thu, 22 Jan 2026 20:48:26 GMT Subject: [lworld] RFR: 8376088: [lworld] value class creation in CompileJavaModules.gmk leaves unnecessary files [v2] In-Reply-To: <-_GVmIAxDHcOH3tubawSxchVnrIIJIxBO21eDMl-hRY=.21b8e350-560f-464d-8309-16a276b5b391@github.com> References: <-_GVmIAxDHcOH3tubawSxchVnrIIJIxBO21eDMl-hRY=.21b8e350-560f-464d-8309-16a276b5b391@github.com> Message-ID: > This is a tidying up of the value class generation and management. > It solves JDK-8376088, but also simplifies the two-step process for creating the `META-INF/preview` class files. > > Short description of changes: > 1. Remove JAR file creation (no longer needed, this is the proximal fix for JDK-8376088). > 2. Stop adding the "intermediate" target for the compilation to the TARGETS list (rely on the subsequent move). > 3. Move directories directly from the output directory to the preview directory (does not move marker files). > 4. Make the marker file appear alongside other markers for the module compilation. > 5. Rename marker file to be consistent with other sibling marker files. > > The marker files in `build/linux-x64/jdk/modules/java.base/` are now: > > > _the.java.base_batch > _the.java.base_batch.cmdline > _the.java.base_batch.filelist > _the.java.base_batch.log > _the.java.base_batch.modfiles > _the.java.base_batch.modfiles.fixed > _the.java.base.config_vardeps > _the.java.base_internalapi > _the.java.base-javacserver.conf > _the.java.base_pubapi > _the.java.base.valueclasses <-- moved/renamed mark file > _the.java.base.vardeps > > > I've added a couple of notes where there could be choices about the implementation. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Remove problem list entry ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1949/files - new: https://git.openjdk.org/valhalla/pull/1949/files/3be51b56..000282db Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1949&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1949&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1949.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1949/head:pull/1949 PR: https://git.openjdk.org/valhalla/pull/1949 From erikj at openjdk.org Thu Jan 22 21:01:48 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 22 Jan 2026 21:01:48 GMT Subject: [lworld] RFR: 8376088: [lworld] value class creation in CompileJavaModules.gmk leaves unnecessary files [v2] In-Reply-To: <8BmqCZdc1gHdguvhzk11mrJWUiajKys7cBZoRvmndFY=.54a6373b-1dc1-4d43-9c18-8f25712aa75e@github.com> References: <-_GVmIAxDHcOH3tubawSxchVnrIIJIxBO21eDMl-hRY=.21b8e350-560f-464d-8309-16a276b5b391@github.com> <8BmqCZdc1gHdguvhzk11mrJWUiajKys7cBZoRvmndFY=.54a6373b-1dc1-4d43-9c18-8f25712aa75e@github.com> Message-ID: On Thu, 22 Jan 2026 20:36:33 GMT, David Beaumont wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove problem list entry > > make/CompileJavaModules.gmk line 182: > >> 180: $(MODULE_OUTPUTDIR)/_the.java.base.valueclasses: $($(MODULE)-$(VALUECLASSES_STR)) >> 181: $(MKDIR) -p $(@D)/META-INF/preview >> 182: $(MV) $(TEMP_OUTPUTDIR)/$(MODULE)/*/ $(@D)/META-INF/preview > > This could also be a `$(CP) -r` (with slight adjustment), but I'd want to still avoid copying the marker files. > The root module directory shouldn't contain any files we care about, so using '*/' suffix just copies directories and ignores marker files. > > I *think* that because TARGETS doesn't have the compilation marker added to it, once the compilation marker files are created, they only serve to support other targets that depend upon them, which is only the valueclasses target. > > If however, the Java compilation macro does have side effects visible to the rest of the build, this might not be a safe assumption. Please let me know if you think I've made an error here, and what your preferences are. By moving the class files instead of copying them, you are disabling any incremental build logic provided by javac and the plugins we use when compiling the value classes. There are most likely other potential issues that I'm not thinking about right now. In my experience maintaining these makefiles since 2012, moving files, or deleting "temporary" files in the build output almost always leads to problems with incremental or interrupted builds. Please leave them be and copy them to where they need to go. Excluding the marker files is certainly a good idea. If this was a review for mainline, I would not accept moving the files, but since this is a project repo, I can assume this is a work in progress and you are free to experiment any which way you like. The final review happens when it goes into mainline. Yes, it's correct to not add `$($(MODULE)-$(VALUECLASSES_STR))` to `TARGETS` since it's an intermediate build step. We only need to add targets to `TARGETS` when they are end targets for the makefile. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1949#discussion_r2718590410 From duke at openjdk.org Thu Jan 22 21:01:50 2026 From: duke at openjdk.org (David Beaumont) Date: Thu, 22 Jan 2026 21:01:50 GMT Subject: [lworld] RFR: 8376088: [lworld] value class creation in CompileJavaModules.gmk leaves unnecessary files [v2] In-Reply-To: References: <-_GVmIAxDHcOH3tubawSxchVnrIIJIxBO21eDMl-hRY=.21b8e350-560f-464d-8309-16a276b5b391@github.com> Message-ID: <7YWE5bJlW-XAubBjp5qAu-SmyrydZYMzinBO289nqbY=.58851a6e-f0a5-489b-97c1-8f5b665b055c@github.com> On Thu, 22 Jan 2026 20:53:09 GMT, Erik Joelsson wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove problem list entry > > make/CompileJavaModules.gmk line 185: > >> 183: $(TOUCH) $@ >> 184: >> 185: TARGETS += $(MODULE_OUTPUTDIR)/_the.java.base.valueclasses > > Maybe not call this `java.base` since this code isn't explicitly specific to the java.base module. *doh* - that needs to use `$(MODULE)` - thanks. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1949#discussion_r2718610564 From duke at openjdk.org Thu Jan 22 21:01:48 2026 From: duke at openjdk.org (David Beaumont) Date: Thu, 22 Jan 2026 21:01:48 GMT Subject: [lworld] RFR: 8376088: [lworld] value class creation in CompileJavaModules.gmk leaves unnecessary files [v2] In-Reply-To: References: <-_GVmIAxDHcOH3tubawSxchVnrIIJIxBO21eDMl-hRY=.21b8e350-560f-464d-8309-16a276b5b391@github.com> <8BmqCZdc1gHdguvhzk11mrJWUiajKys7cBZoRvmndFY=.54a6373b-1dc1-4d43-9c18-8f25712aa75e@github.com> Message-ID: <11KBbAwPVbhSTZOdwwJ77Jm6ZBn3LuhKWALncAwo6GQ=.3b01e126-abb8-4a9f-9631-ef2ac3be8cdf@github.com> On Thu, 22 Jan 2026 20:51:53 GMT, Erik Joelsson wrote: >> make/CompileJavaModules.gmk line 182: >> >>> 180: $(MODULE_OUTPUTDIR)/_the.java.base.valueclasses: $($(MODULE)-$(VALUECLASSES_STR)) >>> 181: $(MKDIR) -p $(@D)/META-INF/preview >>> 182: $(MV) $(TEMP_OUTPUTDIR)/$(MODULE)/*/ $(@D)/META-INF/preview >> >> This could also be a `$(CP) -r` (with slight adjustment), but I'd want to still avoid copying the marker files. >> The root module directory shouldn't contain any files we care about, so using '*/' suffix just copies directories and ignores marker files. >> >> I *think* that because TARGETS doesn't have the compilation marker added to it, once the compilation marker files are created, they only serve to support other targets that depend upon them, which is only the valueclasses target. >> >> If however, the Java compilation macro does have side effects visible to the rest of the build, this might not be a safe assumption. Please let me know if you think I've made an error here, and what your preferences are. > > By moving the class files instead of copying them, you are disabling any incremental build logic provided by javac and the plugins we use when compiling the value classes. There are most likely other potential issues that I'm not thinking about right now. In my experience maintaining these makefiles since 2012, moving files, or deleting "temporary" files in the build output almost always leads to problems with incremental or interrupted builds. Please leave them be and copy them to where they need to go. Excluding the marker files is certainly a good idea. If this was a review for mainline, I would not accept moving the files, but since this is a project repo, I can assume this is a work in progress and you are free to experiment any which way you like. The final review happens when it goes into mainline. > > Yes, it's correct to not add `$($(MODULE)-$(VALUECLASSES_STR))` to `TARGETS` since it's an intermediate build step. We only need to add targets to `TARGETS` when they are end targets for the makefile. Okay, cool, I'll switch it to a copy and leave the intermediate marker NOT added to TARGETS. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1949#discussion_r2718608599 From erikj at openjdk.org Thu Jan 22 21:01:50 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 22 Jan 2026 21:01:50 GMT Subject: [lworld] RFR: 8376088: [lworld] value class creation in CompileJavaModules.gmk leaves unnecessary files [v2] In-Reply-To: References: <-_GVmIAxDHcOH3tubawSxchVnrIIJIxBO21eDMl-hRY=.21b8e350-560f-464d-8309-16a276b5b391@github.com> Message-ID: On Thu, 22 Jan 2026 20:48:26 GMT, David Beaumont wrote: >> This is a tidying up of the value class generation and management. >> It solves JDK-8376088, but also simplifies the two-step process for creating the `META-INF/preview` class files. >> >> Short description of changes: >> 1. Remove JAR file creation (no longer needed, this is the proximal fix for JDK-8376088). >> 2. Stop adding the "intermediate" target for the compilation to the TARGETS list (rely on the subsequent move). >> 3. Move directories directly from the output directory to the preview directory (does not move marker files). >> 4. Make the marker file appear alongside other markers for the module compilation. >> 5. Rename marker file to be consistent with other sibling marker files. >> >> The marker files in `build/linux-x64/jdk/modules/java.base/` are now: >> >> >> _the.java.base_batch >> _the.java.base_batch.cmdline >> _the.java.base_batch.filelist >> _the.java.base_batch.log >> _the.java.base_batch.modfiles >> _the.java.base_batch.modfiles.fixed >> _the.java.base.config_vardeps >> _the.java.base_internalapi >> _the.java.base-javacserver.conf >> _the.java.base_pubapi >> _the.java.base.valueclasses <-- moved/renamed mark file >> _the.java.base.vardeps >> >> >> I've added a couple of notes where there could be choices about the implementation. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Remove problem list entry make/CompileJavaModules.gmk line 185: > 183: $(TOUCH) $@ > 184: > 185: TARGETS += $(MODULE_OUTPUTDIR)/_the.java.base.valueclasses Maybe not call this `java.base` since this code isn't explicitly specific to the java.base module. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1949#discussion_r2718594856 From vromero at openjdk.org Thu Jan 22 21:07:52 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 22 Jan 2026 21:07:52 GMT Subject: [lworld] RFR: 8373916: [lworld] TypeName.this.FieldName should be restricted in early construction context Message-ID: According to spec bugs: JDK-8373719 and JDK-8373721: In JLS 6.5.6.1, references to fields are subject to a handful of restrictions if they refer to instance fields. In 15.8 and 15.11, 'this.x' and 'super.x' are intended to be viewed as instance field references, and subject to the same restrictions. So the following code should fail to compile: class Test { static final boolean check = true; Test(int a) { boolean b = Test.this.check; //compilation error expected here this(); } } However, javac is currently accepting it ------------- Commit messages: - 8373916: [lworld] TypeName.this.FieldName should be restricted in early construction context Changes: https://git.openjdk.org/valhalla/pull/1899/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1899&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373916 Stats: 36 lines in 6 files changed: 33 ins; 0 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1899.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1899/head:pull/1899 PR: https://git.openjdk.org/valhalla/pull/1899 From duke at openjdk.org Thu Jan 22 21:12:09 2026 From: duke at openjdk.org (David Beaumont) Date: Thu, 22 Jan 2026 21:12:09 GMT Subject: [lworld] RFR: 8376088: [lworld] value class creation in CompileJavaModules.gmk leaves unnecessary files [v3] In-Reply-To: <-_GVmIAxDHcOH3tubawSxchVnrIIJIxBO21eDMl-hRY=.21b8e350-560f-464d-8309-16a276b5b391@github.com> References: <-_GVmIAxDHcOH3tubawSxchVnrIIJIxBO21eDMl-hRY=.21b8e350-560f-464d-8309-16a276b5b391@github.com> Message-ID: > This is a tidying up of the value class generation and management. > It solves JDK-8376088, but also simplifies the two-step process for creating the `META-INF/preview` class files. > > Short description of changes: > 1. Remove JAR file creation (no longer needed, this is the proximal fix for JDK-8376088). > 2. Stop adding the "intermediate" target for the compilation to the TARGETS list (rely on the subsequent move). > 3. Move directories directly from the output directory to the preview directory (does not move marker files). > 4. Make the marker file appear alongside other markers for the module compilation. > 5. Rename marker file to be consistent with other sibling marker files. > > The marker files in `build/linux-x64/jdk/modules/java.base/` are now: > > > _the.java.base_batch > _the.java.base_batch.cmdline > _the.java.base_batch.filelist > _the.java.base_batch.log > _the.java.base_batch.modfiles > _the.java.base_batch.modfiles.fixed > _the.java.base.config_vardeps > _the.java.base_internalapi > _the.java.base-javacserver.conf > _the.java.base_pubapi > _the.java.base.valueclasses <-- moved/renamed mark file > _the.java.base.vardeps > > > I've added a couple of notes where there could be choices about the implementation. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Change move to a copy ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1949/files - new: https://git.openjdk.org/valhalla/pull/1949/files/000282db..6fc34561 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1949&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1949&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1949.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1949/head:pull/1949 PR: https://git.openjdk.org/valhalla/pull/1949