Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JDK-8302320: AsyncGetCallTrace obtains too few frames in sanity test #12535

Closed

Conversation

parttimenerd
Copy link
Contributor

@parttimenerd parttimenerd commented Feb 13, 2023

Extends the existing AsyncGetCallTrace test case and fixes the issue.


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-8302320: AsyncGetCallTrace obtains too few frames in sanity test

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 12535

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

Using diff file

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

@bridgekeeper
Copy link

bridgekeeper bot commented Feb 13, 2023

👋 Welcome back parttimenerd! 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 openjdk bot added the rfr Pull request is ready for review label Feb 13, 2023
@openjdk
Copy link

openjdk bot commented Feb 13, 2023

@parttimenerd The following labels will be automatically applied to this pull request:

  • hotspot
  • serviceability

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

@openjdk openjdk bot added serviceability serviceability-dev@openjdk.org hotspot hotspot-dev@openjdk.org labels Feb 13, 2023
@mlbridge
Copy link

mlbridge bot commented Feb 13, 2023

Webrevs

Comment on lines 71 to 72
// unextended sp must be within the stack
if (!thread->is_in_full_stack_checked(unextended_sp)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not at all sure this relaxation is valid. What are you basing this on?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test fails without this relaxation and the relaxation has been used on PPC to solve a similar issue a few years back.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original assumption does not always hold anymore and should therefore relaxed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think unextended_sp < sp is possible on x86 when interpreter entries generated by MethodHandles::generate_method_handle_interpreter_entry() are executed. They modify sp (here for example) but not sender_sp (InterpreterMacroAssembler ::_bcp_register).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From frame_x86.hpp:

  // The interpreter and adapters will extend the frame of the caller.
  // Since oopMaps are based on the sp of the caller before extension
  // we need to know that value. However in order to compute the address
  // of the return address we need the real "raw" sp. By convention we
  // use sp() to mean "raw" sp and unextended_sp() to mean the caller's
  // original sp.

by that definition unextended_sp is always > sp. If something has violated that definition/convention then we may have bigger problems!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If an ordinary interpreter entry is used for a call this means the callee will be interpreted

Maybe we're not talking about the same thing?

Method has a from_interpreted_entry and a from_compiled_entry, but which one is used depends on the caller, and which calling convention they are using. The callee can be either interpreted or compiled (and if there's a mismatch, we go through an adapter). The entry generated by generate_method_handle_interpreter_entry is essentially the from_interpreted_entry, AFAIU.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The entry generated by generate_method_handle_interpreter_entry is essentially the from_interpreted_entry, AFAIU.

But it is also stored in Method::_i2i_entry which is used by c2i adapters.

(Maybe too) long version:

The interpreter has entries depending on the MethodKind. See AbstractInterpreter::entry_for_kind(). The entries are stored in AbstractInterpreter::_entry_table. In MethodHandlesAdapterGenerator::generate() the interpreter entries for method handle intrinsics MethodKinds are generated using the generator MethodHandles::generate_method_handle_interpreter_entry().

In Method::link_method() the entry points are set depending on the MethodKind. The interpreter entry (see above) for the method's MethodKind is looked up and stored in Method::_i2i_entry which is also used by c2i adapters.

So to me it looks as if the entry generated by generate_method_handle_interpreter_entry() can be reached coming from a compiled caller. The generator for ordinary methods is TemplateInterpreterGenerator::generate_normal_entry(). The entries it generates are surely reached by compiled callers. I might be missing something in the case of MH intrinsics but right now it looks to me as if the caller can be compiled too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Maybe too) long version:

Not at all :) I don't know much about the interpreter, so this is pretty helpful.

Ok. I think the main point is that a MH linker method doesn't have use a c2i adapter, it instead has separate versions for interpreted and compiled callers altogether (except linkToNative which doesn't have an interpreter version atm)

Longer version:

I think there are 4 theoretical cases (are there more?):

  1. interpreted -> MH interpreter entry -> interpreted (the case we want to fix, I think)
  2. interpreted -> MH interpreter entry -> i2c -> compiled
  3. compiled -> c2i -> MH interpreter entry -> interpreted
  4. compiled -> c2i -> MH interpreter entry -> i2c -> compiled

So... my understanding is that a c2i adapter is used when a callee is interpreted, so its from_compiled_entry points to the c2i adapter. A compiled caller calls the from_compiled_entry, so it ends up going through the c2i adapter of an interpreted callee. However, for method handle linkers, the from_compiled_entry never points to a c2i adapter, but to the MH linker compiler entry generated in gen_special_dispatch in e.g sharedRuntime_x86_64. So, in other words, the 3. and 4. scenarios above are not possible, AFAICS. An MH linker's interpreted/compiled entries simply replace the regular i2c and c2i adapters for a MH linker method. Though, the actual target method can be either compiled or interpreted, so we can go into either a c2i adapter from a MH linker compiler entry, or a i2c adapter from a MH linker interpreter entry (which is scenario 2.).

For scenario 1.: caller sets r13 before jumping to callee (MH linker), we end up in the MH adapter, pop the last argument, and adjust r13 for the actual callee. The MH interpreter entry uses from_interpreted_entry of the target method, so we don't go through any adapter.

For scenario 2.: mostly the same as 1., but we go through an i2c adapter, and the compiled callee doesn't care about what's in r13 any ways. (there's a comment in the ic2 adapter code about preserving r13 for the case that we might go back into a c2i adapter if we lose a race where the callee is made non-entrant, but r13 is also used as a scratch register later in the i2c code, and the c2i code overwrites r13 any ways. So, I think that is an outdated comment...)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So... my understanding is that a c2i adapter is used when a callee is
interpreted, so its from_compiled_entry points to the c2i adapter. A
compiled caller calls the from_compiled_entry, so it ends up going through
the c2i adapter of an interpreted callee. However, for method handle
linkers, the from_compiled_entry never points to a c2i adapter, but to the
MH linker compiler entry generated in gen_special_dispatch in e.g
sharedRuntime_x86_64. So, in other words, the 3. and 4. scenarios above are
not possible, AFAICS.

I see. Thanks! That's what I've been missing. It's implemented in SystemDictionary::find_method_handle_intrinsic() I think.

I agree that it will be ok to modify r13 as you suggested. Maybe explaining why we never reach here coming from a c2i adapter: because native wrappers are generated eagerly in SystemDictionary::find_method_handle_intrinsic() unless -Xint is given but then the caller cannot be compiled.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I integrated your suggestion, it seems to work now. I'm hopeful that our internal queue does not find a test error.

I'm happy for any commenting suggestions.

@dholmes-ora
Copy link
Member

dholmes-ora commented Feb 17, 2023

There are crashes in stack walking with this change. Try e.g.

vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (c:\sb\prod\1676562544\workspace\open\src\hotspot\share\code/codeCache.inline.hpp:49), pid=55852, tid=36120
#  assert(cb != nullptr) failed: must be

Stack: [0x0000001077100000,0x0000001077200000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xbf7311]  os::win32::platform_print_native_stack+0xf1  (os_windows_x86.cpp:236)
V  [jvm.dll+0xe705d0]  VMError::report+0x10c0  (vmError.cpp:813)
V  [jvm.dll+0xe7220e]  VMError::report_and_die+0x6ce  (vmError.cpp:1593)
V  [jvm.dll+0xe72954]  VMError::report_and_die+0x64  (vmError.cpp:1352)
V  [jvm.dll+0x576ef6]  report_vm_error+0x96  (debug.cpp:181)
V  [jvm.dll+0x3fb595]  frame::sender_for_compiled_frame+0x515  (frame_x86.inline.hpp:441)
V  [jvm.dll+0x3fb85d]  frame::sender_raw+0x1dd  (frame_x86.inline.hpp:386)
V  [jvm.dll+0x524f4f]  vframeStreamCommon::next+0x52f  (vframe.inline.hpp:103)
V  [jvm.dll+0x7d7350]  java_lang_Throwable::fill_in_stack_trace+0x810  (javaClasses.cpp:2589)
V  [jvm.dll+0x7d6b16]  java_lang_Throwable::fill_in_stack_trace+0x86  (javaClasses.cpp:2649)
V  [jvm.dll+0x8b723d]  JVM_FillInStackTrace+0x1ad  (jvm.cpp:505)
C  [java.dll+0x7162]

@parttimenerd
Copy link
Contributor Author

There also errors on Linux, e.g. vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java:

- stepBreakPopReturn.cpp, 57: Setting debuggee class name to Lvm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test;
- stepBreakPopReturn.cpp, 86: Entering method: Lvm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test;.setDebuggeeMethodName
- stepBreakPopReturn.cpp, 51: Setting debuggee method name to target
### TRACE 0: Call site 1
- stepBreakPopReturn.cpp, 86: Entering method: Lvm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test;.bootstrap
### TRACE 0: Lookup vm.mlvm.indy.func.jvmti.stepBreakPopReturn.INDIFY_Test; method name = greet; method type = (Object,String,int)int
- stepBreakPopReturn.cpp, 86: Entering method: Lvm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test;.target
- stepBreakPopReturn.cpp, 115: Single step event: Lvm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test; .target :1
- stepBreakPopReturn.cpp, 128: Pop a frame
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000000315, pid=41551, tid=41572
#
# JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-adhoc.openjdk.jdk-dev)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-adhoc.openjdk.jdk-dev, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  0x00000000e755a950
#
# Core dump will be written. Default location: /priv/jvmtests/output_openjdk21_dev_dbgU_linuxx86_64/jtreg_hotspot_tier4_work/JTwork/scratch/0
#
# An error report file with more information is saved as:
# /priv/jvmtests/output_openjdk21_dev_dbgU_linuxx86_64/jtreg_hotspot_tier4_work/JTwork/scratch/hs_err_pid41551.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

So back to my original suggestion which is simple and worked (ran it through our internal test queue and found no errors)?

@reinrich
Copy link
Member

Java stack

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000000315, pid=41551, tid=41572
#
# JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-adhoc.openjdk.jdk-dev)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-adhoc.openjdk.jdk-dev, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  0x00000000e755a950
#
# Core dump will be written. Default location: .../jtreg_hotspot_tier4_work/JTwork/scratch/0
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Dtest.vm.opts=-Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=.../jtreg_hotspot_tier4_work/tmp -Djava.io.tmpdir=.../jtreg_hotspot_tier4_work/tmp -Dtest.getfreeport.max.tries=40 -ea -esa -Dtest.tool.vm.opts=-J-Xmx768m -J-Djava.awt.headless=true -J-Djava.util.prefs.userRoot=.../jtreg_hotspot_tier4_work/tmp -J-Djava.io.tmpdir=.../jtreg_hotspot_tier4_work/tmp -J-Dtest.getfreeport.max.tries=40 -J-ea -J-esa -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=.../sapjvm_21 -Dcompile.jdk=.../sapjvm_21 -Dtest.timeout.factor=6.0 -Dtest.nativepath=.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/native -Dtest.root=.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg -Dtest.name=vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java -Dtest.file=.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java -Dtest.src=.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn -Dtest.src.path=.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn:.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/vmTestbase:.../grmpf/testdata/jtreg/jtreg_test_21/test/lib -Dtest.classes=.../jtreg_hotspot_tier4_work/JTwork/classes/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.d -Dtest.class.path=.../jtreg_hotspot_tier4_work/JTwork/classes/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.d:.../jtreg_hotspot_tier4_work/JTwork/classes/vmTestbase:.../jtreg_hotspot_tier4_work/JTwork/classes/test/lib -Dtest.class.path.prefix=.../jtreg_hotspot_tier4_work/JTwork/classes/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.d:.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn:.../jtreg_hotspot_tier4_work/JTwork/classes/vmTestbase:.../jtreg_hotspot_tier4_work/JTwork/classes/test/lib -Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=.../jtreg_hotspot_tier4_work/tmp -Djava.io.tmpdir=.../jtreg_hotspot_tier4_work/tmp -Dtest.getfreeport.max.tries=40 -ea -esa -Djava.library.path=.../grmpf/testdata/jtreg/jtreg_test_21/test/hotspot/jtreg/native -agentlib:stepBreakPopReturn=verbose= com.sun.javatest.regtest.agent.MainWrapper .../jtreg_hotspot_tier4_work/JTwork/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.d/main.0.jta

Host: ..., Intel(R) Xeon(R) Platinum 8260M CPU @ 2.40GHz, 8 cores, 23G, SUSE Linux Enterprise Server 15 SP3
Time: Fri Feb 17 01:34:06 2023 CET elapsed time: 2.781186 seconds (0d 0h 0m 2s)

---------------  T H R E A D  ---------------

Current thread (0x00007fbc94422600):  JavaThread "MainThread" [_thread_in_Java, id=41572, stack(0x00007fbc6af26000,0x00007fbc6b027000)]

Stack: [0x00007fbc6af26000,0x00007fbc6b027000],  sp=0x00007fbc6b025118,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x00000000e755a950
j  java.lang.invoke.LambdaForm$MH+0x0000000801018400.linkToTargetMethod(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;)I+7 java.base@21-internal
j  vm.mlvm.indy.func.jvmti.stepBreakPopReturn.INDIFY_Test.run()Z+52
j  vm.mlvm.share.MlvmTestExecutor.runMlvmTestInstance(Lvm/mlvm/share/MlvmTest;)Z+82
j  vm.mlvm.share.MlvmTestExecutor.runMlvmTest(Ljava/lang/Class;[Ljava/lang/Object;)Z+21
j  vm.mlvm.share.MlvmTestExecutor.launch(Ljava/lang/Class;[Ljava/lang/Object;)V+28
j  vm.mlvm.share.MlvmTestExecutor.launch([Ljava/lang/Object;)V+20
j  vm.mlvm.share.MlvmTestExecutor.launch([Ljava/lang/String;[Ljava/lang/Object;)V+5
j  vm.mlvm.share.MlvmTest.launch([Ljava/lang/String;)V+2
j  vm.mlvm.indy.func.jvmti.stepBreakPopReturn.INDIFY_Test.main([Ljava/lang/String;)V+1
j  java.lang.invoke.LambdaForm$DMH+0x0000000801001800.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base@21-internal
j  java.lang.invoke.LambdaForm$MH+0x0000000801002c00.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base@21-internal
j  java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base@21-internal
j  jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base@21-internal
j  jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base@21-internal
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base@21-internal
j  com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+134
j  java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@21-internal
j  java.lang.Thread.run()V+19 java.base@21-internal
v  ~StubRoutines::call_stub 0x00007fbc8417fd21
V  [libjvm.so+0xeec41a]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4da  (javaCalls.cpp:415)
V  [libjvm.so+0xeeca90]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x290  (javaCalls.cpp:329)

@JornVernee
Copy link
Member

JornVernee commented Feb 17, 2023

Thanks for trying it out! I ran tier 1-4 here as well, and all failing tests are in vmTestbase/vm/mlvm/indy/func/jvmti. They all seem to be using PopFrame before a crash happens, so I think that might be where the problem is. I don't think it's impossible that there is other code out there that has its own workaround for the incorrect unextended_sp.

Also, I later realized that interpreter frames also save the sp before before making a call (interpreter_frame_last_sp_offset), and I can find at least some code that seems to assume caller.unextended_sp() == (intptr_t*)caller.at(frame::interpreter_frame_last_sp_offset), so we'd just be breaking another invariant with my "fix".

There's probably a bit of tech debt here (filed: https://bugs.openjdk.org/browse/JDK-8302745).

I had a closer look at the original fix, and it looks like the unextended_sp is only used to check the size of the caller frame for interpreter -> interpreter calls. So, I think it's okay to relax the unextende_sp >= sp check (the invariant it tests turns out not to hold for otherwise valid stacks any way). But, in that case, please leave a comment that explains why we can have sp > unextended_sp.

@parttimenerd
Copy link
Contributor Author

But, in that case, please leave a comment that explains why we can have sp > unextended_sp.

Could you be so kind to synthesize a comment for me? I'm slightly overwhelmed by the discussion.

@JornVernee
Copy link
Member

Could you be so kind to synthesize a comment for me? I'm slightly overwhelmed by the discussion.

Something like:

// Note: sp can be greater than unextended_sp in the case of
// interpreted -> interpreted calls that go through a method handle linker,
// since those pop the last argument (the appendix) from the stack.

@parttimenerd
Copy link
Contributor Author

Thanks, I modified my PR accordingly.

@parttimenerd
Copy link
Contributor Author

Is this PR then ready?

@dholmes-ora
Copy link
Member

I'm somewhat concerned that the code doesn't seem to have a clear notion of exactly how unextended_sp relates to sp in general. I would still be concerned that the relaxation may cause a bad value to be considered safe and so lead to a crash. But I guess we will just have to address that if it arises.
Thanks for all the due-diligence on this one.

Copy link
Member

@JornVernee JornVernee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new check looks good to me. I think the only potential issue is in cases where unextended_sp == sp and sp - Interpreter::stackElementSize is somehow outside of the stack. But, since this is looking at a sender, it would mean that the current frame would definitely be outside of the stack, so I think we're good.

I'll submit tier 1-4 on our CI, and give a check mark when it comes back green.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The latest version seems a more conservative constraint, so as long as that fixes things it seems good to me. Thanks.

@openjdk
Copy link

openjdk bot commented Feb 21, 2023

⚠️ @parttimenerd the full name on your profile does not match the author name in this pull requests' HEAD commit. If this pull request gets integrated then the author name from this pull requests' HEAD commit will be used for the resulting commit. If you wish to push a new commit with a different author name, then please run the following commands in a local repository of your personal fork:

$ git checkout parttimenerd_too_few_frames
$ git commit --author='Preferred Full Name <you@example.com>' --allow-empty -m 'Update full name'
$ git push

@openjdk
Copy link

openjdk bot commented Feb 21, 2023

@parttimenerd 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:

8302320: AsyncGetCallTrace obtains too few frames in sanity test

Reviewed-by: jvernee, dholmes, rrich

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 133 new commits pushed to the master branch:

  • 8b20aa9: 8302981: Fix a typo in the doc comment for java.lang.Record.equals
  • 644fe0a: 8302837: Kernel32.cpp array memory release invokes undefined behaviour
  • 60e6378: 8302977: ZGC: Doesn't support gc/TestVerifySubSet.java
  • fef1910: 8299777: Test runtime/NMT/BaselineWithParameter.java timed out
  • 622f560: 8302886: Parallel: Remove unimplemented methods in ParCompactionManager
  • 9fd77c7: 8302868: Serial: Remove CardTableRS::initialize
  • f35cf79: 8302867: G1: Removing unused variable in G1CardTable::initialize
  • 63a3501: 8302741: ZGC: Remove Universe::verify calls
  • 9145670: 8301661: Enhance os::pd_print_cpu_info on macOS and Windows
  • aa10f0d: 8302151: BMPImageReader throws an exception reading BMP images
  • ... and 123 more: https://git.openjdk.org/jdk/compare/0458d3825c0b6ba215a87143ad472acdcba59f40...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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@JornVernee, @dholmes-ora, @reinrich) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Feb 21, 2023
Copy link
Member

@reinrich reinrich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.
Richard.

Copy link
Member

@JornVernee JornVernee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Testing looks good

@parttimenerd
Copy link
Contributor Author

/integrate

@openjdk openjdk bot added the sponsor Pull request is ready to be sponsored label Feb 21, 2023
@openjdk
Copy link

openjdk bot commented Feb 21, 2023

@parttimenerd
Your change (at version 42bdfd8) is now ready to be sponsored by a Committer.

@JornVernee
Copy link
Member

/sponsor

@openjdk
Copy link

openjdk bot commented Feb 21, 2023

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

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Feb 21, 2023
@openjdk openjdk bot closed this Feb 21, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Feb 21, 2023
@openjdk
Copy link

openjdk bot commented Feb 21, 2023

@JornVernee @parttimenerd Pushed as commit db483a3.

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

@parttimenerd
Copy link
Contributor Author

/backport jdk17u

@openjdk
Copy link

openjdk bot commented Mar 3, 2023

@parttimenerd To use the /backport command, you need to be in the OpenJDK census and your GitHub account needs to be linked with your OpenJDK username (how to associate your GitHub account with your OpenJDK username).

@RealCLanger
Copy link
Contributor

db483a3.

You need to do that on the commit, not on the PR. However, not sure whether your author role is sufficient and everything Github is set up correctly...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot hotspot-dev@openjdk.org integrated Pull request has been integrated serviceability serviceability-dev@openjdk.org
5 participants