Return-Path: 
 <users-return-207564-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org>
Delivered-To: apmail-tomcat-users-archive@www.apache.org
Received: (qmail 62205 invoked from network); 27 Jan 2010 19:30:22 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 27 Jan 2010 19:30:22 -0000
Received: (qmail 30586 invoked by uid 500); 27 Jan 2010 19:30:18 -0000
Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org
Received: (qmail 30504 invoked by uid 500); 27 Jan 2010 19:30:18 -0000
Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@tomcat.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@tomcat.apache.org>
List-Post: <mailto:users@tomcat.apache.org>
List-Id: <users.tomcat.apache.org>
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Delivered-To: mailing list users@tomcat.apache.org
Received: (qmail 30464 invoked by uid 99); 27 Jan 2010 19:30:18 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Jan 2010 19:30:18 +0000
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [76.96.62.24] (HELO qmta02.westchester.pa.mail.comcast.net)
 (76.96.62.24)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Jan 2010 19:30:09 +0000
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74])
	by qmta02.westchester.pa.mail.comcast.net with comcast
	id aecf1d00H1c6gX852jVoEw; Wed, 27 Jan 2010 19:29:48 +0000
Received: from [192.168.1.202] ([98.218.200.175])
	by omta23.westchester.pa.mail.comcast.net with comcast
	id ajWT1d00Z3nZbXm3jjWTRi; Wed, 27 Jan 2010 19:30:27 +0000
Message-ID: <4B609429.6020204@christopherschultz.net>
Date: Wed, 27 Jan 2010 14:29:45 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: tomcat memory usage
References: <626831.11349.qm@web54404.mail.re2.yahoo.com>
 		<e0c148a1001260743k2292547cl83ba0d7d56826955@mail.gmail.com>
 		<309552.52635.qm@web54410.mail.re2.yahoo.com>
 	<4B606228.4080708@christopherschultz.net>
 	<99C8B2929B39C24493377AC7A121E21F96C31C98F8@USEA-EXCH8.na.uis.unisys.com>
 <4B608849.2080400@christopherschultz.net>
 <99C8B2929B39C24493377AC7A121E21F96C31C9DCC@USEA-EXCH8.na.uis.unisys.com>
In-Reply-To: 
 <99C8B2929B39C24493377AC7A121E21F96C31C9DCC@USEA-EXCH8.na.uis.unisys.com>
X-Enigmail-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

-----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