On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev
wrote:
>> Character strings within JVM are produced and consumed in several formats.
>> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
>> or dlopen()) consume strings also in UTF8. On Windows, however, the
>> situa
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 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 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 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 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
Hi all,
Please review this revision 2 of a cleanup, where we remove
JDK_GetVersionInfo0 and related code, since we can get build versions
directly from within the VM itself.
The rev2 differs from rev1 in that it's simpler due to JDK-8234185,
which was just checked in yesterday. Waiting for t
an official review thread tomorrow...
Thanks
Christoph
-Original Message-
From: hotspot-dev On Behalf Of
Mandy Chung
Sent: Mittwoch, 13. November 2019 20:30
To: gerard ziemski
Cc: awt-...@openjdk.java.net; hotspot-dev developers ; core-libs-dev@openjdk.java.net
Subject: Re: RFR (M) 8223
maybe you can hold off
submitting your change until my cleanup is reviewed?
I'll create a bug and post an official review thread tomorrow...
Thanks
Christoph
-Original Message-
From: hotspot-dev On Behalf Of
Mandy Chung
Sent: Mittwoch, 13. November 2019 20:30
To: gerard z
Thank you for the review, will remove the comment and updated the
webrev, but only after Christop Langer gets his fix in - I'm going to
wait for him to check in first.
cheers
On 11/13/19 1:29 PM, Mandy Chung wrote:
On 11/13/19 10:50 AM, gerard ziemski wrote:
Hi all,
Please review
Hi all,
Please review this cleanup, where we remove JDK_GetVersionInfo0 and
related code, since we can get build versions directly from within the
VM itself:
I'm including core-libs and awt in this review because the proposed fix
touches their corresponding files.
bug: https://bugs.openjd
Ping.
> On Aug 24, 2017, at 2:59 AM, David Holmes wrote:
>
> On 24/08/2017 2:20 AM, Gerard Ziemski wrote:
>> Thank you David.
>> Do I need a second reviewer here?
>
> Yes any launcher changes should be signed off by launcher folk - so I've
> directly
Thank you David.
Do I need a second reviewer here?
cheers
> On Aug 22, 2017, at 9:15 PM, David Holmes wrote:
>
> Hi Gerard,
>
> On 23/08/2017 3:41 AM, Gerard Ziemski wrote:
>> hi all,
>> The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now it’s
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
webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev2_jdk/
cheers
hi Harold,
The changes look fine. I have a couple of questions though:
#1 Would the "test/runtime/modules/ModuleOptionsTest.java” be more robust if we
included a case with a non-error return value that takes more than one module?
Ex: “java --add-modules=java.base
--add-modules=jdk.internal.ref
> On Jun 29, 2016, at 6:47 PM, Mandy Chung wrote:
>
>>
>> On Jun 29, 2016, at 12:36 PM, Brent Christian
>> wrote:
>>
>> Hi,
>>
>> Please review the following change for JDK 9:
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8160370
>> Webrev:
>> http://cr.openjdk.java.net/~bchristi/
hi Brent,
Thank you for fixing the original issue and for putting in this follow-up fix!
Looks good! (for full disclosure I proposed the workaround)
cheers
> On Jun 29, 2016, at 2:36 PM, Brent Christian
> wrote:
>
> Hi,
>
> Please review the following change for JDK 9:
>
> Bug:
> https://
view this Mac-only fix:
>
> http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-7131356
>
> Thanks go to Gerard Ziemski for the thorough investigation and detailed
> write-up in the bug report.
>
> The symptoms:
>
&
> On Apr 19, 2016, at 12:04 AM, David Holmes wrote:
>
> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote:
>> Hi Gerard,
>>
>> 2016/04/19 3:14 "Gerard Ziemski" > <mailto:gerard.ziem...@oracle.com>>:
>> >
>> > hi Yasumasa,
&g
hi Yasumasa,
Nice work. I have 2 questions:
File: java.c
#1 Shouldn’t we be checking for “(*env)->ExceptionOccurred(env)” after every
single JNI call? In this example instead of NULL_CHECK, should we be using
CHECK_EXCEPTION_NULL_LEAVE macro?
#2 Should the comment for “SetNativeThrea
> On Feb 1, 2016, at 1:25 PM, Roger Riggs wrote:
>
> Hi Gerard,
>
> On 2/1/2016 1:58 PM, Gerard Ziemski wrote:
>> hi Roger,
>>
>> I love that we are adding this Signal object. I have several questions, but
>> please do not take them as critic
hi Roger,
I love that we are adding this Signal object. I have several questions, but
please do not take them as criticism, I’m just seeking clarification and
providing feedback:
#1 Re: "Consumers for signals that are unknown or reserved by the Java
implementation can not be registered.”
- W
41 matches
Mail list logo
