Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]
On Mon, 15 Feb 2021 19:07:40 GMT, Andrew Haley wrote: >> Hello, we have updated PR, now this bailout is used only by the code which >> can handle it (native wrapper generator), for the rest it will cause >> guarantee failed if this bailout is triggered > > This is when passing a float, yes? In the case where we have more float > arguments than n_float_register_parameters_c. > I don't understand why you think it's acceptable to bail in this case. Can > you explain, please? it's for everything that uses less than 8 bytes on a stack( ints ( 4), shorts(2), bytes(1), floats(4)). currently native wrapper generation does not support such cases at all, it needs refactoring before this can be implemented. So when a method has more argument than can be placed in registers, we may have issues. So we just bailing out to interpreter in case when a smaller (<=4 b) type is going to be passed thru the stack. There was attempt to implement handling such cases but currently it requires some hacks (like using some vectors for non-specific task) - https://github.com/openjdk/aarch64-port/pull/3 - PR: https://git.openjdk.java.net/jdk/pull/2200
Withdrawn: 8253757: Add LLVM-based backend for hsdis
On Tue, 29 Sep 2020 04:36:16 GMT, Ludovic Henry wrote: > When bringing up Hotspot onto new platforms, it is not always possible to > compile hsdis because gcc is not yet available. For example, for > Windows-AArch64 and macOS-AArch64. > > For some such platforms, it is possible to use LLVM as an alternative backend > as it also supports a disassembler feature. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/392
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v8]
On Mon, 15 Feb 2021 20:52:09 GMT, Gerard Ziemski wrote: >> Ajit Ghaisas 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 20 additional >> commits since the last revision: >> >> - Lanai PR#191 - 8261705 - jdv >> - Lanai PR#190 - 8261706 - jdv >> - Lanai PR#189 - 8261712 - avu >> - Lanai PR#187 - 8261704 - jdv >> - Lanai PR#186 - 8261638 - avu >> - Lanai PR#185 - 8261632 - jdv >> - Lanai PR#184 - 8261620 - aghaisas >> - Lanai PR#182 - 8261547 - psadhukhan >> - Merge branch 'master' into 8260931_lanai_JEP_branch >> - Lanai PR#181 - 8261143 - aghaisas >> - ... and 10 more: >> https://git.openjdk.java.net/jdk/compare/c8554bef...7b0b0dc4 > > Marked as reviewed by gziemski (Committer). > > > Thanks @gerard-ziemski for taking a detailed look at this. > > > We do have an open bug to address this. Please refer > > > [JDK-8259825](https://bugs.openjdk.java.net/browse/JDK-8259825). > > > > > > Hi Gerard, expecting a process and parsing its output is definitely not > > ideal and that's why there's this open bug. > > One thing that is under consideration is to equate >= 10.14 with Metal is > > available since as of 10.14 macOS won't install if a system does not > > support metal. We have no compelling reason to support metal on earlier > > releases anyway .. those are either already unsupported or barely supported > > and OGL will always be available there. > > I did not know that there already was a bug covering this issue. > > Your idea seems reasonable. > > More than just focusing on this immediate issue, however, I was hoping to > raise the point of us starting adopting profiling tools to analyze our code > (memory utilization, leaks, cpu/gpu profiling etc). A new feature that brings > 10% benefit, but uses 50% more resources for example would probably not be a > good investment. And to figure that we need to relay on some good tools and > Xcode provides some. There were actually tasks to do profiling of the memory footprint and look for leaks. We did not think it possible to be able to assert "Metal must use less memory than OpenGL" or dig into tiny differences but it was intended to find the big issues. See https://bugs.openjdk.java.net/browse/JDK-8237856 @prsadhuk maybe able to say how much of it was doing using Xcode. - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v8]
On Mon, 15 Feb 2021 06:24:13 GMT, Ajit Ghaisas wrote: >> **Description :** >> This is the implementation of [JEP 382 : New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) >> It implements a Java 2D internal rendering pipeline for macOS using the >> Apple Metal API. >> The entire work on this was done under [OpenJDK Project - >> Lanai](http://openjdk.java.net/projects/lanai/) >> >> We iterated through several Early Access (EA) builds and have reached a >> stage where it is ready to be integrated to openjdk/jdk. The latest EA build >> is available at - https://jdk.java.net/lanai/ >> >> A new option -Dsun.java2d.metal=true | True needs to be used to use this >> pipeline. >> >> **Testing :** >> This implementation has been tested with the tests present at - [Test Plan >> for JEP 382: New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396) >> >> **Note to reviewers :** >> 1) Default rendering pipeline on macOS has not been changed by this PR. >> OpenGL still stays as the default rendering pipeline and Metal rendering >> pipeline is optional to choose. >> >> 2) To apply and test this PR - >> To enable the metal pipeline you must specify on command line >> -Dsun.java2d.metal=true (No message will be printed in this case) or >> -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is >> enabled gets printed) >> >> 3) Review comments (including some preliminary informal review comments) are >> tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598 > > Ajit Ghaisas 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 20 additional > commits since the last revision: > > - Lanai PR#191 - 8261705 - jdv > - Lanai PR#190 - 8261706 - jdv > - Lanai PR#189 - 8261712 - avu > - Lanai PR#187 - 8261704 - jdv > - Lanai PR#186 - 8261638 - avu > - Lanai PR#185 - 8261632 - jdv > - Lanai PR#184 - 8261620 - aghaisas > - Lanai PR#182 - 8261547 - psadhukhan > - Merge branch 'master' into 8260931_lanai_JEP_branch > - Lanai PR#181 - 8261143 - aghaisas > - ... and 10 more: > https://git.openjdk.java.net/jdk/compare/827ab648...7b0b0dc4 Marked as reviewed by gziemski (Committer). - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v7]
On Mon, 15 Feb 2021 18:30:51 GMT, Gerard Ziemski wrote: >> Changes requested by gziemski (Committer). > > I took a look at https://bugs.openjdk.java.net/browse/JDK-8261408 and noticed > a startup time regression with the Metal rendering pipeline, so I dug a bit > and here is what I found using Xcode startup profiler: > > Here is the OpenGL pipeline: > src="https://user-images.githubusercontent.com/63425797/107981859-8efb4780-6f88-11eb-849a-385c29f3ff6f.png";> > > > Here is the Metal pipeline: > src="https://user-images.githubusercontent.com/63425797/107981882-9ae70980-6f88-11eb-9b73-d1bd19dfa07f.png";> > > If I read the results correctly, there is a weird 330ms time gap in the case > of the Metal pipeline where nothing is done and it looks like the culprit is > `Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable` > > The OpenGL pipeline gets blocked only for 83ms in > `Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo` > > I would advice that we take a closer look at why > 'Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable' takes so > long, and optimize it, or cache the results, so the next VM instance can skip > it if needed (assuming the call doesn't end up initializing the native Metal > or something like that), still worth taking a look. > > I would also recommend that you adopt Xcode and its Instruments profiler > tools for future work. Please let me know if you need help in this area. > > I only scratched the surface here and I think that there is plenty of > profiling that can be done to investigate the startup time regression further. > > Thanks @gerard-ziemski for taking a detailed look at this. > > We do have an open bug to address this. Please refer > > [JDK-8259825](https://bugs.openjdk.java.net/browse/JDK-8259825). > > Hi Gerard, expecting a process and parsing its output is definitely not ideal > and that's why there's this open bug. > One thing that is under consideration is to equate >= 10.14 with Metal is > available since as of 10.14 macOS won't install if a system does not support > metal. We have no compelling reason to support metal on earlier releases > anyway .. those are either already unsupported or barely supported and OGL > will always be available there. I did not know that there already was a bug covering this issue. Your idea seems reasonable. More than just focusing on this immediate issue, however, I was hoping to raise the point of us starting adopting profiling tools to analyze our code (memory utilization, leaks, cpu/gpu profiling etc). A new feature that brings 10% benefit, but uses 50% more resources for example would probably not be a good investment. And to figure that we need to relay on some good tools and Xcode provides some. - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v7]
On Mon, 15 Feb 2021 18:30:51 GMT, Gerard Ziemski wrote: >> Changes requested by gziemski (Committer). > > I took a look at https://bugs.openjdk.java.net/browse/JDK-8261408 and noticed > a startup time regression with the Metal rendering pipeline, so I dug a bit > and here is what I found using Xcode startup profiler: > > Here is the OpenGL pipeline: > src="https://user-images.githubusercontent.com/63425797/107981859-8efb4780-6f88-11eb-849a-385c29f3ff6f.png";> > > > Here is the Metal pipeline: > src="https://user-images.githubusercontent.com/63425797/107981882-9ae70980-6f88-11eb-9b73-d1bd19dfa07f.png";> > > If I read the results correctly, there is a weird 330ms time gap in the case > of the Metal pipeline where nothing is done and it looks like the culprit is > `Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable` > > The OpenGL pipeline gets blocked only for 83ms in > `Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo` > > I would advice that we take a closer look at why > 'Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable' takes so > long, and optimize it, or cache the results, so the next VM instance can skip > it if needed (assuming the call doesn't end up initializing the native Metal > or something like that), still worth taking a look. > > I would also recommend that you adopt Xcode and its Instruments profiler > tools for future work. Please let me know if you need help in this area. > > I only scratched the surface here and I think that there is plenty of > profiling that can be done to investigate the startup time regression further. > Thanks @gerard-ziemski for taking a detailed look at this. > We do have an open bug to address this. Please refer > [JDK-8259825](https://bugs.openjdk.java.net/browse/JDK-8259825). Hi Gerard, expecting a process and parsing its output is definitely not ideal and that's why there's this open bug. One thing that is under consideration is to equate >= 10.14 with Metal is available since as of 10.14 macOS won't install if a system does not support metal. We have no compelling reason to support metal on earlier releases anyway .. those are either already unsupported or barely supported and OGL will always be available there. - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]
On Mon, 15 Feb 2021 18:00:50 GMT, Vladimir Kempik wrote: >> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839: >> >>> 837: // The code unable to handle this, bailout. >>> 838: return -1; >>> 839: #endif >> >> This looks like a bug to me. The caller doesn't necessarily check the return >> value. See CallRuntimeNode::calling_convention. > > Hello, we have updated PR, now this bailout is used only by the code which > can handle it (native wrapper generator), for the rest it will cause > guarantee failed if this bailout is triggered This is when passing a float, yes? In the case where we have more float arguments than n_float_register_parameters_c. I don't understand why you think it's acceptable to bail in this case. Can you explain, please? - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v7]
On Mon, 15 Feb 2021 18:30:51 GMT, Gerard Ziemski wrote: >> Changes requested by gziemski (Committer). > > I took a look at https://bugs.openjdk.java.net/browse/JDK-8261408 and noticed > a startup time regression with the Metal rendering pipeline, so I dug a bit > and here is what I found using Xcode startup profiler: > > Here is the OpenGL pipeline: > src="https://user-images.githubusercontent.com/63425797/107981859-8efb4780-6f88-11eb-849a-385c29f3ff6f.png";> > > > Here is the Metal pipeline: > src="https://user-images.githubusercontent.com/63425797/107981882-9ae70980-6f88-11eb-9b73-d1bd19dfa07f.png";> > > If I read the results correctly, there is a weird 330ms time gap in the case > of the Metal pipeline where nothing is done and it looks like the culprit is > `Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable` > > The OpenGL pipeline gets blocked only for 83ms in > `Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo` > > I would advice that we take a closer look at why > 'Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable' takes so > long, and optimize it, or cache the results, so the next VM instance can skip > it if needed (assuming the call doesn't end up initializing the native Metal > or something like that), still worth taking a look. > > I would also recommend that you adopt Xcode and its Instruments profiler > tools for future work. Please let me know if you need help in this area. > > I only scratched the surface here and I think that there is plenty of > profiling that can be done to investigate the startup time regression further. Thanks @gerard-ziemski for taking a detailed look at this. We do have an open bug to address this. Please refer [JDK-8259825](https://bugs.openjdk.java.net/browse/JDK-8259825). - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v7]
On Thu, 11 Feb 2021 20:55:47 GMT, Gerard Ziemski wrote: >> Ajit Ghaisas has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Lanai PR#181 - 8261143 - aghaisas >> - Lanai PR#180 - 8261546 - jdv > > Changes requested by gziemski (Committer). I took a look at https://bugs.openjdk.java.net/browse/JDK-8261408 and noticed a startup time regression with the Metal rendering pipeline, so I dug a bit and here is what I found using Xcode startup profiler: Here is the OpenGL pipeline: https://user-images.githubusercontent.com/63425797/107981859-8efb4780-6f88-11eb-849a-385c29f3ff6f.png";> Here is the Metal pipeline: https://user-images.githubusercontent.com/63425797/107981882-9ae70980-6f88-11eb-9b73-d1bd19dfa07f.png";> If I read the results correctly, there is a weird 330ms time gap in the case of the Metal pipeline where nothing is done and it looks like the culprit is `Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable` The OpenGL pipeline gets blocked only for 83ms in `Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo` I would advice that we take a closer look at why 'Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable' takes so long, and optimize it, or cache the results, so the next VM instance can skip it if needed (assuming the call doesn't end up initializing the native Metal or something like that), still worth taking a look. I would also recommend that you adopt Xcode and its Instruments profiler tools for future work. Please let me know if you need help in this area. I only scratched the surface here and I think that there is plenty of profiling that can be done to investigate the startup time regression further. - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v17]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #9 from VladimirKempik/pull/2200 Removed unused variables - Removed unused variables - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/419c2b1a..90e244e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=15-16 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v16]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #6 from VladimirKempik/pull/2200 Fix typo in comments - Fix typo in comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/a9452a4c..419c2b1a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Wed, 3 Feb 2021 20:08:41 GMT, Anton Kozlov wrote: > I'm going to do as much refactoring as needed before this patch under > JDK-8261071 The recent merge resolves inconsitency between pass_byte/pass_short and other methods. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]
On Mon, 1 Feb 2021 18:44:48 GMT, Andrew Haley wrote: >> Anton Kozlov has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 62 commits: >> >> - Merge branch 'master' into jdk-macos >> - Update copyright year for BsdAARCH64ThreadContext.java >> - Fix inclusing of StubRoutines header >> - Redo buildsys fix >> - Revert harfbuzz changes, disable warnings for it >> - Little adjustement of SlowSignatureHandler >> - Partially bring previous commit >> - Revert "Address feedback for signature generators" >> >>This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d. >> - Refactor CDS disabling >> - Redo builsys support for aarch64-darwin >> - ... and 52 more: >> https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4 > > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839: > >> 837: // The code unable to handle this, bailout. >> 838: return -1; >> 839: #endif > > This looks like a bug to me. The caller doesn't necessarily check the return > value. See CallRuntimeNode::calling_convention. Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Tue, 2 Feb 2021 21:52:47 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 810: > >> 808: #ifdef __APPLE__ >> 809: // Less-than word types are stored one after another. >> 810: // The code unable to handle this, bailout. > > Perhaps: // The code is unable to handle this so bailout. Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v15]
On Sun, 31 Jan 2021 20:08:01 GMT, Vladimir Kempik wrote: >> I'm not sure it can wait. This change turns already-messy code into >> something significantly messier, to the extent that it's not really good >> enough to go into mainline. > > Hello > Does this look like something in the right direction ? > > https://github.com/VladimirKempik/jdk/commit/c2820734f4b10148154085a70d380b8c5775fa49 The latest merge with JDK-8261071 should resolve the issue. Please take a look. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v15]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits: - Pull/2200 (#5) * bsd_aarch64 cleanup * remove the actual attribute too * Refactor bailing out on nativeWrapper generation * rename c_call_conv_priv function - Merge branch 'master' into jdk-macos - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos Additional work for JDK-8253817: Support macOS Aarch64 ABI in Interpreter - JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945 - Update signal handler part for debugger - Cleanup SA changes - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - support macos_aarch64 in hsdis - Merge branch 'master' into jdk-macos - Update copyright year for BsdAARCH64ThreadContext.java - ... and 65 more: https://git.openjdk.java.net/jdk/compare/849f4c0f...a9452a4c - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=14 Stats: 3032 lines in 83 files changed: 2919 ins; 47 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v14]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 73 commits: - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos Additional work for JDK-8253817: Support macOS Aarch64 ABI in Interpreter - JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945 - Update signal handler part for debugger - Cleanup SA changes - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - support macos_aarch64 in hsdis - Merge branch 'master' into jdk-macos - Update copyright year for BsdAARCH64ThreadContext.java - Fix inclusing of StubRoutines header - Redo buildsys fix - ... and 63 more: https://git.openjdk.java.net/jdk/compare/40ae9937...4094f351 - Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=13 Stats: 3066 lines in 84 files changed: 2954 ins; 47 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Fri, 12 Feb 2021 12:22:09 GMT, Vladimir Kempik wrote: >> Where did this come from - some snippet/example/tech note code? Maybe other >> people can help figure it out if we provide more info. > > This is the version of w^x on-demand switch implemented by microsoft guys. > This is enabled only for debug builds. > @lewurm could you comment here please Those values can be observed in the debugger, but aren't documented or defined in header files. This mode was useful for the initial bootstrap of the platform (it helped with missing W^X transitions), but shouldn't be required anymore today. I'm fine with removing it altogether. - PR: https://git.openjdk.java.net/jdk/pull/2200
