Re: [11u] RFR(M): 8233787 backport: Break cycle in vm_version* includes

[Vladimir Kempik]

Hello
this backport is pretty much needed in jdk11u-dev as it’s one of prerequests 
(soft one tho) for jep-391 to apply more cleanly.
I was doing this backport multiple times (including to zulu11) and know what a 
PITA it is.
Looking forward for integration of this into 11u.
Regards, Vladimir.

> 13 апр. 2021 г., в 10:51, Schmidt, Lutz  написал(а):
> 
> Dear Community,
> 
> I would appreciate receiving reviews for this downport change. It consists of 
> many modified files. In most cases, it’s only #include statement changes, 
> caused by factoring out abstract_vm_version.{c|h}pp from vm_version.{c|h}pp. 
> The change did not apply cleanly, for the most part because of this split. 
> The other merge conflicts were trivial (include rearrangement and copyright 
> headers).
> 
> Original bug:  https://bugs.openjdk.java.net/browse/JDK-8233787
> Downport webrev:   
> https://cr.openjdk.java.net/~lucy/webrevs/8233787.11u.01/
> Merge conflicts:   
> https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflicts
> Conflict resolve diff: 
> https://cr.openjdk.java.net/~lucy/webrevs/8233787-jdk11u.conflictresolve
> 
> Tests:
> SAP's internal build and test farm (all OpenJDK platforms (no 32-bit), and 
> more). Tests include JCK, jtreg (hotspot and jdk), and SAP-private tests. No 
> issues found.
> 
> Your effort is very much appreciated!
> 
> Thanks,
> Lutz
> 
> P.S.: build-dev on CC: because a small build change is included.
> 

Integrated: 8264240: [macos_aarch64] enable appcds support after JDK-8263002

[Vladimir Kempik]

On Fri, 26 Mar 2021 17:18:22 GMT, Vladimir Kempik  wrote:

> Please review this small patch for macos_aarch64.
> It reverts small part of jep-391 where we disabled cds for macos_aarch64.
> After JDK-8263002 is fixed, the appcds can be enabled back on macos_aarch64.
> CDS related tests in tier1 now pass

This pull request has now been integrated.

Changeset: d6bb1537
Author:    Vladimir Kempik 
URL:   https://git.openjdk.java.net/jdk/commit/d6bb1537
Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8264240: [macos_aarch64] enable appcds support after JDK-8263002

Reviewed-by: erikj

-

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

RFR: 8264240: [macos_aarch64] enable appcds support after JDK-8263002

[Vladimir Kempik]

Please review this patch for macos_aarch64.
It reverts small part of jep-391 were we disabled cds for macos_aarch64.
After JDK-8263002 is fixed, the appcds can be enabled back on macos_aarch64.
CDS related tests in tier1 now pass

-

Commit messages:
 - 8264240: [macos_aarch64] enable appcds support after JDK-8263002

Changes: https://git.openjdk.java.net/jdk/pull/3221/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3221=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264240
  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3221.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3221/head:pull/3221

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

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

[Vladimir Kempik]

On Tue, 23 Mar 2021 13:58:03 GMT, Andrew Haley  wrote:

> > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 
> > maintainers to accept this (and few other, like jep-388, as we depend on 
> > it) contribution.
> 
> To the extent that 11u has fixed policies :) we definitely have a policy of 
> accepting patches to keep 11u working on current hardware. So yes.

@lewurm That sounds like a green flag for you and jep-388 (with its 
R18_RESERVED functionality) ;)

-

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

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

[Vladimir Kempik]

On Tue, 23 Mar 2021 13:26:19 GMT, Anton Kozlov  wrote:

>> Build changes still look good. Hope you can get this done now! :)
>
>> > No, no, no! I am not suggesting you change anything else, just that
>> > you do not define contentless macros. You might as well define it
>> > to be something, and true is a reasonable default, that's all. It's
>> > not terribly important, it's just good practice.
>> 
>> I'm quite prepared to drop this if it's holding up the port. It's a style 
>> thing, but it's not critical.
> 
> Sorry, I missed your reply.
> 
> R18_RESERVED is also defined in 
> https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96.
>  I think changing the value here and there would be slightly out of the scope 
> of this PR, so I would prefer to avoid the suggested change. 
> 
> The biggest argument from my side is that the current macro value is 
> consistent with the rest of the macros in this file. For example 
> https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35
> and 
> https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137
> 
> But 
> https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59
> and   
> https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540

Hello
That depends on the will of openjdk11 maintainers to accept this (and few 
other, like jep-388, as we depend on it) contribution.

> 23 марта 2021 г., в 16:39, drej1 ***@***.***> написал(а):
> 
> 
> So, where are we up to now? Are we done yet?
> 
> Hello
> we would like to get approval for the final version we have now and then 
> integrate this pr as soon as Mark will target it to jdk17
> 
> Hi there, will this be also supported backwards? To support java11 LTS 
> version?
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
>

-

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

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

[Vladimir Kempik]

On Tue, 23 Mar 2021 09:54:16 GMT, Andrew Haley  wrote:

> So, where are we up to now? Are we done yet?

Hello
we would like to get approval for the final version we have now and then 
integrate this pr as soon as Mark will target it to jdk17

-

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

Re: CMake replacing Autotools?

[Vladimir Kempik]

Hello
On macmini m1 jdk in default config can be built in about 4 minutes. (make 
images)
I might guess autotools aren't the slowest thing.
Regards, Vladimir

Andrew Haley  19 марта 2021 г. 13:04:38 написал:

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) or use Ninja, which is faster than
gmake

Is gmake really where we lose time? Did you analyze this or is this just 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://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Vladimir Kempik]

On Tue, 2 Mar 2021 08:12:10 GMT, Anton Kozlov  wrote:

>> I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these 
>> workaround
>> @gerard-ziemski, 8020753 was originally your fix, do you know if it still 
>> needed on intel-mac ?
>
> The x86_bsd still carries the workaround 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L745.
>  It's worth having macos ports to be aligned by features. I would propose to 
> have this workaround for now, and decide on it later for macos/x86 and 
> macos/aarch64 at once. Sorry for chiming in so late.

Hello Anton.
Please keep JDK-8020753 away from this port, as JDK-8020753 was very 
intel-specific workaround and macos11.0 on aarch64 doesn't show any signs of 
original bug.

-

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

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

[Vladimir Kempik]

On Thu, 4 Mar 2021 17:36:22 GMT, Alan Hayward 
 wrote:

> I was building this PR on a new machine, and I now get the following error:
> 
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31:
> >  error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') 
> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIClientRef client = (MIDIClientRef) NULL;
> > ^~~~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29:
> >  error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') 
> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIPortRef inPort = (MIDIPortRef) NULL;
> > ^~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30:
> >  error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') 
> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIPortRef outPort = (MIDIPortRef) NULL;
> > ^~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32:
> >  error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned int') 
> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL;
> > ^~
> > 4 errors generated.
> 
> As far as I can tell the only difference between the two systems is the xcode 
> version:
> 
> New system (failing)
> % xcodebuild -version
> Xcode 12.5
> Build version 12E5244e
> 
> Old system (working)
> % xcodebuild -version
> Xcode 12.4
> Build version 12D4e
> 
> Looks like the newer version of Xcode is being a little stricter with casting?
> Replacing the NULL with 0 seems to fix the issue.

Hello
there is one issue with the info you provided, it's from Xcode12.5 beta.
And beta license agreement forbids sharing output of beta version of compiler
So we can't say we have issue with newer xcode beta until that beta went public 
& released.
Fixing issues you found now will mean someone have violated xcode beta license 
agreement and made these issues public.

-

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

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

[Vladimir Kempik]

On Tue, 2 Feb 2021 23:07:08 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/java.base/macosx/native/libjli/java_md_macosx.m line 210:
> 
>> 208: if (preferredJVM == NULL) {
>> 209: #if defined(__i386__)
>> 210: preferredJVM = "client";
> 
> #if defined(__i386__)
> preferredJVM = "client";
> Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS.

Hello
I thought the openjdk7 supported 32-bit macos at some point in time

-

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

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

[Vladimir Kempik]

On Thu, 4 Feb 2021 22:49:23 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
>>
>>+ minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 297:
> 
>> 295:   stub = SharedRuntime::handle_unsafe_access(thread, next_pc);
>> 296: }
>> 297:   } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) {
> 
> Can we add a comment here describing what this case means?

This was added as part of this commit ( to linux_aarch64) - 
https://github.com/openjdk/jdk/commit/339d52600b285eb3bc57d9ff107567d4424efeb1

@gerard-ziemski  do we really want to add anything new here ?

-

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

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

[Vladimir Kempik]

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

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

[Vladimir Kempik]

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]

[Vladimir Kempik]

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 [v10]

[Vladimir Kempik]

On Thu, 4 Feb 2021 22:49:23 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
>>
>>+ minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 297:
> 
>> 295:   stub = SharedRuntime::handle_unsafe_access(thread, next_pc);
>> 296: }
>> 297:   } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) {
> 
> Can we add a comment here describing what this case means?

this arm64 specific part came as is from linux_aarch64 and I can't add any 
meaning comments here.

> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 302:
> 
>> 300: const uint64_t *detail_msg_ptr
>> 301:   = (uint64_t*)(pc + NativeInstruction::instruction_size);
>> 302: const char *detail_msg = (const char *)*detail_msg_ptr;
> 
> Where is `detail_msg` used?

Came from linux_arm64. was used in os_linux_aarch64.cpp on line 246 in 
report_and_die
But became unused on bsd_arm64. I agree this needs to be removed

> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 403:
> 
>> 401:   }
>> 402: 
>> 403:   return false; // Mute compiler
> 
> Is this comment needed?

this part came as is from linux_aarch64 as well and was supposed to mean 
something there.

-

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

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

[Vladimir Kempik]

On Tue, 2 Feb 2021 22:08:14 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/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 221:
> 
>> 219: assert(sig == info->si_signo, "bad siginfo");
>> 220:   }
>> 221: */
> 
> Should this code be deleted? From here and from where it was copied
> from if it is also commented out there...

Thanks, will fix in bsd_aarch64 soon, as for bsd_x86 I've filled new bug and pr 
- https://github.com/openjdk/jdk/pull/2547

-

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

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

[Vladimir Kempik]

On Tue, 2 Feb 2021 22:14:42 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/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 486:
> 
>> 484: }
>> 485:   }
>> 486: }
> 
> This appears to be a mix for Mavericks (10.9) and 10.12
> work arounds. Is this code needed by this project?

I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these 
workaround
Gerard, 8020753 was originally your fix, do you know if it still needed on 
intel-mac ?

-

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

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

[Vladimir Kempik]

On Thu, 4 Feb 2021 22:54:42 GMT, Gerard Ziemski  wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 363:
>> 
>>> 361: address pc = os::Posix::ucontext_get_pc(uc);
>>> 362: 
>>> 363: if (pc != addr && uc->context_esr == 0x924F) { //TODO: figure 
>>> out what this value means
>> 
>> Is this TODO going to be resolved by this port?
>
> 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

-

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

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

[Vladimir Kempik]

On Tue, 2 Feb 2021 22:12:07 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/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435:
> 
>> 433: //||\  Java thread created by VM does not 
>> have glibc
>> 434: //|glibc guard page| - guard, attached Java thread usually 
>> has
>> 435: //||/  1 glibc guard page.
> 
> Is this code going to be built by GCC (with glibc) or will only
> macOS compilers and libraries be used?

only macos comiplers

-

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

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

[Vladimir Kempik]

On Tue, 2 Feb 2021 22:07:15 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/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 195:
> 
>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>> 194:   return frame(fr->link(), fr->link(), fr->sender_pc());
>> 195: }
> 
> Is this file going to be built by GCC or just macOS compilers?

there is no support for compiling java with gcc on macos since about jdk11, 
only clang.
considering this and the absence of gcc for macos_m1, the answer is - just 
macOS compilers.

-

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

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

[Vladimir Kempik]

On Thu, 4 Feb 2021 21:59:02 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
>>
>>+ minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> 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(), fr->sender_pc());
> 
> Why is it
> 
> return frame(fr->link(), fr->link(), fr->sender_pc());
> 
> and not 
> 
> return frame(fr->sender_sp(), fr->link(), fr->sender_pc());
> 
> like in the bsd-x86 counter part?

bsd_aarcb64 was based on linux_aarch64, with addition of bsd-specific things 
from bsd_x86
You think  the bsd-x86 is better here ?

-

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

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

[Vladimir Kempik]

On Thu, 4 Feb 2021 15:13:49 GMT, Anton Kozlov  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:
> 
> testJNIthrpt   25   277997000.151 ±   4095685.956  ops/s
> testJniNanoTimethrpt   2517851098.010 ±119489.599  ops/s
> testNanoTime   thrpt   2578007491.762 ±628455.971  ops/s
> testNothingthrpt   25  1724298829.088 ± 100537565.068  ops/s
> testTwoStateAndWX  thrpt   2521958839.057 ±210490.755  ops/s
> testWX thrpt   2523299813.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-...@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
> > >  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

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

[Vladimir Kempik]

On Thu, 4 Feb 2021 14:27:53 GMT, Andrew Haley  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
> > https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
> > > Because pthread_jit_write_protect_np changes only the current thread’s 
> > > permissions, avoid accessing the same memory region from multiple 
> > > threads. Giving multiple threads access to the same memory region opens 
> > > up a potential attack vector, in which one thread has write access and 
> > > another has executable access to the same region.
> 
> Umm, so how does patching work? We don't even know if other threads are 
> executing the code we need to patch.

I thought java can handle that scenario in usual (non W^X systems) just fine, 
so we just believe jvm did everything right and it's safe to rewrite some code 
at specific moment.

-

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

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

[Vladimir Kempik]

On Thu, 4 Feb 2021 08:26:35 GMT, Mikael Vidstedt  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

https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon

>Because pthread_jit_write_protect_np changes only the current thread’s 
>permissions, avoid accessing the same memory region from multiple threads. 
>Giving multiple threads access to the same memory region opens up a potential 
>attack vector, in which one thread has write access and another has executable 
>access to the same region.

-

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

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

[Vladimir Kempik]

On Tue, 2 Feb 2021 11:14:12 GMT, Vladimir Kempik  wrote:

> > > > Hello, hsdis is a separate out-of-tree project and is not part of this 
> > > > jep.
> > > 
> > > 
> > > Unless there's something I'm missing it only requires a few lines of 
> > > change to src/utils/hsdis/makefile (it already has support for macos 
> > > x86_64)
> > 
> > 
> > I agree with Alan that it makes sense to add this trivial change as part of 
> > this PR, if it allows the current hsdis solution to continue working on 
> > mac/aarch64.
> > > > support for looking for proper hsdis dylib library was added as part of 
> > > > this jep.
> > > 
> > > 
> > > I'm a little confused. Are you planning on adding a new disassembler?
> > 
> > 
> > @a74nh I think Vladimir is referring to #392. The hsdis "component" has 
> > been left behind for a long time, and there are several requests to add new 
> > backends, which require a modernized build of hsdis. This is undfortunately 
> > not a high-priority project, and has been postponed several times already. 
> > :(
> 
> Sorry I was under impression hsdis is not part of openjdk tree.
> 
> Alan, could you please share with us the version of binutils you were using 
> in your test ?
> 
> Regards, Vladimir

I have updated PR with patch for hsdis, one thing to notice, LP64 is not 
defined for arm64 in Makefile

-

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

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

[Vladimir Kempik]

On Mon, 1 Feb 2021 14:06:32 GMT, Magnus Ihse Bursie  wrote:

>>> Hello, hsdis is a separate out-of-tree project and is not part of this jep.
>> 
>> Unless there's something I'm missing it only requires a few lines of change 
>> to src/utils/hsdis/makefile (it already has support for macos x86_64)
>> 
>>>support for looking for proper hsdis dylib library was added as part of this 
>>>jep.
>> 
>> I'm a little confused. Are you planning on adding a new disassembler?
>
>> > Hello, hsdis is a separate out-of-tree project and is not part of this jep.
>> 
>> Unless there's something I'm missing it only requires a few lines of change 
>> to src/utils/hsdis/makefile (it already has support for macos x86_64)
> 
> I agree with Alan that it makes sense to add this trivial change as part of 
> this PR, if it allows the current hsdis solution to continue working on 
> mac/aarch64.
> 
>> 
>> > support for looking for proper hsdis dylib library was added as part of 
>> > this jep.
>> 
>> I'm a little confused. Are you planning on adding a new disassembler?
> 
> @a74nh I think Vladimir is referring to 
> https://github.com/openjdk/jdk/pull/392. The hsdis "component" has been left 
> behind for a long time, and there are several requests to add new backends, 
> which require a modernized build of hsdis. This is undfortunately not a 
> high-priority project, and has been postponed several times already. :(

> > > Hello, hsdis is a separate out-of-tree project and is not part of this 
> > > jep.
> > 
> > 
> > Unless there's something I'm missing it only requires a few lines of change 
> > to src/utils/hsdis/makefile (it already has support for macos x86_64)
> 
> I agree with Alan that it makes sense to add this trivial change as part of 
> this PR, if it allows the current hsdis solution to continue working on 
> mac/aarch64.
> 
> > > support for looking for proper hsdis dylib library was added as part of 
> > > this jep.
> > 
> > 
> > I'm a little confused. Are you planning on adding a new disassembler?
> 
> @a74nh I think Vladimir is referring to #392. The hsdis "component" has been 
> left behind for a long time, and there are several requests to add new 
> backends, which require a modernized build of hsdis. This is undfortunately 
> not a high-priority project, and has been postponed several times already. :(

Sorry I was under impression hsdis is not part of openjdk tree.

Alan, could you please share with us the version of binutils you were using in 
your test ?

Regards, Vladimir

-

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

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

[Vladimir Kempik]

On Mon, 1 Feb 2021 09:31:31 GMT, Alan Hayward 
 wrote:

> You need add macos arm64 to hsdis. Having it working is fairly essential for 
> debugging.
> 
> Inside src/utils/hsdis, After cloning binutils
> 
> ```
> make; make demo; ./build/macosx-arm64/hsdis-demo
> ```
> 
> Results in:
> 
> ```
> Hello, world!
> ...And now for something completely different:
> 
> Decoding from 0x1046e31a4 to 0x1046e3664...with decode_instructions_virtual
> hsdis: bad native mach=architecture not set in Makefile!; please port hsdis 
> to this platform
> hsdis output options:
> ```
> 
> I fixed it by changing the makefile to force the build flags:
> 
> ```
> ARCH=aarch64
> CFLAGS/aarch64+= -m64
> ```
> 
> Resulting in:
> 
> ```
> Hello, world!
> ...And now for something completely different:
> 
> Decoding from 0x10012719c to 0x10012765c...with decode_instructions_virtual
> Decoding for CPU 'aarch64'
> main:
>  0x10012719c  sub sp, sp, #0x60
>  0x1001271a0  stp x29, x30, [sp, #80]
> ...etc
> ```
> 
> Putting the library in the right place then made disassembly in java work for 
> me.

Hello, hsdis is a separate out-of-tree project and is not part of this jep.
support for looking for proper hsdis dylib library was added as part of this 
jep.

-

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

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

[Vladimir Kempik]

On Mon, 25 Jan 2021 09:48:46 GMT, Andrew Haley  wrote:

>> Would you like me to do something about it now? The problem is that the 
>> functions of SlowSignatureHandler are subtly different, so it will be 
>> multiple tables, not sure how many. Such change is another candidate for a 
>> separate code enhancement, which I would like not to mix into the JEP 
>> implementation (it's already not a small change :)). But if you think it 
>> would be a good thing, please let me know. In another case, I'll add this to 
>> a queue of follow-up enhancements.
>
> 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

-

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

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

[Vladimir Kempik]

On Wed, 27 Jan 2021 08:36:19 GMT, Magnus Ihse Bursie  wrote:

> Build changes per se now looks okay. However, I agree with Erik that unless 
> this PR can wait for the JNF removal, at the very least the build docs needs 
> to be updated to explain how to successfully build for this platform. (I can 
> live with the configure command line hack, since it's temporary -- otherwise 
> I'd have requested a new configure argument.) This can be done in this PR or 
> a follow-up PR.

I believe it's better be done under separate PR/bugfix, so it can be completely 
reverted once JNF removed.

-

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

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

[Vladimir Kempik]

On Tue, 26 Jan 2021 09:23:18 GMT, Magnus Ihse Bursie  wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional 
>> commits since the last revision:
>> 
>>  - Refactor CDS disabling
>>  - Redo builsys support for aarch64-darwin
>
> make/autoconf/build-aux/autoconf-config.guess line 1275:
> 
>> 1273:  UNAME_PROCESSOR="aarch64"
>> 1274:  fi
>> 1275:fi ;;
> 
> Almost, but not quite, correct. We cannot change the autoconf-config.guess 
> file due to license restrictions (the license allows redistribution, not 
> modifications). Instead we have the config.guess file which "wraps" 
> autoconf-config.guess and makes pre-/post-call modifications to work around 
> limitations in the autoconf original file. So you need to check there if you 
> are getting incorrect results back and adjust it in that case. See the 
> already existing clauses in that file.

Hello
I have updated PR and moved this logic to make/autoconf/build-aux/config.guess
It's pretty similar to i386 -> x86_64 fix-up on macos_intel

-

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

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

[Vladimir Kempik]

On Tue, 26 Jan 2021 19:33:28 GMT, Weijun Wang  wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Revert harfbuzz changes, disable warnings for it
>
> src/java.security.jgss/share/native/libj2gss/gssapi.h line 48:
> 
>> 46: // Condition was copied from
>> 47: // 
>> Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
>> 48: #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || 
>> defined(__i386__) || defined(__x86_64__))
> 
> So for macOS/AArch64, this `if` is no longer true?

That is according to Xcode sdk.

-

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

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

[Vladimir Kempik]

On Mon, 25 Jan 2021 17:43:22 GMT, Phil Race  wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional 
>> commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/java.desktop/share/native/libharfbuzz/hb-common.h line 113:
> 
>> 111: 
>> 112: #define HB_TAG(c1,c2,c3,c4) 
>> ((hb_tag_t)uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF)))
>> 113: #define HB_UNTAG(tag)   (char)(((tag)>>24)&0xFF), 
>> (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF)
> 
> I need a robust explanation of these changes.
> They are not mentioned, nor are they in upstream harfbuzz.
> Likely these should be pushed to upstream first if there is a reason for them.

@lewurm This and other harfbuzz changes came from MS, could you please comment 
here ?

-

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

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

[Vladimir Kempik]

On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward 
 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

-

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

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

[Vladimir Kempik]

On Mon, 25 Jan 2021 23:35:52 GMT, Phil Race  wrote:

>> That may actually be a valid concern. Both say macOS 10.12+ ...  which might 
>> conflict with the 10.9 target.
>
> Maybe you should just file a bug after all for this to be dealt with 
> separately.
> Certainly if it is NOT fixed now such a bug needs to be filed.

I have created https://bugs.openjdk.java.net/browse/JDK-8260402 which is 
blocked by jep-391 currently

-

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

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

[Vladimir Kempik]

On Mon, 25 Jan 2021 22:42:40 GMT, Phil Race  wrote:

>> Min_macos version is changed to 11.0 for macos_aarch64
>> 
>> https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136
>
> 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask
> 2) So maybe rather than the deprecation suppression  you could change both 
> constants to the new ones.
> Ordinarily I'd say let someone else do that but this looks like a simple 
> obvious change and is dwarfed by all the other changes going on for Mac ARM 
> ...

that sounds good to me, I am just afraid to break intel mac on older macos 
versions with this change.

-

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

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

[Vladimir Kempik]

On Mon, 25 Jan 2021 22:22:06 GMT, Phil Race  wrote:

>> It seems these workarounds are still needed:
>> 
>> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39:
>>  error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 
>> 10.14 [-Werror,-Wdeprecated-declarations]
>> bitmapFormat: NSAlphaFirstBitmapFormat | 
>> NSAlphaNonpremultipliedBitmapFormat
>>   ^~~~
>>   NSBitmapFormatAlphaFirst
>> 
>> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34:
>>  error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 
>> 10.12 [-Werror,-Wdeprecated-declarations]
>>   styleMask: NSBorderlessWindowMask
>>  ^~
>>  NSWindowStyleMaskBorderless
>
> Are you doing something somewhere to change the target version of macOS or 
> SDK ? I had no such problem.
> I think we currently target a macOS 10.9 and if you are changing that it 
> would need discussion.
> If you are changing it only for Mac ARM that may make more sense .. 
> 
> And these appear to be just API churn by Apple
> NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst
> 
> https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc
> 
> NSBorderlessWindowMask is replaced by NSWindowStyleMask
> 
> https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ

Min_macos version is changed to 11.0 for macos_aarch64

https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136

-

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

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

[Vladimir Kempik]

On Mon, 25 Jan 2021 20:54:38 GMT, Vladimir Kempik  wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573:
>> 
>>> 571: EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \
>>> 572: WARNINGS_AS_ERRORS_xlc := false, \
>>> 573: DISABLED_WARNINGS_clang := deprecated-declarations, \
>> 
>> I see this added here and in another location. What is deprecated ? You 
>> really need to explain these sorts of things.
>> I've built JDK using Xcode 12.3 and not had any need for this.
>
> Hello
> I believe it was a workaround for issues with xcode 12.2 in early beta days.
> Those issues were fixed later in upstream jdk, so most likely we need to 
> remove these workarounds.

It seems these workarounds are still needed:

jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: 
error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 
10.14 [-Werror,-Wdeprecated-declarations]
bitmapFormat: NSAlphaFirstBitmapFormat | 
NSAlphaNonpremultipliedBitmapFormat
  ^~~~
  NSBitmapFormatAlphaFirst

jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: 
error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 
[-Werror,-Wdeprecated-declarations]
  styleMask: NSBorderlessWindowMask
 ^~
 NSWindowStyleMaskBorderless

-

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

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

[Vladimir Kempik]

On Mon, 25 Jan 2021 19:42:41 GMT, Phil Race  wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional 
>> commits since the last revision:
>> 
>>  - Refactor CDS disabling
>>  - Redo builsys support for aarch64-darwin
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573:
> 
>> 571: EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \
>> 572: WARNINGS_AS_ERRORS_xlc := false, \
>> 573: DISABLED_WARNINGS_clang := deprecated-declarations, \
> 
> I see this added here and in another location. What is deprecated ? You 
> really need to explain these sorts of things.
> I've built JDK using Xcode 12.3 and not had any need for this.

Hello
I believe it was a workaround for issues with xcode 12.2 in early beta days.
Those issues were fixed later in upstream jdk, so most likely we need to remove 
these workarounds.

-

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

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

[Vladimir Kempik]

On Mon, 25 Jan 2021 14:03:40 GMT, Per Liden  wrote:

> In `make/autoconf/jvm-features.m4` I notice that you haven't enabled ZGC for 
> macos/aarch64. Is that just an oversight, or is there a reason for that?

because it does not work
processor_id has no "official docs"-friendly implementation, only a hacky one 
from ios world.

Also ZGC needs additional W^X work.
I believe zgc supports needs to be done in a separate commit.

-

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

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

[Vladimir Kempik]

On Mon, 25 Jan 2021 13:18:34 GMT, Magnus Ihse Bursie  wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional 
>> commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> make/common/NativeCompilation.gmk line 1180:
> 
>> 1178: # silently fail otherwise.
>> 1179: ifneq ($(CODESIGN), )
>> 1180:  $(CODESIGN) -f -s "$(MACOSX_CODESIGN_IDENTITY)" 
>> --timestamp --options runtime \
> 
> What does -f do, and is it needed for macos-x64 as well?

-f  - replace signature if it's present, if not  - just sign as usual
macos-aarch64 binaries always have adhoc signature, so need to replace it.

> make/modules/jdk.hotspot.agent/Lib.gmk line 34:
> 
>> 32: 
>> 33: else ifeq ($(call isTargetOs, macosx), true)
>> 34:   SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
> 
> Is this really proper for macos-x64? I thought we used -Damd64 as a marker 
> for all macos-x64 C/C++ files. (Most files get their flags from the common 
> setup in configure, but SA is a different beast due to historical reasons).

@luhenry , could you please check this comment, I think SA-agent was MS's job 
here.

-

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

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

[Vladimir Kempik]

On Sat, 23 Jan 2021 11:43:31 GMT, Andrew Haley  wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional 
>> commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272:
> 
>> 5270: void MacroAssembler::get_thread(Register dst) {
>> 5271:   RegSet saved_regs = RegSet::range(r0, r1) + 
>> BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;
>> 5272:   push(saved_regs, sp);
> 
> This isn't very nice.

Hello
Why is it not nice ?
linux_aarch64 uses some linux specific tls function 
_ZN10JavaThread25aarch64_get_thread_helperEv from 
hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s
which clobbers only r0 and r1
macos_aarch64 has no such tls code and uses generic C-call to Thread::current();
Hence we  are saving possibly clobbered regs here.

-

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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

[Vladimir Kempik]

On Mon, 28 Sep 2020 19:38:15 GMT, Bernhard Urban-Forster  
wrote:

>> this looks better I think, if it's done right from beginning, we won't have 
>> to modify it later.
>> The Question is, can we do it ahead of JEP-391 ?
>> If we can't then maybe better to leave it this way for now:
>> WIN64_ONLY("rtls") NOT_WIN64("r18")
>> 
>> as r18 is supposed to be reserved register on aarch64, linux is just an 
>> exception where it's allowed.
>
> Let us go with the following in this PR as that's the extend of this PR:
> Suggestion:
> 
> "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls"), "r19",
> We can update it accordingly in a PR for JEP-391.

Ok, Great.

-

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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

[Vladimir Kempik]

On Mon, 28 Sep 2020 19:09:17 GMT, Bernhard Urban-Forster  
wrote:

>> src/hotspot/cpu/aarch64/register_aarch64.cpp line 44:
>> 
>>> 42: "rscratch1", "rscratch2",
>>> 43: "r10", "r11", "r12", "r13", "r14", "r15", "r16",
>>> 44: "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19",
>> 
>> For me this line doesn't look good in case of expanding this functionality 
>> to macos-aarch64
>> as it's just the name of register and it's r18 on every platform except 
>> WIN64 and has nothing to do with reserving r18.
>
> The idea is that the naming should suggest that `r18` shouldn't be used on 
> that particular platform. Same is true for
> macOS, but the ABI docs suggest a different usage, hence we have something 
> like that in our internal branch for macOS:
> Suggestion:
> "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") 
> MACOS_ONLY("rplatform"), "r19",
> Are you suggesting it should rather be something like this eventually?
> Suggestion:
> 
> "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), 
> "r19",

this looks better I think, if it's done right from beginning, we won't have to 
modify it later.
The Question is, can we do it ahead of JEP-391 ?
If we can't then maybe better to leave it this way for now:
WIN64_ONLY("rtls") NOT_WIN64("r18")

as r18 is supposed to be reserved register on aarch64, linux is just an 
exception where it's allowed.

-

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

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

[Vladimir Kempik]

On Mon, 28 Sep 2020 14:07:16 GMT, Monica Beckwith  wrote:

>> This is a continuation of 
>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This 
>> will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov 
>> in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] 
>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> Monica Beckwith has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now
> contains 24 commits:
>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>  - SA: update copyright
>  - Fix graal codestyle
>  - Reduce includes
>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>  - os_windows: remove duplicated UMA handling
>  - test_safefetch{32,N} works fine on win+aarch64
>  - cleanup for 8253539: Remove unused JavaThread functions for 
> set_last_Java_fp/pc
>  - cleanup for 8253457: Remove unimplemented register stack functions
>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>  - ... and 14 more: 
> https://git.openjdk.java.net/jdk/compare/ec9bee68...a7cdaad6

src/hotspot/cpu/aarch64/register_aarch64.cpp line 44:

> 42: "rscratch1", "rscratch2",
> 43: "r10", "r11", "r12", "r13", "r14", "r15", "r16",
> 44: "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19",

For me this line doesn't look good in case of expanding this functionality to 
macos-aarch64
as it's just the name of register and it's r18 on every platform except WIN64 
and has nothing to do with reserving r18.

-

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

Re: RFR: 8250876: Build system preparation to macos on aarch64

[Vladimir Kempik]

Hello
Please check the updated webrev - 
http://cr.openjdk.java.net/~vkempik/8250876/webrev.02/
Thanks, Vladimir

> 10 авг. 2020 г., в 16:11, Erik Joelsson  написал(а):
> 
> On 2020-08-10 03:47, Vladimir Kempik wrote:
>> Hello
>> 
>> Renamed the bug to "Fix issues with cross-compile on macos"
>> 
>> Please check updated webrev: 
>> http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/
>> 
>> Adlc is fine with cross-compiling now.
>> 
> While not strictly needed for ADLC, I would like to see BUILD_CC getting the 
> same treatment here for consistency.
> 
> /Erik
> 
>> Regards, Vladimir
>>> 10 авг. 2020 г., в 12:52, Magnus Ihse Bursie 
>>>  написал(а):
>>> 
>>> So, basically, what this patch is about is not so much "preparation for 
>>> aarch64" as "allow cross-compile on macos"?  If I understand you correctly, 
>>> maybe you should rename the bug?
>>> 
>>> /Magnus
>>> 
>>> On 2020-08-04 16:09, Erik Joelsson wrote:
>>>> That's a good find! You are correct in that we haven't cross compiled in 
>>>> any direction involving Macosx before.
>>>> 
>>>> The preferred patch would be a bit more elaborate than that. Ideally we 
>>>> need better control over the toolchain type of the BUILD_* compiler 
>>>> settings. For now, I think just forcing clang/clang++ if BUILD_OS is 
>>>> macosx is good enough.
>>>> 
>>>> /Erik
>>>> 
>>>> On 2020-08-04 07:02, Bernhard Urban-Forster wrote:
>>>>> Good observation David, the change in adlc is just fixing a symptom. The 
>>>>> difference to a regular macOS build is that technically, despite running 
>>>>> on the same machine, it's actually cross compiling due to Rosetta being 
>>>>> the --build=x86_64 system.
>>>>> 
>>>>> Being a cross-compile, we therefore hit this case:
>>>>> https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921
>>>>> 
>>>>> And thus infers `/usr/bin/CC` for CXX.
>>>>> 
>>>>> I guess cross compiling hasn't been a thing on macOS yet. I tried the 
>>>>> following and it passes the adlc build:
>>>>> 
>>>>> --- a/make/autoconf/toolchain.m4
>>>>> +++ b/make/autoconf/toolchain.m4
>>>>> @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS],
>>>>>   # find the build compilers in the tools dir, if needed.
>>>>>   UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc])
>>>>>   UTIL_FIXUP_EXECUTABLE(BUILD_CC)
>>>>> -UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++])
>>>>> +UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++])
>>>>>   UTIL_FIXUP_EXECUTABLE(BUILD_CXX)
>>>>>   UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm)
>>>>>   UTIL_FIXUP_EXECUTABLE(BUILD_NM)
>>>>> 
>>>>> Although I'm not sure about its cleanliness :-)
>>>>> 
>>>>> -Bernhard
>>>>> 
>>>>> 
>>>>> From: build-dev  on behalf of David 
>>>>> Holmes 
>>>>> Sent: Tuesday, August 4, 2020 00:46
>>>>> To: Erik Joelsson; Vladimir Kempik; build-dev
>>>>> Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov
>>>>> Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64
>>>>> 
>>>>> On 3/08/2020 10:57 pm, Erik Joelsson wrote:
>>>>>> Hello Vladimir,
>>>>>> 
>>>>>> These changes look innocent enough to me. They aren't actually adding
>>>>>> macosx-aarch64 support, they are just removing two minor (and more
>>>>>> likely OS version related) hurdles from the build. You still have to
>>>>>> provide the actual configuration on the configure command line as is
>>>>>> shown in your example. Before we can call build system support, we would
>>>>>> need configure to automatically setup those flags and add a separate
>>>>>> parameter for the JNF framework. So, given that, I don't think this
>>>>>> change warrants a JEP in itself.
>>>>> Of course this change doesn't warrant a JEP in itself :) My point is
>>>>> that until we have a JEP for the platform that is being targeted then we

Re: RFR: 8250876: Build system preparation to macos on aarch64

[Vladimir Kempik]

Hello Erik
It’s not clear to me, what exactly you want to change in BUILD_CC, add clang to 
list for macos ?

Thanks, Vladimir

> 10 авг. 2020 г., в 16:11, Erik Joelsson  написал(а):
> 
> On 2020-08-10 03:47, Vladimir Kempik wrote:
>> Hello
>> 
>> Renamed the bug to "Fix issues with cross-compile on macos"
>> 
>> Please check updated webrev: 
>> http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/ 
>> <http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/>
>> 
>> Adlc is fine with cross-compiling now.
>> 
> While not strictly needed for ADLC, I would like to see BUILD_CC getting the 
> same treatment here for consistency.
> 
> /Erik
> 
>> Regards, Vladimir
>>> 10 авг. 2020 г., в 12:52, Magnus Ihse Bursie >> <mailto:magnus.ihse.bur...@oracle.com>> написал(а):
>>> 
>>> So, basically, what this patch is about is not so much "preparation for 
>>> aarch64" as "allow cross-compile on macos"?  If I understand you correctly, 
>>> maybe you should rename the bug?
>>> 
>>> /Magnus
>>> 
>>> On 2020-08-04 16:09, Erik Joelsson wrote:
>>>> That's a good find! You are correct in that we haven't cross compiled in 
>>>> any direction involving Macosx before.
>>>> 
>>>> The preferred patch would be a bit more elaborate than that. Ideally we 
>>>> need better control over the toolchain type of the BUILD_* compiler 
>>>> settings. For now, I think just forcing clang/clang++ if BUILD_OS is 
>>>> macosx is good enough.
>>>> 
>>>> /Erik
>>>> 
>>>> On 2020-08-04 07:02, Bernhard Urban-Forster wrote:
>>>>> Good observation David, the change in adlc is just fixing a symptom. The 
>>>>> difference to a regular macOS build is that technically, despite running 
>>>>> on the same machine, it's actually cross compiling due to Rosetta being 
>>>>> the --build=x86_64 system.
>>>>> 
>>>>> Being a cross-compile, we therefore hit this case:
>>>>> https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921
>>>>>  
>>>>> <https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921>
>>>>> 
>>>>> And thus infers `/usr/bin/CC` for CXX.
>>>>> 
>>>>> I guess cross compiling hasn't been a thing on macOS yet. I tried the 
>>>>> following and it passes the adlc build:
>>>>> 
>>>>> --- a/make/autoconf/toolchain.m4
>>>>> +++ b/make/autoconf/toolchain.m4
>>>>> @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS],
>>>>>   # find the build compilers in the tools dir, if needed.
>>>>>   UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc])
>>>>>   UTIL_FIXUP_EXECUTABLE(BUILD_CC)
>>>>> -UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++])
>>>>> +UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++])
>>>>>   UTIL_FIXUP_EXECUTABLE(BUILD_CXX)
>>>>>   UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm)
>>>>>   UTIL_FIXUP_EXECUTABLE(BUILD_NM)
>>>>> 
>>>>> Although I'm not sure about its cleanliness :-)
>>>>> 
>>>>> -Bernhard
>>>>> 
>>>>> 
>>>>> From: build-dev >>>> <mailto:build-dev-r...@openjdk.java.net>> on behalf of David Holmes 
>>>>> mailto:david.hol...@oracle.com>>
>>>>> Sent: Tuesday, August 4, 2020 00:46
>>>>> To: Erik Joelsson; Vladimir Kempik; build-dev
>>>>> Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov
>>>>> Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64
>>>>> 
>>>>> On 3/08/2020 10:57 pm, Erik Joelsson wrote:
>>>>>> Hello Vladimir,
>>>>>> 
>>>>>> These changes look innocent enough to me. They aren't actually adding
>>>>>> macosx-aarch64 support, they are just removing two minor (and more
>>>>>> likely OS version related) hurdles from the build. You still have to
>>>>>> provide the actual configuration on the configure command line as is
>>>>>> shown in your example. Before we can call build system support, we would
>>>>>> need configure to au

Re: RFR: 8250876: Build system preparation to macos on aarch64

[Vladimir Kempik]

Hello

Renamed the bug to "Fix issues with cross-compile on macos"

Please check updated webrev: 
http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/ 
<http://cr.openjdk.java.net/~vkempik/8250876/webrev.01/>

Adlc is fine with cross-compiling now.

Regards, Vladimir
> 10 авг. 2020 г., в 12:52, Magnus Ihse Bursie  
> написал(а):
> 
> So, basically, what this patch is about is not so much "preparation for 
> aarch64" as "allow cross-compile on macos"?  If I understand you correctly, 
> maybe you should rename the bug?
> 
> /Magnus
> 
> On 2020-08-04 16:09, Erik Joelsson wrote:
>> That's a good find! You are correct in that we haven't cross compiled in any 
>> direction involving Macosx before.
>> 
>> The preferred patch would be a bit more elaborate than that. Ideally we need 
>> better control over the toolchain type of the BUILD_* compiler settings. For 
>> now, I think just forcing clang/clang++ if BUILD_OS is macosx is good enough.
>> 
>> /Erik
>> 
>> On 2020-08-04 07:02, Bernhard Urban-Forster wrote:
>>> Good observation David, the change in adlc is just fixing a symptom. The 
>>> difference to a regular macOS build is that technically, despite running on 
>>> the same machine, it's actually cross compiling due to Rosetta being the 
>>> --build=x86_64 system.
>>> 
>>> Being a cross-compile, we therefore hit this case:
>>> https://github.com/openjdk/jdk/blob/b0ceab23dd4176329cbf3a95f21e8e9ac2d8723f/make/autoconf/toolchain.m4#L905-L921
>>> 
>>> And thus infers `/usr/bin/CC` for CXX.
>>> 
>>> I guess cross compiling hasn't been a thing on macOS yet. I tried the 
>>> following and it passes the adlc build:
>>> 
>>> --- a/make/autoconf/toolchain.m4
>>> +++ b/make/autoconf/toolchain.m4
>>> @@ -917,7 +917,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS],
>>>   # find the build compilers in the tools dir, if needed.
>>>   UTIL_REQUIRE_PROGS(BUILD_CC, [cl cc gcc])
>>>   UTIL_FIXUP_EXECUTABLE(BUILD_CC)
>>> -UTIL_REQUIRE_PROGS(BUILD_CXX, [cl CC g++])
>>> +UTIL_REQUIRE_PROGS(BUILD_CXX, [clang++ cl CC g++])
>>>   UTIL_FIXUP_EXECUTABLE(BUILD_CXX)
>>>       UTIL_PATH_PROGS(BUILD_NM, nm gcc-nm)
>>>   UTIL_FIXUP_EXECUTABLE(BUILD_NM)
>>> 
>>> Although I'm not sure about its cleanliness :-)
>>> 
>>> -Bernhard
>>> 
>>> 
>>> From: build-dev  on behalf of David Holmes 
>>> 
>>> Sent: Tuesday, August 4, 2020 00:46
>>> To: Erik Joelsson; Vladimir Kempik; build-dev
>>> Cc: Anton Kozlov; Alexander Ioffe; Andrew Brygin; Andrey Petushkov
>>> Subject: Re: RFR: 8250876: Build system preparation to macos on aarch64
>>> 
>>> On 3/08/2020 10:57 pm, Erik Joelsson wrote:
>>>> Hello Vladimir,
>>>> 
>>>> These changes look innocent enough to me. They aren't actually adding
>>>> macosx-aarch64 support, they are just removing two minor (and more
>>>> likely OS version related) hurdles from the build. You still have to
>>>> provide the actual configuration on the configure command line as is
>>>> shown in your example. Before we can call build system support, we would
>>>> need configure to automatically setup those flags and add a separate
>>>> parameter for the JNF framework. So, given that, I don't think this
>>>> change warrants a JEP in itself.
>>> Of course this change doesn't warrant a JEP in itself :) My point is
>>> that until we have a JEP for the platform that is being targeted then we
>>> shouldn't be making changes to provide support for that platform.
>>> 
>>> That said I didn't actually look at the changes but focused on the
>>> larger stated aim, so apologies for that.
>>> 
>>> The actual changes here are small and not obviously related to
>>> supporting macOS-Aarch64. But I'm unclear on this change as it affects
>>> all macOS builds:
>>> 
>>> 42   else ifeq ($(call isBuildOs, macosx), true)
>>> 43 ADLC_LDFLAGS := -lc++
>>> 
>>> if this was fixing a bug as indicated, why do we not see this bug in
>>> regular builds?
>>> 
>>> Thanks,
>>> David
>>> -
>>> 
>>> 
>>>> My only complaint is that you revert jib-profiles.js. That file is only
>>>> used internally at Oracle. If/when we need it to support macosx-aarch64,
>>>> we will p

RFR: 8250876: Build system preparation to macos on aarch64

[Vladimir Kempik]

Hello

Please review this change for JDK-8250876

This changeset adds support for macos/aarch64 into build system.
It will allow to crosscompile for macos/aarch64 using intel mac as well.

This changeset does NOT address some arm specific issues in the macos related 
code, we plan to do that in s separate commit.

An example of configure to cross-compile for macos/arm64:

--with-boot-jdk=/path/to/java/ --with-build-jdk=/path/to/same/java/as/compiled  
--disable-warnings-as-errors --with-jvm-variants=zero 
--openjdk-target=aarch64-apple-darwin --with-extra-cflags='-arch arm64' 
--with-extra-ldflags='-arch arm64 -F/Path/To/Folder/Containing/JNF_framework/' 
—with-extra-cxxflags='-arch arm64’

JNF.framework is missing arm64 part as of next macos release, but Apple has 
opensourced it. 

Fix to adlc were needed due to it using symbols from stdc++ and not linking to 
it, so it fails when doing make images.

The webrev: http://cr.openjdk.java.net/~vkempik/8250876/webrev.00/
The bug: https://bugs.openjdk.java.net/browse/JDK-8250876

Testing: jdk/submit.

Thanks, Vladimir.

Re: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers location

[Vladimir Kempik]

Hello
Thanks for looking into this
Here is updated webrev.

http://cr.openjdk.java.net/~vkempik/8248495/webrev.03/

Regards, Vladimir.

> 1 июля 2020 г., в 21:59, Erik Joelsson  написал(а):
> 
> I think this looks ok, but would like Magnus' input as he is already involved 
> in this review.
> 
> /Erik
> 
> On 2020-07-01 02:45, Vladimir Kempik wrote:
>> Hello
>> 
>> Please take a look at updated webrev - 
>> http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/ 
>> <http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/>
>> 
>> I decided to use AC_CHECK_HEADERS instead AC_CHECK_FILE as it doesn’t work 
>> in cross-compilation scenario.
>> 
>> libffi binary is located in absolutely standard location, so -lffi was 
>> enough.
>> 
>> Thanks, Vladimir
>> 
>>> 30 июня 2020 г., в 23:09, Magnus Ihse Bursie 
>>>  написал(а):
>>> 
>>> 
>>> On 2020-06-30 21:08, Vladimir Kempik wrote:
>>>> Hello
>>>> 
>>>> I agree modding  hpp files is a bad idea
>>>> 
>>>> Thanks for idea with setting LIBFFI_CFLAGS
>>>> 
>>>> here is updated webrev: 
>>>> http://cr.openjdk.java.net/~vkempik/8248495/webrev.01/
>>> I still think you are doing this too complicated, and the wrong way around.
>>>> AC_CHECK_HEADERS ignored CFLAGS for some reason, so modding header_name 
>>>> for it was still needed.
>>> No, AC_CHECK_HEADERS does not work that way. It knows nothing about our 
>>> internal variables. How could it?
>>> 
>>> First of all, I still think you should let PKG_CHECK_MODULES do its magic 
>>> first. If that fails, you can try compiling with AC_CHECK_HEADERS([ffi.h]), 
>>> just as the code currently does.
>>> 
>>> Only if this fails, your workaround should kick in, before giving up 
>>> completely. At this point, you should check if 
>>> ${SYSROOT}/usr/include/ffi/ffi/ffi.h exists. If it does, you should set
>>> LIBFFI_CFLAGS := -I${SYSROOT}/usr/include/ffi/ffi
>>> 
>>> and you will not need the AC_CHECK_HEADERS, since you know the ffi.h file 
>>> is there, and there is a AC_LINK_IFELSE at the end to verify that 
>>> everything works. You can even skip the platform checks, since this will 
>>> apply to all configurations where the header file is in this odd place 
>>> relative to the sysroot. (But please save a comment about where you have 
>>> spotted it.)
>>> 
>>> However, you are not done yet.  Your patch do not address the whereabouts 
>>> of the library, only the include file. I assume it might too be stored in 
>>> an odd location?
>>> 
>>> I see that we do not follow the best-practice of separating LDFLAGS and 
>>> LIBS here, so if you need to point to a non-standard location for the 
>>> library, you have to do like this example:
>>> 
>>> LIBFFI_LIBS="-L${with_libffi}/lib -lffi"
>>> 
>>> Ideally, this should be explit out to an LIBFFI_LDFLAGS, but that's a 
>>> change for another day, since it required changes in many places.
>>> 
>>> /Magnus
>>> 
>>> 
>>> 
>>>> This special case only applies to macos/clang when sysroot is set and no 
>>>> libffi configure options is used. (which is default case)
>>>> 
>>>> Thanks, Vladimir
>>>> 
>>>> 
>>>>> 30 июня 2020 г., в 19:46, Magnus Ihse Bursie 
>>>>>  написал(а):
>>>>> 
>>>>> Vladimir,
>>>>> 
>>>>> This looks like it can break in other situation than your specific case.
>>>>> 
>>>>> It sounds like you should set LIBFFI_CFLAGS= to  -I>>>> installation>, such that "/ffi.h" exists. 
>>>>> In particular, the change of include path in globalDefinitions_zero.hpp 
>>>>> looks bad.
>>>>> 
>>>>> /Magnus
>>>>> 
>>>>> On 2020-06-30 15:33, Vladimir Kempik wrote:
>>>>>> Hello
>>>>>> 
>>>>>> Please review this fix for zero vm building on macos.
>>>>>> 
>>>>>> The issue comes from the libffi, it’s headers are located inside 
>>>>>> usr/include/ffi/ folder in Macos.sdk, so it can’t be found by configure 
>>>>>> script.
>>>>>> 
>>>>>> If one wants to use system’s libffi and pass path to libffi via 
>>>>>> configure argument as --with-libffi-include=/usr/include/ffi, then it 
>>>>>> won’t be found by configure because clang will look exactly in 
>>>>>> /usr/include/ffi, but not in macos.sdk
>>>>>> The system, at least on 10.15 doesn’t have /usr/includes at all.
>>>>>> 
>>>>>> This patch makes jdk to look for ffi/ffi.h header in case of Macos/clang 
>>>>>> and no --with-libffi-include argument.
>>>>>> 
>>>>>> However there is one issue with this patch, if --with-libffi-include 
>>>>>> passed then c++ code will still try to include 
>>>>>> 
>>>>>> I’m not sure which way is the best for such rare case. it could be 
>>>>>> possible to define include filename in configure and pass it via -D and 
>>>>>> CFLAGS to c++ code.
>>>>>> 
>>>>>> 
>>>>>> The webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.00/
>>>>>> 
>>>>>> The bug - https://bugs.openjdk.java.net/browse/JDK-8248495
>>>>>> 
>>>>>> Thanks, Vladimir

Re: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers location

[Vladimir Kempik]

Hello

Please take a look at updated webrev - 
http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/ 
<http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/>

I decided to use AC_CHECK_HEADERS instead AC_CHECK_FILE as it doesn’t work in 
cross-compilation scenario.

libffi binary is located in absolutely standard location, so -lffi was enough.

Thanks, Vladimir

> 30 июня 2020 г., в 23:09, Magnus Ihse Bursie  
> написал(а):
> 
> 
> On 2020-06-30 21:08, Vladimir Kempik wrote:
>> Hello
>> 
>> I agree modding  hpp files is a bad idea
>> 
>> Thanks for idea with setting LIBFFI_CFLAGS
>> 
>> here is updated webrev: 
>> http://cr.openjdk.java.net/~vkempik/8248495/webrev.01/
> I still think you are doing this too complicated, and the wrong way around.
>> 
>> AC_CHECK_HEADERS ignored CFLAGS for some reason, so modding header_name for 
>> it was still needed.
> 
> No, AC_CHECK_HEADERS does not work that way. It knows nothing about our 
> internal variables. How could it?
> 
> First of all, I still think you should let PKG_CHECK_MODULES do its magic 
> first. If that fails, you can try compiling with AC_CHECK_HEADERS([ffi.h]), 
> just as the code currently does.
> 
> Only if this fails, your workaround should kick in, before giving up 
> completely. At this point, you should check if 
> ${SYSROOT}/usr/include/ffi/ffi/ffi.h exists. If it does, you should set
> LIBFFI_CFLAGS := -I${SYSROOT}/usr/include/ffi/ffi
> 
> and you will not need the AC_CHECK_HEADERS, since you know the ffi.h file is 
> there, and there is a AC_LINK_IFELSE at the end to verify that everything 
> works. You can even skip the platform checks, since this will apply to all 
> configurations where the header file is in this odd place relative to the 
> sysroot. (But please save a comment about where you have spotted it.)
> 
> However, you are not done yet.  Your patch do not address the whereabouts of 
> the library, only the include file. I assume it might too be stored in an odd 
> location?
> 
> I see that we do not follow the best-practice of separating LDFLAGS and LIBS 
> here, so if you need to point to a non-standard location for the library, you 
> have to do like this example:
> 
> LIBFFI_LIBS="-L${with_libffi}/lib -lffi"
> 
> Ideally, this should be explit out to an LIBFFI_LDFLAGS, but that's a change 
> for another day, since it required changes in many places.
> 
> /Magnus
> 
> 
> 
>> This special case only applies to macos/clang when sysroot is set and no 
>> libffi configure options is used. (which is default case)
>> 
>> Thanks, Vladimir
>> 
>> 
>>> 30 июня 2020 г., в 19:46, Magnus Ihse Bursie 
>>>  написал(а):
>>> 
>>> Vladimir,
>>> 
>>> This looks like it can break in other situation than your specific case.
>>> 
>>> It sounds like you should set LIBFFI_CFLAGS= to  -I>> installation>, such that "/ffi.h" exists. In 
>>> particular, the change of include path in globalDefinitions_zero.hpp looks 
>>> bad.
>>> 
>>> /Magnus
>>> 
>>> On 2020-06-30 15:33, Vladimir Kempik wrote:
>>>> Hello
>>>> 
>>>> Please review this fix for zero vm building on macos.
>>>> 
>>>> The issue comes from the libffi, it’s headers are located inside 
>>>> usr/include/ffi/ folder in Macos.sdk, so it can’t be found by configure 
>>>> script.
>>>> 
>>>> If one wants to use system’s libffi and pass path to libffi via configure 
>>>> argument as --with-libffi-include=/usr/include/ffi, then it won’t be found 
>>>> by configure because clang will look exactly in /usr/include/ffi, but not 
>>>> in macos.sdk
>>>> The system, at least on 10.15 doesn’t have /usr/includes at all.
>>>> 
>>>> This patch makes jdk to look for ffi/ffi.h header in case of Macos/clang 
>>>> and no --with-libffi-include argument.
>>>> 
>>>> However there is one issue with this patch, if --with-libffi-include 
>>>> passed then c++ code will still try to include 
>>>> 
>>>> I’m not sure which way is the best for such rare case. it could be 
>>>> possible to define include filename in configure and pass it via -D and 
>>>> CFLAGS to c++ code.
>>>> 
>>>> 
>>>> The webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.00/
>>>> 
>>>> The bug - https://bugs.openjdk.java.net/browse/JDK-8248495
>>>> 
>>>> Thanks, Vladimir

Re: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers location

[Vladimir Kempik]

Hello

You are using libffi from brew. I'm trying to use the system's one. On x86_64 
you have a choice, but on arm64 there is no choice atm.

I believe its wrong when configure script can't find default system's library 
located at default location for this type of OS.

Thanks, Vladimir.

"jiefu(傅杰)"  1 июля 2020 г. 02:59:18 написал:

Hi Vladimir and Magnus,

How about configuring with --with-libffi=... like this:
--with-libffi=/usr/local/Cellar/libffi/3.2.1/lib/libffi-3.2.1 
--disable-warnings-as-errors

I can compile zero vm on our macos platforms with that configuration.

Thanks.
Best regards,
Jie

On 2020/7/1, 3:15 AM, "build-dev on behalf of Vladimir Kempik" 
 wrote:

Hello

I agree modding  hpp files is a bad idea

Thanks for idea with setting LIBFFI_CFLAGS

here is updated webrev: 
http://cr.openjdk.java.net/~vkempik/8248495/webrev.01/

AC_CHECK_HEADERS ignored CFLAGS for some reason, so modding header_name for 
it was still needed.
This special case only applies to macos/clang when sysroot is set and no 
libffi configure options is used. (which is default case)

Thanks, Vladimir


30 июня 2020 г., в 19:46, Magnus Ihse Bursie  
написал(а):

Vladimir,

This looks like it can break in other situation than your specific case.

It sounds like you should set LIBFFI_CFLAGS= to  -I, such that "/ffi.h" exists. In 
particular, the change of include path in globalDefinitions_zero.hpp looks bad.

/Magnus

On 2020-06-30 15:33, Vladimir Kempik wrote:
Hello

Please review this fix for zero vm building on macos.

The issue comes from the libffi, it’s headers are located inside 
usr/include/ffi/ folder in Macos.sdk, so it can’t be found by configure script.

If one wants to use system’s libffi and pass path to libffi via configure 
argument as --with-libffi-include=/usr/include/ffi, then it won’t be found by 
configure because clang will look exactly in /usr/include/ffi, but not in 
macos.sdk
The system, at least on 10.15 doesn’t have /usr/includes at all.

This patch makes jdk to look for ffi/ffi.h header in case of Macos/clang and no 
--with-libffi-include argument.

However there is one issue with this patch, if --with-libffi-include passed 
then c++ code will still try to include 

I’m not sure which way is the best for such rare case. it could be possible to 
define include filename in configure and pass it via -D and CFLAGS to c++ code.


The webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.00/

The bug - https://bugs.openjdk.java.net/browse/JDK-8248495

Thanks, Vladimir

Re: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers location

[Vladimir Kempik]

Hello

I agree modding  hpp files is a bad idea

Thanks for idea with setting LIBFFI_CFLAGS

here is updated webrev: http://cr.openjdk.java.net/~vkempik/8248495/webrev.01/

AC_CHECK_HEADERS ignored CFLAGS for some reason, so modding header_name for it 
was still needed.
This special case only applies to macos/clang when sysroot is set and no libffi 
configure options is used. (which is default case)

Thanks, Vladimir


> 30 июня 2020 г., в 19:46, Magnus Ihse Bursie  
> написал(а):
> 
> Vladimir,
> 
> This looks like it can break in other situation than your specific case.
> 
> It sounds like you should set LIBFFI_CFLAGS= to  -I installation>, such that "/ffi.h" exists. In 
> particular, the change of include path in globalDefinitions_zero.hpp looks 
> bad.
> 
> /Magnus
> 
> On 2020-06-30 15:33, Vladimir Kempik wrote:
>> Hello
>> 
>> Please review this fix for zero vm building on macos.
>> 
>> The issue comes from the libffi, it’s headers are located inside 
>> usr/include/ffi/ folder in Macos.sdk, so it can’t be found by configure 
>> script.
>> 
>> If one wants to use system’s libffi and pass path to libffi via configure 
>> argument as --with-libffi-include=/usr/include/ffi, then it won’t be found 
>> by configure because clang will look exactly in /usr/include/ffi, but not in 
>> macos.sdk
>> The system, at least on 10.15 doesn’t have /usr/includes at all.
>> 
>> This patch makes jdk to look for ffi/ffi.h header in case of Macos/clang and 
>> no --with-libffi-include argument.
>> 
>> However there is one issue with this patch, if --with-libffi-include passed 
>> then c++ code will still try to include 
>> 
>> I’m not sure which way is the best for such rare case. it could be possible 
>> to define include filename in configure and pass it via -D and CFLAGS to c++ 
>> code.
>> 
>> 
>> The webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.00/
>> 
>> The bug - https://bugs.openjdk.java.net/browse/JDK-8248495
>> 
>> Thanks, Vladimir

RFR[16] 8248495: [macos] zerovm is broken due to libffi headers location

[Vladimir Kempik]

Hello

Please review this fix for zero vm building on macos.

The issue comes from the libffi, it’s headers are located inside 
usr/include/ffi/ folder in Macos.sdk, so it can’t be found by configure script.

If one wants to use system’s libffi and pass path to libffi via configure 
argument as --with-libffi-include=/usr/include/ffi, then it won’t be found by 
configure because clang will look exactly in /usr/include/ffi, but not in 
macos.sdk
The system, at least on 10.15 doesn’t have /usr/includes at all.

This patch makes jdk to look for ffi/ffi.h header in case of Macos/clang and no 
--with-libffi-include argument.

However there is one issue with this patch, if --with-libffi-include passed 
then c++ code will still try to include 

I’m not sure which way is the best for such rare case. it could be possible to 
define include filename in configure and pass it via -D and CFLAGS to c++ code.


The webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.00/

The bug - https://bugs.openjdk.java.net/browse/JDK-8248495

Thanks, Vladimir

Re: RFR: 8243470: [macos] bring back O2 opt level for unsafe.cpp

[Vladimir Kempik]

Hello
Thanks for looking into this Magnus.

Here is updated version of webrev - 
http://cr.openjdk.java.net/~vkempik/8243470/webrev.01/ 
<http://cr.openjdk.java.net/~vkempik/8243470/webrev.01/>
effectively it does exactly the same as previous version, I have removed the 
version check for clang.


Thanks, Vladimir

> 4 июня 2020 г., в 16:04, Magnus Ihse Bursie  
> написал(а):
> 
> On 2020-06-03 20:07, Magnus Ihse Bursie wrote:
>> Thanks for cc:ing us.
>> 
>> This is not the correct way to check for compiler versions. Nor is it the 
>> correct place.
>> 
>> I don't have time for a full reply tonight, but will return with a better 
>> reply tomorrow.
> Ok, I have now looked more into this.
> 
> You are apparently want to check for Xcode version, not clang version. This 
> is not the same. Note that clang can be used on Linux as well. Apple is 
> basically dropping the normal clang versioning and replacing it with their 
> own, messed-up version which somewhat resembles the corresponding Xcode 
> version, but is not identical. Horray. :-/ (For those interested, have a look 
> at https://gist.github.com/yamaya/2924292.)
> 
> Anyway. We do not support Xcode prior to 8. You seem to have tested from 8 
> and up, so this patch should be applied unconditionally. That is, just remove 
> the -O1 special thing.
> 
> /Magnus
>> 
>> /Magnus
>> 
>> On 2020-06-03 19:47, Daniel D. Daugherty wrote:
>>> Adding build-dev@... since this is a build system change.
>>> 
>>> As for the right HotSpot team, I'm not sure who should be making
>>> the call on changing the way unsafe.cpp is built for macOSX. My guess
>>> when I moved the bug to hotspot/runtime was that someone on the Runtime
>>> team would know, but...
>>> 
>>> Dan
>>> 
>>> 
>>> 
>>> On 6/3/20 1:38 PM, Vladimir Kempik wrote:
>>>> Hello
>>>> 
>>>> Can somebody please review this simple change ?
>>>> 
>>>> Thanks
>>>> 
>>>>> 6 мая 2020 г., в 12:43, Vladimir Kempik  написал(а):
>>>>> 
>>>>> Adding hotspot-runtime-dev
>>>>> 
>>>>>> 23 апр. 2020 г., в 18:26, Vladimir Kempik  написал(а):
>>>>>> 
>>>>>> 
>>>>>> Hello
>>>>>> Please review a fix for JDK-8243470
>>>>>> 
>>>>>> Long time ago as part of JEP284: New HotSpot Build System this fix was 
>>>>>> applied to jdk9 https://bugs.openjdk.java.net/browse/JDK-8152666
>>>>>> At that time it was decided to lower optimisation level for unsafe.cpp 
>>>>>> from O2 to O1 only for clang on Macosx.
>>>>>> 
>>>>>> I suppose it was done due to issues in Set/Get helper functions 
>>>>>> where too optimistic optimisations were eliminating some null pointer 
>>>>>> checks. it was probably a clang bug.
>>>>>> That issue could be checked with test jdk/test/sun/misc/CopyMemory.java.
>>>>>> 
>>>>>> I believe that workaround (going from O2 to O1) produced this issue - 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8234963 (Thread.getStackTrace 
>>>>>> is slow with clang).
>>>>>> JDK-8234963 can only be seen on mac with libjvm compiled by clang.
>>>>>> 
>>>>>> Here I propose the patch which eliminates that workaround for clang 8+.
>>>>>> 
>>>>>> I have tested clang versions 8/9/9.1/10, all of them showed good results:
>>>>>> 1) CopyMemory test passes fine on 11/14/15.
>>>>>> 2) jdk11/jdk14 passed tck. Regression testing were good as well. jdk15: 
>>>>>> no new failures in tck.
>>>>>> 3) The testRandom "benchmark" from 8234963 shows great improvements on 
>>>>>> my machine, going down from ~200 seconds to ~150 seconds (the newer 
>>>>>> clang the better result). For comparision, gcc built libjvm for jdk11 
>>>>>> shows ~130 seconds on my machine.
>>>>>> 
>>>>>> The webrev: http://cr.openjdk.java.net/~vkempik/8243470/webrev.00/
>>>>>> 
>>>>>> getStackTrace benchmark: 
>>>>>> http://cr.openjdk.java.net/~vkempik/8243470/TestRandom.java
>>>>>> 
>>>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8243470
>>>>>> 
>>>>>> Thanks, Vladimir
>>> 
>> 

Re: [8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u

[Vladimir Kempik]

Hello

Are you sure it’s needed for jdk8 ?

Notarization requires sdk of version at least 10.9

This can be achieved using xcode 4.3.x together with 10.9 sdk (either copy 
10.l9 sdk from xcode5 or use systemwide sdk if build host is 10.9) and patching 
two lines in jdk8’s make files.

Going to clang may have many undesired consequences, for example 
https://bugs.openjdk.java.net/browse/JDK-8234963 


Example of the patch to build jdk8 with gcc-llvm and sdk 10.9:

hotspot:
$ hg diff
diff -r 3c35d9ae7194 make/bsd/makefiles/gcc.make
--- a/make/bsd/makefiles/gcc.make   Thu Feb 20 15:54:10 2020 +0300
+++ b/make/bsd/makefiles/gcc.make   Wed Feb 26 14:06:16 2020 +0300
@@ -344,7 +344,7 @@
   # if built on a newer version of the OS.
   # The expected format is X.Y.Z
   ifeq ($(MACOSX_VERSION_MIN),)
-MACOSX_VERSION_MIN=10.7.0
+MACOSX_VERSION_MIN=10.9.0
   endif
   # The macro takes the version with no dots, ex: 1070
   CFLAGS += -DMAC_OS_X_VERSION_MAX_ALLOWED=$(subst .,,$(MACOSX_VERSION_MIN)) \
os-x-10:hotspot dmitry$ cd ..
$ hg diff
diff -r d8c00a997c65 common/autoconf/flags.m4
--- a/common/autoconf/flags.m4  Thu Feb 20 15:54:10 2020 +0300
+++ b/common/autoconf/flags.m4  Wed Feb 26 14:06:22 2020 +0300
@@ -633,7 +633,7 @@
   # newer than the given OS version and makes the linked binaries 
compatible
   # even if built on a newer version of the OS.
   # The expected format is X.Y.Z
-  MACOSX_VERSION_MIN=10.7.0
+  MACOSX_VERSION_MIN=10.9.0
   AC_SUBST(MACOSX_VERSION_MIN)

   # The macro takes the version with no dots, ex: 1070
diff -r d8c00a997c65 common/autoconf/generated-configure.sh
--- a/common/autoconf/generated-configure.shThu Feb 20 15:54:10 2020 +0300
+++ b/common/autoconf/generated-configure.shWed Feb 26 14:06:22 2020 +0300
@@ -4396,7 +4396,7 @@
 #CUSTOM_AUTOCONF_INCLUDE

 # Do not change or remove the following line, it is needed for consistency 
checks:
-DATE_WHEN_GENERATED=1580709484
+DATE_WHEN_GENERATED=1582708947

 ###
 #
@@ -42159,7 +42159,7 @@
   # newer than the given OS version and makes the linked binaries 
compatible
   # even if built on a newer version of the OS.
   # The expected format is X.Y.Z
-  MACOSX_VERSION_MIN=10.7.0
+  MACOSX_VERSION_MIN=10.9.0


   # The macro takes the version with no dots, ex: 1070

Thanks, Vladimir

> 13 сент. 2019 г., в 17:05, Simon Tooke  написал(а):
> 
> Hello all,
> 
> This is a request for review of my patch to enable building 8u with
> modern (9,10,11) Xcode versions on macOS.  I've received a few recent
> enquiries so I thought I'd submit this.
> 
> When I first created this patch is was more for convenience, but soon
> macOS will require applications to be "notarized", which cannot be done
> with the old version of Xcode.  This will become mandatory long before
> 8u is due to retire [1].
> 
> This patch is not intended to remove the current ability to build 8u on
> the current supported build platform.
> 
> I have used the patch with Xcode 9,10 and a beta of 11, and used the
> resultant JDK to build Graal.
> 
> I have not build a JDK using the old Xcode and this patch; my intent was
> to ensure this was still possible.
> 
> There is some information available on my GitHub page:
> https://github.com/stooke/jdk8u-xcode10
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8226288
> 
> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8226288-jdk8u/00/
> 
> Previous discussion:
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009733.html
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009760.html
> 
> Thank you for your time,
> 
> -Simon
> 
> 
> [1]
> https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution