On Thu, 23 Feb 2023 04:44:18 GMT, Martin Doerr <mdo...@openjdk.org> wrote:
> > > (I'd be happy to implement the needed changes in shared code if you want, > > > since it touches `BindingSpecializer` which is pretty dense) > > > > > > FYI: > > [master...JornVernee:jdk:I2L](https://github.com/openjdk/jdk/compare/master...JornVernee:jdk:I2L) > > (assuming `I2L` has the same semantics as `extsw`). Then just add a > > `.cast(int.class, long.class)` wherever currently an `int` is `vmStore`d in > > the PPC CallArranger. > > Correct, `extsw` performs a `I2L` conversion. I had thought about this > already, but I think my current implementation is more efficient as it > combines register moves with the 64 bit extend. Your proposal would generate > separate extend and move instructions, right? The design philosophy has been to put as much as possible on the Java side, and there are a few reasons for that: 1. For maintainability. Generated assembly is ultimately harder to debug, compared to Java code (especially in interpreted mode using `-Djdk.internal.foreign.*Linker.USE_SPEC=false`). (Though, there might also be some personal bias here) 2. Moving things to the Java side makes it visible to the JIT, which means it has the opportunity to be optimized away, or otherwise optimized together with the surrounding Java code. While anything put into the downcall stub is fixed. 3. If we want to intrisify `linkToNative` in C2 later, having downcall stubs be simple and consistent across platforms makes that much easier. Anything that's special in the native code would have to be replicated by the JIT as well. So... WRT efficiency, I think it depends. I've found in the past that adding a few more move instructions to the downcall stub didn't visibly affect performance. This might be because the CPU is good at just aliasing the registers instead of performing an actual move, or because it's just noise next to the membar we do on the return path. Ultimately, I don't think it matters much for performance, though (you could measure). I think the maintainability/future-proofing from implementing in Java is more important. ------------- PR: https://git.openjdk.org/jdk/pull/12708
