From asotona at openjdk.org Thu Aug 1 08:28:58 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 1 Aug 2024 08:28:58 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v12] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: <1dNT-SFR-DcjL7gPSupnYJiqql-SnyUmVLqR4oaH8PM=.9231128c-4630-45d4-8c0e-eed41e0cd051@github.com> > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Fixd lifting of split exception table (with internal transitions) imediatelly followed by handler + avoided lifting and generation of empty exception regions ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/0140e073..c1ac080e Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=11 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=10-11 Stats: 42 lines in 3 files changed: 24 ins; 8 del; 10 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Thu Aug 1 08:54:30 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 1 Aug 2024 08:54:30 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v13] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed generation of exception regions with implicit exits only ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/c1ac080e..401b4380 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=12 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=11-12 Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Thu Aug 1 14:49:19 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 1 Aug 2024 14:49:19 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v14] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Implemented BytecodeLift::extractExceptionHandlers to filter and split exception handlers by each detected external entry + added TestBytecode::finallyWithLoop test ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/401b4380..4983f05f Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=13 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=12-13 Stats: 85 lines in 3 files changed: 79 ins; 3 del; 3 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From rotanolexandr842 at gmail.com Thu Aug 1 19:44:23 2024 From: rotanolexandr842 at gmail.com (Olexandr Rotan) Date: Thu, 1 Aug 2024 22:44:23 +0300 Subject: Is LINQ-like API considered to be included in JDK? Message-ID: Greetings. Continuing my work on LINQ-like API for Java, I am currently on the crossroads regarding including a several dependencies into my project. Thing that bothers me the most is the fact that if jdk plans to integrate some kind of feature like linq, I would strongly prefer using plain java so my code could provide more insights from the point of view that is the closest to jdk devs themself, and even could become a foundation of such api in the future. I know that jdk prefers to ship APIs with features that utilize them (like streams and optionals with lambdas), so I figured there is a pretty significant chance this could be an intention So I would like to ask, is there any plans for introducing LINQ-like API into jdk, in java.sql for example? -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Thu Aug 1 21:01:21 2024 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Aug 2024 21:01:21 +0000 Subject: Is LINQ-like API considered to be included in JDK? In-Reply-To: References: Message-ID: <60A6F16E-679D-415D-8D80-576FDB3400D1@oracle.com> Hi, There are currently no plans to do. Babylon can enable library developers to implement LINQ-like APIs. Near term such efforts are importing to provide feedback to Babylon. Longer term library developers are empowered to do their own thing, without the heavy design, release, and support constraints of the Java platform. Over time we can look at what library developers do. Maybe some key aspects of such libraries could be brought into the JDK, but it?s far too early to say what, if any, at the moment. Paul. > On Aug 1, 2024, at 12:44 PM, Olexandr Rotan wrote: > > Greetings. Continuing my work on LINQ-like API for Java, I am currently on the crossroads regarding including a several dependencies into my project. > > Thing that bothers me the most is the fact that if jdk plans to integrate some kind of feature like linq, I would strongly prefer using plain java so my code could provide more insights from the point of view that is the closest to jdk devs themself, and even could become a foundation of such api in the future. I know that jdk prefers to ship APIs with features that utilize them (like streams and optionals with lambdas), so I figured there is a pretty significant chance this could be an intention > > So I would like to ask, is there any plans for introducing LINQ-like API into jdk, in java.sql for example? > From paul.sandoz at oracle.com Thu Aug 1 22:53:12 2024 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Aug 2024 22:53:12 +0000 Subject: Newbie dumb question In-Reply-To: References: Message-ID: <09719E0B-1E60-4A8B-B14A-4927DA511E27@oracle.com> Hi Archie, In our current approach code to be reflected over needs to be explicitly identified. You have to opt in and grant permission that the code you wrote can be reflected over and accessed by something else and potentially interpreted differently, perhaps with explicit knowledge of that. Such reflection is not transitive - the code of methods that are invoked are not reflected over, since you may not have permission to do so. We are not generally trying to support the transformation of whole Java programs to other programming platforms (similar I guess to transpilation). Nor are we trying to enhance the Java platform to provide a universal intermediate language. A main goal of Babylon is to broaden Java?s reach to foreign programming models. Arguably a more realistic and less ambitious goal :-) In that respect reflected code is likely to be scoped and constrained to that which is needed, and which may differ in terms of the Java programming model and was written with that knowledge in mind. This is the case for the support of GPU kernels, where use of certain language constructs and APIs (such as HashMap) do not translate very well to say CUDA or PTX - we are not trying to preserve the Java programming model and Java APIs when executing on the GPU. I think the same applies, albeit with different constraints, to many other use cases - not all code is parallel suitable code, not all code is differentiable code, not all code is translatable to SQL statements, not all code represents a machine learning model. At the moment we also cannot model all Java language constructs, local class declarations are particularly problematic. We are striving to model as much as we can (nearly all expressions and statements are currently modeled to some degree of fidelity), but we may hit limits in terms of complexity or unnecessary duplication with existing information in class files, such as class declarations. For the analysis of reflected code I think we are in reasonable shape. Note that we are not limiting ourselves to the source compiler producing code models from its internal AST. We are also actively exploring lifting code models from bytecode, assuming one has access to class files. That may be more in the spirit of what you are thinking if bytecode is not suitable for such purposes. However, there are many traps in doing so. Much of Java?s core libraries are naturally written with Java in mind and the workings of the JVM (what else would we have in mind :-) ), trying to reinterpret that differently, or emulating, will be problematic. Paul. > On Jul 24, 2024, at 7:35 AM, Archie Cobbs wrote: > > Hi, > > Got a newbie dumb question... > > Why not have the compiler mandatorily generate code models for all class files? > > Motivation: I'm interested in how Babylon could facilitate the general use case of remote execution, e.g. for database access (i.e., moving the code to the data vs. the other way around like we do today), high-performance computing, holomorphic encryption, or some other purpose: > ? > We want to describe a computation/algorithm that will execute on some remote, non-Java runtime > ? We want developers to be able to write the computation in completely normal Java and have it translated and serialized > ? "Normal" includes the use of usual classes like java.util.HashMap, Guava utility classes, etc. > This is similar to the GPU use case except for #3 - AFAICT, with current Babylon your reflected code model doesn't include classes like HashMap they aren't code-reflected - correct? > > In an ideal world, it should be possible to access the code model for every non-native method, so there are no "holes" in your view of the code. Otherwise, when coding up your algorithm you'll have one hand tightly tied behind your back - no collections, no streams, no Guava, no Apache commons-foobar, etc. > > Then you could really go to town optimizing your code - virtual dispatch becomes non-virtual, escape analysis eliminates heap allocations, lots of methods inlined, etc. You could take a huge Java processing pipeline and lower it down to target a relatively simplistic sandbox-style virtual machine environment (could be WASM, SQL stored procedure, or even machine code). For scenarios where the pipeline is going to be executed frequently (e.g., database query) it is well worth it to pay this one-time, upfront cost for these extensive optimizations. > > Of course, the code couldn't do native code things like Thread.start() without some kind of shim... and there may be more native code "gotchas" lying around in the standard Java libraries than one might think. But I'm guessing most stuff you would want to send over the network for the above examples of remote execution would need few if any native methods. > > Side note: This situation reminds me of when I first switched from svn to git and gasped at the notion that git stores the entire revision history on your local disk. It turns out to work great, and all the scary seeming downsides are not an issue (e.g., space is not an issue with today's disks and the fact that git just ZIPs up the past history into giant "packs"). Moreover, there are important upsides like speed, private branches, repo portability, server/client symmetry, the ability to work on an airplane, etc. > > Similarly, I'm sure there are a lot of "obvious" reasons to not make code models mandatory, like disk space, compiler speed, and fear of mass panic. But in the end these may also be non-issues, especially if having code models available for all classes opens up a lot of use cases that aren't available now. Maybe there are some simple things that could be done to quiet the naysayers, like storing the JRE code models in a separate JAR file, etc. > > Put another way, I think we need to think bigger... e.g., project Babylon could position Java as a universal "starting language" so to speak. > > -Archie > > -- > Archie L. Cobbs From paul.sandoz at oracle.com Thu Aug 1 23:27:59 2024 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Aug 2024 23:27:59 +0000 Subject: Reflecting method references In-Reply-To: References: Message-ID: > On Jul 26, 2024, at 12:20 PM, Tagir Valeev wrote: > > Hello! > > I'm continuing working on my toy decompiler-interpreter-asserts-library and trying to restore a method reference from the code model. I've noticed that there's a LambdaOp.methodReference() method. However, it works for only one method reference case: instance method without qualifier expression. In other cases, it returns null. More specifically: > String::isEmpty -- works > Integer::valueOf -- doesn't work > "xyz"::equals -- doesn't work > String::new -- doesn't work > > Probably it's not implemented yet and still in the queue, I just wanted to ensure that current behavior is not final. Correct, work in progress! I added that quickly as an experiment and it seems worthwhile pursuing further i.e. could this lambda operation have modeled a method reference? (Originally we modeled method references directly, but it was easier to manage by desugaring.) > > Concentrating on a single working case (String::isEmpty), I need to construct a functional lambda. We don't need to capture anything here, which simplifies things a bit, but still the construction takes some effort. My best attempt is the following (error handling removed for brevity): > > CoreOp.InvokeOp invokeOp = lambdaOp.methodReference().get(); > MethodHandle handle = invokeOp.invokeDescriptor().resolveToHandle(lookup); > Class fnClass = toClass(lambdaOp.functionalInterface()); > // It looks like finding SAM is necessary. Is there an easier way of getting it? Yeah, I have also wanted some public method for this, there is an implementation buried in the bytecode generator and MethodHandleProxies. Methods on Object needs to be skipped. > Method sam = Stream.of(fnClass.getMethods()) > .filter(m -> Modifier.isAbstract(m.getModifiers())).findFirst().get(); > MethodType samMethodType = MethodType.methodType(sam.getReturnType(), sam.getParameterTypes()); > MethodType dynamicType = toMethodType(lambdaOp.invokableType()); > CallSite callSite = LambdaMetafactory.metafactory(lookup, sam.getName(), MethodType.methodType(fnClass), > samMethodType, handle, dynamicType); > Object lambda = callSite.dynamicInvoker().invoke(); > ... use lambda ... > > The toMethodType() is the following helper: > > private MethodType toMethodType(FunctionType functionType) { > Class rType = toClass(functionType.returnType()); > Class[] pTypes = functionType.parameterTypes().stream().map(this::toClass).toArray(Class[]::new); > return MethodType.methodType(rType, pTypes); > } > > Which in turn uses another helper toClass to convert TypeElement to Class > > So, quite a lot of code. The first thing which could be improved is providing toMethodType(lookup) instance method directly inside FunctionType. It could be nice to have a convenient bridge between TypeElement world and MethodType world. > There's a method on MethodRef that can help: static MethodTypeDesc toNominalDescriptor(FunctionType t) { I placed it there, temporarily, because I was uncertain if we should place Java specific functionality on FunctionType. WDYT? > But probably it would be reasonable to resolve a LambdaOp directly to CallSite, encapsulating all this stuff I write? In my application, I don't need to do something fancy with nested lambdas, I just want to run them normally. Not sure, but probably this could be reasonable in other applications as well. Just something to think about. > Can you share some details as to why you need this? Do you also intend to also support lambda expressions? I am wondering if we can leverage functionality in the bytecode generator and expose it as functionality e.g. for any LambdaOp generate a CallSite for it, which may include generating bytecode for the lambda if its not like a method reference? Paul. From psandoz at openjdk.org Fri Aug 2 00:58:44 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 2 Aug 2024 00:58:44 GMT Subject: [code-reflection] RFR: 8337157: Second operand to array.load should be an int In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 05:49:49 GMT, Mourad Abbay wrote: > Convert array access indexing expression to int. Marked as reviewed by psandoz (Lead). ------------- PR Review: https://git.openjdk.org/babylon/pull/194#pullrequestreview-2214307519 From archie.cobbs at gmail.com Fri Aug 2 01:37:31 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 1 Aug 2024 20:37:31 -0500 Subject: Newbie dumb question In-Reply-To: <09719E0B-1E60-4A8B-B14A-4927DA511E27@oracle.com> References: <09719E0B-1E60-4A8B-B14A-4927DA511E27@oracle.com> Message-ID: Hi Paul, Thanks for the thoughtful reply. > We are not generally trying to support the transformation of whole Java > programs to other programming platforms (similar I guess to transpilation). > Nor are we trying to enhance the Java platform to provide a universal > intermediate language. A main goal of Babylon is to broaden Java?s reach to > foreign programming models. Arguably a more realistic and less ambitious > goal :-) > That makes sense for the concrete use cases that are being talked about, and it's a prudent conservative approach to getting started. I just also have a gut feeling that there could eventually be a lot more to this than is clear now, analogous to all the ways the JVM is being used today beyond just the Java language. I guess it can come over time - gotta start somewhere. Lifting from bytecode can be an intermediate workaround for those ideas, so I guess we'll see what people may come up with in any case. > Much of Java?s core libraries are naturally written with Java in mind and > the workings of the JVM (what else would we have in mind :-) ), trying to > reinterpret that differently, or emulating, will be problematic. Sure, maybe lots of code is highly optimized for running on the JVM, but as long as the code doesn't (indirectly) invoke any native methods you should still be able to slurp it into whatever giant transformation you're doing. Hopefully the optimizations would get sophisticated enough over time so that those original details would come out in the wash out so to speak. Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From asotona at openjdk.org Fri Aug 2 08:44:29 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 2 Aug 2024 08:44:29 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v15] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed LshlOp generation ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/4983f05f..6a50b0e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=14 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Fri Aug 2 10:10:59 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 2 Aug 2024 10:10:59 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v16] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed INDY lifting of BSMs with vararg parameter ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/6a50b0e6..30790163 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=15 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=14-15 Stats: 46 lines in 2 files changed: 27 ins; 15 del; 4 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Fri Aug 2 12:22:13 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 2 Aug 2024 12:22:13 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v17] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed BytecodeLift::extractExceptionHandlers ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/30790163..f19605a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=16 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=15-16 Stats: 28 lines in 1 file changed: 8 ins; 1 del; 19 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Fri Aug 2 13:03:19 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 2 Aug 2024 13:03:19 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v18] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Do not cache class constants in BytecodeLift ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/f19605a2..26b38f3a Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=17 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=16-17 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Fri Aug 2 13:48:58 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 2 Aug 2024 13:48:58 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v19] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed BytecodeGenerator NPE when result is used twice in one operands + test ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/26b38f3a..26073d96 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=18 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=17-18 Stats: 16 lines in 3 files changed: 13 ins; 0 del; 3 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From mcimadamore at openjdk.org Fri Aug 2 15:03:50 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 2 Aug 2024 15:03:50 GMT Subject: [code-reflection] RFR: 8337156: Lowering of switch expressions that throw on no matching [v2] In-Reply-To: References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: On Thu, 25 Jul 2024 09:29:10 GMT, Maurizio Cimadamore wrote: >> Mourad Abbay 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 'code-reflection' into 8337156 >> - Update the lowering of switch expression to throw Match Exception if no label applies > > src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 865: > >> 863: if (isLabelBody) { >> 864: Block.Builder expression = blocks.get(i + 1); >> 865: boolean isLastLabel = i == blocks.size() - 2; > > This is a bit tricky. The details on when a default case is added with a `throw` are spread between `TransPatterns` and `Lower`. Basically: > * `TransPatterns` will turn an unconditional pattern (see below) into a default label > * `Lower` will add a `default` throwing label, only if one isn't there > * the type of the exception is `IncompatibleClassChangeError` if selector is an enum, or `MatchException` otherwise. > > An unconditional pattern is a pattern whose type is guaranteed to always match the selector expression (e.g. because the type of the pattern is a supertype of the type of the selector expression). This property should be captured by `tree.hasUnconditionalPattern`. In fact, that flag seems to be set also when the switch has a `default` label. So just checking that flag should suffice (but please double check). Actually... this code is about a lowering step... I think the best way would be to automatically insert a `default` label when generating the code model in `ReflectMethods`. At that point, as explained, the compiler knows which switches are "unconditional" and which are not. We could maybe reflect this piece of info in the model, but I think it's actually better to remove edge cases and just add the missing case. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/195#discussion_r1701971303 From asotona at openjdk.org Fri Aug 2 16:04:13 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 2 Aug 2024 16:04:13 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v20] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: <70yHqg0utubW7xL2KlCBo3SLjh4pCNHKEXndhdXjB_s=.6af35e17-3a1a-4cc7-9341-6dc492a0c3d6@github.com> > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: SlotSSA modified to avoid adding block parameters to catch blocks ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/26073d96..88c55506 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=19 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=18-19 Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From psandoz at openjdk.org Fri Aug 2 19:51:44 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 2 Aug 2024 19:51:44 GMT Subject: [code-reflection] RFR: 8337155: Support expressions returning boxed booleans for the condition blocks of if/do/while In-Reply-To: References: Message-ID: <4wQkYo-7vi2WmYeWqXBynKRRu8K_W75frd3qGoDx_JE=.7fa2b51a-7633-47c6-bdde-825cbbff9d6d@github.com> On Thu, 25 Jul 2024 03:15:57 GMT, Mourad Abbay wrote: > Condition body of if or while or do-while should yield a boolean value Marked as reviewed by psandoz (Lead). src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1649: > 1647: Value last = toValue(cond); > 1648: // Yield the boolean result of the condition > 1649: last = convert(last, typeElementToType(JavaType.BOOLEAN)); Remove the "@@@ cond.type ..." comment above, same for other places. ------------- PR Review: https://git.openjdk.org/babylon/pull/193#pullrequestreview-2216304411 PR Review Comment: https://git.openjdk.org/babylon/pull/193#discussion_r1702260049 From psandoz at openjdk.org Fri Aug 2 19:55:51 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 2 Aug 2024 19:55:51 GMT Subject: [code-reflection] RFR: 8337156: Lowering of switch expressions that throw on no matching [v2] In-Reply-To: References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: <5NLqEydIPULlSeq0n593L0p7Jj6HHr_yCU_wH6Ywj_M=.c23314cc-fde7-4d67-9396-706480e97e28@github.com> On Mon, 29 Jul 2024 18:55:22 GMT, Mourad Abbay wrote: >> Update the lowering of switch expression to throw Match Exception if no label applies. > > Mourad Abbay 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 'code-reflection' into 8337156 > - Update the lowering of switch expression to throw Match Exception if no label applies test/jdk/java/lang/reflect/code/TestSwitchExpressionOp2.java line 59: > 57: } > 58: > 59: private static void writeModel(CoreOp.FuncOp f, OutputStream os, OpWriter.Option... options) { Why do you need to print out the model without location? ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/195#discussion_r1702263242 From psandoz at openjdk.org Fri Aug 2 19:59:56 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 2 Aug 2024 19:59:56 GMT Subject: [code-reflection] RFR: 8337156: Lowering of switch expressions that throw on no matching [v2] In-Reply-To: References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: On Fri, 2 Aug 2024 15:00:57 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 865: >> >>> 863: if (isLabelBody) { >>> 864: Block.Builder expression = blocks.get(i + 1); >>> 865: boolean isLastLabel = i == blocks.size() - 2; >> >> This is a bit tricky. The details on when a default case is added with a `throw` are spread between `TransPatterns` and `Lower`. Basically: >> * `TransPatterns` will turn an unconditional pattern (see below) into a default label >> * `Lower` will add a `default` throwing label, only if one isn't there >> * the type of the exception is `IncompatibleClassChangeError` if selector is an enum, or `MatchException` otherwise. >> >> An unconditional pattern is a pattern whose type is guaranteed to always match the selector expression (e.g. because the type of the pattern is a supertype of the type of the selector expression). This property should be captured by `tree.hasUnconditionalPattern`. In fact, that flag seems to be set also when the switch has a `default` label. So just checking that flag should suffice (but please double check). > > Actually... this code is about a lowering step... I think the best way would be to automatically insert a `default` label when generating the code model in `ReflectMethods`. At that point, as explained, the compiler knows which switches are "unconditional" and which are not. We could maybe reflect this piece of info in the model, but I think it's actually better to remove edge cases and just add the missing case. Yes, that seems a better approach given the knowledge the compiler has. For switch ops created manually we anyway cannot guarantee Java program behavior, same for other operations too. FWIW modeling of `if/else if/else` statements will always add an `else` if not explicitly present with the default behavior that yields nothing. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/195#discussion_r1702266872 From psandoz at openjdk.org Fri Aug 2 20:14:42 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 2 Aug 2024 20:14:42 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v20] In-Reply-To: <70yHqg0utubW7xL2KlCBo3SLjh4pCNHKEXndhdXjB_s=.6af35e17-3a1a-4cc7-9341-6dc492a0c3d6@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> <70yHqg0utubW7xL2KlCBo3SLjh4pCNHKEXndhdXjB_s=.6af35e17-3a1a-4cc7-9341-6dc492a0c3d6@github.com> Message-ID: On Fri, 2 Aug 2024 16:04:13 GMT, Adam Sotona wrote: >> Bytecode round 9 contains following improvements: >> - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` >> - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) >> - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` >> - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added >> - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` >> - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types >> >> `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > SlotSSA modified to avoid adding block parameters to catch blocks src/java.base/share/classes/java/lang/reflect/code/bytecode/SlotSSA.java line 303: > 301: * @param joinPoints the join points to clean. > 302: */ > 303: public static void removeCatchBlocksFromJoinPoints(Body body, Map> joinPoints) { An alternative is to remove them from the dominance frontier map? ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/192#discussion_r1702278398 From paul.sandoz at oracle.com Fri Aug 2 21:33:14 2024 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 2 Aug 2024 21:33:14 +0000 Subject: Newbie dumb question In-Reply-To: References: <09719E0B-1E60-4A8B-B14A-4927DA511E27@oracle.com> Message-ID: <07696795-19A3-44D3-890E-203F5C055B40@oracle.com> > On Aug 1, 2024, at 6:37 PM, Archie Cobbs wrote: > > I just also have a gut feeling that there could eventually be a lot more to this than is clear now, analogous to all the ways the JVM is being used today beyond just the Java language. I guess it can come over time - gotta start somewhere. > I share similar gut feelings, if we keep focused and do a good job on the design we will hopefully be surprised, it a good way, by what folks do with it. Paul. From psandoz at openjdk.org Fri Aug 2 22:07:57 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 2 Aug 2024 22:07:57 GMT Subject: [code-reflection] RFR: Test Switch Expression lowering when case is constant [v3] In-Reply-To: <-85x1ISqf4Ucsl9qYMjF7QS5RMBODgubXR6gOF5QK5c=.fce8fcb0-9281-4227-b2e8-d79ed8dd9aed@github.com> References: <-85x1ISqf4Ucsl9qYMjF7QS5RMBODgubXR6gOF5QK5c=.fce8fcb0-9281-4227-b2e8-d79ed8dd9aed@github.com> Message-ID: On Thu, 25 Jul 2024 09:34:35 GMT, Maurizio Cimadamore wrote: >> Mourad Abbay has updated the pull request incrementally with three additional commits since the last revision: >> >> - Write code models without location info >> - Fix a typo >> - Add compiler tests of Switch Expression. > > test/langtools/tools/javac/reflect/SwitchExpressionTest2.java line 76: > >> 74: ()java.lang.String -> { >> 75: %7 : java.lang.String = constant @"BAR"; >> 76: java.yield %7; > > unrelated: but I found the distinction between `yield` and `java.yield` a bit confusing... Indeed it is confusing. The core operation `yield` means to yield a value from a body, where as the extended operation `java.yield` models Java's `yield` statement. Perhaps rename the former to `body.yield`? ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/169#discussion_r1702361313 From mabbay at openjdk.org Sat Aug 3 00:16:40 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Sat, 3 Aug 2024 00:16:40 GMT Subject: [code-reflection] RFR: 8337156: Lowering of switch expressions that throw on no matching [v2] In-Reply-To: <5NLqEydIPULlSeq0n593L0p7Jj6HHr_yCU_wH6Ywj_M=.c23314cc-fde7-4d67-9396-706480e97e28@github.com> References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> <5NLqEydIPULlSeq0n593L0p7Jj6HHr_yCU_wH6Ywj_M=.c23314cc-fde7-4d67-9396-706480e97e28@github.com> Message-ID: On Fri, 2 Aug 2024 19:52:45 GMT, Paul Sandoz wrote: >> Mourad Abbay 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 'code-reflection' into 8337156 >> - Update the lowering of switch expression to throw Match Exception if no label applies > > test/jdk/java/lang/reflect/code/TestSwitchExpressionOp2.java line 59: > >> 57: } >> 58: >> 59: private static void writeModel(CoreOp.FuncOp f, OutputStream os, OpWriter.Option... options) { > > Why do you need to print out the model without location? I just wanted to look at the code model without the extra noise (e.g. location info) ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/195#discussion_r1702414974 From mabbay at openjdk.org Sat Aug 3 07:54:44 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Sat, 3 Aug 2024 07:54:44 GMT Subject: [code-reflection] RFR: 8337156: Lowering of switch expressions that throw on no matching [v2] In-Reply-To: References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: On Fri, 2 Aug 2024 19:57:21 GMT, Paul Sandoz wrote: >> Actually... this code is about a lowering step... I think the best way would be to automatically insert a `default` label when generating the code model in `ReflectMethods`. At that point, as explained, the compiler knows which switches are "unconditional" and which are not. We could maybe reflect this piece of info in the model, but I think it's actually better to remove edge cases and just add the missing case. > > Yes, that seems a better approach given the knowledge the compiler has. For switch ops created manually we anyway cannot guarantee Java program behavior, same for other operations too. > > FWIW modeling of `if/else if/else` statements will always add an `else` if not explicitly present with the default behavior that yields nothing. This will make testing easier, we simply need to test that the generated code model has default label that throws the right exception. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/195#discussion_r1702603816 From mabbay at openjdk.org Sat Aug 3 09:07:15 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Sat, 3 Aug 2024 09:07:15 GMT Subject: [code-reflection] RFR: 8337156: Lowering of switch expressions that throw on no matching [v3] In-Reply-To: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: > Update the lowering of switch expression to throw Match Exception if no label applies. Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Add default label (if it's missing) during code model generation ------------- Changes: - all: https://git.openjdk.org/babylon/pull/195/files - new: https://git.openjdk.org/babylon/pull/195/files/6903daf8..3e562d94 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=195&range=02 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=195&range=01-02 Stats: 308 lines in 4 files changed: 176 ins; 91 del; 41 mod Patch: https://git.openjdk.org/babylon/pull/195.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/195/head:pull/195 PR: https://git.openjdk.org/babylon/pull/195 From mabbay at openjdk.org Sat Aug 3 09:11:40 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Sat, 3 Aug 2024 09:11:40 GMT Subject: [code-reflection] Integrated: 8337157: Second operand to array.load should be an int In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 05:49:49 GMT, Mourad Abbay wrote: > Convert array access indexing expression to int. This pull request has now been integrated. Changeset: 4321c342 Author: Mourad Abbay URL: https://git.openjdk.org/babylon/commit/4321c34217ce479c52facfc47bf67f58af336ba9 Stats: 16 lines in 2 files changed: 15 ins; 0 del; 1 mod 8337157: Second operand to array.load should be an int Reviewed-by: mcimadamore, psandoz ------------- PR: https://git.openjdk.org/babylon/pull/194 From mabbay at openjdk.org Sat Aug 3 09:11:11 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Sat, 3 Aug 2024 09:11:11 GMT Subject: git: openjdk/babylon: code-reflection: 8337157: Second operand to array.load should be an int Message-ID: Changeset: 4321c342 Branch: code-reflection Author: Mourad Abbay Date: 2024-08-03 09:09:09 +0000 URL: https://git.openjdk.org/babylon/commit/4321c34217ce479c52facfc47bf67f58af336ba9 8337157: Second operand to array.load should be an int Reviewed-by: mcimadamore, psandoz ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java ! test/langtools/tools/javac/reflect/ArrayAccessTest.java From mabbay at openjdk.org Sat Aug 3 09:12:45 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Sat, 3 Aug 2024 09:12:45 GMT Subject: git: openjdk/babylon: code-reflection: 8337155: Support expressions returning boxed booleans for the condition blocks of if/do/while Message-ID: <5384b05d-c300-4e58-9217-4bfb3d9fe180@openjdk.org> Changeset: 953de8f8 Branch: code-reflection Author: Mourad Abbay Date: 2024-08-03 09:11:18 +0000 URL: https://git.openjdk.org/babylon/commit/953de8f8c79ba27f445a4895f063480d495f54e3 8337155: Support expressions returning boxed booleans for the condition blocks of if/do/while Reviewed-by: mcimadamore, psandoz ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java ! test/langtools/tools/javac/reflect/IfTest.java ! test/langtools/tools/javac/reflect/WhileLoopTest.java From mabbay at openjdk.org Sat Aug 3 09:16:16 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Sat, 3 Aug 2024 09:16:16 GMT Subject: [code-reflection] RFR: 8337155: Support expressions returning boxed booleans for the condition blocks of if/do/while [v2] In-Reply-To: References: Message-ID: > Condition body of if or while or do-while should yield a boolean value Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Remove outdated comment ------------- Changes: - all: https://git.openjdk.org/babylon/pull/193/files - new: https://git.openjdk.org/babylon/pull/193/files/191caf2a..14923910 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=193&range=01 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=193&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/babylon/pull/193.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/193/head:pull/193 PR: https://git.openjdk.org/babylon/pull/193 From mabbay at openjdk.org Sat Aug 3 09:16:16 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Sat, 3 Aug 2024 09:16:16 GMT Subject: [code-reflection] Integrated: 8337155: Support expressions returning boxed booleans for the condition blocks of if/do/while In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 03:15:57 GMT, Mourad Abbay wrote: > Condition body of if or while or do-while should yield a boolean value This pull request has now been integrated. Changeset: 953de8f8 Author: Mourad Abbay URL: https://git.openjdk.org/babylon/commit/953de8f8c79ba27f445a4895f063480d495f54e3 Stats: 109 lines in 3 files changed: 106 ins; 3 del; 0 mod 8337155: Support expressions returning boxed booleans for the condition blocks of if/do/while Reviewed-by: mcimadamore, psandoz ------------- PR: https://git.openjdk.org/babylon/pull/193 From mabbay at openjdk.org Sat Aug 3 09:18:15 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Sat, 3 Aug 2024 09:18:15 GMT Subject: [code-reflection] RFR: 8337156: Generate code model for switch expression that throws when no label applies [v4] In-Reply-To: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: > Update the code model generation of switch expression to throw if no label applies. Mourad Abbay 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 'code-reflection' into 8337156 - Add default label (if it's missing) during code model generation - Merge branch 'code-reflection' into 8337156 - Update the lowering of switch expression to throw Match Exception if no label applies ------------- Changes: - all: https://git.openjdk.org/babylon/pull/195/files - new: https://git.openjdk.org/babylon/pull/195/files/3e562d94..ba2b3629 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=195&range=03 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=195&range=02-03 Stats: 706 lines in 13 files changed: 518 ins; 77 del; 111 mod Patch: https://git.openjdk.org/babylon/pull/195.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/195/head:pull/195 PR: https://git.openjdk.org/babylon/pull/195 From asotona at openjdk.org Mon Aug 5 11:06:58 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 5 Aug 2024 11:06:58 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v21] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: <9BRLLedjK1xBAr2QSwsT2HmZub48SRwhhDIsBsuuMcM=.62ca90ed-75c1-45de-b037-665326c2cc66@github.com> > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Removing catch blocks from dominance frontier in SlotSSA ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/88c55506..cfda3b51 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=20 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=19-20 Stats: 24 lines in 1 file changed: 8 ins; 16 del; 0 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Mon Aug 5 11:06:58 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 5 Aug 2024 11:06:58 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v20] In-Reply-To: References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> <70yHqg0utubW7xL2KlCBo3SLjh4pCNHKEXndhdXjB_s=.6af35e17-3a1a-4cc7-9341-6dc492a0c3d6@github.com> Message-ID: On Fri, 2 Aug 2024 20:12:01 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> SlotSSA modified to avoid adding block parameters to catch blocks > > src/java.base/share/classes/java/lang/reflect/code/bytecode/SlotSSA.java line 303: > >> 301: * @param joinPoints the join points to clean. >> 302: */ >> 303: public static void removeCatchBlocksFromJoinPoints(Body body, Map> joinPoints) { > > An alternative is to remove them from the dominance frontier map? The catch blocks are now removed from the dominance frontiers. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/192#discussion_r1703944548 From mabbay at openjdk.org Tue Aug 6 09:57:56 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Tue, 6 Aug 2024 09:57:56 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement Message-ID: Modeling and lowering of switch statement. ------------- Commit messages: - Model switch statement Changes: https://git.openjdk.org/babylon/pull/211/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337158 Stats: 233 lines in 3 files changed: 212 ins; 19 del; 2 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From asotona at openjdk.org Tue Aug 6 15:22:02 2024 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 6 Aug 2024 15:22:02 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v22] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed lifting of CONDY with vararg BSM ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/cfda3b51..55c4108c Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=21 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=20-21 Stats: 86 lines in 3 files changed: 23 ins; 41 del; 22 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Wed Aug 7 16:03:22 2024 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 7 Aug 2024 16:03:22 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v23] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: BytecodeLKift fixed insertion of exception region exits before handler blocks in nested try/catch and de-duplicated exception regions ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/55c4108c..4f6ed249 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=22 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=21-22 Stats: 47 lines in 2 files changed: 4 ins; 1 del; 42 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From mabbay at openjdk.org Thu Aug 8 07:49:46 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Thu, 8 Aug 2024 07:49:46 GMT Subject: [code-reflection] RFR: 8337156: Generate code model for switch expression that throws when no label applies [v4] In-Reply-To: References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: On Fri, 2 Aug 2024 15:00:57 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 865: >> >>> 863: if (isLabelBody) { >>> 864: Block.Builder expression = blocks.get(i + 1); >>> 865: boolean isLastLabel = i == blocks.size() - 2; >> >> This is a bit tricky. The details on when a default case is added with a `throw` are spread between `TransPatterns` and `Lower`. Basically: >> * `TransPatterns` will turn an unconditional pattern (see below) into a default label >> * `Lower` will add a `default` throwing label, only if one isn't there >> * the type of the exception is `IncompatibleClassChangeError` if selector is an enum, or `MatchException` otherwise. >> >> An unconditional pattern is a pattern whose type is guaranteed to always match the selector expression (e.g. because the type of the pattern is a supertype of the type of the selector expression). This property should be captured by `tree.hasUnconditionalPattern`. In fact, that flag seems to be set also when the switch has a `default` label. So just checking that flag should suffice (but please double check). > > Actually... this code is about a lowering step... I think the best way would be to automatically insert a `default` label when generating the code model in `ReflectMethods`. At that point, as explained, the compiler knows which switches are "unconditional" and which are not. We could maybe reflect this piece of info in the model, but I think it's actually better to remove edge cases and just add the missing case. According to java spec, MatchException will be thrown when no label applies and the selector expression is not null. IncompatibleClassChangeError is not mentioned at all. @mcimadamore ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/195#discussion_r1708864948 From mabbay at openjdk.org Thu Aug 8 09:21:17 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Thu, 8 Aug 2024 09:21:17 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v2] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision: - Lower switch statement - Add default label when generating switch code model if enhanced switch and no default label ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/07a2f3ee..d96e292e Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=01 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=00-01 Stats: 228 lines in 2 files changed: 142 ins; 36 del; 50 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From asotona at openjdk.org Thu Aug 8 14:21:02 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 8 Aug 2024 14:21:02 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v24] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed generation of multi-catch exception regions ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/4f6ed249..8c87a825 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=23 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=22-23 Stats: 22 lines in 2 files changed: 6 ins; 3 del; 13 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Thu Aug 8 14:53:17 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 8 Aug 2024 14:53:17 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v25] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed lifting of complex nested exception regions ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/8c87a825..4a6740aa Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=24 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=23-24 Stats: 10 lines in 1 file changed: 7 ins; 1 del; 2 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Thu Aug 8 15:31:01 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 8 Aug 2024 15:31:01 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v26] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed generation of BASTORE, SASTORE and CASTORE ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/4a6740aa..8af2006d Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=25 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=24-25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From andrii0lomakin at gmail.com Thu Aug 8 15:54:06 2024 From: andrii0lomakin at gmail.com (Andrii Lomakin) Date: Thu, 8 Aug 2024 17:54:06 +0200 Subject: HAT use cases in AI Message-ID: Good day. Probably it is a very preliminary question to ask. But what are the benefits of using Bablylon/HAT the project's creators can see, in the context of AI development, if we take into account that there are already big players such as ONX Runtime? I am asking to understand the vision of the project creators without any intention of undermining the project's value. From asotona at openjdk.org Thu Aug 8 15:55:16 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 8 Aug 2024 15:55:16 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v27] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: explicit cast of method return type to InvokeOp return type in BytecodeGenerator ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/8af2006d..3d43c045 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=26 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=25-26 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Thu Aug 8 16:34:03 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 8 Aug 2024 16:34:03 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v28] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: <42i8HQXwlTCr4itzbDQgdaOi9WWktvJgv-1pPWmlR4Q=.6682fab6-8b50-41e3-a5d2-46bacf377bc3@github.com> > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: included verification into TestSmallCorpus ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/3d43c045..52b0ea71 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=27 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=26-27 Stats: 66 lines in 1 file changed: 51 ins; 0 del; 15 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From duke at openjdk.org Thu Aug 8 23:57:59 2024 From: duke at openjdk.org (Ruby Chen) Date: Thu, 8 Aug 2024 23:57:59 GMT Subject: [code-reflection] RFR: Implementing Black Scholes HAT Example Message-ID: Finished implementing Black Scholes, which calculates call and put values for randomly generated inputs. Also made some minor modifications to the PTX backend and added a starting implementation of a Chess kernel. The Chess kernel has not been parallelized and only understands how to move pieces according to the rules and how to detect if a player is in check (although this is likely very buggy). ------------- Commit messages: - fixing whitespace and headers - starting implementation of chess - improving blackscholes and adding chess - black scholes runs with ptx Changes: https://git.openjdk.org/babylon/pull/212/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=212&range=00 Stats: 1222 lines in 7 files changed: 926 ins; 230 del; 66 mod Patch: https://git.openjdk.org/babylon/pull/212.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/212/head:pull/212 PR: https://git.openjdk.org/babylon/pull/212 From chen.l.liang at oracle.com Fri Aug 9 00:02:47 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Fri, 9 Aug 2024 00:02:47 +0000 Subject: HAT use cases in AI In-Reply-To: References: Message-ID: It feels weird that your first impression of anything that allows running on GPGPU is "AI." Indeed, code models support transforming Java source code or bytecode to run on the GPU, but it also allows for alternative compilers or decompilers (such as Java decompilers), or create any IR that is of user interest. In fact, more people express their interest in the LINQ capabilities than the AI capabilities of the code model. > if we take into account that there are already big players such as ONX Runtime? External "big players" does not mean Java users do not need a feature. I fail to see how this should affect our decisions. ________________________________ From: babylon-dev on behalf of Andrii Lomakin Sent: Thursday, August 8, 2024 10:54 AM To: babylon-dev at openjdk.org Subject: HAT use cases in AI Good day. Probably it is a very preliminary question to ask. But what are the benefits of using Bablylon/HAT the project's creators can see, in the context of AI development, if we take into account that there are already big players such as ONX Runtime? I am asking to understand the vision of the project creators without any intention of undermining the project's value. -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Aug 9 07:56:43 2024 From: duke at openjdk.org (duke) Date: Fri, 9 Aug 2024 07:56:43 GMT Subject: [code-reflection] RFR: Implementing Black Scholes HAT Example In-Reply-To: References: Message-ID: On Thu, 8 Aug 2024 23:22:39 GMT, Ruby Chen wrote: > Finished implementing Black Scholes, which calculates call and put values for randomly generated inputs. > > Also made some minor modifications to the PTX backend and added a starting implementation of a Chess kernel. The Chess kernel has not been parallelized and only understands how to move pieces according to the rules and how to detect if a player is in check (although this is likely very buggy). @rbrchen Your change (at version fd7830b9e9322a15f27745aeadabc06a210bc6c9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/babylon/pull/212#issuecomment-2277373300 From asotona at openjdk.org Fri Aug 9 08:22:18 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 9 Aug 2024 08:22:18 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v29] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: <4C3ooJ4UH4-EBav3aWTwQtju4Hh5cCHakLQmTwS0j10=.b9b9b839-d6c8-4516-8ea3-8c67d06fb00e@github.com> > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed identification of the right target block in BytecodeLift ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/52b0ea71..17fbfc56 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=28 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=27-28 Stats: 17 lines in 2 files changed: 3 ins; 2 del; 12 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Fri Aug 9 08:28:14 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 9 Aug 2024 08:28:14 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v30] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona 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 39 additional commits since the last revision: - Merge remote-tracking branch 'babylon/code-reflection' into bytecode-round-9 - fixed identification of the right target block in BytecodeLift - included verification into TestSmallCorpus - explicit cast of method return type to InvokeOp return type in BytecodeGenerator - fixed generation of BASTORE, SASTORE and CASTORE - fixed lifting of complex nested exception regions - fixed generation of multi-catch exception regions - BytecodeLKift fixed insertion of exception region exits before handler blocks in nested try/catch and de-duplicated exception regions - fixed lifting of CONDY with vararg BSM - Removing catch blocks from dominance frontier in SlotSSA - ... and 29 more: https://git.openjdk.org/babylon/compare/8c1b6ef2...129a80de ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/17fbfc56..129a80de Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=29 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=28-29 Stats: 4849 lines in 54 files changed: 2688 ins; 1934 del; 227 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Fri Aug 9 08:48:11 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 9 Aug 2024 08:48:11 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v31] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: <_s4CN6R-GMiV3kX_fgnFvZDLpB0gNUoESk0QJVGemT0=.ebaccdb8-0e65-4338-b9b4-73fe16c0fc75@github.com> > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Updated TestSmallCorpus ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/129a80de..268128f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=30 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=29-30 Stats: 91 lines in 1 file changed: 17 ins; 53 del; 21 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Fri Aug 9 08:52:16 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 9 Aug 2024 08:52:16 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v32] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Updated TestSmallCorpus ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/268128f3..54006099 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=31 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=30-31 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From asotona at openjdk.org Fri Aug 9 09:03:46 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 9 Aug 2024 09:03:46 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v32] In-Reply-To: References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: On Fri, 9 Aug 2024 08:52:16 GMT, Adam Sotona wrote: >> Bytecode round 9 contains following improvements: >> - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` >> - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) >> - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` >> - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added >> - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` >> - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types >> >> `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > Updated TestSmallCorpus Bytecode round 9 reached its goals, `TestSmallCorpus::testDoubleRoundtripStability` indicates: - no first and second lift exceptions - no first and second generation exceptions - no verification errors in any of the generated code (except "Illegal call to internal method") - ~92% roundtrip stability (>59900 out of ~65000 java.base methods are stable) ------------- PR Comment: https://git.openjdk.org/babylon/pull/192#issuecomment-2277488811 From duke at openjdk.org Fri Aug 9 12:24:49 2024 From: duke at openjdk.org (Ruby Chen) Date: Fri, 9 Aug 2024 12:24:49 GMT Subject: [code-reflection] Integrated: Implementing Black Scholes HAT Example In-Reply-To: References: Message-ID: On Thu, 8 Aug 2024 23:22:39 GMT, Ruby Chen wrote: > Finished implementing Black Scholes, which calculates call and put values for randomly generated inputs. > > Also made some minor modifications to the PTX backend and added a starting implementation of a Chess kernel. The Chess kernel has not been parallelized and only understands how to move pieces according to the rules and how to detect if a player is in check (although this is likely very buggy). This pull request has now been integrated. Changeset: 3e6e6d45 Author: Ruby Chen Committer: Gary Frost URL: https://git.openjdk.org/babylon/commit/3e6e6d455510778d1322bf744e86945a82375e52 Stats: 1222 lines in 7 files changed: 926 ins; 230 del; 66 mod Implementing Black Scholes HAT Example ------------- PR: https://git.openjdk.org/babylon/pull/212 From gfrost at openjdk.org Fri Aug 9 12:25:04 2024 From: gfrost at openjdk.org (Gary Frost) Date: Fri, 9 Aug 2024 12:25:04 GMT Subject: git: openjdk/babylon: code-reflection: Implementing Black Scholes HAT Example Message-ID: <97e341d5-3c3c-46fa-b8b8-d9c68d7c050f@openjdk.org> Changeset: 3e6e6d45 Branch: code-reflection Author: Ruby Chen Committer: Gary Frost Date: 2024-08-09 12:22:12 +0000 URL: https://git.openjdk.org/babylon/commit/3e6e6d455510778d1322bf744e86945a82375e52 Implementing Black Scholes HAT Example ! hat/backends/ptx/src/main/java/hat/backend/PTXBackend.java ! hat/backends/ptx/src/main/java/hat/backend/PTXCodeBuilder.java ! hat/backends/ptx/src/main/java/hat/backend/PTXPtrOp.java ! hat/examples/blackscholes/src/main/java/blackscholes/Main.java - hat/examples/experiments/src/main/java/experiments/BlackScholes.java + hat/examples/experiments/src/main/java/experiments/Chess.java + hat/hat/src/main/java/hat/buffer/ChessState.java From mabbay at openjdk.org Fri Aug 9 15:45:03 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Fri, 9 Aug 2024 15:45:03 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v3] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Test switch statement model ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/d96e292e..193e06d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=02 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=01-02 Stats: 328 lines in 2 files changed: 322 ins; 5 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From mabbay at openjdk.org Fri Aug 9 16:38:16 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Fri, 9 Aug 2024 16:38:16 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v4] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Test switch statement model ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/193e06d0..ff5f5ed7 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=03 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=02-03 Stats: 168 lines in 2 files changed: 168 ins; 0 del; 0 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From paul.sandoz at oracle.com Fri Aug 9 20:14:06 2024 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 9 Aug 2024 20:14:06 +0000 Subject: HAT use cases in AI In-Reply-To: References: Message-ID: <3D01565D-1E0F-4232-8DA4-D3941B979BFC@oracle.com> Hi Andrii, I think there is plenty of room to explore many forms of AI development, including using ONNX, and more broadly code reflection can apply to other many other non-AI use cases. I would like to explore the expression of ONNX functions and models using a subset of Java code, much like ONNX Script [1] does for Python. The GPU/HAT use-case explores a parallel computing model, applicable HPC of which AI is a subset, and targeting GPU execution environments. Not all AI is deep learning. Very recently Oracle open sources Sandwood [2], a language, compiler, and runtime for JVM based probabilistic models. Code reflection can be used to express the probabilistic model in Java code rather than in its own domain specific language. HAT might also be used for executing the probabilistic models on the GPU. Another example is MSET2 [3], we can implement on the GPU using HAT, or on the CPU using vectorization where we could use code reflection to vectorize lanewise expressions. Hopefully you can see from those few examples there are a broad set of use cases where HAT and/or just code reflection may be applicable. Paul. [1] https://github.com/microsoft/onnxscript [2] https://github.com/oracle/sandwood [3] https://docs.oracle.com/en-us/iaas/Content/anomaly/using/kernels.htm > On Aug 8, 2024, at 8:54 AM, Andrii Lomakin wrote: > > Good day. > > Probably it is a very preliminary question to ask. > > But what are the benefits of using Bablylon/HAT the project's creators > can see, in the context of AI development, if we take into account > that there are already big players such as ONX Runtime? > > I am asking to understand the vision of the project creators without > any intention of undermining the project's value. From psandoz at openjdk.org Fri Aug 9 22:54:01 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 9 Aug 2024 22:54:01 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v4] In-Reply-To: References: Message-ID: <2EXSJR1r5W4rknr3qUeM4KRwxjJc82WwcJ4-EsLrnBE=.844ab7ff-6ab6-4e39-b395-1e20a8532be6@github.com> On Fri, 9 Aug 2024 16:38:16 GMT, Mourad Abbay wrote: >> Modeling and lowering of switch statement. > > Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: > > Test switch statement model src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 76: > 74: * An operation that models a Java statement > 75: */ > 76: sealed interface JavaStatement permits ArrayAccessOp.ArrayStoreOp, AssertOp, FieldAccessOp.FieldStoreOp, InvokeOp, NewOp, ReturnOp, ThrowOp, VarAccessOp.VarStoreOp, VarOp, ExtendedOp.JavaBlockOp, ExtendedOp.JavaDoWhileOp, ExtendedOp.JavaEnhancedForOp, ExtendedOp.JavaForOp, ExtendedOp.JavaIfOp, ExtendedOp.JavaLabelOp, ExtendedOp.JavaLabeledOp, ExtendedOp.JavaSwitchStatementOp, ExtendedOp.JavaTryOp, ExtendedOp.JavaWhileOp, ExtendedOp.JavaYieldOp { Can you change the formatting back? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 72: > 70: import static jdk.internal.java.lang.reflect.code.op.CoreOp._throw; > 71: import static jdk.internal.java.lang.reflect.code.type.FunctionType.functionType; > 72: import static jdk.internal.java.lang.reflect.code.type.JavaType.type; Can you revert these? AFAICT they are inconsistently used, plus non-related changes make it harder to review. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1764: > 1762: return l instanceof JCTree.JCConstantCaseLabel ccl && ccl.expr instanceof JCLiteral literal && literal.value == null; > 1763: })); > 1764: if (enhancedSw && !tree.hasUnconditionalPattern) { Add a test that generates this part of the model? ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1712313146 PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1712319978 PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1712326858 From psandoz at openjdk.org Fri Aug 9 23:04:56 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 9 Aug 2024 23:04:56 GMT Subject: [code-reflection] RFR: 8337156: Generate code model for switch expression that throws when no label applies [v4] In-Reply-To: References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: On Sat, 3 Aug 2024 09:18:15 GMT, Mourad Abbay wrote: >> Update the code model generation of switch expression to throw if no label applies. > > Mourad Abbay 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 'code-reflection' into 8337156 > - Add default label (if it's missing) during code model generation > - Merge branch 'code-reflection' into 8337156 > - Update the lowering of switch expression to throw Match Exception if no label applies src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 872: > 870: case YieldOp yop -> { > 871: if (isDefaultLabel) { > 872: block.op(branch(expression.successor())); Extra indentation. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1649: > 1647: // statement > 1648: pushBody(tree, actionType); > 1649: Class exClass = isEnum(tree.selector.type.tsym) ? IncompatibleClassChangeError.class : MatchException.class; JEP 441 (https://openjdk.org/jeps/441) states: " To align with pattern switch semantics, switch expressions over enum classes now throw MatchException rather than IncompatibleClassChangeError when no switch label applies at run time. This is a minor incompatible change to the language. (An exhaustive switch over an enum fails to match only if the enum class is changed after the switch has been compiled, which is highly unusual.) " ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/195#discussion_r1712328274 PR Review Comment: https://git.openjdk.org/babylon/pull/195#discussion_r1712335469 From psandoz at openjdk.org Fri Aug 9 23:24:46 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 9 Aug 2024 23:24:46 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v32] In-Reply-To: References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: On Fri, 9 Aug 2024 08:52:16 GMT, Adam Sotona wrote: >> Bytecode round 9 contains following improvements: >> - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` >> - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) >> - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` >> - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added >> - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` >> - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types >> >> `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > Updated TestSmallCorpus I don't understand all the details about the exception mapping - i am going on the increase of lifted code and round tripping improvements of the small corpus test, great progress! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 950: > 948: return uses.size() > 1 > 949: || uses.size() == 1 && uses.iterator().next().op().operands().stream().filter(o -> o == res).count() > 1 > 950: || inBlockArgs(res); Uses will return a use if the value used as an operand or as a successor argument, but as you found out it will not differentiate between single and multiple uses of the same value for the same operation, which in theory could be across operands or successor arguments. ------------- Marked as reviewed by psandoz (Lead). PR Review: https://git.openjdk.org/babylon/pull/192#pullrequestreview-2231231522 PR Review Comment: https://git.openjdk.org/babylon/pull/192#discussion_r1712360725 From andrii0lomakin at gmail.com Sat Aug 10 10:15:37 2024 From: andrii0lomakin at gmail.com (Andrii Lomakin) Date: Sat, 10 Aug 2024 12:15:37 +0200 Subject: HAT use cases in AI In-Reply-To: <3D01565D-1E0F-4232-8DA4-D3941B979BFC@oracle.com> References: <3D01565D-1E0F-4232-8DA4-D3941B979BFC@oracle.com> Message-ID: Hi Paul. Thank you very much that you, as usual, provided such detailed answer. I appreciate it. On Fri, 9 Aug 2024, 22:14 Paul Sandoz, wrote: > Hi Andrii, > > I think there is plenty of room to explore many forms of AI development, > including using ONNX, and more broadly code reflection can apply to other > many other non-AI use cases. > > I would like to explore the expression of ONNX functions and models using > a subset of Java code, much like ONNX Script [1] does for Python. > > The GPU/HAT use-case explores a parallel computing model, applicable HPC > of which AI is a subset, and targeting GPU execution environments. > > Not all AI is deep learning. > > Very recently Oracle open sources Sandwood [2], a language, compiler, and > runtime for JVM based probabilistic models. Code reflection can be used to > express the probabilistic model in Java code rather than in its own domain > specific language. HAT might also be used for executing the probabilistic > models on the GPU. > > Another example is MSET2 [3], we can implement on the GPU using HAT, or on > the CPU using vectorization where we could use code reflection to vectorize > lanewise expressions. > > Hopefully you can see from those few examples there are a broad set of use > cases where HAT and/or just code reflection may be applicable. > > Paul. > > > [1] https://github.com/microsoft/onnxscript > [2] https://github.com/oracle/sandwood > [3] https://docs.oracle.com/en-us/iaas/Content/anomaly/using/kernels.htm > > > > On Aug 8, 2024, at 8:54 AM, Andrii Lomakin > wrote: > > > > Good day. > > > > Probably it is a very preliminary question to ask. > > > > But what are the benefits of using Bablylon/HAT the project's creators > > can see, in the context of AI development, if we take into account > > that there are already big players such as ONX Runtime? > > > > I am asking to understand the vision of the project creators without > > any intention of undermining the project's value. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asotona at openjdk.org Mon Aug 12 09:16:47 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 12 Aug 2024 09:16:47 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v32] In-Reply-To: References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: On Fri, 9 Aug 2024 23:14:05 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated TestSmallCorpus > > src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 950: > >> 948: return uses.size() > 1 >> 949: || uses.size() == 1 && uses.iterator().next().op().operands().stream().filter(o -> o == res).count() > 1 >> 950: || inBlockArgs(res); > > Uses will return a use if the value used as an operand or as a successor argument, but as you found out it will not differentiate between single and multiple uses of the same value for the same operation, which in theory could be across operands or successor arguments. Will fix it, thanks. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/192#discussion_r1713410706 From mabbay at openjdk.org Mon Aug 12 10:27:21 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Mon, 12 Aug 2024 10:27:21 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v5] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision: - rewrite test cases to return a result, to check its behaviour through interpreter - Test switch statement model ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/ff5f5ed7..288bfb1e Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=04 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=03-04 Stats: 736 lines in 1 file changed: 476 ins; 8 del; 252 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From asotona at openjdk.org Mon Aug 12 11:13:59 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 12 Aug 2024 11:13:59 GMT Subject: [code-reflection] RFR: Bytecode round 9 [v33] In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: <3ExmeOJGu8a_3zV_PAeVbkIMLPi2433Mi9YZiz-qzZM=.26628dd7-4436-418c-8c15-4fc9bb1e78b4@github.com> > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed BytecodeGenerator::moreThanOneUse calculation and implemented isFirstOperand calculation for unconditional branches ------------- Changes: - all: https://git.openjdk.org/babylon/pull/192/files - new: https://git.openjdk.org/babylon/pull/192/files/54006099..3a94b055 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=32 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=192&range=31-32 Stats: 22 lines in 1 file changed: 6 ins; 9 del; 7 mod Patch: https://git.openjdk.org/babylon/pull/192.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/192/head:pull/192 PR: https://git.openjdk.org/babylon/pull/192 From mabbay at openjdk.org Mon Aug 12 11:45:20 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Mon, 12 Aug 2024 11:45:20 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v6] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Test switch statement model ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/288bfb1e..0e983147 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=05 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=04-05 Stats: 241 lines in 1 file changed: 241 ins; 0 del; 0 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From asotona at openjdk.org Mon Aug 12 12:48:10 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 12 Aug 2024 12:48:10 GMT Subject: git: openjdk/babylon: code-reflection: Bytecode round 9 Message-ID: Changeset: bf2ee69c Branch: code-reflection Author: Adam Sotona Date: 2024-08-12 12:46:54 +0000 URL: https://git.openjdk.org/babylon/commit/bf2ee69c0e14d78b207c51cf96aaaf95a7d7aa83 Bytecode round 9 Reviewed-by: psandoz ! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java ! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeLift.java ! src/java.base/share/classes/java/lang/reflect/code/bytecode/LocalsTypeMapper.java ! src/java.base/share/classes/java/lang/reflect/code/bytecode/SlotSSA.java ! test/jdk/java/lang/reflect/code/bytecode/TestBytecode.java ! test/jdk/java/lang/reflect/code/bytecode/TestLiftCustomBytecode.java ! test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java From asotona at openjdk.org Mon Aug 12 12:49:44 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 12 Aug 2024 12:49:44 GMT Subject: [code-reflection] Integrated: Bytecode round 9 In-Reply-To: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> References: <1z83IeLvQS2wLqPzvN9cTa6DnYWlbrUznh-Vw71mqUw=.cd3c1e12-d0bb-42d4-bfdf-4c32523237aa@github.com> Message-ID: On Mon, 22 Jul 2024 17:21:01 GMT, Adam Sotona wrote: > Bytecode round 9 contains following improvements: > - `String` (and non-`String`) concats are lifted to `CoreOp.ConcatOp` > - `LocalsTypeMapper` is fixed to use instruction index as a key (instead of the instruction identity) > - `LocalsTypeMapper` newly calculates types of uninitialized stack map frame entries and provides that info to `BytecodeLift` > - `BytecodeLift` is fixed to handle deep stacks correctly while branching + tests added > - Oboslete `BytecodeGenerator::conversion` method is replaced by direct call of `CodeBuilder::conversion` > - LocalTypeMapper performs iterative correction of int stack map frame entries to support byte, boolean, short and char types > > `TestSmallCorpus` is not experiencing any first-lift exceptions after the above changes, however we cannot yet say that all the lifted models are correct. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: bf2ee69c Author: Adam Sotona URL: https://git.openjdk.org/babylon/commit/bf2ee69c0e14d78b207c51cf96aaaf95a7d7aa83 Stats: 859 lines in 7 files changed: 545 ins; 187 del; 127 mod Bytecode round 9 Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/babylon/pull/192 From mabbay at openjdk.org Mon Aug 12 16:06:37 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Mon, 12 Aug 2024 16:06:37 GMT Subject: [code-reflection] RFR: 8337156: Generate code model for switch expression that throws when no label applies [v5] In-Reply-To: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: > Update the code model generation of switch expression to throw if no label applies. Mourad Abbay has updated the pull request incrementally with three additional commits since the last revision: - Test switch expression that has default case not the last - Test switch expression that has unconditional pattern - Throw MatchException when no label applies and selector is Enum ------------- Changes: - all: https://git.openjdk.org/babylon/pull/195/files - new: https://git.openjdk.org/babylon/pull/195/files/ba2b3629..edd59df8 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=195&range=04 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=195&range=03-04 Stats: 110 lines in 4 files changed: 98 ins; 2 del; 10 mod Patch: https://git.openjdk.org/babylon/pull/195.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/195/head:pull/195 PR: https://git.openjdk.org/babylon/pull/195 From mabbay at openjdk.org Tue Aug 13 14:58:38 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Tue, 13 Aug 2024 14:58:38 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v7] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Test switch statement model when case is pattern ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/0e983147..1db7b4d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=06 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=05-06 Stats: 748 lines in 1 file changed: 748 ins; 0 del; 0 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From psandoz at openjdk.org Wed Aug 14 00:13:22 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 14 Aug 2024 00:13:22 GMT Subject: [code-reflection] RFR: Unary plus Message-ID: <2pfH7YGm8a5vZqPxmoMcHk9IeCSQmf-hRCzQPEHZ94A=.7cd4d3e7-7ab7-4f36-8b0c-19ebad352414@github.com> Support unary plus operator. No need to explicitly model as it has no direct operational semantics. ------------- Commit messages: - Unary plus operator - Unary plus operator Changes: https://git.openjdk.org/babylon/pull/213/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=213&range=00 Stats: 92 lines in 2 files changed: 90 ins; 0 del; 2 mod Patch: https://git.openjdk.org/babylon/pull/213.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/213/head:pull/213 PR: https://git.openjdk.org/babylon/pull/213 From hgreule at openjdk.org Wed Aug 14 08:03:29 2024 From: hgreule at openjdk.org (Hannes Greule) Date: Wed, 14 Aug 2024 08:03:29 GMT Subject: [code-reflection] RFR: Experiment: Alternative SSA construction algorithm Message-ID: Hi, this is mainly an experiment, I wanted to play around with the API and see how an alternative SSA construction algorithm can be implemented. There are a few notable problems I encountered: - The original algorithm is supposed to work on-the-fly in a single step. This does not work with the current API. - `Value`s (operands) and `Reference`s (successor arguments) are bound eagerly. I assume terminating ops could be emitted only after everything else was done, but that's not easy to achieve currently either. For operands, I don't see any way to say "oh, please use a different value" after the operation is passed to the builder. I'm not sure how relevant this is for other transformations, but if we find a simple solution to this without giving up immutability, I could imagine it to be very powerful. - I'm currently using more data structures to cope with the two-step variant than the original algorithm itself requires. - The `predecessors` map could be avoided at the cost of additional computation whenever only filled blocks should be considered - The `loads` map is required as we can't replace the loads directly during the analysis step - The `additionalParameters` could probably be removed if `Block.Builder` allowed removing parameters - The `deletedPhis` set is also needed to cope with the fact that we look up current defs in both steps - I noticed that for the method in `TestTraverse`, this implementation gets rid of one parameter that the existing implementation does not get rid of. I'm not sure if it is designed to produce minimal SSA, but that looks odd. (`c` is passed to the while body, but it is never read there before being written) I think the algorithm itself is pretty straightforward, but the extra steps needed to adapt to the API somewhat nullify that. I tried to document the implementation details that differ from the paper, but if there are any questions or suggestions how this could be improved, please let me know. ------------- Commit messages: - alternative SSA construction algorithm Changes: https://git.openjdk.org/babylon/pull/214/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=214&range=00 Stats: 315 lines in 2 files changed: 312 ins; 0 del; 3 mod Patch: https://git.openjdk.org/babylon/pull/214.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/214/head:pull/214 PR: https://git.openjdk.org/babylon/pull/214 From mcimadamore at openjdk.org Wed Aug 14 10:27:06 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 14 Aug 2024 10:27:06 GMT Subject: [code-reflection] RFR: Unary plus In-Reply-To: <2pfH7YGm8a5vZqPxmoMcHk9IeCSQmf-hRCzQPEHZ94A=.7cd4d3e7-7ab7-4f36-8b0c-19ebad352414@github.com> References: <2pfH7YGm8a5vZqPxmoMcHk9IeCSQmf-hRCzQPEHZ94A=.7cd4d3e7-7ab7-4f36-8b0c-19ebad352414@github.com> Message-ID: On Wed, 14 Aug 2024 00:08:15 GMT, Paul Sandoz wrote: > Support unary plus operator. No need to explicitly model as it has no direct operational semantics. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/babylon/pull/213#pullrequestreview-2237757691 From mabbay at openjdk.org Wed Aug 14 11:34:31 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Wed, 14 Aug 2024 11:34:31 GMT Subject: [code-reflection] RFR: 8337156: Generate code model for switch expression that throws when no label applies [v6] In-Reply-To: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: > Update the code model generation of switch expression to throw if no label applies. Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision: - Add a comment about missing switch expression tests - Revert unnecessary changes ------------- Changes: - all: https://git.openjdk.org/babylon/pull/195/files - new: https://git.openjdk.org/babylon/pull/195/files/edd59df8..a4960d88 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=195&range=05 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=195&range=04-05 Stats: 51 lines in 2 files changed: 7 ins; 4 del; 40 mod Patch: https://git.openjdk.org/babylon/pull/195.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/195/head:pull/195 PR: https://git.openjdk.org/babylon/pull/195 From mabbay at openjdk.org Wed Aug 14 12:11:21 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Wed, 14 Aug 2024 12:11:21 GMT Subject: [code-reflection] RFR: 8337156: Generate code model for switch expression that throws when no label applies [v7] In-Reply-To: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: > Update the code model generation of switch expression to throw if no label applies. Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Make default case the last two bodies of switch expr op ------------- Changes: - all: https://git.openjdk.org/babylon/pull/195/files - new: https://git.openjdk.org/babylon/pull/195/files/a4960d88..6dc46572 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=195&range=06 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=195&range=05-06 Stats: 57 lines in 3 files changed: 21 ins; 27 del; 9 mod Patch: https://git.openjdk.org/babylon/pull/195.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/195/head:pull/195 PR: https://git.openjdk.org/babylon/pull/195 From mabbay at openjdk.org Wed Aug 14 14:29:13 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Wed, 14 Aug 2024 14:29:13 GMT Subject: [code-reflection] RFR: Unary plus In-Reply-To: <2pfH7YGm8a5vZqPxmoMcHk9IeCSQmf-hRCzQPEHZ94A=.7cd4d3e7-7ab7-4f36-8b0c-19ebad352414@github.com> References: <2pfH7YGm8a5vZqPxmoMcHk9IeCSQmf-hRCzQPEHZ94A=.7cd4d3e7-7ab7-4f36-8b0c-19ebad352414@github.com> Message-ID: On Wed, 14 Aug 2024 00:08:15 GMT, Paul Sandoz wrote: > Support unary plus operator. No need to explicitly model as it has no direct operational semantics. in test4, we are unboxing then boxing without a reason ------------- PR Comment: https://git.openjdk.org/babylon/pull/213#issuecomment-2288931871 From mcimadamore at openjdk.org Wed Aug 14 14:54:19 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 14 Aug 2024 14:54:19 GMT Subject: [code-reflection] RFR: Unary plus In-Reply-To: References: <2pfH7YGm8a5vZqPxmoMcHk9IeCSQmf-hRCzQPEHZ94A=.7cd4d3e7-7ab7-4f36-8b0c-19ebad352414@github.com> Message-ID: On Wed, 14 Aug 2024 14:25:54 GMT, Mourad Abbay wrote: > in test4, we are unboxing then boxing without a reason That is odd, yes. But note that javac bytecode generates same odd stuff: Code: stack=1, locals=1, args_size=1 0: aload_0 1: invokevirtual #2 // Method java/lang/Integer.intValue:()I 4: invokestatic #3 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; 7: areturn The "issue" is that the operand type (`tree.arg.type`) is `Integer`, but `tree.type` is `int` - because the unary operator is seen as as an operator from `int` to `int` (so you need to unbox to apply the `+`). This is backed up by the JLS: > The type of the operand expression of the unary + operator must be a type that is convertible ([?5.1.8](https://docs.oracle.com/javase/specs/jls/se22/html/jls-5.html#jls-5.1.8)) to a primitive numeric type, or a compile-time error occurs. And > Unary numeric promotion ([?5.6](https://docs.oracle.com/javase/specs/jls/se22/html/jls-5.html#jls-5.6)) is performed on the operand. The type of the unary plus expression is the promoted type of the operand. So, these conversions are actually mandated because: the operand is a reference, so "promoting" means doing "unboxing". Then, the "promoted type" is just `int` (the primitive type), and that is the type of the `+v` expression. But then you need to rebox to respect the return type. So this is all good (albeit admittedly odd). ------------- PR Comment: https://git.openjdk.org/babylon/pull/213#issuecomment-2289033524 From mabbay at openjdk.org Wed Aug 14 17:56:49 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Wed, 14 Aug 2024 17:56:49 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v8] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Runtime test of switch statement ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/1db7b4d6..ea945b00 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=07 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=06-07 Stats: 134 lines in 3 files changed: 129 ins; 0 del; 5 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From mabbay at openjdk.org Wed Aug 14 18:18:29 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Wed, 14 Aug 2024 18:18:29 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v9] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Runtime test of switch statement ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/ea945b00..b9cc325e Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=08 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=07-08 Stats: 45 lines in 1 file changed: 45 ins; 0 del; 0 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From psandoz at openjdk.org Wed Aug 14 18:21:59 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 14 Aug 2024 18:21:59 GMT Subject: [code-reflection] RFR: Unary plus In-Reply-To: References: <2pfH7YGm8a5vZqPxmoMcHk9IeCSQmf-hRCzQPEHZ94A=.7cd4d3e7-7ab7-4f36-8b0c-19ebad352414@github.com> Message-ID: <2lW77mLQFadDMG-6NH_29FsT6jXS0jRNykHaT30OCes=.54e31cde-ddfb-4aa8-8549-2585453079a9@github.com> On Wed, 14 Aug 2024 14:51:24 GMT, Maurizio Cimadamore wrote: > So, these conversions are actually mandated because: the operand is a reference, so "promoting" means doing "unboxing". Then, the "promoted type" is just `int` (the primitive type), and that is the type of the `+v` expression. But then you need to rebox to respect the return type. So this is all good (albeit admittedly odd). Yes, that was the intent of this test. Since the unary `+` is a no-op i wanted to ensure we still do the numeric promotion and we don't optimize it away. I will add a some brief comments to the tests. ------------- PR Comment: https://git.openjdk.org/babylon/pull/213#issuecomment-2289526960 From psandoz at openjdk.org Wed Aug 14 18:28:17 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 14 Aug 2024 18:28:17 GMT Subject: [code-reflection] RFR: Unary plus [v2] In-Reply-To: <2pfH7YGm8a5vZqPxmoMcHk9IeCSQmf-hRCzQPEHZ94A=.7cd4d3e7-7ab7-4f36-8b0c-19ebad352414@github.com> References: <2pfH7YGm8a5vZqPxmoMcHk9IeCSQmf-hRCzQPEHZ94A=.7cd4d3e7-7ab7-4f36-8b0c-19ebad352414@github.com> Message-ID: > Support unary plus operator. No need to explicitly model as it has no direct operational semantics. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Add comments to tests ------------- Changes: - all: https://git.openjdk.org/babylon/pull/213/files - new: https://git.openjdk.org/babylon/pull/213/files/4ce02a21..38fe9b1b Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=213&range=01 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=213&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/babylon/pull/213.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/213/head:pull/213 PR: https://git.openjdk.org/babylon/pull/213 From psandoz at openjdk.org Wed Aug 14 18:33:14 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 14 Aug 2024 18:33:14 GMT Subject: git: openjdk/babylon: code-reflection: Unary plus Message-ID: <9f326d58-7842-42ef-b0fc-8d589e2e1fd7@openjdk.org> Changeset: a566edf2 Branch: code-reflection Author: Paul Sandoz Date: 2024-08-14 18:32:45 +0000 URL: https://git.openjdk.org/babylon/commit/a566edf2bceb3ffcabbc3232cc9b8a2248c5a4cc Unary plus Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java + test/langtools/tools/javac/reflect/UnaryopTest.java From psandoz at openjdk.org Wed Aug 14 18:35:17 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 14 Aug 2024 18:35:17 GMT Subject: [code-reflection] Integrated: Unary plus In-Reply-To: <2pfH7YGm8a5vZqPxmoMcHk9IeCSQmf-hRCzQPEHZ94A=.7cd4d3e7-7ab7-4f36-8b0c-19ebad352414@github.com> References: <2pfH7YGm8a5vZqPxmoMcHk9IeCSQmf-hRCzQPEHZ94A=.7cd4d3e7-7ab7-4f36-8b0c-19ebad352414@github.com> Message-ID: On Wed, 14 Aug 2024 00:08:15 GMT, Paul Sandoz wrote: > Support unary plus operator. No need to explicitly model as it has no direct operational semantics. This pull request has now been integrated. Changeset: a566edf2 Author: Paul Sandoz URL: https://git.openjdk.org/babylon/commit/a566edf2bceb3ffcabbc3232cc9b8a2248c5a4cc Stats: 94 lines in 2 files changed: 92 ins; 0 del; 2 mod Unary plus Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/babylon/pull/213 From psandoz at openjdk.org Wed Aug 14 21:23:58 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 14 Aug 2024 21:23:58 GMT Subject: [code-reflection] RFR: 8337156: Generate code model for switch expression that throws when no label applies [v7] In-Reply-To: References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: On Wed, 14 Aug 2024 12:11:21 GMT, Mourad Abbay wrote: >> Update the code model generation of switch expression to throw if no label applies. > > Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: > > Make default case the last two bodies of switch expr op Marked as reviewed by psandoz (Lead). ------------- PR Review: https://git.openjdk.org/babylon/pull/195#pullrequestreview-2239219873 From psandoz at openjdk.org Wed Aug 14 22:52:25 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 14 Aug 2024 22:52:25 GMT Subject: [code-reflection] RFR: Bitwise complement op Message-ID: Lowering `~x` to bytecode generates the equivalent of `x ^ -1`, so the first lift and generation cycle will result in different bytecode. ------------- Commit messages: - Bitwise complement op Changes: https://git.openjdk.org/babylon/pull/216/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=216&range=00 Stats: 125 lines in 7 files changed: 118 ins; 2 del; 5 mod Patch: https://git.openjdk.org/babylon/pull/216.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/216/head:pull/216 PR: https://git.openjdk.org/babylon/pull/216 From liach at openjdk.org Wed Aug 14 23:39:32 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 14 Aug 2024 23:39:32 GMT Subject: [code-reflection] RFR: Bitwise complement op In-Reply-To: References: Message-ID: On Wed, 14 Aug 2024 22:46:35 GMT, Paul Sandoz wrote: > Lowering `~x` to bytecode generates the equivalent of `x ^ -1`, so the first lift and generation cycle will result in different bytecode. src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 586: > 584: processFirstOperand(op); > 585: switch (rvt) { > 586: case IntType, BooleanType, ByteType, ShortType, CharType -> { Do we intend to support boolean even though JLS doesn't allow complement `~` on boolean values? ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/216#discussion_r1717642009 From mabbay at openjdk.org Thu Aug 15 09:47:43 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Thu, 15 Aug 2024 09:47:43 GMT Subject: git: openjdk/babylon: code-reflection: 8337156: Generate code model for switch expression that throws when no label applies Message-ID: <49b2e442-eb60-40a8-a4d0-73f251cc7050@openjdk.org> Changeset: 00d8b6f0 Branch: code-reflection Author: Mourad Abbay Date: 2024-08-15 09:47:00 +0000 URL: https://git.openjdk.org/babylon/commit/00d8b6f0c6e2f630887e620061f916a13be1ae73 8337156: Generate code model for switch expression that throws when no label applies Reviewed-by: psandoz ! src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java ! test/jdk/java/lang/reflect/code/TestSwitchExpressionOp.java ! test/langtools/tools/javac/reflect/SwitchExpressionTest2.java From mabbay at openjdk.org Thu Aug 15 09:50:01 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Thu, 15 Aug 2024 09:50:01 GMT Subject: [code-reflection] Integrated: 8337156: Generate code model for switch expression that throws when no label applies In-Reply-To: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> References: <8QXkeiPMMcjK4RfCKKJJLUCFE35mCI3D2cJByifO9Ko=.f4f5c2c8-1813-4c46-9642-3d3b2f760b0e@github.com> Message-ID: On Thu, 25 Jul 2024 08:13:25 GMT, Mourad Abbay wrote: > Update the code model generation of switch expression to throw if no label applies. This pull request has now been integrated. Changeset: 00d8b6f0 Author: Mourad Abbay URL: https://git.openjdk.org/babylon/commit/00d8b6f0c6e2f630887e620061f916a13be1ae73 Stats: 277 lines in 4 files changed: 268 ins; 0 del; 9 mod 8337156: Generate code model for switch expression that throws when no label applies Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/babylon/pull/195 From asotona at openjdk.org Thu Aug 15 13:36:10 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 15 Aug 2024 13:36:10 GMT Subject: [code-reflection] RFR: Bytecode round 10 Message-ID: This time I focused on the roundtrip stabilizations, namely: - BytecodeLift: injected blocks do not pass the stack through block params - Avoided redundant slot loads and stores for parameters of blocks with just a single predecessor - SlotSSA calculates join point block argument types from the consuming slot load ops (instead of the slot store ops) - TestSmallCorpus now performs triple round stability verification and actual numbers are: >99% of methods is stable, no exceptions, no verification errors Remaining instability of ~130 methods is related to nested try blocks. Please review. Thanks, Adam ------------- Commit messages: - SlotSSA determines join point block argument types from the consuming SlotLoadOps - TestSmallCorpus changed from double round to triple round stability - SlotSSA determines join point block argument types from the consuming SlotLoadOps - avoid redundant slot loads and stores for parameters of blocks with single predecessor - Roundtrip stabilization in BytecodeLift: Changes: https://git.openjdk.org/babylon/pull/215/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=215&range=00 Stats: 138 lines in 4 files changed: 44 ins; 20 del; 74 mod Patch: https://git.openjdk.org/babylon/pull/215.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/215/head:pull/215 PR: https://git.openjdk.org/babylon/pull/215 From mcimadamore at openjdk.org Thu Aug 15 16:33:03 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 15 Aug 2024 16:33:03 GMT Subject: [code-reflection] RFR: Bitwise complement op In-Reply-To: References: Message-ID: On Wed, 14 Aug 2024 22:46:35 GMT, Paul Sandoz wrote: > Lowering `~x` to bytecode generates the equivalent of `x ^ -1`, so the first lift and generation cycle will result in different bytecode. javac changes look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/babylon/pull/216#pullrequestreview-2240798329 From mcimadamore at openjdk.org Thu Aug 15 16:35:12 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 15 Aug 2024 16:35:12 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v4] In-Reply-To: <2EXSJR1r5W4rknr3qUeM4KRwxjJc82WwcJ4-EsLrnBE=.844ab7ff-6ab6-4e39-b395-1e20a8532be6@github.com> References: <2EXSJR1r5W4rknr3qUeM4KRwxjJc82WwcJ4-EsLrnBE=.844ab7ff-6ab6-4e39-b395-1e20a8532be6@github.com> Message-ID: On Fri, 9 Aug 2024 22:46:17 GMT, Paul Sandoz wrote: >> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: >> >> Test switch statement model > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 72: > >> 70: import static jdk.internal.java.lang.reflect.code.op.CoreOp._throw; >> 71: import static jdk.internal.java.lang.reflect.code.type.FunctionType.functionType; >> 72: import static jdk.internal.java.lang.reflect.code.type.JavaType.type; > > Can you revert these? AFAICT they are inconsistently used, plus non-related changes make it harder to review. Agreed - I'll wait to review until these spurious changes are reverted - hard to see the forest for the trees in here :-) ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1718667222 From psandoz at openjdk.org Thu Aug 15 16:50:19 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 15 Aug 2024 16:50:19 GMT Subject: [code-reflection] RFR: Bitwise complement op In-Reply-To: References: Message-ID: <1zE-XG3yDOpTGHEIWe75efkPBS9zjg_pdy-5Bhwsecs=.9cf1b3b4-55e0-4e8d-ac88-bee1967625d9@github.com> On Wed, 14 Aug 2024 23:00:12 GMT, Chen Liang wrote: >> Lowering `~x` to bytecode generates the equivalent of `x ^ -1`, so the first lift and generation cycle will result in different bytecode. > > src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 586: > >> 584: processFirstOperand(op); >> 585: switch (rvt) { >> 586: case IntType, BooleanType, ByteType, ShortType, CharType -> { > > Do we intend to support boolean even though JLS doesn't allow complement `~` on boolean values? I observed that too, but decided to copy the same pattern as used else where. @asotona will know more. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/216#discussion_r1718689779 From asotona at openjdk.org Thu Aug 15 17:22:02 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 15 Aug 2024 17:22:02 GMT Subject: [code-reflection] RFR: Bitwise complement op In-Reply-To: <1zE-XG3yDOpTGHEIWe75efkPBS9zjg_pdy-5Bhwsecs=.9cf1b3b4-55e0-4e8d-ac88-bee1967625d9@github.com> References: <1zE-XG3yDOpTGHEIWe75efkPBS9zjg_pdy-5Bhwsecs=.9cf1b3b4-55e0-4e8d-ac88-bee1967625d9@github.com> Message-ID: <580z6z42PfkwGjK3p-o1SQBZIAZ9GA9M9y56jN4PI6U=.d34893ae-c83c-482a-9f18-4d91f806d04e@github.com> On Thu, 15 Aug 2024 16:46:57 GMT, Paul Sandoz wrote: >> src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 586: >> >>> 584: processFirstOperand(op); >>> 585: switch (rvt) { >>> 586: case IntType, BooleanType, ByteType, ShortType, CharType -> { >> >> Do we intend to support boolean even though JLS doesn't allow complement `~` on boolean values? > > I observed that too, but decided to copy the same pattern as used else where. @asotona will know more. Well, JVMS doesn't make a difference anyway, so why not? ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/216#discussion_r1718740057 From liach at openjdk.org Thu Aug 15 17:22:02 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 15 Aug 2024 17:22:02 GMT Subject: [code-reflection] RFR: Bitwise complement op In-Reply-To: <580z6z42PfkwGjK3p-o1SQBZIAZ9GA9M9y56jN4PI6U=.d34893ae-c83c-482a-9f18-4d91f806d04e@github.com> References: <1zE-XG3yDOpTGHEIWe75efkPBS9zjg_pdy-5Bhwsecs=.9cf1b3b4-55e0-4e8d-ac88-bee1967625d9@github.com> <580z6z42PfkwGjK3p-o1SQBZIAZ9GA9M9y56jN4PI6U=.d34893ae-c83c-482a-9f18-4d91f806d04e@github.com> Message-ID: On Thu, 15 Aug 2024 17:17:57 GMT, Adam Sotona wrote: >> I observed that too, but decided to copy the same pattern as used else where. @asotona will know more. > > Well, JVMS doesn't make a difference anyway, so why not? Then classfile api would need an enum dedicated to model actual loadable types :) ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/216#discussion_r1718742860 From asotona at openjdk.org Thu Aug 15 17:51:00 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 15 Aug 2024 17:51:00 GMT Subject: [code-reflection] RFR: Bytecode round 10 In-Reply-To: References: Message-ID: <_IP4nOBGok_LOzIrcmA_mXr5lsZ7X9N_x0EWsx1CSL0=.d915bafe-232b-47f2-a587-53adc46f4bb4@github.com> On Wed, 14 Aug 2024 10:40:40 GMT, Adam Sotona wrote: > This time I focused on the roundtrip stabilizations, namely: > - BytecodeLift: injected blocks do not pass the stack through block params > - Avoided redundant slot loads and stores for parameters of blocks with just a single predecessor > - SlotSSA calculates join point block argument types from the consuming slot load ops (instead of the slot store ops) > - TestSmallCorpus now performs triple round stability verification and actual numbers are: >99% of methods is stable, no exceptions, no verification errors > > Remaining instability of ~130 methods is related to nested try blocks. > > Please review. > > Thanks, > Adam Majority of the remaining instabilities seems to related to the variables modified in the try block and consumed by the exception handler. ------------- PR Comment: https://git.openjdk.org/babylon/pull/215#issuecomment-2291847569 From liach at openjdk.org Thu Aug 15 18:16:58 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 15 Aug 2024 18:16:58 GMT Subject: [code-reflection] RFR: Bytecode round 10 In-Reply-To: References: Message-ID: On Wed, 14 Aug 2024 10:40:40 GMT, Adam Sotona wrote: > This time I focused on the roundtrip stabilizations, namely: > - BytecodeLift: injected blocks do not pass the stack through block params > - Avoided redundant slot loads and stores for parameters of blocks with just a single predecessor > - SlotSSA calculates join point block argument types from the consuming slot load ops (instead of the slot store ops) > - TestSmallCorpus now performs triple round stability verification and actual numbers are: >99% of methods is stable, no exceptions, no verification errors > > Remaining instability of ~130 methods is related to nested try blocks. > > Please review. > > Thanks, > Adam src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 1117: > 1115: List sargs = ref.arguments(); > 1116: if (catchingBlocks.get(target.index())) { > 1117: // Jumping to an exceptio handler, exception parameter is expected on stack Suggestion: // Jumping to an exception handler, exception parameter is expected on stack ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/215#discussion_r1718799419 From psandoz at openjdk.org Thu Aug 15 18:19:12 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 15 Aug 2024 18:19:12 GMT Subject: git: openjdk/babylon: code-reflection: Bitwise complement op Message-ID: <5bd532e1-be84-43d1-b6cc-a6871c3e2130@openjdk.org> Changeset: 6f5f2119 Branch: code-reflection Author: Paul Sandoz Date: 2024-08-15 18:18:41 +0000 URL: https://git.openjdk.org/babylon/commit/6f5f211932c3b65d988c6213af5dd000ec150833 Bitwise complement op Reviewed-by: mcimadamore ! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java ! src/java.base/share/classes/java/lang/reflect/code/interpreter/InvokableLeafOps.java ! src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java ! test/jdk/java/lang/reflect/code/TestBinops.java ! test/jdk/java/lang/reflect/code/bytecode/TestBytecode.java ! test/langtools/tools/javac/reflect/UnaryopTest.java From psandoz at openjdk.org Thu Aug 15 18:21:41 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 15 Aug 2024 18:21:41 GMT Subject: [code-reflection] RFR: Bitwise complement op [v2] In-Reply-To: References: Message-ID: > Lowering `~x` to bytecode generates the equivalent of `x ^ -1`, so the first lift and generation cycle will result in different bytecode. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Doc fix ------------- Changes: - all: https://git.openjdk.org/babylon/pull/216/files - new: https://git.openjdk.org/babylon/pull/216/files/74587625..5cfa8c59 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=216&range=01 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=216&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/216.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/216/head:pull/216 PR: https://git.openjdk.org/babylon/pull/216 From psandoz at openjdk.org Thu Aug 15 18:21:41 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 15 Aug 2024 18:21:41 GMT Subject: [code-reflection] Integrated: Bitwise complement op In-Reply-To: References: Message-ID: On Wed, 14 Aug 2024 22:46:35 GMT, Paul Sandoz wrote: > Lowering `~x` to bytecode generates the equivalent of `x ^ -1`, so the first lift and generation cycle will result in different bytecode. This pull request has now been integrated. Changeset: 6f5f2119 Author: Paul Sandoz URL: https://git.openjdk.org/babylon/commit/6f5f211932c3b65d988c6213af5dd000ec150833 Stats: 125 lines in 7 files changed: 118 ins; 2 del; 5 mod Bitwise complement op Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/babylon/pull/216 From psandoz at openjdk.org Thu Aug 15 21:34:04 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 15 Aug 2024 21:34:04 GMT Subject: [code-reflection] RFR: Bytecode round 10 In-Reply-To: References: Message-ID: On Wed, 14 Aug 2024 10:40:40 GMT, Adam Sotona wrote: > This time I focused on the roundtrip stabilizations, namely: > - BytecodeLift: injected blocks do not pass the stack through block params > - Avoided redundant slot loads and stores for parameters of blocks with just a single predecessor > - SlotSSA calculates join point block argument types from the consuming slot load ops (instead of the slot store ops) > - TestSmallCorpus now performs triple round stability verification and actual numbers are: >99% of methods is stable, no exceptions, no verification errors > > Remaining instability of ~130 methods is related to nested try blocks. > > Please review. > > Thanks, > Adam src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 200: > 198: private final BitSet blocksToVisit, catchingBlocks; > 199: private final Map slots; > 200: private final Map valueMap; Can we rename this or add a comment here as to it use (single predecessor case)? src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 1124: > 1122: load(value); > 1123: } > 1124: } else if (target.predecessors().size() > (target.isEntryBlock() ? 0 : 1)) { An entry block cannot have any predecessors. Are you observing that? If so its a bug. test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java line 96: > 94: > 95: // Roundtrip is >99% stable, no exceptions, no verification errors > 96: Assert.assertTrue(stable > 65200 && unstable < 140 && errorStats.isEmpty(), String.format(""" Excellent, really close! ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/215#discussion_r1719006650 PR Review Comment: https://git.openjdk.org/babylon/pull/215#discussion_r1719012215 PR Review Comment: https://git.openjdk.org/babylon/pull/215#discussion_r1719024857 From psandoz at openjdk.org Thu Aug 15 22:50:10 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 15 Aug 2024 22:50:10 GMT Subject: [code-reflection] RFR: Experiment: Alternative SSA construction algorithm In-Reply-To: References: Message-ID: On Wed, 14 Aug 2024 07:58:53 GMT, Hannes Greule wrote: > Hi, > > this is mainly an experiment, I wanted to play around with the API and see how an alternative SSA construction algorithm can be implemented. There are a few notable problems I encountered: > > - The original algorithm is supposed to work on-the-fly in a single step. This does not work with the current API. > - `Value`s (operands) and `Reference`s (successor arguments) are bound eagerly. I assume terminating ops could be emitted only after everything else was done, but that's not easy to achieve currently either. For operands, I don't see any way to say "oh, please use a different value" after the operation is passed to the builder. I'm not sure how relevant this is for other transformations, but if we find a simple solution to this without giving up immutability, I could imagine it to be very powerful. > - I'm currently using more data structures to cope with the two-step variant than the original algorithm itself requires. > - The `predecessors` map could be avoided at the cost of additional computation whenever only filled blocks should be considered > - The `loads` map is required as we can't replace the loads directly during the analysis step > - The `additionalParameters` could probably be removed if `Block.Builder` allowed removing parameters > - The `deletedPhis` set is also needed to cope with the fact that we look up current defs in both steps > - I noticed that for the method in `TestTraverse`, this implementation gets rid of one parameter that the existing implementation does not get rid of. I'm not sure if it is designed to produce minimal SSA, but that looks odd. (`c` is passed to the while body, but it is never read there before being written) > > > I think the algorithm itself is pretty straightforward, but the extra steps needed to adapt to the API somewhat nullify that. > I tried to document the implementation details that differ from the paper, but if there are any questions or suggestions how this could be improved, please let me know. This is a good experiment. The Cytron paper is quite old and I did not check to see if there were more recent alternative algorithms that were simpler. It will take me some time to fully digest the paper and your implementation. My gut feeling is this might be a good default replacement for the current implementation. I am curious as to how easily you found the adaption from phi nodes to block parameters. Generally i have found it easy to adapt and it can often simplify things. You noticed a deficiency in the Cytron implementation (and possibly the algorithm), regarding a variable that is just stored to. We have noticed that too. I don't currently see a way to retain immutability and post-adapt what is currently built before building completes. Maybe as I look more deeply a few ideas will emerge. One approach i have used when transforming is instead of building up data structures I build up (capturing) functions on the first pass to apply when transforming on the second pass. I don't yet know if this would make your implementation simpler. ------------- PR Comment: https://git.openjdk.org/babylon/pull/214#issuecomment-2292415152 From asotona at openjdk.org Fri Aug 16 05:41:13 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 16 Aug 2024 05:41:13 GMT Subject: [code-reflection] RFR: Bytecode round 10 [v2] In-Reply-To: References: Message-ID: > This time I focused on the roundtrip stabilizations, namely: > - BytecodeLift: injected blocks do not pass the stack through block params > - Avoided redundant slot loads and stores for parameters of blocks with just a single predecessor > - SlotSSA calculates join point block argument types from the consuming slot load ops (instead of the slot store ops) > - TestSmallCorpus now performs triple round stability verification and actual numbers are: >99% of methods is stable, no exceptions, no verification errors > > Remaining instability of ~130 methods is related to nested try blocks. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/babylon/pull/215/files - new: https://git.openjdk.org/babylon/pull/215/files/542ca315..657ea0e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=215&range=01 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=215&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/215.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/215/head:pull/215 PR: https://git.openjdk.org/babylon/pull/215 From asotona at openjdk.org Fri Aug 16 05:41:13 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 16 Aug 2024 05:41:13 GMT Subject: [code-reflection] RFR: Bytecode round 10 [v2] In-Reply-To: References: Message-ID: On Thu, 15 Aug 2024 21:19:37 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java >> >> Co-authored-by: Chen Liang > > src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 1124: > >> 1122: load(value); >> 1123: } >> 1124: } else if (target.predecessors().size() > (target.isEntryBlock() ? 0 : 1)) { > > An entry block cannot have any predecessors. Are you observing that? If so its a bug. Right, it does not happen. I added it intuitively as looping to bci 0 is frequent in the bytecode. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/215#discussion_r1719345345 From asotona at openjdk.org Fri Aug 16 06:13:32 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 16 Aug 2024 06:13:32 GMT Subject: [code-reflection] RFR: Bytecode round 10 [v3] In-Reply-To: References: Message-ID: > This time I focused on the roundtrip stabilizations, namely: > - BytecodeLift: injected blocks do not pass the stack through block params > - Avoided redundant slot loads and stores for parameters of blocks with just a single predecessor > - SlotSSA calculates join point block argument types from the consuming slot load ops (instead of the slot store ops) > - TestSmallCorpus now performs triple round stability verification and actual numbers are: >99% of methods is stable, no exceptions, no verification errors > > Remaining instability of ~130 methods is related to nested try blocks. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: applied the proposed changes ------------- Changes: - all: https://git.openjdk.org/babylon/pull/215/files - new: https://git.openjdk.org/babylon/pull/215/files/657ea0e8..60e8ecd6 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=215&range=02 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=215&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/babylon/pull/215.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/215/head:pull/215 PR: https://git.openjdk.org/babylon/pull/215 From hgreule at openjdk.org Fri Aug 16 07:28:03 2024 From: hgreule at openjdk.org (Hannes Greule) Date: Fri, 16 Aug 2024 07:28:03 GMT Subject: [code-reflection] RFR: Experiment: Alternative SSA construction algorithm In-Reply-To: References: Message-ID: <1xX4KKGtMI14aGYL5Ixnuttal1e9IwitYsnXzddxvBw=.ef076445-a3a2-415c-8cc1-0272312db283@github.com> On Thu, 15 Aug 2024 22:47:08 GMT, Paul Sandoz wrote: > I am curious as to how easily you found the adaption from phi nodes to block parameters. Generally i have found it easy to adapt and it can often simplify things. Conceptually, I think block parameters are easy to understand. One hurdle I could imagine when doing global transformation is the "when do I need them", or rather the "why do I *sometimes* need them". I'm not sure how I would explain that without explaining phis first. But for local transformations, that doesn't really matter at all, reducing the complexity in that aspect. It also fits in well with the design of the API (I think it wouldn't fit into a sea-of-nodes style API), and transformations between the representations seem pretty simple too. > I don't currently see a way to retain immutability and post-adapt what is currently built before building completes. Maybe as I look more deeply a few ideas will emerge. One approach i have used when transforming is instead of building up data structures I build up (capturing) functions on the first pass to apply when transforming on the second pass. I don't yet know if this would make your implementation simpler. I'm not sure how useful that is in general, but I think terminating ops could always only be added to the block after everything else was done. Combined with the ability to remove block parameters again, it would potentially made some things a little easier. However, that also feels like an odd special casing that might be more confusing than helpful. ------------- PR Comment: https://git.openjdk.org/babylon/pull/214#issuecomment-2292975517 From mabbay at openjdk.org Fri Aug 16 10:40:20 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Fri, 16 Aug 2024 10:40:20 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v10] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Revert unnecessary changes ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/b9cc325e..2bba4d4d Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=09 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=08-09 Stats: 115 lines in 2 files changed: 56 ins; 5 del; 54 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From mabbay at openjdk.org Fri Aug 16 10:40:21 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Fri, 16 Aug 2024 10:40:21 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v4] In-Reply-To: <2EXSJR1r5W4rknr3qUeM4KRwxjJc82WwcJ4-EsLrnBE=.844ab7ff-6ab6-4e39-b395-1e20a8532be6@github.com> References: <2EXSJR1r5W4rknr3qUeM4KRwxjJc82WwcJ4-EsLrnBE=.844ab7ff-6ab6-4e39-b395-1e20a8532be6@github.com> Message-ID: On Fri, 9 Aug 2024 22:51:21 GMT, Paul Sandoz wrote: >> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: >> >> Test switch statement model > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1764: > >> 1762: return l instanceof JCTree.JCConstantCaseLabel ccl && ccl.expr instanceof JCLiteral literal && literal.value == null; >> 1763: })); >> 1764: if (enhancedSw && !tree.hasUnconditionalPattern) { > > Add a test that generates this part of the model? Are you asking if the tests cover this ? ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1719673800 From mabbay at openjdk.org Fri Aug 16 11:38:23 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Fri, 16 Aug 2024 11:38:23 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v11] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch 'code-reflection' into 8337158 # Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java - Revert unnecessary changes - Runtime test of switch statement - Runtime test of switch statement - Test switch statement model when case is pattern - Test switch statement model - rewrite test cases to return a result, to check its behaviour through interpreter - Test switch statement model - Test switch statement model - Test switch statement model - ... and 3 more: https://git.openjdk.org/babylon/compare/6f5f2119...28367d20 ------------- Changes: https://git.openjdk.org/babylon/pull/211/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=10 Stats: 2297 lines in 5 files changed: 2292 ins; 0 del; 5 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From mabbay at openjdk.org Fri Aug 16 11:50:15 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Fri, 16 Aug 2024 11:50:15 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v12] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Revert changes lost during merge ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/28367d20..d7885130 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=11 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=10-11 Stats: 175 lines in 1 file changed: 174 ins; 0 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From mabbay at openjdk.org Fri Aug 16 12:02:19 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Fri, 16 Aug 2024 12:02:19 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v13] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision: - Add a test case of switch statement model - Runtime tests of switch statement ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/d7885130..be050a2b Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=12 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=11-12 Stats: 111 lines in 2 files changed: 111 ins; 0 del; 0 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From mabbay at openjdk.org Fri Aug 16 12:04:58 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Fri, 16 Aug 2024 12:04:58 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v13] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 12:02:19 GMT, Mourad Abbay wrote: >> Modeling and lowering of switch statement. > > Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision: > > - Add a test case of switch statement model > - Runtime tests of switch statement @mcimadamore As you can see in visitSwitch method, we are checking if the tree represents an enhanced switch statement, I'm wondering if we have a flag on tree like isEnhanced, what do you think ? ------------- PR Comment: https://git.openjdk.org/babylon/pull/211#issuecomment-2293382332 From mcimadamore at openjdk.org Fri Aug 16 13:54:00 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 16 Aug 2024 13:54:00 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v13] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 12:02:19 GMT, Mourad Abbay wrote: >> Modeling and lowering of switch statement. > > Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision: > > - Add a test case of switch statement model > - Runtime tests of switch statement src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1686: > 1684: JCTree.JCCaseLabel headCl = c.labels.head; > 1685: if (headCl instanceof JCTree.JCPatternCaseLabel pcl) { > 1686: if (c.labels.size() > 1) { Can this happen, with patterns? ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1719875401 From mcimadamore at openjdk.org Fri Aug 16 14:10:02 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 16 Aug 2024 14:10:02 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v13] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 12:02:19 GMT, Mourad Abbay wrote: >> Modeling and lowering of switch statement. > > Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision: > > - Add a test case of switch statement model > - Runtime tests of switch statement src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1676: > 1674: > 1675: @Override > 1676: public void visitSwitch(JCTree.JCSwitch tree) { This method seems 90% the same as the one for switch expression, we should try to consolidate. I've left a comment on how to maybe simplify the logic to add a throwing default - let's see where we are after that's addressed. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1822: > 1820: // if enhanced switch and no default label > 1821: // enhanced: target type not byte, char short, int, String, or, has case pattern or case null > 1822: boolean enhancedSw = !List.of(JavaType.BYTE, JavaType.CHAR, JavaType.SHORT, JavaType.INT, In `Lower` the code corresponding to this is: public void visitSwitch(JCSwitch tree) { List cases = tree.patternSwitch ? addDefaultIfNeeded(tree.patternSwitch, tree.wasEnumSelector, tree.cases) : tree.cases; handleSwitch(tree, tree.selector, cases); } So, I don't think you need all this state tracking and you can probably simplify all this. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1719895548 PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1719894382 From mcimadamore at openjdk.org Fri Aug 16 14:20:02 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 16 Aug 2024 14:20:02 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v13] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 14:07:40 GMT, Maurizio Cimadamore wrote: >> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add a test case of switch statement model >> - Runtime tests of switch statement > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1676: > >> 1674: >> 1675: @Override >> 1676: public void visitSwitch(JCTree.JCSwitch tree) { > > This method seems 90% the same as the one for switch expression, we should try to consolidate. I've left a comment on how to maybe simplify the logic to add a throwing default - let's see where we are after that's addressed. In particular, this big chunk of code: for (JCTree.JCCase c : tree.cases) { ... switch (c.caseKind) { Seems to be virtually identical for both switch expression and statement, except for _one_ line: bodies.add(stack.body); Which is added more lazily in the cases of switch expressions. I'm not super sure as to what is the reason for that discrepancy. If we could somehow eliminate that, at least all this big portion of code could be shared. (and, even if the difference cannot be eliminated, perhaps a shared routine which returns the default body would enable clients to use that as they see fit). ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1719907121 From mabbay at openjdk.org Fri Aug 16 14:58:58 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Fri, 16 Aug 2024 14:58:58 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v13] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 13:51:22 GMT, Maurizio Cimadamore wrote: >> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add a test case of switch statement model >> - Runtime tests of switch statement > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1686: > >> 1684: JCTree.JCCaseLabel headCl = c.labels.head; >> 1685: if (headCl instanceof JCTree.JCPatternCaseLabel pcl) { >> 1686: if (c.labels.size() > 1) { > > Can this happen, with patterns? Yes. Here is an example: private static String casePatternMultiLabel(Object o) { String r = ""; switch (o) { case Integer _, Long _, Character _, Byte _, Short _-> r += "integral type"; default -> r += "non integral type"; } return r; } ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1719961581 From psandoz at openjdk.org Fri Aug 16 16:13:00 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 16 Aug 2024 16:13:00 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v13] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 14:17:07 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1676: >> >>> 1674: >>> 1675: @Override >>> 1676: public void visitSwitch(JCTree.JCSwitch tree) { >> >> This method seems 90% the same as the one for switch expression, we should try to consolidate. I've left a comment on how to maybe simplify the logic to add a throwing default - let's see where we are after that's addressed. > > In particular, this big chunk of code: > > > for (JCTree.JCCase c : tree.cases) { > ... > switch (c.caseKind) { > > > Seems to be virtually identical for both switch expression and statement, except for _one_ line: > > > bodies.add(stack.body); > > > Which is added more lazily in the cases of switch expressions. I'm not super sure as to what is the reason for that discrepancy. If we could somehow eliminate that, at least all this big portion of code could be shared. (and, even if the difference cannot be eliminated, perhaps a shared routine which returns the default body would enable clients to use that as they see fit). Mourad and I chatted off-line about this. My suggestion was to swiftly follow up with another PR that consolidates, since this PR contains a comprehensive set of tests to detect any bugs in such refactoring. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1720043127 From psandoz at openjdk.org Fri Aug 16 16:13:01 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 16 Aug 2024 16:13:01 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v4] In-Reply-To: References: <2EXSJR1r5W4rknr3qUeM4KRwxjJc82WwcJ4-EsLrnBE=.844ab7ff-6ab6-4e39-b395-1e20a8532be6@github.com> Message-ID: <1Rbuh8YAkjkDXYWOMJ0rlFE8rQslb_nOHwbXfO1kfyY=.a8d23515-b45a-4d14-9473-5734c3b6c0cf@github.com> On Fri, 16 Aug 2024 10:37:45 GMT, Mourad Abbay wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1764: >> >>> 1762: return l instanceof JCTree.JCConstantCaseLabel ccl && ccl.expr instanceof JCLiteral literal && literal.value == null; >>> 1763: })); >>> 1764: if (enhancedSw && !tree.hasUnconditionalPattern) { >> >> Add a test that generates this part of the model? > > Are you asking if the tests cover this ? Yes. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1720043929 From psandoz at openjdk.org Fri Aug 16 16:30:01 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 16 Aug 2024 16:30:01 GMT Subject: [code-reflection] RFR: Experiment: Alternative SSA construction algorithm In-Reply-To: References: Message-ID: On Wed, 14 Aug 2024 07:58:53 GMT, Hannes Greule wrote: > Hi, > > this is mainly an experiment, I wanted to play around with the API and see how an alternative SSA construction algorithm can be implemented. There are a few notable problems I encountered: > > - The original algorithm is supposed to work on-the-fly in a single step. This does not work with the current API. > - `Value`s (operands) and `Reference`s (successor arguments) are bound eagerly. I assume terminating ops could be emitted only after everything else was done, but that's not easy to achieve currently either. For operands, I don't see any way to say "oh, please use a different value" after the operation is passed to the builder. I'm not sure how relevant this is for other transformations, but if we find a simple solution to this without giving up immutability, I could imagine it to be very powerful. > - I'm currently using more data structures to cope with the two-step variant than the original algorithm itself requires. > - The `predecessors` map could be avoided at the cost of additional computation whenever only filled blocks should be considered > - The `loads` map is required as we can't replace the loads directly during the analysis step > - The `additionalParameters` could probably be removed if `Block.Builder` allowed removing parameters > - The `deletedPhis` set is also needed to cope with the fact that we look up current defs in both steps > - I noticed that for the method in `TestTraverse`, this implementation gets rid of one parameter that the existing implementation does not get rid of. I'm not sure if it is designed to produce minimal SSA, but that looks odd. (`c` is passed to the while body, but it is never read there before being written) > > > I think the algorithm itself is pretty straightforward, but the extra steps needed to adapt to the API somewhat nullify that. > I tried to document the implementation details that differ from the paper, but if there are any questions or suggestions how this could be improved, please let me know. (BTW the changes from `Set` to `SequencedSet` are nice, feel free to separate that out as a separate PR.) (Still working my way through the paper + code, i'l send some further thoughts later today.) Explaining phis at that level is i would imagine a proxy for explaining control flow join points. If one thinks of blocks as little functions, that jump to other functions as a tail call, it might actually be easier to explain. > Combined with the ability to remove block parameters again, it would potentially made some things a little easier. This should be possible to support, the `Block.Builder::parameters` currently returns an unmodifiable list. I was hesitant about exposing a mutable list, since removing a parameter that is used will create an invalid model. But, we could support removing block parameters that are not currently used nor are any successor arguments associated with them. Although, that probably means it is not very useful. In general my approach to the design as been to lean into multiple passes (analysis/transformation) rather than try and optimize for single passes. That's a trade off. We are not trying to build a framework for compiler pipelines like say LLVM, MLIR, or C2, although there are obvious similarities to key aspects. ------------- PR Comment: https://git.openjdk.org/babylon/pull/214#issuecomment-2293804522 From psandoz at openjdk.org Fri Aug 16 16:37:02 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 16 Aug 2024 16:37:02 GMT Subject: [code-reflection] RFR: Bytecode round 10 [v3] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 06:13:32 GMT, Adam Sotona wrote: >> This time I focused on the roundtrip stabilizations, namely: >> - BytecodeLift: injected blocks do not pass the stack through block params >> - Avoided redundant slot loads and stores for parameters of blocks with just a single predecessor >> - SlotSSA calculates join point block argument types from the consuming slot load ops (instead of the slot store ops) >> - TestSmallCorpus now performs triple round stability verification and actual numbers are: >99% of methods is stable, no exceptions, no verification errors >> >> Remaining instability of ~130 methods is related to nested try blocks. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > applied the proposed changes Marked as reviewed by psandoz (Lead). ------------- PR Review: https://git.openjdk.org/babylon/pull/215#pullrequestreview-2243089833 From psandoz at openjdk.org Fri Aug 16 16:37:03 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 16 Aug 2024 16:37:03 GMT Subject: [code-reflection] RFR: Bytecode round 10 [v3] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 05:38:08 GMT, Adam Sotona wrote: >> src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 1124: >> >>> 1122: load(value); >>> 1123: } >>> 1124: } else if (target.predecessors().size() > (target.isEntryBlock() ? 0 : 1)) { >> >> An entry block cannot have any predecessors. Are you observing that? If so its a bug. > > Right, it does not happen. > I added it intuitively as looping to bci 0 is frequent in the bytecode. Interesting. I suppose when lifting such cases you have to create a block (with possible parameters) that the entry block unconditionally branches too. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/215#discussion_r1720068613 From psandoz at openjdk.org Fri Aug 16 16:46:02 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 16 Aug 2024 16:46:02 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v13] In-Reply-To: References: Message-ID: <2E_ee2EIAF7LSzdGvGo7vpKqnhgEeej4ZOjxqVHTgMA=.66f02b78-9379-4ea2-a185-019b49602c22@github.com> On Fri, 16 Aug 2024 12:02:19 GMT, Mourad Abbay wrote: >> Modeling and lowering of switch statement. > > Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision: > > - Add a test case of switch statement model > - Runtime tests of switch statement src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 126: > 124: } while (!(op instanceof Op.Loop || op instanceof JavaSwitchStatementOp)); > 125: // } while (!(op instanceof Op.Loop lop)); > 126: // error: variable lop might not have been initialized Now we have two choices we can remove the comment. Also we can update the comment at line 114. Suggest you also change the if/else if/else into a switch expression. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 843: > 841: // Arithmetic operations > 842: case PLUS_ASG -> { > 843: if (tree.operator.opcode == ByteCodes.string_add) { Make an `@@@` comment about the boxing ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1720074066 PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1720075756 From asotona at openjdk.org Fri Aug 16 16:56:56 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 16 Aug 2024 16:56:56 GMT Subject: git: openjdk/babylon: code-reflection: Bytecode round 10 Message-ID: <613488aa-002e-44f9-bae0-3e3321ba4334@openjdk.org> Changeset: 15d8b3b3 Branch: code-reflection Author: Adam Sotona Date: 2024-08-16 16:56:27 +0000 URL: https://git.openjdk.org/babylon/commit/15d8b3b3b64d84134c389dae2e1026261688d511 Bytecode round 10 Reviewed-by: psandoz ! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java ! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeLift.java ! src/java.base/share/classes/java/lang/reflect/code/bytecode/SlotSSA.java ! test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java From asotona at openjdk.org Fri Aug 16 16:58:57 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 16 Aug 2024 16:58:57 GMT Subject: [code-reflection] RFR: Bytecode round 10 [v3] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 06:13:32 GMT, Adam Sotona wrote: >> This time I focused on the roundtrip stabilizations, namely: >> - BytecodeLift: injected blocks do not pass the stack through block params >> - Avoided redundant slot loads and stores for parameters of blocks with just a single predecessor >> - SlotSSA calculates join point block argument types from the consuming slot load ops (instead of the slot store ops) >> - TestSmallCorpus now performs triple round stability verification and actual numbers are: >99% of methods is stable, no exceptions, no verification errors >> >> Remaining instability of ~130 methods is related to nested try blocks. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > applied the proposed changes Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/babylon/pull/215#issuecomment-2293843843 From asotona at openjdk.org Fri Aug 16 16:58:58 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 16 Aug 2024 16:58:58 GMT Subject: [code-reflection] RFR: Bytecode round 10 [v3] In-Reply-To: References: Message-ID: On Fri, 16 Aug 2024 16:34:03 GMT, Paul Sandoz wrote: >> Right, it does not happen. >> I added it intuitively as looping to bci 0 is frequent in the bytecode. > > Interesting. I suppose when lifting such cases you have to create a block (with possible parameters) that the entry block unconditionally branches too. Yes, in such cases an explicit method entry stack map frame triggers a new block with implicit branch from the entry block. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/215#discussion_r1720089309 From asotona at openjdk.org Fri Aug 16 16:58:58 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 16 Aug 2024 16:58:58 GMT Subject: [code-reflection] Integrated: Bytecode round 10 In-Reply-To: References: Message-ID: On Wed, 14 Aug 2024 10:40:40 GMT, Adam Sotona wrote: > This time I focused on the roundtrip stabilizations, namely: > - BytecodeLift: injected blocks do not pass the stack through block params > - Avoided redundant slot loads and stores for parameters of blocks with just a single predecessor > - SlotSSA calculates join point block argument types from the consuming slot load ops (instead of the slot store ops) > - TestSmallCorpus now performs triple round stability verification and actual numbers are: >99% of methods is stable, no exceptions, no verification errors > > Remaining instability of ~130 methods is related to nested try blocks. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 15d8b3b3 Author: Adam Sotona URL: https://git.openjdk.org/babylon/commit/15d8b3b3b64d84134c389dae2e1026261688d511 Stats: 138 lines in 4 files changed: 44 ins; 20 del; 74 mod Bytecode round 10 Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/babylon/pull/215 From psandoz at openjdk.org Fri Aug 16 23:22:59 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 16 Aug 2024 23:22:59 GMT Subject: [code-reflection] RFR: Experiment: Alternative SSA construction algorithm In-Reply-To: References: Message-ID: On Wed, 14 Aug 2024 07:58:53 GMT, Hannes Greule wrote: > Hi, > > this is mainly an experiment, I wanted to play around with the API and see how an alternative SSA construction algorithm can be implemented. There are a few notable problems I encountered: > > - The original algorithm is supposed to work on-the-fly in a single step. This does not work with the current API. > - `Value`s (operands) and `Reference`s (successor arguments) are bound eagerly. I assume terminating ops could be emitted only after everything else was done, but that's not easy to achieve currently either. For operands, I don't see any way to say "oh, please use a different value" after the operation is passed to the builder. I'm not sure how relevant this is for other transformations, but if we find a simple solution to this without giving up immutability, I could imagine it to be very powerful. > - I'm currently using more data structures to cope with the two-step variant than the original algorithm itself requires. > - The `predecessors` map could be avoided at the cost of additional computation whenever only filled blocks should be considered > - The `loads` map is required as we can't replace the loads directly during the analysis step > - The `additionalParameters` could probably be removed if `Block.Builder` allowed removing parameters > - The `deletedPhis` set is also needed to cope with the fact that we look up current defs in both steps > - I noticed that for the method in `TestTraverse`, this implementation gets rid of one parameter that the existing implementation does not get rid of. I'm not sure if it is designed to produce minimal SSA, but that looks odd. (`c` is passed to the while body, but it is never read there before being written) > > > I think the algorithm itself is pretty straightforward, but the extra steps needed to adapt to the API somewhat nullify that. > I tried to document the implementation details that differ from the paper, but if there are any questions or suggestions how this could be improved, please let me know. I have a better grasp now (not complete). This algorithm really leans on the mutability of a phi node's operand list and user list, and replacement of uses of a phi with another value. I don't see how we can make it work in one pass with the current code model design. However, its still rather good in two passes, better than the Cytron implementation IMO. My suggestion would be to lean into the two passes and make the second pass simpler for the resolution of values, for load operation results and additional successor arguments. Its either replacement with another `Value` or a say `BlockParameterHolder` that holds the actual `Block.Parameter` to use. When a `Block` is processed to append the additional block parameters given the list of the holders it will update the holders. In our current approach it is possible to SSA transform models with nested operations, but the constraint is variables declared outside a body can only be loaded from within a body. This obviously works well for lambdas. But it means we cannot support say the SSA transformation of the high-level model while retaining the structure e.g. the model for this code snippet: int x =0; if (...) { x = 42; } else { x = -42; } We would have to transform the operation modeling the if statement into one that yields the resulting value of x. I explored that and it quickly became complex. So instead we throw an exception. There is also another case, not currently supported, where we cannot fully SSA transform - if a variable is updated in a try block and accessed in a catch or finally block, or updated in a catch block and accessed in a finally block. We should either fail on such cases or leave the variable intact (perhaps via some configuration parameter). This requires analysis of stores within exception regions. We might be able to transform and split the code, but that is harder and may not be worth the effort given the likely edge case nature. ------------- PR Comment: https://git.openjdk.org/babylon/pull/214#issuecomment-2294437961 From mabbay at openjdk.org Mon Aug 19 10:52:19 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Mon, 19 Aug 2024 10:52:19 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v14] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with four additional commits since the last revision: - Add a comment about the concat of a string with a primitive value - Refactor - Remove outdated comments - Simplify logic of when to add a default case to the switch statement model ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/be050a2b..90698d02 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=13 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=12-13 Stats: 23 lines in 2 files changed: 1 ins; 15 del; 7 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From mabbay at openjdk.org Mon Aug 19 10:57:02 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Mon, 19 Aug 2024 10:57:02 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v4] In-Reply-To: <1Rbuh8YAkjkDXYWOMJ0rlFE8rQslb_nOHwbXfO1kfyY=.a8d23515-b45a-4d14-9473-5734c3b6c0cf@github.com> References: <2EXSJR1r5W4rknr3qUeM4KRwxjJc82WwcJ4-EsLrnBE=.844ab7ff-6ab6-4e39-b395-1e20a8532be6@github.com> <1Rbuh8YAkjkDXYWOMJ0rlFE8rQslb_nOHwbXfO1kfyY=.a8d23515-b45a-4d14-9473-5734c3b6c0cf@github.com> Message-ID: On Fri, 16 Aug 2024 16:10:13 GMT, Paul Sandoz wrote: >> Are you asking if the tests cover this ? > > Yes. We do have tests that check we only add default when switch statement is enhanced and there is no implicit/explicit default. These tests can be found in SwitchStatementTest and are named: nonEnhancedSwStatNoDefault, enhancedSwStatNoDefault1, enhancedSwStatNoDefault2 and enhancedSwStatUnconditionalPattern. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/211#discussion_r1721605985 From mabbay at openjdk.org Mon Aug 19 11:38:17 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Mon, 19 Aug 2024 11:38:17 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v15] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Update the expected model due to the change in modeling of string concat ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/90698d02..a800fd8d Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=14 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=13-14 Stats: 667 lines in 1 file changed: 0 ins; 1 del; 666 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From hgreule at openjdk.org Mon Aug 19 14:09:03 2024 From: hgreule at openjdk.org (Hannes Greule) Date: Mon, 19 Aug 2024 14:09:03 GMT Subject: [code-reflection] RFR: Experiment: Alternative SSA construction algorithm In-Reply-To: References: Message-ID: <1DZXimowI6VpbrKI4ZUiPU9f8JbnwSAqJDtHgYHZyx0=.002ad1df-9286-4e0e-abe5-3d8187401493@github.com> On Fri, 16 Aug 2024 16:27:40 GMT, Paul Sandoz wrote: > This should be possible to support, the `Block.Builder::parameters` currently returns an unmodifiable list. I was hesitant about exposing a mutable list, since removing a parameter that is used will create an invalid model. But, we could support removing block parameters that are not currently used nor are any successor arguments associated with them. Although, that probably means it is not very useful. Yes, that's a restriction that is probably also hard to track, and not restricting removal wouldn't be a good API I think. > This algorithm really leans on the mutability of a phi node's operand list and user list, and replacement of uses of a phi with another value. I don't see how we can make it work in one pass with the current code model design. However, its still rather good in two passes, better than the Cytron implementation IMO. I agree. I also think if we want to properly support try-catch-finally constructs with it (as you mentioned), it wouldn't be one pass even if we had mutability. So two passes are probably fine. > My suggestion would be to lean into the two passes and make the second pass simpler for the resolution of values, for load operation results and additional successor arguments. Its either replacement with another `Value` or a say `BlockParameterHolder` that holds the actual `Block.Parameter` to use. When a `Block` is processed to append the additional block parameters given the list of the holders it will update the holders. I'll try to improve on that. > In our current approach it is possible to SSA transform models with nested operations, but the constraint is variables declared outside a body can only be loaded from within a body. This obviously works well for lambdas. But it means we cannot support say the SSA transformation of the high-level model while retaining the structure e.g. the model for this code snippet I think this is a general problem that comes with the (very powerful) flexibility of the model. It's generally difficult to set boundaries what a valid input code model is for a specific transformation operation, and then there might still be two options: 1) In such case, do not touch that variable and only transform the rest, or 2) throw an exception if an unsupported code element is encountered. Both might make sense in specific scenarios, or both variants could be combined depending *what kind of* unsupported elements are encountered. ---- Without trying hard, I also noticed that the current transform API isn't well-suited when trying to clean up e.g. empty blocks or to combine blocks. Especially with the SSA transform, we end up with unneeded blocks in many places, so I thought that could be a potential improvement, but I didn't find a way to do that without a lot of additional work. ------------- PR Comment: https://git.openjdk.org/babylon/pull/214#issuecomment-2296668168 From mabbay at openjdk.org Mon Aug 19 14:15:29 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Mon, 19 Aug 2024 14:15:29 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v16] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with four additional commits since the last revision: - Runtime tests of switch statement - Refactor - Runtime tests of switch statement - Runtime tests of switch statement ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/a800fd8d..abce9b39 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=15 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=14-15 Stats: 269 lines in 2 files changed: 257 ins; 5 del; 7 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From mabbay at openjdk.org Mon Aug 19 14:37:38 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Mon, 19 Aug 2024 14:37:38 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v17] In-Reply-To: References: Message-ID: > Modeling and lowering of switch statement. Mourad Abbay has updated the pull request incrementally with three additional commits since the last revision: - Remove outdated comment - Correct the arguments passed in a switch expression test - Always have the case default as last bodies ------------- Changes: - all: https://git.openjdk.org/babylon/pull/211/files - new: https://git.openjdk.org/babylon/pull/211/files/abce9b39..63d71d18 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=16 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=211&range=15-16 Stats: 96 lines in 4 files changed: 90 ins; 0 del; 6 mod Patch: https://git.openjdk.org/babylon/pull/211.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/211/head:pull/211 PR: https://git.openjdk.org/babylon/pull/211 From mcimadamore at openjdk.org Mon Aug 19 17:12:03 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 19 Aug 2024 17:12:03 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v17] In-Reply-To: References: Message-ID: On Mon, 19 Aug 2024 14:37:38 GMT, Mourad Abbay wrote: >> Modeling and lowering of switch statement. > > Mourad Abbay has updated the pull request incrementally with three additional commits since the last revision: > > - Remove outdated comment > - Correct the arguments passed in a switch expression test > - Always have the case default as last bodies Changes in ReflectMethods look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/babylon/pull/211#pullrequestreview-2246060155 From psandoz at openjdk.org Mon Aug 19 17:34:00 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 19 Aug 2024 17:34:00 GMT Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch statement [v17] In-Reply-To: References: Message-ID: <0jUyzpaQHG3ap76L-lDOIWQJN2ZEaSJgqeFkzkM6WMk=.51095551-d76a-4a71-8614-2e1d8844df1d@github.com> On Mon, 19 Aug 2024 14:37:38 GMT, Mourad Abbay wrote: >> Modeling and lowering of switch statement. > > Mourad Abbay has updated the pull request incrementally with three additional commits since the last revision: > > - Remove outdated comment > - Correct the arguments passed in a switch expression test > - Always have the case default as last bodies Looks good. Please follow up with another PR that consolidates common switch expression and switch statement functionality. ------------- Marked as reviewed by psandoz (Lead). PR Review: https://git.openjdk.org/babylon/pull/211#pullrequestreview-2246097947 From psandoz at openjdk.org Mon Aug 19 17:59:58 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 19 Aug 2024 17:59:58 GMT Subject: [code-reflection] RFR: Experiment: Alternative SSA construction algorithm In-Reply-To: References: Message-ID: On Wed, 14 Aug 2024 07:58:53 GMT, Hannes Greule wrote: > Hi, > > this is mainly an experiment, I wanted to play around with the API and see how an alternative SSA construction algorithm can be implemented. There are a few notable problems I encountered: > > - The original algorithm is supposed to work on-the-fly in a single step. This does not work with the current API. > - `Value`s (operands) and `Reference`s (successor arguments) are bound eagerly. I assume terminating ops could be emitted only after everything else was done, but that's not easy to achieve currently either. For operands, I don't see any way to say "oh, please use a different value" after the operation is passed to the builder. I'm not sure how relevant this is for other transformations, but if we find a simple solution to this without giving up immutability, I could imagine it to be very powerful. > - I'm currently using more data structures to cope with the two-step variant than the original algorithm itself requires. > - The `predecessors` map could be avoided at the cost of additional computation whenever only filled blocks should be considered > - The `loads` map is required as we can't replace the loads directly during the analysis step > - The `additionalParameters` could probably be removed if `Block.Builder` allowed removing parameters > - The `deletedPhis` set is also needed to cope with the fact that we look up current defs in both steps > - I noticed that for the method in `TestTraverse`, this implementation gets rid of one parameter that the existing implementation does not get rid of. I'm not sure if it is designed to produce minimal SSA, but that looks odd. (`c` is passed to the while body, but it is never read there before being written) > > > I think the algorithm itself is pretty straightforward, but the extra steps needed to adapt to the API somewhat nullify that. > I tried to document the implementation details that differ from the paper, but if there are any questions or suggestions how this could be improved, please let me know. > I think this is a general problem that comes with the (very powerful) flexibility of the model. It's generally difficult to set boundaries what a valid input code model is for a specific transformation operation, and then there might still be two options: 1) In such case, do not touch that variable and only transform the rest, or 2) throw an exception if an unsupported code element is encountered. Both might make sense in specific scenarios, or both variants could be combined depending _what kind of_ unsupported elements are encountered. Yes, since it is specific to the operations present in the model. I used the current SSA implementation carefully in the Triton example, when translating the operation modeling the Java `for` statement, modeling a counted loop, into a Triton SSA counted loop expression. > > Without trying hard, I also noticed that the current transform API isn't well-suited when trying to clean up e.g. empty blocks or to combine blocks. Especially with the SSA transform, we end up with unneeded blocks in many places, so I thought that could be a potential improvement, but I didn't find a way to do that without a lot of additional work. Indeed, it's often easier not to do that, and apply as a separate transformation if needed. When a body is built, any empty blocks with no predecessors are removed, and then the blocks are topologically sorted. This will retain non-empty block with no predecessors, occurring at the end, and i am unsure whether it is appropriate to remove them or not -- is it intentional or an error? It was intentional, for simplicity, to retain blocks that unconditionally branch to other blocks that could otherwise be merged, lowering will likely do this. ------------- PR Comment: https://git.openjdk.org/babylon/pull/214#issuecomment-2297126827 From mabbay at openjdk.org Tue Aug 20 08:59:11 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Tue, 20 Aug 2024 08:59:11 GMT Subject: git: openjdk/babylon: code-reflection: 8337158: Modeling and lowering of switch statement Message-ID: <47e51e51-4514-41db-b48e-916d4327a2ba@openjdk.org> Changeset: 8042d934 Branch: code-reflection Author: Mourad Abbay Date: 2024-08-20 08:57:06 +0000 URL: https://git.openjdk.org/babylon/commit/8042d934b925d3767b746e57944b99b25c92c47e 8337158: Modeling and lowering of switch statement Reviewed-by: mcimadamore, psandoz ! src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java ! src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java ! test/jdk/java/lang/reflect/code/TestSwitchExpressionOp.java + test/jdk/java/lang/reflect/code/TestSwitchStatementOp.java + test/langtools/tools/javac/reflect/SwitchStatementTest.java From mabbay at openjdk.org Tue Aug 20 09:00:07 2024 From: mabbay at openjdk.org (Mourad Abbay) Date: Tue, 20 Aug 2024 09:00:07 GMT Subject: [code-reflection] Integrated: 8337158: Modeling and lowering of switch statement In-Reply-To: References: Message-ID: On Tue, 6 Aug 2024 09:53:16 GMT, Mourad Abbay wrote: > Modeling and lowering of switch statement. This pull request has now been integrated. Changeset: 8042d934 Author: Mourad Abbay URL: https://git.openjdk.org/babylon/commit/8042d934b925d3767b746e57944b99b25c92c47e Stats: 2916 lines in 6 files changed: 2905 ins; 1 del; 10 mod 8337158: Modeling and lowering of switch statement Reviewed-by: mcimadamore, psandoz ------------- PR: https://git.openjdk.org/babylon/pull/211 From psandoz at openjdk.org Thu Aug 22 20:51:56 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 22 Aug 2024 20:51:56 GMT Subject: [code-reflection] RFR: Model synchronized statements Message-ID: Model synchronized statements. A synchronized op has two bodies one for the expression yielding the monitor and one for the synchronized block that covers the monitor enter and exit. The lowering of synchronized op produces a model containing monitor enter and exit operations and operations covered by exception regions, ensuring that a monitor exits under exceptional circumstances. The interpreter has been updated, but locking is currently on a best effort basis using `ReentrantLock` instances thus we cannot consistently apply synchronization on objects across interpretation, executing in a single thread, and bytecode executing in one or more other threads. We would need to update the interpreter to use native methods that invoke the JNI `MonitorEnter` and `MonitorExit` methods, although it is not clear if those can be mixed in a nested manner with JVM execution of monitor enter and exit bytecode instructions. A simple test for generated bytecode has been included that tests for the expected number of monitor enter and exit instructions, and single threaded execution for non-exceptional and exceptional cases. ------------- Commit messages: - Simple bytecode test. - Bytecode generation and lifting - Merge remote-tracking branch 'upstream/code-reflection' into synchronized-op - Synchronized op Changes: https://git.openjdk.org/babylon/pull/217/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=217&range=00 Stats: 681 lines in 9 files changed: 673 ins; 6 del; 2 mod Patch: https://git.openjdk.org/babylon/pull/217.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/217/head:pull/217 PR: https://git.openjdk.org/babylon/pull/217 From mcimadamore at openjdk.org Fri Aug 23 08:54:24 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 23 Aug 2024 08:54:24 GMT Subject: [code-reflection] RFR: Model synchronized statements In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 20:43:44 GMT, Paul Sandoz wrote: > Model synchronized statements. > > A synchronized op has two bodies one for the expression yielding the monitor and one for the synchronized block that covers the monitor enter and exit. > > The lowering of synchronized op produces a model containing monitor enter and exit operations and operations covered by exception regions, ensuring that a monitor exits under exceptional circumstances. > > The interpreter has been updated, but locking is currently on a best effort basis using `ReentrantLock` instances thus we cannot consistently apply synchronization on objects across interpretation, executing in a single thread, and bytecode executing in one or more other threads. We would need to update the interpreter to use native methods that invoke the JNI `MonitorEnter` and `MonitorExit` methods, although it is not clear if those can be mixed in a nested manner with JVM execution of monitor enter and exit bytecode instructions. > > A simple test for generated bytecode has been included that tests for the expected number of monitor enter and exit instructions, and single threaded execution for non-exceptional and exceptional cases. src/java.base/share/classes/java/lang/reflect/code/interpreter/Interpreter.java line 567: > 565: .map(String::valueOf) > 566: .collect(Collectors.joining()); > 567: } else if (o instanceof CoreOp.MonitorOp.MonitorEnterOp) { Crazy suggestion: given the recent push of making more of the monitor logic be expressed in Java (as part of Loom), I wonder if it would make sense to imagine a world where a `synchronized` is just lowered to plain Java code - no special core ops? The really fundamental operation that cannot be expressed here is the "gimme a lock for this object". But if we had that (and that is a single core op, or maybe just expressed as a special "field access") wouldn't we be able to achieve the same result? e.g. lock = lockFor(synchronizedValue) lock.lock(); try { // stats } finally { lock.unlock(); } ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/217#discussion_r1728622630 From mcimadamore at openjdk.org Fri Aug 23 08:59:26 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 23 Aug 2024 08:59:26 GMT Subject: [code-reflection] RFR: Model synchronized statements In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 20:43:44 GMT, Paul Sandoz wrote: > Model synchronized statements. > > A synchronized op has two bodies one for the expression yielding the monitor and one for the synchronized block that covers the monitor enter and exit. > > The lowering of synchronized op produces a model containing monitor enter and exit operations and operations covered by exception regions, ensuring that a monitor exits under exceptional circumstances. > > The interpreter has been updated, but locking is currently on a best effort basis using `ReentrantLock` instances thus we cannot consistently apply synchronization on objects across interpretation, executing in a single thread, and bytecode executing in one or more other threads. We would need to update the interpreter to use native methods that invoke the JNI `MonitorEnter` and `MonitorExit` methods, although it is not clear if those can be mixed in a nested manner with JVM execution of monitor enter and exit bytecode instructions. > > A simple test for generated bytecode has been included that tests for the expected number of monitor enter and exit instructions, and single threaded execution for non-exceptional and exceptional cases. javac changes (and test) look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/babylon/pull/217#pullrequestreview-2256729950 From asotona at openjdk.org Fri Aug 23 12:17:53 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 23 Aug 2024 12:17:53 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes Message-ID: Proposal of `BytecodeLift` implementation skipping intermediate use of `SlotOp` and `SlotSSA` transformation. `LocalsTypeMapper` already handled majority of the variable mapping and its complexity grew to cover more use cases. This patch adds a very simple slots model to `LocalsTypeMapper` to compute variables out of the bytecode directly . `BytecodeLift` now knows all necessary information to emit relevant `VarOp` and `VarAccessOp` directly. Stability of `TestSmallCorpus` has slightly degraded, however it is just a temporary regression. Please review. Thanks, Adam ------------- Commit messages: - removed obsolete method - TestSmallCorpus changed back to double round and stability stats temporary degraded - fixed var type calculation - stabilization fixes - using JavaType.wildcard() for null types in BytecodeLift - direct var mapping - work in progress - direct var mapping - work in progress - direct var mapping - work in progress - direct var mapping - work in progress - direct var mapping - work in progress - ... and 4 more: https://git.openjdk.org/babylon/compare/15d8b3b3...13b21cca Changes: https://git.openjdk.org/babylon/pull/218/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=00 Stats: 770 lines in 6 files changed: 163 ins; 541 del; 66 mod Patch: https://git.openjdk.org/babylon/pull/218.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/218/head:pull/218 PR: https://git.openjdk.org/babylon/pull/218 From asotona at openjdk.org Fri Aug 23 13:01:58 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 23 Aug 2024 13:01:58 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v2] In-Reply-To: References: Message-ID: > Proposal of `BytecodeLift` implementation skipping intermediate use of `SlotOp` and `SlotSSA` transformation. > `LocalsTypeMapper` already handled majority of the variable mapping and its complexity grew to cover more use cases. > This patch adds a very simple slots model to `LocalsTypeMapper` to compute variables out of the bytecode directly . > `BytecodeLift` now knows all necessary information to emit relevant `VarOp` and `VarAccessOp` directly. > > Stability of `TestSmallCorpus` has slightly degraded, however it is just a temporary regression. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: added test ------------- Changes: - all: https://git.openjdk.org/babylon/pull/218/files - new: https://git.openjdk.org/babylon/pull/218/files/13b21cca..1e73c040 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=01 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=00-01 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.org/babylon/pull/218.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/218/head:pull/218 PR: https://git.openjdk.org/babylon/pull/218 From asotona at openjdk.org Fri Aug 23 14:21:37 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 23 Aug 2024 14:21:37 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v3] In-Reply-To: References: Message-ID: <8vs2YU7WgPlJeuTCQdkR9MxwtnBJgAwJDSdbkflJt_0=.bcc720fd-543b-4b4d-a9a5-7751533c23e7@github.com> > Proposal of `BytecodeLift` implementation skipping intermediate use of `SlotOp` and `SlotSSA` transformation. > `LocalsTypeMapper` already handled majority of the variable mapping and its complexity grew to cover more use cases. > This patch adds a very simple slots model to `LocalsTypeMapper` to compute variables out of the bytecode directly . > `BytecodeLift` now knows all necessary information to emit relevant `VarOp` and `VarAccessOp` directly. > > Stability of `TestSmallCorpus` has slightly degraded, however it is just a temporary regression. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with two additional commits since the last revision: - re-disabled TestSmallCorpus - Revert "TestSmallCorpus changed back to double round and stability stats temporary degraded" This reverts commit e8a55a1cd2bdfa3dd0c1d316d2dab1a924d745a8. ------------- Changes: - all: https://git.openjdk.org/babylon/pull/218/files - new: https://git.openjdk.org/babylon/pull/218/files/1e73c040..eb00a7e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=02 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=01-02 Stats: 25 lines in 1 file changed: 11 ins; 0 del; 14 mod Patch: https://git.openjdk.org/babylon/pull/218.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/218/head:pull/218 PR: https://git.openjdk.org/babylon/pull/218 From psandoz at openjdk.org Fri Aug 23 15:41:12 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 23 Aug 2024 15:41:12 GMT Subject: [code-reflection] RFR: Model synchronized statements In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024 08:51:56 GMT, Maurizio Cimadamore wrote: >> Model synchronized statements. >> >> A synchronized op has two bodies one for the expression yielding the monitor and one for the synchronized block that covers the monitor enter and exit. >> >> The lowering of synchronized op produces a model containing monitor enter and exit operations and operations covered by exception regions, ensuring that a monitor exits under exceptional circumstances. >> >> The interpreter has been updated, but locking is currently on a best effort basis using `ReentrantLock` instances thus we cannot consistently apply synchronization on objects across interpretation, executing in a single thread, and bytecode executing in one or more other threads. We would need to update the interpreter to use native methods that invoke the JNI `MonitorEnter` and `MonitorExit` methods, although it is not clear if those can be mixed in a nested manner with JVM execution of monitor enter and exit bytecode instructions. >> >> A simple test for generated bytecode has been included that tests for the expected number of monitor enter and exit instructions, and single threaded execution for non-exceptional and exceptional cases. > > src/java.base/share/classes/java/lang/reflect/code/interpreter/Interpreter.java line 567: > >> 565: .map(String::valueOf) >> 566: .collect(Collectors.joining()); >> 567: } else if (o instanceof CoreOp.MonitorOp.MonitorEnterOp) { > > Crazy suggestion: given the recent push of making more of the monitor logic be expressed in Java (as part of Loom), I wonder if it would make sense to imagine a world where a `synchronized` is just lowered to plain Java code - no special core ops? The really fundamental operation that cannot be expressed here is the "gimme a lock for this object". Something like: > > > lock = lockFor(synchronizedValue) // (1) > lock.lock(); > try { > // stats > } finally { > lock.unlock(); > } > > > Where (1) can be expressed as a core op similar to `ArrayLengthOp`. > > I realize that what you have here is more 1-1 with the bytecode, hence, maybe preferrable. But I wanted to put it out there :-) I would very much like to do that, alas we cannot today. `s.m.Unsafe` used to have methods to lock, try-lock, and unlock object monitors. I removed them :-) The JVM permits but does not enforce (HotSpot does enforce) constraints on structured locking (JVM spec section [2.11.10](https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-2.html#jvms-2.11.10)) ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/217#discussion_r1729169174 From psandoz at openjdk.org Fri Aug 23 15:41:56 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 23 Aug 2024 15:41:56 GMT Subject: git: openjdk/babylon: code-reflection: Model synchronized statements Message-ID: <353cfd56-a2f1-427c-a5a5-fb27d4100829@openjdk.org> Changeset: 345cfa09 Branch: code-reflection Author: Paul Sandoz Date: 2024-08-23 15:41:26 +0000 URL: https://git.openjdk.org/babylon/commit/345cfa0979c382f3e250880e567a5acba285b907 Model synchronized statements Reviewed-by: mcimadamore ! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java ! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeLift.java ! src/java.base/share/classes/java/lang/reflect/code/interpreter/Interpreter.java ! src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java ! src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java + test/jdk/java/lang/reflect/code/bytecode/TestSynchronizedOp.java + test/jdk/java/lang/reflect/code/lower/TestSynchronized.java + test/langtools/tools/javac/reflect/SynchronizedTest.java From psandoz at openjdk.org Fri Aug 23 15:45:16 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 23 Aug 2024 15:45:16 GMT Subject: [code-reflection] Integrated: Model synchronized statements In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 20:43:44 GMT, Paul Sandoz wrote: > Model synchronized statements. > > A synchronized op has two bodies one for the expression yielding the monitor and one for the synchronized block that covers the monitor enter and exit. > > The lowering of synchronized op produces a model containing monitor enter and exit operations and operations covered by exception regions, ensuring that a monitor exits under exceptional circumstances. > > The interpreter has been updated, but locking is currently on a best effort basis using `ReentrantLock` instances thus we cannot consistently apply synchronization on objects across interpretation, executing in a single thread, and bytecode executing in one or more other threads. We would need to update the interpreter to use native methods that invoke the JNI `MonitorEnter` and `MonitorExit` methods, although it is not clear if those can be mixed in a nested manner with JVM execution of monitor enter and exit bytecode instructions. > > A simple test for generated bytecode has been included that tests for the expected number of monitor enter and exit instructions, and single threaded execution for non-exceptional and exceptional cases. This pull request has now been integrated. Changeset: 345cfa09 Author: Paul Sandoz URL: https://git.openjdk.org/babylon/commit/345cfa0979c382f3e250880e567a5acba285b907 Stats: 681 lines in 9 files changed: 673 ins; 6 del; 2 mod Model synchronized statements Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/babylon/pull/217 From asotona at openjdk.org Fri Aug 23 15:52:52 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 23 Aug 2024 15:52:52 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v4] In-Reply-To: References: Message-ID: <80T1H6y8XU9sLaTL2OF-7ZEtgQF0Po6X_XNrT4boHS8=.059d610a-be04-43b5-a11a-bbbb76762403@github.com> > Proposal of `BytecodeLift` implementation skipping intermediate use of `SlotOp` and `SlotSSA` transformation. > `LocalsTypeMapper` already handled majority of the variable mapping and its complexity grew to cover more use cases. > This patch adds a very simple slots model to `LocalsTypeMapper` to compute variables out of the bytecode directly . > `BytecodeLift` now knows all necessary information to emit relevant `VarOp` and `VarAccessOp` directly. > > Stability of `TestSmallCorpus` has slightly degraded, however it is just a temporary regression. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: roundtrip stabilization ------------- Changes: - all: https://git.openjdk.org/babylon/pull/218/files - new: https://git.openjdk.org/babylon/pull/218/files/eb00a7e4..240c3888 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=03 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=02-03 Stats: 24 lines in 2 files changed: 10 ins; 2 del; 12 mod Patch: https://git.openjdk.org/babylon/pull/218.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/218/head:pull/218 PR: https://git.openjdk.org/babylon/pull/218 From psandoz at openjdk.org Fri Aug 23 16:34:12 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 23 Aug 2024 16:34:12 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v4] In-Reply-To: <80T1H6y8XU9sLaTL2OF-7ZEtgQF0Po6X_XNrT4boHS8=.059d610a-be04-43b5-a11a-bbbb76762403@github.com> References: <80T1H6y8XU9sLaTL2OF-7ZEtgQF0Po6X_XNrT4boHS8=.059d610a-be04-43b5-a11a-bbbb76762403@github.com> Message-ID: On Fri, 23 Aug 2024 15:52:52 GMT, Adam Sotona wrote: >> Proposal of `BytecodeLift` implementation skipping intermediate use of `SlotOp` and `SlotSSA` transformation. >> `LocalsTypeMapper` already handled majority of the variable mapping and its complexity grew to cover more use cases. >> This patch adds a very simple slots model to `LocalsTypeMapper` to compute variables out of the bytecode directly . >> `BytecodeLift` now knows all necessary information to emit relevant `VarOp` and `VarAccessOp` directly. >> >> Stability of `TestSmallCorpus` has slightly degraded, however it is just a temporary regression. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > roundtrip stabilization Overall this looks fine, and looks manageable in terms of complexity. I still need to look more closely. The prior approach served a purpose to move forward, but it looks like we no longer need it. AFAICT there are a few advantages to this approach: 1. There may be a closer correspondence to vars in the lowered and lifted model. We should be able to lower models in pure SSA or not. We lift into vars and if needed a separate SSA transformation can be applied. 2. We don't have to deal with the edge case of try/catch/finally reading and writing variables. Do you have a sense of where the additional failures in the corpus are occurring? I am hoping that such edge cases do not result in large increase in complexity. src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeLift.java line 235: > 233: case ITEM_DOUBLE -> params.add(JavaType.DOUBLE); > 234: case ITEM_LONG -> params.add(JavaType.LONG); > 235: case ITEM_NULL -> params.add(JavaType.wildcard()); That's a curious change, can you explain you did that? ------------- PR Comment: https://git.openjdk.org/babylon/pull/218#issuecomment-2307423100 PR Review Comment: https://git.openjdk.org/babylon/pull/218#discussion_r1729232010 From asotona at openjdk.org Mon Aug 26 08:19:24 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 26 Aug 2024 08:19:24 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v4] In-Reply-To: References: <80T1H6y8XU9sLaTL2OF-7ZEtgQF0Po6X_XNrT4boHS8=.059d610a-be04-43b5-a11a-bbbb76762403@github.com> Message-ID: <2HmFVmJip12bI6XIwzt5Ehd1LCa8BS_-HW6egAomLNI=.5b542095-0516-4899-89c9-1a7768bd9b06@github.com> On Fri, 23 Aug 2024 16:31:52 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> roundtrip stabilization > > src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeLift.java line 235: > >> 233: case ITEM_DOUBLE -> params.add(JavaType.DOUBLE); >> 234: case ITEM_LONG -> params.add(JavaType.LONG); >> 235: case ITEM_NULL -> params.add(JavaType.wildcard()); > > That's a curious change, can you explain why you did that? I did this purely for debugging purposes. It is hard to differentiate if a variable has J_L_OBJECT type intentionally or as a result of a bug in the merge process of the lift. I can revert it if needed. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/218#discussion_r1730872527 From asotona at openjdk.org Mon Aug 26 08:25:11 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 26 Aug 2024 08:25:11 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v4] In-Reply-To: References: <80T1H6y8XU9sLaTL2OF-7ZEtgQF0Po6X_XNrT4boHS8=.059d610a-be04-43b5-a11a-bbbb76762403@github.com> Message-ID: On Fri, 23 Aug 2024 16:30:31 GMT, Paul Sandoz wrote: > Do you have a sense of where the additional failures in the corpus are occurring? I am hoping that such edge cases do not result in large increase in complexity. There are actually no known bugs (in terms of invalid generated or lifted code), just roundtrip instabilities. The instabilities (mainly growing number of redundant variable declarations and loads) are caused by specific cases (yet to be isolated) and it should be fixable. ------------- PR Comment: https://git.openjdk.org/babylon/pull/218#issuecomment-2309632843 From psandoz at openjdk.org Mon Aug 26 15:50:18 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 26 Aug 2024 15:50:18 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v4] In-Reply-To: <2HmFVmJip12bI6XIwzt5Ehd1LCa8BS_-HW6egAomLNI=.5b542095-0516-4899-89c9-1a7768bd9b06@github.com> References: <80T1H6y8XU9sLaTL2OF-7ZEtgQF0Po6X_XNrT4boHS8=.059d610a-be04-43b5-a11a-bbbb76762403@github.com> <2HmFVmJip12bI6XIwzt5Ehd1LCa8BS_-HW6egAomLNI=.5b542095-0516-4899-89c9-1a7768bd9b06@github.com> Message-ID: On Mon, 26 Aug 2024 08:16:16 GMT, Adam Sotona wrote: >> src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeLift.java line 235: >> >>> 233: case ITEM_DOUBLE -> params.add(JavaType.DOUBLE); >>> 234: case ITEM_LONG -> params.add(JavaType.LONG); >>> 235: case ITEM_NULL -> params.add(JavaType.wildcard()); >> >> That's a curious change, can you explain why you did that? > > I did this purely for debugging purposes. It is hard to differentiate if a variable has J_L_OBJECT type intentionally or as a result of a bug in the merge process of the lift. > I can revert it if needed. It would be odd for that unbounded wildcard type to appear in the model e.g., for `Object o = null`, can it? I recommend hiding it behind a debug system property ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/218#discussion_r1731446285 From asotona at openjdk.org Mon Aug 26 15:50:18 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 26 Aug 2024 15:50:18 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v4] In-Reply-To: References: <80T1H6y8XU9sLaTL2OF-7ZEtgQF0Po6X_XNrT4boHS8=.059d610a-be04-43b5-a11a-bbbb76762403@github.com> <2HmFVmJip12bI6XIwzt5Ehd1LCa8BS_-HW6egAomLNI=.5b542095-0516-4899-89c9-1a7768bd9b06@github.com> Message-ID: On Mon, 26 Aug 2024 15:46:11 GMT, Paul Sandoz wrote: >> I did this purely for debugging purposes. It is hard to differentiate if a variable has J_L_OBJECT type intentionally or as a result of a bug in the merge process of the lift. >> I can revert it if needed. > > It would be odd for that unbounded wildcard type to appear in the model e.g., for `Object o = null`, can it? I recommend hiding it behind a debug system property I think I can remove it now, nulls should be no more an issue. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/218#discussion_r1731448498 From asotona at openjdk.org Mon Aug 26 15:58:31 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 26 Aug 2024 15:58:31 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v5] In-Reply-To: References: Message-ID: > Proposal of `BytecodeLift` implementation skipping intermediate use of `SlotOp` and `SlotSSA` transformation. > `LocalsTypeMapper` already handled majority of the variable mapping and its complexity grew to cover more use cases. > This patch adds a very simple slots model to `LocalsTypeMapper` to compute variables out of the bytecode directly . > `BytecodeLift` now knows all necessary information to emit relevant `VarOp` and `VarAccessOp` directly. > > Stability of `TestSmallCorpus` has slightly degraded, however it is just a temporary regression. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: - reverted wildcard type use in BytecodeLift - Bytecode lift names variables by slot number "slot#XY" - Stabilization of the roundtrip - single-use var allocations deferred ------------- Changes: - all: https://git.openjdk.org/babylon/pull/218/files - new: https://git.openjdk.org/babylon/pull/218/files/240c3888..ea76ac61 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=04 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=03-04 Stats: 39 lines in 4 files changed: 16 ins; 0 del; 23 mod Patch: https://git.openjdk.org/babylon/pull/218.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/218/head:pull/218 PR: https://git.openjdk.org/babylon/pull/218 From asotona at openjdk.org Mon Aug 26 16:01:30 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 26 Aug 2024 16:01:30 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v5] In-Reply-To: References: Message-ID: On Mon, 26 Aug 2024 15:58:31 GMT, Adam Sotona wrote: >> Proposal of `BytecodeLift` implementation skipping intermediate use of `SlotOp` and `SlotSSA` transformation. >> `LocalsTypeMapper` already handled majority of the variable mapping and its complexity grew to cover more use cases. >> This patch adds a very simple slots model to `LocalsTypeMapper` to compute variables out of the bytecode directly . >> `BytecodeLift` now knows all necessary information to emit relevant `VarOp` and `VarAccessOp` directly. >> >> Stability of `TestSmallCorpus` has slightly degraded, however it is just a temporary regression. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: > > - reverted wildcard type use in BytecodeLift > - Bytecode lift names variables by slot number "slot#XY" > - Stabilization of the roundtrip - single-use var allocations deferred Stability of the `TestSmallCorpus` is now back (even slightly better). ------------- PR Comment: https://git.openjdk.org/babylon/pull/218#issuecomment-2310545382 From psandoz at openjdk.org Mon Aug 26 16:50:15 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 26 Aug 2024 16:50:15 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v5] In-Reply-To: References: Message-ID: On Mon, 26 Aug 2024 15:58:31 GMT, Adam Sotona wrote: >> Proposal of `BytecodeLift` implementation skipping intermediate use of `SlotOp` and `SlotSSA` transformation. >> `LocalsTypeMapper` already handled majority of the variable mapping and its complexity grew to cover more use cases. >> This patch adds a very simple slots model to `LocalsTypeMapper` to compute variables out of the bytecode directly . >> `BytecodeLift` now knows all necessary information to emit relevant `VarOp` and `VarAccessOp` directly. >> >> Stability of `TestSmallCorpus` has slightly degraded, however it is just a temporary regression. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: > > - reverted wildcard type use in BytecodeLift > - Bytecode lift names variables by slot number "slot#XY" > - Stabilization of the roundtrip - single-use var allocations deferred src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 987: > 985: > 986: // Checks if the Op.Result is used more than once in operands and block arguments > 987: private static boolean moreThanOneUse(Value val) { Memo to self - we should have something in the API. More generally, liveness analysis of values might help formalize when a value is no longer used and its slot can be reused with another value. I suspect generating bytecode in from models in pure SSA might result use of more locals than actually needed. src/java.base/share/classes/java/lang/reflect/code/bytecode/LocalsTypeMapper.java line 328: > 326: case IncrementInstruction i -> { > 327: Slot v = locals.get(i.slot()); > 328: v.writes++; Why is this required? I likely don't understand the significance of this and how it differs from a store instruction. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/218#discussion_r1731489221 PR Review Comment: https://git.openjdk.org/babylon/pull/218#discussion_r1731517616 From asotona at openjdk.org Mon Aug 26 17:34:50 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 26 Aug 2024 17:34:50 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v6] In-Reply-To: References: Message-ID: > Proposal of `BytecodeLift` implementation skipping intermediate use of `SlotOp` and `SlotSSA` transformation. > `LocalsTypeMapper` already handled majority of the variable mapping and its complexity grew to cover more use cases. > This patch adds a very simple slots model to `LocalsTypeMapper` to compute variables out of the bytecode directly . > `BytecodeLift` now knows all necessary information to emit relevant `VarOp` and `VarAccessOp` directly. > > Stability of `TestSmallCorpus` has slightly degraded, however it is just a temporary regression. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: different approach to handle lift of IncrementInstruction ------------- Changes: - all: https://git.openjdk.org/babylon/pull/218/files - new: https://git.openjdk.org/babylon/pull/218/files/ea76ac61..fb2b937c Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=05 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=04-05 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/babylon/pull/218.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/218/head:pull/218 PR: https://git.openjdk.org/babylon/pull/218 From asotona at openjdk.org Mon Aug 26 17:34:50 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 26 Aug 2024 17:34:50 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v5] In-Reply-To: References: Message-ID: On Mon, 26 Aug 2024 16:47:42 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision: >> >> - reverted wildcard type use in BytecodeLift >> - Bytecode lift names variables by slot number "slot#XY" >> - Stabilization of the roundtrip - single-use var allocations deferred > > src/java.base/share/classes/java/lang/reflect/code/bytecode/LocalsTypeMapper.java line 328: > >> 326: case IncrementInstruction i -> { >> 327: Slot v = locals.get(i.slot()); >> 328: v.writes++; > > Why is this required? I likely don't understand the significance of this and how it differs from a store instruction. I've just pushed a different approach - load and store + link two var fragments. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/218#discussion_r1731576867 From psandoz at openjdk.org Mon Aug 26 18:51:17 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 26 Aug 2024 18:51:17 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v6] In-Reply-To: References: Message-ID: On Mon, 26 Aug 2024 17:34:50 GMT, Adam Sotona wrote: >> Proposal of `BytecodeLift` implementation skipping intermediate use of `SlotOp` and `SlotSSA` transformation. >> `LocalsTypeMapper` already handled majority of the variable mapping and its complexity grew to cover more use cases. >> This patch adds a very simple slots model to `LocalsTypeMapper` to compute variables out of the bytecode directly . >> `BytecodeLift` now knows all necessary information to emit relevant `VarOp` and `VarAccessOp` directly. >> >> Stability of `TestSmallCorpus` has slightly degraded, however it is just a temporary regression. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > different approach to handle lift of IncrementInstruction Marked as reviewed by psandoz (Lead). src/java.base/share/classes/java/lang/reflect/code/bytecode/LocalsTypeMapper.java line 58: > 56: final class LocalsTypeMapper { > 57: > 58: private record Link(Slot slot, Link other) {} Consider enclosing the declaration of `Link` in `Slot` (with the same access control as `Slot`). ------------- PR Review: https://git.openjdk.org/babylon/pull/218#pullrequestreview-2261375084 PR Review Comment: https://git.openjdk.org/babylon/pull/218#discussion_r1731666662 From asotona at openjdk.org Tue Aug 27 12:40:13 2024 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 27 Aug 2024 12:40:13 GMT Subject: git: openjdk/babylon: code-reflection: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes Message-ID: <7524c1e5-d630-4e58-888f-1e78bf8fdc88@openjdk.org> Changeset: 207ca5e1 Branch: code-reflection Author: Adam Sotona Date: 2024-08-27 12:37:50 +0000 URL: https://git.openjdk.org/babylon/commit/207ca5e15964aa9dced66cb81c911c59527d6d8b BytecodeLift directly calculating local variables + related BytecodeGenerator fixes Reviewed-by: psandoz ! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java ! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeLift.java ! src/java.base/share/classes/java/lang/reflect/code/bytecode/LocalsTypeMapper.java - src/java.base/share/classes/java/lang/reflect/code/bytecode/SlotOp.java - src/java.base/share/classes/java/lang/reflect/code/bytecode/SlotSSA.java ! test/jdk/java/lang/reflect/code/bytecode/TestBytecode.java ! test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java From asotona at openjdk.org Tue Aug 27 12:40:33 2024 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 27 Aug 2024 12:40:33 GMT Subject: [code-reflection] RFR: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes [v7] In-Reply-To: References: Message-ID: <5YKtKmgmDb8C-xXrKfh1Em8OAoCtlVm-xWW8hKCjNxQ=.6b29db62-47bc-4647-9003-79b3575dab82@github.com> > Proposal of `BytecodeLift` implementation skipping intermediate use of `SlotOp` and `SlotSSA` transformation. > `LocalsTypeMapper` already handled majority of the variable mapping and its complexity grew to cover more use cases. > This patch adds a very simple slots model to `LocalsTypeMapper` to compute variables out of the bytecode directly . > `BytecodeLift` now knows all necessary information to emit relevant `VarOp` and `VarAccessOp` directly. > > Stability of `TestSmallCorpus` has slightly degraded, however it is just a temporary regression. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: LocalsTypeMapper.Link moved under LocalsTypeMapper.Slot ------------- Changes: - all: https://git.openjdk.org/babylon/pull/218/files - new: https://git.openjdk.org/babylon/pull/218/files/fb2b937c..c10f265b Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=06 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=218&range=05-06 Stats: 23 lines in 1 file changed: 11 ins; 9 del; 3 mod Patch: https://git.openjdk.org/babylon/pull/218.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/218/head:pull/218 PR: https://git.openjdk.org/babylon/pull/218 From asotona at openjdk.org Tue Aug 27 12:40:33 2024 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 27 Aug 2024 12:40:33 GMT Subject: [code-reflection] Integrated: BytecodeLift directly calculating local variables + related BytecodeGenerator fixes In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024 11:58:55 GMT, Adam Sotona wrote: > Proposal of `BytecodeLift` implementation skipping intermediate use of `SlotOp` and `SlotSSA` transformation. > `LocalsTypeMapper` already handled majority of the variable mapping and its complexity grew to cover more use cases. > This patch adds a very simple slots model to `LocalsTypeMapper` to compute variables out of the bytecode directly . > `BytecodeLift` now knows all necessary information to emit relevant `VarOp` and `VarAccessOp` directly. > > Stability of `TestSmallCorpus` has slightly degraded, however it is just a temporary regression. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 207ca5e1 Author: Adam Sotona URL: https://git.openjdk.org/babylon/commit/207ca5e15964aa9dced66cb81c911c59527d6d8b Stats: 811 lines in 7 files changed: 205 ins; 532 del; 74 mod BytecodeLift directly calculating local variables + related BytecodeGenerator fixes Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/babylon/pull/218 From asotona at openjdk.org Fri Aug 30 14:11:54 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 30 Aug 2024 14:11:54 GMT Subject: [code-reflection] RFR: Bytecode round 12 Message-ID: - Added test for operand values dominance revealed a bug in the BytecodeLift. - Fixed BytecodeLift revealed regression in the roundtrip stability. - Roundtrip instability was caused by a bug in the LocalsTypeMapper. All the above is fixed and the roundtrip stability is restored. Please review. Thanks, Adam ------------- Commit messages: - restored roundtrip stability - fixed LocalsTypeMapper - TestSmallCorpus actual numbers - Roundtrip stabilization - deferred redundant var initializations with defaults in BytecodeGenerator - fixed lifting of variables without dominant initial store - Added Op operand values declaration dominance verification to TestSmallCorpus Changes: https://git.openjdk.org/babylon/pull/219/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=219&range=00 Stats: 162 lines in 4 files changed: 141 ins; 0 del; 21 mod Patch: https://git.openjdk.org/babylon/pull/219.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/219/head:pull/219 PR: https://git.openjdk.org/babylon/pull/219 From asotona at openjdk.org Fri Aug 30 14:17:04 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 30 Aug 2024 14:17:04 GMT Subject: [code-reflection] RFR: Bytecode round 12 [v2] In-Reply-To: References: Message-ID: > - Added test for operand values dominance revealed a bug in the BytecodeLift. > - Fixed BytecodeLift revealed regression in the roundtrip stability. > - Roundtrip instability was caused by a bug in the LocalsTypeMapper. > > All the above is fixed and the roundtrip stability is restored. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: minor corrections ------------- Changes: - all: https://git.openjdk.org/babylon/pull/219/files - new: https://git.openjdk.org/babylon/pull/219/files/59c2cecd..ae7f0ccf Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=219&range=01 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=219&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/219.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/219/head:pull/219 PR: https://git.openjdk.org/babylon/pull/219 From asotona at openjdk.org Fri Aug 30 14:31:13 2024 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 30 Aug 2024 14:31:13 GMT Subject: [code-reflection] RFR: Bytecode round 12 [v3] In-Reply-To: References: Message-ID: > - Added test for operand values dominance revealed a bug in the BytecodeLift. > - Fixed BytecodeLift revealed regression in the roundtrip stability. > - Roundtrip instability was caused by a bug in the LocalsTypeMapper. > > All the above is fixed and the roundtrip stability is restored. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: minor corrections ------------- Changes: - all: https://git.openjdk.org/babylon/pull/219/files - new: https://git.openjdk.org/babylon/pull/219/files/ae7f0ccf..60e3d36d Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=219&range=02 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=219&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/babylon/pull/219.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/219/head:pull/219 PR: https://git.openjdk.org/babylon/pull/219 From psandoz at openjdk.org Fri Aug 30 20:51:42 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 30 Aug 2024 20:51:42 GMT Subject: [code-reflection] RFR: Bytecode round 12 [v3] In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 14:31:13 GMT, Adam Sotona wrote: >> - Added test for operand values dominance revealed a bug in the BytecodeLift. >> - Fixed BytecodeLift revealed regression in the roundtrip stability. >> - Roundtrip instability was caused by a bug in the LocalsTypeMapper. >> >> All the above is fixed and the roundtrip stability is restored. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > minor corrections It's good to see the value-based `isDominatedBy`method being used, probably the first time in anger (not much prior testing on that). How fastidious are you being about round trip stability? Given the following chain of events, where B == bytecode and M == code mode, B1 -> M1 -> B2 -> M2 -> B3 -> M3 Do you want M1, M2 and M3 to be the same or just M2 and M3? src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 399: > 397: } > 398: > 399: Set stopBlocks = new HashSet<>(); If i got this right, we are dealing with an equivalent of an uninitialized variable, of a primitive type, in source that will be assigned in divergent code paths, and the compiler will check it's DA. In the model we currently require the modelling var op be initialized with a default constant value for the primitive type. We don't currently have a concept of an uninitialized value (which might help?), so we have to detect that all loads are dominated by stores, some of which are initializing stores (which detects the uninitialized case or a redundant initialization). This specific bit of code after the dominated by checks determines if there is a path from `n`'s declaring block to the entry block that does not pass through any of `dom`'s declaring blocks? Why is that is important? test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java line 171: > 169: private void verify(String category, CoreOp.FuncOp func) { > 170: OpWriter.CodeItemNamerOption naming = null; > 171: for (Body body : func.bodies()) { It's possible to collapse all the loops by traversing the operations, passing in `naming` as the argument e.g., naming = func.traverse(naming, opVisitor((n, op) -> { for (Value v : op.operands()) { if (!op.result().isDominatedBy(v)) { if (n == null) { n = ... } ... } } return n; })); ------------- PR Review: https://git.openjdk.org/babylon/pull/219#pullrequestreview-2273428609 PR Review Comment: https://git.openjdk.org/babylon/pull/219#discussion_r1739399511 PR Review Comment: https://git.openjdk.org/babylon/pull/219#discussion_r1739373420