From never at openjdk.org  Tue May 16 16:51:45 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 16 May 2023 16:51:45 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err
In-Reply-To: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
Message-ID: <8Wgr4DuTLQIMk2IgF9EV7H1D5kuzxzNNXoF-nJGFv8E=.55faf559-4da0-4c2b-9a06-b1ca000151cd@github.com>

On Tue, 16 May 2023 08:02:11 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
> 
> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
> 
> JVMCI Events (11 events):
> ...
> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
> 
> 
> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
> 
> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
> 
> 
> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe

Marked as reviewed by never (Reviewer).

src/hotspot/share/jvmci/jvmciEnv.cpp line 342:

> 340:     }
> 341:     if (line >= max_lines) {
> 342:       JVMCI_event_1("[elided %d more stack trace lines]", line - max_lines);

You could add this output to the last line instead of burning an extra line.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14000#pullrequestreview-1428988011
PR Review Comment: https://git.openjdk.org/jdk/pull/14000#discussion_r1195429692

From never at openjdk.org  Tue May 16 16:51:48 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 16 May 2023 16:51:48 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err
In-Reply-To: <u5OT4rFH0LmXRBOutYvvyKhph0IlSu5Of00Zfz3RHaA=.4a1a34e6-9d8c-4a96-97e9-ff423990e25e@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
 <u5OT4rFH0LmXRBOutYvvyKhph0IlSu5Of00Zfz3RHaA=.4a1a34e6-9d8c-4a96-97e9-ff423990e25e@github.com>
Message-ID: <2ln_MtqHYewt77jwXAcxlMLqDL6eH3ytFRUKSq1FG-c=.a226b0b4-8ff9-412f-b4a8-aa4ce070d5c5@github.com>

On Tue, 16 May 2023 09:05:25 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
>> 
>> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
>> 
>> JVMCI Events (11 events):
>> ...
>> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
>> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
>> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
>> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
>> 
>> 
>> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
>> 
>> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
>> 
>> 
>> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe
>
> src/hotspot/share/jvmci/jvmciRuntime.cpp line 2047:
> 
>> 2045:                                                                      (jlong) compile_state, compile_state->task()->compile_id());
>> 2046: #ifdef ASSERT
>> 2047:   if (JVMCIENV->has_pending_exception() && JVMCICompileMethodExceptionIsFatal) {
> 
> It's a shame to introduce a VM flag (i.e., `JVMCICompileMethodExceptionIsFatal`) for a test case but I don't know of any other way to do this. As far as I know, system properties cannot be accessed here. Maybe using an environment variable is better than a VM flag?

Why can't you use a JVMCI property for this?  You get a chance to see them when copying them to Graal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14000#discussion_r1195435341

From dnsimon at openjdk.org  Tue May 16 21:26:47 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 16 May 2023 21:26:47 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err
In-Reply-To: <8Wgr4DuTLQIMk2IgF9EV7H1D5kuzxzNNXoF-nJGFv8E=.55faf559-4da0-4c2b-9a06-b1ca000151cd@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
 <8Wgr4DuTLQIMk2IgF9EV7H1D5kuzxzNNXoF-nJGFv8E=.55faf559-4da0-4c2b-9a06-b1ca000151cd@github.com>
Message-ID: <oSAQyvGYQ4BJSuCYzuYdkdQ36UrBYGz4xLT8PVAZ9zY=.b381e499-bf68-49dc-be3b-8f05f45f0af0@github.com>

On Tue, 16 May 2023 16:38:02 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
>> 
>> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
>> 
>> JVMCI Events (11 events):
>> ...
>> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
>> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
>> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
>> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
>> 
>> 
>> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
>> 
>> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
>> 
>> 
>> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe
>
> src/hotspot/share/jvmci/jvmciEnv.cpp line 342:
> 
>> 340:     }
>> 341:     if (line >= max_lines) {
>> 342:       JVMCI_event_1("[elided %d more stack trace lines]", line - max_lines);
> 
> You could add this output to the last line instead of burning an extra line.

Indeed:

Event: 0.237 Thread 0x000000011e019e10 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
Event: 0.237 Thread 0x000000011e019e10 	at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:161) [elided 2 more stack trace lines]

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14000#discussion_r1195700413

From dnsimon at openjdk.org  Tue May 16 21:26:52 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 16 May 2023 21:26:52 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err
In-Reply-To: <2ln_MtqHYewt77jwXAcxlMLqDL6eH3ytFRUKSq1FG-c=.a226b0b4-8ff9-412f-b4a8-aa4ce070d5c5@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
 <u5OT4rFH0LmXRBOutYvvyKhph0IlSu5Of00Zfz3RHaA=.4a1a34e6-9d8c-4a96-97e9-ff423990e25e@github.com>
 <2ln_MtqHYewt77jwXAcxlMLqDL6eH3ytFRUKSq1FG-c=.a226b0b4-8ff9-412f-b4a8-aa4ce070d5c5@github.com>
Message-ID: <F7PkiuERABNj5x-6hbGpypbqFbbInyw9EvlA-H61dB8=.19fbacd3-0eb5-41e4-893a-a07c894f1714@github.com>

On Tue, 16 May 2023 16:43:01 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmciRuntime.cpp line 2047:
>> 
>>> 2045:                                                                      (jlong) compile_state, compile_state->task()->compile_id());
>>> 2046: #ifdef ASSERT
>>> 2047:   if (JVMCIENV->has_pending_exception() && JVMCICompileMethodExceptionIsFatal) {
>> 
>> It's a shame to introduce a VM flag (i.e., `JVMCICompileMethodExceptionIsFatal`) for a test case but I don't know of any other way to do this. As far as I know, system properties cannot be accessed here. Maybe using an environment variable is better than a VM flag?
>
> Why can't you use a JVMCI property for this?  You get a chance to see them when copying them to Graal.

The copying is only done when using libgraal. I'd like to have this test run in a JDK without libgraal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14000#discussion_r1195702132

From dnsimon at openjdk.org  Tue May 16 21:33:50 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 16 May 2023 21:33:50 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err [v2]
In-Reply-To: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
Message-ID: <0xLc58Wa85RKMBStJ-W3xO67Y5rvy24hu9Ggu-dMOMo=.570e69cd-7435-4cc0-ac48-01597e943512@github.com>

> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
> 
> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
> 
> JVMCI Events (11 events):
> ...
> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
> 
> 
> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
> 
> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
> 
> 
> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  append elision comment to end of last stack trace line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14000/files
  - new: https://git.openjdk.org/jdk/pull/14000/files/b1854a6a..9efd3ea6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14000&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14000&range=00-01

  Stats: 13 lines in 1 file changed: 9 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14000/head:pull/14000

PR: https://git.openjdk.org/jdk/pull/14000

From dnsimon at openjdk.org  Tue May 16 22:04:55 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 16 May 2023 22:04:55 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err [v3]
In-Reply-To: <F7PkiuERABNj5x-6hbGpypbqFbbInyw9EvlA-H61dB8=.19fbacd3-0eb5-41e4-893a-a07c894f1714@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
 <u5OT4rFH0LmXRBOutYvvyKhph0IlSu5Of00Zfz3RHaA=.4a1a34e6-9d8c-4a96-97e9-ff423990e25e@github.com>
 <2ln_MtqHYewt77jwXAcxlMLqDL6eH3ytFRUKSq1FG-c=.a226b0b4-8ff9-412f-b4a8-aa4ce070d5c5@github.com>
 <F7PkiuERABNj5x-6hbGpypbqFbbInyw9EvlA-H61dB8=.19fbacd3-0eb5-41e4-893a-a07c894f1714@github.com>
Message-ID: <ld29DU0Qtqkg196XAZXxGrI73_tRV2AEI-wsBbT0cZM=.5f7e8fd9-b6fb-4ea0-bfa8-bb1216909b09@github.com>

On Tue, 16 May 2023 21:24:24 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Why can't you use a JVMCI property for this?  You get a chance to see them when copying them to Graal.
>
> The copying is only done when using libgraal. I'd like to have this test run in a JDK without libgraal.

I see that I can simply use system properties after all: https://github.com/openjdk/jdk/pull/14000/commits/90f4346b3c8737fd0fee25a7ed0c32a1bd506c88

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14000#discussion_r1195727360

From dnsimon at openjdk.org  Tue May 16 22:04:54 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 16 May 2023 22:04:54 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err [v3]
In-Reply-To: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
Message-ID: <9AgB36HtSjwiSZMH3rTs2FolM3LDZeTm0dR-lk3m1FE=.b2b773a7-879b-48e4-80d1-7132c1a2b256@github.com>

> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
> 
> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
> 
> JVMCI Events (11 events):
> ...
> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
> 
> 
> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
> 
> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
> 
> 
> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  replace JVMCICompileMethodExceptionIsFatal VM flag with test.jvmci.compileMethodExceptionIsFatal system property

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14000/files
  - new: https://git.openjdk.org/jdk/pull/14000/files/9efd3ea6..90f4346b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14000&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14000&range=01-02

  Stats: 17 lines in 4 files changed: 4 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14000/head:pull/14000

PR: https://git.openjdk.org/jdk/pull/14000

From never at openjdk.org  Wed May 17 06:33:47 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 17 May 2023 06:33:47 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err [v3]
In-Reply-To: <ld29DU0Qtqkg196XAZXxGrI73_tRV2AEI-wsBbT0cZM=.5f7e8fd9-b6fb-4ea0-bfa8-bb1216909b09@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
 <u5OT4rFH0LmXRBOutYvvyKhph0IlSu5Of00Zfz3RHaA=.4a1a34e6-9d8c-4a96-97e9-ff423990e25e@github.com>
 <2ln_MtqHYewt77jwXAcxlMLqDL6eH3ytFRUKSq1FG-c=.a226b0b4-8ff9-412f-b4a8-aa4ce070d5c5@github.com>
 <F7PkiuERABNj5x-6hbGpypbqFbbInyw9EvlA-H61dB8=.19fbacd3-0eb5-41e4-893a-a07c894f1714@github.com>
 <ld29DU0Qtqkg196XAZXxGrI73_tRV2AEI-wsBbT0cZM=.5f7e8fd9-b6fb-4ea0-bfa8-bb1216909b09@github.com>
Message-ID: <QlVPohkZJfnul_pQFP2Q7HeXJ655P0amLcjyn9dMzlk=.c8d0b0be-0a1e-4862-bd87-689f1d9f1f45@github.com>

On Tue, 16 May 2023 22:00:22 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The copying is only done when using libgraal. I'd like to have this test run in a JDK without libgraal.
>
> I see that I can simply use system properties after all: https://github.com/openjdk/jdk/pull/14000/commits/90f4346b3c8737fd0fee25a7ed0c32a1bd506c88

Yes that looks good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14000#discussion_r1196004966

From coleenp at openjdk.org  Thu May 18 22:45:04 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 May 2023 22:45:04 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
Message-ID: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>

Please review this change to use ByteSize and byte_offset_of() to refer to offsets to metadata and other types that are used in generated code.  This avoids the int narrowing conversion warning for -Wconversion.  There were a couple that I just added an (int) cast instead because these offsets are either being used in other code currently being changed (in oopDesc) or there are too many (like displaced_header_offset_in_bytes) and should be their own change.

This change takes a  chunk out of the -Wconversion warnings - see CR for more info.

It might be easier and less tedious to review the commits separately.  One commit renames blah_offset_in_bytes to blah_offset, since in_bytes(blah_offset()) is typically used (except in Address constructor which has an overload for ByteSize).

Tested with tier1-4, x86 and aarch64, and built linux-x64-zero linux-x64-zero-debug linux-aarch64-debug linux-s390x-open linux-arm32-debug linux-ppc64le-debug linux-riscv64-debug locally.

-------------

Commit messages:
 - Change ObjectMonitor offset to return ByteSize
 - Restore warnings are errors.
 - Rename blah_in_bytes to blah because now the functions return ByteSize which require in_bytes() to get to int.
 - Change offset_of to byte_offset_of returning ByteSize for most cases, or add int cast in the cases where too much code downstream does arithmetic with the offset.

Changes: https://git.openjdk.org/jdk/pull/14053/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14053&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308396
  Stats: 447 lines in 85 files changed: 11 ins; 9 del; 427 mod
  Patch: https://git.openjdk.org/jdk/pull/14053.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14053/head:pull/14053

PR: https://git.openjdk.org/jdk/pull/14053

From amitkumar at openjdk.org  Fri May 19 02:49:59 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 19 May 2023 02:49:59 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
In-Reply-To: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
Message-ID: <z7vC44ATCj4y-uW5CqhCzUeGsMgqMNz2hBCxPaS5G6I=.de593e67-0a51-4c06-88e4-8805b7c4b7ac@github.com>

On Thu, 18 May 2023 22:37:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to use ByteSize and byte_offset_of() to refer to offsets to metadata and other types that are used in generated code.  This avoids the int narrowing conversion warning for -Wconversion.  There were a couple that I just added an (int) cast instead because these offsets are either being used in other code currently being changed (in oopDesc) or there are too many (like displaced_header_offset_in_bytes) and should be their own change.
> 
> This change takes a  chunk out of the -Wconversion warnings - see CR for more info.
> 
> It might be easier and less tedious to review the commits separately.  One commit renames blah_offset_in_bytes to blah_offset, since in_bytes(blah_offset()) is typically used (except in Address constructor which has an overload for ByteSize).
> 
> Tested with tier1-4, x86 and aarch64, and built linux-x64-zero linux-x64-zero-debug linux-aarch64-debug linux-s390x-open linux-arm32-debug linux-ppc64le-debug linux-riscv64-debug locally.

src/hotspot/cpu/s390/sharedRuntime_s390.cpp line 2784:

> 2782: #ifndef VM_LITTLE_ENDIAN
> 2783:   + 3
> 2784: #endif

This is breaking build for s390x. 


/home/amit/jdk/src/hotspot/cpu/s390/sharedRuntime_s390.cpp: In static member function 'static void SharedRuntime::generate_uncommon_trap_blob()':           
/home/amit/jdk/src/hotspot/cpu/s390/sharedRuntime_s390.cpp:2783:3: error: no match for 'operator+' (operand types are 'ByteSize' and 'int')                 
   const int unpack_kind_byte_offset = Deoptimization::UnrollBlock::unpack_kind_offset()                                                                    
                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                    
 #ifndef VM_LITTLE_ENDIAN                                                                                                                                   
 ~~~~~~~~~~~~~~~~~~~~~~~~                                                                                                                                   
   + 3                                                                                                                                                      
   ^~~                                                                                                                                                      
In file included from /home/amit/jdk/src/hotspot/share/utilities/exceptions.hpp:31,                                                                         
                 from /home/amit/jdk/src/hotspot/share/oops/metadata.hpp:28,                                                                                
                 from /home/amit/jdk/src/hotspot/share/oops/oop.hpp:32,                                                                                     
                 from /home/amit/jdk/src/hotspot/share/runtime/handles.hpp:29,
                 from /home/amit/jdk/src/hotspot/share/code/oopRecorder.hpp:28,                                                                            
                 from /home/amit/jdk/src/hotspot/share/asm/codeBuffer.hpp:28,
                 from /home/amit/jdk/src/hotspot/share/asm/assembler.hpp:28,
                 from /home/amit/jdk/src/hotspot/share/asm/macroAssembler.hpp:28,                                                                          
                 from /home/amit/jdk/src/hotspot/share/asm/macroAssembler.inline.hpp:28,                                                                   
                 from /home/amit/jdk/src/hotspot/cpu/s390/sharedRuntime_s390.cpp:27:                                                                       
/home/amit/jdk/src/hotspot/share/utilities/sizes.hpp:53:20: note: candidate: 'constexpr ByteSize operator+(ByteSize, ByteSize)'                            
 constexpr ByteSize operator + (ByteSize x, ByteSize y) { return in_ByteSize(in_bytes(x) + in_bytes(y)); }                                                 
                    ^~~~~~~~
/home/amit/jdk/src/hotspot/share/utilities/sizes.hpp:53:20: note:   no known conversion for argument 2 from 'int' to 'ByteSize'                            
gmake[3]: *** [lib/CompileJvm.gmk:147: /home/amit/jdk/build/linux-s390x-server-fastdebug/hotspot/variant-server/libjvm/objs/sharedRuntime_s390.o] Error 1  
gmake[3]: *** Waiting for unfinished jobs....
gmake[2]: *** [make/Main.gmk:252: hotspot-server-libs] Error 2

ERROR: Build failed for target 'images' in configuration 'linux-s390x-server-fastdebug' (exit code 2)                                                      
Stopping javac server

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14053#discussion_r1198492213

From amitkumar at openjdk.org  Fri May 19 05:01:57 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 19 May 2023 05:01:57 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
In-Reply-To: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
Message-ID: <ys0Zsc4vRxQDPfVAukGTgBPxyA0_fAKKDk_8GQDlqzQ=.6b92385c-2988-408f-a385-843952460816@github.com>

On Thu, 18 May 2023 22:37:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to use ByteSize and byte_offset_of() to refer to offsets to metadata and other types that are used in generated code.  This avoids the int narrowing conversion warning for -Wconversion.  There were a couple that I just added an (int) cast instead because these offsets are either being used in other code currently being changed (in oopDesc) or there are too many (like displaced_header_offset_in_bytes) and should be their own change.
> 
> This change takes a  chunk out of the -Wconversion warnings - see CR for more info.
> 
> It might be easier and less tedious to review the commits separately.  One commit renames blah_offset_in_bytes to blah_offset, since in_bytes(blah_offset()) is typically used (except in Address constructor which has an overload for ByteSize).
> 
> Tested with tier1-4, x86 and aarch64, and built linux-x64-zero linux-x64-zero-debug linux-aarch64-debug linux-s390x-open linux-arm32-debug linux-ppc64le-debug linux-riscv64-debug locally.

Testing for fastdebug build/ tier1 tests looks good on s390x.

I've given my suggestion for fixing the build-break, but I leave that upto you :-)

src/hotspot/cpu/s390/sharedRuntime_s390.cpp line 2781:

> 2779:   assert(Immediate::is_uimm8(Deoptimization::Unpack_LIMIT), "Code not fit for larger immediates");
> 2780:   assert(Immediate::is_uimm8(Deoptimization::Unpack_uncommon_trap), "Code not fit for larger immediates");
> 2781:   const int unpack_kind_byte_offset = Deoptimization::UnrollBlock::unpack_kind_offset()

Suggestion:

  const int unpack_kind_byte_offset = in_bytes(Deoptimization::UnrollBlock::unpack_kind_offset())

-------------

Marked as reviewed by amitkumar (Author).

PR Review: https://git.openjdk.org/jdk/pull/14053#pullrequestreview-1433773874
PR Review Comment: https://git.openjdk.org/jdk/pull/14053#discussion_r1198543159

From coleenp at openjdk.org  Fri May 19 11:55:34 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 May 2023 11:55:34 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
 [v2]
In-Reply-To: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
Message-ID: <U4MeE8064imfq65Wy_k8lNMvNWP_aRjhUrXqlHI5J58=.88bc28f2-9e58-4109-8314-fc87b4bfab11@github.com>

> Please review this change to use ByteSize and byte_offset_of() to refer to offsets to metadata and other types that are used in generated code.  This avoids the int narrowing conversion warning for -Wconversion.  There were a couple that I just added an (int) cast instead because these offsets are either being used in other code currently being changed (in oopDesc) or there are too many (like displaced_header_offset_in_bytes) and should be their own change.
> 
> This change takes a  chunk out of the -Wconversion warnings - see CR for more info.
> 
> It might be easier and less tedious to review the commits separately.  One commit renames blah_offset_in_bytes to blah_offset, since in_bytes(blah_offset()) is typically used (except in Address constructor which has an overload for ByteSize).
> 
> Tested with tier1-4, x86 and aarch64, and built linux-x64-zero linux-x64-zero-debug linux-aarch64-debug linux-s390x-open linux-arm32-debug linux-ppc64le-debug linux-riscv64-debug locally.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix s390

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14053/files
  - new: https://git.openjdk.org/jdk/pull/14053/files/56f2b4ba..f629ebce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14053&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14053&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14053.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14053/head:pull/14053

PR: https://git.openjdk.org/jdk/pull/14053

From coleenp at openjdk.org  Fri May 19 11:55:39 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 May 2023 11:55:39 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
 [v2]
In-Reply-To: <ys0Zsc4vRxQDPfVAukGTgBPxyA0_fAKKDk_8GQDlqzQ=.6b92385c-2988-408f-a385-843952460816@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
 <ys0Zsc4vRxQDPfVAukGTgBPxyA0_fAKKDk_8GQDlqzQ=.6b92385c-2988-408f-a385-843952460816@github.com>
Message-ID: <whPagQGwcyYEhJVvPdJx6ldjDAavPMAZhEuI47fyghY=.68ea1e2c-1f86-42fe-a5f9-d0fba6082709@github.com>

On Fri, 19 May 2023 04:55:30 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix s390
>
> src/hotspot/cpu/s390/sharedRuntime_s390.cpp line 2781:
> 
>> 2779:   assert(Immediate::is_uimm8(Deoptimization::Unpack_LIMIT), "Code not fit for larger immediates");
>> 2780:   assert(Immediate::is_uimm8(Deoptimization::Unpack_uncommon_trap), "Code not fit for larger immediates");
>> 2781:   const int unpack_kind_byte_offset = Deoptimization::UnrollBlock::unpack_kind_offset()
> 
> Suggestion:
> 
>   const int unpack_kind_byte_offset = in_bytes(Deoptimization::UnrollBlock::unpack_kind_offset())

Fixed.

> src/hotspot/cpu/s390/sharedRuntime_s390.cpp line 2784:
> 
>> 2782: #ifndef VM_LITTLE_ENDIAN
>> 2783:   + 3
>> 2784: #endif
> 
> This is breaking build for s390x. 
> 
> 
> /home/amit/jdk/src/hotspot/cpu/s390/sharedRuntime_s390.cpp: In static member function 'static void SharedRuntime::generate_uncommon_trap_blob()':           
> /home/amit/jdk/src/hotspot/cpu/s390/sharedRuntime_s390.cpp:2783:3: error: no match for 'operator+' (operand types are 'ByteSize' and 'int')                 
>    const int unpack_kind_byte_offset = Deoptimization::UnrollBlock::unpack_kind_offset()                                                                    
>                                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                    
>  #ifndef VM_LITTLE_ENDIAN                                                                                                                                   
>  ~~~~~~~~~~~~~~~~~~~~~~~~                                                                                                                                   
>    + 3                                                                                                                                                      
>    ^~~                                                                                                                                                      
> In file included from /home/amit/jdk/src/hotspot/share/utilities/exceptions.hpp:31,                                                                         
>                  from /home/amit/jdk/src/hotspot/share/oops/metadata.hpp:28,                                                                                
>                  from /home/amit/jdk/src/hotspot/share/oops/oop.hpp:32,                                                                                     
>                  from /home/amit/jdk/src/hotspot/share/runtime/handles.hpp:29,
>                  from /home/amit/jdk/src/hotspot/share/code/oopRecorder.hpp:28,                                                                            
>                  from /home/amit/jdk/src/hotspot/share/asm/codeBuffer.hpp:28,
>                  from /home/amit/jdk/src/hotspot/share/asm/assembler.hpp:28,
>                  from /home/amit/jdk/src/hotspot/share/asm/macroAssembler.hpp:28,                                                                          
>                  from /home/amit/jdk/src/hotspot/sha...

I only built product so have now adjusted my cross builds to include debug for s390.   Thank you for testing s390!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14053#discussion_r1198871600
PR Review Comment: https://git.openjdk.org/jdk/pull/14053#discussion_r1198872670

From jsjolen at openjdk.org  Fri May 19 12:39:55 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 19 May 2023 12:39:55 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
 [v2]
In-Reply-To: <U4MeE8064imfq65Wy_k8lNMvNWP_aRjhUrXqlHI5J58=.88bc28f2-9e58-4109-8314-fc87b4bfab11@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
 <U4MeE8064imfq65Wy_k8lNMvNWP_aRjhUrXqlHI5J58=.88bc28f2-9e58-4109-8314-fc87b4bfab11@github.com>
Message-ID: <xtQi-LjaYSDFVI9OSv8WukKX3gq9kGe3o6J0Wuk4lB4=.dc44e78b-e631-4c03-96f5-54315710b455@github.com>

On Fri, 19 May 2023 11:55:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to use ByteSize and byte_offset_of() to refer to offsets to metadata and other types that are used in generated code.  This avoids the int narrowing conversion warning for -Wconversion.  There were a couple that I just added an (int) cast instead because these offsets are either being used in other code currently being changed (in oopDesc) or there are too many (like displaced_header_offset_in_bytes) and should be their own change.
>> 
>> This change takes a  chunk out of the -Wconversion warnings - see CR for more info.
>> 
>> It might be easier and less tedious to review the commits separately.  One commit renames blah_offset_in_bytes to blah_offset, since in_bytes(blah_offset()) is typically used (except in Address constructor which has an overload for ByteSize).
>> 
>> Tested with tier1-4, x86 and aarch64, and built linux-x64-zero linux-x64-zero-debug linux-aarch64-debug linux-s390x-open linux-arm32-debug linux-ppc64le-debug linux-riscv64-debug locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix s390

Hi,

This looks good to me, with one small nit.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4313:

> 4311:   ldr(holder, Address(method, Method::const_offset()));                      // ConstMethod*
> 4312:   ldr(holder, Address(holder, ConstMethod::constants_offset()));             // ConstantPool*
> 4313:   ldr(holder, Address(holder, ConstantPool::pool_holder_offset())); // InstanceKlass*

Nit: Alignment.

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14053#pullrequestreview-1434344338
PR Review Comment: https://git.openjdk.org/jdk/pull/14053#discussion_r1198908937

From coleenp at openjdk.org  Fri May 19 12:47:02 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 May 2023 12:47:02 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
 [v3]
In-Reply-To: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
Message-ID: <gxhsmLEevCupepcSMnSWchhlv2nLBVuz8zpA5jgSTlM=.1695fc45-5230-4a0d-ac7a-3aca68719560@github.com>

> Please review this change to use ByteSize and byte_offset_of() to refer to offsets to metadata and other types that are used in generated code.  This avoids the int narrowing conversion warning for -Wconversion.  There were a couple that I just added an (int) cast instead because these offsets are either being used in other code currently being changed (in oopDesc) or there are too many (like displaced_header_offset_in_bytes) and should be their own change.
> 
> This change takes a  chunk out of the -Wconversion warnings - see CR for more info.
> 
> It might be easier and less tedious to review the commits separately.  One commit renames blah_offset_in_bytes to blah_offset, since in_bytes(blah_offset()) is typically used (except in Address constructor which has an overload for ByteSize).
> 
> Tested with tier1-4, x86 and aarch64, and built linux-x64-zero linux-x64-zero-debug linux-aarch64-debug linux-s390x-open linux-arm32-debug linux-ppc64le-debug linux-riscv64-debug locally.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14053/files
  - new: https://git.openjdk.org/jdk/pull/14053/files/f629ebce..90f9544b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14053&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14053&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14053.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14053/head:pull/14053

PR: https://git.openjdk.org/jdk/pull/14053

From coleenp at openjdk.org  Fri May 19 12:47:03 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 May 2023 12:47:03 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
 [v2]
In-Reply-To: <xtQi-LjaYSDFVI9OSv8WukKX3gq9kGe3o6J0Wuk4lB4=.dc44e78b-e631-4c03-96f5-54315710b455@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
 <U4MeE8064imfq65Wy_k8lNMvNWP_aRjhUrXqlHI5J58=.88bc28f2-9e58-4109-8314-fc87b4bfab11@github.com>
 <xtQi-LjaYSDFVI9OSv8WukKX3gq9kGe3o6J0Wuk4lB4=.dc44e78b-e631-4c03-96f5-54315710b455@github.com>
Message-ID: <s1ew07BXqgHkszy2k2qJbP0S7N0xiX_uQ6S8eSi3-aw=.f284bc0c-58b4-4313-84dd-c2f5a7d43e9d@github.com>

On Fri, 19 May 2023 12:34:21 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix s390
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4313:
> 
>> 4311:   ldr(holder, Address(method, Method::const_offset()));                      // ConstMethod*
>> 4312:   ldr(holder, Address(holder, ConstMethod::constants_offset()));             // ConstantPool*
>> 4313:   ldr(holder, Address(holder, ConstantPool::pool_holder_offset())); // InstanceKlass*
> 
> Nit: Alignment.

Thanks for reviewing!  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14053#discussion_r1198915009

From coleenp at openjdk.org  Fri May 19 12:49:35 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 May 2023 12:49:35 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
 [v4]
In-Reply-To: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
Message-ID: <zqqXMk4-5FRaxgaX5HrgO2zVeWFTDy6OkVxm1nFVSig=.bc17d283-176b-4d78-8269-fcde28fd01f1@github.com>

> Please review this change to use ByteSize and byte_offset_of() to refer to offsets to metadata and other types that are used in generated code.  This avoids the int narrowing conversion warning for -Wconversion.  There were a couple that I just added an (int) cast instead because these offsets are either being used in other code currently being changed (in oopDesc) or there are too many (like displaced_header_offset_in_bytes) and should be their own change.
> 
> This change takes a  chunk out of the -Wconversion warnings - see CR for more info.
> 
> It might be easier and less tedious to review the commits separately.  One commit renames blah_offset_in_bytes to blah_offset, since in_bytes(blah_offset()) is typically used (except in Address constructor which has an overload for ByteSize).
> 
> Tested with tier1-4, x86 and aarch64, and built linux-x64-zero linux-x64-zero-debug linux-aarch64-debug linux-s390x-open linux-arm32-debug linux-ppc64le-debug linux-riscv64-debug locally.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14053/files
  - new: https://git.openjdk.org/jdk/pull/14053/files/90f9544b..1f78a6fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14053&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14053&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14053.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14053/head:pull/14053

PR: https://git.openjdk.org/jdk/pull/14053

From amitkumar at openjdk.org  Fri May 19 14:30:53 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 19 May 2023 14:30:53 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
 [v4]
In-Reply-To: <whPagQGwcyYEhJVvPdJx6ldjDAavPMAZhEuI47fyghY=.68ea1e2c-1f86-42fe-a5f9-d0fba6082709@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
 <ys0Zsc4vRxQDPfVAukGTgBPxyA0_fAKKDk_8GQDlqzQ=.6b92385c-2988-408f-a385-843952460816@github.com>
 <whPagQGwcyYEhJVvPdJx6ldjDAavPMAZhEuI47fyghY=.68ea1e2c-1f86-42fe-a5f9-d0fba6082709@github.com>
Message-ID: <7qARwbxWMlkAuSLCvjz50X8YY9Ej9_OhEgI0L_A7CjM=.1b5dfff6-6cc7-4661-8ae1-1446b29c2490@github.com>

On Fri, 19 May 2023 11:49:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/s390/sharedRuntime_s390.cpp line 2784:
>> 
>>> 2782: #ifndef VM_LITTLE_ENDIAN
>>> 2783:   + 3
>>> 2784: #endif
>> 
>> This is breaking build for s390x. 
>> 
>> 
>> /home/amit/jdk/src/hotspot/cpu/s390/sharedRuntime_s390.cpp: In static member function 'static void SharedRuntime::generate_uncommon_trap_blob()':           
>> /home/amit/jdk/src/hotspot/cpu/s390/sharedRuntime_s390.cpp:2783:3: error: no match for 'operator+' (operand types are 'ByteSize' and 'int')                 
>>    const int unpack_kind_byte_offset = Deoptimization::UnrollBlock::unpack_kind_offset()                                                                    
>>                                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                    
>>  #ifndef VM_LITTLE_ENDIAN                                                                                                                                   
>>  ~~~~~~~~~~~~~~~~~~~~~~~~                                                                                                                                   
>>    + 3                                                                                                                                                      
>>    ^~~                                                                                                                                                      
>> In file included from /home/amit/jdk/src/hotspot/share/utilities/exceptions.hpp:31,                                                                         
>>                  from /home/amit/jdk/src/hotspot/share/oops/metadata.hpp:28,                                                                                
>>                  from /home/amit/jdk/src/hotspot/share/oops/oop.hpp:32,                                                                                     
>>                  from /home/amit/jdk/src/hotspot/share/runtime/handles.hpp:29,
>>                  from /home/amit/jdk/src/hotspot/share/code/oopRecorder.hpp:28,                                                                            
>>                  from /home/amit/jdk/src/hotspot/share/asm/codeBuffer.hpp:28,
>>                  from /home/amit/jdk/src/hotspot/share/asm/assembler.hpp:28,
>>                  from /home/amit/jdk/src/hotspot/share/asm/macroAssembler.hpp:28,                                                                          
>>                  from ...
>
> I only built product so have now adjusted my cross builds to include debug for s390.   Thank you for testing s390!

oh, Got it. 

BTW thanks for considering suggestion & for this change as well ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14053#discussion_r1199029787

From fparain at openjdk.org  Fri May 19 15:11:53 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 19 May 2023 15:11:53 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
 [v4]
In-Reply-To: <zqqXMk4-5FRaxgaX5HrgO2zVeWFTDy6OkVxm1nFVSig=.bc17d283-176b-4d78-8269-fcde28fd01f1@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
 <zqqXMk4-5FRaxgaX5HrgO2zVeWFTDy6OkVxm1nFVSig=.bc17d283-176b-4d78-8269-fcde28fd01f1@github.com>
Message-ID: <TYpRsvaAWmn67YHZjg88spFmeOzwhVgHcxWk1itQlD4=.819690e8-f6b5-49c4-88b8-53b61238daf2@github.com>

On Fri, 19 May 2023 12:49:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to use ByteSize and byte_offset_of() to refer to offsets to metadata and other types that are used in generated code.  This avoids the int narrowing conversion warning for -Wconversion.  There were a couple that I just added an (int) cast instead because these offsets are either being used in other code currently being changed (in oopDesc) or there are too many (like displaced_header_offset_in_bytes) and should be their own change.
>> 
>> This change takes a  chunk out of the -Wconversion warnings - see CR for more info.
>> 
>> It might be easier and less tedious to review the commits separately.  One commit renames blah_offset_in_bytes to blah_offset, since in_bytes(blah_offset()) is typically used (except in Address constructor which has an overload for ByteSize).
>> 
>> Tested with tier1-4, x86 and aarch64, and built linux-x64-zero linux-x64-zero-debug linux-aarch64-debug linux-s390x-open linux-arm32-debug linux-ppc64le-debug linux-riscv64-debug locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Looks good to me, only a few comments on the style.

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2741:

> 2739:   // Current thread already owns the lock. Just increment recursions.
> 2740:   Register recursions = displaced_header;
> 2741:   ld(recursions, in_bytes(ObjectMonitor::recursions_offset()-ObjectMonitor::owner_offset()), temp);

Minus sign should be surrounded by spaces.

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2743:

> 2741:   ld(recursions, in_bytes(ObjectMonitor::recursions_offset()-ObjectMonitor::owner_offset()), temp);
> 2742:   addi(recursions, recursions, 1);
> 2743:   std(recursions, in_bytes(ObjectMonitor::recursions_offset()-ObjectMonitor::owner_offset()), temp);

Minus sign should be surrounded by spaces.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5119:

> 5117:   movptr(holder, Address(method, Method::const_offset()));                      // ConstMethod*
> 5118:   movptr(holder, Address(holder, ConstMethod::constants_offset()));             // ConstantPool*
> 5119:   movptr(holder, Address(holder, ConstantPool::pool_holder_offset())); // InstanceKlass*

Comment could be aligned with the comment of the line above.

-------------

Marked as reviewed by fparain (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14053#pullrequestreview-1434536063
PR Review Comment: https://git.openjdk.org/jdk/pull/14053#discussion_r1199029302
PR Review Comment: https://git.openjdk.org/jdk/pull/14053#discussion_r1199029485
PR Review Comment: https://git.openjdk.org/jdk/pull/14053#discussion_r1199052897

From coleenp at openjdk.org  Fri May 19 15:54:09 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 May 2023 15:54:09 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
 [v5]
In-Reply-To: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
Message-ID: <UxrjSWXLISuaHvEJENrSXY81lvXdDkILl8NKRJb1zHA=.6c492fd0-d00a-4de3-b7f8-aff9f362bfa7@github.com>

> Please review this change to use ByteSize and byte_offset_of() to refer to offsets to metadata and other types that are used in generated code.  This avoids the int narrowing conversion warning for -Wconversion.  There were a couple that I just added an (int) cast instead because these offsets are either being used in other code currently being changed (in oopDesc) or there are too many (like displaced_header_offset_in_bytes) and should be their own change.
> 
> This change takes a  chunk out of the -Wconversion warnings - see CR for more info.
> 
> It might be easier and less tedious to review the commits separately.  One commit renames blah_offset_in_bytes to blah_offset, since in_bytes(blah_offset()) is typically used (except in Address constructor which has an overload for ByteSize).
> 
> Tested with tier1-4, x86 and aarch64, and built linux-x64-zero linux-x64-zero-debug linux-aarch64-debug linux-s390x-open linux-arm32-debug linux-ppc64le-debug linux-riscv64-debug locally.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix more indentation and fparain comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14053/files
  - new: https://git.openjdk.org/jdk/pull/14053/files/1f78a6fe..7736bb96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14053&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14053&range=03-04

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14053.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14053/head:pull/14053

PR: https://git.openjdk.org/jdk/pull/14053

From coleenp at openjdk.org  Fri May 19 15:54:12 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 May 2023 15:54:12 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
 [v4]
In-Reply-To: <TYpRsvaAWmn67YHZjg88spFmeOzwhVgHcxWk1itQlD4=.819690e8-f6b5-49c4-88b8-53b61238daf2@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
 <zqqXMk4-5FRaxgaX5HrgO2zVeWFTDy6OkVxm1nFVSig=.bc17d283-176b-4d78-8269-fcde28fd01f1@github.com>
 <TYpRsvaAWmn67YHZjg88spFmeOzwhVgHcxWk1itQlD4=.819690e8-f6b5-49c4-88b8-53b61238daf2@github.com>
Message-ID: <sqCGDNUU10E8mBa8w8XKMYm0DvorWQqT0E0MS5zW6k4=.0a94da8f-0f0e-4631-a2a8-91de3dbbcce5@github.com>

On Fri, 19 May 2023 14:48:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indentation
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5119:
> 
>> 5117:   movptr(holder, Address(method, Method::const_offset()));                      // ConstMethod*
>> 5118:   movptr(holder, Address(holder, ConstMethod::constants_offset()));             // ConstantPool*
>> 5119:   movptr(holder, Address(holder, ConstantPool::pool_holder_offset())); // InstanceKlass*
> 
> Comment could be aligned with the comment of the line above.

Thanks - I fixed one but not two others that were  no longer aligned.  Now fixed, with these other changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14053#discussion_r1199114713

From coleenp at openjdk.org  Fri May 19 17:20:02 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 May 2023 17:20:02 GMT
Subject: RFR: 8308396: Fix offset_of conversion warnings in runtime code
 [v5]
In-Reply-To: <UxrjSWXLISuaHvEJENrSXY81lvXdDkILl8NKRJb1zHA=.6c492fd0-d00a-4de3-b7f8-aff9f362bfa7@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
 <UxrjSWXLISuaHvEJENrSXY81lvXdDkILl8NKRJb1zHA=.6c492fd0-d00a-4de3-b7f8-aff9f362bfa7@github.com>
Message-ID: <d0FS-cuEdhCBSsMrcRVAytnum33AwLF6XdtdPfD6RpM=.0581060c-0e5f-4e2a-99fb-b90c085f8741@github.com>

On Fri, 19 May 2023 15:54:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to use ByteSize and byte_offset_of() to refer to offsets to metadata and other types that are used in generated code.  This avoids the int narrowing conversion warning for -Wconversion.  There were a couple that I just added an (int) cast instead because these offsets are either being used in other code currently being changed (in oopDesc) or there are too many (like displaced_header_offset_in_bytes) and should be their own change.
>> 
>> This change takes a  chunk out of the -Wconversion warnings - see CR for more info.
>> 
>> It might be easier and less tedious to review the commits separately.  One commit renames blah_offset_in_bytes to blah_offset, since in_bytes(blah_offset()) is typically used (except in Address constructor which has an overload for ByteSize).
>> 
>> Tested with tier1-4, x86 and aarch64, and built linux-x64-zero linux-x64-zero-debug linux-aarch64-debug linux-s390x-open linux-arm32-debug linux-ppc64le-debug linux-riscv64-debug locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix more indentation and fparain comments.

Thank you for reviewing Amit, Johan and Fred.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14053#issuecomment-1554992892

From coleenp at openjdk.org  Fri May 19 17:20:03 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 May 2023 17:20:03 GMT
Subject: Integrated: 8308396: Fix offset_of conversion warnings in runtime code
In-Reply-To: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
References: <PO6ab91kERTe7b47eABs9wNSN_Yloyk68_OZqakRv9g=.78dc0400-7726-4e9a-919a-099cc0157cc9@github.com>
Message-ID: <D0mW8s8sAvNJ8GcJVJMSbPPFIGnE3gN3y5uhZAFClPk=.389ab91f-6b18-4229-90c3-38fd9d069b4a@github.com>

On Thu, 18 May 2023 22:37:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to use ByteSize and byte_offset_of() to refer to offsets to metadata and other types that are used in generated code.  This avoids the int narrowing conversion warning for -Wconversion.  There were a couple that I just added an (int) cast instead because these offsets are either being used in other code currently being changed (in oopDesc) or there are too many (like displaced_header_offset_in_bytes) and should be their own change.
> 
> This change takes a  chunk out of the -Wconversion warnings - see CR for more info.
> 
> It might be easier and less tedious to review the commits separately.  One commit renames blah_offset_in_bytes to blah_offset, since in_bytes(blah_offset()) is typically used (except in Address constructor which has an overload for ByteSize).
> 
> Tested with tier1-4, x86 and aarch64, and built linux-x64-zero linux-x64-zero-debug linux-aarch64-debug linux-s390x-open linux-arm32-debug linux-ppc64le-debug linux-riscv64-debug locally.

This pull request has now been integrated.

Changeset: 265f40b4
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/265f40b4f70102c37bf28b2bf9dda16b92d1d975
Stats:     447 lines in 85 files changed: 11 ins; 9 del; 427 mod

8308396: Fix offset_of conversion warnings in runtime code

Reviewed-by: amitkumar, jsjolen, fparain

-------------

PR: https://git.openjdk.org/jdk/pull/14053

From dnsimon at openjdk.org  Mon May 22 12:26:54 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 22 May 2023 12:26:54 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err [v3]
In-Reply-To: <9AgB36HtSjwiSZMH3rTs2FolM3LDZeTm0dR-lk3m1FE=.b2b773a7-879b-48e4-80d1-7132c1a2b256@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
 <9AgB36HtSjwiSZMH3rTs2FolM3LDZeTm0dR-lk3m1FE=.b2b773a7-879b-48e4-80d1-7132c1a2b256@github.com>
Message-ID: <jTXF0xcEy7ytFNxR44kCt1-lt3yknrz7AvO5DvdHH6U=.b9bb19e2-54ac-423f-92e3-8df8acecc2b5@github.com>

On Tue, 16 May 2023 22:04:54 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
>> 
>> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
>> 
>> JVMCI Events (11 events):
>> ...
>> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
>> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
>> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
>> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
>> 
>> 
>> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
>> 
>> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
>> 
>> 
>> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace JVMCICompileMethodExceptionIsFatal VM flag with test.jvmci.compileMethodExceptionIsFatal system property

src/hotspot/share/jvmci/jvmciRuntime.cpp line 2048:

> 2046:                                                                      (jlong) compile_state, compile_state->task()->compile_id());
> 2047:   if (JVMCIENV->has_pending_exception()) {
> 2048:     const char* val = Arguments::PropertyList_get_value(Arguments::system_properties(), "test.jvmci.compileMethodExceptionIsFatal");

Note that this view on system properties is restricted to properties set at VM startup (e.g. on the command line) and will not see the result of calls to `System.setProperty()` made by an application.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14000#discussion_r1200441783

From dnsimon at openjdk.org  Tue May 23 08:46:52 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 23 May 2023 08:46:52 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err [v4]
In-Reply-To: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
Message-ID: <VuxXC-CquuMsjgjvwPu50fqXDelOwUB10_JxlTaUae8=.0df686a5-e570-4fe9-8949-ed8249498d29@github.com>

> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
> 
> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
> 
> JVMCI Events (11 events):
> ...
> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
> 
> 
> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
> 
> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
> 
> 
> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe

Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8308151
 - replace JVMCICompileMethodExceptionIsFatal VM flag with test.jvmci.compileMethodExceptionIsFatal system property
 - append elision comment to end of last stack trace line
 - send JVMCI exception info to hs-err log and/or tty
 - remove unused callToString method
 - make JMCI more robust in low resource conditions

-------------

Changes: https://git.openjdk.org/jdk/pull/14000/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14000&range=03
  Stats: 404 lines in 11 files changed: 341 ins; 31 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/14000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14000/head:pull/14000

PR: https://git.openjdk.org/jdk/pull/14000

From dnsimon at openjdk.org  Tue May 23 15:13:55 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 23 May 2023 15:13:55 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err [v5]
In-Reply-To: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
Message-ID: <C_qVm7tJf9asqtMkiZZXj61fok0Mp-GEogJtpPpgSEY=.668bc6fc-1565-4159-b1d4-f6e0ba35a509@github.com>

> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
> 
> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
> 
> JVMCI Events (11 events):
> ...
> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
> 
> 
> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
> 
> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
> 
> 
> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  [skip ci] make TestUncaughtErrorInCompileMethod more robust

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14000/files
  - new: https://git.openjdk.org/jdk/pull/14000/files/fb50cbbe..fe2ca698

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14000&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14000&range=03-04

  Stats: 32 lines in 4 files changed: 21 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14000/head:pull/14000

PR: https://git.openjdk.org/jdk/pull/14000

From dnsimon at openjdk.org  Tue May 23 15:39:44 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 23 May 2023 15:39:44 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err [v6]
In-Reply-To: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
Message-ID: <vWQ9G9D4myZr4U7yE5T7OrZPTtwloFXLYwP-6JGQieY=.f705330b-4f1e-47d1-a0c2-fb2c003487db@github.com>

> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
> 
> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
> 
> JVMCI Events (11 events):
> ...
> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
> 
> 
> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
> 
> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
> 
> 
> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe

Doug Simon 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 new commit since the last revision:

  [skip ci] make TestUncaughtErrorInCompileMethod more robust

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14000/files
  - new: https://git.openjdk.org/jdk/pull/14000/files/fe2ca698..0471e7c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14000&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14000&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14000/head:pull/14000

PR: https://git.openjdk.org/jdk/pull/14000

From never at openjdk.org  Wed May 24 06:58:58 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 24 May 2023 06:58:58 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err [v6]
In-Reply-To: <vWQ9G9D4myZr4U7yE5T7OrZPTtwloFXLYwP-6JGQieY=.f705330b-4f1e-47d1-a0c2-fb2c003487db@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
 <vWQ9G9D4myZr4U7yE5T7OrZPTtwloFXLYwP-6JGQieY=.f705330b-4f1e-47d1-a0c2-fb2c003487db@github.com>
Message-ID: <0pFHulKR_iivOKeNxbX6aIrljWkUWXWAP2CTVrZ0Krs=.fc9dc852-7f05-4788-a263-af64ac7cbaf9@github.com>

On Tue, 23 May 2023 15:39:44 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
>> 
>> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
>> 
>> JVMCI Events (11 events):
>> ...
>> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
>> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
>> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
>> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
>> 
>> 
>> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
>> 
>> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
>> 
>> 
>> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe
>
> Doug Simon 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 new commit since the last revision:
> 
>   [skip ci] make TestUncaughtErrorInCompileMethod more robust

The latest version looks ok to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14000#issuecomment-1560552464

From dnsimon at openjdk.org  Wed May 24 07:18:07 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 24 May 2023 07:18:07 GMT
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err [v6]
In-Reply-To: <vWQ9G9D4myZr4U7yE5T7OrZPTtwloFXLYwP-6JGQieY=.f705330b-4f1e-47d1-a0c2-fb2c003487db@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
 <vWQ9G9D4myZr4U7yE5T7OrZPTtwloFXLYwP-6JGQieY=.f705330b-4f1e-47d1-a0c2-fb2c003487db@github.com>
Message-ID: <uQ0CVtZ74Tms7wsrEyKpxrc_pf1pOuo6G3P3vuHYtFk=.91e81288-7631-4703-90d3-4eba9b2463a0@github.com>

On Tue, 23 May 2023 15:39:44 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
>> 
>> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
>> 
>> JVMCI Events (11 events):
>> ...
>> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
>> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
>> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
>> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
>> 
>> 
>> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
>> 
>> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
>> 
>> 
>> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe
>
> Doug Simon 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 new commit since the last revision:
> 
>   [skip ci] make TestUncaughtErrorInCompileMethod more robust

Thanks Tom for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14000#issuecomment-1560574273

From dnsimon at openjdk.org  Wed May 24 07:18:09 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 24 May 2023 07:18:09 GMT
Subject: Integrated: 8308151: [JVMCI] capture JVMCI exceptions in hs-err
In-Reply-To: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
Message-ID: <LDPSxVTTd3wkmG7lGE_xalFYOqha_r0dqj47zNdhqRc=.f75b1ca3-27b9-460a-a847-ba61dfe721cd@github.com>

On Tue, 16 May 2023 08:02:11 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
> 
> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
> 
> JVMCI Events (11 events):
> ...
> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
> 
> 
> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
> 
> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
> 
> 
> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe

This pull request has now been integrated.

Changeset: 05c095cf
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05c095cf39447d8becb3094c38c84a2c0853112b
Stats:     427 lines in 12 files changed: 362 ins; 32 del; 33 mod

8308151: [JVMCI] capture JVMCI exceptions in hs-err

Reviewed-by: never

-------------

PR: https://git.openjdk.org/jdk/pull/14000

From jsjolen at openjdk.org  Mon May 29 11:02:40 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 29 May 2023 11:02:40 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code
In-Reply-To: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
Message-ID: <hMxviuuUN_qpfFue6unPDKaBFkFUdfUKF0Qf_FBJnHs=.8e1061bf-15da-42ab-8b0e-9c2ee44f536a@github.com>

On Mon, 29 May 2023 10:09:15 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.

All of the stuff to actually keep.

src/hotspot/cpu/aarch64/jvmciCodeInstaller_aarch64.cpp line 125:

> 123: 
> 124: void CodeInstaller::pd_relocate_JavaMethod(CodeBuffer &cbuf, methodHandle& method, jint pc_offset, JVMCI_TRAPS) {
> 125:   NativeCall* call = nullptr;

T

src/hotspot/cpu/aarch64/jvmciCodeInstaller_aarch64.cpp line 158:

> 156:     // Check for proper post_call_nop
> 157:     NativePostCallNop* nop = nativePostCallNop_at(call->next_instruction_address());
> 158:     if (nop == nullptr) {

T

src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 2297:

> 2295:   __ ld_ptr(method, array_base_offset + in_bytes(ResolvedIndyEntry::method_offset()), cache);
> 2296: 
> 2297:   // The invokedynamic is unresolved iff method is null

T

src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 374:

> 372:   // Make sure klass is 'reasonable', which is not zero.
> 373:   __ load_klass(obj, obj, tmp1); // get klass
> 374:   __ beqz(obj, error);           // if klass is null it is broken

T

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4019:

> 4017:     StubRoutines::_forward_exception_entry = generate_forward_exception();
> 4018: 
> 4019:     if (UnsafeCopyMemory::_table == nullptr) {

T

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4077:

> 4075: 
> 4076:     BarrierSetNMethod* bs_nm = BarrierSet::barrier_set()->barrier_set_nmethod();
> 4077:     if (bs_nm != nullptr) {

T

src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp line 489:

> 487:   __ load_klass(obj, obj, tmp1);  // get klass
> 488:   __ testptr(obj, obj);
> 489:   __ jcc(Assembler::zero, error); // if klass is null it is broken

T

src/hotspot/cpu/x86/interp_masm_x86.cpp line 303:

> 301:     jcc(Assembler::equal, L);
> 302:     stop("InterpreterMacroAssembler::call_VM_base:"
> 303:          " last_sp != null");

T

src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp line 191:

> 189:     // Check for proper post_call_nop
> 190:     NativePostCallNop* nop = nativePostCallNop_at(call->next_instruction_address());
> 191:     if (nop == nullptr) {

T

src/hotspot/share/adlc/output_c.cpp line 279:

> 277:   int max_stage = 0;
> 278:   i = 0;
> 279:   for (pipeline->_reslist.reset(); (resource = pipeline->_reslist.iter()) != nullptr;) {

T

src/hotspot/share/adlc/output_c.cpp line 305:

> 303:   templen = 0;
> 304:   i = 0;
> 305:   for (pipeline->_reslist.reset(); (resource = pipeline->_reslist.iter()) != nullptr;) {

T

src/hotspot/share/adlc/output_c.cpp line 368:

> 366:   const char* resource;
> 367:   i = 0;
> 368:   for (pipeline->_reslist.reset(); (resource = pipeline->_reslist.iter()) != nullptr;) {

T

src/hotspot/share/adlc/output_c.cpp line 393:

> 391: 
> 392:   i = 0;
> 393:   for (pipeline->_reslist.reset(); (resource = pipeline->_reslist.iter()) != nullptr;) {

T

src/hotspot/share/adlc/output_c.cpp line 1009:

> 1007:   const char* resource;
> 1008:   i = 0;
> 1009:   for (_pipeline->_reslist.reset(); (resource = _pipeline->_reslist.iter()) != nullptr;) {

T

src/hotspot/share/cds/filemap.cpp line 363:

> 361: 
> 362: void SharedClassPathEntry::copy_from(SharedClassPathEntry* ent, ClassLoaderData* loader_data, TRAPS) {
> 363:   assert(ent != nullptr, "sanity");

T

src/hotspot/share/classfile/stringTable.hpp line 150:

> 148:   static size_t shared_entry_count() NOT_CDS_JAVA_HEAP_RETURN_(0);
> 149:   static void allocate_shared_strings_array(TRAPS) NOT_CDS_JAVA_HEAP_RETURN;
> 150:   static oop init_shared_table(const DumpedInternedStrings* dumped_interned_strings) NOT_CDS_JAVA_HEAP_RETURN_(nullptr);

T

src/hotspot/share/code/compiledIC.hpp line 93:

> 91:   CompiledICHolder*    claim_cached_icholder() {
> 92:     assert(_is_icholder, "");
> 93:     assert(_cached_value != nullptr, "must be non-null");

T

src/hotspot/share/code/compiledIC.hpp line 342:

> 340:   // Code
> 341: 
> 342:   // Returns null if CodeBuffer::expand fails

T

src/hotspot/share/compiler/compileBroker.cpp line 388:

> 386: 
> 387:   MonitorLocker locker(MethodCompileQueue_lock);
> 388:   // If _first is null we have no more compile jobs. There are two reasons for

T

src/hotspot/share/gc/x/xBarrier.cpp line 242:

> 240: oop XBarrier::weak_load_barrier_on_oop_field_preloaded(volatile narrowOop* p, oop o) {
> 241:   ShouldNotReachHere();
> 242:   return nullptr;

T

src/hotspot/share/gc/x/xBarrierSet.inline.hpp line 187:

> 185:     // No check cast, bulk barrier and bulk copy
> 186:     XBarrier::load_barrier_on_oop_array(src, length);
> 187:     return Raw::oop_arraycopy_in_heap(nullptr, 0, src, nullptr, 0, dst, length);

T

src/hotspot/share/gc/x/xPageTable.inline.hpp line 43:

> 41: inline bool XPageTableIterator::next(XPage** page) {
> 42:   for (XPage* entry; _iter.next(&entry);) {
> 43:     if (entry != nullptr && entry != _prev) {

T

src/hotspot/share/gc/z/zHeap.cpp line 383:

> 381: 
> 382:   if (addr == zaddress::null) {
> 383:     st->print_raw_cr("null");

T

src/hotspot/share/gc/z/zHeap.cpp line 438:

> 436: 
> 437:   if (addr == zaddress::null) {
> 438:     st->print_raw_cr("null");

T

src/hotspot/share/interpreter/linkResolver.cpp line 816:

> 814:   st->print("%s%s, compile-time-class:%s, method:%s, method_holder:%s, access_flags: ",
> 815:             prefix,
> 816:             (klass == nullptr ? "<null>" : klass->internal_name()),

T

src/hotspot/share/jfr/dcmd/jfrDcmds.hpp line 162:

> 160:   }
> 161:   static const JavaPermission permission() {
> 162:     JavaPermission p = {"java.lang.management.ManagementPermission", "monitor", nullptr};

T

src/hotspot/share/jfr/dcmd/jfrDcmds.hpp line 187:

> 185:   }
> 186:   static const JavaPermission permission() {
> 187:     JavaPermission p = {"java.lang.management.ManagementPermission", "monitor", nullptr};

T

src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp line 125:

> 123:     }
> 124:   }
> 125:   assert(name_str != nullptr, "unexpected null thread name");

T

src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp line 147:

> 145:   const char* const canonical_chunk_path = JfrJavaSupport::c_str(path, jt);
> 146:   if (nullptr == canonical_chunk_path && !_chunkwriter->is_valid()) {
> 147:     // new output is null and current output is null

T

src/hotspot/share/jfr/recorder/stringpool/jfrStringPool.cpp line 119:

> 117:   }
> 118:   release(old, thread);
> 119:   return new_buffer; // might be null

T

src/hotspot/share/jvmci/jvmciEnv.cpp line 366:

> 364:     JNIAccessMark jni(this, THREAD);
> 365:     jthrowable ex = jni()->ExceptionOccurred();
> 366:     if (ex != nullptr) {

T

src/hotspot/share/logging/logAsyncWriter.cpp line 195:

> 193:   if (self->_initialized) {
> 194:     Atomic::release_store_fence(&AsyncLogWriter::_instance, self);
> 195:     // All readers of _instance after the fence see non-null.

T

src/hotspot/share/logging/logConfiguration.cpp line 481:

> 479:                                            const char* output_options,
> 480:                                            outputStream* errstream) {
> 481:   assert(errstream != nullptr, "errstream can not be null");

T

src/hotspot/share/logging/logConfiguration.hpp line 64:

> 62:   static bool                       _async_mode;
> 63: 
> 64:   // Create a new output. Returns null if failed.

T

src/hotspot/share/logging/logMessageBuffer.hpp line 112:

> 110:   // using set_prefix(). Lines added to the LogMessageBuffer after a prefix
> 111:   // function has been set will be prefixed automatically.
> 112:   // Setting this to null will disable prefixing.

T

src/hotspot/share/logging/logStream.hpp line 103:

> 101:     : LogStreamImpl(LogTargetHandle(level, LogTagSetMapping<T0, T1, T2, T3, T4>::tagset())) {}
> 102: 
> 103:   // Constructor to support creation from typed (likely null) pointer. Mostly used by the logging framework.

T

src/hotspot/share/memory/metaspace.cpp line 878:

> 876:          "allocation size too large (" SIZE_FORMAT ")", word_size);
> 877: 
> 878:   assert(loader_data != nullptr, "Should never pass around a null loader_data. "

T

src/hotspot/share/memory/metaspace/metachunk.cpp line 280:

> 278: 
> 279:   // Test base pointer
> 280:   assert(base() != nullptr, "Base pointer null");

T

src/hotspot/share/memory/metaspace/metaspaceArena.cpp line 346:

> 344: 
> 345:   if (p == nullptr) {
> 346:     UL(info, "allocation failed, returned null.");

T

src/hotspot/share/memory/universe.cpp line 469:

> 467:         if (!is_reference_type((BasicType)i)) {
> 468:           oop m = _basic_type_mirrors[i].resolve();
> 469:           assert(m != nullptr, "archived mirrors should not be null");

T

src/hotspot/share/memory/virtualspace.cpp line 598:

> 596:     // Last, desperate try without any placement.
> 597:     if (_base == nullptr) {
> 598:       log_trace(gc, heap, coops)("Trying to allocate at address null heap of size " SIZE_FORMAT_X, size + noaccess_prefix);

T

src/hotspot/share/oops/cpCache.cpp line 888:

> 886:   const bool has_appendix    = appendix.not_null();
> 887: 
> 888:   LogStream* log_stream = nullptr;

T

src/hotspot/share/oops/cpCache.cpp line 906:

> 904:     objArrayOop resolved_references = constant_pool()->resolved_references();
> 905:     assert(appendix_index >= 0 && appendix_index < resolved_references->length(), "oob");
> 906:     assert(resolved_references->obj_at(appendix_index) == nullptr, "init just once");

T

src/hotspot/share/oops/cpCache.cpp line 914:

> 912:   resolved_indy_entry_at(index)->fill_in(adapter, adapter->size_of_parameters(), as_TosState(adapter->result_type()), has_appendix);
> 913: 
> 914:   if (log_stream != nullptr) {

T

src/hotspot/share/prims/jvmtiAgent.cpp line 375:

> 373:   HandleMark hm(thread);
> 374:   extern struct JavaVM_ main_vm;
> 375:   const jint err = (*on_load_entry)(&main_vm, const_cast<char*>(agent->options()), nullptr);

T

src/hotspot/share/prims/jvmtiThreadState.cpp line 248:

> 246: 
> 247: // disable VTMS transitions for one virtual thread
> 248: // no-op if thread is non-null and not a virtual thread

T

src/hotspot/share/prims/whitebox.cpp line 1885:

> 1883:   InstanceKlass* ik = InstanceKlass::cast(java_lang_Class::as_Klass(JNIHandles::resolve(klass)));
> 1884:   ConstantPool* cp = ik->constants();
> 1885:   if (cp->cache() == nullptr) {

T

src/hotspot/share/prims/whitebox.cpp line 1894:

> 1892:   InstanceKlass* ik = InstanceKlass::cast(java_lang_Class::as_Klass(JNIHandles::resolve(klass)));
> 1893:   ConstantPool* cp = ik->constants();
> 1894:   if (cp->cache() == nullptr) {

T

src/hotspot/share/runtime/fieldDescriptor.cpp line 164:

> 162:         obj->obj_field(offset())->print_value_on(st);
> 163:       } else {
> 164:         st->print("null");

T

src/hotspot/share/runtime/fieldDescriptor.cpp line 171:

> 169:         obj->obj_field(offset())->print_value_on(st);
> 170:       } else {
> 171:         st->print("null");

T

src/hotspot/share/runtime/globals.hpp line 632:

> 630:                                                                             \
> 631:   develop(bool, InterceptOSException, false,                                \
> 632:           "Start debugger when an implicit OS (e.g. null) "                 \

T

src/hotspot/share/runtime/handles.hpp line 71:

> 69:  protected:
> 70:   oop     obj() const                            { return _handle == nullptr ? (oop)nullptr : *_handle; }
> 71:   oop     non_null_obj() const                   { assert(_handle != nullptr, "resolving null handle"); return *_handle; }

T

src/hotspot/share/runtime/handles.hpp line 147:

> 145:    protected:                                    \
> 146:     type*        obj() const                     { return _value; } \
> 147:     type*        non_null_obj() const            { assert(_value != nullptr, "resolving null _value"); return _value; } \

T

src/hotspot/share/runtime/jniHandles.cpp line 381:

> 379:       JNIHandleBlock* next = block->_next;
> 380:       Atomic::dec(&_blocks_allocated);
> 381:       assert(block->pop_frame_link() == nullptr, "pop_frame_link should be null");

T

src/hotspot/share/runtime/jniHandles.inline.hpp line 116:

> 114:   assert(handle != nullptr, "JNI handle should not be null");
> 115:   oop result = resolve_impl<DECORATORS_NONE, false /* external_guard */>(handle);
> 116:   assert(result != nullptr, "null read from jni handle");

T

src/hotspot/share/runtime/objectMonitor.cpp line 539:

> 537:     // Attempt async deflation protocol.
> 538: 
> 539:     // Set a null owner to DEFLATER_MARKER to force any contending thread

T

src/hotspot/share/runtime/objectMonitor.cpp line 564:

> 562:     if (Atomic::cmpxchg(&_contentions, 0, INT_MIN) != 0) {
> 563:       // Contentions was no longer 0 so we lost the race since the
> 564:       // ObjectMonitor is now busy. Restore owner to null if it is

T

src/hotspot/share/runtime/objectMonitor.cpp line 669:

> 667:     ss->print("owner=" INTPTR_FORMAT, p2i(owner_raw()));
> 668:   } else {
> 669:     // We report null instead of DEFLATER_MARKER here because is_busy()

T

src/hotspot/share/runtime/os.cpp line 1131:

> 1129:   // Handle null first, so later checks don't need to protect against it.
> 1130:   if (addr == nullptr) {
> 1131:     st->print_cr("0x0 is null");

T

src/hotspot/share/runtime/safepoint.cpp line 235:

> 233:   for (; JavaThread *cur = jtiwh.next(); ) {
> 234:     ThreadSafepointState *cur_tss = cur->safepoint_state();
> 235:     assert(cur_tss->get_next() == nullptr, "Must be null");

T

src/hotspot/share/runtime/thread.cpp line 269:

> 267:   delete metadata_handles();
> 268: 
> 269:   // osthread() can be null, if creation of thread failed.

T

src/hotspot/share/runtime/thread.hpp line 343:

> 341:   virtual const char* type_name() const { return "Thread"; }
> 342: 
> 343:   // Returns the current thread (ASSERTS if null)

T

src/hotspot/share/runtime/threadSMR.cpp line 623:

> 621: // Shared singleton data for all ThreadsList(0) instances.
> 622: // Used by _bootstrap_list to avoid static init time heap allocation.
> 623: // No real entries, just the final null terminator.

T

src/hotspot/share/runtime/threadSMR.cpp line 849:

> 847:     _protected_java_thread = java_lang_Thread::thread(thread_oop);
> 848:     assert(_protected_java_thread == nullptr || _tlh.includes(_protected_java_thread), "must be");
> 849:     // If we captured a non-null JavaThread* after the _tlh was created

T

src/hotspot/share/runtime/vmOperations.cpp line 335:

> 333:           jt->is_exiting() ||
> 334:           jt->is_hidden_from_external_view())  {
> 335:         // add a null snapshot if skipped

T

src/hotspot/share/services/threadService.cpp line 1071:

> 1069:       oop ownerObj = java_util_concurrent_locks_AbstractOwnableSynchronizer::get_owner_threadObj(waitingToLockBlocker);
> 1070:       currentThread = java_lang_Thread::thread(ownerObj);
> 1071:       assert(currentThread != nullptr, "AbstractOwnableSynchronizer owning thread is unexpectedly null");

T

src/hotspot/share/utilities/concurrentHashTable.inline.hpp line 1295:

> 1293:     return false;
> 1294:   }
> 1295:   assert(_new_table == nullptr || _new_table == POISON_PTR, "Must be null");

T

src/hotspot/share/utilities/copy.cpp line 73:

> 71:     assert(src != nullptr, "address must not be null");
> 72:     assert(dst != nullptr, "address must not be null");
> 73:     assert(elem_size == 2 || elem_size == 4 || elem_size == 8,

T

src/hotspot/share/utilities/elfFile.cpp line 1827:

> 1825: }
> 1826: 
> 1827: // If result is a null, we do not care about the content of the string being read.

T

src/hotspot/share/utilities/elfFuncDescTable.hpp line 135:

> 133:   ~ElfFuncDescTable();
> 134: 
> 135:   // return the function address for the function descriptor at 'index' or null on error

T

src/hotspot/share/utilities/exceptions.cpp line 138:

> 136: // therefore the exception oop should be in the oopmap.
> 137: void Exceptions::_throw_oop(JavaThread* thread, const char* file, int line, oop exception) {
> 138:   assert(exception != nullptr, "exception should not be null");

T

src/hotspot/share/utilities/exceptions.cpp line 145:

> 143: void Exceptions::_throw(JavaThread* thread, const char* file, int line, Handle h_exception, const char* message) {
> 144:   ResourceMark rm(thread);
> 145:   assert(h_exception() != nullptr, "exception should not be null");

T

src/hotspot/share/utilities/globalDefinitions.cpp line 162:

> 160:   static_assert((size_t)HeapWordSize >= sizeof(juint),
> 161:                 "HeapWord should be at least as large as juint");
> 162:   static_assert(sizeof(nullptr) == sizeof(char*), "null must be same size as pointer");

T

src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 135:

> 133: 
> 134: // gcc warns about applying offsetof() to non-POD object or calculating
> 135: // offset directly when base address is null. The -Wno-invalid-offsetof

T

src/hotspot/share/utilities/linkedlist.hpp line 174:

> 172: 
> 173:   virtual void add(LinkedListNode<E>* node) {
> 174:     assert(node != nullptr, "null pointer");

T

src/hotspot/share/utilities/linkedlist.hpp line 388:

> 386: 
> 387:   virtual void add(LinkedListNode<E>* node) {
> 388:     assert(node != nullptr, "null pointer");

T

src/hotspot/share/utilities/lockFreeStack.hpp line 79:

> 77: 
> 78:   // Atomically removes the top object from this stack and returns a
> 79:   // pointer to that object, or null if this stack is empty. Acts as a

T

src/hotspot/share/utilities/lockFreeStack.hpp line 100:

> 98:   }
> 99: 
> 100:   // Atomically exchange the list of elements with null, returning the old

T

src/hotspot/share/utilities/lockFreeStack.hpp line 146:

> 144:   bool empty() const { return top() == nullptr; }
> 145: 
> 146:   // Return the most recently pushed element, or null if the stack is empty.

T

src/hotspot/share/utilities/nonblockingQueue.hpp line 48:

> 46: // A queue may temporarily appear to be empty even though elements have been
> 47: // added and not removed.  For example, after running the following program,
> 48: // the value of r may be null.

T

src/hotspot/share/utilities/nonblockingQueue.hpp line 108:

> 106:   // Thread-safe attempt to remove and return the first object in the queue.
> 107:   // Returns true if successful.  If successful then *node_ptr is the former
> 108:   // first object, or null if the queue was empty.  If unsuccessful, because

T

src/hotspot/share/utilities/nonblockingQueue.hpp line 114:

> 112:   inline bool try_pop(T** node_ptr);
> 113: 
> 114:   // Thread-safe remove and return the first object in the queue, or null

T

src/hotspot/share/utilities/nonblockingQueue.hpp line 116:

> 114:   // Thread-safe remove and return the first object in the queue, or null
> 115:   // if the queue was empty.  This just iterates on try_pop() until it
> 116:   // succeeds, returning the (possibly null) element obtained from that.

T

src/hotspot/share/utilities/nonblockingQueue.inline.hpp line 88:

> 86: // An append operation atomically exchanges the new tail with the queue tail.
> 87: // It then sets the "next" value of the old tail to the head of the list being
> 88: // appended. If the old tail is null then the queue was empty, then the

T

src/hotspot/share/utilities/nonblockingQueue.inline.hpp line 111:

> 109:   if (old_tail == nullptr) {
> 110:     // If old_tail is null then the queue was empty, and _head must also be
> 111:     // null.  The correctness of this assertion depends on try_pop clearing

T

src/hotspot/share/utilities/nonblockingQueue.inline.hpp line 129:

> 127:   } else {
> 128:     // A concurrent try_pop has claimed old_tail, so it is no longer in the
> 129:     // list.  The queue was logically empty.  _head is either null or

T

src/hotspot/share/utilities/nonblockingQueue.inline.hpp line 155:

> 153:     // There are several cases for next_node.
> 154:     // (1) next_node is the extension of the queue's list.
> 155:     // (2) next_node is null, because a competing try_pop took old_head.

T

src/hotspot/share/utilities/nonblockingQueue.inline.hpp line 178:

> 176:       // report it as such for consistency, though we could report the queue
> 177:       // was empty.  We don't attempt to further help [Clause 2] by also
> 178:       // trying to set _tail to nullptr, as that would just ensure that one or

T

src/hotspot/share/utilities/nonblockingQueue.inline.hpp line 194:

> 192:     // [Clause 2]
> 193:     // Old_head was the last entry and we've claimed it by setting its next
> 194:     // value to null.  However, this leaves the queue in disarray.  Fix up

T

src/hotspot/share/utilities/nonblockingQueue.inline.hpp line 203:

> 201:     // also consistent with [Clause 1b].
> 202: 
> 203:     // Attempt to change the queue head from old_head to null.  Failure of

T

src/hotspot/share/utilities/nonblockingQueue.inline.hpp line 208:

> 206:     Atomic::cmpxchg(&_head, old_head, (T*)nullptr);
> 207: 
> 208:     // Attempt to change the queue tail from old_head to null.  Failure of

T

src/hotspot/share/utilities/ostream.cpp line 709:

> 707:     start_log();
> 708:   } else {
> 709:     // and leave xtty as null

T

src/hotspot/share/utilities/ostream.cpp line 771:

> 769:           text->print_raw(p->key());
> 770:           text->put('=');
> 771:           assert(p->value() != nullptr, "p->value() is null");

T

src/hotspot/share/utilities/unsigned5.hpp line 327:

> 325:     Writer(const ARR& array)
> 326:       : _array(const_cast<ARR&>(array)), _limit_ptr(nullptr), _position(0) {
> 327:       // Note: if _limit_ptr is null, the ARR& is never reassigned,

T

src/hotspot/share/utilities/utf8.hpp line 76:

> 74:   // Utility methods
> 75: 
> 76:   // Returns null if 'c' it not found. This only works as long

T

src/hotspot/share/utilities/vmError.hpp line 45:

> 43:   static char        _detail_msg[1024];
> 44: 
> 45:   static Thread*     _thread;           // null if it's native thread

T

-------------

PR Review: https://git.openjdk.org/jdk/pull/14198#pullrequestreview-1449252066
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209159785
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209159872
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209160289
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209160378
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209160527
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209160578
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209161770
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209160686
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209160791
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209161299
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209161367
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209161415
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209161470
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209162033
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209162094
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209162234
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209162319
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209162344
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209162424
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209162602
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209162648
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209162687
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209162835
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209162873
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163006
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163074
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163111
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163185
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163220
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163248
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163287
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163352
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163396
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163558
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163605
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163642
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163724
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163763
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163811
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163873
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209163927
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209164027
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209164087
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209164125
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209164508
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209164848
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209164910
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209164940
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209165038
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209165073
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209165280
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209165354
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209165423
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209165533
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209165626
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209165671
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209165736
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209165819
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209165977
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209166087
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209166196
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209166250
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209166340
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209166433
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209166563
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209166748
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209166817
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209166925
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209166991
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209167061
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209167105
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209167139
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209167208
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209167536
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209167644
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209167683
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209167736
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209167787
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209167918
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209167968
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168014
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168057
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168094
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168142
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168185
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168230
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168252
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168310
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168372
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168414
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168454
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168522
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168564
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168609
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168655
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209168750

From jsjolen at openjdk.org  Mon May 29 11:02:27 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 29 May 2023 11:02:27 GMT
Subject: RFR: 8309044: Replace NULL with nullptr, final sweep of hotspot code
Message-ID: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>

A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.

-------------

Commit messages:
 - Fix remaining work

Changes: https://git.openjdk.org/jdk/pull/14198/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14198&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309044
  Stats: 110 lines in 63 files changed: 0 ins; 0 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/14198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14198/head:pull/14198

PR: https://git.openjdk.org/jdk/pull/14198

From jsjolen at openjdk.org  Mon May 29 11:02:42 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 29 May 2023 11:02:42 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code
In-Reply-To: <hMxviuuUN_qpfFue6unPDKaBFkFUdfUKF0Qf_FBJnHs=.8e1061bf-15da-42ab-8b0e-9c2ee44f536a@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <hMxviuuUN_qpfFue6unPDKaBFkFUdfUKF0Qf_FBJnHs=.8e1061bf-15da-42ab-8b0e-9c2ee44f536a@github.com>
Message-ID: <JEU3ZFaGeNeH_QG5SAyTd8VqSudmT_7gzt_eG1LqePw=.ef9f941d-07c7-4f0b-918a-0cf87f263792@github.com>

On Mon, 29 May 2023 10:19:02 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> src/hotspot/share/utilities/globalDefinitions.cpp line 162:
> 
>> 160:   static_assert((size_t)HeapWordSize >= sizeof(juint),
>> 161:                 "HeapWord should be at least as large as juint");
>> 162:   static_assert(sizeof(nullptr) == sizeof(char*), "null must be same size as pointer");
> 
> T

Add both?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209167397

From amitkumar at openjdk.org  Mon May 29 12:27:03 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 29 May 2023 12:27:03 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code
In-Reply-To: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
Message-ID: <QQKox5yAeM7hIum2mRsp1CHOmF7PvVA5LpBa8CdcLJw=.92df0050-c823-41bf-9fb8-0dadbabdbfd1@github.com>

On Mon, 29 May 2023 10:09:15 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.

not a review, but would you like to check if these could replaced as well :-) 

./cpu/ppc/macroAssembler_ppc.hpp:735:  void load_klass_check_null(Register dst, Register src, Label* is_null = NULL);
./cpu/ppc/stubGenerator_ppc.cpp:4700:    if (UnsafeCopyMemory::_table == NULL) {
./cpu/riscv/codeBuffer_riscv.cpp:74:  if (cb->stubs()->maybe_expand_to_ensure_remaining(total_requested_size) && cb->blob() == NULL) {
./share/include/jvm.h:423: * Find a class from a boot class loader. Returns NULL if class not found.
./share/include/cds.h:72:  char*   _mapped_base;       // Actually mapped address (NULL if this region is not mapped).
./share/opto/runtime.cpp:491:  fields[TypeFunc::Parms+0] = NULL; // void

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-1567074248

From stefank at openjdk.org  Mon May 29 15:45:04 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 29 May 2023 15:45:04 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code
In-Reply-To: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
Message-ID: <4I1TbflhiAql_f2keh9Pbu7AA0wHem16ntfy8hP-cx4=.ad35b94a-6430-4a7d-87d4-ee019a3962b5@github.com>

On Mon, 29 May 2023 10:09:15 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.

Looks good. Though, I'd prefer if we could slightly tweak the following two print lines.

src/hotspot/share/gc/z/zHeap.cpp line 383:

> 381: 
> 382:   if (addr == zaddress::null) {
> 383:     st->print_raw_cr("NULL");

I'd prefer if this were left as either NULL or null.

src/hotspot/share/gc/z/zHeap.cpp line 438:

> 436: 
> 437:   if (addr == zaddress::null) {
> 438:     st->print_raw_cr("nullptr");

I'd prefer if this were left as either NULL or null.

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14198#pullrequestreview-1449662288
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209421642
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209421699

From dholmes at openjdk.org  Tue May 30 01:01:13 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 May 2023 01:01:13 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code
In-Reply-To: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
Message-ID: <DayDaiijFt7-A7aeOnzwjQgSzG7JcFEFUlKpVjOWnto=.8abd11fa-1905-459d-9651-3c9518b393bb@github.com>

On Mon, 29 May 2023 10:09:15 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.

Looks good. A few suggested changes below.

Can we now poison NULL so it can't get reintroduced? Or would that potentially break standard headers?

Thanks

src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 2297:

> 2295:   __ ld_ptr(method, array_base_offset + in_bytes(ResolvedIndyEntry::method_offset()), cache);
> 2296: 
> 2297:   // The invokedynamic is unresolved iff method is nullptr

Suggest: null

src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp line 489:

> 487:   __ load_klass(obj, obj, tmp1);  // get klass
> 488:   __ testptr(obj, obj);
> 489:   __ jcc(Assembler::zero, error); // if klass is nullptr it is broken

suggest: null

src/hotspot/share/gc/z/zHeap.cpp line 383:

> 381: 
> 382:   if (addr == zaddress::null) {
> 383:     st->print_raw_cr("nullptr");

Suggest: null

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14198#pullrequestreview-1449932378
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209610406
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209610541
PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209610909

From dholmes at openjdk.org  Tue May 30 01:01:19 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 May 2023 01:01:19 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code
In-Reply-To: <hMxviuuUN_qpfFue6unPDKaBFkFUdfUKF0Qf_FBJnHs=.8e1061bf-15da-42ab-8b0e-9c2ee44f536a@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <hMxviuuUN_qpfFue6unPDKaBFkFUdfUKF0Qf_FBJnHs=.8e1061bf-15da-42ab-8b0e-9c2ee44f536a@github.com>
Message-ID: <yDA9BVHGj93WRkwiqjC7s-zUiyIZWyShg3tVarTSBh8=.3f889657-1cee-4ef2-9205-395b3e147c31@github.com>

On Mon, 29 May 2023 10:17:06 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> src/hotspot/share/runtime/globals.hpp line 632:
> 
>> 630:                                                                             \
>> 631:   develop(bool, InterceptOSException, false,                                \
>> 632:           "Start debugger when an implicit OS (e.g. null) "                 \
> 
> T

Suggest: null pointer

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209611686

From dholmes at openjdk.org  Tue May 30 01:01:16 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 May 2023 01:01:16 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code
In-Reply-To: <4I1TbflhiAql_f2keh9Pbu7AA0wHem16ntfy8hP-cx4=.ad35b94a-6430-4a7d-87d4-ee019a3962b5@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <4I1TbflhiAql_f2keh9Pbu7AA0wHem16ntfy8hP-cx4=.ad35b94a-6430-4a7d-87d4-ee019a3962b5@github.com>
Message-ID: <-Fymi8Igyn7pUXLI9SqWDIabCue12XT0Avjgb071gzU=.2bbe930b-0788-47b6-860d-77ae1f9a12e9@github.com>

On Mon, 29 May 2023 15:36:36 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> src/hotspot/share/gc/z/zHeap.cpp line 438:
> 
>> 436: 
>> 437:   if (addr == zaddress::null) {
>> 438:     st->print_raw_cr("nullptr");
> 
> I'd prefer if this were left as either NULL or null.

Suggest: null

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14198#discussion_r1209611018

From jsjolen at openjdk.org  Tue May 30 19:15:38 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 30 May 2023 19:15:38 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
Message-ID: <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>

> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.

Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:

 - Align
 - Suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14198/files
  - new: https://git.openjdk.org/jdk/pull/14198/files/c7e28571..c9d9c30c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14198&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14198&range=00-01

  Stats: 9 lines in 8 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/14198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14198/head:pull/14198

PR: https://git.openjdk.org/jdk/pull/14198

From jsjolen at openjdk.org  Tue May 30 19:15:41 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 30 May 2023 19:15:41 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code
In-Reply-To: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
Message-ID: <tIM8XeumG7U336AuwLDHOo2ohWDF9qdK6-eXAKeeCUE=.fd418e25-a8ca-426a-953f-c67e60a2bea6@github.com>

On Mon, 29 May 2023 10:09:15 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.

Hi, thank you all for the suggestions! I've now applied them. I'll look at integrating tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-1568940197

From kvn at openjdk.org  Tue May 30 19:28:07 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 30 May 2023 19:28:07 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
Message-ID: <N6fi9A4ZZdY8Bo0sjo1cbX5k0xaqAb4kaPXJDNqEhlA=.52e52b1b-600e-41e8-9197-8fcac49a4e5a@github.com>

On Tue, 30 May 2023 19:15:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Align
>  - Suggestions

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14198#pullrequestreview-1451670515

From dnsimon at openjdk.org  Tue May 30 22:38:04 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 30 May 2023 22:38:04 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag
Message-ID: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>

Use of the Graal-based JIT in OpenJDK currently requires the following flag: `-XX:+EnableJVMCIProduct`

This has no direct association with Graal. If the JDK image happens to include a non-Graal JVMCI implementation, it will be automatically selected. This would come as a surprise to users who equate JVMCI with Graal.

This PR introduces a new flag, `-XX:+UseGraalJIT` to address these shortcomings. The VM fails fast at startup if there is a non-Graal JVMCI implementation or no JVMCI implementation in the JDK image.

-------------

Commit messages:
 - add UseGraalJIT VM flag

Changes: https://git.openjdk.org/jdk/pull/14231/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14231&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309136
  Stats: 53 lines in 4 files changed: 36 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14231/head:pull/14231

PR: https://git.openjdk.org/jdk/pull/14231

From amitkumar at openjdk.org  Wed May 31 04:27:04 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 31 May 2023 04:27:04 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
Message-ID: <1jUN4aGELW2Mc9vIZlta5Ml1wA9aXRYVYkF2DyU1F8w=.8c984fb2-de2b-4526-aa6e-214d97565d3f@github.com>

On Tue, 30 May 2023 19:15:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Align
>  - Suggestions

Thanks for addressing the comment. Looks Good :-)

-------------

Marked as reviewed by amitkumar (Author).

PR Review: https://git.openjdk.org/jdk/pull/14198#pullrequestreview-1452183165

From dholmes at openjdk.org  Wed May 31 07:31:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 31 May 2023 07:31:58 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag
In-Reply-To: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
Message-ID: <rBs2VWnMoPQr62MNQZldHq_Z_zN_Bv8WTSLLd3aJ0wo=.80a1a5d9-65a1-4c0d-abf4-7f078dafeea2@github.com>

On Tue, 30 May 2023 22:31:13 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Use of the Graal-based JIT in OpenJDK currently requires the following flag: `-XX:+EnableJVMCIProduct`
> 
> This has no direct association with Graal. If the JDK image happens to include a non-Graal JVMCI implementation, it will be automatically selected. This would come as a surprise to users who equate JVMCI with Graal.
> 
> This PR introduces a new flag, `-XX:+UseGraalJIT` to address these shortcomings. The VM fails fast at startup if there is a non-Graal JVMCI implementation or no JVMCI implementation in the JDK image.

A couple of minor items but otherwise the flag handling seems fine (though not what was linked in the CSR request).

Thanks.

src/hotspot/share/jvmci/jvmci_globals.hpp line 51:

> 49:           "Enable JVMCI")                                                   \
> 50:                                                                             \
> 51:   product(bool, UseGraalJIT, false,                                         \

This should be EXPERIMENTAL

src/hotspot/share/jvmci/jvmci_globals.hpp line 52:

> 50:                                                                             \
> 51:   product(bool, UseGraalJIT, false,                                         \
> 52:           "Select the Graal JVMCI compiler. This is a macro for: "          \

s/a macro/an alias/ please

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14231#pullrequestreview-1452387120
PR Review Comment: https://git.openjdk.org/jdk/pull/14231#discussion_r1211206390
PR Review Comment: https://git.openjdk.org/jdk/pull/14231#discussion_r1211206940

From dnsimon at openjdk.org  Wed May 31 08:08:34 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 31 May 2023 08:08:34 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag [v2]
In-Reply-To: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
Message-ID: <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>

> Use of the Graal-based JIT in OpenJDK currently requires the following flag: `-XX:+EnableJVMCIProduct`
> 
> This has no direct association with Graal. If the JDK image happens to include a non-Graal JVMCI implementation, it will be automatically selected. This would come as a surprise to users who equate JVMCI with Graal.
> 
> This PR introduces a new flag, `-XX:+UseGraalJIT` to address these shortcomings. The VM fails fast at startup if there is a non-Graal JVMCI implementation or no JVMCI implementation in the JDK image.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  review based fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14231/files
  - new: https://git.openjdk.org/jdk/pull/14231/files/f9b3538d..235075c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14231&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14231&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14231/head:pull/14231

PR: https://git.openjdk.org/jdk/pull/14231

From dnsimon at openjdk.org  Wed May 31 08:08:54 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 31 May 2023 08:08:54 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag [v2]
In-Reply-To: <rBs2VWnMoPQr62MNQZldHq_Z_zN_Bv8WTSLLd3aJ0wo=.80a1a5d9-65a1-4c0d-abf4-7f078dafeea2@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
 <rBs2VWnMoPQr62MNQZldHq_Z_zN_Bv8WTSLLd3aJ0wo=.80a1a5d9-65a1-4c0d-abf4-7f078dafeea2@github.com>
Message-ID: <h2_hKuFQMJ1TLpKFRoN771vkcJ6Vz09dvNYkcqTTKiI=.9fff2c1b-4848-488b-b1e0-0ca47d568bff@github.com>

On Wed, 31 May 2023 07:28:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> though not what was linked in the CSR request

Would you mind expanding on the discrepancy? I'd like to make it consistent.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14231#issuecomment-1569696991

From dholmes at openjdk.org  Wed May 31 08:21:56 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 31 May 2023 08:21:56 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag [v2]
In-Reply-To: <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
 <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
Message-ID: <Kt9kO6obFwaytACXMEEWlA-CQPm34uxuk6tlK-FzVRg=.d76667fc-ceb3-47d6-a3cf-727ef2d38061@github.com>

On Wed, 31 May 2023 08:08:34 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Use of the Graal-based JIT in OpenJDK currently requires the following flag: `-XX:+EnableJVMCIProduct`
>> 
>> This has no direct association with Graal. If the JDK image happens to include a non-Graal JVMCI implementation, it will be automatically selected. This would come as a surprise to users who equate JVMCI with Graal.
>> 
>> This PR introduces a new flag, `-XX:+UseGraalJIT` to address these shortcomings. The VM fails fast at startup if there is a non-Graal JVMCI implementation or no JVMCI implementation in the JDK image.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review based fixes

In the CSR request when asked about the response when the run-time image does not include the Graal JIT you pointed to this Java code:
https://github.com/openjdk/jdk/blob/927a9ed68371597eba1609f97ac03dd1de812e26/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCICompilerConfig.java#L112
but it seems to me that the logic in arguments.cpp handles the case where Graal is not available. Or are there different levels of "availability" here?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14231#issuecomment-1569717552

From dnsimon at openjdk.org  Wed May 31 08:30:55 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 31 May 2023 08:30:55 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag [v2]
In-Reply-To: <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
 <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
Message-ID: <fuyqnNIjmzlqOXEWpAfyJIpfGALtqITy6WIitL79EYQ=.1057a20c-728a-4add-99f4-522e02f37ebc@github.com>

On Wed, 31 May 2023 08:08:34 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Use of the Graal-based JIT in OpenJDK currently requires the following flag: `-XX:+EnableJVMCIProduct`
>> 
>> This has no direct association with Graal. If the JDK image happens to include a non-Graal JVMCI implementation, it will be automatically selected. This would come as a surprise to users who equate JVMCI with Graal.
>> 
>> This PR introduces a new flag, `-XX:+UseGraalJIT` to address these shortcomings. The VM fails fast at startup if there is a non-Graal JVMCI implementation or no JVMCI implementation in the JDK image.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review based fixes

The logic in arguments.cpp only ensures the value of `jvmci.Compiler` is consistent with `-XX:+UseGraalJIT`. Actually checking the availability of Graal can only be done in the code I linked to and it's only done on the first Graal JIT compilation (JVMCI compiler initialization is lazy to reduce impact to VM startup time).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14231#issuecomment-1569732162

From jsjolen at openjdk.org  Wed May 31 09:23:21 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 31 May 2023 09:23:21 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
Message-ID: <ZzBm0WEcALaAwSRD0XbpsMU8JOGK_dWVqnQ34va0rIk=.3243e9cf-163e-4e25-810e-e8cbdb632c83@github.com>

On Tue, 30 May 2023 19:15:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Align
>  - Suggestions

Right, seems like the Windows CI fails at fetching JTReg. I'm merging this, thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-1569815714

From jsjolen at openjdk.org  Wed May 31 09:23:22 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 31 May 2023 09:23:22 GMT
Subject: Integrated: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code
In-Reply-To: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
Message-ID: <l_zKJPkNuVxrOJ9DkaDWnFmI5GQ3qiVoqMFGJzkvpbI=.71c60b94-e12e-4c1a-a095-02f9c5c24719@github.com>

On Mon, 29 May 2023 10:09:15 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.

This pull request has now been integrated.

Changeset: 4f161616
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4f16161607edbf69f423ced1d3c24f7af058d46b
Stats:     114 lines in 67 files changed: 0 ins; 0 del; 114 mod

8309044: Replace NULL with nullptr, final sweep of hotspot code

Reviewed-by: stefank, dholmes, kvn, amitkumar

-------------

PR: https://git.openjdk.org/jdk/pull/14198

From kvn at openjdk.org  Wed May 31 19:01:43 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 31 May 2023 19:01:43 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag [v2]
In-Reply-To: <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
 <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
Message-ID: <7DH6pc4XKq6zIVuk4l5Uii330eaqKCSU4xKjU7f4hj4=.fa606e85-d43d-41b4-8569-7754c3cdef48@github.com>

On Wed, 31 May 2023 08:08:34 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Use of the Graal-based JIT in OpenJDK currently requires the following flag: `-XX:+EnableJVMCIProduct`
>> 
>> This has no direct association with Graal. If the JDK image happens to include a non-Graal JVMCI implementation, it will be automatically selected. This would come as a surprise to users who equate JVMCI with Graal.
>> 
>> This PR introduces a new flag, `-XX:+UseGraalJIT` to address these shortcomings. The VM fails fast at startup if there is a non-Graal JVMCI implementation or no JVMCI implementation in the JDK image.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review based fixes

What about `UseJVMCICompiler` flag? A lot of code in HotSpot is guarded by this flag.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14231#pullrequestreview-1453927961

From dnsimon at openjdk.org  Wed May 31 20:11:10 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 31 May 2023 20:11:10 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag [v2]
In-Reply-To: <7DH6pc4XKq6zIVuk4l5Uii330eaqKCSU4xKjU7f4hj4=.fa606e85-d43d-41b4-8569-7754c3cdef48@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
 <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
 <7DH6pc4XKq6zIVuk4l5Uii330eaqKCSU4xKjU7f4hj4=.fa606e85-d43d-41b4-8569-7754c3cdef48@github.com>
Message-ID: <L6cLNLXjRrzvEfLZ0l3IT3Oz4y_khn5ijupFtxIL5Os=.6238769d-093f-45d1-8038-5432fa3ec968@github.com>

On Wed, 31 May 2023 18:47:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> What about `UseJVMCICompiler` flag? A lot of code in HotSpot is guarded by this flag.

`UseGraalJIT` is an alias for `EnableJVMCIProduct` and the latter sets `UseJVMCICompiler` to true.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14231#issuecomment-1570872972

From kvn at openjdk.org  Wed May 31 22:18:08 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 31 May 2023 22:18:08 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag [v2]
In-Reply-To: <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
 <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
Message-ID: <MngVGFj9vI6w3UmEpFXJ5weNb1pSHqnAYyZzVOJYs5E=.0fcd4b4e-3955-408c-adba-c2316f421877@github.com>

On Wed, 31 May 2023 08:08:34 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Use of the Graal-based JIT in OpenJDK currently requires the following flag: `-XX:+EnableJVMCIProduct`
>> 
>> This has no direct association with Graal. If the JDK image happens to include a non-Graal JVMCI implementation, it will be automatically selected. This would come as a surprise to users who equate JVMCI with Graal.
>> 
>> This PR introduces a new flag, `-XX:+UseGraalJIT` to address these shortcomings. It is an alias for `-XX:+EnableJVMCIProduct -Djvmci.Compiler=graal`. 
>> 
>> When `-XX:+UseGraalJIT` is specified, the VM fails fast at startup if there is a non-Graal JVMCI implementation or no JVMCI implementation in the JDK image.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review based fixes

Update Copyright year in test.

src/hotspot/share/runtime/arguments.cpp line 2834:

> 2832:         jio_fprintf(defaultStream::error_stream(),
> 2833:                   "-XX:-EnableJVMCIProduct or -XX:-UseGraalJIT cannot come after -XX:+EnableJVMCIProduct or -XX:+UseGraalJIT\n");
> 2834:         return JNI_EINVAL;

Why this restriction? Usually latest specified flag wins. May be comment with explanation.
Also you did not check for `if (UseGraalJIT)`. 
What about the case `-XX:+EnableJVMCIProduct -XX:-UseGraalJIT`?
I would expect this kind of checks done in `JVMCIGlobals::check_jvmci_flags_are_consistent()`

src/hotspot/share/runtime/arguments.cpp line 2840:

> 2838:         const char* jvmci_compiler = get_property("jvmci.Compiler");
> 2839:         if (jvmci_compiler != nullptr) {
> 2840:           if (strcmp(jvmci_compiler, "graal") != 0) {

You should not use `strcmp` - use `strncmp`.

test/hotspot/jtreg/compiler/jvmci/TestEnableJVMCIProduct.java line 78:

> 76:             new Expectation("UseJVMCICompiler", "false", "default"));
> 77:         test("-XX:+EnableJVMCIProduct",
> 78:             new Expectation("EnableJVMCIProduct", "true", "(?:command line|jimage)"),

What "(?:command line|jimage)" means? Also `|` hard to see.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14231#pullrequestreview-1454237098
PR Review Comment: https://git.openjdk.org/jdk/pull/14231#discussion_r1212367355
PR Review Comment: https://git.openjdk.org/jdk/pull/14231#discussion_r1212359663
PR Review Comment: https://git.openjdk.org/jdk/pull/14231#discussion_r1212368628

From dholmes at openjdk.org  Wed May 31 23:15:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 31 May 2023 23:15:08 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag [v2]
In-Reply-To: <fuyqnNIjmzlqOXEWpAfyJIpfGALtqITy6WIitL79EYQ=.1057a20c-728a-4add-99f4-522e02f37ebc@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
 <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
 <fuyqnNIjmzlqOXEWpAfyJIpfGALtqITy6WIitL79EYQ=.1057a20c-728a-4add-99f4-522e02f37ebc@github.com>
Message-ID: <lWjRQDCPwQeBTRNZaQpEhbg9n2u7-odmQolLzc8yAgo=.451325e0-06f4-4c96-8a1d-66013692a967@github.com>

On Wed, 31 May 2023 08:27:59 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>  Actually checking the availability of Graal can only be done in the code I linked to and it's only done on the first Graal JIT compilation (JVMCI compiler initialization is lazy to reduce impact to VM startup time).

Are you saying that the application will start executing quite happily in interpreted mode and then only abort when the JIT first kicks in? That would be a very bad thing to do unless you can guarantee the jit will kick in extremely early during VM init sequence.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14231#issuecomment-1571082925

From dnsimon at openjdk.org  Wed May 31 23:26:17 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 31 May 2023 23:26:17 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag [v3]
In-Reply-To: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
Message-ID: <yH40bTMVqeNYGlF-Up3LpfiPoBAMSJ34WeWTGqmr6MM=.fa11b834-2a54-4588-a083-86297b45ca76@github.com>

> Use of the Graal-based JIT in OpenJDK currently requires the following flag: `-XX:+EnableJVMCIProduct`
> 
> This has no direct association with Graal. If the JDK image happens to include a non-Graal JVMCI implementation, it will be automatically selected. This would come as a surprise to users who equate JVMCI with Graal.
> 
> This PR introduces a new flag, `-XX:+UseGraalJIT` to address these shortcomings. It is an alias for `-XX:+EnableJVMCIProduct -Djvmci.Compiler=graal`. 
> 
> When `-XX:+UseGraalJIT` is specified, the VM fails fast at startup if there is a non-Graal JVMCI implementation or no JVMCI implementation in the JDK image.

Doug Simon has updated the pull request incrementally with five additional commits since the last revision:

 - improve error message when UseGraalJIT is used without -XX:+UnlockExperimentalVMOptions
 - use strncmp instead of strcmp
 - fix date in copyright header
 - set UseGraalJIT value in enable_jvmci_product_mode
 - added missing test of UseJVMCICompiler when adjusting JVMCI flags under -Xint

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14231/files
  - new: https://git.openjdk.org/jdk/pull/14231/files/235075c1..28f0a8b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14231&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14231&range=01-02

  Stats: 15 lines in 5 files changed: 7 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14231/head:pull/14231

PR: https://git.openjdk.org/jdk/pull/14231

From kvn at openjdk.org  Wed May 31 23:26:18 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 31 May 2023 23:26:18 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag [v2]
In-Reply-To: <lWjRQDCPwQeBTRNZaQpEhbg9n2u7-odmQolLzc8yAgo=.451325e0-06f4-4c96-8a1d-66013692a967@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
 <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
 <fuyqnNIjmzlqOXEWpAfyJIpfGALtqITy6WIitL79EYQ=.1057a20c-728a-4add-99f4-522e02f37ebc@github.com>
 <lWjRQDCPwQeBTRNZaQpEhbg9n2u7-odmQolLzc8yAgo=.451325e0-06f4-4c96-8a1d-66013692a967@github.com>
Message-ID: <pxWUXMxsRwliVNPsnYDe2ioreLXpZJ1Bwh0vbcLtI9w=.9f80e7c9-ea04-46a1-aa53-574eb4153814@github.com>

On Wed, 31 May 2023 23:12:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Actually checking the availability of Graal can only be done in the code I linked to and it's only done on the first Graal JIT compilation (JVMCI compiler initialization is lazy to reduce impact to VM startup time).
> 
> Are you saying that the application will start executing quite happily in interpreted mode and then only abort when the JIT first kicks in? That would be a very bad thing to do unless you can guarantee the jit will kick in extremely early during VM init sequence.

I assume this is required only for Java Graal. For libgraal you can check library presence at the VM startup. Or I am wrong?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14231#issuecomment-1571088397

From dnsimon at openjdk.org  Wed May 31 23:26:20 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 31 May 2023 23:26:20 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag [v2]
In-Reply-To: <MngVGFj9vI6w3UmEpFXJ5weNb1pSHqnAYyZzVOJYs5E=.0fcd4b4e-3955-408c-adba-c2316f421877@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
 <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
 <MngVGFj9vI6w3UmEpFXJ5weNb1pSHqnAYyZzVOJYs5E=.0fcd4b4e-3955-408c-adba-c2316f421877@github.com>
Message-ID: <KGXkc_c5tJ-p6R9EiWL05qOo3Iim86CWFy6ThBNrt6A=.85219065-110b-4c02-9632-4f82357872f2@github.com>

On Wed, 31 May 2023 22:09:12 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Why this restriction? Usually latest specified flag wins. May be comment with explanation.

This is a pre-existing restriction on `EnableJVMCIProduct` and since `UseGraalJIT` is an alias for `EnableJVMCIProduct`, it must abide by the same restrictions. For whatever reason, the effect of `+EnableJVMCIProduct` cannot be undone and so the same must hold for `+UseGraalJIT`.

> Also you did not check for `if (UseGraalJIT)`.

This check is not necessary as `UseGraalJIT` is an alias. When `EnableJVMCIProduct` is set to true, `UseGraalJIT` will also be set to true. Stating this now, I see that I missed it: https://github.com/openjdk/jdk/pull/14231/commits/430b7a58975f49f02de0f0eeb6de5267ee461558

> What about the case -XX:+EnableJVMCIProduct -XX:-UseGraalJIT?

That results in:

-XX:-EnableJVMCIProduct or -XX:-UseGraalJIT cannot come after -XX:+EnableJVMCIProduct or -XX:+UseGraalJIT
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

which is what is expected.

> test/hotspot/jtreg/compiler/jvmci/TestEnableJVMCIProduct.java line 78:
> 
>> 76:             new Expectation("UseJVMCICompiler", "false", "default"));
>> 77:         test("-XX:+EnableJVMCIProduct",
>> 78:             new Expectation("EnableJVMCIProduct", "true", "(?:command line|jimage)"),
> 
> What "(?:command line|jimage)" means? Also `|` hard to see.

That's a standard Java regular expression and it means the value is expected have been set on the command line or by the VM options read from the jimage (see [JDK-8232080](https://bugs.openjdk.org/browse/JDK-8232080)).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14231#discussion_r1212407808
PR Review Comment: https://git.openjdk.org/jdk/pull/14231#discussion_r1212409301

From dnsimon at openjdk.org  Wed May 31 23:33:05 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 31 May 2023 23:33:05 GMT
Subject: RFR: 8309136: [JVMCI] add -XX:+UseGraalJIT flag [v2]
In-Reply-To: <pxWUXMxsRwliVNPsnYDe2ioreLXpZJ1Bwh0vbcLtI9w=.9f80e7c9-ea04-46a1-aa53-574eb4153814@github.com>
References: <E_gEIx19Xl8tU4cseznXK1f38--NqKIrfzUXIWBOTEU=.bf32672a-316f-49d9-a9dd-3d8aba8e588b@github.com>
 <EavE1_fhjehgJpgvsPJIeKevUM_cAwNO2M5w0ZKXlMk=.ed65461e-3e7a-4884-86a3-c8c17429ba87@github.com>
 <fuyqnNIjmzlqOXEWpAfyJIpfGALtqITy6WIitL79EYQ=.1057a20c-728a-4add-99f4-522e02f37ebc@github.com>
 <lWjRQDCPwQeBTRNZaQpEhbg9n2u7-odmQolLzc8yAgo=.451325e0-06f4-4c96-8a1d-66013692a967@github.com>
 <pxWUXMxsRwliVNPsnYDe2ioreLXpZJ1Bwh0vbcLtI9w=.9f80e7c9-ea04-46a1-aa53-574eb4153814@github.com>
Message-ID: <3AfA6xb81WsQ55qBRk0QHMTZw25OQ2bVLdTTvO_C-U8=.bc8afd02-7049-43c2-a263-56da5f56c831@github.com>

On Wed, 31 May 2023 23:21:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > > Actually checking the availability of Graal can only be done in the code I linked to and it's only done on the first Graal JIT compilation (JVMCI compiler initialization is lazy to reduce impact to VM startup time).
> > 
> > 
> > Are you saying that the application will start executing quite happily in interpreted mode and then only abort when the JIT first kicks in? That would be a very bad thing to do unless you can guarantee the jit will kick in extremely early during VM init sequence.
> 
> I assume this is required only for Java Graal. For libgraal you can check library presence at the VM startup. Or I am wrong?

JVMCI compiler initialization is always lazy. It has been this way since the initial JVMCI implementation. Even libgraal initialization will impact VM startup. The first top tier compilation usually happens within the first 100 ms of VM execution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14231#issuecomment-1571093117

From dnsimon at openjdk.org  Tue May 16 09:09:12 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 16 May 2023 09:09:12 -0000
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err
Message-ID: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>

When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).

This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):

JVMCI Events (11 events):
...
Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)


It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:

COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]


[1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe

-------------

Depends on: https://git.openjdk.org/jdk/pull/13905

Commit messages:
 - send JVMCI exception info to hs-err log and/or tty
 - remove unused callToString method

Changes: https://git.openjdk.org/jdk/pull/14000/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14000&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308151
  Stats: 398 lines in 13 files changed: 335 ins; 31 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/14000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14000/head:pull/14000

PR: https://git.openjdk.org/jdk/pull/14000

From dnsimon at openjdk.org  Tue May 16 09:09:17 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 16 May 2023 09:09:17 -0000
Subject: RFR: 8308151: [JVMCI] capture JVMCI exceptions in hs-err
In-Reply-To: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
References: <acMcdIf5N84l9BsbXQL6MsF-kc4KZRTNLULuuZ-sQto=.f756f441-6267-4c49-8731-e8d5bae9de0c@github.com>
Message-ID: <u5OT4rFH0LmXRBOutYvvyKhph0IlSu5Of00Zfz3RHaA=.4a1a34e6-9d8c-4a96-97e9-ff423990e25e@github.com>

On Tue, 16 May 2023 08:02:11 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> When there is a pending exception after a JVMCI upcall into libjvmci, the VM calls the ExceptionDescribe JNI function to print the exception. Unfortunately, this output goes to "a system error-reporting channel" [1] which may not be tty. It also means the output is not in a hs-err log should the VM then exit with a fatal error. This has historically made it harder to triage libgraal bugs (i.e. the console output is usually required in addition to the hs-err crash log).
> 
> This PR addresses these shortcomings by printing the exception info to a string which is added to the JVMCI event log (for hs-err):
> 
> JVMCI Events (11 events):
> ...
> Event: 0.274 Thread 0x0000000146819210 compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError
> Event: 0.274 Thread 0x0000000146819210  at compiler.jvmci.TestUncaughtErrorInCompileMethod$1.createCompiler(TestUncaughtErrorInCompileMethod.java:147)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:829)
> Event: 0.274 Thread 0x0000000146819210  at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:943)
> 
> 
> It is also be used to enhance the `-XX:+PrintCompilation` message issued for a failed compilation:
> 
> COMPILE SKIPPED: uncaught exception in call_HotSpotJVMCIRuntime_compileMethod [compiler.jvmci.TestUncaughtErrorInCompileMethod$CompilerCreationError]
> 
> 
> [1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe

src/hotspot/share/jvmci/jvmciRuntime.cpp line 2047:

> 2045:                                                                      (jlong) compile_state, compile_state->task()->compile_id());
> 2046: #ifdef ASSERT
> 2047:   if (JVMCIENV->has_pending_exception() && JVMCICompileMethodExceptionIsFatal) {

It's a shame to introduce a VM flag (i.e., `JVMCICompileMethodExceptionIsFatal`) for a test case but I don't know of any other way to do this. As far as I know, system properties cannot be accessed here. Maybe using an environment variable is better than a VM flag?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14000#discussion_r1194855033