about static method

[Jeff Zhao]

Hi everyone,

I know static fields are always hosting in memory.But,how about
static methods? Are they always hosting in memory? I think they
aren't,but how are they running?

thanks,

Best rgds.

 

[John C. Bollinger]

I know static fields are always hosting in memory.But,how about
static methods? Are they always hosting in memory? I think they
aren't,but how are they running?

All instance fields of every object in the JVM and all static fields of
every class in the JVM are always in (possibly virtual) memory. Some
version of the code for all methods, static and non-static, of all
classes currently loaded in the JVM are always in (possibly virtual)
memory. These are direct implications of an instance being live in a
JVM and of a class being loaded in a JVM. Why do you suggest otherwise?

Methods do not run in any case. Threads run, executing methods' code in
the process.

 

[Roedy Green]

I know static fields are always hosting in memory.But,how about
static methods? Are they always hosting in memory? I think they
aren't,but how are they running?

They hang around in RAM until there are no more references to them.
Then they can be GCed like anything else.

 

[jan V]

I know static fields are always hosting in memory.But,how about

They hang around in RAM until there are no more references to them.
Then they can be GCed like anything else.

Static *methods* ?? Surely not. And what's a reference to a static method?

 

[Jeff Zhao]

John C. Bollinger 写é“：

All instance fields of every object in the JVM and all static fields of
every class in the JVM are always in (possibly virtual) memory. Some
version of the code for all methods, static and non-static, of all
classes currently loaded in the JVM are always in (possibly virtual)
memory. These are direct implications of an instance being live in a
JVM and of a class being loaded in a JVM. Why do you suggest otherwise?

Methods do not run in any case. Threads run, executing methods' code in
the process.

then,does it work like following?

1. when class isn't be loaded in JVM
--all fields not in memory

2. when class is loaded in JVM
--static fields are in memory,but instance fields aren't in
memory,all methods not in memory

3. when class is loaded in JVM,but it isn't be initialized,and its
static method is invoked
--all fields are in memory,static methods in memory,but instance
methods aren't in memory

4. when class is initialized
--all fields are in memory,all methods are in memory

5. Whether it's true or not? and at last,I want to know when are they
be GCed?
I'm puzzled by Roedy,static fields can be GCed? And static methods
too?

 

[Chris Uppal]

then,does it work like following?

1.[...]

No. The following is a simplification (there are exceptions in certain
"advanced" situation -- all of which involve classloaders), but it's close
enough for a working approximation:

When a class is loaded, the code for its instance methods
and static methods are treated identically. They are copied
into the JVM's memory and stay there (with the class itself)
until the JVM exits. Nothing is ever GCed.

Instance fields are part of the instances, so the memory used
for storing any instance's fields is allocated when the instance
is created, and released when the instance is GCed. Static
fields are part of the class, and their memory is allocated when
the class is loaded, and never released until the JVM exits.
(Or until the class is itself GCed -- but that can never happen
except in special applications which make sophisticated use
of classloaders)

(Actually, the JVM is at liberty to play tricks to reduce memory consumption,
as long as that is never visible to application programmers. That's an
implementation detail, and will vary from JVM to JVM. As far as I, personally,
know the only "trick" that is used is that the JITed form of the methods' code
/can/ be created lazily (when the method is used, or is used more than a
certain number of times), and that the compiled machine-code representation
/can/ be thrown away if it has not been used for a while.)

I'm puzzled by Roedy,static fields can be GCed? And static methods
too?

Roedy is wrong. If he is confusing you then it's probably best just to ignore
him (on this subject).

-- chris

 

[Roedy Green]

1. when class isn't be loaded in JVM
--all fields not in memory

2. when class is loaded in JVM
--static fields are in memory,but instance fields aren't in
memory,all methods not in memory

Instance fields only exist in objects. So until you instantiate some
objects of the class, this is exactly how it works.

 

[Roedy Green]

--all fields are in memory,static methods in memory,but instance
methods aren't in memory

Sometimes the methods are loaded one at a time as they are used,
static or instance. It is really up to the JVM to do it how it sees
fit. The way JVMs are designed is based mainly on space/time
tradeoffs. It is obviously faster to load an entire class as a lump
and instantiate all its methods than to do it one at a time.

Keep in mind that there is only one copy of the code for a method in
RAM, whether it is static or instance. Instance methods are only
logically connected to objects, not duplicated.

 

[Roedy Green]

I'm puzzled by Roedy,static fields can be GCed? And static methods
too?

Inside the JVM there is an object for each class that will point to
the code for its various static and instance methods and its static
variables, and also its superclass. This thing is an object like any
other, even if you don't play with it directly, and is subject to the
same GC rules as any other object.

However, I can't think of a time where I noticed a class
reinitialising its statics in mid run after a period of disuse. So I
suspect in practice classes don't often get GCed. You might be able
to find out with the java -verbose option that logs every class
loaded. You could see if some got loaded twice, implying a GC.

 

[Roedy Green]

Static *methods* ?? Surely not. And what's a reference to a static method?

A piece of code that invokes a static method would be a reference to a
static method, but GC is only interested in what class references
point to, not which method within that class.

On the other hand, a method might be inlined, interpreted or compiled.
Over a session it might even exist in all three forms. Each method of
the class can be handled separately. Presumably GC scavenges
discarded compilations whose "effectively final" assumptions have been
ruined by a new class loaded.

 

[Roedy Green]

When a class is loaded, the code for its instance methods
and static methods are treated identically. They are copied
into the JVM's memory and stay there (with the class itself)
until the JVM exits. Nothing is ever GCed.

Is this part of the JVM spec or just the way some particular JVM
works? Where did you read this? Unfortunately I can't recall where I
read the story I have been repeating.