Request for reviews (M): 6580131: Exposing Method Inlining InformationTo JVMTI Agents

[Tom Rodriguez]

>>>> line 1756
>>>>
>>  > >record->methods[record->numstackframes] = sd->method()- 
>> >jmethod_id();
>>
>>
>>> This code does not check for a NULL method() return, but
>>> the code that calls this function does. I'm guessing that
>>> means that it is possible for sd->method() to return NULL
>>> here...
>>>
>>
>> One solution to this would be to insert a null check that marks the  
>> whole JvmtiCompiledMethodLoadInlineRecord as invalid if sd- 
>> >method() returns null. (In the header we could hash-define a  
>> constant value that indicates an invalid record). A JVMTI agent  
>> would then have to check that the record is valid before proceeding  
>> to use it. Would this be an acceptable solution?
>>
>
> I think for this "failure mode", you're going to need Tom's opinion
> about what a NULL sd->method() return means. It seems to me that you
> could potentially be invalidating a lot of data due to one glitch.
> It might be better to return a dummy jmethodID, e.g., NO_METHOD_FOUND,
> for that method and let the agent sort out it out amongst the rest of
> the data...

I think the method can be NULL for stubs but never for nmethods.  If  
you wanted to be completely robust then ignore them if you encounter  
them but include an assert that you should never see them.

tom

>
> Dan
>