RFR(S): 8211852: inspect stack during error reporting

[David Holmes]

Hi Martin,

On 9/10/2018 9:30 PM, Doerr, Martin wrote:
> Hi David,
> 
> thank you for reviewing my change.
> 
> An example of the output is:
> stack at sp + 5 slots: 0x00007f905f4fa618 points into unknown readable memory: 0x00007f905f4fa618:   20 a5 3f 5f 90 7f 00 00
> The "(byte x of)" only shows up for unaligned addresses.

Sure - but when it does it seems a little odd.

> "print_hex_dump" prints the address again so I could replace it by a loop. I think this makes sense.

Okay.

> I have chosen bytewise output because it's the most conservative assumption. So larger types need to get interpreted in reverse order on little endian.

I was wondering about endianness and how to interpret the "byte x of".

>> src/hotspot/share/utilities/vmError.cpp
>> Seems odd to have:
>> 751   STEP("printing top of stack info")
>> then
>> 769   STEP("printing registers, top of stack, instructions near pc")
>>
>> as they both refer to "top of stack". Should they be merged (I know you
>> touch on this above)? Should they be the other way round? Should they
>> use different descriptions?
> 
> I had also asked myself such kind of questions.
> An argument against combining the steps is that if one of them fails (which can happen in rare cases) we still have the other one.
> I don't have a specific opinion about the order. I'm willing to change if you prefer them the other way round.

I think the new stack details should come after the existing register 
ToS etc.

> Would "inspecting top of stack" be a better description?

Sure.

>> Any particular reason to show 8 slots? Or is it just a "Goldilocks number"?
> This is the number which is used in step "printing registers, top of stack, instructions near pc" on x86 which is the main platform I'd like to address with this change because I think it has the most complex stack usage.

Ok.

Thanks,
David

> Further improvement requests are appreciated.
> 
> Best regards,
> Martin
>