From dholmes at openjdk.org  Wed Nov  1 02:12:04 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 1 Nov 2023 02:12:04 GMT
Subject: RFR: 8318694: [JVMCI] disable can_call_java in most contexts for
 libjvmci compiler threads [v6]
In-Reply-To: <jLwufcgBTChCuJn0N3MFV47xzbm_0LKp1onetrA9F4U=.e921a1ed-51f8-4dc2-86e6-2a24b2b9fd33@github.com>
References: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
 <BYbLj5lr7SmjuqcgoM9jFap9TwbKcYYn3Pjp_hwFw6o=.324a1dc8-0472-491d-aa99-7e4cb6b2f3b1@github.com>
 <jLwufcgBTChCuJn0N3MFV47xzbm_0LKp1onetrA9F4U=.e921a1ed-51f8-4dc2-86e6-2a24b2b9fd33@github.com>
Message-ID: <ibaJ4vzyFBgiTxQlK8oYir19SkQeQxkIvt0cgyDqJMM=.ba96a1d6-e9b2-430a-a1a3-684fd41a5993@github.com>

On Mon, 30 Oct 2023 07:58:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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:
>> 
>>   allow JavaCalls in HotSpotConstantPool.callSystemExit
>
> Can't comment on all the details of the changes, but I don't see anything untoward in general.
> 
> Thanks.

> What do you think @dholmes-ora @vnkozlov ?

Normally we use asserts for things that are absolutely expected to be uncovered during testing - things that are purely internal VM concerns and for which a failure is a VM coding error. So I don't think it is necessary to change these to guarantees provided we have sufficient test coverage. The guarantee may not hurt but the same could be said for many other assertions.

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

PR Comment: https://git.openjdk.org/jdk/pull/16383#issuecomment-1788288243

From dnsimon at openjdk.org  Wed Nov  1 08:03:06 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 1 Nov 2023 08:03:06 GMT
Subject: RFR: 8318694: [JVMCI] disable can_call_java in most contexts for
 libjvmci compiler threads [v6]
In-Reply-To: <BYbLj5lr7SmjuqcgoM9jFap9TwbKcYYn3Pjp_hwFw6o=.324a1dc8-0472-491d-aa99-7e4cb6b2f3b1@github.com>
References: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
 <BYbLj5lr7SmjuqcgoM9jFap9TwbKcYYn3Pjp_hwFw6o=.324a1dc8-0472-491d-aa99-7e4cb6b2f3b1@github.com>
Message-ID: <e80jvgtALcwJUCBfXH6Gwgyc2OVd7WD6d-UZo6R5FP8=.9c9ee966-2143-44b3-be0e-a3998d78d0d9@github.com>

On Sun, 29 Oct 2023 20:39:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR reduces the context in which a libjvmci CompilerThread can make a Java call. By default, a CompileThread for a JVMCI compiler can make Java calls (as jarjvmci only works that way). When libjvmci calls into the VM via a CompilerToVM native method, it enters a scope where Java calls are disabled until either the call returns or a nested scope is entered that re-enables Java calls. The latter is required for the Truffle use case described in [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694) as well as for a few other VM entry points where libgraal currently still requires the ability to make Java calls (e.g. to load the Java classes used for boxing primitives). We may be able to eventually eliminate all need for libgraal to make Java calls but this PR is a first step in the right direction.
>
> 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:
> 
>   allow JavaCalls in HotSpotConstantPool.callSystemExit

With GraalVM, we're doing a lot more testing with product builds than fastdebug builds as the majority of checks are done at the Java level and fastdebug just slows everything down. In that testing context, guarantees are much more useful. Given the importance of the "can_call_java" invariant, would you agree that converting these 3 specific assertions to guarantees is justified?

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

PR Comment: https://git.openjdk.org/jdk/pull/16383#issuecomment-1788559705

From dholmes at openjdk.org  Wed Nov  1 12:05:02 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 1 Nov 2023 12:05:02 GMT
Subject: RFR: 8318694: [JVMCI] disable can_call_java in most contexts for
 libjvmci compiler threads [v6]
In-Reply-To: <BYbLj5lr7SmjuqcgoM9jFap9TwbKcYYn3Pjp_hwFw6o=.324a1dc8-0472-491d-aa99-7e4cb6b2f3b1@github.com>
References: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
 <BYbLj5lr7SmjuqcgoM9jFap9TwbKcYYn3Pjp_hwFw6o=.324a1dc8-0472-491d-aa99-7e4cb6b2f3b1@github.com>
Message-ID: <mdfrA0BQCtVB-OvlY4ZHuCwTPCicCqDpxQoopgqLnvg=.79a5103a-7949-41d5-94c9-0506fb836fae@github.com>

On Sun, 29 Oct 2023 20:39:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR reduces the context in which a libjvmci CompilerThread can make a Java call. By default, a CompileThread for a JVMCI compiler can make Java calls (as jarjvmci only works that way). When libjvmci calls into the VM via a CompilerToVM native method, it enters a scope where Java calls are disabled until either the call returns or a nested scope is entered that re-enables Java calls. The latter is required for the Truffle use case described in [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694) as well as for a few other VM entry points where libgraal currently still requires the ability to make Java calls (e.g. to load the Java classes used for boxing primitives). We may be able to eventually eliminate all need for libgraal to make Java calls but this PR is a first step in the right direction.
>
> 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:
> 
>   allow JavaCalls in HotSpotConstantPool.callSystemExit

The majority of hotspot testing is done on fastdebug and performance is not considered an issue there. But I don't have a hard objection to these three asserts becoming guarantees.

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

PR Comment: https://git.openjdk.org/jdk/pull/16383#issuecomment-1788837986

From dnsimon at openjdk.org  Wed Nov  1 13:33:32 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 1 Nov 2023 13:33:32 GMT
Subject: RFR: 8318694: [JVMCI] disable can_call_java in most contexts for
 libjvmci compiler threads [v7]
In-Reply-To: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
References: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
Message-ID: <aHYZTp5W5NBWigyOgQ0k0T5JQdDBA_dECcnLHb_ZU6M=.e56bbe59-2109-47c4-91e7-bc4d0d505fea@github.com>

> This PR reduces the context in which a libjvmci CompilerThread can make a Java call. By default, a CompileThread for a JVMCI compiler can make Java calls (as jarjvmci only works that way). When libjvmci calls into the VM via a CompilerToVM native method, it enters a scope where Java calls are disabled until either the call returns or a nested scope is entered that re-enables Java calls. The latter is required for the Truffle use case described in [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694) as well as for a few other VM entry points where libgraal currently still requires the ability to make Java calls (e.g. to load the Java classes used for boxing primitives). We may be able to eventually eliminate all need for libgraal to make Java calls but this PR is a first step in the right direction.

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

  convert assertions about can_call_java to guarantees

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16383/files
  - new: https://git.openjdk.org/jdk/pull/16383/files/b7181d70..832a5912

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

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

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

From dnsimon at openjdk.org  Wed Nov  1 16:27:03 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 1 Nov 2023 16:27:03 GMT
Subject: RFR: 8318694: [JVMCI] disable can_call_java in most contexts for
 libjvmci compiler threads [v7]
In-Reply-To: <aHYZTp5W5NBWigyOgQ0k0T5JQdDBA_dECcnLHb_ZU6M=.e56bbe59-2109-47c4-91e7-bc4d0d505fea@github.com>
References: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
 <aHYZTp5W5NBWigyOgQ0k0T5JQdDBA_dECcnLHb_ZU6M=.e56bbe59-2109-47c4-91e7-bc4d0d505fea@github.com>
Message-ID: <I5lvUcZ_tCnehn_8KsywDSYM7igCgOr0xa_EKEFCm3Y=.61650ff0-414b-40a6-ba93-3497e7632201@github.com>

On Wed, 1 Nov 2023 13:33:32 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR reduces the context in which a libjvmci CompilerThread can make a Java call. By default, a CompileThread for a JVMCI compiler can make Java calls (as jarjvmci only works that way). When libjvmci calls into the VM via a CompilerToVM native method, it enters a scope where Java calls are disabled until either the call returns or a nested scope is entered that re-enables Java calls. The latter is required for the Truffle use case described in [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694) as well as for a few other VM entry points where libgraal currently still requires the ability to make Java calls (e.g. to load the Java classes used for boxing primitives). We may be able to eventually eliminate all need for libgraal to make Java calls but this PR is a first step in the right direction.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert assertions about can_call_java to guarantees

Thanks for all the reviews and useful input.

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

PR Comment: https://git.openjdk.org/jdk/pull/16383#issuecomment-1789260596

From dnsimon at openjdk.org  Wed Nov  1 16:30:15 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 1 Nov 2023 16:30:15 GMT
Subject: Integrated: 8318694: [JVMCI] disable can_call_java in most contexts
 for libjvmci compiler threads
In-Reply-To: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
References: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
Message-ID: <9s6umJ-aLcpc2JLD0PQV_sUs3Wgk7YPGV2lyPo-tjbE=.82a70281-39e2-4ac5-a753-3c0846a38849@github.com>

On Thu, 26 Oct 2023 17:39:46 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR reduces the context in which a libjvmci CompilerThread can make a Java call. By default, a CompileThread for a JVMCI compiler can make Java calls (as jarjvmci only works that way). When libjvmci calls into the VM via a CompilerToVM native method, it enters a scope where Java calls are disabled until either the call returns or a nested scope is entered that re-enables Java calls. The latter is required for the Truffle use case described in [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694) as well as for a few other VM entry points where libgraal currently still requires the ability to make Java calls (e.g. to load the Java classes used for boxing primitives). We may be able to eventually eliminate all need for libgraal to make Java calls but this PR is a first step in the right direction.

This pull request has now been integrated.

Changeset: d354141a
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d354141aa191c80b473dfeee27b51f1562ffeafd
Stats:     197 lines in 13 files changed: 109 ins; 65 del; 23 mod

8318694: [JVMCI] disable can_call_java in most contexts for libjvmci compiler threads

Reviewed-by: dholmes, never

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

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

From cslucas at openjdk.org  Thu Nov  2 22:36:20 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 2 Nov 2023 22:36:20 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes during
 code emission
Message-ID: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>

# Description

Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.

Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.

# Help Needed for Testing

I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.

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

Commit messages:
 - Reuse same C2_MacroAssembler object to emit instructions.

Changes: https://git.openjdk.org/jdk/pull/16484/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16484&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8241503
  Stats: 2665 lines in 60 files changed: 112 ins; 429 del; 2124 mod
  Patch: https://git.openjdk.org/jdk/pull/16484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16484/head:pull/16484

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

From mdoerr at openjdk.org  Thu Nov  2 23:24:05 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 2 Nov 2023 23:24:05 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <BJtlt-cQZXjDRa0F5QbiqHe_3y-Ih58tlRScZy1H-Ps=.86398c74-3a29-4b8b-b7c6-9e7b6a75cdf9@github.com>

On Thu, 2 Nov 2023 22:17:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.

PPC64 runs into assert(masm->inst_mark() == nullptr) failed: should be.
V  [libjvm.so+0x1648528]  PhaseOutput::fill_buffer(C2_MacroAssembler*, unsigned int*)+0x10c8  (output.cpp:1812)
V  [libjvm.so+0x164b35c]  PhaseOutput::Output()+0xd5c  (output.cpp:362)
V  [libjvm.so+0x958f9c]  Compile::Code_Gen()+0x4ec  (compile.cpp:2989)
V  [libjvm.so+0x95e484]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1a84  (compile.cpp:887)
V  [libjvm.so+0x718f58]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x198  (c2compiler.cpp:119)

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1791694904

From cslucas at openjdk.org  Thu Nov  2 23:39:02 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 2 Nov 2023 23:39:02 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <BJtlt-cQZXjDRa0F5QbiqHe_3y-Ih58tlRScZy1H-Ps=.86398c74-3a29-4b8b-b7c6-9e7b6a75cdf9@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <BJtlt-cQZXjDRa0F5QbiqHe_3y-Ih58tlRScZy1H-Ps=.86398c74-3a29-4b8b-b7c6-9e7b6a75cdf9@github.com>
Message-ID: <4LqTlmsaVA4gGTi5WQNjhn9KCN9SotYddp9SpdIpv-g=.294ccf81-e719-4621-8384-10242d2d7e95@github.com>

On Thu, 2 Nov 2023 23:21:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>
> PPC64 runs into assert(masm->inst_mark() == nullptr) failed: should be.
> V  [libjvm.so+0x1648528]  PhaseOutput::fill_buffer(C2_MacroAssembler*, unsigned int*)+0x10c8  (output.cpp:1812)
> V  [libjvm.so+0x164b35c]  PhaseOutput::Output()+0xd5c  (output.cpp:362)
> V  [libjvm.so+0x958f9c]  Compile::Code_Gen()+0x4ec  (compile.cpp:2989)
> V  [libjvm.so+0x95e484]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1a84  (compile.cpp:887)
> V  [libjvm.so+0x718f58]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x198  (c2compiler.cpp:119)

@TheRealMDoerr - this is likely because of some missing `clear_inst_mark` call on my part in the PPC ad, I'll take a look into it.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1791705658

From dlong at openjdk.org  Fri Nov  3 01:47:02 2023
From: dlong at openjdk.org (Dean Long)
Date: Fri, 3 Nov 2023 01:47:02 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <UGrpyynLCpoOo2S1FPh_i4G44QflcSFCFr42qvQrBVI=.d6495455-c652-4447-be5c-c1c7df457a72@github.com>

On Thu, 2 Nov 2023 22:17:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.

src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 37:

> 35: #include "gc/z/zBarrierSetAssembler.hpp"
> 36: 
> 37: static void z_color(MacroAssembler* masm, const MachNode* node, Register ref) {

For files already using MacroAssembler& _masm, the only change needed is this at the top:

undef __
#define __ _masm.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1381015121

From dlong at openjdk.org  Fri Nov  3 02:07:10 2023
From: dlong at openjdk.org (Dean Long)
Date: Fri, 3 Nov 2023 02:07:10 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <UGrpyynLCpoOo2S1FPh_i4G44QflcSFCFr42qvQrBVI=.d6495455-c652-4447-be5c-c1c7df457a72@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <UGrpyynLCpoOo2S1FPh_i4G44QflcSFCFr42qvQrBVI=.d6495455-c652-4447-be5c-c1c7df457a72@github.com>
Message-ID: <CzmCsBgo4tYIKfIH32SOVqy6GLusy8DRIz1QMt97XCA=.d5b9d7e1-1e74-4c05-a474-05abf000d190@github.com>

On Fri, 3 Nov 2023 01:44:42 GMT, Dean Long <dlong at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>
> src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 37:
> 
>> 35: #include "gc/z/zBarrierSetAssembler.hpp"
>> 36: 
>> 37: static void z_color(MacroAssembler* masm, const MachNode* node, Register ref) {
> 
> For files already using MacroAssembler& _masm, the only change needed is this at the top:
> 
> undef __
> #define __ _masm.

I guess that doesn't work because different files are concatenated together, causing a conflict if some files expect MacroAssembler *masm.  To reduce the number of changes, couldn't we use MacroAssembler& _masm everywhere?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1381098489

From fyang at openjdk.org  Fri Nov  3 04:49:01 2023
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 3 Nov 2023 04:49:01 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <F4F6PqnrFUaeVy2mZA9h09Gd5X9xjJQfC0HVts-zxcs=.c7e38cd6-285c-49f0-b711-76b7df681e37@github.com>

On Thu, 2 Nov 2023 22:17:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.

Hello, I guess you might want to merge latest jdk master and add more changes.
I witnessed some build errors when building the latest jdk master with this patch on linux-riscv64:

/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UdivINode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2412:30: error: 'cbuf' was not declared in this scope
 2412 |     C2_MacroAssembler _masm(&cbuf);
      |                              ^~~~
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UdivLNode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2427:30: error: 'cbuf' was not declared in this scope
 2427 |     C2_MacroAssembler _masm(&cbuf);
      |                              ^~~~
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UmodINode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2442:30: error: 'cbuf' was not declared in this scope
 2442 |     C2_MacroAssembler _masm(&cbuf);
      |                              ^~~~
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UmodLNode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
/home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2457:30: error: 'cbuf' was not declared in this scope
 2457 |     C2_MacroAssembler _masm(&cbuf);

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1791888196

From cslucas at openjdk.org  Fri Nov  3 16:27:06 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 3 Nov 2023 16:27:06 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <F4F6PqnrFUaeVy2mZA9h09Gd5X9xjJQfC0HVts-zxcs=.c7e38cd6-285c-49f0-b711-76b7df681e37@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <F4F6PqnrFUaeVy2mZA9h09Gd5X9xjJQfC0HVts-zxcs=.c7e38cd6-285c-49f0-b711-76b7df681e37@github.com>
Message-ID: <_Qvj6Msy_P6hIWUc4IwGPLKXLK7391GMCEI4XlNYQrY=.1e03e561-071f-48ae-b322-d944c7b1ff36@github.com>

On Fri, 3 Nov 2023 04:44:40 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>
> Hello, I guess you might want to merge latest jdk master and add more changes.
> I witnessed some build errors when building the latest jdk master with this patch on linux-riscv64:
> 
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UdivINode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2412:30: error: 'cbuf' was not declared in this scope
>  2412 |     C2_MacroAssembler _masm(&cbuf);
>       |                              ^~~~
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UdivLNode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2427:30: error: 'cbuf' was not declared in this scope
>  2427 |     C2_MacroAssembler _masm(&cbuf);
>       |                              ^~~~
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UmodINode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2442:30: error: 'cbuf' was not declared in this scope
>  2442 |     C2_MacroAssembler _masm(&cbuf);
>       |                              ^~~~
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad: In member function 'virtual void UmodLNode::emit(C2_MacroAssembler*, PhaseRegAlloc*) const':
> /home/fyang/jdk/src/hotspot/cpu/riscv/riscv.ad:2457:30: error: 'cbuf' was not declared in this scope
>  2457 |     C2_MacroAssembler _masm(&cbuf);

@RealFYang - Thanks for the note. I'll do that and update the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1792746837

From dnsimon at openjdk.org  Mon Nov  6 21:39:54 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 6 Nov 2023 21:39:54 GMT
Subject: RFR: 8319559: [JVMCI] ensureLinked must be able to call Java
Message-ID: <Zc8zG5kZcK-ytnp4DPZO5imoRmrr1X61mrA-lLHy2LI=.cbd851e3-895c-4170-8502-624d4cf04eef@github.com>

As of [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694), only a few select C2V entry points in `jvmciCompilerToVM.cpp` can make Java calls. The `ensureLinked` method was not included but needs to be as it is called from a Truffle context executing on a Compiler thread.

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

Commit messages:
 - ensureLinked must be able to call Java

Changes: https://git.openjdk.org/jdk/pull/16530/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16530&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319559
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16530/head:pull/16530

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

From never at openjdk.org  Mon Nov  6 21:46:28 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 6 Nov 2023 21:46:28 GMT
Subject: RFR: 8319559: [JVMCI] ensureLinked must be able to call Java
In-Reply-To: <Zc8zG5kZcK-ytnp4DPZO5imoRmrr1X61mrA-lLHy2LI=.cbd851e3-895c-4170-8502-624d4cf04eef@github.com>
References: <Zc8zG5kZcK-ytnp4DPZO5imoRmrr1X61mrA-lLHy2LI=.cbd851e3-895c-4170-8502-624d4cf04eef@github.com>
Message-ID: <Bjgue6Faaq7QsWrnUOyI5ZZmoaF_HOqv1zUJpVo2kA4=.e11d5e3d-2415-43aa-a4bf-dab7d5c89a0d@github.com>

On Mon, 6 Nov 2023 21:33:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> As of [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694), only a few select C2V entry points in `jvmciCompilerToVM.cpp` can make Java calls. The `ensureLinked` method was not included but needs to be as it is called from a Truffle context executing on a Compiler thread.

Marked as reviewed by never (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16530#pullrequestreview-1716319369

From cslucas at openjdk.org  Mon Nov  6 22:22:30 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 6 Nov 2023 22:22:30 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <CzmCsBgo4tYIKfIH32SOVqy6GLusy8DRIz1QMt97XCA=.d5b9d7e1-1e74-4c05-a474-05abf000d190@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <UGrpyynLCpoOo2S1FPh_i4G44QflcSFCFr42qvQrBVI=.d6495455-c652-4447-be5c-c1c7df457a72@github.com>
 <CzmCsBgo4tYIKfIH32SOVqy6GLusy8DRIz1QMt97XCA=.d5b9d7e1-1e74-4c05-a474-05abf000d190@github.com>
Message-ID: <_1LI3cbeE9XR-7E7gD22M7xNueLRhlAtHWopiTccb1Y=.a26dde00-d6b8-4c98-a84d-143d65ef251c@github.com>

On Fri, 3 Nov 2023 02:04:13 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 37:
>> 
>>> 35: #include "gc/z/zBarrierSetAssembler.hpp"
>>> 36: 
>>> 37: static void z_color(MacroAssembler* masm, const MachNode* node, Register ref) {
>> 
>> For files already using MacroAssembler& _masm, the only change needed is this at the top:
>> 
>> undef __
>> #define __ _masm.
>
> I guess that doesn't work because different files are concatenated together, causing a conflict if some files expect MacroAssembler *masm.  To reduce the number of changes, couldn't we use MacroAssembler& _masm everywhere?

Because some places were using `if (cbuf)` I ended up opting to make the parameter also a pointer instead of a reference.

> For files already using MacroAssembler& _masm, the only change needed is this at the top:

My opinion would be to use Reference or Pointer everywhere and not mix the two - to prevent confusion. But if you folks think it's best to go that way, I'm fine with it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1384095916

From azafari at openjdk.org  Tue Nov  7 09:31:41 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 7 Nov 2023 09:31:41 GMT
Subject: Withdrawn: 8198918: jio_snprintf and friends are not checked by
 -Wformat
In-Reply-To: <iGF_flkCDz0l3wGv67krXjLgH4AL3545MT4gaGR_ueU=.83fd2b02-2b4e-4bd6-85e4-6d34fd02e197@github.com>
References: <iGF_flkCDz0l3wGv67krXjLgH4AL3545MT4gaGR_ueU=.83fd2b02-2b4e-4bd6-85e4-6d34fd02e197@github.com>
Message-ID: <kTR43aQDuohPOsk_CKJp7OdumDibZnz5v-DTtrz8Q5g=.f1ca5528-f349-4c79-97e3-968a719d3380@github.com>

On Tue, 26 Sep 2023 11:46:19 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> - The `ATTRIBUTE_PRINTF` usage in cpp files is useless. They are removed.
> -  There are cases where `jio_xxprintf` functions use `char *` arguments for format string, rather than a literal like `"%s..."`. These cases are _not compiled_ when `ATTRIBUTE_PRINTF` is used for them. So, first I used the attribute and got the corresponding compile errors. Then I fixed the issues and removed the attribute when all issues were fixed.
> 
> ### Test
> The changes are tested on all platforms tiers 1-4.

This pull request has been closed without being integrated.

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

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

From thartmann at openjdk.org  Tue Nov  7 10:16:41 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 7 Nov 2023 10:16:41 GMT
Subject: RFR: 8319559: [JVMCI] ensureLinked must be able to call Java
In-Reply-To: <Zc8zG5kZcK-ytnp4DPZO5imoRmrr1X61mrA-lLHy2LI=.cbd851e3-895c-4170-8502-624d4cf04eef@github.com>
References: <Zc8zG5kZcK-ytnp4DPZO5imoRmrr1X61mrA-lLHy2LI=.cbd851e3-895c-4170-8502-624d4cf04eef@github.com>
Message-ID: <6Khzi-PCE-FLJYFY-LIe6LzBDwokPsr-7U-Qotq4LS4=.5ab05ad8-7c09-49e6-8317-7d8b04fb8bf9@github.com>

On Mon, 6 Nov 2023 21:33:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> As of [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694), only a few select C2V entry points in `jvmciCompilerToVM.cpp` can make Java calls. The `ensureLinked` method was not included but needs to be as it is called from a Truffle context executing on a Compiler thread.

Marked as reviewed by thartmann (Reviewer).

Looks good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/16530#pullrequestreview-1717316768
PR Comment: https://git.openjdk.org/jdk/pull/16530#issuecomment-1798203638

From dnsimon at openjdk.org  Tue Nov  7 10:16:42 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 7 Nov 2023 10:16:42 GMT
Subject: RFR: 8319559: [JVMCI] ensureLinked must be able to call Java
In-Reply-To: <Zc8zG5kZcK-ytnp4DPZO5imoRmrr1X61mrA-lLHy2LI=.cbd851e3-895c-4170-8502-624d4cf04eef@github.com>
References: <Zc8zG5kZcK-ytnp4DPZO5imoRmrr1X61mrA-lLHy2LI=.cbd851e3-895c-4170-8502-624d4cf04eef@github.com>
Message-ID: <_In44bcRvVKLOFkVpQnlf4MDDPIqFYZxYn_fO7uqdBI=.85de6178-33a9-4def-b323-cbe63668f94d@github.com>

On Mon, 6 Nov 2023 21:33:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> As of [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694), only a few select C2V entry points in `jvmciCompilerToVM.cpp` can make Java calls. The `ensureLinked` method was not included but needs to be as it is called from a Truffle context executing on a Compiler thread.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/16530#issuecomment-1798204298

From dnsimon at openjdk.org  Tue Nov  7 10:16:43 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 7 Nov 2023 10:16:43 GMT
Subject: Integrated: 8319559: [JVMCI] ensureLinked must be able to call Java
In-Reply-To: <Zc8zG5kZcK-ytnp4DPZO5imoRmrr1X61mrA-lLHy2LI=.cbd851e3-895c-4170-8502-624d4cf04eef@github.com>
References: <Zc8zG5kZcK-ytnp4DPZO5imoRmrr1X61mrA-lLHy2LI=.cbd851e3-895c-4170-8502-624d4cf04eef@github.com>
Message-ID: <AR3YQDkrjyRurCJkN619UMwN0i2Yh22rIBmtGMyNvsM=.9cda2bef-79ad-4471-8eaa-7afd54deb9e7@github.com>

On Mon, 6 Nov 2023 21:33:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> As of [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694), only a few select C2V entry points in `jvmciCompilerToVM.cpp` can make Java calls. The `ensureLinked` method was not included but needs to be as it is called from a Truffle context executing on a Compiler thread.

This pull request has now been integrated.

Changeset: 9ac6ac86
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ac6ac86d32d2a9a52fade257adeedd103d6ff82
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8319559: [JVMCI] ensureLinked must be able to call Java

Reviewed-by: never, thartmann

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

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

From dcubed at openjdk.org  Tue Nov  7 20:22:11 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 7 Nov 2023 20:22:11 GMT
Subject: RFR: 8318694: [JVMCI] disable can_call_java in most contexts for
 libjvmci compiler threads [v6]
In-Reply-To: <e80jvgtALcwJUCBfXH6Gwgyc2OVd7WD6d-UZo6R5FP8=.9c9ee966-2143-44b3-be0e-a3998d78d0d9@github.com>
References: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
 <BYbLj5lr7SmjuqcgoM9jFap9TwbKcYYn3Pjp_hwFw6o=.324a1dc8-0472-491d-aa99-7e4cb6b2f3b1@github.com>
 <e80jvgtALcwJUCBfXH6Gwgyc2OVd7WD6d-UZo6R5FP8=.9c9ee966-2143-44b3-be0e-a3998d78d0d9@github.com>
Message-ID: <dqCyB42bmMzB4Y3IQVIEegQal6oaYPQxLE0bCmSyJ2A=.6340311e-bbe0-4f19-a5a8-c9c3e060979c@github.com>

On Wed, 1 Nov 2023 08:00:46 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> With GraalVM, we're doing a lot more testing with product builds than fastdebug
> builds as the majority of checks are done at the Java level and fastdebug just
> slows everything down. In that testing context, guarantees are much more useful.
> Given the importance of the "can_call_java" invariant, would you agree that
> converting these 3 specific assertions to guarantees is justified?

Hmmm... I hope this doesn't mean that the GraalVM project has changed the
Tier[1-3] task definitions to focus on 'release' bits testing instead of 'fastdebug'
bits testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/16383#issuecomment-1799922110

From dnsimon at openjdk.org  Tue Nov  7 21:16:09 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 7 Nov 2023 21:16:09 GMT
Subject: RFR: 8318694: [JVMCI] disable can_call_java in most contexts for
 libjvmci compiler threads [v6]
In-Reply-To: <dqCyB42bmMzB4Y3IQVIEegQal6oaYPQxLE0bCmSyJ2A=.6340311e-bbe0-4f19-a5a8-c9c3e060979c@github.com>
References: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
 <BYbLj5lr7SmjuqcgoM9jFap9TwbKcYYn3Pjp_hwFw6o=.324a1dc8-0472-491d-aa99-7e4cb6b2f3b1@github.com>
 <e80jvgtALcwJUCBfXH6Gwgyc2OVd7WD6d-UZo6R5FP8=.9c9ee966-2143-44b3-be0e-a3998d78d0d9@github.com>
 <dqCyB42bmMzB4Y3IQVIEegQal6oaYPQxLE0bCmSyJ2A=.6340311e-bbe0-4f19-a5a8-c9c3e060979c@github.com>
Message-ID: <VK3Jw66A1bOqX5iIhx1K3qWulSLrEwz9w64wgeZtJB4=.f89870b9-6c22-40fb-878b-775bab75f58d@github.com>

On Tue, 7 Nov 2023 20:18:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Hmmm... I hope this doesn't mean that the GraalVM project has changed the
> Tier[1-3] task definitions to focus on 'release' bits testing instead of 'fastdebug'
> bits testing.

No, we did not change this in the tier testing. I was referring to the Graal CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/16383#issuecomment-1800137205

From dcubed at openjdk.org  Tue Nov  7 21:46:06 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 7 Nov 2023 21:46:06 GMT
Subject: RFR: 8318694: [JVMCI] disable can_call_java in most contexts for
 libjvmci compiler threads [v6]
In-Reply-To: <VK3Jw66A1bOqX5iIhx1K3qWulSLrEwz9w64wgeZtJB4=.f89870b9-6c22-40fb-878b-775bab75f58d@github.com>
References: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
 <BYbLj5lr7SmjuqcgoM9jFap9TwbKcYYn3Pjp_hwFw6o=.324a1dc8-0472-491d-aa99-7e4cb6b2f3b1@github.com>
 <e80jvgtALcwJUCBfXH6Gwgyc2OVd7WD6d-UZo6R5FP8=.9c9ee966-2143-44b3-be0e-a3998d78d0d9@github.com>
 <dqCyB42bmMzB4Y3IQVIEegQal6oaYPQxLE0bCmSyJ2A=.6340311e-bbe0-4f19-a5a8-c9c3e060979c@github.com>
 <VK3Jw66A1bOqX5iIhx1K3qWulSLrEwz9w64wgeZtJB4=.f89870b9-6c22-40fb-878b-775bab75f58d@github.com>
Message-ID: <JS6LYc1LjkRRgQSEqcAmxte67z9-35VHoxYtFoK2Nfc=.a7caea69-b303-44c5-af4d-0dbedde3fcb9@github.com>

On Tue, 7 Nov 2023 21:13:34 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> No, we did not change this in the tier testing. I was referring to the Graal CI.

Thanks for the info. Does this mean that the Graal CI is running its own Tier[1-8]
definitions and not the same Tier[1-8] as the main JDK repo?

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

PR Comment: https://git.openjdk.org/jdk/pull/16383#issuecomment-1800221785

From dcubed at openjdk.org  Tue Nov  7 21:51:09 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 7 Nov 2023 21:51:09 GMT
Subject: RFR: 8318694: [JVMCI] disable can_call_java in most contexts for
 libjvmci compiler threads [v7]
In-Reply-To: <aHYZTp5W5NBWigyOgQ0k0T5JQdDBA_dECcnLHb_ZU6M=.e56bbe59-2109-47c4-91e7-bc4d0d505fea@github.com>
References: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
 <aHYZTp5W5NBWigyOgQ0k0T5JQdDBA_dECcnLHb_ZU6M=.e56bbe59-2109-47c4-91e7-bc4d0d505fea@github.com>
Message-ID: <D3rJCf2pwS6QvnFHWETG7TiG2oEtC8w6f_PhDwqODFg=.a23256c0-c9c2-4210-9710-426c41ac09a1@github.com>

On Wed, 1 Nov 2023 13:33:32 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR reduces the context in which a libjvmci CompilerThread can make a Java call. By default, a CompileThread for a JVMCI compiler can make Java calls (as jarjvmci only works that way). When libjvmci calls into the VM via a CompilerToVM native method, it enters a scope where Java calls are disabled until either the call returns or a nested scope is entered that re-enables Java calls. The latter is required for the Truffle use case described in [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694) as well as for a few other VM entry points where libgraal currently still requires the ability to make Java calls (e.g. to load the Java classes used for boxing primitives). We may be able to eventually eliminate all need for libgraal to make Java calls but this PR is a first step in the right direction.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert assertions about can_call_java to guarantees

I meant does that mean that Graal CI is running its own Graal-Tier[1-N] and it not
running the same Tier[1-8] definitions as the main JDK repo at all?

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

PR Comment: https://git.openjdk.org/jdk/pull/16383#issuecomment-1800232912

From dnsimon at openjdk.org  Tue Nov  7 21:54:08 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 7 Nov 2023 21:54:08 GMT
Subject: RFR: 8318694: [JVMCI] disable can_call_java in most contexts for
 libjvmci compiler threads [v7]
In-Reply-To: <aHYZTp5W5NBWigyOgQ0k0T5JQdDBA_dECcnLHb_ZU6M=.e56bbe59-2109-47c4-91e7-bc4d0d505fea@github.com>
References: <cvOVQ1lpjLXeE1jxarAcbSCpitvsIDVTVC4rTgx3kyU=.6ca999c6-9f10-48b7-8fed-75e29c808a7f@github.com>
 <aHYZTp5W5NBWigyOgQ0k0T5JQdDBA_dECcnLHb_ZU6M=.e56bbe59-2109-47c4-91e7-bc4d0d505fea@github.com>
Message-ID: <nOciDmL8-uoz2nLXBp4bIJuUYaEMMF3lfxXpmXfhOBI=.f8e36ef1-7135-4af5-b475-ab3f211b9e45@github.com>

On Wed, 1 Nov 2023 13:33:32 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR reduces the context in which a libjvmci CompilerThread can make a Java call. By default, a CompileThread for a JVMCI compiler can make Java calls (as jarjvmci only works that way). When libjvmci calls into the VM via a CompilerToVM native method, it enters a scope where Java calls are disabled until either the call returns or a nested scope is entered that re-enables Java calls. The latter is required for the Truffle use case described in [JDK-8318694](https://bugs.openjdk.org/browse/JDK-8318694) as well as for a few other VM entry points where libgraal currently still requires the ability to make Java calls (e.g. to load the Java classes used for boxing primitives). We may be able to eventually eliminate all need for libgraal to make Java calls but this PR is a first step in the right direction.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert assertions about can_call_java to guarantees

The Graal CI system is completely disjoint from mach5-based JDK testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/16383#issuecomment-1800238885

From amitkumar at openjdk.org  Wed Nov  8 04:36:53 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 8 Nov 2023 04:36:53 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <yMm8dccKyhmu3glz-hLgP8V81EYvwFASjEUItwKGlHI=.692202d3-87e0-4c0e-9daf-1b4df9af36b9@github.com>

On Thu, 2 Nov 2023 22:17:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.

`s390x` also run into assert failure: `assert(masm->inst_mark() == nullptr) failed: should be.`


V  [libjvm.so+0xfb0938]  PhaseOutput::fill_buffer(C2_MacroAssembler*, unsigned int*)+0x2370  (output.cpp:1812)
V  [libjvm.so+0xfb21ce]  PhaseOutput::Output()+0xcae  (output.cpp:362)
V  [libjvm.so+0x6a90a8]  Compile::Code_Gen()+0x460  (compile.cpp:2989)
V  [libjvm.so+0x6ad848]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1738  (compile.cpp:887)
V  [libjvm.so+0x4fb932]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x14a  (c2compiler.cpp:119)
V  [libjvm.so+0x6b81a2]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd9a  (compileBroker.cpp:2282)
V  [libjvm.so+0x6b8eaa]  CompileBroker::compiler_thread_loop()+0x5a2  (compileBroker.cpp:1943)

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1801070622

From cslucas at openjdk.org  Wed Nov  8 16:51:00 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 8 Nov 2023 16:51:00 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <BJtlt-cQZXjDRa0F5QbiqHe_3y-Ih58tlRScZy1H-Ps=.86398c74-3a29-4b8b-b7c6-9e7b6a75cdf9@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <BJtlt-cQZXjDRa0F5QbiqHe_3y-Ih58tlRScZy1H-Ps=.86398c74-3a29-4b8b-b7c6-9e7b6a75cdf9@github.com>
Message-ID: <ijV6S7yy1MtQ0DN9fTc_2s4TkVKfFegnWMQ-mGjnmbQ=.81b14c8b-f414-4988-948a-298767d3c33e@github.com>

On Thu, 2 Nov 2023 23:21:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>
> PPC64 runs into assert(masm->inst_mark() == nullptr) failed: should be.
> V  [libjvm.so+0x1648528]  PhaseOutput::fill_buffer(C2_MacroAssembler*, unsigned int*)+0x10c8  (output.cpp:1812)
> V  [libjvm.so+0x164b35c]  PhaseOutput::Output()+0xd5c  (output.cpp:362)
> V  [libjvm.so+0x958f9c]  Compile::Code_Gen()+0x4ec  (compile.cpp:2989)
> V  [libjvm.so+0x95e484]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1a84  (compile.cpp:887)
> V  [libjvm.so+0x718f58]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x198  (c2compiler.cpp:119)

Thank you for helping with test @TheRealMDoerr @offamitkumar @RealFYang . I working on an update and I'll push it today or soon after.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1802277112

From dnsimon at openjdk.org  Wed Nov  8 20:45:09 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 8 Nov 2023 20:45:09 GMT
Subject: RFR: 8319748: [JVMCI] TestUseCompressedOopsFlagsWithUlimit.java
 crashes on libgraal
Message-ID: <WFuB_9gNS1QNtR_DNTAeObhQ0HgzePSGa7RrSCAdmgc=.05b91d7e-23ea-4f57-af82-8b50086f24b7@github.com>

The memory allocated in libjvmci for the error message describing a failure in `JNI_CreateJavaVM` must not be freed with `os::free` as the allocation was not NMT-aware.

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

Commit messages:
 - do not use os::free for memory allocated in libjvmci

Changes: https://git.openjdk.org/jdk/pull/16571/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16571&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319748
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16571.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16571/head:pull/16571

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

From never at openjdk.org  Wed Nov  8 21:26:57 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 8 Nov 2023 21:26:57 GMT
Subject: RFR: 8319748: [JVMCI] TestUseCompressedOopsFlagsWithUlimit.java
 crashes on libgraal
In-Reply-To: <WFuB_9gNS1QNtR_DNTAeObhQ0HgzePSGa7RrSCAdmgc=.05b91d7e-23ea-4f57-af82-8b50086f24b7@github.com>
References: <WFuB_9gNS1QNtR_DNTAeObhQ0HgzePSGa7RrSCAdmgc=.05b91d7e-23ea-4f57-af82-8b50086f24b7@github.com>
Message-ID: <9njmaCsISHDMa-Au6TO6KIwfznfR9n4V39S0h00kJEY=.652b826a-f73c-4650-b4fd-616679e35d94@github.com>

On Wed, 8 Nov 2023 20:38:19 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The memory allocated in libjvmci for the error message describing a failure in `JNI_CreateJavaVM` must not be freed with `os::free` as the allocation was not NMT-aware.

Marked as reviewed by never (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16571#pullrequestreview-1721301940

From dnsimon at openjdk.org  Wed Nov  8 22:32:11 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 8 Nov 2023 22:32:11 GMT
Subject: RFR: 8319748: [JVMCI] TestUseCompressedOopsFlagsWithUlimit.java
 crashes on libgraal [v2]
In-Reply-To: <WFuB_9gNS1QNtR_DNTAeObhQ0HgzePSGa7RrSCAdmgc=.05b91d7e-23ea-4f57-af82-8b50086f24b7@github.com>
References: <WFuB_9gNS1QNtR_DNTAeObhQ0HgzePSGa7RrSCAdmgc=.05b91d7e-23ea-4f57-af82-8b50086f24b7@github.com>
Message-ID: <L6kVebpMJZK2nSFNNcV7d1BKw-GGHHtR7Ne50372koc=.15ef5330-8b23-4c8a-bd8e-589715569c00@github.com>

> The memory allocated in libjvmci for the error message describing a failure in `JNI_CreateJavaVM` must not be freed with `os::free` as the allocation was not NMT-aware.

Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8319748
 - do not use os::free for memory allocated in libjvmci

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16571/files
  - new: https://git.openjdk.org/jdk/pull/16571/files/718c3469..53ca2db0

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

  Stats: 11468 lines in 131 files changed: 2383 ins; 7952 del; 1133 mod
  Patch: https://git.openjdk.org/jdk/pull/16571.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16571/head:pull/16571

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

From thartmann at openjdk.org  Thu Nov  9 06:21:56 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 9 Nov 2023 06:21:56 GMT
Subject: RFR: 8319748: [JVMCI] TestUseCompressedOopsFlagsWithUlimit.java
 crashes on libgraal [v2]
In-Reply-To: <L6kVebpMJZK2nSFNNcV7d1BKw-GGHHtR7Ne50372koc=.15ef5330-8b23-4c8a-bd8e-589715569c00@github.com>
References: <WFuB_9gNS1QNtR_DNTAeObhQ0HgzePSGa7RrSCAdmgc=.05b91d7e-23ea-4f57-af82-8b50086f24b7@github.com>
 <L6kVebpMJZK2nSFNNcV7d1BKw-GGHHtR7Ne50372koc=.15ef5330-8b23-4c8a-bd8e-589715569c00@github.com>
Message-ID: <CCVVGYLjh3TVTfyzRkw24Vf4qj3e8BENORD1wzsNLtk=.beec6b1b-3092-49ed-949f-1cc9badd7574@github.com>

On Wed, 8 Nov 2023 22:32:11 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The memory allocated in libjvmci for the error message describing a failure in `JNI_CreateJavaVM` must not be freed with `os::free` as the allocation was not NMT-aware.
>
> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8319748
>  - do not use os::free for memory allocated in libjvmci

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16571#pullrequestreview-1721783433

From dnsimon at openjdk.org  Thu Nov  9 10:51:12 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 9 Nov 2023 10:51:12 GMT
Subject: RFR: 8319748: [JVMCI] TestUseCompressedOopsFlagsWithUlimit.java
 crashes on libgraal [v2]
In-Reply-To: <L6kVebpMJZK2nSFNNcV7d1BKw-GGHHtR7Ne50372koc=.15ef5330-8b23-4c8a-bd8e-589715569c00@github.com>
References: <WFuB_9gNS1QNtR_DNTAeObhQ0HgzePSGa7RrSCAdmgc=.05b91d7e-23ea-4f57-af82-8b50086f24b7@github.com>
 <L6kVebpMJZK2nSFNNcV7d1BKw-GGHHtR7Ne50372koc=.15ef5330-8b23-4c8a-bd8e-589715569c00@github.com>
Message-ID: <qvkLMRU3PZg6u7V-FwUfxGTDrPb7Jx91xl_p43oR_5A=.9833c6ec-5606-491e-8756-57a8829933b8@github.com>

On Wed, 8 Nov 2023 22:32:11 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The memory allocated in libjvmci for the error message describing a failure in `JNI_CreateJavaVM` must not be freed with `os::free` as the allocation was not NMT-aware.
>
> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8319748
>  - do not use os::free for memory allocated in libjvmci

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/16571#issuecomment-1803594558

From dnsimon at openjdk.org  Thu Nov  9 10:51:14 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 9 Nov 2023 10:51:14 GMT
Subject: Integrated: 8319748: [JVMCI] TestUseCompressedOopsFlagsWithUlimit.java
 crashes on libgraal
In-Reply-To: <WFuB_9gNS1QNtR_DNTAeObhQ0HgzePSGa7RrSCAdmgc=.05b91d7e-23ea-4f57-af82-8b50086f24b7@github.com>
References: <WFuB_9gNS1QNtR_DNTAeObhQ0HgzePSGa7RrSCAdmgc=.05b91d7e-23ea-4f57-af82-8b50086f24b7@github.com>
Message-ID: <sKCAzds_YOtGV2zc_HoKkqgbpGJwTQXP0d5Pzrt__q4=.8c2a1184-d9d7-4df8-8300-421709f0f0bc@github.com>

On Wed, 8 Nov 2023 20:38:19 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The memory allocated in libjvmci for the error message describing a failure in `JNI_CreateJavaVM` must not be freed with `os::free` as the allocation was not NMT-aware.

This pull request has now been integrated.

Changeset: 4451a927
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4451a927bc151b23246f733e8eb892080dd693af
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8319748: [JVMCI] TestUseCompressedOopsFlagsWithUlimit.java crashes on libgraal

Reviewed-by: never, thartmann

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

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

From kvn at openjdk.org  Fri Nov 17 16:16:47 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 17 Nov 2023 16:16:47 GMT
Subject: RFR: 8320272: Make method_entry_barrier address shared
Message-ID: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>

Currently all platforms have declared their own address variable for method_entry_barrier stub. Some have even slightly different name: nmethod_entry_barrier. For Leyden project one address is preferable.
In aarch64 code changed `movptr` to `lea` instruction to get relocation info as on x86.

Tested x86 and aarch64, tier1-4, xcomp, stress.  I need help to test on other platforms. Thanks!

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

Commit messages:
 - 8320272: Make method_entry_barrier address shared

Changes: https://git.openjdk.org/jdk/pull/16708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16708&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320272
  Stats: 63 lines in 32 files changed: 5 ins; 37 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/16708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16708/head:pull/16708

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

From kvn at openjdk.org  Fri Nov 17 18:30:30 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 17 Nov 2023 18:30:30 GMT
Subject: RFR: 8320272: Make method_entry_barrier address shared
In-Reply-To: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
References: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
Message-ID: <gcZt4FuELloP2o19ZR1Hj_w1FOBAiFg41wKsz4ax6lk=.cf80c265-3515-4907-9fb4-e97438d37d99@github.com>

On Fri, 17 Nov 2023 16:10:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Currently all platforms have declared their own address variable for method_entry_barrier stub. Some have even slightly different name: nmethod_entry_barrier. For Leyden project one address is preferable.
> In aarch64 code changed `movptr` to `lea` instruction to get relocation info as on x86.
> 
> Tested x86 and aarch64, tier1-4, xcomp, stress.  I need help to test on other platforms. Thanks!

Arm (32-bit) cross build is broken by recent changes [8301997](https://github.com/openjdk/jdk/commit/ffa35d8cf181cfbcb54497e997dbd18a9b62b97e)

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

PR Comment: https://git.openjdk.org/jdk/pull/16708#issuecomment-1816897098

From dlong at openjdk.org  Fri Nov 17 22:11:30 2023
From: dlong at openjdk.org (Dean Long)
Date: Fri, 17 Nov 2023 22:11:30 GMT
Subject: RFR: 8320272: Make method_entry_barrier address shared
In-Reply-To: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
References: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
Message-ID: <7FwjBlfdMsgPdHcdOer9mZsQDQ0PamT8qLzCzdq14z4=.ef428fec-764a-4a28-94f2-4ccbd9c6b3d4@github.com>

On Fri, 17 Nov 2023 16:10:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Currently all platforms have declared their own address variable for method_entry_barrier stub. Some have even slightly different name: nmethod_entry_barrier. For Leyden project one address is preferable.
> In aarch64 code changed `movptr` to `lea` instruction to get relocation info as on x86.
> 
> Tested x86 and aarch64, tier1-4, xcomp, stress.  I need help to test on other platforms. Thanks!

This seems fine, but you could explain a little more why this is useful for Leyden?  I would think having StubRoutines::method_entry_barrier() would be enough, and that it could reference the existing platform-specific name, minimizing changes.  I don't understand why the storage needs to be shared in StubRoutines::_method_entry_barrier, for example.

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

PR Comment: https://git.openjdk.org/jdk/pull/16708#issuecomment-1817176789

From kvn at openjdk.org  Fri Nov 17 22:39:28 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 17 Nov 2023 22:39:28 GMT
Subject: RFR: 8320272: Make method_entry_barrier address shared
In-Reply-To: <7FwjBlfdMsgPdHcdOer9mZsQDQ0PamT8qLzCzdq14z4=.ef428fec-764a-4a28-94f2-4ccbd9c6b3d4@github.com>
References: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
 <7FwjBlfdMsgPdHcdOer9mZsQDQ0PamT8qLzCzdq14z4=.ef428fec-764a-4a28-94f2-4ccbd9c6b3d4@github.com>
Message-ID: <Zje59kVIbUjZM5g_i5MaoHO8noz0dM4XnUTWpTeNrZA=.d8b14ce4-494f-4570-9a90-cb742ae18351@github.com>

On Fri, 17 Nov 2023 22:09:09 GMT, Dean Long <dlong at openjdk.org> wrote:

> This seems fine, but you could explain a little more why this is useful for Leyden? I would think having StubRoutines::method_entry_barrier() would be enough, and that it could reference the existing platform-specific name, minimizing changes. I don't understand why the storage needs to be shared in StubRoutines::_method_entry_barrier, for example.

Thank you for looking, Dean. Yes, your suggestion would work too. Leyden code calls StubRoutines::method_entry_barrier() to get address: [SCCache.cpp#L3337](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp#L3337)
But we would need StubRoutines::method_entry_barrier()  implementation for each platform in such case. And having duplication and different names does not feel right for me ;^)

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

PR Comment: https://git.openjdk.org/jdk/pull/16708#issuecomment-1817207215

From never at openjdk.org  Sat Nov 18 00:27:29 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Sat, 18 Nov 2023 00:27:29 GMT
Subject: RFR: 8320272: Make method_entry_barrier address shared
In-Reply-To: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
References: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
Message-ID: <hiDV__0lMjYOd4Hq7SdmoEXtPYW1O-7PPbRb6gSMiBc=.f89cb691-53f1-45bd-85c8-609bf0d7643a@github.com>

On Fri, 17 Nov 2023 16:10:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Currently all platforms have declared their own address variable for method_entry_barrier stub. Some have even slightly different name: nmethod_entry_barrier. For Leyden project one address is preferable.
> In aarch64 code changed `movptr` to `lea` instruction to get relocation info as on x86.
> 
> Tested x86 and aarch64, tier1-4, xcomp, stress.  I need help to test on other platforms. Thanks!

src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 150:

> 148:     thread_disarmed_guard_value_offset = in_bytes(bs_nm->thread_disarmed_guard_value_offset());
> 149:     AMD64_ONLY(nmethod_entry_barrier = StubRoutines::method_entry_barrier());
> 150:     AARCH64_ONLY(nmethod_entry_barrier = StubRoutines::method_entry_barrier());

Now that's there's a single name you can remove the 2 per arch definitions in favor of single assignment statement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16708#discussion_r1398009834

From dlong at openjdk.org  Sat Nov 18 00:31:27 2023
From: dlong at openjdk.org (Dean Long)
Date: Sat, 18 Nov 2023 00:31:27 GMT
Subject: RFR: 8320272: Make method_entry_barrier address shared
In-Reply-To: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
References: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
Message-ID: <q3whg4fKgesNgrbHxWxG5I6D9a0gyWWn8Ph0ABC6FN8=.5884c124-321c-4e3a-8629-d4a9c85a6031@github.com>

On Fri, 17 Nov 2023 16:10:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Currently all platforms have declared their own address variable for method_entry_barrier stub. Some have even slightly different name: nmethod_entry_barrier. For Leyden project one address is preferable.
> In aarch64 code changed `movptr` to `lea` instruction to get relocation info as on x86.
> 
> Tested x86 and aarch64, tier1-4, xcomp, stress.  I need help to test on other platforms. Thanks!

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16708#pullrequestreview-1738124382

From kvn at openjdk.org  Sun Nov 19 20:50:50 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 19 Nov 2023 20:50:50 GMT
Subject: RFR: 8320272: Make method_entry_barrier address shared [v2]
In-Reply-To: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
References: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
Message-ID: <YAGJ6bHuQtG6yEOCeEdyIzJe_Z0lBQbrwMx7gBz6luI=.803475c3-ba95-4462-a7db-7987f0df28ea@github.com>

> Currently all platforms have declared their own address variable for method_entry_barrier stub. Some have even slightly different name: nmethod_entry_barrier. For Leyden project one address is preferable.
> In aarch64 code changed `movptr` to `lea` instruction to get relocation info as on x86.
> 
> Tested x86 and aarch64, tier1-4, xcomp, stress.  I need help to test on other platforms. Thanks!

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  address comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16708/files
  - new: https://git.openjdk.org/jdk/pull/16708/files/359135e5..3af07981

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

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

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

From kvn at openjdk.org  Sun Nov 19 20:50:51 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 19 Nov 2023 20:50:51 GMT
Subject: RFR: 8320272: Make method_entry_barrier address shared [v2]
In-Reply-To: <hiDV__0lMjYOd4Hq7SdmoEXtPYW1O-7PPbRb6gSMiBc=.f89cb691-53f1-45bd-85c8-609bf0d7643a@github.com>
References: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
 <hiDV__0lMjYOd4Hq7SdmoEXtPYW1O-7PPbRb6gSMiBc=.f89cb691-53f1-45bd-85c8-609bf0d7643a@github.com>
Message-ID: <OxBxbNPjjnHZ1xIrz_MAEOfLAQqL2pqnwC-dq3sth_0=.cb43f4f6-593b-4f45-93f4-5c7efc391f41@github.com>

On Sat, 18 Nov 2023 00:24:47 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address comment
>
> src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 150:
> 
>> 148:     thread_disarmed_guard_value_offset = in_bytes(bs_nm->thread_disarmed_guard_value_offset());
>> 149:     AMD64_ONLY(nmethod_entry_barrier = StubRoutines::method_entry_barrier());
>> 150:     AARCH64_ONLY(nmethod_entry_barrier = StubRoutines::method_entry_barrier());
> 
> Now that's there's a single name you can remove the 2 per arch definitions in favor of single assignment statement.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16708#discussion_r1398491708

From fyang at openjdk.org  Mon Nov 20 04:17:33 2023
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 20 Nov 2023 04:17:33 GMT
Subject: RFR: 8320272: Make method_entry_barrier address shared
In-Reply-To: <Zje59kVIbUjZM5g_i5MaoHO8noz0dM4XnUTWpTeNrZA=.d8b14ce4-494f-4570-9a90-cb742ae18351@github.com>
References: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
 <7FwjBlfdMsgPdHcdOer9mZsQDQ0PamT8qLzCzdq14z4=.ef428fec-764a-4a28-94f2-4ccbd9c6b3d4@github.com>
 <Zje59kVIbUjZM5g_i5MaoHO8noz0dM4XnUTWpTeNrZA=.d8b14ce4-494f-4570-9a90-cb742ae18351@github.com>
Message-ID: <QakINzNEVBOYkJkY0em5xfW6fjiPpAk1Cqca0_ltMZU=.61218487-f745-4612-9955-8c6267504e75@github.com>

On Fri, 17 Nov 2023 22:36:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This seems fine, but you could explain a little more why this is useful for Leyden?  I would think having StubRoutines::method_entry_barrier() would be enough, and that it could reference the existing platform-specific name, minimizing changes.  I don't understand why the storage needs to be shared in StubRoutines::_method_entry_barrier, for example.
>
>> This seems fine, but you could explain a little more why this is useful for Leyden? I would think having StubRoutines::method_entry_barrier() would be enough, and that it could reference the existing platform-specific name, minimizing changes. I don't understand why the storage needs to be shared in StubRoutines::_method_entry_barrier, for example.
> 
> Thank you for looking, Dean. Yes, your suggestion would work too. Leyden code calls StubRoutines::method_entry_barrier() to get address: [SCCache.cpp#L3337](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp#L3337)
> But we would need StubRoutines::method_entry_barrier()  implementation for each platform in such case. And having duplication and different names does not feel right for me ;^)

@vnkozlov : Hi, I have tested this on linux-riscv platform. Result looks fine.
Would you mind apply following small add-on change which adds relocation info for this platform too? Thanks.
[16708-riscv.diff.txt](https://github.com/openjdk/jdk/files/13406179/16708-riscv.diff.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/16708#issuecomment-1818200214

From kvn at openjdk.org  Mon Nov 20 18:25:52 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 20 Nov 2023 18:25:52 GMT
Subject: RFR: 8320272: Make method_entry_barrier address shared [v3]
In-Reply-To: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
References: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
Message-ID: <SEfVOk20cwNrIwckf1cARO_7ApXMv5SKpqpP5Gx5vSo=.3f432223-d97a-46da-898d-f941fb00d99b@github.com>

> Currently all platforms have declared their own address variable for method_entry_barrier stub. Some have even slightly different name: nmethod_entry_barrier. For Leyden project one address is preferable.
> In aarch64 code changed `movptr` to `lea` instruction to get relocation info as on x86.
> 
> Tested x86 and aarch64, tier1-4, xcomp, stress.  I need help to test on other platforms. Thanks!

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Addition RISC-V patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16708/files
  - new: https://git.openjdk.org/jdk/pull/16708/files/3af07981..bbf946c6

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

  Stats: 16 lines in 2 files changed: 10 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16708/head:pull/16708

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

From kvn at openjdk.org  Mon Nov 20 18:25:54 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 20 Nov 2023 18:25:54 GMT
Subject: RFR: 8320272: Make method_entry_barrier address shared
In-Reply-To: <QakINzNEVBOYkJkY0em5xfW6fjiPpAk1Cqca0_ltMZU=.61218487-f745-4612-9955-8c6267504e75@github.com>
References: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
 <7FwjBlfdMsgPdHcdOer9mZsQDQ0PamT8qLzCzdq14z4=.ef428fec-764a-4a28-94f2-4ccbd9c6b3d4@github.com>
 <Zje59kVIbUjZM5g_i5MaoHO8noz0dM4XnUTWpTeNrZA=.d8b14ce4-494f-4570-9a90-cb742ae18351@github.com>
 <QakINzNEVBOYkJkY0em5xfW6fjiPpAk1Cqca0_ltMZU=.61218487-f745-4612-9955-8c6267504e75@github.com>
Message-ID: <q588k0-XTNBOb9-gP1SMun2Y6cANKt1lhXY_9OjvXEY=.7abb678d-3a2c-4982-ae5e-8aa820d43666@github.com>

On Mon, 20 Nov 2023 04:14:57 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> This seems fine, but you could explain a little more why this is useful for Leyden? I would think having StubRoutines::method_entry_barrier() would be enough, and that it could reference the existing platform-specific name, minimizing changes. I don't understand why the storage needs to be shared in StubRoutines::_method_entry_barrier, for example.
>> 
>> Thank you for looking, Dean. Yes, your suggestion would work too. Leyden code calls StubRoutines::method_entry_barrier() to get address: [SCCache.cpp#L3337](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp#L3337)
>> But we would need StubRoutines::method_entry_barrier()  implementation for each platform in such case. And having duplication and different names does not feel right for me ;^)
>
> @vnkozlov : Hi, I have tested this on linux-riscv platform. Result looks fine.
> Would you mind apply following small add-on change which adds relocation info for this platform too? Thanks.
> [16708-riscv.diff.txt](https://github.com/openjdk/jdk/files/13406179/16708-riscv.diff.txt)

Thank you, @RealFYang, for testing. I applied your patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/16708#issuecomment-1819584853

From kvn at openjdk.org  Tue Nov 21 16:51:18 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 21 Nov 2023 16:51:18 GMT
Subject: Integrated: 8320272: Make method_entry_barrier address shared
In-Reply-To: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
References: <32KZcukg8d6Fjn0bnPQIa-X4q_o8DU0XtcHYA5YT468=.c9f33a2d-215d-404c-822b-448c8fd443d4@github.com>
Message-ID: <7nP-iFYNkh_-yiUqE69FmAdNC5mKOhk0XCl7X_4ZCHI=.4ea0ea93-153c-4783-a733-9b0e2aa411ce@github.com>

On Fri, 17 Nov 2023 16:10:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Currently all platforms have declared their own address variable for method_entry_barrier stub. Some have even slightly different name: nmethod_entry_barrier. For Leyden project one address is preferable.
> In aarch64 code changed `movptr` to `lea` instruction to get relocation info as on x86.
> 
> Tested x86 and aarch64, tier1-4, xcomp, stress.  I need help to test on other platforms. Thanks!

This pull request has now been integrated.

Changeset: c4aba875
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4aba875708f1701e8f1b6fa9676f42e235ec461
Stats:     77 lines in 32 files changed: 15 ins; 41 del; 21 mod

8320272: Make method_entry_barrier address shared

Reviewed-by: dlong

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

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

From cslucas at openjdk.org  Tue Nov 21 17:58:35 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 21 Nov 2023 17:58:35 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v2]
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <eNpS7tbWtMBTrYSjB8UmDJOf3Qno02YB4VZTFNUjVSg=.857e56be-2e67-4379-a300-cb31abac4c22@github.com>

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
> 
> # Testing status
> 
> ## tier1
> 
> |          |   Win   |   Mac   |  Linux  |
> |----------|---------|---------|---------|
> | ARM64    |         |         |         |
> | ARM32    |         |         |         |
> | x86      |         |         |         |
> | x64      |         |         |         |
> | PPC64    |         |         |         |
> | S390x    |         |         |         |
> | RiscV    |         |         |         |

Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Catch up with changes on master
 - Reuse same C2_MacroAssembler object to emit instructions.

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

Changes: https://git.openjdk.org/jdk/pull/16484/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16484&range=01
  Stats: 3356 lines in 60 files changed: 1039 ins; 426 del; 1891 mod
  Patch: https://git.openjdk.org/jdk/pull/16484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16484/head:pull/16484

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

From dnsimon at openjdk.org  Thu Nov 23 23:26:30 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 23 Nov 2023 23:26:30 GMT
Subject: RFR: 8320679: [JVMCI] invalid code in PushLocalFrame event message
Message-ID: <6OE1zi5HnO7VeZVjz1yFSSnNendoQFsqyR-zK0HmN5g=.defa291d-ad24-4ca9-982b-32d2a3b68442@github.com>

This is a trivial fix to the JVMCI event logged when PushLocalFrame fails in a new libjvmci env. It must report the value of `result`, not `_init_error`.

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

Commit messages:
 - use correct variable containing PushLocalFrame return code

Changes: https://git.openjdk.org/jdk/pull/16803/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16803&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320679
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16803.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16803/head:pull/16803

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

From never at openjdk.org  Thu Nov 23 23:32:02 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 23 Nov 2023 23:32:02 GMT
Subject: RFR: 8320679: [JVMCI] invalid code in PushLocalFrame event message
In-Reply-To: <6OE1zi5HnO7VeZVjz1yFSSnNendoQFsqyR-zK0HmN5g=.defa291d-ad24-4ca9-982b-32d2a3b68442@github.com>
References: <6OE1zi5HnO7VeZVjz1yFSSnNendoQFsqyR-zK0HmN5g=.defa291d-ad24-4ca9-982b-32d2a3b68442@github.com>
Message-ID: <HEdC_Z0EM8Ey_KfpjjEsrKk7cnXnI-C0CSe1UlczoB0=.f5ddff6d-436b-4e32-a413-94c5f2209b62@github.com>

On Thu, 23 Nov 2023 23:12:27 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This is a trivial fix to the JVMCI event logged when PushLocalFrame fails in a new libjvmci env. It must report the value of `result`, not `_init_error`.

Marked as reviewed by never (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16803#pullrequestreview-1747089936

From dnsimon at openjdk.org  Thu Nov 23 23:39:13 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 23 Nov 2023 23:39:13 GMT
Subject: RFR: 8320679: [JVMCI] invalid code in PushLocalFrame event message
In-Reply-To: <6OE1zi5HnO7VeZVjz1yFSSnNendoQFsqyR-zK0HmN5g=.defa291d-ad24-4ca9-982b-32d2a3b68442@github.com>
References: <6OE1zi5HnO7VeZVjz1yFSSnNendoQFsqyR-zK0HmN5g=.defa291d-ad24-4ca9-982b-32d2a3b68442@github.com>
Message-ID: <PwgOFCPD3CY11OaFA8wP0LRxg2psaMD-541o5Q-7XJA=.ee725a85-dab2-4f7c-9d79-54eada61a499@github.com>

On Thu, 23 Nov 2023 23:12:27 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This is a trivial fix to the JVMCI event logged when PushLocalFrame fails in a new libjvmci env. It must report the value of `result`, not `_init_error`.

Thanks for the review. I'm integrating this based on a single review given how trivial the change is.

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

PR Comment: https://git.openjdk.org/jdk/pull/16803#issuecomment-1824995257

From dnsimon at openjdk.org  Thu Nov 23 23:39:14 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 23 Nov 2023 23:39:14 GMT
Subject: Integrated: 8320679: [JVMCI] invalid code in PushLocalFrame event
 message
In-Reply-To: <6OE1zi5HnO7VeZVjz1yFSSnNendoQFsqyR-zK0HmN5g=.defa291d-ad24-4ca9-982b-32d2a3b68442@github.com>
References: <6OE1zi5HnO7VeZVjz1yFSSnNendoQFsqyR-zK0HmN5g=.defa291d-ad24-4ca9-982b-32d2a3b68442@github.com>
Message-ID: <y8_f5gt5x3L98pEm4ibTPzbhVQ-8lAcct7qXD26km84=.20ed13a6-38c6-45fb-babd-2b01bb876108@github.com>

On Thu, 23 Nov 2023 23:12:27 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This is a trivial fix to the JVMCI event logged when PushLocalFrame fails in a new libjvmci env. It must report the value of `result`, not `_init_error`.

This pull request has now been integrated.

Changeset: df1b896e
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df1b896e01f4e7feeff90c1836aa395201fc4e4e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8320679: [JVMCI] invalid code in PushLocalFrame event message

Reviewed-by: never

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

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

From cslucas at openjdk.org  Wed Nov 29 19:30:24 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 29 Nov 2023 19:30:24 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v3]
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <hvtbVfw1oUP70vZ0432X-3F1hHylcFqOH1xkJJ7SrAY=.af5e7218-7e02-42db-a03f-a7804024ba3a@github.com>

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
> 
> # Testing status
> 
> ## tier1
> 
> |          |   Win   |   Mac   |  Linux  |
> |----------|---------|---------|---------|
> | ARM64    |         |         |         |
> | ARM32    |         |         |         |
> | x86      |         |         |         |
> | x64      |         |         |         |
> | PPC64    |         |         |         |
> | S390x    |         |         |         |
> | RiscV    |         |         |         |

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Some inst_mark fixes; Catch up with master.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16484/files
  - new: https://git.openjdk.org/jdk/pull/16484/files/b56c98de..89a6dff3

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

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

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

From cslucas at openjdk.org  Wed Nov 29 22:40:35 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 29 Nov 2023 22:40:35 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v4]
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <h1AmMexga4JM1boU-1EEIk0dX_7EHkxk9RD8V9myD9s=.b736a16c-09fd-4854-94b5-a488cb86f4e1@github.com>

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
> 
> # Testing status
> 
> ## tier1
> 
> |          |   Win   |   Mac   |  Linux  |
> |----------|---------|---------|---------|
> | ARM64    |         |         |         |
> | ARM32    |         |         |         |
> | x86      |         |         |         |
> | x64      |         |         |         |
> | PPC64    |         |         |         |
> | S390x    |         |         |         |
> | RiscV    |         |         |         |

Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Fix merge
 - Catch up with master branch.
   
   Merge remote-tracking branch 'origin/master' into reuse-macroasm
 - Some inst_mark fixes; Catch up with master.
 - Catch up with changes on master
 - Reuse same C2_MacroAssembler object to emit instructions.

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

Changes: https://git.openjdk.org/jdk/pull/16484/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16484&range=03
  Stats: 2433 lines in 60 files changed: 106 ins; 433 del; 1894 mod
  Patch: https://git.openjdk.org/jdk/pull/16484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16484/head:pull/16484

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

From haosun at openjdk.org  Thu Nov 30 09:31:26 2023
From: haosun at openjdk.org (Hao Sun)
Date: Thu, 30 Nov 2023 09:31:26 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v4]
In-Reply-To: <h1AmMexga4JM1boU-1EEIk0dX_7EHkxk9RD8V9myD9s=.b736a16c-09fd-4854-94b5-a488cb86f4e1@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <h1AmMexga4JM1boU-1EEIk0dX_7EHkxk9RD8V9myD9s=.b736a16c-09fd-4854-94b5-a488cb86f4e1@github.com>
Message-ID: <QxR5-i1pw6AYAwooADtSxVdjVcuKwQV8ahPv7bDp_G8=.b139b0f8-7d03-4b27-a883-69730d3c4be8@github.com>

On Wed, 29 Nov 2023 22:40:35 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Testing status
>> 
>> ## tier1
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |         |         |         |
>> | ARM32    |         |         |         |
>> | x86      |         |         |         |
>> | x64      |         |         |         |
>> | PPC64    |         |         |         |
>> | S390x    |         |         |         |
>> | RiscV    |         |         |         |
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - Catch up with changes on master
>  - Reuse same C2_MacroAssembler object to emit instructions.

We should update the copyright year for the following files:


src/hotspot/cpu/aarch64/gc/x/x_aarch64.ad
src/hotspot/cpu/arm/arm_32.ad
src/hotspot/cpu/ppc/gc/x/x_ppc.ad
src/hotspot/cpu/riscv/gc/x/x_riscv.ad
src/hotspot/cpu/x86/c2_intelJccErratum_x86.hpp
src/hotspot/cpu/x86/gc/x/x_x86_64.ad
src/hotspot/cpu/x86/x86_32.ad
src/hotspot/share/opto/c2_CodeStubs.hpp
src/hotspot/share/opto/constantTable.hpp

src/hotspot/cpu/aarch64/aarch64.ad line 2829:

> 2827:   enc_class aarch64_enc_ldrsbw(iRegI dst, memory1 mem) %{
> 2828:     Register dst_reg = as_Register($dst$$reg);
> 2829:     loadStore(masm, &MacroAssembler::ldrsbw, dst_reg, $mem->opcode(),

The block of code should be auto-generated by `ad_encode.m4` file. 
We'd better not edit these lines directly. Instead, we should update the m4 file accordingly.

src/hotspot/cpu/aarch64/aarch64_vector.ad line 122:

> 120:       }
> 121:       int imm4 = disp / mesize / Matcher::scalable_vector_reg_size(vector_elem_bt);
> 122:       (masm->*insn)(reg, Assembler::elemType_to_regVariant(vector_elem_bt), pg, Address(base, imm4));

this update is missing in the corresponding `aarch64_vector_ad.m4` file.
(that is, there is a mismatch between the ad file and the generated one.)

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

PR Review: https://git.openjdk.org/jdk/pull/16484#pullrequestreview-1756986982
PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1410387066
PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1410381293

From cslucas at openjdk.org  Thu Nov 30 17:38:16 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 30 Nov 2023 17:38:16 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v4]
In-Reply-To: <QxR5-i1pw6AYAwooADtSxVdjVcuKwQV8ahPv7bDp_G8=.b139b0f8-7d03-4b27-a883-69730d3c4be8@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <h1AmMexga4JM1boU-1EEIk0dX_7EHkxk9RD8V9myD9s=.b736a16c-09fd-4854-94b5-a488cb86f4e1@github.com>
 <QxR5-i1pw6AYAwooADtSxVdjVcuKwQV8ahPv7bDp_G8=.b139b0f8-7d03-4b27-a883-69730d3c4be8@github.com>
Message-ID: <j71QjUvXG0HSy8PKg0MYzpHBZYJ3T31SdrRWutU0pN0=.e6e1988c-3b11-410f-aaee-523849360310@github.com>

On Thu, 30 Nov 2023 09:24:12 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Fix merge
>>  - Catch up with master branch.
>>    
>>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>>  - Some inst_mark fixes; Catch up with master.
>>  - Catch up with changes on master
>>  - Reuse same C2_MacroAssembler object to emit instructions.
>
> src/hotspot/cpu/aarch64/aarch64.ad line 2829:
> 
>> 2827:   enc_class aarch64_enc_ldrsbw(iRegI dst, memory1 mem) %{
>> 2828:     Register dst_reg = as_Register($dst$$reg);
>> 2829:     loadStore(masm, &MacroAssembler::ldrsbw, dst_reg, $mem->opcode(),
> 
> The block of code should be auto-generated by `ad_encode.m4` file. 
> We'd better not edit these lines directly. Instead, we should update the m4 file accordingly.

Oops. I didn't see the comment there! Thank you for letting me know.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1411050332