tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Caldarale, Charles R" <Chuck.Caldar...@unisys.com>
Subject RE: tomcat memory usage
Date Wed, 27 Jan 2010 19:50:09 GMT
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Re: tomcat memory usage
> 
> 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.

You're confusing the reference with the object it points to.  The field containing the reference
is in PermGen, the object the reference refers to is in the main heap.

> The runtime doesn't know until the putstatic call that the object is
> destined to be a static reference.

See above; "reference" != "object", but "reference" == pointer to "object".  (But I think
you know that.)

> any long-living, heap-allocated object could be attached to 
> a static member at any time without warning.

Sure; it happens all the time.

> 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

No, the object will never migrate to PermGen space.  (Nothing ever migrates across the PermGen
/ main heap boundary, in either direction.)

> In either case, each object would need not only a regular reference
> count but also a static reference count 

No Java GC mechanism has used reference counting for close to ten years now.  All GC operations
are performed by following reference chains from the roots (subject to a ton of acceleration
techniques that avoid following all paths on all GCs).

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

They do exactly that.  The fact that a reference field is static says nothing about the expected
lifetime of what the reference refers to.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus
for use only by the intended recipient. If you received this in error, please contact the
sender and delete the e-mail and its attachments from all computers.

Mime
View raw message