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