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
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.
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
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
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
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
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 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't be o
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
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
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
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
>
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
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 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:
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 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 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
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
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
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 |
>>>
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).
The
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 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 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
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 ->
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
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
41 matches
Mail list logo
