in other places too.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On Mon, 23 May 2022 16:12:34 GMT, Dmitry Chuyko wrote:
>> On AArch64 it is sometimes convenient to have LSE atomics right from the
>> start. Currently they are enabled after feature detection and RR reverse
>> debugger works incorrectly.
>>
>> New build configuration feature 'hardlse' is
On Thu, 19 May 2022 14:36:28 GMT, Andrew Haley wrote:
> > Some concerns:
> > ```
> > 1. It should work at least for Clang and GCC but still will require
> > checking all os-cpu/compiler variants.
Non-Linux systems don't use this stuff at all, so don't worry about it.
On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote:
> On AArch64 it is sometimes convenient to have LSE atomics right from the
> start. Currently they are enabled after feature detection and RR reverse
> debugger works incorrectly.
>
> New build configuration feature 'hardlse' is added. If
On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote:
> On AArch64 it is sometimes convenient to have LSE atomics right from the
> start. Currently they are enabled after feature detection and RR reverse
> debugger works incorrectly.
>
> New build configuration feature 'hardlse' is added. If
On Thu, 19 May 2022 10:05:41 GMT, Dmitry Chuyko wrote:
> Some concerns:
>
> 1. It should work at least for Clang and GCC but still will require
> checking all os-cpu/compiler variants.
Really, no. Don't think that way. Just do Linux for now, and throw it over the
wall for Windows people.
On Thu, 19 May 2022 08:43:55 GMT, Nick Gasson wrote:
> What's the advantage of defining the new hardlse VM feature over using the
> existing `__ARM_FEATURE_ATOMICS` preprocessor symbol? Both GCC and Clang will
> define that with an appropriate `-march` value, which you're passing to
>
On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote:
> On AArch64 it is sometimes convenient to have LSE atomics right from the
> start. Currently they are enabled after feature detection and RR reverse
> debugger works incorrectly.
>
> New build configuration feature 'hardlse' is added. If
On Thu, 19 May 2022 07:59:56 GMT, Andrew Haley wrote:
> This looks reasonable enough, but I take it that this would create an OpenJDK
> build that would not run on AArch64 systems without LSE instructions.
Forget that, we already do so with extra-cflags.
-
PR:
On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote:
> On AArch64 it is sometimes convenient to have LSE atomics right from the
> start. Currently they are enabled after feature detection and RR reverse
> debugger works incorrectly.
>
> New build configuration feature 'hardlse' is added. If
On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote:
> On AArch64 it is sometimes convenient to have LSE atomics right from the
> start. Currently they are enabled after feature detection and RR reverse
> debugger works incorrectly.
>
> New build configuration feature 'hardlse' is added. If
On Mon, 11 Apr 2022 17:27:35 GMT, Andrew Leonard wrote:
> I excluded all kinds of debuginfo files because I didn't know if they could
> be made free of absolute paths, and it was out of scope for what I was doing
> at the time.
GCC, I believe, uses whatever pathname you give to the compiler
On Thu, 10 Mar 2022 05:35:39 GMT, Man Cao wrote:
> Any updates on whether this is acceptable?
What is the point of this change? It'd require legal inspection, and as far as
I can tell there is no point.
-
PR: https://git.openjdk.java.net/jdk/pull/7649
On 2/25/22 13:12, David Holmes wrote:
the Zero build
Zero on AArch64? I wonder if we need a better way of handling this than
AARCH64_ONLY(NOT_ZERO(
Maybe AARCH64_PORT_ONLY would be a Good Thing.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.
On Tue, 22 Feb 2022 16:10:22 GMT, Magnus Ihse Bursie wrote:
> This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting
> this, together with a valid backend using `--with-hsdis`, will bundle the
> generated hsdis library with the JDK.
Maybe I missed it, but are there
On Fri, 11 Feb 2022 11:37:56 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Fri, 11 Feb 2022 11:37:56 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Tue, 8 Feb 2022 09:40:49 GMT, Andrew Haley wrote:
>> Doing this caused 7 failures across a full jtreg run, namely:
>>
>> serviceability/sa/ClhsdbFindPC.java#xcomp-core
>> vmTestbase/jit/misctests/fpustack/GraphApplet.java
>> vmTestbase/nsk/jdi/MonitorWai
On Tue, 8 Feb 2022 09:22:39 GMT, Alan Hayward wrote:
> Doing this caused 7 failures across a full jtreg run, namely:
I'm glad we caught that.
-
PR: https://git.openjdk.java.net/jdk/pull/6334
On Mon, 7 Feb 2022 13:43:55 GMT, Alan Hayward wrote:
>> Tell you what, first put a comment here that says when it should (and
>> therefore, should not) be used. Once it's clear exactly what this is for,
>> thinking of a name maight be easier.
>
> How about extending the existing enter()
On Mon, 7 Feb 2022 12:01:18 GMT, Alan Hayward wrote:
> PreserveFramePointer is doing some additional stuff. I'll give it a test to
> make sure everything still works with PreserveFramePointer fully set. It
> would make things easier just to force it set with rop protection on.
Using
On Mon, 7 Feb 2022 11:42:43 GMT, Alan Hayward wrote:
>> Because enter always enters a subframe. That's what it's for.
>
> enter_nested() ?
> enter_inner() ?
Tell you what, first put a comment here that says when it should (and
therefore, should not) be used. Once it's clear exactly what this
On Mon, 7 Feb 2022 11:41:57 GMT, Alan Hayward wrote:
>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5328:
>>
>>> 5326: // Uses the FP from the start of the function as the modifier - which
>>> is stored at the address of
>>> 5327: // the current FP.
>>> 5328: //
>>
>> Is it? C2
On Mon, 7 Feb 2022 11:28:30 GMT, Alan Hayward wrote:
>>> Let's see both pc and signed pc here, if they are different.
>
> Are you sure? At the moment with PAC we get:
>
> patch_pc at address 0xf58edf98 [0x0068ed17b5fc ->
> 0x00abed17b7f8]
>
> With both signed and unsigned
On Thu, 3 Feb 2022 16:51:48 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Mon, 7 Feb 2022 10:58:59 GMT, Andrew Haley wrote:
>> Alan Hayward has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Documentation updates
>
> src/hotspot/cpu/aarch64/frame_aarch64.cpp line 275:
&g
On Thu, 3 Feb 2022 16:51:48 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Mon, 7 Feb 2022 10:55:52 GMT, Andrew Haley wrote:
>> Alan Hayward has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Documentation updates
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp li
On Thu, 3 Feb 2022 16:51:48 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Thu, 3 Feb 2022 16:51:48 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Thu, 3 Feb 2022 12:11:16 GMT, Alan Hayward wrote:
> As mentioned on the CSR, the JEP is being dropped - unless anyone has any
> objections. JDK-8277204 will become a normal RFE.
Good decision.
-
PR: https://git.openjdk.java.net/jdk/pull/6334
On Wed, 2 Feb 2022 09:34:20 GMT, Alan Hayward wrote:
> And this change will keep ROP protection enabled if we fall into the "this VM
> was built without ROP-protection support.". In that case we'll be protecting
> generated code, but the VM itself won't be protected. This will run without
>
On Tue, 1 Feb 2022 12:42:26 GMT, David Holmes wrote:
>> As per this conversation:
>> https://github.com/openjdk/jdk/pull/6334#discussion_r791722292
>>
>> The idea was, the user is explicitly asking for asking for pac-ret so we
>> should honour that. Whereas standard would only enable what is
On Mon, 31 Jan 2022 22:25:38 GMT, David Holmes wrote:
>> Alan Hayward has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix popframe failures
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 417:
>
>> 415: // Enable PAC if
On Mon, 24 Jan 2022 15:56:06 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Tue, 25 Jan 2022 14:22:15 GMT, Alan Hayward wrote:
>> Was this ever resolved?
>
> Sort of. That code has changed quite a bit - UseROPProtection now is a string
> field not a bool.
> "none" or not set - pac disabled.
> "pac-ret" - pac always enabled
> "standard" - pac enabled if the cpu+os
On Mon, 24 Jan 2022 15:56:06 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Sat, 11 Dec 2021 09:30:32 GMT, Andrew Haley wrote:
>> Ok, I think that's fine. How about on a non pac system allowing it for
>> development only ?
>
> Maybe. Mind you, a lot of the time I'm looking at the output from production
> systems.
> From a rather philos
On Thu, 11 Nov 2021 18:15:08 GMT, Florian Weimer wrote:
> > > > Am I right is saying that for Macos, all generated code is remapped RO
> > > > before execution?
> > >
> > >
> > > Ah, no, it seems the code cache is not RWX all the time as far as Java
> > > threads are concerned. The
On Fri, 14 Jan 2022 09:18:43 GMT, Johannes Bechberger
wrote:
>> make/autoconf/toolchain.m4 line 237:
>>
>>> 235: if test -n "$XCODEBUILD"; then
>>> 236: # On Mac OS X, default toolchain to clang after Xcode 5
>>> 237: XCODE_VERSION_OUTPUT=`"$XCODEBUILD" -version 2>&1 | $HEAD -n
On Wed, 12 Jan 2022 09:42:07 GMT, Johannes Bechberger
wrote:
> Simple change to `make/autoconf/toolchain.m4` to fix the bug as described in
> its title and description.
make/autoconf/toolchain.m4 line 237:
> 235: if test -n "$XCODEBUILD"; then
> 236: # On Mac OS X, default
and then copy that filesystem into your
sysroot.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On Tue, 4 Jan 2022 12:15:10 GMT, Aleksey Shipilev wrote:
> Brings lots of goodies, including automatic enablement of Compiler
> Blackholes:
> https://mail.openjdk.java.net/pipermail/jmh-dev/2021-December/003406.html
>
> Additional testing:
> - [x] Devkit creation works
> - [x] Sample
On Tue, 14 Dec 2021 09:40:03 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Mon, 13 Dec 2021 09:50:26 GMT, Alan Hayward wrote:
> You can support one without the other. The architecture allows you to have
> one without the other. The GCC flag is an enum of
> "none|standard|pac-ret[+leaf]|bti", with some of them changing depending on
> which cpu you specify to -mcpu
On Sat, 11 Dec 2021 15:39:24 GMT, Florian Weimer wrote:
>> src/hotspot/cpu/aarch64/globals_aarch64.hpp line 122:
>>
>>> 120: "It cannot be used with OnSpinWaitInst=none.")
>>> \
>>> 121: range(1, 99)
>>> \
>>>
On Fri, 10 Dec 2021 15:14:47 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Fri, 10 Dec 2021 15:16:19 GMT, Alan Hayward wrote:
>> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 419:
>>
>>> 417: if (UseROPProtection) {
>>> 418: warning("UseROPProtection specified, but not supported on this
>>> CPU.");
>>> 419: FLAG_SET_DEFAULT(UseROPProtection,
On Fri, 10 Dec 2021 12:39:50 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Thu, 2 Dec 2021 09:20:53 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Mon, 15 Nov 2021 11:21:37 GMT, Alan Hayward wrote:
>> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 452:
>>
>>> 450: // patch the return address, this stub will directly return to the
>>> exception handler
>>> 451: __ str(r0, Address(rfp, 1*BytesPerWord));
>>> 452:
>>
>> Please
On Mon, 15 Nov 2021 10:58:06 GMT, Alan Hayward wrote:
>> src/hotspot/cpu/aarch64/pauth_aarch64.hpp line 132:
>>
>>> 130: // Authenticate or strip a return value. Use for efficiency and only
>>> when the safety of the data
>>> 131: // isn't an issue - for example when viewing the stack.
>>>
On Mon, 15 Nov 2021 09:07:11 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Mon, 15 Nov 2021 09:07:11 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Mon, 15 Nov 2021 09:07:11 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Fri, 12 Nov 2021 16:18:04 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Thu, 11 Nov 2021 16:31:41 GMT, Andrew Dinn wrote:
> > Am I right is saying that for Macos, all generated code is remapped RO
> > before execution?
>
> Ah, no, it seems the code cache is not RWX all the time as far as Java
> threads are concerned. The Macos/AArch64 code is strategically
On Thu, 11 Nov 2021 14:59:32 GMT, Andrew Dinn wrote:
>> I did mean the description, not the flag name.
>
> Yes, understood. I too was talking about the description even though I
> introduced my comment by talking about what the flag does.
`"Protect branches against ROP attacks".`
On Thu, 11 Nov 2021 11:52:46 GMT, Andrew Haley wrote:
>> I'm thinking for references to the Arm Arm to use header titles instead of
>> section numbers, as the titles should be more stable.
>>
>> Also probably need some description around the code in the pauth_aarch64
On Thu, 11 Nov 2021 11:44:09 GMT, Alan Hayward wrote:
>> Correction:
>> Using the most up to date ARM ARM G [ARM DDI 0487G.a (ID011921)]
>>
>> - The PAC functionality is described in ARM-ARM Section D5.1.5
>> - Overview of the PAC instructions is provided in section C3.1.10
>> - Detailed PAC
On Wed, 10 Nov 2021 12:32:53 GMT, Alan Hayward wrote:
> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
> of its uses is to protect against ROP based attacks. This is done by
> signing the Link Register whenever it is stored on the stack, and
> authenticating the value
On Wed, 10 Nov 2021 12:32:53 GMT, Alan Hayward wrote:
> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
> of its uses is to protect against ROP based attacks. This is done by
> signing the Link Register whenever it is stored on the stack, and
> authenticating the value
On Wed, 10 Nov 2021 12:32:53 GMT, Alan Hayward wrote:
> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
> of its uses is to protect against ROP based attacks. This is done by
> signing the Link Register whenever it is stored on the stack, and
> authenticating the value
On Wed, 3 Nov 2021 11:54:39 GMT, Aleksey Shipilev wrote:
> [JDK-8182285](https://bugs.openjdk.java.net/browse/JDK-8182285) added the
> incremental build capabilities for modules, by hashing the APIs of each
> module.
>
> The original change uses MD5, which is quite weak, and
>
On Wed, 27 Oct 2021 12:28:16 GMT, Aleksey Shipilev wrote:
> Time to update the devkit to the latest JMH.
>
> Additional testing:
> - [x] Devkit generation works
> - [x] Sample benchmarks run
Marked as reviewed by aph (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6139
On Mon, 18 Oct 2021 09:10:32 GMT, Andrew Haley wrote:
> >Can you describe a reproducer?
> Sure. Create a .hotspot_compiler file containing print
> java.lang.String::checkIndex then
Sorry, thinko. You don't need the .hotspot_compiler file
-
PR: https://git.openjdk.
On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote:
> This patch expands the newly added system for hsdis backends to include LLVM.
>
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry,
> as published in the never integrated PR
>
On Fri, 15 Oct 2021 08:20:05 GMT, Ludovic Henry wrote:
> Since the maintenance is fairly low (small codebase, small and knowledgable
> user base), I would be biased towards including it with appropriate warnings.
I don't think we should commit code that we know is broken. I don't believe
that
On Wed, 13 Oct 2021 07:26:21 GMT, Ludovic Henry wrote:
>> This patch expands the newly added system for hsdis backends to include LLVM.
>>
>> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry,
>> as published in the never integrated PR
>>
On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote:
> This patch expands the newly added system for hsdis backends to include LLVM.
>
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry,
> as published in the never integrated PR
>
On Wed, 13 Oct 2021 13:55:04 GMT, Andrew Haley wrote:
>> This patch expands the newly added system for hsdis backends to include LLVM.
>>
>> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry,
>> as published in the never integrated PR
>>
On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote:
> This patch expands the newly added system for hsdis backends to include LLVM.
>
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry,
> as published in the never integrated PR
>
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Ahead-of-Time Compiler from JDK:
>>
>> - `jdk.aot` module — the `jaotc` tool
>> - `src/hotspot/share/aot` — loads AoT compiled code into VM for
On Tue, 23 Mar 2021 16:20:47 GMT, Ludovic Henry 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 115 commits:
>>
>> - Merge branch 'master' into jdk-macos
>> - JDK-8262491: bsd_aarch64 part
>> -
On Tue, 23 Mar 2021 13:54:24 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 115 commits:
>>
>> - Merge branch 'master' into jdk-macos
>> - JDK-82624
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov wrote:
>> 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
On Fri, 12 Mar 2021 16:32:10 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 105 commits:
>>
>> - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlo
On Tue, 23 Mar 2021 09:53:54 GMT, Andrew Haley wrote:
>>> @theRealAph, could you elaborate on what is need to be done for [#2200
>>> (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).
>>
>> I think that what you've got now is fine.
&
On 3/19/21 10:14 AM, Thomas Stüfe wrote:
> On Fri, Mar 19, 2021 at 11:04 AM Andrew Haley wrote:
>
>> On 3/19/21 9:22 AM, Thomas Stüfe wrote:
>>>> 2. More choices to actually build the project: Use integrated build
>>>> tools of IDEs (Visual Studio, Xcode
st an
> assumption? I would have thought it's things like single threaded jmod,
> jlink, and subprocess spawning.
I'm sure it is. The other slow thing is linking HotSpot.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.
On 3/15/21 6:56 PM, Anton Kozlov wrote:
> On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley wrote:
>
>>> We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to
>>> define the value for the macro?
>>
>> Robustness, clarity, maintainability,
On Tue, 9 Mar 2021 18:01:11 GMT, Anton Kozlov wrote:
>> src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62:
>>
>>> 60:
>>> 61: #if defined(__APPLE__) || defined(_WIN64)
>>> 62: #define R18_RESERVED
>>
>> #define R18_RESERVED true```
>
> We always check for `R18_RESERVED` with
On Tue, 9 Mar 2021 16:12:36 GMT, Anton Kozlov wrote:
>> 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
On Wed, 3 Mar 2021 17:39:28 GMT, Gerard Ziemski wrote:
> A list of the bugs that our internal testing revealed so far:
Are any of these blockers for integration? Some of them are to do with things
like features that aren't yet supported, and we can't fix what we can't see.
-
PR:
On Fri, 12 Feb 2021 11:42:59 GMT, Vladimir Kempik wrote:
>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 194:
>>
>>> 192: // may get turned off by -fomit-frame-pointer.
>>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>>> 194: return frame(fr->link(), fr->link(),
On Fri, 5 Feb 2021 17:20:55 GMT, Anton Kozlov wrote:
>> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93:
>>
>>> 91: CPU_MARVELL = 'V',
>>> 92: CPU_INTEL = 'i',
>>> 93: CPU_APPLE = 'a',
>>
>> The `ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture
>>
On Fri, 26 Feb 2021 19:17:12 GMT, Anton Kozlov wrote:
>> 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
On Thu, 4 Feb 2021 23:01:52 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> - Add comments to WX transitions
>>
>>
On Fri, 26 Feb 2021 19:17:12 GMT, Anton Kozlov wrote:
>> 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
On Sun, 28 Feb 2021 14:08:37 GMT, Andrew Haley wrote:
>> Before this fix, the alignment is defaulting to that of the build host. We
>> would like to provide a way to produce a JDK distribution, with a pre
>> generated CDS archive, where the alignment has the highest know
On Fri, 26 Feb 2021 18:28:04 GMT, Erik Joelsson wrote:
> Before this fix, the alignment is defaulting to that of the build host. We
> would like to provide a way to produce a JDK distribution, with a pre
> generated CDS archive, where the alignment has the highest known value of any
> target
On Mon, 15 Feb 2021 17:45:32 GMT, Anton Kozlov 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.
>
> The latest merge with JDK-8261071 should resolve the
On Tue, 16 Feb 2021 06:24:05 GMT, Vladimir Kempik wrote:
>> 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
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
On Thu, 4 Feb 2021 23:05:56 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> - Add comments to WX transitions
>>
>>
On Thu, 4 Feb 2021 09:49:17 GMT, Vladimir Kempik wrote:
> > You read my mind, Andrew. Unless, of course, it's optimized to leverage the
> > fact that it's thread-specific..
>
> it's thread-specific
>
>
On Tue, 2 Feb 2021 21:49:36 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/macroAssembler_aarch64.cpp line 323:
>
>> 321:
On Tue, 2 Feb 2021 18:03:50 GMT, Gerard Ziemski 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/macroAssembler_aarch64.cpp line 5271:
>
>> 5269: //
>>
On Sun, 31 Jan 2021 20:14:01 GMT, Anton Kozlov wrote:
>> 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
On 2/1/21 5:14 PM, Aleksey Shipilev wrote:
> On 2/1/21 4:38 PM, Andrew Haley wrote:
>> but that doesn't work either. Any ideas? I'm really stuck.
>
> Did you "make clean" after changing any of the configure files and/or
> configure arguments? I.e. did
> AWT
1 - 100 of 348 matches
Mail list logo
