From liach at openjdk.org Thu May 1 04:43:48 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 04:43:48 GMT Subject: [lworld] RFR: 8355227: [lworld] Clarify preview API status for some valhalla APIs [v2] In-Reply-To: References: Message-ID: > Per [JEP 12](https://openjdk.org/jeps/12): > >> In order for frameworks to deliver early support for a preview language feature, frameworks should utilize the reflective preview APIs that are co-developed with it. This will allow frameworks to keep up when programs are written to use the permanent version of the language feature. > > According to these rules, the `Objects` methods and the `IdentityException` class themselves must be reflective preview APIs: programs compiled without preview feature dependencies that are running with preview features enabled should be able to access these APIs, as at run-time, they may receive value objects and `IdentityException` thrown by the JVM. > > The only remaining essential preview APIs are the constructors of `IdentityException`: non-preview programs have no reason to construct them. > > In addition, fixed a few JEP feature reference: notably, add reference to [Strict Fields JEP](https://openjdk.org/jeps/8350458). > > Also, made ClassFile API new models reflective preview APIs - class file processors wish to process structures from preview class files even if the current runtime is not in preview. This is already happening to javac and javap. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'lworld' into fix/preview-annos - 8355227: [lworld] Clarify preview API status for some vallhalla APIs ------------- Changes: https://git.openjdk.org/valhalla/pull/1439/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1439&range=01 Stats: 19 lines in 6 files changed: 12 ins; 0 del; 7 mod Patch: https://git.openjdk.org/valhalla/pull/1439.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1439/head:pull/1439 PR: https://git.openjdk.org/valhalla/pull/1439 From qamai at openjdk.org Thu May 1 05:15:35 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 1 May 2025 05:15:35 GMT Subject: [lworld] RFR: 8354408: [lworld] compiler/types/TestSubTypeCheckUniqueSubclass.java IR mismatches post jdk-25+16 merge Message-ID: Hi, The issue here is that `IRNode::macroNodes` takes a full line regex, not only the node name part like `IRNode::beforeMatchingNameRegex`. As a result, we should compute the full regex for `SUBTYPE_CHECK`. Please kindly review, thanks a lot. ------------- Commit messages: - Fix IRNode.SUBTYPE_CHECK Changes: https://git.openjdk.org/valhalla/pull/1448/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1448&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354408 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1448.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1448/head:pull/1448 PR: https://git.openjdk.org/valhalla/pull/1448 From matsaave at openjdk.org Thu May 1 17:46:42 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 1 May 2025 17:46:42 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 Message-ID: Updates to javac prevent it from creating classes with improper uses of strict fields. Additionally, non-final strict fields are now allowed so `StrictFinalInstanceFieldsTest.java` needs to updated with new test cases. This patch adds new cases for final and non-final stricts as well as negative test cases using asmtools that check improper use of strict fields and early larval stack map frames. During testing, it was revealed that the new verify errors added in [JDK-8354694](https://bugs.openjdk.org/browse/JDK-8354694) do not work properly so a fix is included in this patch. Note: This cannot be integrated until jtreg is updated with a recent build of asmtools which can handle strict fields and can generate early_larval frames. ------------- Commit messages: - Remove old test - Added copyright - Added more positive test cases - [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 Changes: https://git.openjdk.org/valhalla/pull/1449/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1449&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352068 Stats: 1843 lines in 10 files changed: 1581 ins; 262 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1449.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1449/head:pull/1449 PR: https://git.openjdk.org/valhalla/pull/1449 From fparain at openjdk.org Fri May 2 14:52:32 2025 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 2 May 2025 14:52:32 GMT Subject: [lworld] Integrated: 8356088: [lworld] dead methods in array code Message-ID: Removal of dead code. ------------- Commit messages: - Remove dead methods Changes: https://git.openjdk.org/valhalla/pull/1450/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1450&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356088 Stats: 51 lines in 3 files changed: 0 ins; 51 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1450.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1450/head:pull/1450 PR: https://git.openjdk.org/valhalla/pull/1450 From fparain at openjdk.org Fri May 2 14:52:32 2025 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 2 May 2025 14:52:32 GMT Subject: [lworld] Integrated: 8356088: [lworld] dead methods in array code In-Reply-To: References: Message-ID: On Fri, 2 May 2025 14:46:11 GMT, Frederic Parain wrote: > Removal of dead code. This pull request has now been integrated. Changeset: 9ad77893 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/9ad77893e305af5bdf9965e19707290f0a9be7ea Stats: 51 lines in 3 files changed: 0 ins; 51 del; 0 mod 8356088: [lworld] dead methods in array code ------------- PR: https://git.openjdk.org/valhalla/pull/1450 From chagedorn at openjdk.org Mon May 5 08:02:03 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 5 May 2025 08:02:03 GMT Subject: [lworld] RFR: 8354408: [lworld] compiler/types/TestSubTypeCheckUniqueSubclass.java IR mismatches post jdk-25+16 merge In-Reply-To: References: Message-ID: On Thu, 1 May 2025 05:10:33 GMT, Quan Anh Mai wrote: > Hi, > > The issue here is that `IRNode::macroNodes` takes a full line regex, not only the node name part like `IRNode::beforeMatchingNameRegex`. As a result, we should compute the full regex for `SUBTYPE_CHECK`. > > Please kindly review, thanks a lot. test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 1974: > 1972: static { > 1973: String regex = START + "SubTypeCheck" + MID + END; > 1974: macroNodes(SUBTYPE_CHECK, regex); Could you also directly call `beforeMatchingNameRegex()` as we do in mainline? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1448#discussion_r2073005121 From qamai at openjdk.org Mon May 5 08:32:00 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 5 May 2025 08:32:00 GMT Subject: [lworld] RFR: 8354408: [lworld] compiler/types/TestSubTypeCheckUniqueSubclass.java IR mismatches post jdk-25+16 merge In-Reply-To: References: Message-ID: On Mon, 5 May 2025 07:59:05 GMT, Christian Hagedorn wrote: >> Hi, >> >> The issue here is that `IRNode::macroNodes` takes a full line regex, not only the node name part like `IRNode::beforeMatchingNameRegex`. As a result, we should compute the full regex for `SUBTYPE_CHECK`. >> >> Please kindly review, thanks a lot. > > test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 1974: > >> 1972: static { >> 1973: String regex = START + "SubTypeCheck" + MID + END; >> 1974: macroNodes(SUBTYPE_CHECK, regex); > > Could you also directly call `beforeMatchingNameRegex()` as we do in mainline? I believe you changed it to `macroNodes` here :) https://github.com/openjdk/valhalla/pull/1296 ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1448#discussion_r2073043237 From chagedorn at openjdk.org Mon May 5 08:53:56 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 5 May 2025 08:53:56 GMT Subject: [lworld] RFR: 8354408: [lworld] compiler/types/TestSubTypeCheckUniqueSubclass.java IR mismatches post jdk-25+16 merge In-Reply-To: References: Message-ID: <7oGE3VCdyAqDEJ_nolVWoOMtlVMYJstbhi8InJGwjxk=.089a747b-26cb-4305-9ab7-2a988b17567d@github.com> On Thu, 1 May 2025 05:10:33 GMT, Quan Anh Mai wrote: > Hi, > > The issue here is that `IRNode::macroNodes` takes a full line regex, not only the node name part like `IRNode::beforeMatchingNameRegex`. As a result, we should compute the full regex for `SUBTYPE_CHECK`. > > Please kindly review, thanks a lot. Marked as reviewed by chagedorn (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1448#pullrequestreview-2814187903 From chagedorn at openjdk.org Mon May 5 08:53:57 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 5 May 2025 08:53:57 GMT Subject: [lworld] RFR: 8354408: [lworld] compiler/types/TestSubTypeCheckUniqueSubclass.java IR mismatches post jdk-25+16 merge In-Reply-To: References: Message-ID: On Mon, 5 May 2025 08:29:26 GMT, Quan Anh Mai wrote: >> test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 1974: >> >>> 1972: static { >>> 1973: String regex = START + "SubTypeCheck" + MID + END; >>> 1974: macroNodes(SUBTYPE_CHECK, regex); >> >> Could you also directly call `beforeMatchingNameRegex()` as we do in mainline? > > I believe you changed it to `macroNodes` here :) > > https://github.com/openjdk/valhalla/pull/1296 Okay, I guess it makes sense to treat it as macro node here to limit the compile phases. We should probably also change that in mainline but probably not worth to do it separately in mainline. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1448#discussion_r2073077311 From qamai at openjdk.org Mon May 5 10:44:00 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 5 May 2025 10:44:00 GMT Subject: [lworld] RFR: 8354408: [lworld] compiler/types/TestSubTypeCheckUniqueSubclass.java IR mismatches post jdk-25+16 merge In-Reply-To: References: Message-ID: On Thu, 1 May 2025 05:10:33 GMT, Quan Anh Mai wrote: > Hi, > > The issue here is that `IRNode::macroNodes` takes a full line regex, not only the node name part like `IRNode::beforeMatchingNameRegex`. As a result, we should compute the full regex for `SUBTYPE_CHECK`. > > Please kindly review, thanks a lot. Thanks a lot for your review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1448#issuecomment-2850590521 From duke at openjdk.org Mon May 5 10:44:00 2025 From: duke at openjdk.org (duke) Date: Mon, 5 May 2025 10:44:00 GMT Subject: [lworld] RFR: 8354408: [lworld] compiler/types/TestSubTypeCheckUniqueSubclass.java IR mismatches post jdk-25+16 merge In-Reply-To: References: Message-ID: On Thu, 1 May 2025 05:10:33 GMT, Quan Anh Mai wrote: > Hi, > > The issue here is that `IRNode::macroNodes` takes a full line regex, not only the node name part like `IRNode::beforeMatchingNameRegex`. As a result, we should compute the full regex for `SUBTYPE_CHECK`. > > Please kindly review, thanks a lot. @merykitty Your change (at version ccafe5131e67706944ba8b4d93864c3b4f358b48) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1448#issuecomment-2850593526 From thartmann at openjdk.org Mon May 5 11:41:59 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 5 May 2025 11:41:59 GMT Subject: [lworld] RFR: 8354408: [lworld] compiler/types/TestSubTypeCheckUniqueSubclass.java IR mismatches post jdk-25+16 merge In-Reply-To: References: Message-ID: On Thu, 1 May 2025 05:10:33 GMT, Quan Anh Mai wrote: > Hi, > > The issue here is that `IRNode::macroNodes` takes a full line regex, not only the node name part like `IRNode::beforeMatchingNameRegex`. As a result, we should compute the full regex for `SUBTYPE_CHECK`. > > Please kindly review, thanks a lot. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1448#pullrequestreview-2814527823 From qamai at openjdk.org Mon May 5 11:41:59 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 5 May 2025 11:41:59 GMT Subject: [lworld] Integrated: 8354408: [lworld] compiler/types/TestSubTypeCheckUniqueSubclass.java IR mismatches post jdk-25+16 merge In-Reply-To: References: Message-ID: <9wZC6u854-SX7-iLn_0MzlxWgW-cR8NxsQn0oFVDBwQ=.5d5e0002-f9ab-45a1-9cb9-9b0b8bc0f5b0@github.com> On Thu, 1 May 2025 05:10:33 GMT, Quan Anh Mai wrote: > Hi, > > The issue here is that `IRNode::macroNodes` takes a full line regex, not only the node name part like `IRNode::beforeMatchingNameRegex`. As a result, we should compute the full regex for `SUBTYPE_CHECK`. > > Please kindly review, thanks a lot. This pull request has now been integrated. Changeset: 1163cc65 Author: Quan Anh Mai Committer: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/1163cc6556e9e424a436d19f5580e02a8c01b44b Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod 8354408: [lworld] compiler/types/TestSubTypeCheckUniqueSubclass.java IR mismatches post jdk-25+16 merge Reviewed-by: chagedorn, thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1448 From thartmann at openjdk.org Mon May 5 12:04:53 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 5 May 2025 12:04:53 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v4] In-Reply-To: <6MMbO4fn1i6swKVOezub46YyiWLW29JWIvntcqSg-4s=.a5f46c5e-7e66-4125-8b52-4d701182ec6b@github.com> References: <6MMbO4fn1i6swKVOezub46YyiWLW29JWIvntcqSg-4s=.a5f46c5e-7e66-4125-8b52-4d701182ec6b@github.com> Message-ID: <0DhP9Q4w2jjUP-uhgTLrCqxlVDFKdP7wm7_-Skfz21I=.1154aeb0-cd70-4dae-9b36-9070be8b642b@github.com> On Tue, 29 Apr 2025 20:12:07 GMT, Quan Anh Mai wrote: >> Hi >> >> The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects. >> >> It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE. >> >> An example regarding the issue with tracking the identity of a larval InlineTypeNode: >> >> Consider this pseudobytecode sequence: >> >> new MyValue; >> dup; >> loop; >> invokespecial MyValue::; >> areturn; >> >> There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object. >> >> 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: > > fast path for non intrinsics Thanks for quickly fixing these issues. I ran another round of testing and there's only one issue left: compiler/arraycopy/TestEliminatedArrayCopyPhi.java -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/workspace/open/src/hotspot/share/opto/phaseX.cpp:1821), pid=1040062, tid=1040080 # Error: assert(_worklist.size() == 0) failed # # JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-04-30-0702055.tobias.hartmann.valhalla2) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-04-30-0702055.tobias.hartmann.valhalla2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x17de609] PhaseCCP::PhaseCCP(PhaseIterGVN*)+0x169 Current CompileTask: C2:455 160 b 4 compiler.arraycopy.TestEliminatedArrayCopyPhi::test (27 bytes) Stack: [0x00007fadf8385000,0x00007fadf8485000], sp=0x00007fadf8480270, free space=1004k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x17de609] PhaseCCP::PhaseCCP(PhaseIterGVN*)+0x169 (phaseX.cpp:1821) V [libjvm.so+0xb2573a] Compile::Optimize()+0xa0a (compile.cpp:2950) V [libjvm.so+0xb28b7b] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1feb (compile.cpp:874) V [libjvm.so+0x94e98d] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x46d (c2compiler.cpp:142) V [libjvm.so+0xb37882] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb22 (compileBroker.cpp:2307) V [libjvm.so+0xb38888] CompileBroker::compiler_thread_loop()+0x588 (compileBroker.cpp:1951) V [libjvm.so+0x109182f] JavaThread::thread_main_inner()+0x12f (javaThread.cpp:773) V [libjvm.so+0x1ac19d6] Thread::call_run()+0xb6 (thread.cpp:231) V [libjvm.so+0x1748888] thread_native_entry(Thread*)+0x128 (os_linux.cpp:877) ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1447#issuecomment-2850775468 From rreyelts at gmail.com Mon May 5 19:41:12 2025 From: rreyelts at gmail.com (Toby Reyelts) Date: Mon, 5 May 2025 15:41:12 -0400 Subject: Value objects and inheritance Message-ID: [Apologies if this is the wrong list. I was hoping to find something more user-focused (e.g. a valhalla-users@), but this seems to be the recommended place to ask questions. Please LMK if there's somewhere more appropriate]. I've been reading the JEPs and messing around with the early access build, trying to create a mental model for myself about how JVMs will typically be able to optimize value classes. It seems like a goal is effectively to be able to dump object headers: - no identity (no boxing/unboxing visibility, no gc) - no synchronization - restrictions on inheritance etc but this seems like it relies on the ability of the JIT to know the concrete value of the type at runtime. E.G. if I have the method: public void print(java.lang.Number! n) { System.out.println(n.toString()); } It seems that the JVM must require some kind of object header to be able to determine the appropriate toString to dispatch to. Similarly, if I have: class X { Number![] nums = someNums(); } It seems like every Number in nums must still require an object header, because the JIT doesn't know the concrete type of said objects. Reading JEP 401 more closely, I see now that scalarization can't be supported for supertypes: One limitation of scalarization is that it is not typically applied to a > variable with a type that is a *supertype* of a value class type. Is heap flattening in the same category? Are there any optimizations that end up working with supertypes, or is the general premise that you'll mostly need to be working with the concrete classes for optimizations to kick in? -------------- next part -------------- An HTML attachment was scrubbed... URL: From qamai at openjdk.org Tue May 6 00:13:24 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 6 May 2025 00:13:24 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v5] In-Reply-To: References: Message-ID: > Hi > > The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects. > > It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE. > > An example regarding the issue with tracking the identity of a larval InlineTypeNode: > > Consider this pseudobytecode sequence: > > new MyValue; > dup; > loop; > invokespecial MyValue::; > areturn; > > There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object. > > Please take a look and leave your reviews, 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: - move progress check - Merge branch 'lworld' into larvaloop - fast path for non intrinsics - fix test failures - Merge branch 'lworld' into larvaloop - remove larval InlineTypeNode ------------- Changes: https://git.openjdk.org/valhalla/pull/1447/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1447&range=04 Stats: 851 lines in 18 files changed: 285 ins; 416 del; 150 mod Patch: https://git.openjdk.org/valhalla/pull/1447.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1447/head:pull/1447 PR: https://git.openjdk.org/valhalla/pull/1447 From qamai at openjdk.org Tue May 6 00:13:25 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 6 May 2025 00:13:25 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v4] In-Reply-To: <0DhP9Q4w2jjUP-uhgTLrCqxlVDFKdP7wm7_-Skfz21I=.1154aeb0-cd70-4dae-9b36-9070be8b642b@github.com> References: <6MMbO4fn1i6swKVOezub46YyiWLW29JWIvntcqSg-4s=.a5f46c5e-7e66-4125-8b52-4d701182ec6b@github.com> <0DhP9Q4w2jjUP-uhgTLrCqxlVDFKdP7wm7_-Skfz21I=.1154aeb0-cd70-4dae-9b36-9070be8b642b@github.com> Message-ID: On Mon, 5 May 2025 12:02:46 GMT, Tobias Hartmann wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> fast path for non intrinsics > > Thanks for quickly fixing these issues. I ran another round of testing and there's only one issue left: > > > compiler/arraycopy/TestEliminatedArrayCopyPhi.java > -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/workspace/open/src/hotspot/share/opto/phaseX.cpp:1821), pid=1040062, tid=1040080 > # Error: assert(_worklist.size() == 0) failed > # > # JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-04-30-0702055.tobias.hartmann.valhalla2) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-04-30-0702055.tobias.hartmann.valhalla2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x17de609] PhaseCCP::PhaseCCP(PhaseIterGVN*)+0x169 > > Current CompileTask: > C2:455 160 b 4 compiler.arraycopy.TestEliminatedArrayCopyPhi::test (27 bytes) > > Stack: [0x00007fadf8385000,0x00007fadf8485000], sp=0x00007fadf8480270, free space=1004k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x17de609] PhaseCCP::PhaseCCP(PhaseIterGVN*)+0x169 (phaseX.cpp:1821) > V [libjvm.so+0xb2573a] Compile::Optimize()+0xa0a (compile.cpp:2950) > V [libjvm.so+0xb28b7b] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1feb (compile.cpp:874) > V [libjvm.so+0x94e98d] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x46d (c2compiler.cpp:142) > V [libjvm.so+0xb37882] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb22 (compileBroker.cpp:2307) > V [libjvm.so+0xb38888] CompileBroker::compiler_thread_loop()+0x588 (compileBroker.cpp:1951) > V [libjvm.so+0x109182f] JavaThread::thread_main_inner()+0x12f (javaThread.cpp:773) > V [libjvm.so+0x1ac19d6] Thread::call_run()+0xb6 (thread.cpp:231) > V [libjvm.so+0x1748888] thread_native_entry(Thread*)+0x128 (os_linux.cpp:877) @TobiHartmann The failure was due to the fact that `PhaseMacroExpand::eliminate_allocate_node` can push nodes on the igvn worklist even if it does not successfully remove the allocation. As a result, I moved the progress check to after `igvn.optimize()` so that igvn worklist is cleared. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1447#issuecomment-2852804313 From forax at univ-mlv.fr Tue May 6 20:09:39 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 6 May 2025 22:09:39 +0200 (CEST) Subject: Value objects and inheritance In-Reply-To: References: Message-ID: <11900150.257451033.1746562179130.JavaMail.zimbra@univ-eiffel.fr> > From: "Toby Reyelts" > To: "valhalla-dev" > Sent: Monday, May 5, 2025 9:41:12 PM > Subject: Value objects and inheritance > [Apologies if this is the wrong list. I was hoping to find something more > user-focused (e.g. a valhalla-users@), but this seems to be the recommended > place to ask questions. Please LMK if there's somewhere more appropriate]. > I've been reading the JEPs and messing around with the early access build, > trying to create a mental model for myself about how JVMs will typically be > able to optimize value classes. It seems like a goal is effectively to be able > to dump object headers: > - no identity (no boxing/unboxing visibility, no gc) > - no synchronization > - restrictions on inheritance > etc > but this seems like it relies on the ability of the JIT to know the concrete > value of the type at runtime. E.G. if I have the method: > public void print(java.lang.Number! n) { > System.out.println(n.toString()); > } > It seems that the JVM must require some kind of object header to be able to > determine the appropriate toString to dispatch to. Not necessarily, if you call with print(Integer.valueOf(3)), if the JIT is able to inlining the call, the JIT will propagate the type (here Integer) so not boxing will occur. > Similarly, if I have: > class X { > Number![] nums = someNums(); > } > It seems like every Number in nums must still require an object header, because > the JIT doesn't know the concrete type of said objects. Here you have a field which store an array. An array is never a value type, so you will always have a header for the array. But at runtime, you can have an array of Integer!, in that case, all the elements of the array have no header. > Reading JEP 401 more closely, I see now that scalarization can't be supported > for supertypes: >> One limitation of scalarization is that it is not typically applied to a >> variable with a type that is a supertype of a value class type. > Is heap flattening in the same category? Heap flattening is usually harder to optimize than scalarization (see below). > Are there any optimizations that end up working with supertypes, or is the > general premise that you'll mostly need to be working with the concrete classes > for optimizations to kick in? Here is a simplified mental model : The bytecode instructions are the same for an identity class or a value class. That allow us to retrofit Integer or Optional to be a value type without any recompilation (yai !). Because of that, the value class optimizations have to be done at runtime, most of them are done by the JIT. For parameters/local variable (scalarization), if you use a concrete class, it's easy for a JIT. If you use a supertype, it depends on inlining. For fields (flattening), if you use a concrete class, if sizeof(object) < 64 bits, it's easy for the JIT. if you use a supertype, it depends on escape analysis. In the future, if sizeof(object) == 64 bits, the field has to be non-nullable. if sizeof(object) >= 64 bits, the field has to be non-nullable and the class has to allow tearing (several reads/writes). regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From matsaave at openjdk.org Thu May 8 17:41:25 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 8 May 2025 17:41:25 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v2] In-Reply-To: References: Message-ID: > Updates to javac prevent it from creating classes with improper uses of strict fields. Additionally, non-final strict fields are now allowed so `StrictFinalInstanceFieldsTest.java` needs to updated with new test cases. This patch adds new cases for final and non-final stricts as well as negative test cases using asmtools that check improper use of strict fields and early larval stack map frames. > > During testing, it was revealed that the new verify errors added in [JDK-8354694](https://bugs.openjdk.org/browse/JDK-8354694) do not work properly so a fix is included in this patch. > > Note: This cannot be integrated until jtreg is updated with a recent build of asmtools which can handle strict fields and can generate early_larval frames. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Problem list test until jtreg is updated ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1449/files - new: https://git.openjdk.org/valhalla/pull/1449/files/ef26fc6c..86fcbf48 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1449&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1449&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1449.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1449/head:pull/1449 PR: https://git.openjdk.org/valhalla/pull/1449 From coleenp at openjdk.org Thu May 8 17:56:18 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 May 2025 17:56:18 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:41:25 GMT, Matias Saavedra Silva wrote: >> Updates to javac prevent it from creating classes with improper uses of strict fields. Additionally, non-final strict fields are now allowed so `StrictFinalInstanceFieldsTest.java` needs to updated with new test cases. This patch adds new cases for final and non-final stricts as well as negative test cases using asmtools that check improper use of strict fields and early larval stack map frames. >> >> During testing, it was revealed that the new verify errors added in [JDK-8354694](https://bugs.openjdk.org/browse/JDK-8354694) do not work properly so a fix is included in this patch. >> >> Note: This cannot be integrated until jtreg is updated with a recent build of asmtools which can handle strict fields and can generate early_larval frames. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Problem list test until jtreg is updated test/hotspot/jtreg/ProblemList.txt line 142: > 140: runtime/valhalla/inlinetypes/PreloadCircularityTest.java 8349631 linux-aarch64-debug > 141: runtime/valhalla/inlinetypes/ValuePreloadTest.java 8349630 linux-aarch64-debug > 142: runtime/valhalla/inlinetypes/verifier/StrictInstanceFieldsTest.java generic-all Does this require a bug number? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1449#discussion_r2080186619 From coleenp at openjdk.org Thu May 8 17:56:18 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 May 2025 17:56:18 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v2] In-Reply-To: References: Message-ID: <848GaUIY64h1n3AqcMCdTa9Vc8zfXwV1RjwLceUguow=.ac8b68b5-6aad-42e7-9102-5697a6b6d57f@github.com> On Thu, 8 May 2025 17:50:47 GMT, Coleen Phillimore wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Problem list test until jtreg is updated > > test/hotspot/jtreg/ProblemList.txt line 142: > >> 140: runtime/valhalla/inlinetypes/PreloadCircularityTest.java 8349631 linux-aarch64-debug >> 141: runtime/valhalla/inlinetypes/ValuePreloadTest.java 8349630 linux-aarch64-debug >> 142: runtime/valhalla/inlinetypes/verifier/StrictInstanceFieldsTest.java generic-all > > Does this require a bug number? Maybe CODETOOLS-7903081 will work. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1449#discussion_r2080189276 From thartmann at openjdk.org Fri May 9 06:43:41 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 9 May 2025 06:43:41 GMT Subject: [lworld] RFR: 8356599: [lworld] C2 incorrectly folds array object klass load for atomic arrays Message-ID: `TypeAryKlassPtr` and `TypeAryPtr`/`TypeAry` in C2's typesystem currently don't keep track of atomicity of arrays. As a result, C2 might incorrectly fold loads from `GraphKit::load_object_klass` to non-atomic `TypeAryKlassPtr`, resulting in the `GraphKit::null_free_atomic_array_test` to incorrectly return false at runtime. I fixed this by selectively disabling folding of the klass load done by the `GraphKit::null_free_atomic_array_test` via a `fold_for_arrays` flag for now. I'll revisit this with JDK-8350865. Thanks, Tobias ------------- Commit messages: - Updated comment - 8356599: [lworld] C2 incorrectly folds array object klass load for atomic arrays Changes: https://git.openjdk.org/valhalla/pull/1451/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1451&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356599 Stats: 170 lines in 13 files changed: 117 ins; 17 del; 36 mod Patch: https://git.openjdk.org/valhalla/pull/1451.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1451/head:pull/1451 PR: https://git.openjdk.org/valhalla/pull/1451 From thartmann at openjdk.org Fri May 9 06:48:10 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 9 May 2025 06:48:10 GMT Subject: [lworld] Integrated: 8356599: [lworld] C2 incorrectly folds array object klass load for atomic arrays In-Reply-To: References: Message-ID: On Fri, 9 May 2025 06:38:11 GMT, Tobias Hartmann wrote: > `TypeAryKlassPtr` and `TypeAryPtr`/`TypeAry` in C2's typesystem currently don't keep track of atomicity of arrays. As a result, C2 might incorrectly fold loads from `GraphKit::load_object_klass` to non-atomic `TypeAryKlassPtr`, resulting in the `GraphKit::null_free_atomic_array_test` to incorrectly return false at runtime. > > I fixed this by selectively disabling folding of the klass load done by the `GraphKit::null_free_atomic_array_test` via a `fold_for_arrays` flag for now. I'll revisit this with JDK-8350865. > > Thanks, > Tobias This pull request has now been integrated. Changeset: c65b4584 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/c65b458426e51bd8f1893f455cdef33041baf408 Stats: 170 lines in 13 files changed: 117 ins; 17 del; 36 mod 8356599: [lworld] C2 incorrectly folds array object klass load for atomic arrays 8355941: [lworld] TestArrayAccessDeopt.java fails due to unexpected deoptimization ------------- PR: https://git.openjdk.org/valhalla/pull/1451 From thartmann at openjdk.org Fri May 9 10:33:16 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 9 May 2025 10:33:16 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v5] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 00:13:24 GMT, Quan Anh Mai wrote: >> Hi >> >> The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects. >> >> It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE. >> >> An example regarding the issue with tracking the identity of a larval InlineTypeNode: >> >> Consider this pseudobytecode sequence: >> >> new MyValue; >> dup; >> loop; >> invokespecial MyValue::; >> areturn; >> >> There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object. >> >> Please take a look and leave your reviews, 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: > > - move progress check > - Merge branch 'lworld' into larvaloop > - fast path for non intrinsics > - fix test failures > - Merge branch 'lworld' into larvaloop > - remove larval InlineTypeNode Thanks a lot for this great work and your patience, @merykitty. All tests passed and I had a detailed look at the changes. Looks all good to me, I just left a few questions / comments / suggestions. src/hotspot/share/opto/compile.cpp line 2847: > 2845: > 2846: { > 2847: // Eliminate some macro nodes before EA to reduce analysis pressure Is this something we should consider doing in mainline? src/hotspot/share/opto/compile.cpp line 2900: > 2898: } > 2899: igvn.set_delay_transform(false); > 2900: print_method(PHASE_ITER_GVN_AFTER_ELIMINATION, 2); Why did you remove the `igvn.optimize();` here? src/hotspot/share/opto/doCall.cpp line 707: > 705: } > 706: > 707: // Scalarize value objects passed into this invocation because we know that they are not larval Suggestion: // Scalarize value objects passed into this invocation if we know that they are not larval src/hotspot/share/opto/doCall.cpp line 891: > 889: if (cg->method()->is_object_constructor() && receiver != nullptr && gvn().type(receiver)->is_inlinetypeptr()) { > 890: InlineTypeNode* non_larval = InlineTypeNode::make_from_oop(this, receiver, gvn().type(receiver)->inline_klass()); > 891: // Relinquish the oop input, we will delay the allocation to the point it is needed It would be good to explain in more detail why we need to give up the oop input here. src/hotspot/share/opto/graphKit.cpp line 1504: > 1502: } > 1503: > 1504: Node* GraphKit::cast_non_larval(Node* obj) { Suggestion: Node* GraphKit::cast_to_non_larval(Node* obj) { src/hotspot/share/opto/graphKit.cpp line 1510: > 1508: > 1509: const Type* obj_type = gvn().type(obj); > 1510: if (!obj_type->is_inlinetypeptr()) { I think this should be merged with the if above. src/hotspot/share/opto/inlinetypenode.cpp line 1097: > 1095: // Use base oop if fields are loaded from memory, don't do so if base is the CheckCastPP of an > 1096: // allocation because the only case we load from a naked CheckCastPP is when we exit a > 1097: // constructor of an inline type and we want to relinquish the larval oop there As mentioned above, it would be good to explain why we need to relinquish the oop. src/hotspot/share/opto/inlinetypenode.cpp line 1100: > 1098: Node* base = is_loaded(phase); > 1099: if (base != nullptr && !base->is_InlineType() && !phase->type(base)->maybe_null() && AllocateNode::Ideal_allocation(base) == nullptr) { > 1100: if (oop != base || phase->type(is_buffered) != TypeInt::ONE) { Maybe use `InlineTypeNode::is_allocated` here instead? src/hotspot/share/opto/inlinetypenode.cpp line 1492: > 1490: res->set_oop(kit->gvn(), alloc_oop); > 1491: } > 1492: // TODO 8239003 Should we close/update [JDK-8239003](https://bugs.openjdk.org/browse/JDK-8239003) now? src/hotspot/share/opto/inlinetypenode.cpp line 1741: > 1739: // Equivalent InlineTypeNodes are merged by GVN, so we just need to search for AllocateNode users to find redundant allocations. > 1740: void InlineTypeNode::remove_redundant_allocations(PhaseIdealLoop* phase) { > 1741: // TODO 8332886 Really needed? GVN is disabled anyway. Should [JDK-8332886](https://bugs.openjdk.org/browse/JDK-8332886) be updated? Can the tests marked with `// TODO 8332886` in `TestBasicFunctionality.java` be enabled again? src/hotspot/share/opto/macro.cpp line 2907: > 2905: while (C->macro_count() > 0) { > 2906: if (iteration++ > 100) { > 2907: assert(false, "Too slow convergence of macro elimination"); Is this something that should be upstreamed to mainline? src/hotspot/share/opto/macro.cpp line 2955: > 2953: case Node::Class_Unlock: > 2954: success = eliminate_locking_node(n->as_AbstractLock()); > 2955: #ifndef PRODUCT Why is this change needed? src/hotspot/share/opto/macro.cpp line 2986: > 2984: } > 2985: > 2986: // If an allocation is used only in safepoints, elimination of another macro nodes can remove Suggestion: // If an allocation is used only in safepoints, elimination of another macro node can remove src/hotspot/share/opto/parse1.cpp line 186: > 184: bad_type_exit->control()->add_req(bad_type_ctrl); > 185: } > 186: l = gen_checkcast(l, makecon(tp->as_klass_type()->cast_to_exactness(true)), &bad_type_ctrl, false, true); Please add a comment explaining why we need to pass `true` here. src/hotspot/share/opto/parse1.cpp line 625: > 623: const Type* t = _gvn.type(parm); > 624: if (t->is_inlinetypeptr()) { > 625: if (!is_osr_parse() && !(method()->is_object_constructor() && i == 0)) { A comment would be good here src/hotspot/share/opto/parse1.cpp line 1782: > 1780: } > 1781: if (t != nullptr && t != Type::BOTTOM) { > 1782: if (!t->is_inlinetypeptr()) { I think below code needs more comments, it's really hard to read. src/hotspot/share/opto/parse1.cpp line 1799: > 1797: } else { > 1798: if (!n->is_InlineType()) { > 1799: // We cannot blindly expand an inline type here since it may be larval Suggestion: // We cannot blindly scalarize an inline type oop here since it may be larval src/hotspot/share/opto/parse1.cpp line 1801: > 1799: // We cannot blindly expand an inline type here since it may be larval > 1800: if (gvn().type(n)->is_zero_type()) { > 1801: // Null constant implies that this is not a larval objects Suggestion: // Null constant implies that this is not a larval object src/hotspot/share/opto/parse1.cpp line 1804: > 1802: map()->set_req(j, InlineTypeNode::make_null(gvn(), t->inline_klass())); > 1803: } else if (phi != nullptr && phi->is_InlineType()) { > 1804: // Larval oops cannot be merged with non-larval ones Suggestion: // Larval oops cannot be merged with non-larval ones and since the merge point is non-larval, 'n' must be non-larval as well src/hotspot/share/opto/parse2.cpp line 3600: > 3598: IdealGraphPrinter* printer = C->igv_printer(); > 3599: char buffer[256]; > 3600: jio_snprintf(buffer, sizeof(buffer), "Bytecode %d: %s, map: %d", bci(), Bytecodes::name(bc()), map() == nullptr ? -1 : map()->_idx); Looks like this should be fixed in mainline? src/hotspot/share/opto/parse3.cpp line 260: > 258: val = cast_non_larval(val); > 259: > 260: assert(!obj->is_InlineType(), "InlineTypeNodes are non-larval value objects"); The assert message is a bit confusing. Maybe improve it or add a comment that the field holder should not have been scalarized because it's a larval. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1447#pullrequestreview-2827293741 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081098023 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081099460 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081110476 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081258219 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081258646 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081259816 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081268646 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081272123 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081281915 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081279707 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081313953 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081324229 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081319481 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081327425 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081329157 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081395622 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081400005 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081392727 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081401220 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081347200 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081371648 From thartmann at openjdk.org Fri May 9 10:33:17 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 9 May 2025 10:33:17 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v5] In-Reply-To: References: Message-ID: <_DYwrHMqet7l_gFlsBgMLG0TqtSgxAcQ8g6xAbiRqU8=.a483e1d1-7e91-4319-a9ab-eacc91702794@github.com> On Fri, 9 May 2025 07:27:47 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: >> >> - move progress check >> - Merge branch 'lworld' into larvaloop >> - fast path for non intrinsics >> - fix test failures >> - Merge branch 'lworld' into larvaloop >> - remove larval InlineTypeNode > > src/hotspot/share/opto/compile.cpp line 2900: > >> 2898: } >> 2899: igvn.set_delay_transform(false); >> 2900: print_method(PHASE_ITER_GVN_AFTER_ELIMINATION, 2); > > Why did you remove the `igvn.optimize();` here? Ah, you added it to `eliminate_macro_nodes`. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2081312701 From liach at openjdk.org Fri May 9 15:15:10 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 15:15:10 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:41:25 GMT, Matias Saavedra Silva wrote: >> Updates to javac prevent it from creating classes with improper uses of strict fields. Additionally, non-final strict fields are now allowed so `StrictFinalInstanceFieldsTest.java` needs to updated with new test cases. This patch adds new cases for final and non-final stricts as well as negative test cases using asmtools that check improper use of strict fields and early larval stack map frames. >> >> During testing, it was revealed that the new verify errors added in [JDK-8354694](https://bugs.openjdk.org/browse/JDK-8354694) do not work properly so a fix is included in this patch. >> >> Note: This cannot be integrated until jtreg is updated with a recent build of asmtools which can handle strict fields and can generate early_larval frames. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Problem list test until jtreg is updated For jasm tests, do we usually include a Xxx.test which includes the source to generate the basic jasm with asmtools, and then include comments in jasm to indicate where the class is modified from the original? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1449#issuecomment-2866930834 From qamai at openjdk.org Fri May 9 17:55:47 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 9 May 2025 17:55:47 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v5] In-Reply-To: <_DYwrHMqet7l_gFlsBgMLG0TqtSgxAcQ8g6xAbiRqU8=.a483e1d1-7e91-4319-a9ab-eacc91702794@github.com> References: <_DYwrHMqet7l_gFlsBgMLG0TqtSgxAcQ8g6xAbiRqU8=.a483e1d1-7e91-4319-a9ab-eacc91702794@github.com> Message-ID: <1pq_08LLRjgurWInMkN4u8HTgajh_QFybJkeEF_oZ78=.65fd1abc-682e-4a0b-abfa-e6aba882e69e@github.com> On Fri, 9 May 2025 09:36:50 GMT, Tobias Hartmann wrote: >> src/hotspot/share/opto/compile.cpp line 2900: >> >>> 2898: } >>> 2899: igvn.set_delay_transform(false); >>> 2900: print_method(PHASE_ITER_GVN_AFTER_ELIMINATION, 2); >> >> Why did you remove the `igvn.optimize();` here? > > Ah, you added it to `eliminate_macro_nodes`. Yes, I think it is cleaner that way instead of trailing each `mex.eliminate_macro_nodes` with an `igvn.optimize()` ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2082228503 From qamai at openjdk.org Fri May 9 17:55:46 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 9 May 2025 17:55:46 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v6] In-Reply-To: References: Message-ID: > Hi > > The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects. > > It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE. > > An example regarding the issue with tracking the identity of a larval InlineTypeNode: > > Consider this pseudobytecode sequence: > > new MyValue; > dup; > loop; > invokespecial MyValue::; > areturn; > > There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object. > > 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: Tobias' comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1447/files - new: https://git.openjdk.org/valhalla/pull/1447/files/bdc01f44..4b16f6d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1447&range=05 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1447&range=04-05 Stats: 74 lines in 9 files changed: 34 ins; 8 del; 32 mod Patch: https://git.openjdk.org/valhalla/pull/1447.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1447/head:pull/1447 PR: https://git.openjdk.org/valhalla/pull/1447 From qamai at openjdk.org Fri May 9 18:03:13 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 9 May 2025 18:03:13 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v5] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 09:11:06 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: >> >> - move progress check >> - Merge branch 'lworld' into larvaloop >> - fast path for non intrinsics >> - fix test failures >> - Merge branch 'lworld' into larvaloop >> - remove larval InlineTypeNode > > src/hotspot/share/opto/inlinetypenode.cpp line 1100: > >> 1098: Node* base = is_loaded(phase); >> 1099: if (base != nullptr && !base->is_InlineType() && !phase->type(base)->maybe_null() && AllocateNode::Ideal_allocation(base) == nullptr) { >> 1100: if (oop != base || phase->type(is_buffered) != TypeInt::ONE) { > > Maybe use `InlineTypeNode::is_allocated` here instead? `InlineTypeNode::is_allocated` tries to see if an `InlineTypeNode` is buffered, while this check tries to see if the node has `is_buffered` being `true` and `oop` being exactly `base`, not a random value. So it cannot be used here. > src/hotspot/share/opto/macro.cpp line 2955: > >> 2953: case Node::Class_Unlock: >> 2954: success = eliminate_locking_node(n->as_AbstractLock()); >> 2955: #ifndef PRODUCT > > Why is this change needed? `_has_locks` is not used any where. So I remove it and merge the 2 loops into 1. I don't see any reason why locks and allocations need to be eliminated separately. > src/hotspot/share/opto/parse2.cpp line 3600: > >> 3598: IdealGraphPrinter* printer = C->igv_printer(); >> 3599: char buffer[256]; >> 3600: jio_snprintf(buffer, sizeof(buffer), "Bytecode %d: %s, map: %d", bci(), Bytecodes::name(bc()), map() == nullptr ? -1 : map()->_idx); > > Looks like this should be fixed in mainline? It can be, but it's one-line and it is nice to have so I think it can be here, too. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2082234017 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2082238906 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2082237006 From qamai at openjdk.org Fri May 9 18:03:13 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 9 May 2025 18:03:13 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v6] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 09:17:33 GMT, Tobias Hartmann wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> Tobias' comments > > src/hotspot/share/opto/inlinetypenode.cpp line 1492: > >> 1490: res->set_oop(kit->gvn(), alloc_oop); >> 1491: } >> 1492: // TODO 8239003 > > Should we close/update [JDK-8239003](https://bugs.openjdk.org/browse/JDK-8239003) now? I think we can. > src/hotspot/share/opto/inlinetypenode.cpp line 1741: > >> 1739: // Equivalent InlineTypeNodes are merged by GVN, so we just need to search for AllocateNode users to find redundant allocations. >> 1740: void InlineTypeNode::remove_redundant_allocations(PhaseIdealLoop* phase) { >> 1741: // TODO 8332886 Really needed? GVN is disabled anyway. > > Should [JDK-8332886](https://bugs.openjdk.org/browse/JDK-8332886) be updated? Can the tests marked with `// TODO 8332886` in `TestBasicFunctionality.java` be enabled again? I tried and the `TODO` on `test28` can go away while that on `test21` cannot. I have not investigated further. The caption of [JDK-8332886](https://bugs.openjdk.org/browse/JDK-8332886) should certainly be updated after this patch, though. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2082236372 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2082235655 From qamai at openjdk.org Fri May 9 18:07:26 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 9 May 2025 18:07:26 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v5] In-Reply-To: References: Message-ID: <9Den44bm-DHy1Ddv5L1POBNlJZfQs8r2CoCG8ZXRoZI=.9bfd256b-5ad7-4f4b-b6c3-53045ff834af@github.com> On Fri, 9 May 2025 07:26:48 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: >> >> - move progress check >> - Merge branch 'lworld' into larvaloop >> - fast path for non intrinsics >> - fix test failures >> - Merge branch 'lworld' into larvaloop >> - remove larval InlineTypeNode > > src/hotspot/share/opto/compile.cpp line 2847: > >> 2845: >> 2846: { >> 2847: // Eliminate some macro nodes before EA to reduce analysis pressure > > Is this something we should consider doing in mainline? I'm not sure what effect it will have on mainline. For this patch, without this, `TestNullableInlineTypes::test85` tries to enter EA with 10k nodes, which it bails out. Trying to eliminate all trivially removable allocations reduces the number to 2k, allows EA to complete successfully. I think it may be more significant on Valhalla because in general we seem to emit a lot more nodes with value objects. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2082243176 From qamai at openjdk.org Fri May 9 18:10:05 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 9 May 2025 18:10:05 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v5] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 09:37:38 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: >> >> - move progress check >> - Merge branch 'lworld' into larvaloop >> - fast path for non intrinsics >> - fix test failures >> - Merge branch 'lworld' into larvaloop >> - remove larval InlineTypeNode > > src/hotspot/share/opto/macro.cpp line 2907: > >> 2905: while (C->macro_count() > 0) { >> 2906: if (iteration++ > 100) { >> 2907: assert(false, "Too slow convergence of macro elimination"); > > Is this something that should be upstreamed to mainline? I think this mostly helps if we try to eliminate allocations without or before EA (because otherwise allocations should be scalarized at safepoints during EA already). As a result, it is necessary only if this is also done: > // Eliminate some macro nodes before EA to reduce analysis pressure ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2082246572 From qamai at openjdk.org Fri May 9 18:13:09 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 9 May 2025 18:13:09 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v5] In-Reply-To: <9Den44bm-DHy1Ddv5L1POBNlJZfQs8r2CoCG8ZXRoZI=.9bfd256b-5ad7-4f4b-b6c3-53045ff834af@github.com> References: <9Den44bm-DHy1Ddv5L1POBNlJZfQs8r2CoCG8ZXRoZI=.9bfd256b-5ad7-4f4b-b6c3-53045ff834af@github.com> Message-ID: On Fri, 9 May 2025 18:04:30 GMT, Quan Anh Mai wrote: >> src/hotspot/share/opto/compile.cpp line 2847: >> >>> 2845: >>> 2846: { >>> 2847: // Eliminate some macro nodes before EA to reduce analysis pressure >> >> Is this something we should consider doing in mainline? > > I'm not sure what effect it will have on mainline. For this patch, without this, `TestNullableInlineTypes::test85` tries to enter EA with 10k nodes, which it bails out. Trying to eliminate all trivially removable allocations reduces the number to 2k, allows EA to complete successfully. I think it may be more significant on Valhalla because in general we seem to emit a lot more nodes with value objects. Please let me know what you think about this, perhaps we need to measure the effects on mainline first. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2082250108 From qamai at openjdk.org Fri May 9 18:13:08 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 9 May 2025 18:13:08 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v4] In-Reply-To: <0DhP9Q4w2jjUP-uhgTLrCqxlVDFKdP7wm7_-Skfz21I=.1154aeb0-cd70-4dae-9b36-9070be8b642b@github.com> References: <6MMbO4fn1i6swKVOezub46YyiWLW29JWIvntcqSg-4s=.a5f46c5e-7e66-4125-8b52-4d701182ec6b@github.com> <0DhP9Q4w2jjUP-uhgTLrCqxlVDFKdP7wm7_-Skfz21I=.1154aeb0-cd70-4dae-9b36-9070be8b642b@github.com> Message-ID: On Mon, 5 May 2025 12:02:46 GMT, Tobias Hartmann wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> fast path for non intrinsics > > Thanks for quickly fixing these issues. I ran another round of testing and there's only one issue left: > > > compiler/arraycopy/TestEliminatedArrayCopyPhi.java > -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/workspace/open/src/hotspot/share/opto/phaseX.cpp:1821), pid=1040062, tid=1040080 > # Error: assert(_worklist.size() == 0) failed > # > # JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-04-30-0702055.tobias.hartmann.valhalla2) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-04-30-0702055.tobias.hartmann.valhalla2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x17de609] PhaseCCP::PhaseCCP(PhaseIterGVN*)+0x169 > > Current CompileTask: > C2:455 160 b 4 compiler.arraycopy.TestEliminatedArrayCopyPhi::test (27 bytes) > > Stack: [0x00007fadf8385000,0x00007fadf8485000], sp=0x00007fadf8480270, free space=1004k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x17de609] PhaseCCP::PhaseCCP(PhaseIterGVN*)+0x169 (phaseX.cpp:1821) > V [libjvm.so+0xb2573a] Compile::Optimize()+0xa0a (compile.cpp:2950) > V [libjvm.so+0xb28b7b] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1feb (compile.cpp:874) > V [libjvm.so+0x94e98d] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x46d (c2compiler.cpp:142) > V [libjvm.so+0xb37882] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb22 (compileBroker.cpp:2307) > V [libjvm.so+0xb38888] CompileBroker::compiler_thread_loop()+0x588 (compileBroker.cpp:1951) > V [libjvm.so+0x109182f] JavaThread::thread_main_inner()+0x12f (javaThread.cpp:773) > V [libjvm.so+0x1ac19d6] Thread::call_run()+0xb6 (thread.cpp:231) > V [libjvm.so+0x1748888] thread_native_entry(Thread*)+0x128 (os_linux.cpp:877) @TobiHartmann Thanks a lot for your reviews, I think I have addressed all of them. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1447#issuecomment-2867520708 From liach at openjdk.org Fri May 9 21:42:06 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 21:42:06 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:41:25 GMT, Matias Saavedra Silva wrote: >> Updates to javac prevent it from creating classes with improper uses of strict fields. Additionally, non-final strict fields are now allowed so `StrictFinalInstanceFieldsTest.java` needs to updated with new test cases. This patch adds new cases for final and non-final stricts as well as negative test cases using asmtools that check improper use of strict fields and early larval stack map frames. >> >> During testing, it was revealed that the new verify errors added in [JDK-8354694](https://bugs.openjdk.org/browse/JDK-8354694) do not work properly so a fix is included in this patch. >> >> Note: This cannot be integrated until jtreg is updated with a recent build of asmtools which can handle strict fields and can generate early_larval frames. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Problem list test until jtreg is updated Just noticed these jasm and jcod are from StrictInstanceFieldsTest. Should be all good. ------------- Marked as reviewed by liach (no project role). PR Review: https://git.openjdk.org/valhalla/pull/1449#pullrequestreview-2829733625 From thartmann at openjdk.org Mon May 12 05:43:41 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 12 May 2025 05:43:41 GMT Subject: [lworld] Integrated: 8348959: [lworld] compiler/c2/TestMergeStores.java fails IR verification Message-ID: The test now passes after [JDK-8351414](https://bugs.openjdk.org/browse/JDK-8351414) was merged from mainline. Thanks, Tobias ------------- Commit messages: - [lworld] Un-problem listing TestMergeStores.java Changes: https://git.openjdk.org/valhalla/pull/1453/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1453&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348959 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1453.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1453/head:pull/1453 PR: https://git.openjdk.org/valhalla/pull/1453 From thartmann at openjdk.org Mon May 12 05:43:42 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 12 May 2025 05:43:42 GMT Subject: [lworld] Integrated: 8348959: [lworld] compiler/c2/TestMergeStores.java fails IR verification In-Reply-To: References: Message-ID: <-AAH3pOT0-SAdW7DMG38yrtgUlh5p8jr4jws65iZQvI=.a4be8fca-555e-4dfd-aa3a-04af45285871@github.com> On Mon, 12 May 2025 05:39:24 GMT, Tobias Hartmann wrote: > The test now passes after [JDK-8351414](https://bugs.openjdk.org/browse/JDK-8351414) was merged from mainline. > > Thanks, > Tobias This pull request has now been integrated. Changeset: cc76937a Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/cc76937adc2586aec264e54377731f941e83d25a Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8348959: [lworld] compiler/c2/TestMergeStores.java fails IR verification ------------- PR: https://git.openjdk.org/valhalla/pull/1453 From thartmann at openjdk.org Mon May 12 11:58:06 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 12 May 2025 11:58:06 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v5] In-Reply-To: References: <9Den44bm-DHy1Ddv5L1POBNlJZfQs8r2CoCG8ZXRoZI=.9bfd256b-5ad7-4f4b-b6c3-53045ff834af@github.com> Message-ID: On Fri, 9 May 2025 18:10:40 GMT, Quan Anh Mai wrote: >> I'm not sure what effect it will have on mainline. For this patch, without this, `TestNullableInlineTypes::test85` tries to enter EA with 10k nodes, which it bails out. Trying to eliminate all trivially removable allocations reduces the number to 2k, allows EA to complete successfully. I think it may be more significant on Valhalla because in general we seem to emit a lot more nodes with value objects. > > Please let me know what you think about this, perhaps we need to measure the effects on mainline first. Makes sense. I'd say we put it into Valhalla only for now. We can still consider upstreaming it later. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2084508877 From thartmann at openjdk.org Mon May 12 11:58:06 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 12 May 2025 11:58:06 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v5] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 17:56:35 GMT, Quan Anh Mai wrote: >> src/hotspot/share/opto/inlinetypenode.cpp line 1100: >> >>> 1098: Node* base = is_loaded(phase); >>> 1099: if (base != nullptr && !base->is_InlineType() && !phase->type(base)->maybe_null() && AllocateNode::Ideal_allocation(base) == nullptr) { >>> 1100: if (oop != base || phase->type(is_buffered) != TypeInt::ONE) { >> >> Maybe use `InlineTypeNode::is_allocated` here instead? > > `InlineTypeNode::is_allocated` tries to see if an `InlineTypeNode` is buffered, while this check tries to see if the node has `is_buffered` being `true` and `oop` being exactly `base`, not a random value. So it cannot be used here. Right, thanks for the clarification. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2084510165 From thartmann at openjdk.org Mon May 12 11:58:06 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 12 May 2025 11:58:06 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v6] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 17:57:54 GMT, Quan Anh Mai wrote: >> src/hotspot/share/opto/inlinetypenode.cpp line 1741: >> >>> 1739: // Equivalent InlineTypeNodes are merged by GVN, so we just need to search for AllocateNode users to find redundant allocations. >>> 1740: void InlineTypeNode::remove_redundant_allocations(PhaseIdealLoop* phase) { >>> 1741: // TODO 8332886 Really needed? GVN is disabled anyway. >> >> Should [JDK-8332886](https://bugs.openjdk.org/browse/JDK-8332886) be updated? Can the tests marked with `// TODO 8332886` in `TestBasicFunctionality.java` be enabled again? > > I tried and the `TODO` on `test28` can go away while that on `test21` cannot. I have not investigated further. The caption of [JDK-8332886](https://bugs.openjdk.org/browse/JDK-8332886) should certainly be updated after this patch, though. Sounds good, please update [JDK-8332886](https://bugs.openjdk.org/browse/JDK-8332886) accordingly once this is in. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2084512511 From thartmann at openjdk.org Mon May 12 12:03:06 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 12 May 2025 12:03:06 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v6] In-Reply-To: References: Message-ID: <8WxiAyy4POjGSQzHEd-wCq0zS-S4G1EzMKhnSyiJx7A=.36eceb54-1cc7-40bf-938d-9d830a036c6c@github.com> On Fri, 9 May 2025 17:58:34 GMT, Quan Anh Mai wrote: >> src/hotspot/share/opto/inlinetypenode.cpp line 1492: >> >>> 1490: res->set_oop(kit->gvn(), alloc_oop); >>> 1491: } >>> 1492: // TODO 8239003 >> >> Should we close/update [JDK-8239003](https://bugs.openjdk.org/browse/JDK-8239003) now? > > I think we can. I tentatively closed [JDK-8239003](https://bugs.openjdk.org/browse/JDK-8239003) as dup. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2084516221 From thartmann at openjdk.org Mon May 12 12:03:07 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 12 May 2025 12:03:07 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v5] In-Reply-To: References: Message-ID: <_AfpMttqb6GcQffeEVuwZAj3HswDFpUs_g8hPlY_OM8=.a28b3a1e-d39f-42fd-93d5-da3655a81087@github.com> On Fri, 9 May 2025 18:07:37 GMT, Quan Anh Mai wrote: >> src/hotspot/share/opto/macro.cpp line 2907: >> >>> 2905: while (C->macro_count() > 0) { >>> 2906: if (iteration++ > 100) { >>> 2907: assert(false, "Too slow convergence of macro elimination"); >> >> Is this something that should be upstreamed to mainline? > > I think this mostly helps if we try to eliminate allocations without or before EA (because otherwise allocations should be scalarized at safepoints during EA already). As a result, it is necessary only if this is also done: > >> // Eliminate some macro nodes before EA to reduce analysis pressure Sounds good. Let's leave it in Valhalla only for now. >> src/hotspot/share/opto/macro.cpp line 2955: >> >>> 2953: case Node::Class_Unlock: >>> 2954: success = eliminate_locking_node(n->as_AbstractLock()); >>> 2955: #ifndef PRODUCT >> >> Why is this change needed? > > `_has_locks` is not used any where. So I remove it and merge the 2 loops into 1. I don't see any reason why locks and allocations need to be eliminated separately. Right but that's something that should be done in mainline (as well) then. Could you please file an RFE? We can still integrate it in Valhalla as part of this change. >> src/hotspot/share/opto/parse2.cpp line 3600: >> >>> 3598: IdealGraphPrinter* printer = C->igv_printer(); >>> 3599: char buffer[256]; >>> 3600: jio_snprintf(buffer, sizeof(buffer), "Bytecode %d: %s, map: %d", bci(), Bytecodes::name(bc()), map() == nullptr ? -1 : map()->_idx); >> >> Looks like this should be fixed in mainline? > > It can be, but it's one-line and it is nice to have so I think it can be here, too. Right, let's leave it in Valhalla only for now. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2084516941 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2084518489 PR Review Comment: https://git.openjdk.org/valhalla/pull/1447#discussion_r2084519453 From thartmann at openjdk.org Mon May 12 12:15:13 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 12 May 2025 12:15:13 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v6] In-Reply-To: References: Message-ID: <5ucuCaR2UrhaUJ67xETy9921E5HupGxFq6Ul4pu8LjU=.588610c7-0306-42af-a37b-0d09490a7ec7@github.com> On Fri, 9 May 2025 17:55:46 GMT, Quan Anh Mai wrote: >> Hi >> >> The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects. >> >> It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE. >> >> An example regarding the issue with tracking the identity of a larval InlineTypeNode: >> >> Consider this pseudobytecode sequence: >> >> new MyValue; >> dup; >> loop; >> invokespecial MyValue::; >> areturn; >> >> There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object. >> >> 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: > > Tobias' comments Thanks for the nice comments and updates, Quan-Anh. The changes look good to me now! ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1447#pullrequestreview-2832993155 From qamai at openjdk.org Mon May 12 13:40:13 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 12 May 2025 13:40:13 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v6] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 17:55:46 GMT, Quan Anh Mai wrote: >> Hi >> >> The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects. >> >> It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE. >> >> An example regarding the issue with tracking the identity of a larval InlineTypeNode: >> >> Consider this pseudobytecode sequence: >> >> new MyValue; >> dup; >> loop; >> invokespecial MyValue::; >> areturn; >> >> There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object. >> >> 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: > > Tobias' comments Thanks very much for the reviews, I have created [JDK-8356779](https://bugs.openjdk.org/browse/JDK-8356779) and [JDK-8356780](https://bugs.openjdk.org/browse/JDK-8356780). ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1447#issuecomment-2872614653 From duke at openjdk.org Mon May 12 13:40:13 2025 From: duke at openjdk.org (duke) Date: Mon, 12 May 2025 13:40:13 GMT Subject: [lworld] RFR: 8335256: [lworld] C2: Remove larval InlineTypeNode [v6] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 17:55:46 GMT, Quan Anh Mai wrote: >> Hi >> >> The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects. >> >> It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE. >> >> An example regarding the issue with tracking the identity of a larval InlineTypeNode: >> >> Consider this pseudobytecode sequence: >> >> new MyValue; >> dup; >> loop; >> invokespecial MyValue::; >> areturn; >> >> There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object. >> >> 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: > > Tobias' comments @merykitty Your change (at version 4b16f6d047ecf497d703684165f58e2f3ef5c6a7) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1447#issuecomment-2872617056 From qamai at openjdk.org Mon May 12 14:36:06 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 12 May 2025 14:36:06 GMT Subject: [lworld] Integrated: 8335256: [lworld] C2: Remove larval InlineTypeNode In-Reply-To: References: Message-ID: On Sun, 27 Apr 2025 13:17:10 GMT, Quan Anh Mai wrote: > Hi > > The root issue is that a larval value object is fundamentally different from a non-larval one. The most important thing is that it has a unique identity and it expects any modification on 1 reference observable by all other equivalent references. As a result, we need a mechanism to track the identity of a larval object, which `InlineTypeNode` does not provide. My current proposal to fix this issue is to abandon larval `InlineTypeNode`s and use the oop like other objects. > > It is probably beneficial to have another mechanism to make it easier optimizing larval inline type nodes, but I think it can be a follow-up RFE. > > An example regarding the issue with tracking the identity of a larval InlineTypeNode: > > Consider this pseudobytecode sequence: > > new MyValue; > dup; > loop; > invokespecial MyValue::; > areturn; > > There are 2 equivalent references in the stack at the loop entry. When `Parse::merge` encounters them, it cannot know that these are the same because the back-edge has not been processed yet. As a result, it creates 2 separate `Phi`s for these references. Then, `invokespecial` will only make the top of the stack a non-larval object, not the next one, which is the one returned to the caller. As a result, we fail with `assert(!value->is_InlineType() || !value->as_InlineType()->is_larval(), "returning a larval")`. Worse, if the method is osr-compiled at the loop head, we have 2 separate references fed into the compiled function and there is no way we may know that they are of the same object. > > Please take a look and leave your reviews, thanks a lot. This pull request has now been integrated. Changeset: 6a6cf4f7 Author: Quan Anh Mai Committer: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/6a6cf4f75583c781b16b44a21eb1254b9d79213f Stats: 881 lines in 19 files changed: 312 ins; 417 del; 152 mod 8335256: [lworld] C2: Remove larval InlineTypeNode 8325627: [lworld] C2 compilation bailout for TestNullableInlineTypes::test85 8354283: [lworld] TestAllocationMergeAndFolding fails since jdk-25+16, since an allocation is detected Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1447 From qamai at openjdk.org Wed May 14 13:11:24 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 14 May 2025 13:11:24 GMT Subject: [lworld] RFR: 8353236: [lworld] Better documentation for Valhalla Unsafe intrinsics [v3] In-Reply-To: References: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com> Message-ID: On Thu, 10 Apr 2025 15:29:40 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch clarifies the meaning of undefined behavior when working with `Unsafe` and specifies the requirements when working with `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer`. >> >> Please take a look and leave your suggestions, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > remove unnecessary statements Can I have this PR reviewed, please? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1425#issuecomment-2880187369 From duke at openjdk.org Wed May 14 19:54:59 2025 From: duke at openjdk.org (duke) Date: Wed, 14 May 2025 19:54:59 GMT Subject: [lworld] Withdrawn: 8351362: Post-process @Strict annotation for testing In-Reply-To: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> Message-ID: <8hc6p0URVhBdX8hU5RXXi21E8Bmoxas1irvr5m9M7ko=.83b63432-6689-49cd-8ae0-678ae1b3c5dd@github.com> On Wed, 12 Mar 2025 14:15:31 GMT, Chen Liang wrote: > Added a test tool to strictify files and migrated the existing StrictFinalInstanceFieldsTest as an example. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/valhalla/pull/1395 From liach at openjdk.org Wed May 14 20:02:09 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 14 May 2025 20:02:09 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing [v4] In-Reply-To: References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> Message-ID: On Wed, 9 Apr 2025 09:48:24 GMT, Chen Liang wrote: >> Added a test tool to strictify files and migrated the existing StrictFinalInstanceFieldsTest as an example. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - 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 > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/strict-processor > - 8351362: Post-process @Strict annotation for testing This does seems a bit weird in the context of lworld, where many structures already make use of strict - I think this would be more convincing if we can port strict onto simply master, or add a flag on lworld to run with just mainline + strict, without any value object. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1395#issuecomment-2881402393 From dsimms at openjdk.org Thu May 15 08:41:22 2025 From: dsimms at openjdk.org (David Simms) Date: Thu, 15 May 2025 08:41:22 GMT Subject: [lworld] Integrated: 8357035: [lworld] ValueTagMapTest missing -XX:+UnlockDiagnosticVMOptions Message-ID: Use UnlockDiagnosticVMOptions for print layout ------------- Commit messages: - 8357035: [lworld] ValueTagMapTest missing -XX:+UnlockDiagnosticVMOptions Changes: https://git.openjdk.org/valhalla/pull/1454/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1454&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357035 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1454.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1454/head:pull/1454 PR: https://git.openjdk.org/valhalla/pull/1454 From dsimms at openjdk.org Thu May 15 08:41:22 2025 From: dsimms at openjdk.org (David Simms) Date: Thu, 15 May 2025 08:41:22 GMT Subject: [lworld] Integrated: 8357035: [lworld] ValueTagMapTest missing -XX:+UnlockDiagnosticVMOptions In-Reply-To: References: Message-ID: <4jX6ynmwpO35WQ9lZZXIm76xM_PmjS3SWsnOJzxU8q4=.650a33a6-ea55-4766-baf9-62f1fc86b976@github.com> On Thu, 15 May 2025 08:34:13 GMT, David Simms wrote: > Use UnlockDiagnosticVMOptions for print layout This pull request has now been integrated. Changeset: 3caea21e Author: David Simms URL: https://git.openjdk.org/valhalla/commit/3caea21e8377e46c7c5c6e838dba79aef487a466 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8357035: [lworld] ValueTagMapTest missing -XX:+UnlockDiagnosticVMOptions ------------- PR: https://git.openjdk.org/valhalla/pull/1454 From david.simms at oracle.com Thu May 15 09:19:51 2025 From: david.simms at oracle.com (David Simms) Date: Thu, 15 May 2025 11:19:51 +0200 Subject: CFV: New Valhalla Committer: Chen Liang Message-ID: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> |I hereby nominate Chen Liang to Valhalla Committer. Chen is a JDK reviewer, working in the langtools and core libraries areas of the JDK. Votes are due by May 29th, 2025. Only current Valhalla Committers [1] 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 [2]. David Simms [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote| -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.simms at oracle.com Thu May 15 09:22:14 2025 From: david.simms at oracle.com (David Simms) Date: Thu, 15 May 2025 11:22:14 +0200 Subject: CFV: New Valhalla Committer: Chen Liang In-Reply-To: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> References: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> Message-ID: Vote: yes On 2025-05-15 11:19, David Simms wrote: > |I hereby nominate Chen Liang to Valhalla Committer. Chen is a JDK > reviewer, working in the langtools and core libraries areas of the > JDK. Votes are due by May 29th, 2025. Only current Valhalla Committers > [1] 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 [2]. David Simms [1] https://openjdk.org/census [2] > https://openjdk.org/projects/#committer-vote| -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu May 15 11:32:31 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 15 May 2025 12:32:31 +0100 Subject: CFV: New Valhalla Committer: Chen Liang In-Reply-To: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> References: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> Message-ID: <1ff08908-64d6-4290-b66d-889bf7478105@oracle.com> Vote: yes! Maurizio On 15/05/2025 10:19, David Simms wrote: > |I hereby nominate Chen Liang to Valhalla Committer. Chen is a JDK > reviewer, working in the langtools and core libraries areas of the > JDK. Votes are due by May 29th, 2025. Only current Valhalla Committers > [1] 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 [2]. David Simms [1] https://openjdk.org/census [2] > https://openjdk.org/projects/#committer-vote| -------------- next part -------------- An HTML attachment was scrubbed... URL: From lois.foltan at oracle.com Thu May 15 12:44:58 2025 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 15 May 2025 12:44:58 +0000 Subject: CFV: New Valhalla Committer: Chen Liang In-Reply-To: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> References: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> Message-ID: Vote: yes Lois From: valhalla-dev on behalf of David Simms Date: Thursday, May 15, 2025 at 5:21?AM To: valhalla-dev at openjdk.org Subject: CFV: New Valhalla Committer: Chen Liang I hereby nominate Chen Liang to Valhalla Committer. Chen is a JDK reviewer, working in the langtools and core libraries areas of the JDK. Votes are due by May 29th, 2025. Only current Valhalla Committers [1] 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 [2]. David Simms [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Thu May 15 13:45:29 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 15 May 2025 15:45:29 +0200 Subject: CFV: New Valhalla Committer: Chen Liang In-Reply-To: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> References: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> Message-ID: <5cd161c7-562d-4bd9-846b-57829001d2f1@oracle.com> Vote: yes Best regards, Tobias On 5/15/25 11:19, David Simms wrote: > |I hereby nominate Chen Liang to Valhalla Committer. Chen is a JDK reviewer, working in the langtools and core libraries areas of the JDK. Votes are due by May 29th, 2025. Only current Valhalla Committers [1] 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 [2]. David Simms [1] https://openjdk.org/census [2] https://openjdk.org/projects/#committer-vote| > From roger.riggs at oracle.com Thu May 15 14:09:18 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 15 May 2025 10:09:18 -0400 Subject: CFV: New Valhalla Committer: Chen Liang In-Reply-To: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> References: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> Message-ID: <9628ef06-bd1c-46e1-abef-e6606cc7969f@oracle.com> Vote: yes On 5/15/25 5:19 AM, David Simms wrote: > |I hereby nominate Chen Liang to Valhalla Committer.| -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsimms at openjdk.org Thu May 15 14:09:33 2025 From: dsimms at openjdk.org (David Simms) Date: Thu, 15 May 2025 14:09:33 GMT Subject: [lworld] RFR: Merge jdk Message-ID: <7g7fmtsuEOLFlWAkSfNqc88_gael1bcnT9P2AfhXCRY=.d3c97dbf-b0dd-4635-8526-ed36ce5f1589@github.com> Merge jdk-25+18 ------------- Commit messages: - Adjust testing - Merge tag 'jdk-25+18' into lworld_merge_jdk_25_18 - 8349479: C2: when a Type node becomes dead, make CFG path that uses it unreachable - 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files - 8352748: Remove com.sun.tools.classfile from the JDK - 8351034: Add AVX-512 intrinsics for ML-DSA - 8351319: AOT cache support for custom class loaders broken since JDK-8348426 - 8350563: C2 compilation fails because PhaseCCP does not reach a fixpoint - 8354213: Restore pointless unicode characters to ASCII - 8353041: NeverBranchNode causes incorrect block frequency calculation - ... and 131 more: https://git.openjdk.org/valhalla/compare/6a6cf4f7...5c5aecd8 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1455&range=00.0 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1455&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1455/files Stats: 33290 lines in 647 files changed: 16765 ins; 14277 del; 2248 mod Patch: https://git.openjdk.org/valhalla/pull/1455.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1455/head:pull/1455 PR: https://git.openjdk.org/valhalla/pull/1455 From vicente.romero at oracle.com Thu May 15 15:18:49 2025 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 15 May 2025 11:18:49 -0400 Subject: CFV: New Valhalla Committer: Chen Liang In-Reply-To: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> References: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> Message-ID: <84bd41b5-ae49-4524-8def-8317abe4176d@oracle.com> vote: yes Vicente On 5/15/25 05:19, David Simms wrote: > |I hereby nominate Chen Liang to Valhalla Committer. Chen is a JDK > reviewer, working in the langtools and core libraries areas of the > JDK. Votes are due by May 29th, 2025. Only current Valhalla Committers > [1] 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 [2]. David Simms [1] https://openjdk.org/census [2] > https://openjdk.org/projects/#committer-vote| -------------- next part -------------- An HTML attachment was scrubbed... URL: From qamai at openjdk.org Thu May 15 16:45:35 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 15 May 2025 16:45:35 GMT Subject: [lworld] RFR: 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" Message-ID: Many thanks to @TobiHartmann for the speedy investigation. This patch fixes the issue by adding a `ciField` for the null marker. I also do a small change to make the name of the `ciField` of a flattened field clearer. I think adding a scenario to test flattening of nullable and atomic fields is necessary. There are some failures that I filed https://bugs.openjdk.org/browse/JDK-8357061 for the investigation. Please kindly review, thanks a lot. ------------- Commit messages: - Add a ciField for null markers, beautify flattened field name Changes: https://git.openjdk.org/valhalla/pull/1456/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1456&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356963 Stats: 100 lines in 6 files changed: 62 ins; 7 del; 31 mod Patch: https://git.openjdk.org/valhalla/pull/1456.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1456/head:pull/1456 PR: https://git.openjdk.org/valhalla/pull/1456 From qamai at openjdk.org Thu May 15 16:48:30 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 15 May 2025 16:48:30 GMT Subject: [lworld] RFR: 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" [v2] In-Reply-To: References: Message-ID: > Many thanks to @TobiHartmann for the speedy investigation. This patch fixes the issue by adding a `ciField` for the null marker. I also do a small change to make the name of the `ciField` of a flattened field clearer. I think adding a scenario to test flattening of nullable and atomic fields is necessary. There are some failures that I filed https://bugs.openjdk.org/browse/JDK-8357061 for the investigation. > > Please kindly review, thanks a lot. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: include ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1456/files - new: https://git.openjdk.org/valhalla/pull/1456/files/a9b00816..128b8292 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1456&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1456&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1456.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1456/head:pull/1456 PR: https://git.openjdk.org/valhalla/pull/1456 From qamai at openjdk.org Thu May 15 17:24:42 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 15 May 2025 17:24:42 GMT Subject: [lworld] RFR: 8332886: [lworld] TestBasicFunctionality::test21 counts incorrectly Message-ID: Hi, The issue here is that the test counts incorrectly, the test looks like this: val1 = MyValue1.createWithFieldsInline(x, y); val2 = MyValue2.createWithFieldsInline(x, rD); val4 = MyValue1.createWithFieldsInline(x, y); All of these are reference fields since they are nullable and `MyValue1` and `MyValue2` are both very large. `MyValue1` has an identity field `int[] oa`, so `val1` and `val4` cannot be commoned. As a result, there should be 4 allocations: `val1`, `val4`, `val1.v4` , and `val2`. Please take a look and leave your reviews, thanks a lot. ------------- Commit messages: - fix test Changes: https://git.openjdk.org/valhalla/pull/1457/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1457&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332886 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1457.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1457/head:pull/1457 PR: https://git.openjdk.org/valhalla/pull/1457 From liach at openjdk.org Thu May 15 18:35:18 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 15 May 2025 18:35:18 GMT Subject: [lworld] RFR: 8357054: [lworld] tools/javac/valhalla/value-objects/ test still using com.sun.tools.classfile Message-ID: Did not notice these old classfile tests. Required for upgrading to latest mainline. ------------- Commit messages: - 8357054: [lworld] tools/javac/valhalla/value-objects/ test still using com.sun.tools.classfile Changes: https://git.openjdk.org/valhalla/pull/1458/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1458&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357054 Stats: 116 lines in 4 files changed: 18 ins; 32 del; 66 mod Patch: https://git.openjdk.org/valhalla/pull/1458.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1458/head:pull/1458 PR: https://git.openjdk.org/valhalla/pull/1458 From duke at openjdk.org Thu May 15 19:45:02 2025 From: duke at openjdk.org (duke) Date: Thu, 15 May 2025 19:45:02 GMT Subject: [valhalla-docs] Withdrawn: Add Brian Goetz presentation from July 2024 In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 15:33:14 GMT, Andrew Byrd wrote: > Looking into the present state of project Valhalla, I found a very good presentation from July of 2024 at https://inside.java/tag/valhalla that was not listed on the page at https://openjdk.org/projects/valhalla/ but seems to fit well alongside the other presentations listed there. > > I updated the page to include this presentation from Brian Goetz. I also sorted the presentations in reverse chronological order, as some of the information in this 2024 presentation seems to supersede previous ones. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/valhalla-docs/pull/14 From frederic.parain at oracle.com Thu May 15 19:50:27 2025 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 15 May 2025 15:50:27 -0400 Subject: CFV: New Valhalla Committer: Chen Liang In-Reply-To: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> References: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> Message-ID: Vote: yes Fred On 5/15/25 05:19, David Simms wrote: > |I hereby nominate Chen Liang to Valhalla Committer. Chen is a JDK > reviewer, working in the langtools and core libraries areas of the > JDK. Votes are due by May 29th, 2025. Only current Valhalla Committers > [1] 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 [2]. David Simms [1] https://openjdk.org/census [2] > https://openjdk.org/projects/#committer-vote| -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu May 15 20:06:44 2025 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 15 May 2025 16:06:44 -0400 Subject: CFV: New Valhalla Committer: Chen Liang In-Reply-To: References: <469dd81f-361a-4715-ab22-d00d0e943d6b@oracle.com> Message-ID: Vote: yes On 5/15/25 3:50 PM, Frederic Parain wrote: > > Vote: yes > > > Fred > > > On 5/15/25 05:19, David Simms wrote: >> |I hereby nominate Chen Liang to Valhalla Committer. Chen is a JDK >> reviewer, working in the langtools and core libraries areas of the >> JDK. Votes are due by May 29th, 2025. Only current Valhalla >> Committers [1] 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 [2]. David Simms [1] >> https://openjdk.org/census [2] >> https://openjdk.org/projects/#committer-vote| -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsimms at openjdk.org Fri May 16 06:31:19 2025 From: dsimms at openjdk.org (David Simms) Date: Fri, 16 May 2025 06:31:19 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: <7g7fmtsuEOLFlWAkSfNqc88_gael1bcnT9P2AfhXCRY=.d3c97dbf-b0dd-4635-8526-ed36ce5f1589@github.com> References: <7g7fmtsuEOLFlWAkSfNqc88_gael1bcnT9P2AfhXCRY=.d3c97dbf-b0dd-4635-8526-ed36ce5f1589@github.com> Message-ID: On Thu, 15 May 2025 14:01:10 GMT, David Simms wrote: > Merge jdk-25+18 This pull request has now been integrated. Changeset: d528f94d Author: David Simms URL: https://git.openjdk.org/valhalla/commit/d528f94d0992f77c044cfea7ab68d1a4b091c6c3 Stats: 33290 lines in 647 files changed: 16765 ins; 14277 del; 2248 mod Merge jdk Merge jdk-25+18 ------------- PR: https://git.openjdk.org/valhalla/pull/1455 From dsimms at openjdk.org Fri May 16 07:31:15 2025 From: dsimms at openjdk.org (David Simms) Date: Fri, 16 May 2025 07:31:15 GMT Subject: [lworld] RFR: 8357054: [lworld] tools/javac/valhalla/value-objects/ test still using com.sun.tools.classfile In-Reply-To: References: Message-ID: On Thu, 15 May 2025 18:31:03 GMT, Chen Liang wrote: > Did not notice these old classfile tests. Required for upgrading to latest mainline. Do mind removing the problem listings (came in with the jdk-25+18 merge), and double check CreateSymbols.java has appropriate support for LoadableDescriptors (I don't know if does, perhaps confirm if it doesn't) ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1458#issuecomment-2885885732 From dsimms at openjdk.org Fri May 16 08:25:15 2025 From: dsimms at openjdk.org (David Simms) Date: Fri, 16 May 2025 08:25:15 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge tag 'jdk-25+19' into lworld_merge_jdk_25_19 Added tag jdk-25+19 for changeset a71f621a ------------- Commit messages: - Merge tag 'jdk-25+19' into lworld_merge_jdk_25_19 - 8353694: Resolved Class/Field/Method CP entries missing from AOT Configuration - 8329887: RISC-V: C2: Support Zvbb Vector And-Not instruction - 8354559: gc/g1/TestAllocationFailure.java doesn't need WB API - 8295651: JFR: 'jfr scrub' should summarize what was removed - 8354471: Assertion failure with -XX:-EnableX86ECoreOpts - 8353589: Open source a few Swing menu-related tests - 8352001: AOT cache should not contain classes injected into built-in class loaders - 8354873: javax/swing/plaf/metal/MetalIconFactory/bug4952462.java failing on CI - 8351603: Change to GCC 14.2.0 for building on Linux at Oracle - ... and 108 more: https://git.openjdk.org/valhalla/compare/d528f94d...83961a81 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1459&range=00.0 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1459&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1459/files Stats: 199974 lines in 645 files changed: 23955 ins; 173295 del; 2724 mod Patch: https://git.openjdk.org/valhalla/pull/1459.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1459/head:pull/1459 PR: https://git.openjdk.org/valhalla/pull/1459 From dsimms at openjdk.org Fri May 16 09:39:51 2025 From: dsimms at openjdk.org (David Simms) Date: Fri, 16 May 2025 09:39:51 GMT Subject: [lworld] RFR: Merge jdk [v2] In-Reply-To: References: Message-ID: > Merge tag 'jdk-25+19' into lworld_merge_jdk_25_19 > Added tag jdk-25+19 for changeset a71f621a David Simms has updated the pull request incrementally with 134 additional commits since the last revision: - Logical Merge Fixes - Merge tag 'jdk-25+20' into lworld_merge_jdk_25_19 Added tag jdk-25+20 for changeset 953eef4f - 8347337: ZGC: String dedups short-lived strings Reviewed-by: kbarrett, aboldtch, eosterlund - 8348928: Check for case label validity are misbehaving when binding patterns with unnamed bindings are present Reviewed-by: asotona, abimpoudis, vromero - 8353558: x86: Use better instructions for ICache sync when available Reviewed-by: kvn, adinn - 8353216: Improve VerifyMethodHandles for method handle linkers Reviewed-by: dlong - 8354558: -XX:AOTMode=record crashes with boot loader package-info class Reviewed-by: ccheung, matsaave - 8354553: Open source several clipboard tests batch0 Reviewed-by: serb, prr - 8353596: GenShen: Test TestClone.java#generational-no-coops intermittent timed out Reviewed-by: kdnilsen, ysr - 8354554: Open source several clipboard tests batch1 Reviewed-by: serb, prr - ... and 124 more: https://git.openjdk.org/valhalla/compare/83961a81...f6641902 ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1459/files - new: https://git.openjdk.org/valhalla/pull/1459/files/83961a81..f6641902 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1459&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1459&range=00-01 Stats: 39093 lines in 1026 files changed: 31311 ins; 5605 del; 2177 mod Patch: https://git.openjdk.org/valhalla/pull/1459.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1459/head:pull/1459 PR: https://git.openjdk.org/valhalla/pull/1459 From liach at openjdk.org Fri May 16 10:13:09 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 16 May 2025 10:13:09 GMT Subject: [lworld] RFR: 8357054: [lworld] tools/javac/valhalla/value-objects/ test still using com.sun.tools.classfile In-Reply-To: References: Message-ID: On Thu, 15 May 2025 18:31:03 GMT, Chen Liang wrote: > Did not notice these old classfile tests. Required for upgrading to latest mainline. LoadableDescriptors is an impl detail; don't think we need to track that for javac compilation against the APIs. I will update the Problemlist soon. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1458#issuecomment-2886284297 From jbhateja at openjdk.org Fri May 16 12:15:14 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 16 May 2025 12:15:14 GMT Subject: [lworld] RFR: 8353236: [lworld] Better documentation for Valhalla Unsafe intrinsics [v3] In-Reply-To: References: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com> Message-ID: On Wed, 14 May 2025 13:07:59 GMT, Quan Anh Mai wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unnecessary statements > > Can I have this PR reviewed, please? Hi @merykitty , Just to complement your documentation update, I have created test scenarios for various verification errors around implicit larval objects, i.e. the ones created using new operator but are still pending initialization, explicit larvals generated using Unsafe.makePrivateBuffer should adhere to the same semantics. [Implicit larval objects verification.docx](https://github.com/user-attachments/files/20243499/Implicit.larval.objects.verification.docx) Overall, your changes look good to me; finer refinements can be done in due course, but specs are much clear now, thank you so much! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1425#issuecomment-2886544198 From jbhateja at openjdk.org Fri May 16 12:15:15 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 16 May 2025 12:15:15 GMT Subject: [lworld] RFR: 8353236: [lworld] Better documentation for Valhalla Unsafe intrinsics [v3] In-Reply-To: References: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com> Message-ID: On Thu, 10 Apr 2025 15:29:40 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch clarifies the meaning of undefined behavior when working with `Unsafe` and specifies the requirements when working with `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer`. >> >> Please take a look and leave your suggestions, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > remove unnecessary statements src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 424: > 422: > 423: /** > 424: * Returns an object instance with a private buffered value whose layout Suggestion: * Returns a value type instance with a private buffered value whose layout src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 426: > 424: * Returns an object instance with a private buffered value whose layout > 425: * and contents is exactly the given value instance. The return object is > 426: * in the larval state that can be updated using the unsafe put operation. Suggestion: * in the larval state that can be modified through an unsafe put operation. src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 430: > 428: * This method mimics the operation of the bytecode {@code new}, allowing > 429: * the creation of a value object without the conventional Java procedure > 430: * and bypassing the bytecode verifier regarding larval objects. As a Suggestion: * the creation of a value object without the conventional Java procedure * and bypassing usual verification applicable to @{code new} bytecode. As a src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 443: > 441: *
  • The return object can only be used as the first argument passed to > 442: * {@code Unsafe::putXXX} or to {@link #finishPrivateBuffer(Object)}, any > 443: * other usage, such as loading from or returning it, is illegal. The only Suggestion: * other usage, such as reading any of its fields or returning it, is illegal. The only ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2092510279 PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2092516930 PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2092626215 PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2092635101 From liach at openjdk.org Fri May 16 12:29:04 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 16 May 2025 12:29:04 GMT Subject: [lworld] RFR: 8353236: [lworld] Better documentation for Valhalla Unsafe intrinsics [v3] In-Reply-To: References: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com> Message-ID: On Thu, 10 Apr 2025 15:29:40 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch clarifies the meaning of undefined behavior when working with `Unsafe` and specifies the requirements when working with `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer`. >> >> Please take a look and leave your suggestions, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > remove unnecessary statements src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 70: > 68: *
  • Impossible code execution. E.g. the branches of an {@code if} are > 69: * both executed or both not executed. > 70: *
  • Wiping out the hard drive. I think these are just for alerting people; this is not that valuable to create a huge list to specifically highlight. I think what we should highlight instead is the best practices. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1425#discussion_r2092949536 From thartmann at openjdk.org Fri May 16 12:30:14 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 May 2025 12:30:14 GMT Subject: [lworld] RFR: 8332886: [lworld] TestBasicFunctionality::test21 counts incorrectly In-Reply-To: References: Message-ID: On Thu, 15 May 2025 17:19:46 GMT, Quan Anh Mai wrote: > Hi, > > The issue here is that the test counts incorrectly, the test looks like this: > > val1 = MyValue1.createWithFieldsInline(x, y); > val2 = MyValue2.createWithFieldsInline(x, rD); > val4 = MyValue1.createWithFieldsInline(x, y); > > All of these are reference fields since they are nullable and `MyValue1` and `MyValue2` are both very large. `MyValue1` has an identity field `int[] oa`, so `val1` and `val4` cannot be commoned. As a result, there should be 4 allocations: `val1`, `val4`, `val1.v4` , and `val2`. > > Please take a look and leave your reviews, thanks a lot. Thanks for looking into this. The fix looks good to me. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1457#pullrequestreview-2846480654 From thartmann at openjdk.org Fri May 16 12:51:06 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 May 2025 12:51:06 GMT Subject: [lworld] RFR: 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" [v2] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 16:48:30 GMT, Quan Anh Mai wrote: >> Many thanks to @TobiHartmann for the speedy investigation. This patch fixes the issue by adding a `ciField` for the null marker. I also do a small change to make the name of the `ciField` of a flattened field clearer. I think adding a scenario to test flattening of nullable and atomic fields is necessary. There are some failures that I filed https://bugs.openjdk.org/browse/JDK-8357061 for the investigation. >> >> Please kindly review, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > include Thanks a lot for working on this Quan-Anh! Give that null markers are `ciFields`now, I think this should be refactored, right? https://github.com/openjdk/valhalla/blob/d528f94d0992f77c044cfea7ab68d1a4b091c6c3/src/hotspot/share/opto/callnode.cpp#L520 https://github.com/openjdk/valhalla/blob/d528f94d0992f77c044cfea7ab68d1a4b091c6c3/src/hotspot/share/opto/callnode.cpp#L535 Can we now also get rid of `InlineTypeNode::field_value_by_offset` -> `InlineTypeNode::null_marker_by_offset`? The new scenario 6 fails with `compiler/valhalla/inlinetypes/TestValueClasses.java` on Windows: Custom Run Test: @Run: test13_verifier - @Test: test13: compiler.lib.ir_framework.shared.TestRunException: There was an error while invoking @Run method public void compiler.valhalla.inlinetypes.TestValueClasses.test13_verifier() at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:162) at compiler.lib.ir_framework.test.AbstractTest.run(AbstractTest.java:105) at compiler.lib.ir_framework.test.CustomRunTest.run(CustomRunTest.java:89) at compiler.lib.ir_framework.test.TestVM.runTests(TestVM.java:869) at compiler.lib.ir_framework.test.TestVM.start(TestVM.java:256) at compiler.lib.ir_framework.test.TestVM.main(TestVM.java:169) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:159) ... 5 more Caused by: java.lang.RuntimeException: assertTrue: expected true, was false at jdk.test.lib.Asserts.fail(Asserts.java:715) at jdk.test.lib.Asserts.assertTrue(Asserts.java:545) at jdk.test.lib.Asserts.assertTrue(Asserts.java:531) at compiler.valhalla.inlinetypes.TestValueClasses.test13_verifier(TestValueClasses.java:482) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ... 7 more Custom Run Test: @Run: test10_verifier - @Test: test10: compiler.lib.ir_framework.shared.TestRunException: There was an error while invoking @Run method public void compiler.valhalla.inlinetypes.TestValueClasses.test10_verifier() at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:162) at compiler.lib.ir_framework.test.AbstractTest.run(AbstractTest.java:105) at compiler.lib.ir_framework.test.CustomRunTest.run(CustomRunTest.java:89) at compiler.lib.ir_framework.test.TestVM.runTests(TestVM.java:869) at compiler.lib.ir_framework.test.TestVM.start(TestVM.java:256) at compiler.lib.ir_framework.test.TestVM.main(TestVM.java:169) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:159) ... 5 more Caused by: java.lang.RuntimeException: assertEquals expected: compiler.valhalla.inlinetypes.MyValueClass1 at f403cd58 but was: compiler.valhalla.inlinetypes.MyValueClass1 at 10d8d1b9 at jdk.test.lib.Asserts.fail(Asserts.java:715) at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) at jdk.test.lib.Asserts.assertEquals(Asserts.java:195) at jdk.test.lib.Asserts.assertEQ(Asserts.java:172) at compiler.valhalla.inlinetypes.TestValueClasses.test10_verifier(TestValueClasses.java:448) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ... 7 more Custom Run Test: @Run: test22_verifier - @Test: test22: compiler.lib.ir_framework.shared.TestRunException: There was an error while invoking @Run method public void compiler.valhalla.inlinetypes.TestValueClasses.test22_verifier() at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:162) at compiler.lib.ir_framework.test.AbstractTest.run(AbstractTest.java:100) at compiler.lib.ir_framework.test.CustomRunTest.run(CustomRunTest.java:89) at compiler.lib.ir_framework.test.TestVM.runTests(TestVM.java:869) at compiler.lib.ir_framework.test.TestVM.start(TestVM.java:256) at compiler.lib.ir_framework.test.TestVM.main(TestVM.java:169) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:159) ... 5 more Caused by: java.lang.RuntimeException: assertEquals expected: 103 but was: 120 at jdk.test.lib.Asserts.fail(Asserts.java:715) at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) at jdk.test.lib.Asserts.assertEquals(Asserts.java:195) at compiler.valhalla.inlinetypes.TestValueClasses.test22_verifier(TestValueClasses.java:961) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ... 7 more Custom Run Test: @Run: test15_verifier - @Test: test15: compiler.lib.ir_framework.shared.TestRunException: There was an error while invoking @Run method public void compiler.valhalla.inlinetypes.TestValueClasses.test15_verifier() at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:162) at compiler.lib.ir_framework.test.AbstractTest.run(AbstractTest.java:105) at compiler.lib.ir_framework.test.CustomRunTest.run(CustomRunTest.java:89) at compiler.lib.ir_framework.test.TestVM.runTests(TestVM.java:869) at compiler.lib.ir_framework.test.TestVM.start(TestVM.java:256) at compiler.lib.ir_framework.test.TestVM.main(TestVM.java:169) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:159) ... 5 more Caused by: java.lang.RuntimeException: assertEquals expected: compiler.valhalla.inlinetypes.MyValueClass1 at f403cd58 but was: compiler.valhalla.inlinetypes.MyValueClass1 at 10d8d1b9 at jdk.test.lib.Asserts.fail(Asserts.java:715) at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) at jdk.test.lib.Asserts.assertEquals(Asserts.java:195) at jdk.test.lib.Asserts.assertEQ(Asserts.java:172) at compiler.valhalla.inlinetypes.TestValueClasses.test15_verifier(TestValueClasses.java:548) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ... 7 more Custom Run Test: @Run: test9_verifier - @Test: test9: compiler.lib.ir_framework.shared.TestRunException: There was an error while invoking @Run method public void compiler.valhalla.inlinetypes.TestValueClasses.test9_verifier() at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:162) at compiler.lib.ir_framework.test.AbstractTest.run(AbstractTest.java:105) at compiler.lib.ir_framework.test.CustomRunTest.run(CustomRunTest.java:89) at compiler.lib.ir_framework.test.TestVM.runTests(TestVM.java:869) at compiler.lib.ir_framework.test.TestVM.start(TestVM.java:256) at compiler.lib.ir_framework.test.TestVM.main(TestVM.java:169) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:159) ... 5 more Caused by: java.lang.RuntimeException: assertEquals expected: compiler.valhalla.inlinetypes.MyValueClass1 at f403cd58 but was: compiler.valhalla.inlinetypes.MyValueClass1 at 10d8d1b9 at jdk.test.lib.Asserts.fail(Asserts.java:715) at jdk.test.lib.Asserts.assertEquals(Asserts.java:208) at jdk.test.lib.Asserts.assertEquals(Asserts.java:195) at jdk.test.lib.Asserts.assertEQ(Asserts.java:172) at compiler.valhalla.inlinetypes.TestValueClasses.test9(TestValueClasses.java:424) at compiler.valhalla.inlinetypes.TestValueClasses.test9_verifier(TestValueClasses.java:435) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ... 7 more `sources/TestIncludesAreSorted.java` fails due to: `java.lang.RuntimeException: 1 files with unsorted headers found: ... open/src/hotspot/share/ci/ciField.cpp` I linked the failure results in JBS. src/hotspot/share/ci/ciField.cpp line 236: > 234: > 235: char buffer[256]; > 236: jio_snprintf(buffer, sizeof(buffer), "%s.%s", declared_field->name()->as_utf8(), subfield->name()->as_utf8()); There's some code that matches on `ciField::name`, for example in `ciField::is_call_site_target` but I think that should never be used for flat fields. ------------- Changes requested by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1456#pullrequestreview-2846519371 PR Review Comment: https://git.openjdk.org/valhalla/pull/1456#discussion_r2092976186 From thartmann at openjdk.org Fri May 16 13:03:45 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 May 2025 13:03:45 GMT Subject: [lworld] RFR: 8346466: [lworld] compiler/valhalla/inlinetypes/TestArrayCopyWithOops.java asserts using generational zgc Message-ID: Un-problem listing tests with ZGC because in the meantime, all issues seem to have been fixed. Thanks, Tobias ------------- Commit messages: - [lworld] Un-problem list ZGC tests Changes: https://git.openjdk.org/valhalla/pull/1460/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1460&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346466 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1460.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1460/head:pull/1460 PR: https://git.openjdk.org/valhalla/pull/1460 From thartmann at openjdk.org Fri May 16 13:05:05 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 May 2025 13:05:05 GMT Subject: [lworld] RFR: 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" [v2] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 16:48:30 GMT, Quan Anh Mai wrote: >> Many thanks to @TobiHartmann for the speedy investigation. This patch fixes the issue by adding a `ciField` for the null marker. I also do a small change to make the name of the `ciField` of a flattened field clearer. I think adding a scenario to test flattening of nullable and atomic fields is necessary. There are some failures that I filed https://bugs.openjdk.org/browse/JDK-8357061 for the investigation. >> >> Please kindly review, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > include I also noticed that `try_optimize_strict_final_load_memory` has a `field` argument that is unused. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1456#issuecomment-2886664346 From thartmann at openjdk.org Fri May 16 13:21:50 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 May 2025 13:21:50 GMT Subject: [lworld] RFR: 8349630: [lworld] runtime/valhalla/inlinetypes/ValuePreloadTest.java fails on linux-aarch64-debug after jdk-25+5 Message-ID: Un-problem listing some more tests that don't fail anymore. Thanks, Tobias ------------- Commit messages: - [lwor?d] More un-problem listing Changes: https://git.openjdk.org/valhalla/pull/1461/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1461&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349630 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1461.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1461/head:pull/1461 PR: https://git.openjdk.org/valhalla/pull/1461 From thartmann at openjdk.org Fri May 16 13:57:47 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 May 2025 13:57:47 GMT Subject: [lworld] RFR: 8349630: [lworld] runtime/valhalla/inlinetypes/ValuePreloadTest.java fails on linux-aarch64-debug after jdk-25+5 [v2] In-Reply-To: References: Message-ID: > Un-problem listing some more tests that don't fail anymore. > > Thanks, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: Re-adding CircularityTest.java ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1461/files - new: https://git.openjdk.org/valhalla/pull/1461/files/86fa7fb0..23d026c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1461&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1461&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1461.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1461/head:pull/1461 PR: https://git.openjdk.org/valhalla/pull/1461 From thartmann at openjdk.org Fri May 16 14:00:05 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 May 2025 14:00:05 GMT Subject: [lworld] Integrated: 8346466: [lworld] compiler/valhalla/inlinetypes/TestArrayCopyWithOops.java asserts using generational zgc In-Reply-To: References: Message-ID: On Fri, 16 May 2025 12:55:52 GMT, Tobias Hartmann wrote: > Un-problem listing tests with ZGC because in the meantime, all issues seem to have been fixed. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 768d0c74 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/768d0c74593369ba5787b34a360bc6e706ad5a9a Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod 8346466: [lworld] compiler/valhalla/inlinetypes/TestArrayCopyWithOops.java asserts using generational zgc 8341848: [lworld] assert(index == 0 || is_power_of_2(index)) with genzgc in several Valhalla tests 8341849: [lworld] Crash compiler.valhalla.inlinetypes.TestIntrinsics.test53 with genzgc 8341850: [lworld] Crash in compiler.valhalla.inlinetypes.TestNullableArrays.test78 with genzgc 8341947: [lworld] Crashing in java frames specifically on aarch64 with genzgc ------------- PR: https://git.openjdk.org/valhalla/pull/1460 From liach at openjdk.org Fri May 16 14:36:32 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 16 May 2025 14:36:32 GMT Subject: [lworld] RFR: 8357054: [lworld] tools/javac/valhalla/value-objects/ test still using com.sun.tools.classfile [v2] In-Reply-To: References: Message-ID: > Did not notice these old classfile tests. Required for upgrading to latest mainline. 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: - Problemlist - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/javac-old-classfile-tests - 8357054: [lworld] tools/javac/valhalla/value-objects/ test still using com.sun.tools.classfile ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1458/files - new: https://git.openjdk.org/valhalla/pull/1458/files/5621aeeb..3ff864cd Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1458&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1458&range=00-01 Stats: 33285 lines in 646 files changed: 16760 ins; 14277 del; 2248 mod Patch: https://git.openjdk.org/valhalla/pull/1458.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1458/head:pull/1458 PR: https://git.openjdk.org/valhalla/pull/1458 From qamai at openjdk.org Fri May 16 15:10:00 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 16 May 2025 15:10:00 GMT Subject: [lworld] RFR: 8332886: [lworld] TestBasicFunctionality::test21 counts incorrectly In-Reply-To: References: Message-ID: On Thu, 15 May 2025 17:19:46 GMT, Quan Anh Mai wrote: > Hi, > > The issue here is that the test counts incorrectly, the test looks like this: > > val1 = MyValue1.createWithFieldsInline(x, y); > val2 = MyValue2.createWithFieldsInline(x, rD); > val4 = MyValue1.createWithFieldsInline(x, y); > > All of these are reference fields since they are nullable and `MyValue1` and `MyValue2` are both very large. `MyValue1` has an identity field `int[] oa`, so `val1` and `val4` cannot be commoned. As a result, there should be 4 allocations: `val1`, `val4`, `val1.v4` , and `val2`. > > Please take a look and leave your reviews, thanks a lot. Thanks for your reviews! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1457#issuecomment-2886991391 From duke at openjdk.org Fri May 16 15:10:00 2025 From: duke at openjdk.org (duke) Date: Fri, 16 May 2025 15:10:00 GMT Subject: [lworld] RFR: 8332886: [lworld] TestBasicFunctionality::test21 counts incorrectly In-Reply-To: References: Message-ID: On Thu, 15 May 2025 17:19:46 GMT, Quan Anh Mai wrote: > Hi, > > The issue here is that the test counts incorrectly, the test looks like this: > > val1 = MyValue1.createWithFieldsInline(x, y); > val2 = MyValue2.createWithFieldsInline(x, rD); > val4 = MyValue1.createWithFieldsInline(x, y); > > All of these are reference fields since they are nullable and `MyValue1` and `MyValue2` are both very large. `MyValue1` has an identity field `int[] oa`, so `val1` and `val4` cannot be commoned. As a result, there should be 4 allocations: `val1`, `val4`, `val1.v4` , and `val2`. > > Please take a look and leave your reviews, thanks a lot. @merykitty Your change (at version d8ace1af72650a18542444a38915d92baed63cfc) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1457#issuecomment-2886993977 From liach at openjdk.org Fri May 16 16:44:00 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 16 May 2025 16:44:00 GMT Subject: [lworld] RFR: 8357054: [lworld] tools/javac/valhalla/value-objects/ test still using com.sun.tools.classfile [v2] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 14:36:32 GMT, Chen Liang wrote: >> Did not notice these old classfile tests. Required for upgrading to latest mainline. > > 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: > > - Problemlist > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/javac-old-classfile-tests > - 8357054: [lworld] tools/javac/valhalla/value-objects/ test still using com.sun.tools.classfile Tested with Problemlist removed. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1458#issuecomment-2887210111 From duke at openjdk.org Fri May 16 16:44:00 2025 From: duke at openjdk.org (duke) Date: Fri, 16 May 2025 16:44:00 GMT Subject: [lworld] RFR: 8357054: [lworld] tools/javac/valhalla/value-objects/ test still using com.sun.tools.classfile [v2] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 14:36:32 GMT, Chen Liang wrote: >> Did not notice these old classfile tests. Required for upgrading to latest mainline. > > 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: > > - Problemlist > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/javac-old-classfile-tests > - 8357054: [lworld] tools/javac/valhalla/value-objects/ test still using com.sun.tools.classfile @liach Your change (at version 3ff864cd5af2c277539826baa205261d205e5bf1) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1458#issuecomment-2887211243 From liach at openjdk.org Fri May 16 16:48:05 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 16 May 2025 16:48:05 GMT Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in Class, Objects, and document limitations of value objects [v7] In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 16:51:40 GMT, Roger Riggs wrote: >> Add APINote and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. >> Simplified WeakHashMap javadoc updates for IdentityException. >> Added note to System.identityHashCode to include value objects. >> Added to class javadoc for IdentityHashMap for value objects. > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge > - Expand javadoc reference to Reference > - Merge remote-tracking branch 'refs/remotes/origin/8346307-throws-identityexception' into 8346307-throws-identityexception > - Merge branch 'openjdk:lworld' into 8346307-throws-identityexception > - 8346307: [lworld] Document WeakHashMap and other apis that may throw IdentityException > Add APINote and javadoc for IdentityException where it will be useful to know. > Simplified WeakHashMap javadoc updates for IdentityException. > Added note to System.identityHashCode to include value objects. > - 8346307: [lworld] Document WeakHashMap and other apis that may throw IdentityException > Add APINote and javadoc for IdentityException where it will be useful to know. > Updated Objects.hasIdentity to return true for non-null reference to identity class; else false > Added Objects.isValueObject to return true for non-null reference to value class; else false > Updated tests for value objects. PreviewNote isn't merged yet; we can revisit this one once that taglet is available here. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1327#issuecomment-2887218953 From qamai at openjdk.org Sat May 17 15:25:52 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sat, 17 May 2025 15:25:52 GMT Subject: [lworld] RFR: 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" [v3] In-Reply-To: References: Message-ID: > Many thanks to @TobiHartmann for the speedy investigation. This patch fixes the issue by adding a `ciField` for the null marker. I also do a small change to make the name of the `ciField` of a flattened field clearer. I think adding a scenario to test flattening of nullable and atomic fields is necessary. There are some failures that I filed https://bugs.openjdk.org/browse/JDK-8357061 for the investigation. > > 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 four additional commits since the last revision: - Merge branch 'lworld' into nullmarker - better error messages - include - Add a ciField for null markers, beautify flattened field name ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1456/files - new: https://git.openjdk.org/valhalla/pull/1456/files/128b8292..f622449e Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1456&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1456&range=01-02 Stats: 33445 lines in 662 files changed: 16829 ins; 14349 del; 2267 mod Patch: https://git.openjdk.org/valhalla/pull/1456.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1456/head:pull/1456 PR: https://git.openjdk.org/valhalla/pull/1456 From qamai at openjdk.org Sun May 18 07:08:43 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 18 May 2025 07:08:43 GMT Subject: [lworld] RFR: 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" [v4] In-Reply-To: References: Message-ID: > Many thanks to @TobiHartmann for the speedy investigation. This patch fixes the issue by adding a `ciField` for the null marker. I also do a small change to make the name of the `ciField` of a flattened field clearer. I think adding a scenario to test flattening of nullable and atomic fields is necessary. There are some failures that I filed https://bugs.openjdk.org/browse/JDK-8357061 for the investigation. > > Please kindly review, thanks a lot. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: fix SigEntry comparison ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1456/files - new: https://git.openjdk.org/valhalla/pull/1456/files/f622449e..c7194bf3 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1456&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1456&range=02-03 Stats: 6 lines in 2 files changed: 3 ins; 1 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1456.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1456/head:pull/1456 PR: https://git.openjdk.org/valhalla/pull/1456 From qamai at openjdk.org Sun May 18 08:35:03 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 18 May 2025 08:35:03 GMT Subject: [lworld] RFR: 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" [v2] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 13:02:53 GMT, Tobias Hartmann wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> include > > I also noticed that `try_optimize_strict_final_load_memory` has a `field` argument that is unused. @TobiHartmann The failures in Windows are due to a bug in `SigEntry::compare`. We try to obtain an `int` from `e1->_sort_offset - e2->_sort_offset` and the rounding error makes it that the null marker is equal to the last field. `std::qsort` is not stable, so we pass on Linux because it seems `std::qsort` is stable there. If I add a shuffle before sorting the array of `SigEntry`, a similar failure can be observed on Linux. The issue has been fixed. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1456#issuecomment-2888856178 From thartmann at openjdk.org Mon May 19 05:42:06 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 19 May 2025 05:42:06 GMT Subject: [lworld] Integrated: 8349630: [lworld] runtime/valhalla/inlinetypes/ValuePreloadTest.java fails on linux-aarch64-debug after jdk-25+5 In-Reply-To: References: Message-ID: On Fri, 16 May 2025 13:12:52 GMT, Tobias Hartmann wrote: > Un-problem listing some more tests that don't fail anymore. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 9190eb6b Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/9190eb6ba20fbbfb3a035c265c94ad18cbfbc8ec Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8349630: [lworld] runtime/valhalla/inlinetypes/ValuePreloadTest.java fails on linux-aarch64-debug after jdk-25+5 8349631: [lworld] runtime/valhalla/inlinetypes/PreloadCircularityTest.java fails on linux-aarch64-debug after jdk-25+5 ------------- PR: https://git.openjdk.org/valhalla/pull/1461 From qamai at openjdk.org Mon May 19 06:16:05 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 19 May 2025 06:16:05 GMT Subject: [lworld] Integrated: 8332886: [lworld] TestBasicFunctionality::test21 counts incorrectly In-Reply-To: References: Message-ID: On Thu, 15 May 2025 17:19:46 GMT, Quan Anh Mai wrote: > Hi, > > The issue here is that the test counts incorrectly, the test looks like this: > > val1 = MyValue1.createWithFieldsInline(x, y); > val2 = MyValue2.createWithFieldsInline(x, rD); > val4 = MyValue1.createWithFieldsInline(x, y); > > All of these are reference fields since they are nullable and `MyValue1` and `MyValue2` are both very large. `MyValue1` has an identity field `int[] oa`, so `val1` and `val4` cannot be commoned. As a result, there should be 4 allocations: `val1`, `val4`, `val1.v4` , and `val2`. > > Please take a look and leave your reviews, thanks a lot. This pull request has now been integrated. Changeset: 7739c439 Author: Quan Anh Mai Committer: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/7739c4395e872e940bdf5de31867818f07460deb Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 8332886: [lworld] TestBasicFunctionality::test21 counts incorrectly Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1457 From thartmann at openjdk.org Mon May 19 07:55:03 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 19 May 2025 07:55:03 GMT Subject: [lworld] RFR: 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" [v4] In-Reply-To: References: Message-ID: On Sun, 18 May 2025 07:08:43 GMT, Quan Anh Mai wrote: >> Many thanks to @TobiHartmann for the speedy investigation. This patch fixes the issue by adding a `ciField` for the null marker. I also do a small change to make the name of the `ciField` of a flattened field clearer. I think adding a scenario to test flattening of nullable and atomic fields is necessary. There are some failures that I filed https://bugs.openjdk.org/browse/JDK-8357061 for the investigation. >> >> Please kindly review, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > fix SigEntry comparison Great job finding the root cause for this! Looks good to me now. I'll re-run testing and report back once it passed. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1456#pullrequestreview-2849771414 From dfenacci at openjdk.org Mon May 19 11:50:17 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 19 May 2025 11:50:17 GMT Subject: [lworld] RFR: 8343420: [lworld] compiler/gcbarriers/TestG1BarrierGeneration.java after merging JDK-8334060 in jdk-24+18 Message-ID: `TestG1BarrierGeneration.testGetAndSet*` tests fail after [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569). These tests check that `VarHandle::getAndSet` with G1 a particular `GetAndSetP` or `GetAndSetN` node is created with a barrier before and after. [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) refactored `Unsafe::getAndSet` (which is used by `VarHandle::getAndSet`) to take value-classes into account, which implies that checks must be introduced to see if the target and argument objects are value-classes. This is done with a new overloaded `getAndSet` method that is now called instead of the old one. This method is not intrinsified (only inlined) and doesn't result in a `GetAndSet` node. It instead relies on the `compareAndSet` method (which gets intrinsified) and results in a `CompareAndSwap` node. As the goal of the test is mainly to check for G1 barrier creation, the sensible fix for now seems to be to modify the `TestG1BarrierGeneration.testGetAndSet*` tests to make them check for `CompareAndSwap` instead of `GetAndSet` nodes. ------------- Commit messages: - Merge branch 'lworld' into JDK-8343420 - JDK-8343420: [lworld] compiler/gcbarriers/TestG1BarrierGeneration.java after merging JDK-8334060 in jdk-24+18 Changes: https://git.openjdk.org/valhalla/pull/1462/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343420 Stats: 17 lines in 2 files changed: 0 ins; 1 del; 16 mod Patch: https://git.openjdk.org/valhalla/pull/1462.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1462/head:pull/1462 PR: https://git.openjdk.org/valhalla/pull/1462 From jbossons at gmail.com Mon May 19 18:15:58 2025 From: jbossons at gmail.com (John Bossons) Date: Mon, 19 May 2025 14:15:58 -0400 Subject: Array fields in value objects Message-ID: The current version of JEP 401 describes the potential flattening of value object array elements, but leaves unspecified the treatment of value object fields that are themselves (immutable) arrays. Some questions: 1) Is a primitive array field (a field that is an array of primitives) necessarily accessed by reference (like an identity object) or can it be accessed as a bit vector (like a scalar primitive)? Example (fixed char array length): value class PostCodeCA { char[] codeValue; // 6-char code, Ascii letter/number chars, could store as byte[] PostCodeCA(String s) { codeValue = s.toCharArray(); // validation code, inter alia checks length == 6 } ... // Note that array elements are immutable because private } Can a PostCodeCA instance be stored as a bit vector, avoiding the indirection of a String reference? 2) Can the following be flattened (apart from the inescapable String ref)? value record AddressCA { String streetAddress, enum provCA, PostCodeCA zipCode } Note that use of the PostCodeCA class ensures the zipCode value is immutable. 3) Does it matter if an array field is of varying length? Example: value class CampaignArea { int areaID; PostCodeCA[] zipCodes; // varying array length, again immutable because private CampaignArea(int areaID, List zipCodes) { ... } ... } Does this class definition potentially permit flattening of a CampaignArea instance? This isn't just about strings, but they illustrate the issue as well as the potential. Also, it would be useful if this could be clarified in the JEP 401 text. John -- Phone: (416) 450-3584 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon May 19 18:20:53 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 May 2025 18:20:53 +0000 Subject: Array fields in value objects In-Reply-To: References: Message-ID: <4C418556-3BDF-4B24-8EE8-E69A52DB3442@oracle.com> Arrays are always identity objects; JEP 401 will not change this. PostCodeCA can be flattened into a single object reference, which is still plenty useful but it won?t flatten the underlying array. > On May 19, 2025, at 2:15 PM, John Bossons wrote: > > The current version of JEP 401 describes the potential flattening of value object array elements, but leaves unspecified the treatment of value object fields that are themselves (immutable) arrays. Some questions: > > 1) Is a primitive array field (a field that is an array of primitives) necessarily accessed by reference (like an identity object) or can it be accessed as a bit vector (like a scalar primitive)? > Example (fixed char array length): > value class PostCodeCA { > char[] codeValue; // 6-char code, Ascii letter/number chars, could store as byte[] > PostCodeCA(String s) { > codeValue = s.toCharArray(); > // validation code, inter alia checks length == 6 > } > ... // Note that array elements are immutable because private > } > Can a PostCodeCA instance be stored as a bit vector, avoiding the indirection of a String reference? > > 2) Can the following be flattened (apart from the inescapable String ref)? > value record AddressCA { String streetAddress, enum provCA, PostCodeCA zipCode } > Note that use of the PostCodeCA class ensures the zipCode value is immutable. > > 3) Does it matter if an array field is of varying length? > Example: > value class CampaignArea { > int areaID; > PostCodeCA[] zipCodes; // varying array length, again immutable because private > CampaignArea(int areaID, List zipCodes) { ... } > ... > } > Does this class definition potentially permit flattening of a CampaignArea instance? > > This isn't just about strings, but they illustrate the issue as well as the potential. Also, it would be useful if this could be clarified in the JEP 401 text. > > John > > -- > Phone: (416) 450-3584 (cell) From jbossons at gmail.com Mon May 19 19:00:41 2025 From: jbossons at gmail.com (John Bossons) Date: Mon, 19 May 2025 15:00:41 -0400 Subject: Array fields in value objects In-Reply-To: <4C418556-3BDF-4B24-8EE8-E69A52DB3442@oracle.com> References: <4C418556-3BDF-4B24-8EE8-E69A52DB3442@oracle.com> Message-ID: Thanks for the clarification. Maybe this is a suggestion for a future JEP (flattening of immutable arrays)? Emphasis on "future". John On Mon, May 19, 2025 at 2:21?PM Brian Goetz wrote: > Arrays are always identity objects; JEP 401 will not change this. > PostCodeCA can be flattened into a single object reference, which is still > plenty useful but it won?t flatten the underlying array. > > > On May 19, 2025, at 2:15 PM, John Bossons wrote: > > > > The current version of JEP 401 describes the potential flattening of > value object array elements, but leaves unspecified the treatment of value > object fields that are themselves (immutable) arrays. Some questions: > > > > 1) Is a primitive array field (a field that is an array of primitives) > necessarily accessed by reference (like an identity object) or can it be > accessed as a bit vector (like a scalar primitive)? > > Example (fixed char array length): > > value class PostCodeCA { > > char[] codeValue; // 6-char code, Ascii letter/number chars, could > store as byte[] > > PostCodeCA(String s) { > > codeValue = s.toCharArray(); > > // validation code, inter alia checks length == 6 > > } > > ... // Note that array elements are immutable because private > > } > > Can a PostCodeCA instance be stored as a bit vector, avoiding the > indirection of a String reference? > > > > 2) Can the following be flattened (apart from the inescapable String > ref)? > > value record AddressCA { String streetAddress, enum provCA, PostCodeCA > zipCode } > > Note that use of the PostCodeCA class ensures the zipCode value is > immutable. > > > > 3) Does it matter if an array field is of varying length? > > Example: > > value class CampaignArea { > > int areaID; > > PostCodeCA[] zipCodes; // varying array length, again immutable > because private > > CampaignArea(int areaID, List zipCodes) { ... } > > ... > > } > > Does this class definition potentially permit flattening of a > CampaignArea instance? > > > > This isn't just about strings, but they illustrate the issue as well as > the potential. Also, it would be useful if this could be clarified in the > JEP 401 text. > > > > John > > > > -- > > Phone: (416) 450-3584 (cell) > > -- Phone: (416) 450-3584 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon May 19 19:10:29 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 May 2025 19:10:29 +0000 Subject: Array fields in value objects In-Reply-To: References: <4C418556-3BDF-4B24-8EE8-E69A52DB3442@oracle.com> Message-ID: That would be a long way into the future :) Right now, arrays are mutable. So, with respect to value-ness, that?s game over. But let?s say we had immutable arrays (which we surely would like to.). The next hurdle is representing the size in the runtime type system, because, to get flattening, we cannot be polymorphic in layout. So the JVM would need to understand `final int[3]` as being a different, concrete, type than `final int[4]`. Pushing dependent types into the descriptor and verifier type system is a big lift ? On May 19, 2025, at 3:00 PM, John Bossons > wrote: Thanks for the clarification. Maybe this is a suggestion for a future JEP (flattening of immutable arrays)? Emphasis on "future". John On Mon, May 19, 2025 at 2:21?PM Brian Goetz > wrote: Arrays are always identity objects; JEP 401 will not change this. PostCodeCA can be flattened into a single object reference, which is still plenty useful but it won?t flatten the underlying array. > On May 19, 2025, at 2:15 PM, John Bossons > wrote: > > The current version of JEP 401 describes the potential flattening of value object array elements, but leaves unspecified the treatment of value object fields that are themselves (immutable) arrays. Some questions: > > 1) Is a primitive array field (a field that is an array of primitives) necessarily accessed by reference (like an identity object) or can it be accessed as a bit vector (like a scalar primitive)? > Example (fixed char array length): > value class PostCodeCA { > char[] codeValue; // 6-char code, Ascii letter/number chars, could store as byte[] > PostCodeCA(String s) { > codeValue = s.toCharArray(); > // validation code, inter alia checks length == 6 > } > ... // Note that array elements are immutable because private > } > Can a PostCodeCA instance be stored as a bit vector, avoiding the indirection of a String reference? > > 2) Can the following be flattened (apart from the inescapable String ref)? > value record AddressCA { String streetAddress, enum provCA, PostCodeCA zipCode } > Note that use of the PostCodeCA class ensures the zipCode value is immutable. > > 3) Does it matter if an array field is of varying length? > Example: > value class CampaignArea { > int areaID; > PostCodeCA[] zipCodes; // varying array length, again immutable because private > CampaignArea(int areaID, List zipCodes) { ... } > ... > } > Does this class definition potentially permit flattening of a CampaignArea instance? > > This isn't just about strings, but they illustrate the issue as well as the potential. Also, it would be useful if this could be clarified in the JEP 401 text. > > John > > -- > Phone: (416) 450-3584 (cell) -- Phone: (416) 450-3584 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbossons at gmail.com Mon May 19 20:23:18 2025 From: jbossons at gmail.com (John Bossons) Date: Mon, 19 May 2025 16:23:18 -0400 Subject: Array fields in value objects In-Reply-To: References: <4C418556-3BDF-4B24-8EE8-E69A52DB3442@oracle.com> Message-ID: That's why I encapsulated the char[6] array in the PostCodeCA class. The immutability is a consequence of the array field being private and final, so that part should be easy to handle. I don't know how it could easily be accomplished other than through encapsulation. With respect to fixing the size, could that be handled by providing an additional term to the field declaration (e.g. "fixed", as in "fixed char[6] codeValue", or even by just "char[6]" without the"fixed")? That would mean the JVM only needs a single tag to know that the field is special and therefore possible to flatten. The compiler would need to verify that the field initialization is correct, but could this not be done by requiring consistency between the field specification and the array constructor size parameter -- or for strings requiring use of a new toCharArray(int size) method? All the compiler needs to do is to check that the constructor/method parameter matches the field specification. Even if this were only done for primitives it would be very useful. Could a limited circumscribed version of this not be done as a "small" lift? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon May 19 21:07:02 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 May 2025 21:07:02 +0000 Subject: Array fields in value objects In-Reply-To: References: <4C418556-3BDF-4B24-8EE8-E69A52DB3442@oracle.com> Message-ID: Except that object layout time is way too early for the JVM to figure out that ?no one could possibly write to this.? The JVM makes layout decisions on the basis of what is evident in the class file ? ACC bits on fields, field descriptors, attributes on fields. If you recall, the descriptor type system is quite limited: carriers for the primitive types (I, J, F, D, etc), carrier for OOPs (Ljava/lang/String), and arrays of one of these types (e.g., [I, [[LString;, etc.). We would have to cram both finality _of elements_ and array size into one of the above channels, and at this point we?re describing a different virtual machine. > On May 19, 2025, at 4:23 PM, John Bossons wrote: > > That's why I encapsulated the char[6] array in the PostCodeCA class. The immutability is a consequence of the array field being private and final, so that part should be easy to handle. I don't know how it could easily be accomplished other than through encapsulation. > > With respect to fixing the size, could that be handled by providing an additional term to the field declaration (e.g. "fixed", as in "fixed char[6] codeValue", or even by just "char[6]" without the"fixed")? That would mean the JVM only needs a single tag to know that the field is special and therefore possible to flatten. > > The compiler would need to verify that the field initialization is correct, but could this not be done by requiring > consistency between the field specification and the array constructor size parameter -- or for strings requiring use of a new toCharArray(int size) method? All the compiler needs to do is to check that the constructor/method parameter matches the field specification. Even if this were only done for primitives it would be very useful. Could a limited circumscribed version of this not be done as a "small" lift? > > John From jbossons at gmail.com Tue May 20 04:28:09 2025 From: jbossons at gmail.com (John Bossons) Date: Tue, 20 May 2025 00:28:09 -0400 Subject: Array fields in value objects In-Reply-To: References: <4C418556-3BDF-4B24-8EE8-E69A52DB3442@oracle.com> Message-ID: Looking for a way to avoid complicating the VM, suppose I rewrite the PostCodeCA class as follows: value class PostCodeCA { byte b0; ... byte b5; PostCodeCA(String s) { byte[] asciiBytes = s.getBytes("US-ASCII"); if (asciiBytes.length != 6) throw exception; // other validation code here b0 = asciiBytes[0]; etc. } // equals, hashCode etc. based on b0 ... b5 } This works and can be flattened, but is rather ugly and laborious. So maybe I'm asking the question the wrong way. Maybe what I should be asking for is a subsequent JEP that (using *record* as a model) gets the compiler to generate detailed code such as the above from a specification like * fixedSmallArray* PostCodeCA { byte[6] asciiBytes } // immutable array thanks to encapsulation Is this a workable idea? (Again, for the future, after value objects are delivered.) The key thought is that the compiler ought to be able to do this without requiring any more modification of the VM than was required for records. It's immutable arrays through the back door. On Mon, May 19, 2025 at 5:07?PM Brian Goetz wrote: > Except that object layout time is way too early for the JVM to figure out > that ?no one could possibly write to this.? The JVM makes layout decisions > on the basis of what is evident in the class file ? ACC bits on fields, > field descriptors, attributes on fields. > > If you recall, the descriptor type system is quite limited: carriers for > the primitive types (I, J, F, D, etc), carrier for OOPs > (Ljava/lang/String), and arrays of one of these types (e.g., [I, > [[LString;, etc.). We would have to cram both finality _of elements_ and > array size into one of the above channels, and at this point we?re > describing a different virtual machine. > > > On May 19, 2025, at 4:23 PM, John Bossons wrote: > > > > That's why I encapsulated the char[6] array in the PostCodeCA class. The > immutability is a consequence of the array field being private and final, > so that part should be easy to handle. I don't know how it could easily be > accomplished other than through encapsulation. > > > > With respect to fixing the size, could that be handled by providing an > additional term to the field declaration (e.g. "fixed", as in "fixed > char[6] codeValue", or even by just "char[6]" without the"fixed")? That > would mean the JVM only needs a single tag to know that the field is > special and therefore possible to flatten. > > > > The compiler would need to verify that the field initialization is > correct, but could this not be done by requiring > > consistency between the field specification and the array constructor > size parameter -- or for strings requiring use of a new toCharArray(int > size) method? All the compiler needs to do is to check that the > constructor/method parameter matches the field specification. Even if this > were only done for primitives it would be very useful. Could a limited > circumscribed version of this not be done as a "small" lift? > > > > John > > -- Phone: (416) 450-3584 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: From thartmann at openjdk.org Tue May 20 06:38:05 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 20 May 2025 06:38:05 GMT Subject: [lworld] RFR: 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" [v4] In-Reply-To: References: Message-ID: On Sun, 18 May 2025 07:08:43 GMT, Quan Anh Mai wrote: >> Many thanks to @TobiHartmann for the speedy investigation. This patch fixes the issue by adding a `ciField` for the null marker. I also do a small change to make the name of the `ciField` of a flattened field clearer. I think adding a scenario to test flattening of nullable and atomic fields is necessary. There are some failures that I filed https://bugs.openjdk.org/browse/JDK-8357061 for the investigation. >> >> Please kindly review, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > fix SigEntry comparison Testing all passed. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1456#issuecomment-2893127747 From qamai at openjdk.org Tue May 20 07:02:03 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 20 May 2025 07:02:03 GMT Subject: [lworld] RFR: 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" [v4] In-Reply-To: References: Message-ID: On Sun, 18 May 2025 07:08:43 GMT, Quan Anh Mai wrote: >> Many thanks to @TobiHartmann for the speedy investigation. This patch fixes the issue by adding a `ciField` for the null marker. I also do a small change to make the name of the `ciField` of a flattened field clearer. I think adding a scenario to test flattening of nullable and atomic fields is necessary. There are some failures that I filed https://bugs.openjdk.org/browse/JDK-8357061 for the investigation. >> >> Please kindly review, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > fix SigEntry comparison Thanks for your reviews! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1456#issuecomment-2893186488 From duke at openjdk.org Tue May 20 07:02:03 2025 From: duke at openjdk.org (duke) Date: Tue, 20 May 2025 07:02:03 GMT Subject: [lworld] RFR: 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" [v4] In-Reply-To: References: Message-ID: On Sun, 18 May 2025 07:08:43 GMT, Quan Anh Mai wrote: >> Many thanks to @TobiHartmann for the speedy investigation. This patch fixes the issue by adding a `ciField` for the null marker. I also do a small change to make the name of the `ciField` of a flattened field clearer. I think adding a scenario to test flattening of nullable and atomic fields is necessary. There are some failures that I filed https://bugs.openjdk.org/browse/JDK-8357061 for the investigation. >> >> Please kindly review, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > fix SigEntry comparison @merykitty Your change (at version c7194bf3ecd4c4969838276365dfa8d606b7737c) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1456#issuecomment-2893187473 From qamai at openjdk.org Tue May 20 08:17:06 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 20 May 2025 08:17:06 GMT Subject: [lworld] Integrated: 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" In-Reply-To: References: Message-ID: On Thu, 15 May 2025 16:40:57 GMT, Quan Anh Mai wrote: > Many thanks to @TobiHartmann for the speedy investigation. This patch fixes the issue by adding a `ciField` for the null marker. I also do a small change to make the name of the `ciField` of a flattened field clearer. I think adding a scenario to test flattening of nullable and atomic fields is necessary. There are some failures that I filed https://bugs.openjdk.org/browse/JDK-8357061 for the investigation. > > Please kindly review, thanks a lot. This pull request has now been integrated. Changeset: 8f0e6242 Author: Quan Anh Mai Committer: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/8f0e62420a27bd0d577da59474fb6936299f775c Stats: 246 lines in 20 files changed: 126 ins; 68 del; 52 mod 8356963: [lworld] MemNode::optimize_simple_memory_chain fails with "sanity check for basic cases" Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1456 From thartmann at openjdk.org Tue May 20 08:18:04 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 20 May 2025 08:18:04 GMT Subject: [lworld] RFR: 8343420: [lworld] compiler/gcbarriers/TestG1BarrierGeneration.java after merging JDK-8334060 in jdk-24+18 In-Reply-To: References: Message-ID: On Mon, 19 May 2025 11:00:19 GMT, Damon Fenacci wrote: > `TestG1BarrierGeneration.testGetAndSet*` tests fail after [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569). These tests check that `VarHandle::getAndSet` with G1 a particular `GetAndSetP` or `GetAndSetN` node is created with a barrier before and after. > [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) refactored `Unsafe::getAndSet` (which is used by `VarHandle::getAndSet`) to take value-classes into account, which implies that checks must be introduced to see if the target and argument objects are value-classes. This is done with a new overloaded `getAndSet` method that is now called instead of the old one. This method is not intrinsified (only inlined) and doesn't result in a `GetAndSet` node. It instead relies on the `compareAndSet` method (which gets intrinsified) and results in a `CompareAndSwap` node. > > As the goal of the test is mainly to check for G1 barrier creation, the sensible fix for now seems to be to modify the `TestG1BarrierGeneration.testGetAndSet*` tests to make them check for `CompareAndSwap` instead of `GetAndSet` nodes. Thanks for investigating this Damon! The fix looks good to me. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1462#pullrequestreview-2853159616 From thartmann at openjdk.org Tue May 20 09:31:20 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 20 May 2025 09:31:20 GMT Subject: [lworld] RFR: 8357156: [lworld] ValueClass.newNullRestrictedAtomicArray and newNullableAtomicArray do not respect FlatArrayElementMaxOops Message-ID: `ValueClass.newNullRestrictedAtomicArray` and `ValueClass.newNullableAtomicArray ` should respect `-XX:FlatArrayElementMaxOops` when deciding if an array should be flat or not. Thanks, Tobias ------------- Commit messages: - Merge branch 'lworld' into JDK-8357156 - Test Changes: https://git.openjdk.org/valhalla/pull/1463/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1463&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357156 Stats: 82 lines in 2 files changed: 79 ins; 0 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1463.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1463/head:pull/1463 PR: https://git.openjdk.org/valhalla/pull/1463 From thartmann at openjdk.org Tue May 20 13:10:13 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 20 May 2025 13:10:13 GMT Subject: [lworld] Integrated: 8357156: [lworld] ValueClass.newNullRestrictedAtomicArray and newNullableAtomicArray do not respect FlatArrayElementMaxOops In-Reply-To: References: Message-ID: On Tue, 20 May 2025 09:26:56 GMT, Tobias Hartmann wrote: > `ValueClass.newNullRestrictedAtomicArray` and `ValueClass.newNullableAtomicArray ` should respect `-XX:FlatArrayElementMaxOops` when deciding if an array should be flat or not. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 70dacbac Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/70dacbacc3ad351b98455004263f8ec1891db6af Stats: 82 lines in 2 files changed: 79 ins; 0 del; 3 mod 8357156: [lworld] ValueClass.newNullRestrictedAtomicArray and newNullableAtomicArray do not respect FlatArrayElementMaxOops ------------- PR: https://git.openjdk.org/valhalla/pull/1463 From archie.cobbs at gmail.com Tue May 20 13:52:11 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 20 May 2025 08:52:11 -0500 Subject: Array fields in value objects In-Reply-To: References: <4C418556-3BDF-4B24-8EE8-E69A52DB3442@oracle.com> Message-ID: On Mon, May 19, 2025 at 11:28?PM John Bossons wrote: > This works and can be flattened, but is rather ugly and laborious. So > maybe I'm asking the question the wrong way. Maybe what I should be asking > for is a subsequent JEP that (using *record* as a model) gets the > compiler to generate detailed code such as the above from a specification > like > > * fixedSmallArray* PostCodeCA { byte[6] asciiBytes } // immutable > array thanks to encapsulation > I had the same thought, but if this is your goal I see the implication differently: this is now "just" an optimization opportunity. You could write a bytecode transformation that looks for array fields that are private, final, non-escaping, never modified, and have a length known at compile time and automatically "inlines" them (surely such a thing already exists?). Or, the JVM could be enhanced to do this at runtime. Either way, there is no need any more for a JEP or language change. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Tue May 20 14:24:19 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 20 May 2025 14:24:19 +0000 Subject: Array fields in value objects In-Reply-To: References: <4C418556-3BDF-4B24-8EE8-E69A52DB3442@oracle.com> Message-ID: <3A2D0870-4847-4D9B-A4F1-39E8A16822A6@oracle.com> I think this is pushing on the short end of the lever; it?s a heroic, narrow, brittle (expensive!) optimization for a narrow outcome. I have a hard time believing we would ever run out of opportunities to invest in higher-leverage activities. This is, at root, a layout specialization problem, similar to specializing instantiated generic types such as Pair; investing in that seems likely to be higher-leverage for the imaginable future. On May 20, 2025, at 12:28 AM, John Bossons > wrote: Looking for a way to avoid complicating the VM, suppose I rewrite the PostCodeCA class as follows: value class PostCodeCA { byte b0; ... byte b5; PostCodeCA(String s) { byte[] asciiBytes = s.getBytes("US-ASCII"); if (asciiBytes.length != 6) throw exception; // other validation code here b0 = asciiBytes[0]; etc. } // equals, hashCode etc. based on b0 ... b5 } This works and can be flattened, but is rather ugly and laborious. So maybe I'm asking the question the wrong way. Maybe what I should be asking for is a subsequent JEP that (using record as a model) gets the compiler to generate detailed code such as the above from a specification like fixedSmallArray PostCodeCA { byte[6] asciiBytes } // immutable array thanks to encapsulation Is this a workable idea? (Again, for the future, after value objects are delivered.) The key thought is that the compiler ought to be able to do this without requiring any more modification of the VM than was required for records. It's immutable arrays through the back door. On Mon, May 19, 2025 at 5:07?PM Brian Goetz > wrote: Except that object layout time is way too early for the JVM to figure out that ?no one could possibly write to this.? The JVM makes layout decisions on the basis of what is evident in the class file ? ACC bits on fields, field descriptors, attributes on fields. If you recall, the descriptor type system is quite limited: carriers for the primitive types (I, J, F, D, etc), carrier for OOPs (Ljava/lang/String), and arrays of one of these types (e.g., [I, [[LString;, etc.). We would have to cram both finality _of elements_ and array size into one of the above channels, and at this point we?re describing a different virtual machine. > On May 19, 2025, at 4:23 PM, John Bossons > wrote: > > That's why I encapsulated the char[6] array in the PostCodeCA class. The immutability is a consequence of the array field being private and final, so that part should be easy to handle. I don't know how it could easily be accomplished other than through encapsulation. > > With respect to fixing the size, could that be handled by providing an additional term to the field declaration (e.g. "fixed", as in "fixed char[6] codeValue", or even by just "char[6]" without the"fixed")? That would mean the JVM only needs a single tag to know that the field is special and therefore possible to flatten. > > The compiler would need to verify that the field initialization is correct, but could this not be done by requiring > consistency between the field specification and the array constructor size parameter -- or for strings requiring use of a new toCharArray(int size) method? All the compiler needs to do is to check that the constructor/method parameter matches the field specification. Even if this were only done for primitives it would be very useful. Could a limited circumscribed version of this not be done as a "small" lift? > > John -- Phone: (416) 450-3584 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: From thartmann at openjdk.org Tue May 20 16:40:36 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 20 May 2025 16:40:36 GMT Subject: [lworld] RFR: 8357384: [lworld] AnnotationsTests.java fails if UseNullableValueFlattening is enabled by default Message-ID: <2Z3WGhHnc2G-XTXwtE_Rw2cKCH6JOMmL0ps1KFi-4o8=.d831b854-4896-4059-b10f-60e0e1a28255@github.com> Test only checks if `UseNullableValueFlattening` is set via the command line and fails if it's set by default. Thanks, Tobias ------------- Commit messages: - 8357384: [lworld] AnnotationsTests.java fails if UseNullableValueFlattening is enabled by default Changes: https://git.openjdk.org/valhalla/pull/1464/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1464&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357384 Stats: 16 lines in 1 file changed: 3 ins; 7 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/1464.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1464/head:pull/1464 PR: https://git.openjdk.org/valhalla/pull/1464 From matsaave at openjdk.org Tue May 20 22:20:30 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 20 May 2025 22:20:30 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) Message-ID: This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. ------------- Commit messages: - Added tests - 8349945: Implement strict static fields (proposed JVM feature) Changes: https://git.openjdk.org/valhalla/pull/1465/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1465&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349945 Stats: 791 lines in 31 files changed: 763 ins; 1 del; 27 mod Patch: https://git.openjdk.org/valhalla/pull/1465.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1465/head:pull/1465 PR: https://git.openjdk.org/valhalla/pull/1465 From thartmann at openjdk.org Wed May 21 05:10:06 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 21 May 2025 05:10:06 GMT Subject: [lworld] Integrated: 8357384: [lworld] AnnotationsTests.java fails if UseNullableValueFlattening is enabled by default In-Reply-To: <2Z3WGhHnc2G-XTXwtE_Rw2cKCH6JOMmL0ps1KFi-4o8=.d831b854-4896-4059-b10f-60e0e1a28255@github.com> References: <2Z3WGhHnc2G-XTXwtE_Rw2cKCH6JOMmL0ps1KFi-4o8=.d831b854-4896-4059-b10f-60e0e1a28255@github.com> Message-ID: On Tue, 20 May 2025 16:35:50 GMT, Tobias Hartmann wrote: > Test only checks if `UseNullableValueFlattening` is set via the command line and fails if it's set by default. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 619da98d Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/619da98d0313fef419afdde2f31b7cdf438cd508 Stats: 16 lines in 1 file changed: 3 ins; 7 del; 6 mod 8357384: [lworld] AnnotationsTests.java fails if UseNullableValueFlattening is enabled by default ------------- PR: https://git.openjdk.org/valhalla/pull/1464 From thartmann at openjdk.org Wed May 21 06:06:36 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 21 May 2025 06:06:36 GMT Subject: [lworld] Integrated: 8357410: [lworld] Disable UseAtomicValueFlattening in ObjectMethods until JDK-8357373 is fixed Message-ID: Setting `-XX:-UseAtomicValueFlattening` until [JDK-8357373](https://bugs.openjdk.org/browse/JDK-8357373) is fixed. Thanks, Tobias ------------- Commit messages: - 8357410: [lworld] Disable UseAtomicValueFlattening in ObjectMethods until JDK-8357373 is fixed Changes: https://git.openjdk.org/valhalla/pull/1466/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1466&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357410 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1466.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1466/head:pull/1466 PR: https://git.openjdk.org/valhalla/pull/1466 From thartmann at openjdk.org Wed May 21 06:06:36 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 21 May 2025 06:06:36 GMT Subject: [lworld] Integrated: 8357410: [lworld] Disable UseAtomicValueFlattening in ObjectMethods until JDK-8357373 is fixed In-Reply-To: References: Message-ID: On Wed, 21 May 2025 06:01:55 GMT, Tobias Hartmann wrote: > Setting `-XX:-UseAtomicValueFlattening` until [JDK-8357373](https://bugs.openjdk.org/browse/JDK-8357373) is fixed. > > Thanks, > Tobias This pull request has now been integrated. Changeset: fcf64258 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/fcf642589be571c89642790b9a50274d769dc598 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8357410: [lworld] Disable UseAtomicValueFlattening in ObjectMethods until JDK-8357373 is fixed ------------- PR: https://git.openjdk.org/valhalla/pull/1466 From dsimms at openjdk.org Wed May 21 07:20:59 2025 From: dsimms at openjdk.org (David Simms) Date: Wed, 21 May 2025 07:20:59 GMT Subject: [lworld] RFR: Merge jdk [v3] In-Reply-To: References: Message-ID: > Merge tag 'jdk-25+19' into lworld_merge_jdk_25_19 > Added tag jdk-25+19 for changeset a71f621a David Simms has updated the pull request incrementally with one additional commit since the last revision: More logical merge fixes ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1459/files - new: https://git.openjdk.org/valhalla/pull/1459/files/f6641902..d4d9c61b Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1459&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1459&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1459.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1459/head:pull/1459 PR: https://git.openjdk.org/valhalla/pull/1459 From dsimms at openjdk.org Wed May 21 07:21:00 2025 From: dsimms at openjdk.org (David Simms) Date: Wed, 21 May 2025 07:21:00 GMT Subject: [lworld] RFR: Merge jdk [v2] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 09:39:51 GMT, David Simms wrote: >> Merge tag 'jdk-25+19' into lworld_merge_jdk_25_19 >> Added tag jdk-25+19 for changeset a71f621a > > David Simms has updated the pull request incrementally with 134 additional commits since the last revision: > > - Logical Merge Fixes > - Merge tag 'jdk-25+20' into lworld_merge_jdk_25_19 > > Added tag jdk-25+20 for changeset 953eef4f > - 8347337: ZGC: String dedups short-lived strings > > Reviewed-by: kbarrett, aboldtch, eosterlund > - 8348928: Check for case label validity are misbehaving when binding patterns with unnamed bindings are present > > Reviewed-by: asotona, abimpoudis, vromero > - 8353558: x86: Use better instructions for ICache sync when available > > Reviewed-by: kvn, adinn > - 8353216: Improve VerifyMethodHandles for method handle linkers > > Reviewed-by: dlong > - 8354558: -XX:AOTMode=record crashes with boot loader package-info class > > Reviewed-by: ccheung, matsaave > - 8354553: Open source several clipboard tests batch0 > > Reviewed-by: serb, prr > - 8353596: GenShen: Test TestClone.java#generational-no-coops intermittent timed out > > Reviewed-by: kdnilsen, ysr > - 8354554: Open source several clipboard tests batch1 > > Reviewed-by: serb, prr > - ... and 124 more: https://git.openjdk.org/valhalla/compare/83961a81...f6641902 Missing set_vm_result_oop changes on platforms other than x86 ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1459#issuecomment-2886219427 From dsimms at openjdk.org Wed May 21 07:21:02 2025 From: dsimms at openjdk.org (David Simms) Date: Wed, 21 May 2025 07:21:02 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: On Fri, 16 May 2025 08:18:47 GMT, David Simms wrote: > Merge tag 'jdk-25+19' into lworld_merge_jdk_25_19 > Added tag jdk-25+19 for changeset a71f621a This pull request has now been integrated. Changeset: 8c53ea5e Author: David Simms URL: https://git.openjdk.org/valhalla/commit/8c53ea5e2328406210490b1ebcd467ebb04b8104 Stats: 238986 lines in 1612 files changed: 55235 ins; 178869 del; 4882 mod Merge jdk Merge jdk-25+19 and jdk-25+20 ------------- PR: https://git.openjdk.org/valhalla/pull/1459 From dsimms at openjdk.org Wed May 21 08:58:40 2025 From: dsimms at openjdk.org (David Simms) Date: Wed, 21 May 2025 08:58:40 GMT Subject: [lworld] RFR: 8354366: [lworld] VirtualObjectDebugInfoTest fails after merging jdk-25+16 Message-ID: Partially undo JDK-8350892, specifically field sorting ------------- Commit messages: - [lworld] VirtualObjectDebugInfoTest fails after merging jdk-25+16 Changes: https://git.openjdk.org/valhalla/pull/1430/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1430&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354366 Stats: 10 lines in 2 files changed: 9 ins; 1 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1430.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1430/head:pull/1430 PR: https://git.openjdk.org/valhalla/pull/1430 From liach at openjdk.org Wed May 21 08:59:04 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 08:59:04 GMT Subject: [lworld] Integrated: 8357054: [lworld] tools/javac/valhalla/value-objects/ test still using com.sun.tools.classfile In-Reply-To: References: Message-ID: <5L8fWAehsO2YkDSNrQX_NXXv8DcJTNZCYbZBgIN4oEA=.ae98acfc-a3ec-458b-87c3-f00a4a25e11a@github.com> On Thu, 15 May 2025 18:31:03 GMT, Chen Liang wrote: > Did not notice these old classfile tests. Required for upgrading to latest mainline. This pull request has now been integrated. Changeset: 79de8f45 Author: Chen Liang Committer: David Simms URL: https://git.openjdk.org/valhalla/commit/79de8f456f129d931e97dd7df94e88fd61d6e870 Stats: 121 lines in 5 files changed: 18 ins; 37 del; 66 mod 8357054: [lworld] tools/javac/valhalla/value-objects/ test still using com.sun.tools.classfile ------------- PR: https://git.openjdk.org/valhalla/pull/1458 From dsimms at openjdk.org Wed May 21 09:15:58 2025 From: dsimms at openjdk.org (David Simms) Date: Wed, 21 May 2025 09:15:58 GMT Subject: [lworld] RFR: 8354366: [lworld] VirtualObjectDebugInfoTest fails after merging jdk-25+16 [v2] In-Reply-To: References: Message-ID: > Partially undo JDK-8350892, specifically field sorting David Simms has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'lworld' into 8354366 - [lworld] VirtualObjectDebugInfoTest fails after merging jdk-25+16 ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1430/files - new: https://git.openjdk.org/valhalla/pull/1430/files/e3751439..779341a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1430&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1430&range=00-01 Stats: 301398 lines in 2756 files changed: 88436 ins; 203565 del; 9397 mod Patch: https://git.openjdk.org/valhalla/pull/1430.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1430/head:pull/1430 PR: https://git.openjdk.org/valhalla/pull/1430 From dsimms at openjdk.org Wed May 21 11:36:43 2025 From: dsimms at openjdk.org (David Simms) Date: Wed, 21 May 2025 11:36:43 GMT Subject: [lworld] Integrated: 8357454: [lworld] trivial: removed modules still named in LoadableDescriptorsAttrTest2 & ValueBasedFlagsTest Message-ID: Removed old module directives ------------- Commit messages: - 8357454: [lworld] trivial: removed modules still named in LoadableDescriptorsAttrTest2 & ValueBasedFlagsTest Changes: https://git.openjdk.org/valhalla/pull/1467/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1467&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357454 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1467.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1467/head:pull/1467 PR: https://git.openjdk.org/valhalla/pull/1467 From dsimms at openjdk.org Wed May 21 11:36:43 2025 From: dsimms at openjdk.org (David Simms) Date: Wed, 21 May 2025 11:36:43 GMT Subject: [lworld] Integrated: 8357454: [lworld] trivial: removed modules still named in LoadableDescriptorsAttrTest2 & ValueBasedFlagsTest In-Reply-To: References: Message-ID: On Wed, 21 May 2025 11:28:14 GMT, David Simms wrote: > Removed old module directives This pull request has now been integrated. Changeset: 889e1581 Author: David Simms URL: https://git.openjdk.org/valhalla/commit/889e1581ed644c18afcf5b007d95fbd85e56ebba Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod 8357454: [lworld] trivial: removed modules still named in LoadableDescriptorsAttrTest2 & ValueBasedFlagsTest ------------- PR: https://git.openjdk.org/valhalla/pull/1467 From thartmann at openjdk.org Wed May 21 12:06:30 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 21 May 2025 12:06:30 GMT Subject: [lworld] Integrated: [lworld] Some more problem listing for JDK-8348972 Message-ID: Test currently fails. Will be fixed and re-enabled with [JDK-8348568](https://bugs.openjdk.org/browse/JDK-8348568). Thanks, Tobias ------------- Commit messages: - [lworld] Some more problem listing for JDK-8348972 Changes: https://git.openjdk.org/valhalla/pull/1468/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1468&range=00 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1468.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1468/head:pull/1468 PR: https://git.openjdk.org/valhalla/pull/1468 From thartmann at openjdk.org Wed May 21 12:06:30 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 21 May 2025 12:06:30 GMT Subject: [lworld] Integrated: [lworld] Some more problem listing for JDK-8348972 In-Reply-To: References: Message-ID: <5d7Tt1FmsF-wXr9DwB548R_JYc31j5l0o0P2IK9uD-A=.47594c45-0e39-44eb-bbb5-2bc4fcc413d7@github.com> On Wed, 21 May 2025 12:02:15 GMT, Tobias Hartmann wrote: > Test currently fails. Will be fixed and re-enabled with [JDK-8348568](https://bugs.openjdk.org/browse/JDK-8348568). > > Thanks, > Tobias This pull request has now been integrated. Changeset: 90c987ae Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/90c987ae759446da5f0d24645ecb7e58220fdfa6 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod [lworld] Some more problem listing for JDK-8348972 ------------- PR: https://git.openjdk.org/valhalla/pull/1468 From thartmann at openjdk.org Wed May 21 12:39:21 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 21 May 2025 12:39:21 GMT Subject: [lworld] RFR: 8357461: [lworld] TestFlatInArraysFolding.java fails with UseNullableValueFlattening enabled by default Message-ID: The test expects folding of `arrayElement == oArr` in the flat array array loop version which does not happen anymore when the flat array element can be null with `-XX:+UseNullableValueFlattening` (because `oArr` can be null as well). I adjusted the test so that C2 can deduce that `oArr` is never null and can therefore fold the check. Thanks, Tobias ------------- Commit messages: - 8357461: [lworld] TestFlatInArraysFolding.java fails with UseNullableValueFlattening enabled by default Changes: https://git.openjdk.org/valhalla/pull/1469/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1469&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357461 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1469.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1469/head:pull/1469 PR: https://git.openjdk.org/valhalla/pull/1469 From thartmann at openjdk.org Wed May 21 12:45:10 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 21 May 2025 12:45:10 GMT Subject: [lworld] Integrated: 8357461: [lworld] TestFlatInArraysFolding.java fails with UseNullableValueFlattening enabled by default In-Reply-To: References: Message-ID: On Wed, 21 May 2025 12:34:21 GMT, Tobias Hartmann wrote: > The test expects folding of `arrayElement == oArr` in the flat array array loop version which does not happen anymore when the flat array element can be null with `-XX:+UseNullableValueFlattening` (because `oArr` can be null as well). I adjusted the test so that C2 can deduce that `oArr` is never null and can therefore fold the check. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 8580a4ee Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/8580a4eea6d533512b1e5d6e115c03fc0fcc773a Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8357461: [lworld] TestFlatInArraysFolding.java fails with UseNullableValueFlattening enabled by default ------------- PR: https://git.openjdk.org/valhalla/pull/1469 From matsaave at openjdk.org Wed May 21 14:13:06 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 21 May 2025 14:13:06 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v3] In-Reply-To: References: Message-ID: <9_cXJebnRt4G-kplhhOKtKxMyGZS3RkCrtOxlSyegx8=.af3b678a-0429-4d3e-9ed5-95e831f58cda@github.com> > Updates to javac prevent it from creating classes with improper uses of strict fields. Additionally, non-final strict fields are now allowed so `StrictFinalInstanceFieldsTest.java` needs to updated with new test cases. This patch adds new cases for final and non-final stricts as well as negative test cases using asmtools that check improper use of strict fields and early larval stack map frames. > > During testing, it was revealed that the new verify errors added in [JDK-8354694](https://bugs.openjdk.org/browse/JDK-8354694) do not work properly so a fix is included in this patch. > > Note: This cannot be integrated until jtreg is updated with a recent build of asmtools which can handle strict fields and can generate early_larval frames. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Added bug number to problem listed test ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1449/files - new: https://git.openjdk.org/valhalla/pull/1449/files/86fcbf48..9dfa4d41 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1449&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1449&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1449.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1449/head:pull/1449 PR: https://git.openjdk.org/valhalla/pull/1449 From matsaave at openjdk.org Wed May 21 14:44:50 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 21 May 2025 14:44:50 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v4] In-Reply-To: References: Message-ID: <8sbj-SGuIXuLwGqBMuR_7aOzGgJ-GAcvEg0pJ5VsgG8=.cd427457-7d61-4d8f-b443-701e338128df@github.com> > Updates to javac prevent it from creating classes with improper uses of strict fields. Additionally, non-final strict fields are now allowed so `StrictFinalInstanceFieldsTest.java` needs to updated with new test cases. This patch adds new cases for final and non-final stricts as well as negative test cases using asmtools that check improper use of strict fields and early larval stack map frames. > > During testing, it was revealed that the new verify errors added in [JDK-8354694](https://bugs.openjdk.org/browse/JDK-8354694) do not work properly so a fix is included in this patch. > > Note: This cannot be integrated until jtreg is updated with a recent build of asmtools which can handle strict fields and can generate early_larval frames. 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 seven commits: - Merge branch 'lworld' into new_strict_tests_8352068 - Added bug number to problem listed test - Problem list test until jtreg is updated - Remove old test - Added copyright - Added more positive test cases - [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 ------------- Changes: https://git.openjdk.org/valhalla/pull/1449/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1449&range=03 Stats: 1844 lines in 11 files changed: 1582 ins; 262 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1449.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1449/head:pull/1449 PR: https://git.openjdk.org/valhalla/pull/1449 From qamai at openjdk.org Wed May 21 16:12:24 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 21 May 2025 16:12:24 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types Message-ID: Hi, This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: value class StringHolder { @NullRestricted String s; } value class StringHolderHolder { // flatten StringHolder v; } Then `v.s` cannot be trusted to be non-null because `v` can be null. This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. Please let me know what you think. Thanks very much. ------------- Commit messages: - add tests - Consolidate load/store of flat values Changes: https://git.openjdk.org/valhalla/pull/1470/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357474 Stats: 743 lines in 10 files changed: 330 ins; 261 del; 152 mod Patch: https://git.openjdk.org/valhalla/pull/1470.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1470/head:pull/1470 PR: https://git.openjdk.org/valhalla/pull/1470 From qamai at openjdk.org Wed May 21 16:39:50 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 21 May 2025 16:39:50 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v2] In-Reply-To: References: Message-ID: > Hi, > > This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: > > - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. > - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. > - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: > > value class StringHolder { > @NullRestricted > String s; > } > > value class StringHolderHolder { > // flatten > StringHolder v; > } > > Then `v.s` cannot be trusted to be non-null because `v` can be null. > > This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. > > Please let me know what you think. Thanks very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: convert_from_payload ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1470/files - new: https://git.openjdk.org/valhalla/pull/1470/files/09d4ddab..8173ef24 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=00-01 Stats: 13 lines in 2 files changed: 3 ins; 1 del; 9 mod Patch: https://git.openjdk.org/valhalla/pull/1470.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1470/head:pull/1470 PR: https://git.openjdk.org/valhalla/pull/1470 From liach at openjdk.org Wed May 21 18:55:03 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 18:55:03 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) In-Reply-To: References: Message-ID: On Tue, 20 May 2025 22:15:29 GMT, Matias Saavedra Silva wrote: > This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. test/hotspot/jtreg/runtime/valhalla/inlinetypes/verifier/Brbefore_BAD.jasm line 24: > 22: */ > 23: > 24: identity class Brbefore_BAD version 69:65535 Can't this be compiled with javac? I don't think we are going to add any checks for strict initialization on the javac side as pre-write reads cannot be detected because they can easily happen in nested method calls. Even if we decide to use jasm, I think the best practice seems to leave the source to generate the jasm in a .test file, and comment in the jasm what was changed. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1465#discussion_r2100957443 From fparain at openjdk.org Wed May 21 21:18:38 2025 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 21 May 2025 21:18:38 GMT Subject: [lworld] RFR: 8357508: [lworld] build with CDS disabled is broken Message-ID: Fix build when CDS is disabled. ------------- Commit messages: - Fix no CDS build Changes: https://git.openjdk.org/valhalla/pull/1471/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1471&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357508 Stats: 19 lines in 5 files changed: 7 ins; 5 del; 7 mod Patch: https://git.openjdk.org/valhalla/pull/1471.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1471/head:pull/1471 PR: https://git.openjdk.org/valhalla/pull/1471 From qamai at openjdk.org Thu May 22 05:56:47 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 22 May 2025 05:56:47 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v3] In-Reply-To: References: Message-ID: > Hi, > > This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: > > - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. > - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. > - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: > > value class StringHolder { > @NullRestricted > String s; > } > > value class StringHolderHolder { > // flatten > StringHolder v; > } > > Then `v.s` cannot be trusted to be non-null because `v` can be null. > > This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. > > Please let me know what you think. Thanks very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: array ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1470/files - new: https://git.openjdk.org/valhalla/pull/1470/files/8173ef24..99d2269a Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=01-02 Stats: 22 lines in 3 files changed: 15 ins; 2 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1470.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1470/head:pull/1470 PR: https://git.openjdk.org/valhalla/pull/1470 From dfenacci at openjdk.org Thu May 22 06:43:14 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Thu, 22 May 2025 06:43:14 GMT Subject: [lworld] RFR: 8343420: [lworld] compiler/gcbarriers/TestG1BarrierGeneration.java after merging JDK-8334060 in jdk-24+18 In-Reply-To: References: Message-ID: On Tue, 20 May 2025 08:15:25 GMT, Tobias Hartmann wrote: >> `TestG1BarrierGeneration.testGetAndSet*` tests fail after [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569). These tests check that `VarHandle::getAndSet` with G1 a particular `GetAndSetP` or `GetAndSetN` node is created with a barrier before and after. >> [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) refactored `Unsafe::getAndSet` (which is used by `VarHandle::getAndSet`) to take value-classes into account, which implies that checks must be introduced to see if the target and argument objects are value-classes. This is done with a new overloaded `getAndSet` method that is now called instead of the old one. This method is not intrinsified (only inlined) and doesn't result in a `GetAndSet` node. It instead relies on the `compareAndSet` method (which gets intrinsified) and results in a `CompareAndSwap` node. >> >> As the goal of the test is mainly to check for G1 barrier creation, the sensible fix for now seems to be to modify the `TestG1BarrierGeneration.testGetAndSet*` tests to make them check for `CompareAndSwap` instead of `GetAndSet` nodes. > > Thanks for investigating this Damon! The fix looks good to me. Thanks for the review @TobiHartmann! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1462#issuecomment-2900086773 From duke at openjdk.org Thu May 22 06:43:14 2025 From: duke at openjdk.org (duke) Date: Thu, 22 May 2025 06:43:14 GMT Subject: [lworld] RFR: 8343420: [lworld] compiler/gcbarriers/TestG1BarrierGeneration.java after merging JDK-8334060 in jdk-24+18 In-Reply-To: References: Message-ID: <9S-0j09qIJbR3y8rCR2kW8WuigArn0Sk3hDZl-uFoYI=.510ce050-2e9a-4693-a6a2-f9075279ae81@github.com> On Mon, 19 May 2025 11:00:19 GMT, Damon Fenacci wrote: > `TestG1BarrierGeneration.testGetAndSet*` tests fail after [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569). These tests check that `VarHandle::getAndSet` with G1 a particular `GetAndSetP` or `GetAndSetN` node is created with a barrier before and after. > [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) refactored `Unsafe::getAndSet` (which is used by `VarHandle::getAndSet`) to take value-classes into account, which implies that checks must be introduced to see if the target and argument objects are value-classes. This is done with a new overloaded `getAndSet` method that is now called instead of the old one. This method is not intrinsified (only inlined) and doesn't result in a `GetAndSet` node. It instead relies on the `compareAndSet` method (which gets intrinsified) and results in a `CompareAndSwap` node. > > As the goal of the test is mainly to check for G1 barrier creation, the sensible fix for now seems to be to modify the `TestG1BarrierGeneration.testGetAndSet*` tests to make them check for `CompareAndSwap` instead of `GetAndSet` nodes. @dafedafe Your change (at version 74bbcc12ac4770b448fa01eac1de5e3f6f4a03bc) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1462#issuecomment-2900090333 From dfenacci at openjdk.org Thu May 22 06:48:03 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Thu, 22 May 2025 06:48:03 GMT Subject: [lworld] Integrated: 8343420: [lworld] compiler/gcbarriers/TestG1BarrierGeneration.java after merging JDK-8334060 in jdk-24+18 In-Reply-To: References: Message-ID: On Mon, 19 May 2025 11:00:19 GMT, Damon Fenacci wrote: > `TestG1BarrierGeneration.testGetAndSet*` tests fail after [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569). These tests check that `VarHandle::getAndSet` with G1 a particular `GetAndSetP` or `GetAndSetN` node is created with a barrier before and after. > [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) refactored `Unsafe::getAndSet` (which is used by `VarHandle::getAndSet`) to take value-classes into account, which implies that checks must be introduced to see if the target and argument objects are value-classes. This is done with a new overloaded `getAndSet` method that is now called instead of the old one. This method is not intrinsified (only inlined) and doesn't result in a `GetAndSet` node. It instead relies on the `compareAndSet` method (which gets intrinsified) and results in a `CompareAndSwap` node. > > As the goal of the test is mainly to check for G1 barrier creation, the sensible fix for now seems to be to modify the `TestG1BarrierGeneration.testGetAndSet*` tests to make them check for `CompareAndSwap` instead of `GetAndSet` nodes. This pull request has now been integrated. Changeset: 5fb6b8e0 Author: Damon Fenacci Committer: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/5fb6b8e05e4717b2dd4e8ca99d87a44b166683d9 Stats: 17 lines in 2 files changed: 0 ins; 1 del; 16 mod 8343420: [lworld] compiler/gcbarriers/TestG1BarrierGeneration.java after merging JDK-8334060 in jdk-24+18 Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1462 From dsimms at openjdk.org Thu May 22 08:03:09 2025 From: dsimms at openjdk.org (David Simms) Date: Thu, 22 May 2025 08:03:09 GMT Subject: [lworld] RFR: 8357508: [lworld] build with CDS disabled is broken In-Reply-To: References: Message-ID: <4nKgl07vwzJG4Ojwt-xbfXWG9RLZbWkEYXFRF8hNXiY=.07a7196a-261d-40fb-aae2-4061e7b753db@github.com> On Wed, 21 May 2025 21:13:53 GMT, Frederic Parain wrote: > Fix build when CDS is disabled. LGTM ------------- Marked as reviewed by dsimms (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1471#pullrequestreview-2860198341 From dsimms at openjdk.org Thu May 22 08:04:08 2025 From: dsimms at openjdk.org (David Simms) Date: Thu, 22 May 2025 08:04:08 GMT Subject: [lworld] Integrated: 8354366: [lworld] VirtualObjectDebugInfoTest fails after merging jdk-25+16 In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 08:34:34 GMT, David Simms wrote: > Partially undo JDK-8350892, specifically field sorting This pull request has now been integrated. Changeset: a47e9b46 Author: David Simms URL: https://git.openjdk.org/valhalla/commit/a47e9b463e7d275d441d79b3539555ea94c52b4d Stats: 10 lines in 2 files changed: 9 ins; 1 del; 0 mod 8354366: [lworld] VirtualObjectDebugInfoTest fails after merging jdk-25+16 ------------- PR: https://git.openjdk.org/valhalla/pull/1430 From fparain at openjdk.org Thu May 22 11:13:05 2025 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 22 May 2025 11:13:05 GMT Subject: [lworld] Integrated: 8357508: [lworld] build with CDS disabled is broken In-Reply-To: References: Message-ID: <6j9LaB59tw3sdLwwO-09j2W1DC5D9QChFz6YyAMqJts=.e97dcd4b-6b34-4cb3-942f-3c35deaf2c6e@github.com> On Wed, 21 May 2025 21:13:53 GMT, Frederic Parain wrote: > Fix build when CDS is disabled. This pull request has now been integrated. Changeset: 4479cf65 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/4479cf6534d93523db1a5ad20fc7b831952d0ab6 Stats: 19 lines in 5 files changed: 7 ins; 5 del; 7 mod 8357508: [lworld] build with CDS disabled is broken Reviewed-by: dsimms ------------- PR: https://git.openjdk.org/valhalla/pull/1471 From heidinga at openjdk.org Thu May 22 11:52:07 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Thu, 22 May 2025 11:52:07 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) In-Reply-To: References: Message-ID: On Tue, 20 May 2025 22:15:29 GMT, Matias Saavedra Silva wrote: > This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. src/hotspot/share/c1/c1_Runtime1.cpp line 1171: > 1169: // Strict statics may require tracking if their class is not fully initialized. > 1170: // For now we can bail out of the compiler and let the interpreter handle it. > 1171: deoptimize_for_strict_static = result.is_strict_static_unset(); Deoptimizing on strict fields makes sense when the field is unset as an initial implementation. As a possible future optimization, we could make some additional checks here to decide whether we need to deopt or not and instead simulate the strict static is_set bits here. `current` Thread is either the thread initializing the class and therefore able to read/update the set/unset bits or it is some other thread that would need to wait. If `current` is the initializing thread, and this is a strict static field write, we know we're currently executing the field set or we wouldn't be patching the code. Given that, it would be possible to avoid the deopt by calling a helper from this code to toggle the bit. Something to think about for the future when strict statics are more common to avoid spurious deopts ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1465#discussion_r2102365209 From thartmann at openjdk.org Thu May 22 12:04:10 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 22 May 2025 12:04:10 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v3] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 05:56:47 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: >> >> - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. >> - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. >> - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: >> >> value class StringHolder { >> @NullRestricted >> String s; >> } >> >> value class StringHolderHolder { >> // flatten >> StringHolder v; >> } >> >> Then `v.s` cannot be trusted to be non-null because `v` can be null. >> >> This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. >> >> Please let me know what you think. Thanks very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > array This is a nice refactoring, thanks for working on this! I'll review the code in detail soon but I submitted some testing already which revealed an issue: compiler/valhalla/inlinetypes/TestArrayNullMarkers.java -Xcomp -XX:-TieredCompilation -DIgnoreCompilerControls=true # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/workspace/open/src/hotspot/share/opto/memnode.cpp:3587), pid=2958342, tid=2958358 # assert(Opcode() == st->Opcode() || st->Opcode() == Op_StoreVector || Opcode() == Op_StoreVector || st->Opcode() == Op_StoreVectorScatter || Opcode() == Op_StoreVectorScatter || phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw || (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || (Opcode() == Op_StoreI && st->Opcode() == Op_StoreL) || (Opcode() == Op_StoreL && st->Opcode() == Op_StoreN) || (st->adr_type()->isa_aryptr() && st->adr_type()->is_aryptr()->is_flat()) || (is_mismatched_access() || st->as_Store()->is_mismatched_access())) failed: no mismatched stores, except on raw memory: StoreB StoreN # # JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-05-22-0636300.tobias.hartmann.valhalla2) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-05-22-0636300.tobias.hartmann.valhalla2, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x167db09] StoreNode::Ideal(PhaseGVN*, bool)+0x2a9 Current CompileTask: C2:18680 865 !b compiler.valhalla.inlinetypes.TestArrayNullMarkers::main (2883 bytes) Stack: [0x00007f99f351b000,0x00007f99f361b000], sp=0x00007f99f36160b0, free space=1004k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x167db09] StoreNode::Ideal(PhaseGVN*, bool)+0x2a9 (memnode.cpp:3587) V [libjvm.so+0x185de4d] PhaseIterGVN::transform_old(Node*)+0xbd (phaseX.cpp:668) V [libjvm.so+0x18530d4] PhaseIterGVN::optimize()+0xb4 (phaseX.cpp:1054) V [libjvm.so+0xb53b16] Compile::Optimize()+0x326 (compile.cpp:2779) V [libjvm.so+0xb5773f] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1fef (compile.cpp:874) V [libjvm.so+0x96db34] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x484 (c2compiler.cpp:142) V [libjvm.so+0xb653f8] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb58 (compileBroker.cpp:2307) V [libjvm.so+0xb665b8] CompileBroker::compiler_thread_loop()+0x568 (compileBroker.cpp:1951) V [libjvm.so+0x10df77b] JavaThread::thread_main_inner()+0x13b (javaThread.cpp:774) V [libjvm.so+0x1b595c6] Thread::call_run()+0xb6 (thread.cpp:231) V [libjvm.so+0x17c4af8] thread_native_entry(Thread*)+0x128 (os_linux.cpp:875) test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestBasicFunctionality.java line 1154: > 1152: > 1153: @Test > 1154: // TODO more aggressive flattening We should reference a tracking bug/RFE for this. Same below. ------------- Changes requested by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1470#pullrequestreview-2860939144 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2102377575 From heidinga at openjdk.org Thu May 22 12:21:04 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Thu, 22 May 2025 12:21:04 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) In-Reply-To: References: Message-ID: <_feQ_CE724KV1yrSK0rIeHs1mG-XRacnK2DYL4KE0Z0=.10cc947d-5823-421a-93be-1de0965af97a@github.com> On Tue, 20 May 2025 22:15:29 GMT, Matias Saavedra Silva wrote: > This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. src/hotspot/share/oops/fieldInfo.hpp line 317: > 315: _fs_modification_watched, // field modification is watched by JVMTI > 316: _fs_strict_static_unset, // JVM_ACC_STRICT static field has not yet been set > 317: _fs_strict_static_unread, // SS field has not yet been read (EnforceStrictStatics=2 only) Suggestion: _fs_strict_static_unread, // SS field has not yet been read Minor comment update - I think we removed the various modes so we don't need to mention them in the comments ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1465#discussion_r2102418109 From heidinga at openjdk.org Thu May 22 12:34:00 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Thu, 22 May 2025 12:34:00 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) In-Reply-To: References: Message-ID: On Tue, 20 May 2025 22:15:29 GMT, Matias Saavedra Silva wrote: > This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. src/hotspot/share/oops/instanceKlass.cpp line 1641: > 1639: } > 1640: } else { > 1641: // Experimentally, enforce additional proposed conditions after the first write. Suggestion: // Ensure no write after read for final strict statics I think this comment may be left over from the multi-option initial prototype. It might be worth going over all the comments and making sure they still apply now that we've settled on a single approach src/hotspot/share/oops/instanceKlass.cpp line 1651: > 1649: throw_strict_static_exception(bad_strict_static, "is set after read (as final) in", CHECK); > 1650: } else if (!is_writing && fs.is_strict_static_unread()) { > 1651: // log the read (this requires an extra status bit, with extra tests on it) Suggestion: This comment also seems like a holdover from the prototype src/hotspot/share/oops/instanceKlassFlags.hpp line 62: > 60: flag(must_be_atomic , 1 << 17) /* doesn't allow tearing */ \ > 61: flag(has_loosely_consistent_annotation , 1 << 18) /* the class has the LooselyConsistentValue annotation WARNING: it doesn't automatically mean that the class allows tearing */ \ > 62: flag(is_implicitly_constructible , 1 << 19) /* the class has the ImplicitlyConstrutible annotation */ \ Did this get accidentally propogated into this patch from somewhere else? src/hotspot/share/prims/jni.cpp line 2062: > 2060: !InstanceKlass::cast(k)->find_field(fieldname, signame, true, &fd) || > 2061: // strict fields need special tracking during ; do not hand them out so early > 2062: (fd.access_flags().is_strict() && !InstanceKlass::cast(k)->is_initialized())) { Should this be an assert rather than a runtime check given that we force the class to be initialized a few lines above? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1465#discussion_r2102433487 PR Review Comment: https://git.openjdk.org/valhalla/pull/1465#discussion_r2102436621 PR Review Comment: https://git.openjdk.org/valhalla/pull/1465#discussion_r2102439672 PR Review Comment: https://git.openjdk.org/valhalla/pull/1465#discussion_r2102444109 From thartmann at openjdk.org Thu May 22 12:52:36 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 22 May 2025 12:52:36 GMT Subject: [lworld] RFR: 8355614: [lworld] SIGSEGV in InlineKlass::write_value_to_addr Message-ID: We crash in `InlineKlass::write_value_to_addr` when writing to a field that is not a flat field. The root cause is that `b->layout_kind() == LayoutKind::NULLABLE_ATOMIC_FLAT` is true in `FieldLayout::shift_fields` because `_layout_kind` contains garbage. It needs to be initialized in the constructor. I also fixed a few other minor things. Thanks, Tobias ------------- Commit messages: - 8355614: [lworld] SIGSEGV in InlineKlass::write_value_to_addr Changes: https://git.openjdk.org/valhalla/pull/1472/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1472&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355614 Stats: 14 lines in 5 files changed: 5 ins; 3 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/1472.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1472/head:pull/1472 PR: https://git.openjdk.org/valhalla/pull/1472 From thartmann at openjdk.org Thu May 22 14:16:21 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 22 May 2025 14:16:21 GMT Subject: [lworld] RFR: 8355614: [lworld] SIGSEGV in InlineKlass::write_value_to_addr [v2] In-Reply-To: References: Message-ID: > We crash in `InlineKlass::write_value_to_addr` when writing to a field that is not a flat field. The root cause is that `b->layout_kind() == LayoutKind::NULLABLE_ATOMIC_FLAT` is true in `FieldLayout::shift_fields` because `_layout_kind` contains garbage. It needs to be initialized in the constructor. > > I also fixed a few other minor things. > > Thanks, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: Reverted changes in fieldInfo.hpp ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1472/files - new: https://git.openjdk.org/valhalla/pull/1472/files/5343fd4e..49b7251c Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1472&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1472&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1472.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1472/head:pull/1472 PR: https://git.openjdk.org/valhalla/pull/1472 From qamai at openjdk.org Thu May 22 17:57:40 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 22 May 2025 17:57:40 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v4] In-Reply-To: References: Message-ID: > Hi, > > This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: > > - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. > - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. > - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: > > value class StringHolder { > @NullRestricted > String s; > } > > value class StringHolderHolder { > // flatten > StringHolder v; > } > > Then `v.s` cannot be trusted to be non-null because `v` can be null. > > This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. > > Please let me know what you think. Thanks very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: fix array field calculations ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1470/files - new: https://git.openjdk.org/valhalla/pull/1470/files/99d2269a..10290802 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=02-03 Stats: 147 lines in 4 files changed: 75 ins; 16 del; 56 mod Patch: https://git.openjdk.org/valhalla/pull/1470.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1470/head:pull/1470 PR: https://git.openjdk.org/valhalla/pull/1470 From heidinga at openjdk.org Thu May 22 18:40:13 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Thu, 22 May 2025 18:40:13 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v4] In-Reply-To: <8sbj-SGuIXuLwGqBMuR_7aOzGgJ-GAcvEg0pJ5VsgG8=.cd427457-7d61-4d8f-b443-701e338128df@github.com> References: <8sbj-SGuIXuLwGqBMuR_7aOzGgJ-GAcvEg0pJ5VsgG8=.cd427457-7d61-4d8f-b443-701e338128df@github.com> Message-ID: On Wed, 21 May 2025 14:44:50 GMT, Matias Saavedra Silva wrote: >> Updates to javac prevent it from creating classes with improper uses of strict fields. Additionally, non-final strict fields are now allowed so `StrictFinalInstanceFieldsTest.java` needs to updated with new test cases. This patch adds new cases for final and non-final stricts as well as negative test cases using asmtools that check improper use of strict fields and early larval stack map frames. >> >> During testing, it was revealed that the new verify errors added in [JDK-8354694](https://bugs.openjdk.org/browse/JDK-8354694) do not work properly so a fix is included in this patch. >> >> Note: This cannot be integrated until jtreg is updated with a recent build of asmtools which can handle strict fields and can generate early_larval frames. > > 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 seven commits: > > - Merge branch 'lworld' into new_strict_tests_8352068 > - Added bug number to problem listed test > - Problem list test until jtreg is updated > - Remove old test > - Added copyright > - Added more positive test cases > - [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 Maintaining jasm and jcod files can be a pain. The less those files contain, the better as it is less classfile / bytecode to try to build in your head while debugging. One option for set of common tests like this that all have x & y fields, as well as getter methods and a complicated toString, is to use an abstract parent class: abstract JasmParent extends Parent { abstract int get_x(); abstract int get_y(); public String toString() { return "x: " + get_x() + "\n" + "y: " + get_y() + "\n" + super.toString(); } } and have all the .jasm file class extend this class instead of using Parent directly. This will move all the bootstrap methods & indy related code out of jasm files and hopefully result in something simpler to look at. Another option is to keep Parent as it is, but have its toString() use Reflection like: `this.getClass().getDeclaredFeilds()` to find all the fields and print them. Any solution that moves code out of jasm / jcod files makes the code easier to maintain and understand longterm test/hotspot/jtreg/runtime/valhalla/inlinetypes/verifier/BadChild.jasm line 40: > 38: putfield Field y:"I"; > 39: aload_0; > 40: invokespecial Method Parent."":"()V"; Suggestion: invokespecial Method Parent."":"()V"; // Strict field x must be set before this call Adding a comment to the code to make the error explicit helps with understanding the test in the future test/hotspot/jtreg/runtime/valhalla/inlinetypes/verifier/BadChild1.jasm line 40: > 38: putfield Field x:"I"; > 39: aload_0; > 40: invokespecial Method Parent."":"()V"; Suggestion: invokespecial Method Parent."":"()V"; // Strict field y must be set before this call test/hotspot/jtreg/runtime/valhalla/inlinetypes/verifier/BadChild1.jasm line 61: > 59: } > 60: > 61: public Method toString:"()Ljava/lang/String;" Can the toString() implementations be added to the Parent class? It cuts down on the amount of bytecode that needs to be understood. Using reflection to look up the fields in the Parent class is a fine way to approach this test/hotspot/jtreg/runtime/valhalla/inlinetypes/verifier/ControlFlowChildBad.jasm line 51: > 49: iconst_2; > 50: putfield Field y:"I"; > 51: goto L39; Suggestion: goto L39; // Strict field x never set on this path test/hotspot/jtreg/runtime/valhalla/inlinetypes/verifier/EndsInEarlyLarval.jcod line 167: > 165: 7b; // same_frame > 166: }; > 167: 246b, []{}, { // early_larval_frame, no base frame Suggestion: 246b, []{}, { // ERROR HERE! early_larval_frame, no base frame test/hotspot/jtreg/runtime/valhalla/inlinetypes/verifier/NestedEarlyLarval.jcod line 162: > 160: [] { // > 161: 246b, []{#8}, { // early_larval_frame > 162: 246b; // early_larval_frame, illegal Suggestion: 246b; // ERROR HERE: early_larval_frame, nest early_larval is illegal test/hotspot/jtreg/runtime/valhalla/inlinetypes/verifier/StrictFieldsNotSubset.jcod line 161: > 159: Attr(#36) { // StackMapTable > 160: [] { // > 161: 246b, []{#8; #12}, { // early_larval_frame Is the issue here? That #12 is not a strict field? A comment of the form `// ERROR: #12 doesn't name a strict field` would go a long way to making this understandable in the future ------------- PR Review: https://git.openjdk.org/valhalla/pull/1449#pullrequestreview-2861806904 PR Review Comment: https://git.openjdk.org/valhalla/pull/1449#discussion_r2102921671 PR Review Comment: https://git.openjdk.org/valhalla/pull/1449#discussion_r2102922516 PR Review Comment: https://git.openjdk.org/valhalla/pull/1449#discussion_r2102925901 PR Review Comment: https://git.openjdk.org/valhalla/pull/1449#discussion_r2102929268 PR Review Comment: https://git.openjdk.org/valhalla/pull/1449#discussion_r2102932625 PR Review Comment: https://git.openjdk.org/valhalla/pull/1449#discussion_r2102934935 PR Review Comment: https://git.openjdk.org/valhalla/pull/1449#discussion_r2103173386 From qamai at openjdk.org Thu May 22 18:49:23 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 22 May 2025 18:49:23 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v5] In-Reply-To: References: Message-ID: > Hi, > > This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: > > - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. > - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. > - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: > > value class StringHolder { > @NullRestricted > String s; > } > > value class StringHolderHolder { > // flatten > StringHolder v; > } > > Then `v.s` cannot be trusted to be non-null because `v` can be null. > > This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. > > Please let me know what you think. Thanks very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: fix array of nullable empty type ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1470/files - new: https://git.openjdk.org/valhalla/pull/1470/files/10290802..b1515710 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=04 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=03-04 Stats: 18 lines in 1 file changed: 14 ins; 0 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1470.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1470/head:pull/1470 PR: https://git.openjdk.org/valhalla/pull/1470 From qamai at openjdk.org Thu May 22 18:56:07 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 22 May 2025 18:56:07 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v3] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 11:55:47 GMT, Tobias Hartmann wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> array > > test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestBasicFunctionality.java line 1154: > >> 1152: >> 1153: @Test >> 1154: // TODO more aggressive flattening > > We should reference a tracking bug/RFE for this. Same below. Done ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2103210848 From qamai at openjdk.org Thu May 22 19:04:10 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 22 May 2025 19:04:10 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v5] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 18:49:23 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: >> >> - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. >> - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. >> - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: >> >> value class StringHolder { >> @NullRestricted >> String s; >> } >> >> value class StringHolderHolder { >> // flatten >> StringHolder v; >> } >> >> Then `v.s` cannot be trusted to be non-null because `v` can be null. >> >> This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. >> >> Please let me know what you think. Thanks very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > fix array of nullable empty type The failure is due to complications computing the field offset of an array access. When finding the field corresponding to a field offset, we cannot find the null marker because it is not a field inside the element type. There is still one strange case, though, consider this class: @LooselyConsistentValue static value class EmptyContainer { @Strict @NullRestricted MyValueEmpty empty = new MyValueEmpty(); } Then, the null marker of `EmptyContainer` is at offset 1 inside the payload. I checked for that case and made it a mismatched access now. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1470#issuecomment-2902266754 From thartmann at openjdk.org Fri May 23 05:36:03 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 23 May 2025 05:36:03 GMT Subject: [lworld] Integrated: 8355614: [lworld] SIGSEGV in InlineKlass::write_value_to_addr In-Reply-To: References: Message-ID: On Thu, 22 May 2025 12:47:25 GMT, Tobias Hartmann wrote: > We crash in `InlineKlass::write_value_to_addr` when writing to a field that is not a flat field. The root cause is that `b->layout_kind() == LayoutKind::NULLABLE_ATOMIC_FLAT` is true in `FieldLayout::shift_fields` because `_layout_kind` contains garbage. It needs to be initialized in the constructor. > > I also fixed a few other minor things. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 533d8143 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/533d81432cf8f8541a62a5a7f01912f15a90400e Stats: 11 lines in 4 files changed: 3 ins; 3 del; 5 mod 8355614: [lworld] SIGSEGV in InlineKlass::write_value_to_addr Co-authored-by: Frederic Parain ------------- PR: https://git.openjdk.org/valhalla/pull/1472 From qamai at openjdk.org Fri May 23 05:41:53 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 23 May 2025 05:41:53 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v6] In-Reply-To: References: Message-ID: <2JtgKXDDAP1V_izSuLUxoU0_XGWq2OCvcWD_13865PI=.368151e1-db00-4ed1-b035-526a2bc5c5a6@github.com> > Hi, > > This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: > > - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. > - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. > - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: > > value class StringHolder { > @NullRestricted > String s; > } > > value class StringHolderHolder { > // flatten > StringHolder v; > } > > Then `v.s` cannot be trusted to be non-null because `v` can be null. > > This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. > > Please let me know what you think. Thanks very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: generalize weird layout ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1470/files - new: https://git.openjdk.org/valhalla/pull/1470/files/b1515710..77f145d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=05 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1470.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1470/head:pull/1470 PR: https://git.openjdk.org/valhalla/pull/1470 From qamai at openjdk.org Fri May 23 05:45:49 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 23 May 2025 05:45:49 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v7] In-Reply-To: References: Message-ID: <7UUCZiRTxA_Y5nWiXYOQwLmL0N_DkdZwSl1puHQSfog=.dce56230-1dcd-4fb7-a92e-1d3ebcfbd691@github.com> > Hi, > > This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: > > - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. > - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. > - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: > > value class StringHolder { > @NullRestricted > String s; > } > > value class StringHolderHolder { > // flatten > StringHolder v; > } > > Then `v.s` cannot be trusted to be non-null because `v` can be null. > > This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. > > Please let me know what you think. Thanks very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: typo ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1470/files - new: https://git.openjdk.org/valhalla/pull/1470/files/77f145d9..5ac917f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=06 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=05-06 Stats: 4 lines in 3 files changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1470.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1470/head:pull/1470 PR: https://git.openjdk.org/valhalla/pull/1470 From qamai at openjdk.org Fri May 23 06:33:48 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 23 May 2025 06:33:48 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v8] In-Reply-To: References: Message-ID: > Hi, > > This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: > > - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. > - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. > - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: > > value class StringHolder { > @NullRestricted > String s; > } > > value class StringHolderHolder { > // flatten > StringHolder v; > } > > Then `v.s` cannot be trusted to be non-null because `v` can be null. > > This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. > > Please let me know what you think. Thanks very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: weird layout ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1470/files - new: https://git.openjdk.org/valhalla/pull/1470/files/5ac917f3..f7e3bd31 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=07 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=06-07 Stats: 40 lines in 1 file changed: 32 ins; 0 del; 8 mod Patch: https://git.openjdk.org/valhalla/pull/1470.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1470/head:pull/1470 PR: https://git.openjdk.org/valhalla/pull/1470 From dsimms at openjdk.org Fri May 23 06:47:23 2025 From: dsimms at openjdk.org (David Simms) Date: Fri, 23 May 2025 06:47:23 GMT Subject: [lworld] Integrated: 8357617: [lworld] trivial: remove remaining references to "jdk.jdeps/com.sun.tools.classfile" Message-ID: Removed old jtreg modules directives ------------- Commit messages: - 8357617: [lworld] trivial: removed remaing references to jdk.jdeps/com.sun.tools.classfile Changes: https://git.openjdk.org/valhalla/pull/1473/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1473&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357617 Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1473.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1473/head:pull/1473 PR: https://git.openjdk.org/valhalla/pull/1473 From dsimms at openjdk.org Fri May 23 06:47:23 2025 From: dsimms at openjdk.org (David Simms) Date: Fri, 23 May 2025 06:47:23 GMT Subject: [lworld] Integrated: 8357617: [lworld] trivial: remove remaining references to "jdk.jdeps/com.sun.tools.classfile" In-Reply-To: References: Message-ID: <73mf_0PSJJzkLJO7My19mjE5ptEw89J5UrigNq3ZvaA=.d8828ee3-2637-4dbf-acdd-fef7813db1e5@github.com> On Fri, 23 May 2025 06:39:32 GMT, David Simms wrote: > Removed old jtreg modules directives This pull request has now been integrated. Changeset: c42af861 Author: David Simms URL: https://git.openjdk.org/valhalla/commit/c42af8615277a3c133bf46db0ff1f3a269421790 Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod 8357617: [lworld] trivial: remove remaining references to "jdk.jdeps/com.sun.tools.classfile" ------------- PR: https://git.openjdk.org/valhalla/pull/1473 From matsaave at openjdk.org Fri May 23 19:15:08 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 23 May 2025 19:15:08 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v2] In-Reply-To: References: Message-ID: > This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision: - Copyrights - Added reflective tests and problem listed test ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1465/files - new: https://git.openjdk.org/valhalla/pull/1465/files/81a6f5a4..fefad149 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1465&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1465&range=00-01 Stats: 207 lines in 5 files changed: 204 ins; 0 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1465.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1465/head:pull/1465 PR: https://git.openjdk.org/valhalla/pull/1465 From matsaave at openjdk.org Fri May 23 19:59:04 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 23 May 2025 19:59:04 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v2] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 18:52:41 GMT, Chen Liang wrote: >> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision: >> >> - Copyrights >> - Added reflective tests and problem listed test > > test/hotspot/jtreg/runtime/valhalla/inlinetypes/verifier/Brbefore_BAD.jasm line 24: > >> 22: */ >> 23: >> 24: identity class Brbefore_BAD version 69:65535 > > Can't this be compiled with javac? I don't think we are going to add any checks for strict initialization on the javac side as pre-write reads cannot be detected because they can easily happen in nested method calls. > > Even if we decide to use jasm, I think the best practice seems to leave the source to generate the jasm in a .test file, and comment in the jasm what was changed. Javac can catch this because the static field hasn't been initialized yet: `error: variable F2__STRICT might not have been initialized int x = F2__STRICT; //FAIL` It may be possible to write a java program with nested calls that does this but I think it's best to keep the test cases simple. I agree with the last comment, I'll add the equivalent java code to the jasm files. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1465#discussion_r2105330628 From matsaave at openjdk.org Fri May 23 20:09:04 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 23 May 2025 20:09:04 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v2] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 12:29:06 GMT, Dan Heidinga wrote: >> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision: >> >> - Copyrights >> - Added reflective tests and problem listed test > > src/hotspot/share/oops/instanceKlassFlags.hpp line 62: > >> 60: flag(must_be_atomic , 1 << 17) /* doesn't allow tearing */ \ >> 61: flag(has_loosely_consistent_annotation , 1 << 18) /* the class has the LooselyConsistentValue annotation WARNING: it doesn't automatically mean that the class allows tearing */ \ >> 62: flag(is_implicitly_constructible , 1 << 19) /* the class has the ImplicitlyConstrutible annotation */ \ > > Did this get accidentally propogated into this patch from somewhere else? Weird, thanks for catching that! ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1465#discussion_r2105347878 From matsaave at openjdk.org Fri May 23 20:26:57 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 23 May 2025 20:26:57 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v3] In-Reply-To: References: Message-ID: > This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Chen and Dan comments and cleanup ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1465/files - new: https://git.openjdk.org/valhalla/pull/1465/files/fefad149..702b82ae Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1465&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1465&range=01-02 Stats: 66 lines in 10 files changed: 51 ins; 9 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/1465.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1465/head:pull/1465 PR: https://git.openjdk.org/valhalla/pull/1465 From matsaave at openjdk.org Fri May 23 20:34:07 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 23 May 2025 20:34:07 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v4] In-Reply-To: References: <8sbj-SGuIXuLwGqBMuR_7aOzGgJ-GAcvEg0pJ5VsgG8=.cd427457-7d61-4d8f-b443-701e338128df@github.com> Message-ID: On Thu, 22 May 2025 18:28:34 GMT, Dan Heidinga wrote: >> 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 seven commits: >> >> - Merge branch 'lworld' into new_strict_tests_8352068 >> - Added bug number to problem listed test >> - Problem list test until jtreg is updated >> - Remove old test >> - Added copyright >> - Added more positive test cases >> - [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 > > test/hotspot/jtreg/runtime/valhalla/inlinetypes/verifier/StrictFieldsNotSubset.jcod line 161: > >> 159: Attr(#36) { // StackMapTable >> 160: [] { // >> 161: 246b, []{#8; #12}, { // early_larval_frame > > Is the issue here? That #12 is not a strict field? A comment of the form `// ERROR: #12 doesn't name a strict field` would go a long way to making this understandable in the future The issue is that there is a field, or rather a NameAndType, that doesn't exist in the initial set of strict fields. The early_larval frame offers a set of fields that are not a subset of the initial set of strict fields generated in the VM. This is certainly one of the larger and more confusing tests so I'll add comments to this test as well as the others. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1449#discussion_r2105377799 From thartmann at openjdk.org Mon May 26 12:58:13 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 26 May 2025 12:58:13 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v8] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 06:33:48 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: >> >> - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. >> - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. >> - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: >> >> value class StringHolder { >> @NullRestricted >> String s; >> } >> >> value class StringHolderHolder { >> // flatten >> StringHolder v; >> } >> >> Then `v.s` cannot be trusted to be non-null because `v` can be null. >> >> This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. >> >> Please let me know what you think. Thanks very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > weird layout Changes requested by thartmann (Committer). src/hotspot/share/opto/graphKit.cpp line 1880: > 1878: arytype = arytype->cast_to_exactness(true); > 1879: arytype = arytype->cast_to_not_null_free(is_not_null_free); > 1880: array = _gvn.transform(new CheckCastPPNode(control(), array, arytype, ConstraintCastNode::StrongDependency)); Did you hit an issue without this? src/hotspot/share/opto/inlinetypenode.cpp line 488: > 486: if (base->is_Con() && oop_ptr->is_inlinetypeptr() && !is_array && !mismatched) { > 487: // If the oop to the inline type is constant (static final field), we can > 488: // also treat the fields as constants because the inline type is immutable. Why is this not needed anymore? src/hotspot/share/opto/inlinetypenode.cpp line 716: > 714: kit->C->set_flat_accesses(); > 715: ciInlineKlass* vk = inline_klass(); > 716: assert(vk->maybe_flat_in_array(), ""); Please add an assert message src/hotspot/share/opto/inlinetypenode.cpp line 722: > 720: region = new RegionNode(3); > 721: region->init_req(1, kit->top()); > 722: region->init_req(2, kit->top()); Why is the top init needed? Aren't `nullptr` inputs handled the same way in `RegionNode::Ideal` etc.? src/hotspot/share/opto/inlinetypenode.cpp line 724: > 722: region->init_req(2, kit->top()); > 723: } else { > 724: region = new RegionNode(4); For simplicity, can't we always have a `RegionNode` with 4 inputs here and simply leave `in(3)` as top/nullptr if we don't need it? src/hotspot/share/opto/inlinetypenode.cpp line 754: > 752: Node* ptr = kit->flat_array_element_address(cast, idx, vk, /* null_free */ false, /* not_null_free */ true, /* atomic */ true); > 753: if (vk->get_field_by_offset(vk->payload_offset(), false) == nullptr && vk->null_marker_offset_in_payload() != 0) { > 754: // TODO 8357612 Weird layout I don't understand why this would be specific to the layout described in [JDK-8357612](https://bugs.openjdk.org/browse/JDK-8357612)? Wouldn't we also hit `vk->get_field_by_offset(vk->payload_offset(), false) == nullptr` when the null marker is at `vk->payload_offset()` which would be totally fine? src/hotspot/share/opto/inlinetypenode.cpp line 768: > 766: } > 767: > 768: kit->set_control(kit->IfTrue(iff_null_free)); Maybe add a `// Null-free` comment here. src/hotspot/share/opto/inlinetypenode.cpp line 1387: > 1385: assert(vk->has_non_atomic_layout(), ""); > 1386: // TODO 8350865 Is the conversion to/from payload folded? We should wire this directly. > 1387: // Also remove the PreserveReexecuteState in Parse::array_load when buffering is no longer possible. Now that you removed the `convert_to_payload` hack, this comment should be removed, right? Also, buffering should no longer be possible and the referenced code in `Parse::array_load` can be removed. src/hotspot/share/opto/parse2.cpp line 131: > 129: arytype = arytype->cast_to_exactness(true); > 130: arytype = arytype->cast_to_not_null_free(is_not_null_free); > 131: Node* flat_array = gvn().transform(new CastPPNode(control(), array, arytype)); I assume you are not using `flat_array_element_address` anymore because you don't need the address but only want to cast the array but I think this casting should then be factored out. Also, why don't you need a `ConstraintCastNode::StrongDependency` here? ------------- PR Review: https://git.openjdk.org/valhalla/pull/1470#pullrequestreview-2867770479 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2106895201 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2106898542 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2106900806 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2106910662 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2106916828 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107279838 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107272385 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107044110 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107016830 From thartmann at openjdk.org Mon May 26 12:58:13 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 26 May 2025 12:58:13 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v8] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 09:11:05 GMT, Tobias Hartmann wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> weird layout > > src/hotspot/share/opto/inlinetypenode.cpp line 716: > >> 714: kit->C->set_flat_accesses(); >> 715: ciInlineKlass* vk = inline_klass(); >> 716: assert(vk->maybe_flat_in_array(), ""); > > Please add an assert message Same for the other asserts with `..., "");` ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107038915 From thartmann at openjdk.org Mon May 26 13:11:42 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 26 May 2025 13:11:42 GMT Subject: [lworld] RFR: [lworld] Problem listing test until JDK-8357785 is fixed Message-ID: Test fails since recent merge. Let's problem list it. Thanks, Tobias ------------- Commit messages: - [lworld] Problem listing test until JDK-8357785 is fixed Changes: https://git.openjdk.org/valhalla/pull/1475/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1475&range=00 Stats: 835 lines in 14 files changed: 420 ins; 230 del; 185 mod Patch: https://git.openjdk.org/valhalla/pull/1475.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1475/head:pull/1475 PR: https://git.openjdk.org/valhalla/pull/1475 From thartmann at openjdk.org Mon May 26 13:13:59 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 26 May 2025 13:13:59 GMT Subject: [lworld] Withdrawn: [lworld] Problem listing test until JDK-8357785 is fixed In-Reply-To: References: Message-ID: <-j3fASeP3EJcksHbrOaX5QmbWI0-zW6OZ0bZCob21Ng=.b8c981fd-9d35-4491-ad2b-d4eb21da776f@github.com> On Mon, 26 May 2025 13:06:58 GMT, Tobias Hartmann wrote: > Test fails since recent merge. Let's problem list it. > > Thanks, > Tobias This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/valhalla/pull/1475 From thartmann at openjdk.org Mon May 26 13:18:15 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 26 May 2025 13:18:15 GMT Subject: [lworld] Integrated: [lworld] Problem listing test until JDK-8357785 is fixed In-Reply-To: References: Message-ID: <_8Gg_jd0BfWk0_KvbIVk0NsQ2YZcioH1FpIG81HjJrE=.3e80cf9f-8ef0-455d-8edb-5e30bde0d465@github.com> On Mon, 26 May 2025 13:13:19 GMT, Tobias Hartmann wrote: > Test fails since recent merge. Let's problem list it. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 5d31f4f1 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/5d31f4f1a15fdd6eff323ce6989150409ff421e0 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod [lworld] Problem listing test until JDK-8357785 is fixed ------------- PR: https://git.openjdk.org/valhalla/pull/1476 From thartmann at openjdk.org Mon May 26 13:18:15 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 26 May 2025 13:18:15 GMT Subject: [lworld] Integrated: [lworld] Problem listing test until JDK-8357785 is fixed Message-ID: Test fails since recent merge. Let's problem list it. Thanks, Tobias ------------- Commit messages: - [lworld] Problem listing test until JDK-8357785 is fixed Changes: https://git.openjdk.org/valhalla/pull/1476/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1476&range=00 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1476.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1476/head:pull/1476 PR: https://git.openjdk.org/valhalla/pull/1476 From heidinga at openjdk.org Mon May 26 13:30:05 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 26 May 2025 13:30:05 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v3] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 20:26:57 GMT, Matias Saavedra Silva wrote: >> This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Chen and Dan comments and cleanup src/hotspot/share/prims/jni.cpp line 2060: > 2058: if (!k->is_instance_klass() || > 2059: !InstanceKlass::cast(k)->find_field(fieldname, signame, true, &fd)) { > 2060: assert(InstanceKlass::cast(k)->is_initialized(), "must be"); The assert is right before throwing a NoSuchFieldError. If we're going to assert, we want to do it on the path that can return the jfieldID so it needs to be moved out of the `if` block ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1465#discussion_r2107360282 From thartmann at openjdk.org Mon May 26 13:34:17 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 26 May 2025 13:34:17 GMT Subject: [lworld] Integrated: [lworld] Disabling assert until JDK-8325632 is fixed Message-ID: Disabling the assert to reduce noise in testing until [JDK-8325632](https://bugs.openjdk.org/browse/JDK-8325632) is fixed. Thanks, Tobias ------------- Commit messages: - [lworld] Disabling assert until JDK-8325632 is fixed Changes: https://git.openjdk.org/valhalla/pull/1477/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1477&range=00 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1477.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1477/head:pull/1477 PR: https://git.openjdk.org/valhalla/pull/1477 From thartmann at openjdk.org Mon May 26 13:34:18 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 26 May 2025 13:34:18 GMT Subject: [lworld] Integrated: [lworld] Disabling assert until JDK-8325632 is fixed In-Reply-To: References: Message-ID: On Mon, 26 May 2025 13:29:11 GMT, Tobias Hartmann wrote: > Disabling the assert to reduce noise in testing until [JDK-8325632](https://bugs.openjdk.org/browse/JDK-8325632) is fixed. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 48c65051 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/48c65051125bc88e51bc8bf2fad9cc6af7281a53 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod [lworld] Disabling assert until JDK-8325632 is fixed ------------- PR: https://git.openjdk.org/valhalla/pull/1477 From heidinga at openjdk.org Mon May 26 13:36:04 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 26 May 2025 13:36:04 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v3] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 20:26:57 GMT, Matias Saavedra Silva wrote: >> This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Chen and Dan comments and cleanup There are a couple of other corner cases for dealing with reflection we should probably test. Assume a single `strict static final` field : * bytecode write; reflective read; bytecode write --> error for write after read * reflective write; bytecode read, bytecode write --> error for write after read * reflective write; bytecode read, reflective write --> error for write after read * reflective write; reflective read, reflective write --> error for write after read This ensures we've covered the mix of reflective vs bytecode reads and writes and ensures all paths correctly set and check the bits. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1465#issuecomment-2909781422 From dfenacci at openjdk.org Mon May 26 13:40:45 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 26 May 2025 13:40:45 GMT Subject: [lworld] RFR: 8342488: [lworld] compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java fails after merging jdk-24+13 Message-ID: <_0MgTBeyoyorG4Sgh94xJyzCpd9oNIKwCWjx_Pjt1vQ=.dd4b3b8e-469d-4cf4-beeb-e71cb8a06e4b@github.com> [JDK-8325660](https://bugs.openjdk.org/browse/JDK-8325660) has (temporarily) made `eliminate_boxing` [to false](https://github.com/dafedafe/valhalla/blob/c42af8615277a3c133bf46db0ff1f3a269421790/src/hotspot/share/opto/c2compiler.cpp#L127). This makes `Integer::valueOf` being immediately inlined instead of late-inlined (as in mainline) and this adds 1 allocation after the parsing (value class buffering?). As a consequence there is also no `Incremental Boxing Inline` anymore. `ScalarReplacementWithGCBarrierTests.java` currently relies on checking the count of allocations in `AFTER_PARSING` and `INCREMENTAL_BOXING_INLINE`. In the first case the count (1) is wrong and in the second case the phase is not present anymore. On the other hand the test has been created to check that one allocation is eliminated by scalar replacement. So, the number of allocations right after parsing and the choice of `Incremental Boxing Inline` as "reference" phase to check for 2 allocation shouldn't matter (up to a certain extent). To fix the issue I suggest we remove the count check after parsing and use `PHASEIDEAL_BEFORE_EA` to check for the 2 allocations instead (which is present in both cases). ------------- Commit messages: - Merge branch 'lworld' into JDK-8342488 - JDK-8342488: [lworld] compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java fails after merging jdk-24+13 Changes: https://git.openjdk.org/valhalla/pull/1474/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1474&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342488 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1474.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1474/head:pull/1474 PR: https://git.openjdk.org/valhalla/pull/1474 From chagedorn at openjdk.org Mon May 26 14:05:06 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 26 May 2025 14:05:06 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v8] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 06:33:48 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: >> >> - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. >> - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. >> - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: >> >> value class StringHolder { >> @NullRestricted >> String s; >> } >> >> value class StringHolderHolder { >> // flatten >> StringHolder v; >> } >> >> Then `v.s` cannot be trusted to be non-null because `v` can be null. >> >> This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. >> >> Please let me know what you think. Thanks very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > weird layout src/hotspot/share/opto/parse2.cpp line 129: > 127: ciArrayKlass* array_klass = ciArrayKlass::make(vk, /* flat */ true, is_null_free, maybe_atomic); > 128: const TypeAryPtr* arytype = TypeOopPtr::make_from_klass(array_klass)->isa_aryptr(); > 129: arytype = arytype->cast_to_exactness(true); Nice refactoring! Just noticed this here: IIUC, we don't know whether it's null-free or not here but we still set it to exact (was like that before already) which we should probably not? But it looks like the way we later use the `CastPP` in `make_from_flat_array()`, it does not cause problems because we will feed it into a nullable and null-free cast which is correctly set as exact. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107422042 From qamai at openjdk.org Mon May 26 15:20:21 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 26 May 2025 15:20:21 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v9] In-Reply-To: References: Message-ID: > Hi, > > This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: > > - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. > - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. > - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: > > value class StringHolder { > @NullRestricted > String s; > } > > value class StringHolderHolder { > // flatten > StringHolder v; > } > > Then `v.s` cannot be trusted to be non-null because `v` can be null. > > This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. > > Please let me know what you think. Thanks very much. 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 11 additional commits since the last revision: - Merge branch 'lworld' into loadstoreflat - cast_to_flat_array - weird layout - typo - generalize weird layout - fix array of nullable empty type - fix array field calculations - array - convert_from_payload - add tests - ... and 1 more: https://git.openjdk.org/valhalla/compare/d1759c70...e49bbc8c ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1470/files - new: https://git.openjdk.org/valhalla/pull/1470/files/f7e3bd31..e49bbc8c Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=08 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=07-08 Stats: 239307 lines in 1636 files changed: 55300 ins; 178981 del; 5026 mod Patch: https://git.openjdk.org/valhalla/pull/1470.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1470/head:pull/1470 PR: https://git.openjdk.org/valhalla/pull/1470 From qamai at openjdk.org Mon May 26 15:20:21 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 26 May 2025 15:20:21 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v9] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 09:09:37 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 11 additional commits since the last revision: >> >> - Merge branch 'lworld' into loadstoreflat >> - cast_to_flat_array >> - weird layout >> - typo >> - generalize weird layout >> - fix array of nullable empty type >> - fix array field calculations >> - array >> - convert_from_payload >> - add tests >> - ... and 1 more: https://git.openjdk.org/valhalla/compare/d1759c70...e49bbc8c > > src/hotspot/share/opto/inlinetypenode.cpp line 488: > >> 486: if (base->is_Con() && oop_ptr->is_inlinetypeptr() && !is_array && !mismatched) { >> 487: // If the oop to the inline type is constant (static final field), we can >> 488: // also treat the fields as constants because the inline type is immutable. > > Why is this not needed anymore? Because the loads we generate can be constant-folded, there is no need for an explicit path here. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107554051 From qamai at openjdk.org Mon May 26 15:25:04 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 26 May 2025 15:25:04 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v8] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 09:07:24 GMT, Tobias Hartmann wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> weird layout > > src/hotspot/share/opto/graphKit.cpp line 1880: > >> 1878: arytype = arytype->cast_to_exactness(true); >> 1879: arytype = arytype->cast_to_not_null_free(is_not_null_free); >> 1880: array = _gvn.transform(new CheckCastPPNode(control(), array, arytype, ConstraintCastNode::StrongDependency)); > > Did you hit an issue without this? In principle, when we cast the array to null-free atomic, the result type depends on 2 dominating tests, which are the null-free test and the atomic test. As a result, we cannot use `RegularDependency` here, because `RegularDependency` means that the cast depends only on the test which is its control input. > src/hotspot/share/opto/inlinetypenode.cpp line 724: > >> 722: region->init_req(2, kit->top()); >> 723: } else { >> 724: region = new RegionNode(4); > > For simplicity, can't we always have a `RegionNode` with 4 inputs here and simply leave `in(3)` as top/nullptr if we don't need it? Oh that's right, I forgot about that > src/hotspot/share/opto/inlinetypenode.cpp line 1387: > >> 1385: assert(vk->has_non_atomic_layout(), ""); >> 1386: // TODO 8350865 Is the conversion to/from payload folded? We should wire this directly. >> 1387: // Also remove the PreserveReexecuteState in Parse::array_load when buffering is no longer possible. > > Now that you removed the `convert_to_payload` hack, this comment should be removed, right? Also, buffering should no longer be possible and the referenced code in `Parse::array_load` can be removed. Yes you are right, I have done that. > src/hotspot/share/opto/parse2.cpp line 131: > >> 129: arytype = arytype->cast_to_exactness(true); >> 130: arytype = arytype->cast_to_not_null_free(is_not_null_free); >> 131: Node* flat_array = gvn().transform(new CastPPNode(control(), array, arytype)); > > I assume you are not using `flat_array_element_address` anymore because you don't need the address but only want to cast the array but I think this casting should then be factored out. Also, why don't you need a `ConstraintCastNode::StrongDependency` here? That's a good idea, I refactored it into `GraphKit::cast_to_flat_array` and the element address can be trivially obtained from `array_element_address`. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107556905 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107557400 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107559526 PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107558685 From qamai at openjdk.org Mon May 26 15:25:04 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 26 May 2025 15:25:04 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v8] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:55 GMT, Tobias Hartmann wrote: >> src/hotspot/share/opto/inlinetypenode.cpp line 716: >> >>> 714: kit->C->set_flat_accesses(); >>> 715: ciInlineKlass* vk = inline_klass(); >>> 716: assert(vk->maybe_flat_in_array(), ""); >> >> Please add an assert message > > Same for the other asserts with `..., "");` Done! ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107557072 From liach at openjdk.org Mon May 26 15:28:06 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 May 2025 15:28:06 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v3] In-Reply-To: References: Message-ID: <-lNC5NcV4HZIvS6GQSJMr_40_lRq8ils8CQ0F0j8DWI=.4a017a06-57a0-4175-89c9-fe29d3ad9e3b@github.com> On Fri, 23 May 2025 20:26:57 GMT, Matias Saavedra Silva wrote: >> This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Chen and Dan comments and cleanup I think reflective write for static final is already impossible - at least that is what I know about Method Handles and core reflection. So we probably just need to care about reflective reads. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1465#issuecomment-2910098188 From qamai at openjdk.org Mon May 26 15:30:04 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 26 May 2025 15:30:04 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v9] In-Reply-To: References: Message-ID: <5_jGd3pafJuIUEx3kfdIniA_U4v1TBE0Hwt4TZrYaw0=.cd38081a-8d52-4346-9c13-41cdb5a299fd@github.com> On Mon, 26 May 2025 15:20:21 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: >> >> - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. >> - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. >> - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: >> >> value class StringHolder { >> @NullRestricted >> String s; >> } >> >> value class StringHolderHolder { >> // flatten >> StringHolder v; >> } >> >> Then `v.s` cannot be trusted to be non-null because `v` can be null. >> >> This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. >> >> Please let me know what you think. Thanks very much. > > 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 11 additional commits since the last revision: > > - Merge branch 'lworld' into loadstoreflat > - cast_to_flat_array > - weird layout > - typo > - generalize weird layout > - fix array of nullable empty type > - fix array field calculations > - array > - convert_from_payload > - add tests > - ... and 1 more: https://git.openjdk.org/valhalla/compare/255dc257...e49bbc8c Thanks for your reviews, I have addressed them. I notice there might be some additional issues here, too: - `AddPNode::Value` does not work properly with pointers into arrays. - The type system around arrays seems unsound. We don't have a way to express `maybe_atomic`. I will investigate these further. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1470#issuecomment-2910103305 From qamai at openjdk.org Mon May 26 15:30:05 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 26 May 2025 15:30:05 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v8] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 12:49:46 GMT, Tobias Hartmann wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> weird layout > > src/hotspot/share/opto/inlinetypenode.cpp line 754: > >> 752: Node* ptr = kit->flat_array_element_address(cast, idx, vk, /* null_free */ false, /* not_null_free */ true, /* atomic */ true); >> 753: if (vk->get_field_by_offset(vk->payload_offset(), false) == nullptr && vk->null_marker_offset_in_payload() != 0) { >> 754: // TODO 8357612 Weird layout > > I don't understand why this would be specific to the layout described in [JDK-8357612](https://bugs.openjdk.org/browse/JDK-8357612)? Wouldn't we also hit `vk->get_field_by_offset(vk->payload_offset(), false) == nullptr` when the null marker is at `vk->payload_offset()` which would be totally fine? The null marker at `vk->payload_offset()` is covered by `vk->null_marker_offset_in_payload() == 0`, am I right? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107563425 From qamai at openjdk.org Mon May 26 15:30:06 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 26 May 2025 15:30:06 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v8] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 14:02:50 GMT, Christian Hagedorn wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> weird layout > > src/hotspot/share/opto/parse2.cpp line 129: > >> 127: ciArrayKlass* array_klass = ciArrayKlass::make(vk, /* flat */ true, is_null_free, maybe_atomic); >> 128: const TypeAryPtr* arytype = TypeOopPtr::make_from_klass(array_klass)->isa_aryptr(); >> 129: arytype = arytype->cast_to_exactness(true); > > Nice refactoring! Just noticed this here: IIUC, we don't know whether it's null-free or not here but we still set it to exact (was like that before already) which we should probably not? But it looks like the way we later use the `CastPP` in `make_from_flat_array()`, it does not cause problems because we will feed it into a nullable/not-null-free and null-free cast which is correctly set as exact. That's a nice catch, I have updated it to cast to exactness only when `is_null_free || is_not_null_free` ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1470#discussion_r2107563614 From heidinga at openjdk.org Mon May 26 15:37:04 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 26 May 2025 15:37:04 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v3] In-Reply-To: <-lNC5NcV4HZIvS6GQSJMr_40_lRq8ils8CQ0F0j8DWI=.4a017a06-57a0-4175-89c9-fe29d3ad9e3b@github.com> References: <-lNC5NcV4HZIvS6GQSJMr_40_lRq8ils8CQ0F0j8DWI=.4a017a06-57a0-4175-89c9-fe29d3ad9e3b@github.com> Message-ID: On Mon, 26 May 2025 15:25:28 GMT, Chen Liang wrote: > I think reflective write for static final is already impossible - at least that is what I know about Method Handles and core reflection. So we probably just need to care about reflective reads. Let's confirm that. It used to be possible (and maybe still is) to use `setAccessible` to allow reflective writes to finals. MHs won't unallow static final setters unless they come through the MethodHandles::unreflect door with an `accessible` reflective field ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1465#issuecomment-2910119235 From thartmann at openjdk.org Tue May 27 09:47:03 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 27 May 2025 09:47:03 GMT Subject: [lworld] RFR: 8342488: [lworld] compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java fails after merging jdk-24+13 In-Reply-To: <_0MgTBeyoyorG4Sgh94xJyzCpd9oNIKwCWjx_Pjt1vQ=.dd4b3b8e-469d-4cf4-beeb-e71cb8a06e4b@github.com> References: <_0MgTBeyoyorG4Sgh94xJyzCpd9oNIKwCWjx_Pjt1vQ=.dd4b3b8e-469d-4cf4-beeb-e71cb8a06e4b@github.com> Message-ID: On Mon, 26 May 2025 12:03:26 GMT, Damon Fenacci wrote: > [JDK-8325660](https://bugs.openjdk.org/browse/JDK-8325660) has (temporarily) made `eliminate_boxing` [to false](https://github.com/dafedafe/valhalla/blob/c42af8615277a3c133bf46db0ff1f3a269421790/src/hotspot/share/opto/c2compiler.cpp#L127). This makes `Integer::valueOf` being immediately inlined instead of late-inlined (as in mainline) and this adds 1 allocation after the parsing (value class buffering?). As a consequence there is also no `Incremental Boxing Inline` anymore. > > `ScalarReplacementWithGCBarrierTests.java` currently relies on checking the count of allocations in `AFTER_PARSING` and `INCREMENTAL_BOXING_INLINE`. In the first case the count (1) is wrong and in the second case the phase is not present anymore. > > On the other hand the test has been created to check that one allocation is eliminated by scalar replacement. So, the number of allocations right after parsing and the choice of `Incremental Boxing Inline` as "reference" phase to check for 2 allocation shouldn't matter (up to a certain extent). > > To fix the issue I suggest we remove the count check after parsing and use `PHASEIDEAL_BEFORE_EA` to check for the 2 allocations instead (which is present in both cases). Thanks for working on this, Damon. The fix looks good to me. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1474#pullrequestreview-2870406607 From dfenacci at openjdk.org Tue May 27 13:35:04 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 27 May 2025 13:35:04 GMT Subject: [lworld] RFR: 8342488: [lworld] compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java fails after merging jdk-24+13 In-Reply-To: References: <_0MgTBeyoyorG4Sgh94xJyzCpd9oNIKwCWjx_Pjt1vQ=.dd4b3b8e-469d-4cf4-beeb-e71cb8a06e4b@github.com> Message-ID: On Tue, 27 May 2025 09:44:03 GMT, Tobias Hartmann wrote: >> [JDK-8325660](https://bugs.openjdk.org/browse/JDK-8325660) has (temporarily) made `eliminate_boxing` [to false](https://github.com/dafedafe/valhalla/blob/c42af8615277a3c133bf46db0ff1f3a269421790/src/hotspot/share/opto/c2compiler.cpp#L127). This makes `Integer::valueOf` being immediately inlined instead of late-inlined (as in mainline) and this adds 1 allocation after the parsing (value class buffering?). As a consequence there is also no `Incremental Boxing Inline` anymore. >> >> `ScalarReplacementWithGCBarrierTests.java` currently relies on checking the count of allocations in `AFTER_PARSING` and `INCREMENTAL_BOXING_INLINE`. In the first case the count (1) is wrong and in the second case the phase is not present anymore. >> >> On the other hand the test has been created to check that one allocation is eliminated by scalar replacement. So, the number of allocations right after parsing and the choice of `Incremental Boxing Inline` as "reference" phase to check for 2 allocation shouldn't matter (up to a certain extent). >> >> To fix the issue I suggest we remove the count check after parsing and use `PHASEIDEAL_BEFORE_EA` to check for the 2 allocations instead (which is present in both cases). > > Thanks for working on this, Damon. The fix looks good to me. Thanks for the review @TobiHartmann. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1474#issuecomment-2912533261 From duke at openjdk.org Tue May 27 13:35:05 2025 From: duke at openjdk.org (duke) Date: Tue, 27 May 2025 13:35:05 GMT Subject: [lworld] RFR: 8342488: [lworld] compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java fails after merging jdk-24+13 In-Reply-To: <_0MgTBeyoyorG4Sgh94xJyzCpd9oNIKwCWjx_Pjt1vQ=.dd4b3b8e-469d-4cf4-beeb-e71cb8a06e4b@github.com> References: <_0MgTBeyoyorG4Sgh94xJyzCpd9oNIKwCWjx_Pjt1vQ=.dd4b3b8e-469d-4cf4-beeb-e71cb8a06e4b@github.com> Message-ID: <-Dyv4tqxBj00OQwCc6Nbb5Yx2rOTGpRTzfep5So1bpI=.3c4fbc7a-f938-486c-8ace-daa917a479fc@github.com> On Mon, 26 May 2025 12:03:26 GMT, Damon Fenacci wrote: > [JDK-8325660](https://bugs.openjdk.org/browse/JDK-8325660) has (temporarily) made `eliminate_boxing` [to false](https://github.com/dafedafe/valhalla/blob/c42af8615277a3c133bf46db0ff1f3a269421790/src/hotspot/share/opto/c2compiler.cpp#L127). This makes `Integer::valueOf` being immediately inlined instead of late-inlined (as in mainline) and this adds 1 allocation after the parsing (value class buffering?). As a consequence there is also no `Incremental Boxing Inline` anymore. > > `ScalarReplacementWithGCBarrierTests.java` currently relies on checking the count of allocations in `AFTER_PARSING` and `INCREMENTAL_BOXING_INLINE`. In the first case the count (1) is wrong and in the second case the phase is not present anymore. > > On the other hand the test has been created to check that one allocation is eliminated by scalar replacement. So, the number of allocations right after parsing and the choice of `Incremental Boxing Inline` as "reference" phase to check for 2 allocation shouldn't matter (up to a certain extent). > > To fix the issue I suggest we remove the count check after parsing and use `PHASEIDEAL_BEFORE_EA` to check for the 2 allocations instead (which is present in both cases). @dafedafe Your change (at version 7702086109a661e8fd165b7287bf6761605c87dd) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1474#issuecomment-2912536604 From dfenacci at openjdk.org Tue May 27 15:21:15 2025 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 27 May 2025 15:21:15 GMT Subject: [lworld] Integrated: 8342488: [lworld] compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java fails after merging jdk-24+13 In-Reply-To: <_0MgTBeyoyorG4Sgh94xJyzCpd9oNIKwCWjx_Pjt1vQ=.dd4b3b8e-469d-4cf4-beeb-e71cb8a06e4b@github.com> References: <_0MgTBeyoyorG4Sgh94xJyzCpd9oNIKwCWjx_Pjt1vQ=.dd4b3b8e-469d-4cf4-beeb-e71cb8a06e4b@github.com> Message-ID: On Mon, 26 May 2025 12:03:26 GMT, Damon Fenacci wrote: > [JDK-8325660](https://bugs.openjdk.org/browse/JDK-8325660) has (temporarily) made `eliminate_boxing` [to false](https://github.com/dafedafe/valhalla/blob/c42af8615277a3c133bf46db0ff1f3a269421790/src/hotspot/share/opto/c2compiler.cpp#L127). This makes `Integer::valueOf` being immediately inlined instead of late-inlined (as in mainline) and this adds 1 allocation after the parsing (value class buffering?). As a consequence there is also no `Incremental Boxing Inline` anymore. > > `ScalarReplacementWithGCBarrierTests.java` currently relies on checking the count of allocations in `AFTER_PARSING` and `INCREMENTAL_BOXING_INLINE`. In the first case the count (1) is wrong and in the second case the phase is not present anymore. > > On the other hand the test has been created to check that one allocation is eliminated by scalar replacement. So, the number of allocations right after parsing and the choice of `Incremental Boxing Inline` as "reference" phase to check for 2 allocation shouldn't matter (up to a certain extent). > > To fix the issue I suggest we remove the count check after parsing and use `PHASEIDEAL_BEFORE_EA` to check for the 2 allocations instead (which is present in both cases). This pull request has now been integrated. Changeset: be146831 Author: Damon Fenacci Committer: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/be146831b65fae0083fd9879674c33436245a07e Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod 8342488: [lworld] compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java fails after merging jdk-24+13 Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1474 From matsaave at openjdk.org Thu May 29 16:56:12 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 29 May 2025 16:56:12 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v3] In-Reply-To: References: <-lNC5NcV4HZIvS6GQSJMr_40_lRq8ils8CQ0F0j8DWI=.4a017a06-57a0-4175-89c9-fe29d3ad9e3b@github.com> Message-ID: <_f9wz0psepbxWGbTOOrrfC2Wal-2A2v7unkbR81KPCk=.1de2d4ac-3790-49f6-a767-6106393564de@github.com> On Mon, 26 May 2025 15:34:45 GMT, Dan Heidinga wrote: > > I think reflective write for static final is already impossible - at least that is what I know about Method Handles and core reflection. So we probably just need to care about reflective reads. > > Let's confirm that. It used to be possible (and maybe still is) to use `setAccessible` to allow reflective writes to finals. MHs won't unallow static final setters unless they come through the MethodHandles::unreflect door with an `accessible` reflective field It looks like Chen is correct here, reflective writing of static finals doesn't seem to be possible. At the very least, setAccessible() won't prevent an exception like this: `java.lang.IllegalAccessException: Can not set static final java.lang.String field WriteAfterReadRefl1.F1__STRICT to java.lang.String` With regards to your suggested test cases, the best I can do at the moment is add the first one on that list. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1465#issuecomment-2919999720 From heidinga at openjdk.org Thu May 29 17:02:49 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Thu, 29 May 2025 17:02:49 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v3] In-Reply-To: References: Message-ID: <3CfGHotENFqsd4J0WzdYhDT0xEWPBq_kUfxvygK45b0=.dfd12639-a857-40ea-9766-eadbea2e5ded@github.com> On Fri, 23 May 2025 20:26:57 GMT, Matias Saavedra Silva wrote: >> This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Chen and Dan comments and cleanup That's great! It removes a bunch cases we'll never have to worry about ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1465#issuecomment-2920006652 From matsaave at openjdk.org Thu May 29 17:02:48 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 29 May 2025 17:02:48 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v4] In-Reply-To: References: Message-ID: <_mKwhIRfQ19M9aJI-AmENBn37zdkEJsDvZ2FlEZAtX4=.72f48ede-743b-4c05-b174-4dae79574525@github.com> > This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. 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 seven commits: - Merge branch 'lworld' into implement_strict_statics_8349945 - Dan comments and new test case - Chen and Dan comments and cleanup - Copyrights - Added reflective tests and problem listed test - Added tests - 8349945: Implement strict static fields (proposed JVM feature) ------------- Changes: https://git.openjdk.org/valhalla/pull/1465/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1465&range=03 Stats: 1139 lines in 35 files changed: 1113 ins; 0 del; 26 mod Patch: https://git.openjdk.org/valhalla/pull/1465.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1465/head:pull/1465 PR: https://git.openjdk.org/valhalla/pull/1465 From matsaave at openjdk.org Thu May 29 17:05:04 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 29 May 2025 17:05:04 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v3] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 20:26:57 GMT, Matias Saavedra Silva wrote: >> This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Chen and Dan comments and cleanup A subtle change got swept up in the merge: `StrictStaticFieldsTest.java` remains problem listed but is now associated with the bug [JDK-8357141](https://bugs.openjdk.org/browse/JDK-8357141) ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1465#issuecomment-2920019999 From matsaave at openjdk.org Thu May 29 19:04:45 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 29 May 2025 19:04:45 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v5] In-Reply-To: References: Message-ID: > Updates to javac prevent it from creating classes with improper uses of strict fields. Additionally, non-final strict fields are now allowed so `StrictFinalInstanceFieldsTest.java` needs to updated with new test cases. This patch adds new cases for final and non-final stricts as well as negative test cases using asmtools that check improper use of strict fields and early larval stack map frames. > > During testing, it was revealed that the new verify errors added in [JDK-8354694](https://bugs.openjdk.org/browse/JDK-8354694) do not work properly so a fix is included in this patch. > > Note: This cannot be integrated until jtreg is updated with a recent build of asmtools which can handle strict fields and can generate early_larval frames. 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 nine commits: - Merge branch 'lworld' into new_strict_tests_8352068 - Dan comment, new test case, and test refactor - Merge branch 'lworld' into new_strict_tests_8352068 - Added bug number to problem listed test - Problem list test until jtreg is updated - Remove old test - Added copyright - Added more positive test cases - [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 ------------- Changes: https://git.openjdk.org/valhalla/pull/1449/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1449&range=04 Stats: 1808 lines in 11 files changed: 1546 ins; 262 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1449.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1449/head:pull/1449 PR: https://git.openjdk.org/valhalla/pull/1449 From matsaave at openjdk.org Thu May 29 19:47:34 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 29 May 2025 19:47:34 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v6] In-Reply-To: References: Message-ID: > Updates to javac prevent it from creating classes with improper uses of strict fields. Additionally, non-final strict fields are now allowed so `StrictFinalInstanceFieldsTest.java` needs to updated with new test cases. This patch adds new cases for final and non-final stricts as well as negative test cases using asmtools that check improper use of strict fields and early larval stack map frames. > > During testing, it was revealed that the new verify errors added in [JDK-8354694](https://bugs.openjdk.org/browse/JDK-8354694) do not work properly so a fix is included in this patch. > > Note: This cannot be integrated until jtreg is updated with a recent build of asmtools which can handle strict fields and can generate early_larval frames. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Improved logging and TryCatchChildBad ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1449/files - new: https://git.openjdk.org/valhalla/pull/1449/files/c981a737..f7651d51 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1449&range=05 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1449&range=04-05 Stats: 83 lines in 2 files changed: 34 ins; 43 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/1449.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1449/head:pull/1449 PR: https://git.openjdk.org/valhalla/pull/1449 From rriggs at openjdk.org Thu May 29 19:48:45 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 29 May 2025 19:48:45 GMT Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in Class, Objects, and document limitations of value objects [v8] In-Reply-To: References: Message-ID: > Add APINote and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. > Simplified WeakHashMap javadoc updates for IdentityException. > Added note to System.identityHashCode to include value objects. > Added to class javadoc for IdentityHashMap for value objects. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'lworld' into 8346307-throws-identityexception - Merge branch 'lworld' into 8346307-throws-identityexception - Merge - Merge branch 'lworld' into 8346307-throws-identityexception - Merge branch 'lworld' into 8346307-throws-identityexception - Merge branch 'lworld' into 8346307-throws-identityexception - Merge - Expand javadoc reference to Reference - Merge remote-tracking branch 'refs/remotes/origin/8346307-throws-identityexception' into 8346307-throws-identityexception - Merge branch 'openjdk:lworld' into 8346307-throws-identityexception - ... and 2 more: https://git.openjdk.org/valhalla/compare/be146831...b6cd55b5 ------------- Changes: https://git.openjdk.org/valhalla/pull/1327/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1327&range=07 Stats: 250 lines in 11 files changed: 193 ins; 14 del; 43 mod Patch: https://git.openjdk.org/valhalla/pull/1327.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1327/head:pull/1327 PR: https://git.openjdk.org/valhalla/pull/1327 From matsaave at openjdk.org Thu May 29 19:50:05 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 29 May 2025 19:50:05 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v4] In-Reply-To: References: <8sbj-SGuIXuLwGqBMuR_7aOzGgJ-GAcvEg0pJ5VsgG8=.cd427457-7d61-4d8f-b443-701e338128df@github.com> Message-ID: On Thu, 22 May 2025 18:37:20 GMT, Dan Heidinga wrote: > Maintaining jasm and jcod files can be a pain. The less those files contain, the better as it is less classfile / bytecode to try to build in your head while debugging. > > One option for set of common tests like this that all have x & y fields, as well as getter methods and a complicated toString, is to use an abstract parent class: > > ``` > abstract JasmParent extends Parent { > abstract int get_x(); > abstract int get_y(); > > public String toString() { > return "x: " + get_x() + "\n" + "y: " + get_y() + "\n" + super.toString(); > } > } > ``` > > and have all the .jasm file class extend this class instead of using Parent directly. This will move all the bootstrap methods & indy related code out of jasm files and hopefully result in something simpler to look at. > > Another option is to keep Parent as it is, but have its toString() use Reflection like: `this.getClass().getDeclaredFeilds()` to find all the fields and print them. Any solution that moves code out of jasm / jcod files makes the code easier to maintain and understand longterm Thanks for this suggestion! I've opted to use reflection for toString() so I can get rid of get_x() and get_y(). The jasm and jcod files have been cleaned up and now include the equivalent java source code as a comment to better illustrate what is being tested. I snuck in a logging improvement as well. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1449#issuecomment-2920412790 From heidinga at openjdk.org Thu May 29 20:23:02 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Thu, 29 May 2025 20:23:02 GMT Subject: [lworld] RFR: 8352068: [lworld] test StrictFinalInstanceFieldsTest.java needs to be updated after fix for JDK-8351951 [v6] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 19:47:34 GMT, Matias Saavedra Silva wrote: >> Updates to javac prevent it from creating classes with improper uses of strict fields. Additionally, non-final strict fields are now allowed so `StrictFinalInstanceFieldsTest.java` needs to updated with new test cases. This patch adds new cases for final and non-final stricts as well as negative test cases using asmtools that check improper use of strict fields and early larval stack map frames. >> >> During testing, it was revealed that the new verify errors added in [JDK-8354694](https://bugs.openjdk.org/browse/JDK-8354694) do not work properly so a fix is included in this patch. >> >> Note: This cannot be integrated until jtreg is updated with a recent build of asmtools which can handle strict fields and can generate early_larval frames. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Improved logging and TryCatchChildBad lgtm ------------- Marked as reviewed by heidinga (no project role). PR Review: https://git.openjdk.org/valhalla/pull/1449#pullrequestreview-2879510634 From rriggs at openjdk.org Thu May 29 21:09:01 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 29 May 2025 21:09:01 GMT Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in Class, Objects, and document limitations of value objects [v8] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 19:48:45 GMT, Roger Riggs wrote: >> Add APINote and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. >> Simplified WeakHashMap javadoc updates for IdentityException. >> Added note to System.identityHashCode to include value objects. >> Added to class javadoc for IdentityHashMap for value objects. > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge > - Expand javadoc reference to Reference > - Merge remote-tracking branch 'refs/remotes/origin/8346307-throws-identityexception' into 8346307-throws-identityexception > - Merge branch 'openjdk:lworld' into 8346307-throws-identityexception > - ... and 2 more: https://git.openjdk.org/valhalla/compare/be146831...b6cd55b5 The PreviewNote tag has been delayed, the plan is to integrate these changes until it settles down. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1327#issuecomment-2920584281 From liach at openjdk.org Fri May 30 00:38:05 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 30 May 2025 00:38:05 GMT Subject: [lworld] RFR: 8349945: Implement strict static fields (proposed JVM feature) [v4] In-Reply-To: <_mKwhIRfQ19M9aJI-AmENBn37zdkEJsDvZ2FlEZAtX4=.72f48ede-743b-4c05-b174-4dae79574525@github.com> References: <_mKwhIRfQ19M9aJI-AmENBn37zdkEJsDvZ2FlEZAtX4=.72f48ede-743b-4c05-b174-4dae79574525@github.com> Message-ID: On Thu, 29 May 2025 17:02:48 GMT, Matias Saavedra Silva wrote: >> This patch enables and implements verification for fields with the ACC_STATIC and ACC_STRICT modifiers. To enforce strictness on static fields, the reads and writes on the field are tracked dynamically to ensure that the field is written before being read and written to before. > > 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 seven commits: > > - Merge branch 'lworld' into implement_strict_statics_8349945 > - Dan comments and new test case > - Chen and Dan comments and cleanup > - Copyrights > - Added reflective tests and problem listed test > - Added tests > - 8349945: Implement strict static fields (proposed JVM feature) test/hotspot/jtreg/runtime/valhalla/inlinetypes/verifier/StrictStaticTests.java line 150: > 148: System.out.println(vererrs); > 149: var cm = ClassFile.of().parse(classBytes); > 150: System.out.println("" + cm + cm.fields() + cm.methods() + cm.methods().get(0).code().orElseThrow().elementList()); Suggestion: System.out.println(cm.toDebugString()); Note we can't fail here: ClassFile.verify is not up-to-date with strict fields. I don't know who originally wrote the `VerificationTable` code that is supposed to be on parity with `stackMapTable.cpp`, but that code is complex and is bound to diverge from whatever we have in the C++ code there. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1465#discussion_r2114943440 From liach at openjdk.org Fri May 30 01:36:08 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 30 May 2025 01:36:08 GMT Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in Class, Objects, and document limitations of value objects [v8] In-Reply-To: References: Message-ID: <4a1JcQIBa_sO7jWFYgqsXX_MJfDYsZQYU106AFKWaZE=.81cdeefc-c9fb-4ca9-b22b-c72be647c7f8@github.com> On Thu, 29 May 2025 19:48:45 GMT, Roger Riggs wrote: >> Add APINote and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. >> Simplified WeakHashMap javadoc updates for IdentityException. >> Added note to System.identityHashCode to include value objects. >> Added to class javadoc for IdentityHashMap for value objects. > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge branch 'lworld' into 8346307-throws-identityexception > - Merge > - Expand javadoc reference to Reference > - Merge remote-tracking branch 'refs/remotes/origin/8346307-throws-identityexception' into 8346307-throws-identityexception > - Merge branch 'openjdk:lworld' into 8346307-throws-identityexception > - ... and 2 more: https://git.openjdk.org/valhalla/compare/be146831...b6cd55b5 test/jdk/java/lang/Class/GenericStringTest.java line 60: > 58: "public abstract class java.lang.Enum>"), > 59: new PlatformTestCase(java.util.Map.class, > 60: "public abstract value interface java.util.Map"), Hmm, isn't value redundant on interfaces? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1327#discussion_r2114990571 From qamai at openjdk.org Fri May 30 19:56:22 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 30 May 2025 19:56:22 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v10] In-Reply-To: References: Message-ID: > Hi, > > This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: > > - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. > - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. > - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: > > value class StringHolder { > @NullRestricted > String s; > } > > value class StringHolderHolder { > // flatten > StringHolder v; > } > > Then `v.s` cannot be trusted to be non-null because `v` can be null. > > This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. > > Please let me know what you think. Thanks very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: remove ptr_type parameters ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1470/files - new: https://git.openjdk.org/valhalla/pull/1470/files/e49bbc8c..0a945fe6 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=09 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1470&range=08-09 Stats: 206 lines in 5 files changed: 38 ins; 118 del; 50 mod Patch: https://git.openjdk.org/valhalla/pull/1470.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1470/head:pull/1470 PR: https://git.openjdk.org/valhalla/pull/1470 From qamai at openjdk.org Sat May 31 10:25:05 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sat, 31 May 2025 10:25:05 GMT Subject: [lworld] RFR: 8357474: [lworld] Consolidate load/store flat inline types [v10] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 19:56:22 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch consolidates loading and storing of flat inline types. This makes it so that `make_from_flat` and `store_flat` will take a pointer to the target location. `make_from_flat_array` and `store_flat_array` are split out into their own methods which receive an `idx` parameter. This also fixes some issues I theorycrafted: >> >> - Improper loading/storing of atomic elements in a non-atomic container. This is not supported at the moment but it would be great to prepare for it. >> - `is_naturally_atomic` checks `nof_declared_nonstatic_fields`, which is incorrect if the sole field has multiple fields. I refactored it into `ciInlineKlass`, the decision to do atomic loads/stores is also delegated to the callee, the caller only needs to know whether the operations act as if they are atomic, not whether they are actually executed atomically. >> - `null_free` of an oop can only be trusted if the container itself is null-free. For example this case: >> >> value class StringHolder { >> @NullRestricted >> String s; >> } >> >> value class StringHolderHolder { >> // flatten >> StringHolder v; >> } >> >> Then `v.s` cannot be trusted to be non-null because `v` can be null. >> >> This also allows straightforward implementation of https://bugs.openjdk.org/browse/JDK-8349110. >> >> Please let me know what you think. Thanks very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > remove ptr_type parameters I have reworked the functions a little bit to remove the `ptr_type` parameters as well as remove the need for special cases for types without a real field at the start of their payload. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1470#issuecomment-2924878770 From qamai at openjdk.org Sat May 31 10:54:54 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sat, 31 May 2025 10:54:54 GMT Subject: [lworld] RFR: 8353432: [lworld] Deoptimization needs to handle nullable, flat fields in non-value class holders Message-ID: <5QYVEiXErBbaSDQp45zYrczU1wUayIWebquNEN0hfX8=.4998cbc9-779b-441e-aa61-6c3caa6f48da@github.com> Hi, This patch adds handling of nullable flat fields in non-value class holder. Currently, we add all the fields to the safepoint, then add all the null markers. I decide to change this to adding the null marker of a flat field right after all the subfields of it. It makes the shape similar to how we pass nullable flat fields in the ABI, as well as simplifies the implementation since we do not have to keep track of all null markers when traversing the object payload. Please take a look and leave your reviews, thanks a lot. ------------- Commit messages: - handle nullable flat fields in safepoint Changes: https://git.openjdk.org/valhalla/pull/1478/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1478&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353432 Stats: 317 lines in 8 files changed: 141 ins; 112 del; 64 mod Patch: https://git.openjdk.org/valhalla/pull/1478.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1478/head:pull/1478 PR: https://git.openjdk.org/valhalla/pull/1478