Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap

[John Rose]

On Nov 29, 2012, at 9:38 AM, Coleen Phillimore wrote:

>> I don't know if this is needed or not. I thought we would have registered some sort of object in the resolved_references to keep the mirror alive. But I guess that's not the case.
>> 
>>       (*appendix_result) = Handle(THREAD, appendix);
>> +      // the target is stored in the cpCache and if a reference to this
>> +      // MethodName is dropped we need a way to make sure the
>> +      // class_loader containing this method is kept alive.
>> +      ClassLoaderData* this_key = InstanceKlass::cast(accessing_klass())->class_loader_data();
>> +      this_key->record_dependency(m->method_holder(), CHECK_NULL); // Can throw OOM
>>       return methodHandle(THREAD, m);
>>     }
> 
> This would be nice if it's true.  I don't really have a way of proving it though and JSR 292 keeps changing so it might not stay true.   I'll add a FIXME comment to this though.

Short answer:  The logic in the comment and the code is correct.

Here's the basic info about MemberName for a method:  Before resolution, it has references to a klass, a name, and a type.  In the resolved state, it has non-null vmtarget that points to a Method.  The Method has been looked up from the klass etc.  It is common that the Method::method_holder is the same as the klass::as_Klass.  But in fact the method_holder might also be a supertype of the original klass.

In any case, the MemberName is discarded, and only the Method (and its appendix oop if any) needs to stick around.  Therefore, I think it is a good idea to add the Method::method_holder to the dependencies list, in all cases, since nothing else remains to "accompany" the Method* pointer in the linkage information.  (The appendix sticks around, but it is an arbitrary oop, not metadata, so it can't help keep the Method's class alive.) 

— John