Code Review for JEP 259: Stack-Walking API

John Rose john.r.rose at oracle.com
Wed Nov 11 23:48:39 UTC 2015


On Nov 11, 2015, at 12:29 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> On 11/11/15 2:32 PM, Mandy Chung wrote:
>>> On Nov 10, 2015, at 6:05 AM, Dmitry Samersoff <dmitry.samersoff at oracle.com> wrote:
>>> 
>>> Mandy,
>>> 
>>> Native part looks good for me.
>>> 
>>> javaClasses.cpp:
>>> 
>>> 1. It might be good to create a helper inline function for
>>> 
>>>  int bci_version = stackFrame->int_field(bci_offset);
>>>  int version     = BackTrace::version_at(bci_version);
>>> 
>> Coleen gave me some suggestion to use injected fields.  This will be changed in the next revision.
>> 
>>> 2. java_lang_StackFrameInfo::fill_methodInfo
>>> 
>>>  CHECK macro left methodInfo partially initialized, not sure it's OK.
>>> 
>> Any exception here will cause StackWalker::walk to fail.  I expect the exception thrown here  would be OOME and other internal errors.  So it should be okay.
>> 
>>> javaClasses.inline.hpp:
>>> 
>>> 78 You can use the same pattern as in assert:
>>> 
>>>    if ((jushort)version != version) version = USHRT_MAX;
>>> 
>>> 117 Is it possible to add comment about +1000000 magic?
>>> 
>> This is existing code refactored from javaClasses.hpp.  I don’t know why it added  +1000000.  For hidden frames, keeping line number to -1 is good to me since it means unavailable.
>> 
>> Coleen - do you know why this is done this way?
> 
> Honestly, I have no idea.  I refactored it into that function preserving the original code.

I added it to make backtraces for internally generated functions more informative.
Since the stack walker will be able to surface BCIs directly, there will be no need for it.

— John


More information about the hotspot-runtime-dev mailing list