RFR 8038797: JVMTI FollowReferences does not report roots reachable from nmethods

[dean.long at oracle.com]

On 8/11/16 12:54 PM, Coleen Phillimore wrote:

>
>
> On 8/11/16 2:32 PM, dean.long at oracle.com wrote:
>> Can you make it work for any CompiledMethod and not just nmethods?
>
> Dean, I tried to do this but CompiledMethod didn't have any oops_do 
> function.

Oh right, I was thinking it did because of some experiments I had made 
in that area.

>>
>> I believe oops_do() also picks up klass_holder() oops that were added 
>> to keep metadata references alive.
>
> Yes, it does.
>
>> So for those you will most likely get a ClassLoader and not the Class 
>> object.  To get the Class object I think you would need to use 
>> something like metadata_do(). Does FollowReferences care either way?
>
> No, FollowReferences really wants the oops and you can use the oops to 
> find out which Class objects (java.lang.Class) and ClassLoaders are 
> alive.   FollowReferences doesn't follow any metadata for anything.
>

OK, this change looks good to me.

dl

> Coleen
>
>>
>> dl
>>
>> On 8/11/16 10:44 AM, Coleen Phillimore wrote:
>>> Summary: Also follow nmethods found on the execution stack.
>>>
>>> I have this fix to follow nmethods found on the execution stack but 
>>> not really a good way to test it.  There are two tests internally 
>>> that exercise this code and with some printing, I verified that they 
>>> do the right thing.   I am open to suggestions how to test this, it 
>>> requires compiled methods on the stack with oops that are only 
>>> referenced from said methods in the oop section (not in locals or on 
>>> stack).
>>>
>>> Also ran the tonga colocated/non-colocated internal tests, 
>>> jdk/test/com/sun/jdi.
>>>
>>> scp -r /home/cphillim/home/public_html/webrev/8038797.01 
>>> coleenp at cr.openjdk.java.net:
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8038797.01/webrev
>>>
>>>
>>> thanks,
>>> Coleen
>>
>