-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck,
On 1/27/2010 1:50 PM, Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Subject: Re: tomcat memory usage >> >> So, static members are stored outside the heap? Where are they >> stored? PermGen? > > They're definitely not in the main Java heap; I'm pretty sure they're > in PermGen, although it's been awhile since I've looked at that code. > Keeping them in PermGen makes it easier for the all the GC > reference-chasing logic to work. This seems fishy to me. Consider the following. public class MyClass { public static Object staticObject = "static"; } The compiler knows that the "staticObject" member is static, and might even be able to tell the runtime that the object to be used for that static member should go into PermGen. But, now what happens if some other code does this: MyClass.staticObject = new String("new string"); (I intentionally used the "new" keyword to force a new object creation at runtime... not sure what the compiler/runtime does with string constants within the constant pool). The bytecode for that looks roughly like this: new String ldc "new string" invokespecial String.<init>(String) putstatic MyClass.staticObject The runtime doesn't know until the putstatic call that the object is destined to be a static reference. Even if the compiler and runtime were to collude to make this happen in this contrived example, any long-living, heap-allocated object could be attached to a static member at any time without warning. Does that mean that the putstatic opcode likely does one of two things: 1. Immediately promote that object into the PermGen space 2. Marks the object as destined for PermGen so that the GC can move it whenever it wants In either case, each object would need not only a regular reference count but also a static reference count in case the object was still relevant but no longer bound to a static member, in which case it should be moved /back/ into the regular heap? That sounds like more work than is really necessary for the GC to perform. Why not just have objects that end up bound to static members grow old and move into the "old" generation just like most long-lived objects? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktglCkACgkQ9CaO5/Lv0PDr3ACdGSJQxadZHAHx5bjyjSRDpqyL /xEAn11hQJeGlz7H6dAlgecQElJTGSD0 =AKd+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
