RFR: 8309613: [Windows] hs_err files sometimes miss information about the code containing the error [v2]
David Holmes
dholmes at openjdk.org
Mon Jun 12 08:10:51 UTC 2023
On Fri, 9 Jun 2023 10:24:08 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:
>> We have seen hs_err files for errors triggered by C2 compiled methods which miss the most relevant information: the C2 method (see JBS issue for more details). I have found a possibility to add it. Please take a look and provide feedback.
>>
>> Testing:
>>
>> diff --git a/src/hotspot/share/opto/parse1.cpp b/src/hotspot/share/opto/parse1.cpp
>> index f179d3ba88d..c35a1ac595e 100644
>> --- a/src/hotspot/share/opto/parse1.cpp
>> +++ b/src/hotspot/share/opto/parse1.cpp
>> @@ -1210,6 +1210,12 @@ void Parse::do_method_entry() {
>> make_dtrace_method_entry(method());
>> }
>>
>> + if (UseNewCode) {
>> + Node* halt = _gvn.transform(new HaltNode(control(), frameptr(), "Requested Halt!"));
>> + C->root()->add_req(halt);
>> + set_control(halt);
>> + }
>> +
>> #ifdef ASSERT
>> // Narrow receiver type when it is too broad for the method being parsed.
>> if (!method()->is_static()) {
>>
>>
>> "java -XX:+UseNewCode -version" shows the following output (when no hsdis lib is provided):
>>
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V [jvm.dll+0x6ca5b9] os::win32::platform_print_native_stack+0xd9 (os_windows_x86.cpp:236)
>> V [jvm.dll+0x8a3afa] VMError::report+0xd6a (vmError.cpp:973)
>> V [jvm.dll+0x8a5cde] VMError::report_and_die+0x5fe (vmError.cpp:1765)
>> V [jvm.dll+0x283061] report_fatal+0x71 (debug.cpp:212)
>> V [jvm.dll+0x621c3e] MacroAssembler::debug64+0x8e (macroAssembler_x86.cpp:829)
>> C 0x000001635fe021f4
>>
>>
>> called by the following code:
>> Compiled method (c2) 87 16 4 java.lang.Object::<init> (1 bytes)
>> total in heap [0x000001635fe02010,0x000001635fe02250] = 576
>> relocation [0x000001635fe02170,0x000001635fe02188] = 24
>> main code [0x000001635fe021a0,0x000001635fe02200] = 96
>> stub code [0x000001635fe02200,0x000001635fe02218] = 24
>> metadata [0x000001635fe02218,0x000001635fe02220] = 8
>> scopes data [0x000001635fe02220,0x000001635fe02228] = 8
>> scopes pcs [0x000001635fe02228,0x000001635fe02248] = 32
>> dependencies [0x000001635fe02248,0x000001635fe02250] = 8
>>
>> [Constant Pool (empty)]
>>
>> [MachCode]
>> [Entry Point]
>> # {method} {0x0000000800478d78} '<init>' '()V' in 'java/lang/Object'
>> # [sp+0x20] (sp of caller)
>> 0x000001635fe021a0: 448b 5208 | 49bb 0000 | 0000 0800 | 0000 4d03 | d349 3bc2
>>
>> 0x000001635fe021b4: ; {runtime_call ic_miss_stub}
>> 0x000001635fe021b4: 0f85 c6c4 | 8fff 6690 | 0f1f 4000
>> [Verified Ent...
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>
> Check result of print_code and update printed_len.
C 0x000001635fe021f4
called by the following code:
So does everything after `called by the following code` relate to the frame `C 0x000001635fe021f4`? If so I'd like to see this delineated more clearly as presently it would appear very disruptive when reading the initial sections of the hs_err file.
Thanks
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14358#issuecomment-1586803723
More information about the hotspot-compiler-dev
mailing list