RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

[Vladimir Kempik]

On Thu, 4 Feb 2021 15:13:49 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Out of curiosity, have you looked at the performance of the W^X state transition? In particular I'm wondering if the cost is effectively negligible so doing it unconditionally on JVM entry is a no-brainer and just easier/cleaner than the alternatives, or if there are reasons to look at only doing the transition if/when needed (perhaps do it lazily and revert back to X when leaving the JVM?).
>
>> Out of curiosity, have you looked at the performance of the W^X state transition?
> 
> Earlier it was possible to disable W^X protection (unfortunately, I don't know a way to do this now). We compared Renaissance results with W^X transitions like the proposed one vs. no transitions with the protection disabled once. Results were identical for a small and large number of iterations.
> 
> From the other hand, I've used https://github.com/AntonKozlov/macos-aarch64-transition-bench to estimate the cost of the transition.
> I re-did measurements with the current implementation and on consumer hardware:
> 
> testJNI            thrpt   25   277997000.151 ±   4095685.956  ops/s
> testJniNanoTime    thrpt   25    17851098.010 ±    119489.599  ops/s
> testNanoTime       thrpt   25    78007491.762 ±    628455.971  ops/s
> testNothing        thrpt   25  1724298829.088 ± 100537565.068  ops/s
> testTwoStateAndWX  thrpt   25    21958839.057 ±    210490.755  ops/s
> testWX             thrpt   25    23299813.266 ±    149837.302  ops/s
> 
> There is an overhead, but it does not look like blocking the first implementation. I'm not refusing future optimizations like enabling W only when necessary. But for now, I don't have a robust and maintainable solution for this, sorry.

> _Mailing list message from [erik.joelsson at oracle.com](mailto:erik.joelsson at oracle.com) on [2d-dev](mailto:2d-dev at openjdk.java.net):_
> 
> On 2021-01-26 04:44, Magnus Ihse Bursie wrote:
> 
> > On 2021-01-26 13:09, Vladimir Kempik wrote:
> > > On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward
> > > <github.com+4146708+a74nh at openjdk.org> wrote:
> > > > AIUI, the configure line needs passing a prebuilt
> > > > JavaNativeFoundation framework
> > > > ie:
> > > > `--with-extra-ldflags='-F
> > > > /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
> > > > Otherwise there will be missing _JNFNative* functions.
> > > > Is this the long term plan? Or will eventually the required code be
> > > > moved into JDK and/or the xcode one automatically get picked up by
> > > > the configure scripts?
> > > > There is ongoing work by P. Race to eliminate dependence on JNF at all
> > > > How far has that work come? Otherwise the logic should be added to
> > > > configure to look for this framework automatically, and provide a way
> > > > to override it/set it if not found.
> > 
> > 
> > I don't think it's OK to publish a new port that cannot build
> > out-of-the-box without hacks like this.
> 
> My understanding is that Apple chose to not provide JNF for aarch64, so
> if you want to build OpenJDK, you first need to build JNF yourself (it's
> available in github). Phil is working on removing this dependency
> completely, which will solve this issue [1].
> 
> In the meantime, I don't think we should rely on finding JNF in
> unsupported locations inside Xcode. Could we wait with integrating this
> port until it can be built without such hacks? If not, then adding
> something in the documentation on how to get a working JNF would at
> least be needed.
> 
> /Erik
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8257852

This doesn't seem to be an issue anymore, After P.Race have finished with JDK-8257852, Macarm port can be build without extra ld flags. J2Demo works fine as example.
This can be checked if one merges pull/2200 branch into his local copy of master branch.

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

PR: https://git.openjdk.java.net/jdk/pull/2200