tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: tomcat memory usage
Date Wed, 27 Jan 2010 19:29:45 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

On 1/27/2010 1:50 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message