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.
> 1
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
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 a
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
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 tr
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
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
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
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 'MID
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: i
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
>>
>>
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
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
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
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
>>
>>
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: ass
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:
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 mea
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: //|
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 o
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
>>
>>
ions 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 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_compil
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
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
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)
>
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:
>
> ```
> Hell
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 co
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
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-confi
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:
>
>
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/libhar
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/'`
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 b
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 chan
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-de
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:
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.gm
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
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/NativeCompilati
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/macroAsse
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(
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",
>>
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
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 is
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 &qu
;>> 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
>>>
>>>
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 s
t; 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/>
>
ted 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
>>
tforms 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.ope
gt;
> 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:
>> Hell
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 --w
020-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
>
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 clan
55 matches
Mail list logo
