Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap (original) (raw)
David Holmes david.holmes at oracle.com
Sun Nov 11 20:32:57 PST 2012
- Previous message: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap
- Next message: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Coleen,
:)
Can you explain the old and new relationships between these various objects please. As I understand it JSR-292 introduced this special kind of class - the anonymous class - and they differ from regular classes in important ways (mainly that they can be collected before their classloader), and pre-NPG this all "just worked". The NPG changes added the ClassLoaderData metadata objects and changed some of the associations that anonymous classes actually relied upon and as a result they stopped getting GC'd in some cases, and were prematurely GC'd in others (I hope I got that right). This changeset addresses these problems.
I've been trying to follow this from the beginning and still don't have a clear understanding on what the relationships between ClassLoader, Class, "anonymous class" and ClassLoaderData objects are. So a clear picture of what relationships exist (particularly this new 1:N association) would be appreciated, and help make the code changes more understandable to me.
Thanks, David
On 12/11/2012 1:51 PM, Coleen Phillimore wrote:
This change creates a ClassLoaderData object for each JSR 292 anonymous class, so that the metadata and mirror object for the anonymous class can be reclaimed when the anonymous class is no longer referenced. The javalangClassLoader object for the anonymous class is the same as its hostclass. Most of this change is to break the assumption that there's a 1-1 relationship between javalangClassLoader Java objects and ClassLoaderData metadata objects in the VM. Also, nmethods and other things that were strong roots for javalangClassLoader objects have to also be strong roots for javalangClass objects for anonymous classes. There were also changes to move the dependencies out of the javalangClassLoader object to the ClassLoaderData type. This type is preallocated so that CMS will have card marks to track additions to the dependencies. Please check this, Stefan! Also, in this change is the addition of mirrors to the interpreter frame and a test case that shows why this is necessary. An interpreter frame can be running while it's class loader is unloaded in some special circumstances. It is easier to do this with JSR292 static MethodHandle code. Some people are looking for a platform independent way to do this, by changing code in GC. While this target-dependent interpreter code is unfortunate, the concept is simple. If the latter effort succeeds, we can remove the mirror from the interpreter frame later. A note to openjdk developers - I added this mirror to zero but not to shark. More testing is necessary. Please review the following change: Summary: Add ClassLoaderData object for each anonymous class with metaspaces to allocate in. Add mirror interpreter frame. http://cr.openjdk.java.net/~coleenp/8000662/ http://bugs.sun.com/viewbug.do?bugid=8000662 Tested with Nashorn tests, NSK full testlist, dacapo with CMS and G1. Thanks, Coleen
- Previous message: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap
- Next message: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]