On Thu, 22 Apr 2021 06:43:45 GMT, Per Liden wrote:
>> This patch enables ZGC on macOS/aarch64. It does three things:
>> 1) Enables building of ZGC on this platform.
>> 2) Adds `os::processor_id()`, which for now always returns 0.
>> 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, wher
On Wed, 3 Mar 2021 17:46:41 GMT, Andrew Haley wrote:
> > A list of the bugs that our internal testing revealed so far:
>
> Are any of these blockers for integration? Some of them are to do with things
> like features that aren't yet supported, and we can't fix what we can't see.
I don't person
On Tue, 2 Mar 2021 11:05:20 GMT, Anton Kozlov wrote:
>> For platform files that were copied from other ports to this port, if the
>> file wasn't
>> changed I presume the copyright years are left alone. If the file required
>> changes
>> for this port, I expect the year to be updated to 2021. Ho
On Tue, 2 Mar 2021 23:21:28 GMT, David Holmes wrote:
> Note that `thread` can be NULL here if the signal handler is running in a
> non-attached thread. If we then perform:
> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) : _thread(thread ?
> thread : Thread::current()),`
> we call Thre
On Wed, 17 Feb 2021 12:36:10 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Mon, 15 Feb 2021 06:24:13 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal API
On Mon, 15 Feb 2021 18:30:51 GMT, Gerard Ziemski wrote:
>> Changes requested by gziemski (Committer).
>
> I took a look at https://bugs.openjdk.java.net/browse/JDK-8261408 and noticed
> a startup time regression with the Metal rendering pipeline, so I dug a bit
> and here is
On Thu, 11 Feb 2021 20:55:47 GMT, Gerard Ziemski wrote:
>> Ajit Ghaisas has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Lanai PR#181 - 8261143 - aghaisas
>> - Lanai PR#180 - 8261546 - jdv
>
> Chan
On Thu, 11 Feb 2021 20:58:36 GMT, Gerard Ziemski wrote:
>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 112:
>>
>>> 110: sourceSize:MTLSizeMake(self.buffer.width,
>>> self.buffer.height, 1)
>>> 111:
On Thu, 11 Feb 2021 20:55:35 GMT, Gerard Ziemski wrote:
>> Ajit Ghaisas has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Lanai PR#181 - 8261143 - aghaisas
>> - Lanai PR#180 - 8261546 - jdv
>
On Thu, 11 Feb 2021 11:51:57 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal API
On Wed, 10 Feb 2021 21:45:37 GMT, Gerard Ziemski wrote:
>> Ajit Ghaisas has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Lanai PR#177 - 8261430 - aghaisas
>> - Lanai PR#176 - 8261399 - jdv
>
> Marke
On Tue, 9 Feb 2021 12:29:52 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal API.
On Wed, 10 Feb 2021 21:40:46 GMT, Gerard Ziemski wrote:
>> Changes requested by gziemski (Committer).
>
> I tried to code review the native implementation files, but Metal APIs is
> brand new to me and it's been a long while since I worked with graphics API,
> so I can&#
On Mon, 8 Feb 2021 23:07:39 GMT, Gerard Ziemski wrote:
>> Ajit Ghaisas has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Lanai PR#175 - 8261304 - aghaisas
>
> Changes requested by gziemski (Committer).
I t
On Mon, 8 Feb 2021 12:28:07 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal API.
On Mon, 8 Feb 2021 12:28:07 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal API.
On Mon, 8 Feb 2021 17:15:25 GMT, Gerard Ziemski wrote:
>> The file in `RenderPerfTest` should have a GPLv2 license header (no
>> Classpath). I filed
>> [JDK-8261273](https://bugs.openjdk.java.net/browse/JDK-8261273) and also
>> highlighted a couple examples below.
&g
On Sat, 6 Feb 2021 00:53:08 GMT, Kevin Rushforth wrote:
>> Ajit Ghaisas has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Lanai PR#175 - 8261304 - aghaisas
>
> The file in `RenderPerfTest` should have a GPLv2 license header (no
> Classpat
On Fri, 5 Feb 2021 12:26:27 GMT, Anton Kozlov wrote:
>> Marked as reviewed by ihse (Reviewer).
>
>> I haven't got a MacOS AArch64 system right now. Is it possible to
>> enable W^X in Linux in order to kick the tyres?
>
> I've just got rid of asserts that fired on Linux sometime :) As for W^X lik
On Tue, 2 Feb 2021 22:09:58 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 363:
>
>> 361: add
On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Wed, 3 Feb 2021 23:13:12 GMT, Bernhard Urban-Forster
wrote:
>> No idea how to insert spaces and make text align :-(
>
> using ` ```c `
> https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks
>
> I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's use
On Wed, 3 Feb 2021 22:44:18 GMT, Gerard Ziemski wrote:
>> Thanks for your questions Gerard.
>>
>>> Part of the comment said This work-around is not necessary for 10.5+, as
>>> CrashReporter no longer intercedes on caught fatal signals.
>>
>>
On Wed, 3 Feb 2021 22:17:02 GMT, Bernhard Urban-Forster
wrote:
>> To answer my own question, it seems that code is still needed on `x86_64`
>> for `lldb` with `EXC_MASK_BAD_ACCESS` or we keep tripping over
>> `EXC_BAD_ACCESS`
>>
>> Remaining questions:
>>
>> a) why we need `EXC_MASK_ARITHMET
On Wed, 3 Feb 2021 20:04:18 GMT, Gerard Ziemski wrote:
>> See comment above about `gdb`, the same applies to `lldb` today. The AArch64
>> backend uses `SIGILL` (~= `EXC_MASK_BAD_INSTRUCTION`) to initiate a
>> deoptimization. Without this change you cannot continue debuggin
On Tue, 2 Feb 2021 19:23:16 GMT, Bernhard Urban-Forster
wrote:
>> src/hotspot/os/posix/signals_posix.cpp line 1297:
>>
>>> 1295: kern_return_t kr;
>>> 1296: kr = task_set_exception_ports(mach_task_self(),
>>> 1297: EXC_MASK_BAD_ACCESS |
>>> EXC_MASK_BAD_INST
On Tue, 2 Feb 2021 18:52:29 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> Changes requested by gziemski (Committer).
There we
On Tue, 2 Feb 2021 11:59:08 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Mon, 1 Feb 2021 20:10:58 GMT, Ioi Lam wrote:
>> - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which
>> allowed the same JDK library to use different version of HotSpot. However,
>> HSX is no longer supported so this API should be removed.
>> - Implementations of APIs such a
On Mon, 1 Feb 2021 20:54:42 GMT, Ioi Lam wrote:
>> src/java.base/share/native/libjava/check_version.c line 33:
>>
>>> 31: DEF_JNI_OnLoad(JavaVM *vm, void *reserved)
>>> 32: {
>>> 33: return JNI_VERSION_1_2;
>>
>> This leaves an entire file with one trivial function implementation. Can we
>
On Mon, 1 Feb 2021 20:10:58 GMT, Ioi Lam wrote:
>> - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which
>> allowed the same JDK library to use different version of HotSpot. However,
>> HSX is no longer supported so this API should be removed.
>> - Implementations of APIs such a
On Mon, 1 Feb 2021 18:31:23 GMT, Gerard Ziemski wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8260616: Removing remaining JNF dependencies in the java.desktop modul
>
> Marked as r
On Fri, 29 Jan 2021 19:53:32 GMT, Phil Race wrote:
>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 83:
>>
>>> 81: stringWithFileSystemRepresentation:chs length:len];
>>> 82: return result;
>>> 83: }
>>
>> Why are we doing:
>>
>> `java_string -> chars -> NS
On Fri, 29 Jan 2021 17:24:05 GMT, Phil Race wrote:
>> This completes the desktop module JNF removal
>>
>> * remove -framework JavaNativeFoundation from make files
>>
>> * remove #import from all
>> source files. If needed add import of JNIUtilities.h to get jni.h
>> definitions - better an
On Fri, 29 Jan 2021 16:57:09 GMT, Gerard Ziemski wrote:
>> This completes the desktop module JNF removal
>>
>> * remove -framework JavaNativeFoundation from make files
>>
>> * remove #import from all
>> source files. If needed add import of JNIUtil
On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race wrote:
> This completes the desktop module JNF removal
>
> * remove -framework JavaNativeFoundation from make files
>
> * remove #import from all
> source files. If needed add import of JNIUtilities.h to get jni.h definitions
> - better anyway si
On Thu, 21 Jan 2021 05:24:09 GMT, David Holmes wrote:
>> We are now confident that we have build-time and runtime support for
>> clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX
>> platforms - see bug report for some more details on different OS.
>> Consequently we can simp
On Tue, 19 Jan 2021 01:53:03 GMT, David Holmes wrote:
>> We are now confident that we have build-time and runtime support for
>> clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX
>> platforms - see bug report for some more details on different OS.
>> Consequently we can simp
Thank you for fixing this.
> On Jun 18, 2018, at 7:36 PM, Martin Buchholz wrote:
>
> 8205197: Never default to using libc++ on Linux
> http://cr.openjdk.java.net/~martin/webrevs/jdk/stlib-default/
> https://bugs.openjdk.java.net/browse/JDK-8205197
>
hi Erik,
Thanks for doing this.
I like how you are using a narrow mechanism to turn off only those warnings
that come up due to deprecated APIs.
Just a quick verification question (not very familiar with the makefiles), in
line like this:
DISABLED_WARNINGS_clang := deprecated-declarations
I
> On Aug 22, 2017, at 9:10 PM, David Holmes wrote:
>
> On 22/08/2017 11:36 PM, Gerard Ziemski wrote:
>> Thank you for the review.
>>> On Aug 21, 2017, at 8:01 AM, Erik Joelsson wrote:
>>>
>>> Build changes look good.
>>>
>>> Don&#
talking about, can you point out the files
you just referred to please?
>
> /Erik
>
>
> On 2017-08-18 23:09, Gerard Ziemski wrote:
>> hi all,
>>
>> The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now it’s the
>> time to remove the co
hi all,
The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now it’s the
time to remove the code and obsolete the -Xprof flag.
issue: https://bugs.openjdk.java.net/browse/JDK-8173715
jdk repo webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev2_repo/
hotspot webrev: h
hi Kim,
I’m withdrawing my objection.
Making this mechanism cover ldflags is beyond the scope of this fix and
deserves its own feature request.
cheers
> On Jun 8, 2017, at 4:21 PM, Gerard Ziemski wrote:
>
> hi Kim,
>
> My understanding is that to enable c++11, for example,
hi Kim,
My understanding is that to enable c++11, for example, we need to do 2 things
(at least on Mac OS X):
#1 For the compilation phase we need to add “-std=c++11 -stdlib=libc++”, where
“-std=c++11” selects the language model, and “-stdlib=libc++” selects the
corresponding headers.
#2 For
Thank you for the review!
> On Feb 1, 2016, at 6:12 AM, Magnus Ihse Bursie
> wrote:
>
> On 2016-01-29 18:04, Erik Joelsson wrote:
>> (adding build-dev)
>>
>> Looks good enough to me.
>
> Looks good to me too.
>
> /Magnus
>
>>
>&g
Thank you for the review!
> On Jan 29, 2016, at 11:04 AM, Erik Joelsson wrote:
>
> (adding build-dev)
>
> Looks good enough to me.
>
> /Erik
>
> On 2016-01-29 17:51, Gerard Ziemski wrote:
>> Hi all (and especially the makefiles experts),
>>
>>
hi Bernhard,
I will have to look into how I can make it available to the open source
code community.
cheers
On 9/4/2014 4:16 PM, Bernhard Urban wrote:
Hi Gerard,
On Thu, Sep 4, 2014 at 6:45 PM, Gerard Ziemski
mailto:gerard.ziem...@oracle.com>> wrote:
For those interested,
what happens?
I was a bit surprised to see a hotspot specific change?
Also - can't you store your favorite IDE project outside of the repository?
thanks,
Karen
On Sep 4, 2014, at 12:45 PM, Gerard Ziemski wrote:
hi all,
Please review a very small fix that makes hotspot build ignore &qu
hi all,
Please review a very small fix that makes hotspot build ignore "ide"
folder, which is where local users can store their own favorite IDE
projects.
For those interested, I have an Xcode project for JDK8 and JDK9 that I
am personally actively supporting and using, which is hosted at
h
hi guys,
I hope this is the right place to ask this question, if not please
suggest where else I could ask it.
Does anyone here have an Xcode project to build Hotspot?
For reference, I have filed
https://jbs.oracle.com/bugs/browse/JDK-8007737 to track this issue.
cheers
59 matches
Mail list logo
