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

John Rose john.r.rose at oracle.com
Thu Nov 29 18:01:21 PST 2012

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 resolvedreferences to keep the mirror alive. But I guess that's not the case.

(*appendixresult) = 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 + // classloader containing this method is kept alive. + ClassLoaderData* thiskey = InstanceKlass::cast(accessingklass())->classloaderdata(); + thiskey->recorddependency(m->methodholder(), CHECKNULL); // 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

More information about the hotspot-dev mailing list