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

2021-01-25 Thread 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

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

2021-01-25 Thread Phil Race
On Mon, 25 Jan 2021 23:34:04 GMT, Phil Race wrote: >> that sounds good to me, I am just afraid to break intel mac on older macos >> versions with this change. > > That may actually be a valid concern. Both say macOS 10.12+ ... which might > conflict with the 10.9 target. Maybe you should

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

2021-01-25 Thread Phil Race
On Mon, 25 Jan 2021 22:47:33 GMT, Vladimir Kempik wrote: >> 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

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

2021-01-25 Thread Chris Plummer
On Mon, 25 Jan 2021 19:38:16 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

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

2021-01-25 Thread Chris Plummer
On Mon, 25 Jan 2021 19:38:16 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

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

2021-01-25 Thread 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

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

2021-01-25 Thread Phil Race
On Mon, 25 Jan 2021 22:25:48 GMT, Vladimir Kempik wrote: >> 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

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

2021-01-25 Thread 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

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

2021-01-25 Thread Phil Race
On Mon, 25 Jan 2021 21:18:59 GMT, Vladimir Kempik wrote: >> 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

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

2021-01-25 Thread 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 :=

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

2021-01-25 Thread 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 > >

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

2021-01-25 Thread Phil Race
On Mon, 25 Jan 2021 19:38:16 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

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

2021-01-25 Thread Anton Kozlov
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818)

Integrated: 8260289: Unable to customize module lists after change JDK-8258411

2021-01-25 Thread Andrew Leonard
On Mon, 25 Jan 2021 12:57:29 GMT, Andrew Leonard wrote: > A problem was found downstream with Eclipse OpenJ9 builds whereby since > JDK-8258411 they were unable to extend the module lists. > This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to > enable the module list

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

2021-01-25 Thread Coleen Phillimore
On Mon, 25 Jan 2021 15:01:25 GMT, Anton Kozlov wrote: >> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87: >> >>> 85: JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env); >>> 86: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));; >>> 87:

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

2021-01-25 Thread Anton Kozlov
On Mon, 25 Jan 2021 09:52:00 GMT, Andrew Haley wrote: >> 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 >>

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

2021-01-25 Thread Phil Race
On Sun, 24 Jan 2021 15:32:59 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

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

2021-01-25 Thread Andrew Haley
On Sun, 24 Jan 2021 15:50:01 GMT, Anton Kozlov wrote: >> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86: >> >>> 84: >>> 85: switch (_num_int_args) { >>> 86: case 0: >> >> I don't think you need such a large switch statement. I think this can be >> expressed as >> if

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

2021-01-25 Thread Bernhard Urban-Forster
On Mon, 25 Jan 2021 13:30:55 GMT, Vladimir Kempik wrote: >> 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

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2]

2021-01-25 Thread Alan Bateman
On Mon, 25 Jan 2021 14:20:01 GMT, Andrew Leonard wrote: >> A problem was found downstream with Eclipse OpenJ9 builds whereby since >> JDK-8258411 they were unable to extend the module lists. >> This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to >> enable the module

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2]

2021-01-25 Thread Magnus Ihse Bursie
On Mon, 25 Jan 2021 14:20:01 GMT, Andrew Leonard wrote: >> A problem was found downstream with Eclipse OpenJ9 builds whereby since >> JDK-8258411 they were unable to extend the module lists. >> This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to >> enable the module

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2]

2021-01-25 Thread Andrew Leonard
On Mon, 25 Jan 2021 13:08:58 GMT, Magnus Ihse Bursie wrote: >> Andrew Leonard has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull request contains one >>

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

2021-01-25 Thread Anton Kozlov
On Mon, 25 Jan 2021 14:36:35 GMT, Coleen Phillimore 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 > >

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2]

2021-01-25 Thread Andrew Leonard
On Mon, 25 Jan 2021 13:57:26 GMT, Magnus Ihse Bursie wrote: >> Note, it was the change from "appending" to BOOT_MODULES to just "assigning" >> that broke the existing behaviour with the JDK-8258411 change. > > @andrew-m-leonard (Seems I can't get github to tag you???) > > That sounds good. I

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2]

2021-01-25 Thread Martin Buchholz
On Mon, 25 Jan 2021 14:00:42 GMT, Andrew Leonard wrote: >> @andrew-m-leonard (Seems I can't get github to tag you???) >> >> That sounds good. I think you could move the IncludeCustomExtension to after >> all *.conf files, to future-proof it and to make it a bit more consistent -- >> "first

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

2021-01-25 Thread Coleen Phillimore
On Mon, 25 Jan 2021 14:40:09 GMT, Coleen Phillimore 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 > >

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

2021-01-25 Thread Coleen Phillimore
On Sun, 24 Jan 2021 15:32:59 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

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

2021-01-25 Thread Coleen Phillimore
On Sun, 24 Jan 2021 15:32:59 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

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2]

2021-01-25 Thread Andrew Leonard
On Mon, 25 Jan 2021 13:57:26 GMT, Magnus Ihse Bursie wrote: >> Note, it was the change from "appending" to BOOT_MODULES to just "assigning" >> that broke the existing behaviour with the JDK-8258411 change. > > @andrew-m-leonard (Seems I can't get github to tag you???) > > That sounds good. I

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2]

2021-01-25 Thread Magnus Ihse Bursie
On Mon, 25 Jan 2021 13:45:23 GMT, Andrew Leonard wrote: >> The previous behavior provided the ability to "extend" the upstream MODULE >> lists, ie.just add OpenJ9 modules to the base module lists, see: >>

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2]

2021-01-25 Thread Andrew Leonard
On Mon, 25 Jan 2021 13:08:58 GMT, Magnus Ihse Bursie wrote: >> Andrew Leonard has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull request contains one >>

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2]

2021-01-25 Thread Andrew Leonard
> A problem was found downstream with Eclipse OpenJ9 builds whereby since > JDK-8258411 they were unable to extend the module lists. > This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to > enable the module list extension again. > > Signed-off-by: Andrew Leonard

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

2021-01-25 Thread 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,

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

2021-01-25 Thread Per Liden
On Mon, 25 Jan 2021 13:23:27 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 > > Changes requested by ihse

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411

2021-01-25 Thread Andrew Leonard
On Mon, 25 Jan 2021 13:41:06 GMT, Andrew Leonard wrote: >>> @AlanBateman Yes, that's what JDK-8258411 inadvertently changed and I am >>> fixing. I am going to now move the common/Modules.gmk >>> IncludeCustomExtension after the module-loader-map.conf include. >> >> Andrew, why can't you just

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411

2021-01-25 Thread Andrew Leonard
On Mon, 25 Jan 2021 13:27:29 GMT, Magnus Ihse Bursie wrote: >> @magicus Is there an ordering issue in common/Modules.gmk? It also invokes >> IncludeCustomExtension but this is done before it includes the conf file. > >> @AlanBateman Yes, that's what JDK-8258411 inadvertently changed and I am

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

2021-01-25 Thread 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 > >

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411

2021-01-25 Thread Magnus Ihse Bursie
On Mon, 25 Jan 2021 13:19:31 GMT, Alan Bateman wrote: >> make/conf/module-loader-map.conf line 100: >> >>> 98: # Hook to include the corresponding custom file, if present. >>> 99: $(eval $(call IncludeCustomExtension, conf/module-loader-map.conf)) >>> 100: >> >> Using IncludeCustomExtension

Re: RFR: 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC [v5]

2021-01-25 Thread Harold Seigel
On Mon, 25 Jan 2021 07:17:13 GMT, Thomas Stuefe wrote: >> Hi David, >> The changes look good. Just a couple of nits. >> 1. Could you add a comment explaining why AIX and BSD have their own version >> of javaTimeNanos_info(). >> 2. A few copyrights need to be updated to 2021. >> Thanks, Harold

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

2021-01-25 Thread Magnus Ihse Bursie
On Sun, 24 Jan 2021 15:32:59 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

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411

2021-01-25 Thread Andrew Leonard
On Mon, 25 Jan 2021 13:19:31 GMT, Alan Bateman wrote: >> make/conf/module-loader-map.conf line 100: >> >>> 98: # Hook to include the corresponding custom file, if present. >>> 99: $(eval $(call IncludeCustomExtension, conf/module-loader-map.conf)) >>> 100: >> >> Using IncludeCustomExtension

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411

2021-01-25 Thread Alan Bateman
On Mon, 25 Jan 2021 13:08:53 GMT, Magnus Ihse Bursie wrote: >> A problem was found downstream with Eclipse OpenJ9 builds whereby since >> JDK-8258411 they were unable to extend the module lists. >> This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to >> enable the

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411

2021-01-25 Thread Andrew Leonard
On Mon, 25 Jan 2021 13:08:53 GMT, Magnus Ihse Bursie wrote: >> A problem was found downstream with Eclipse OpenJ9 builds whereby since >> JDK-8258411 they were unable to extend the module lists. >> This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to >> enable the

Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411

2021-01-25 Thread Magnus Ihse Bursie
On Mon, 25 Jan 2021 12:57:29 GMT, Andrew Leonard wrote: > A problem was found downstream with Eclipse OpenJ9 builds whereby since > JDK-8258411 they were unable to extend the module lists. > This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to > enable the module list

RFR: 8260289: Unable to customize module lists after change JDK-8258411

2021-01-25 Thread Andrew Leonard
A problem was found downstream with Eclipse OpenJ9 builds whereby since JDK-8258411 they were unable to extend the module lists. This PR adds a IncludeCustomExtension to the conf/module-loader-map.conf, to enable the module list extension again. Signed-off-by: Andrew Leonard -

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

2021-01-25 Thread Andrew Haley
On Sun, 24 Jan 2021 16:29:31 GMT, Vladimir Kempik wrote: >> 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; >>>

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

2021-01-25 Thread Andrew Haley
On Sun, 24 Jan 2021 16:10:44 GMT, Anton Kozlov wrote: >> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394: >> >>> 392: >>> 393: class SlowSignatureHandler >>> 394: : public NativeSignatureIterator { >> >> SlowSignatureHandler is turning into a maintenance nightmare. This isn't the