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