On Thu, 4 Feb 2021 15:13:49 GMT, Anton Kozlov <akoz...@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.joels...@oracle.com) on > [2d-dev](mailto:2d-dev@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