8337396: Cleanup usage of ExternalAddess #20412

vnkozlov · 2024-07-31T23:42:36Z

ExternalAddess should be used only for data load. For calls (and jump) instructions we should use RuntimeAddress which uses runtime_call_Relocation.

I found few places where ExternalAddess is used incorrectly and fixed them.

I also added code to print "hottest" (most referenced) ExternalAddess addresses in global table to move them into static global tables which will be introduced by JDK-8334691 and JDK-8337519.

Here is current output from debug VM on MacBook M1 (Aarch64):

External addresses table: 6 entries, 324 accesses
0:      158 0x00000001082de0f0 : extn: vmClasses::_klasses+480
1:       84 0x00000001082ddf20 : extn: vmClasses::_klasses+16
2:       40 0x00000001082c4790 : extn: SharedRuntime::_partial_subtype_ctr
3:       24 0x00000001082bdb04 : extn: JvmtiExport::_should_notify_object_alloc
4:       18 0x0000000118384080 : stub: forward exception

on MacOS-x64:

External addresses table: 143 entries, 44405 accesses
0:    11766 0x00000001047922a0 : extn: CompressedOops::_narrow_oop
1:    11002 0x0000000104474384 : 'should not reach here'
2:     9672 0x0000000104581a90 : extn: ClassLoader::file_name_for_class_name(char const*, int)::class_suffix+882068
3:     2447 0x0000000104508005 : extn: ClassLoader::file_name_for_class_name(char const*, int)::class_suffix+383753
4:     1916 0x000000010458188e : extn: ClassLoader::file_name_for_class_name(char const*, int)::class_suffix+881554

and on linux-x64:

External addresses table: 143 entries, 77297 accesses
0:    22334 0x00007f35d5b9c000 : ''
1:    19789 0x00007f35d55eea1f : 'should not reach here'
2:    18366 0x00007f35d5747bb8 : 'MacroAssembler::decode_heap_oop: heap base corrupted?'
3:     5036 0x00007f35d56e4d40 : 'uncommon trap returned which should never happen'
4:     3643 0x00007f35d57479f8 : 'MacroAssembler::encode_heap_oop: heap base corrupted?'

Few points about difference in output:

aarch64 does not use ExternalAddess or any relocation for messages (strings).
stub: forward exception corresponds to StubRoutines::forward_exception_entry() for which C2 generates tail-call from C2's stubs. It is difficult to convert it to RuntimeAddress because how relocation for constants in C2 are handled.
linux-x64 implementation of dlladdr(), I used to print C++ symbol name, only works for functions:
0x00007f35d5b9c000 points to CompressedOops::_narrow_oop._base from code in MacroAssembler::verify_heapbase() and on aarch64 verify_heapbase() is empty (guarded by #if 0).
I think ClassLoader::file_name_for_class_name()+... on MacOSX-x64 corresponds to strings on linux-x64.

Additionally I moved asserts before locks in ExternalsRecorder methods.

Tested: tier1-3, xcomp, stress

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8337396: Cleanup usage of ExternalAddess (Sub-task - P4)

Reviewers

Andrew Dinn (@adinn - Reviewer) 🔄 Re-review required (review applies to 9bb7867f)
Vladimir Ivanov (@iwanowww - Reviewer)

Contributors

Fei Yang <fyang@openjdk.org>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/20412/head:pull/20412
$ git checkout pull/20412

Update a local copy of the PR:
$ git checkout pull/20412
$ git pull https://git.openjdk.org/jdk.git pull/20412/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 20412

View PR using the GUI difftool:
$ git pr show -t 20412

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/20412.diff

Webrev

Link to Webrev Comment

bridgekeeper · 2024-07-31T23:43:22Z

👋 Welcome back kvn! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2024-07-31T23:43:35Z

@vnkozlov This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8337396: Cleanup usage of ExternalAddess

Co-authored-by: Fei Yang <fyang@openjdk.org>
Reviewed-by: vlivanov, adinn

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 52 new commits pushed to the master branch:

7deee74: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc
f2e1205: 8337676: JFR: Change the label of the throttle setting
066db6e: 8337274: Remove repeated 'the' in StyleSheet.create{Small,Large}AttributeSet
328a053: 8335059: Consider renaming ClassLoaderData::keep_alive
a89b525: 8337721: G1: Remove unused G1CollectedHeap::young_collection_verify_type
dc35f3e: 8337062: x86_64: Unordered add/mul reduction support for vector api
21e86d1: 8334405: java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in testWakeupDuringSelect
f1fa64b: 4966250: SSLSessionContext.setSessionTimeout() documentation could be updated
9fe6e23: 8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception
27af80e: 8324260: java/foreign/TestStubAllocFailure.java run timeout with -Xcomp
... and 42 more: https://git.openjdk.org/jdk/compare/c4e6255ac3ec5520c4cb6d0d4ad9013da177ba88...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2024-07-31T23:44:01Z

@vnkozlov The following label will be automatically applied to this pull request:

hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2024-07-31T23:46:45Z

Webrevs

RealFYang · 2024-08-01T02:12:23Z

Hi, Seems to me that the following two were missed?

diff --git a/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp b/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
index 3f1a4423b5e..5e2ef97e4a3 100644
--- a/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
+++ b/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
@@ -7045,7 +7045,7 @@ class StubGenerator: public StubCodeGenerator {
     Label thaw_success;
     // rscratch2 contains the size of the frames to thaw, 0 if overflow or no more frames
     __ cbnz(rscratch2, thaw_success);
-    __ lea(rscratch1, ExternalAddress(StubRoutines::throw_StackOverflowError_entry()));
+    __ lea(rscratch1, RuntimeAddress(StubRoutines::throw_StackOverflowError_entry()));
     __ br(rscratch1);
     __ bind(thaw_success);

diff --git a/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp b/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp
index f78d7261e40..198835d733f 100644
--- a/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp
+++ b/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp
@@ -3774,7 +3774,7 @@ class StubGenerator: public StubCodeGenerator {
     Label thaw_success;
     // t1 contains the size of the frames to thaw, 0 if overflow or no more frames
     __ bnez(t1, thaw_success);
-    __ la(t0, ExternalAddress(StubRoutines::throw_StackOverflowError_entry()));
+    __ la(t0, RuntimeAddress(StubRoutines::throw_StackOverflowError_entry()));
     __ jr(t0);
     __ bind(thaw_success);

vnkozlov · 2024-08-01T03:15:39Z

Thank you, @RealFYang
I added missing cases pointed by you.

adinn · 2024-08-01T13:59:54Z

Hi Vladimir,

If I am following your comment regarding forward exception correctly, it seems that this is being encoded as an ExternalAddress because:

the raw address constant for StubRoutines::forward_exception_entry() passed into the TailCallNode gets processed in the AD back end by moving the constant into a register
there is no way to mark the constant passed to the TailCallNode as requiring a runtime_call_type reloc
so the address move defaults to using external_word_type

I'm wondering if this can be fixed in the back end.

Firstly, can I just clarify that is it just the forward exception target that needs a runtime_call_type reloc? The other uses of TailCallNode and TailJumpNode transfer control from a stub to a return address passed as argument to the call. So, there is no constant supplied as argument and hence nothing to relocate for those cases.

If so then could we use a match rule to detect this case e.g.

instruct TailCalljmpInd(immP jump_target, inline_cache_RegP method_ptr)
%{
  match(TailCall jump_target method_ptr);
  . . .

If we provide this rule with an encoding that loads the target using a runtime reloc then it should be preferred on cost grounds to the loadConP rule which uses the default external reloc.

adinn · 2024-08-01T15:20:50Z

I think I found a few more places in aarch64 and x86 where we need to use RuntimeAddress. There may be similar problems in the other arch implementations:

diff --git a/src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp b/src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp
index 90c7ca6f08a..c6b078c3c7d 100644
--- a/src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp
+++ b/src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp
@@ -179,7 +179,7 @@ void InterpreterRuntime::SignatureHandlerGenerator::generate(uint64_t fingerprin
   iterate(fingerprint);
 
   // return result handler
-  __ lea(r0, ExternalAddress(Interpreter::result_handler(method()->result_type())));
+  __ lea(r0, RuntimeAddress(Interpreter::result_handler(method()->result_type())));
   __ ret(lr);
 
   __ flush();
diff --git a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
index f90aefc8fd3..73da947c318 100644
--- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
+++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
@@ -1879,7 +1879,7 @@ void MacroAssembler::_verify_oop(Register reg, const char* s, const char* file,
   movptr(rscratch1, (uintptr_t)(address)b);
 
   // call indirectly to solve generation ordering problem
-  lea(rscratch2, ExternalAddress(StubRoutines::verify_oop_subroutine_entry_address()));
+  lea(rscratch2, RuntimeAddress(StubRoutines::verify_oop_subroutine_entry_address()));
   ldr(rscratch2, Address(rscratch2));
   blr(rscratch2);
 
@@ -1918,7 +1918,7 @@ void MacroAssembler::_verify_oop_addr(Address addr, const char* s, const char* f
   movptr(rscratch1, (uintptr_t)(address)b);
 
   // call indirectly to solve generation ordering problem
-  lea(rscratch2, ExternalAddress(StubRoutines::verify_oop_subroutine_entry_address()));
+  lea(rscratch2, RuntimeAddress(StubRoutines::verify_oop_subroutine_entry_address()));
   ldr(rscratch2, Address(rscratch2));
   blr(rscratch2);
 
diff --git a/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp b/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
index 89f5fbd281b..215f1b6453b 100644
--- a/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
+++ b/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
@@ -1337,7 +1337,7 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
   {
     Label L;
     __ ldr(r10, Address(rmethod, Method::native_function_offset()));
-    address unsatisfied = (SharedRuntime::native_method_throw_unsatisfied_link_error_entry());
+    RuntimeAddress unsatisfied(SharedRuntime::native_method_throw_unsatisfied_link_error_entry());
     __ mov(rscratch2, unsatisfied);
     __ ldr(rscratch2, rscratch2);
     __ cmp(r10, rscratch2);
@@ -1432,7 +1432,7 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
     // hand.
     //
     __ mov(c_rarg0, rthread);
-    __ mov(rscratch2, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans));
+    __ mov(rscratch2, RuntimeAddress(CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans)));
     __ blr(rscratch2);
     __ get_method(rmethod);
     __ reinit_heapbase();
@@ -1461,7 +1461,7 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
 
   {
     Label no_oop;
-    __ adr(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT)));
+    __ adr(t, RuntimeAddress(AbstractInterpreter::result_handler(T_OBJECT)));
     __ cmp(t, result_handler);
     __ br(Assembler::NE, no_oop);
     // Unbox oop result, e.g. JNIHandles::resolve result.
@@ -1482,7 +1482,7 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
 
     __ push_call_clobbered_registers();
     __ mov(c_rarg0, rthread);
-    __ mov(rscratch2, CAST_FROM_FN_PTR(address, SharedRuntime::reguard_yellow_pages));
+    __ mov(rscratch2, RuntimeAddress(CAST_FROM_FN_PTR(address, SharedRuntime::reguard_yellow_pages)));
     __ blr(rscratch2);
     __ pop_call_clobbered_registers();
 
@@ -2085,7 +2085,7 @@ void TemplateInterpreterGenerator::trace_bytecode(Template* t) {
 
   assert(Interpreter::trace_code(t->tos_in()) != nullptr,
          "entry must have been generated");
-  __ bl(Interpreter::trace_code(t->tos_in()));
+  __ bl(RuntimeAddress(Interpreter::trace_code(t->tos_in())));
   __ reinit_heapbase();
 }
 
diff --git a/src/hotspot/cpu/x86/interpreterRT_x86_32.cpp b/src/hotspot/cpu/x86/interpreterRT_x86_32.cpp
index a9b96c22427..f9adc8b49a9 100644
--- a/src/hotspot/cpu/x86/interpreterRT_x86_32.cpp
+++ b/src/hotspot/cpu/x86/interpreterRT_x86_32.cpp
@@ -93,7 +93,7 @@ void InterpreterRuntime::SignatureHandlerGenerator::generate( uint64_t fingerpri
   iterate(fingerprint);
   // return result handler
   __ lea(rax,
-         ExternalAddress((address)Interpreter::result_handler(method()->result_type())));
+         RuntimeAddress((address)Interpreter::result_handler(method()->result_type())));
   // return
   __ ret(0);
   __ flush();
diff --git a/src/hotspot/cpu/x86/interpreterRT_x86_64.cpp b/src/hotspot/cpu/x86/interpreterRT_x86_64.cpp
index 7e390564f4c..ec78445dab6 100644
--- a/src/hotspot/cpu/x86/interpreterRT_x86_64.cpp
+++ b/src/hotspot/cpu/x86/interpreterRT_x86_64.cpp
@@ -295,7 +295,7 @@ void InterpreterRuntime::SignatureHandlerGenerator::generate(uint64_t fingerprin
   iterate(fingerprint);
 
   // return result handler
-  __ lea(rax, ExternalAddress(Interpreter::result_handler(method()->result_type())));
+  __ lea(rax, RuntimeAddress(Interpreter::result_handler(method()->result_type())));
   __ ret(0);
 
   __ flush();
diff --git a/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp b/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
index fe2bf67afc9..594216860f3 100644
--- a/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
+++ b/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
@@ -1002,7 +1002,7 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
   {
     Label L;
     __ movptr(rax, Address(method, Method::native_function_offset()));
-    ExternalAddress unsatisfied(SharedRuntime::native_method_throw_unsatisfied_link_error_entry());
+    RuntimeAddress unsatisfied(SharedRuntime::native_method_throw_unsatisfied_link_error_entry());
     __ cmpptr(rax, unsatisfied.addr(), rscratch1);
     __ jcc(Assembler::notEqual, L);
     __ call_VM(noreg,
@@ -1075,8 +1075,8 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
 
   { Label L;
     Label push_double;
-    ExternalAddress float_handler(AbstractInterpreter::result_handler(T_FLOAT));
-    ExternalAddress double_handler(AbstractInterpreter::result_handler(T_DOUBLE));
+    RuntimeAddress float_handler(AbstractInterpreter::result_handler(T_FLOAT));
+    RuntimeAddress double_handler(AbstractInterpreter::result_handler(T_DOUBLE));
     __ cmpptr(Address(rbp, (frame::interpreter_frame_oop_temp_offset + 1)*wordSize),
               float_handler.addr(), noreg);
     __ jcc(Assembler::equal, push_double);
@@ -1167,7 +1167,7 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
 
   {
     Label no_oop;
-    __ lea(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT)));
+    __ lea(t, RuntimeAddress(AbstractInterpreter::result_handler(T_OBJECT)));
     __ cmpptr(t, Address(rbp, frame::interpreter_frame_result_handler_offset*wordSize));
     __ jcc(Assembler::notEqual, no_oop);
     // retrieve result

vnkozlov · 2024-08-01T15:26:53Z

Thank you Andrew. Yes, you analysis is correct - we fall into default value when constructing Address() from register.
Nice suggestion about separate matching for constant for TailCall. I can add assert which checks that constant is forward_exception_entry() address and catch other cases if they happen.

vnkozlov · 2024-08-01T15:47:19Z

I think it is fine to use ExternalAddress in compare instruction or return value even if address points to stub or VM's method. We need to use RuntimeAddress only when it is used as target for call or jump instructions.

vnkozlov · 2024-08-01T15:55:33Z

@adinn Can you explain aarch64 code?
Why we usemov(r, addr); blr(r); instead of bl(adr)?
And why use lea(r1, addr); ldr(r, r1) instead of mov(r, addr)?

vnkozlov · 2024-08-01T17:41:21Z

Answering my questions:
bl() is used for small branches branch_range = NOT_DEBUG(128 * M) DEBUG_ONLY(2 * M)
mov(r, addr) simple loads target addr as 64-bit value into register through which we jump.
lea(r, addr) construct address in register based on Address mode and is used when we need to load value from it.

May be we should also use lea() instead of mov() in next case since we change address argument's type to Address:

-    address unsatisfied = (SharedRuntime::native_method_throw_unsatisfied_link_error_entry());
+    RuntimeAddress unsatisfied(SharedRuntime::native_method_throw_unsatisfied_link_error_entry());
     __ mov(rscratch2, unsatisfied);
     __ ldr(rscratch2, rscratch2);
     __ cmp(r10, rscratch2);

vnkozlov · 2024-08-01T18:03:32Z

Actually lea(r, RuntimeAddress a) method generates the same instructions as mov(r, RuntimeAddress a)

vnkozlov · 2024-08-01T18:19:00Z

And I got compilation failure for templateInterpreterGenerator_aarch64.cpp because mov(r, Address a) is private member of MacroAssembler. I have to use lea() with these changes.

vnkozlov · 2024-08-01T18:36:12Z

I will work on forward_exception_entry() case next.

vnkozlov · 2024-08-01T21:33:40Z

forward_exception_entry() is complicated. Using immP causes assert hit in MachNode::in_RegMask() because C2 assumes that all TailCalls have 2 registers inputs: matcher.cpp#L828

I don't think I should work on it in these changes.

vnkozlov · 2024-08-01T21:46:03Z

I created RFE JDK-8337702 for TailCall(forward_exception_entry).

adinn · 2024-08-01T22:00:16Z

I don't think I should work on it in these changes.
. . .
I created RFE JDK-8337702 for TailCall(forward_exception_entry).

Yes good idea.

As you say lea is needed when loading the RuntimeAddress into a register.

vnkozlov · 2024-08-01T23:03:01Z

Thank you Andrew for review.

RealFYang · 2024-08-02T03:20:26Z

And some addon change to keep RISC-V part up to date. Manually run workloads with -XX:+VerifyOops -XX:+TraceBytecodes.
@vnkozlov : Could you please help add it? Thanks.

diff --git a/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp b/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
index e349eab3177..cd7a4ecf228 100644
--- a/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
+++ b/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
@@ -547,7 +547,7 @@ void MacroAssembler::_verify_oop(Register reg, const char* s, const char* file,
   }

   // call indirectly to solve generation ordering problem
-  ExternalAddress target(StubRoutines::verify_oop_subroutine_entry_address());
+  RuntimeAddress target(StubRoutines::verify_oop_subroutine_entry_address());
   relocate(target.rspec(), [&] {
     int32_t offset;
     la(t1, target.target(), offset);
@@ -592,7 +592,7 @@ void MacroAssembler::_verify_oop_addr(Address addr, const char* s, const char* f
   }

   // call indirectly to solve generation ordering problem
-  ExternalAddress target(StubRoutines::verify_oop_subroutine_entry_address());
+  RuntimeAddress target(StubRoutines::verify_oop_subroutine_entry_address());
   relocate(target.rspec(), [&] {
     int32_t offset;
     la(t1, target.target(), offset);
diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
index 769e4dc5ccc..f01945bc6a3 100644
--- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
+++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
@@ -1111,8 +1111,8 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
   {
     Label L;
     __ ld(x28, Address(xmethod, Method::native_function_offset()));
-    address unsatisfied = (SharedRuntime::native_method_throw_unsatisfied_link_error_entry());
-    __ mv(t, unsatisfied);
+    ExternalAddress unsatisfied(SharedRuntime::native_method_throw_unsatisfied_link_error_entry());
+    __ la(t, unsatisfied);
     __ load_long_misaligned(t1, Address(t, 0), t0, 2); // 2 bytes aligned, but not 4 or 8

     __ bne(x28, t1, L);
@@ -1815,7 +1815,7 @@ void TemplateInterpreterGenerator::trace_bytecode(Template* t) {
   // the tosca in-state for the given template.

   assert(Interpreter::trace_code(t->tos_in()) != nullptr, "entry must have been generated");
-  __ call(Interpreter::trace_code(t->tos_in()));
+  __ rt_call(Interpreter::trace_code(t->tos_in()));
   __ reinit_heapbase();
 }

vnkozlov · 2024-08-02T06:04:53Z

/contributor add @RealFYang

openjdk · 2024-08-02T06:05:47Z

@vnkozlov
Contributor Fei Yang <fyang@openjdk.org> successfully added.

vnkozlov · 2024-08-02T06:06:31Z

And some addon change to keep RISC-V part up to date.

Added. Thank you, Fei Yang.

…print_statistics

iwanowww

Looks good.

vnkozlov · 2024-08-02T18:54:42Z

Thank you, Vladimir

vnkozlov · 2024-08-03T06:20:17Z

/integrate

openjdk · 2024-08-03T06:21:28Z

Going to push as commit 34edc73.
Since your change was applied there have been 52 commits pushed to the master branch:

7deee74: 8335122: Reorganize internal low-level support for HTML in jdk.javadoc
f2e1205: 8337676: JFR: Change the label of the throttle setting
066db6e: 8337274: Remove repeated 'the' in StyleSheet.create{Small,Large}AttributeSet
328a053: 8335059: Consider renaming ClassLoaderData::keep_alive
a89b525: 8337721: G1: Remove unused G1CollectedHeap::young_collection_verify_type
dc35f3e: 8337062: x86_64: Unordered add/mul reduction support for vector api
21e86d1: 8334405: java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in testWakeupDuringSelect
f1fa64b: 4966250: SSLSessionContext.setSessionTimeout() documentation could be updated
9fe6e23: 8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception
27af80e: 8324260: java/foreign/TestStubAllocFailure.java run timeout with -Xcomp
... and 42 more: https://git.openjdk.org/jdk/compare/c4e6255ac3ec5520c4cb6d0d4ad9013da177ba88...master

Your commit was automatically rebased without conflicts.

openjdk · 2024-08-03T06:21:33Z

@vnkozlov Pushed as commit 34edc73.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8337396: Cleanup usage of ExternalAddess

d2abe7f

openjdk bot added the rfr Pull request is ready for review label Jul 31, 2024

openjdk bot added the hotspot hotspot-dev@openjdk.org label Jul 31, 2024

Add missed ExternalAddress changes

7fa9e11

Add more missing cases and update Copyright year

9bb7867

adinn approved these changes Aug 1, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Aug 1, 2024

vnkozlov mentioned this pull request Aug 2, 2024

8337702: Use new ForwardExceptionNode to call StubRoutines::forward_exception_entry() #20437

Closed

3 tasks

Added RISCV missing cases

f19d284

openjdk bot removed the ready Pull request is ready to be integrated label Aug 2, 2024

Remove PrintNMethodStatistics not needed check in ExternalsRecorder::…

d734d41

…print_statistics

iwanowww approved these changes Aug 2, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Aug 2, 2024

openjdk bot added the integrated Pull request has been integrated label Aug 3, 2024

openjdk bot closed this Aug 3, 2024

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Aug 3, 2024

vnkozlov deleted the 8337396 branch August 3, 2024 06:33

8337396: Cleanup usage of ExternalAddess #20412

8337396: Cleanup usage of ExternalAddess #20412

Uh oh!

Conversation

vnkozlov commented Jul 31, 2024 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Contributors

Reviewing

Webrev

Uh oh!

bridgekeeper bot commented Jul 31, 2024

Uh oh!

openjdk bot commented Jul 31, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Jul 31, 2024

Uh oh!

mlbridge bot commented Jul 31, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

RealFYang commented Aug 1, 2024

Uh oh!

vnkozlov commented Aug 1, 2024

Uh oh!

adinn commented Aug 1, 2024

Uh oh!

adinn commented Aug 1, 2024

Uh oh!

vnkozlov commented Aug 1, 2024

Uh oh!

vnkozlov commented Aug 1, 2024

Uh oh!

vnkozlov commented Aug 1, 2024

Uh oh!

vnkozlov commented Aug 1, 2024

Uh oh!

vnkozlov commented Aug 1, 2024

Uh oh!

vnkozlov commented Aug 1, 2024

Uh oh!

vnkozlov commented Aug 1, 2024

Uh oh!

vnkozlov commented Aug 1, 2024

Uh oh!

vnkozlov commented Aug 1, 2024

Uh oh!

adinn commented Aug 1, 2024

Uh oh!

vnkozlov commented Aug 1, 2024

Uh oh!

RealFYang commented Aug 2, 2024

Uh oh!

vnkozlov commented Aug 2, 2024

Uh oh!

openjdk bot commented Aug 2, 2024

Uh oh!

vnkozlov commented Aug 2, 2024

Uh oh!

iwanowww left a comment

Choose a reason for hiding this comment

Uh oh!

vnkozlov commented Aug 2, 2024

Uh oh!

vnkozlov commented Aug 3, 2024

Uh oh!

openjdk bot commented Aug 3, 2024

Uh oh!

openjdk bot commented Aug 3, 2024

Uh oh!

Uh oh!

vnkozlov commented Jul 31, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Jul 31, 2024 •

edited

Loading

mlbridge bot commented Jul 31, 2024 •

edited

Loading