[code-reflection] RFR: Experiment: Alternative SSA construction algorithm

Paul Sandoz psandoz at openjdk.org
Mon Oct 21 21:52:48 UTC 2024


On Sun, 20 Oct 2024 16:22:44 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> > Not at the moment. How about we do the following? Switch to use the new implementation, ensuring tests pass. Keep the old one too and ensure it is explicitly tested, since it is a good test case. And incrementally, if needed, update the new implementation.
> 
> Okay, I'll do that. Is there are way in jtreg to run tests with different system properties? This way we could just check for the property in one of the transform methods (in one of the classes) and delegate to the other depending on what was passed. This is how I tested it locally, but running tests for both this way (where they don't have different results that are relevant to the test) might make sense. WDYT?

Yes, see [here](https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java#L24)

> 
> > Yes, blocks can only reference other blocks from within the same body. Do you need access to a parent context?
> 
> I mainly was confused by the difference, without any need for it. But I also experimented with "preparing" a copy context that I then pass to the `Op#transform(CopyContext, OpTransformer)` call. That also didn't work well for other reasons, and it might be not an intended use at all, but in such scenario it would matter.

Ok. For some wider context i am wondering if it is possible to place all the transform logic within `OpTransformer`. What's missing is the code to transform an input body into output operations added to a block builder. `OpTransformer` should only use public APIs. This may make the transformation seem less special, its just a particular composition of traversal and building with some booking between input and output code items. (Further, `CopyContext` is a terrible name!)

-------------

PR Comment: https://git.openjdk.org/babylon/pull/214#issuecomment-2427806391


More information about the babylon-dev mailing list