Class unloading

Hello,
When you execute a user-defined class, it is loaded into memory. If you delete or update this class in the file system, and re-execute this class, you get the old version of the class that was previously loaded into memory. Is there a way to get rid of the loaded class so that you get the updated one.
Thank you

Allow the classloader that loaded it to be garbage-collectedCould you please expand on that. Also, how can you make a classloader to be garbage-collected ?
Thank you

Similar Messages

Class unloading doesn't work as described in this forum !!!

Hi,
to the problem of dynamic class unloading many people in this forum wrote:
- write your own class loader
- load the class to be unloaded later
- set all instances of your own class loader to null
- if the work is done set all instances of the loaded classes to null
- call the garbage collector and the classes will be removed
I constructed a simple test for the problem:
- the test class
public class Impl {
public String getVersion () {
return "1";
- instanciating the test class
- printing the value of getVersion() to the screen
- changing the return value of getVersion() and recompiling it (the test application is still runnig)
- unload try (see below)
- instanciating the test class
- printing the value of getVersion() to the screen
Back to the tipps above. Why doing this? The theory says a class loader stores every loaded class for
suppressing unnecessary reloads. In reality the classes are NOT stored in the own class loader but in
the parent of it. If no parameter is given to a class loader's constructor the parent of a class loader
is the system classloader.
Let's have a look at the source code of java.lang.ClassLoader.loadClass(...):
protected synchronized Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
// First, check if the class has already been loaded
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
### here the loadClass() of the parent is called and the
### loaded class is stored within the parent
c = parent.loadClass(name, false);
} else {
c = findBootstrapClass(name);
} catch (ClassNotFoundException e) {
// If still not found, then call findClass in order
// to find the class.
c = findClass(name);
if (resolve) {
resolveClass(c);
return c;
My Idea was: Give a null to the class loader's constructor so the classes cannot be stored within a parent.
Here my test class loader (it is build as it is described within javadoc of java.lang.ClassLoader
except the constructor):
import java.io.*;
public class MyClassLoader extends ClassLoader {
public MyClassLoader () {
super ( null );
public Class findClass ( String name ) {
byte[] b = loadClassData ( name );
return defineClass ( name, b, 0, b.length );
private byte[] loadClassData ( String name ) {
byte[] ret = null;
try {
InputStream in = new FileInputStream ( name + ".class" );
ret = new byte[in.available ()];
in.read ( ret );
} catch ( Exception e ) {
e.printStackTrace ();
return ret;
The loading of the class works fine
ClassLoader cl = new MyClassLoader ();
Class c = cl.loadClass ( "Impl" );
Object i = c.newInstance ();
Impl impl = (Impl)i;
The class "Impl" was found and instanciated. But the cast "Impl impl = (Impl)i;" causes a
"java.lang.ClassCastException: Impl"
May second idea was deleting all instances of the class to unload from the class loader via reflection.
A strange way I know but if this is the only way I will do it. But this doesn't work too.
After deleting the class from the class loader and all its parents the class is still anywhere in the depth
of the VM.
Can anybody help me with this problem?
Thanks in advance,
Axel.

<pre>
I made a similar and simpler program and it worked:
import java.net.URLClassLoader;
import java.net.URL;
public class DynamicExtension {
     public static void main(String args[]) throws Exception {
          URL[] ua = new URL[] { new URL("file://c:\\TEMP\\") };
          URLClassLoader ucl = new URLClassLoader(ua);
          MyLoadable l =
               (MyLoadable) ucl.loadClass("LoadableObject").newInstance();
          l.printVersion();
          Thread.currentThread().sleep(10000);
//you have ten seconds to replace the old version of the LoadableObject.class file
//so yo?d better had compiled the new one before executing this
          ucl = new URLClassLoader(ua);
          l = (MyLoadable) ucl.loadClass("LoadableObject").newInstance();
          l.printVersion();
          ucl = null;
          l = null;
          System.gc();
public class LoadableObject implements MyLoadable {
     public void printVersion() {
          System.out.println("version 1");
     protected void finalize() {
          System.out.println("finalizing " + this);
public interface MyLoadable {     void printVersion(); }
C:\Java\TIJ2\Test>java DynamicExtension
version 1
version 2
finalizing LoadableObject@1bd03e
finalizing LoadableObject@4abc9
The ClassCastException was due to the fact that one class was loaded by the system class loader, the one that appers as Impl impl = (Impl), and the other by MyClassLoader. That mean that they are different for the VM because they are in different namespaces: The namespace for MyClassLoader is the set of classes loaded by itself and those returned to it by his parent class loader as a result of a request to MyClassLoader?s parent class loader to load a class.
Setting null for the parent of MyClassLoader was in fact the cause of the problem, because that caused a call to a native method called findBoostrapClass. I guess this method looks for the classes in the bootstrap classpath where MyClassLoader shouldn?t be. This causes MyClassLoader loaded the class itself. If MyClassLoader had had the system class loader as its parent the result had been that only one classloader would have loaded the class. This is what happens in the example above so no ClassCastException is thrown.
In the source code for ClassLoader
there is the following:
* The classes loaded by this class loader. The only purpose of this
* table is to keep the classes from being GC'ed until the loader
* is GC'ed.
private Vector classes = new Vector(); /*
and:
* Called by the VM to record every loaded class with this loader.
void addClass(Class c) {
classes.addElement(c);
I would like to have seen findLoadedClass checking the already loaded classes in this Vector, but this method is native. Anyway, as the code for loadClass shows, the parent or bootstrap classloader is checked if findLoadedClass doesn?t find the class; Can we guess that findLoadedClass only checks the clases loaded by the classloader, not its parent?
By the way, could an example like this be made in c++?
</pre>

PermGen not full but full GC triggerred and classes unloaded

We have a recurring problem where a full GC gets triggered that is quite long (7 seconds). By observation, it seems that a great deal of the full GC time is spent unloading "sun.reflect.GeneratedSerializationConstructorAccessor" classes. However, we have PermSize set to 64 meg and it seems that only 9 megs are actually in use. All the other GCs for the day (about 8.5 hours till the problem) are fairly short (0.10 to 0.35 seconds)
Any hints as to what is triggering this long GC and how I can avoid it? I know stopping class garbage collection could help, but I am not finding enough information on the risks of doing this. Plus I thought the PermGeneration contained the classes, not the tenured generation.
Thanks.
-- 2
Details
Solaris 2.8, dual CPU UltraSparc IIIi with 1MB cache each
8 GB RAM
Java 1.5.0_06
Runtime args:
-Xms1280m -Xmx1280m -server -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+DisableExplicitGC -XX:+PrintGCApplicationStoppedTime -XX:PermSize=64m
"jmap -h" result (sometime after Full GC):
Server compiler detected.
JVM version is 1.5.0_06-b05
using thread-local object allocation.
Parallel GC with 2 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 1342177280 (1280.0MB)
NewSize = 2228224 (2.125MB)
MaxNewSize = 4294901760 (4095.9375MB)
OldSize = 1441792 (1.375MB)
NewRatio = 2
SurvivorRatio = 32
PermSize = 67108864 (64.0MB)
MaxPermSize = 67108864 (64.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 106496000 (101.5625MB)
used = 24655256 (23.513084411621094MB)
free = 81840744 (78.0494155883789MB)
23.151344651442308% used
From Space:
capacity = 196608 (0.1875MB)
used = 134808 (0.12856292724609375MB)
free = 61800 (0.05893707275390625MB)
68.56689453125% used
To Space:
capacity = 14483456 (13.8125MB)
used = 0 (0.0MB)
free = 14483456 (13.8125MB)
0.0% used
PS Old Generation
capacity = 894828544 (853.375MB)
used = 627750416 (598.6694488525391MB)
free = 267078128 (254.70555114746094MB)
70.15315059060075% used
PS Perm Generation
capacity = 67108864 (64.0MB)
used = 9422208 (8.9857177734375MB)
free = 57686656 (55.0142822265625MB)
Verbose GC:
987745K->852246K(1032576K), 0.1995592 secs]
Total time for which application threads were stopped: 0.2016224 seconds
24998.391: [GC [PSYoungGen: 153190K->6928K(149952K)] 996182K->859364K(1023808K), 0.1852391 secs]
Total time for which application threads were stopped: 0.1872944 seconds
25102.514: [GC [PSYoungGen: 149904K->6384K(156864K)] 1002340K->865912K(1030720K), 0.1630581 secs]
25102.677: [Full GC[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor7]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor14]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor12]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor10]
[Unloading class sun.reflect.GeneratedMethodAccessor1]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor8]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor6]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor4]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor2]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor11]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor24]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor21]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor13]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor16]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor9]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor3]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor23]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor1]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor22]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor5]
[PSYoungGen: 6384K->0K(156864K)] [PSOldGen: 859528K->375378K(873856K)] 865912K->375378K(1030720K) [PSPermGen: 9192K->9192K(65536K)], 7.0877752 secs]
Total time for which application threads were stopped: 7.2531067 seconds
25210.000: [GC [PSYoungGen: 142016K->5680K(146688K)] 517394K->381058K(1020544K), 0.0708419 secs]

[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor5 ]
[PSYoungGen: 6384K->0K(156864K)] [PSOldGen: 859528K->375378K(873856K)] 865912K->375378K(1030720K) [PSPermGen: 9192K->9192K(65536K)], 7.0877752 secs]Despite the messages about unloading classes, it is unlikely that class unloading
is taking up any significant amount of the 7 seconds. The last line quoted above
shows the old generation (PSOldGen) had 859528K used before GC and
375378K used after GC. Reclaiming the ~470MB in the old gen took the
majority of the time.
This GC is caused by the fact that your old gen became nearly full, or at least
full enough that the JVM decided that the next young generation GC would
fill up the old generation.
Since you are using 1.5.0_06 you can try using the parallel compacting collector
to do these Full GCs in parallel. It should reduce the time somewhat if you have 2
cpus, and even more if you have 4 or more cpus (or hardware threads).
To enable it, add the option -XX:+UseParallelOldGC.
If that does not meet your needs or if you have strict limits on GC pause times,
then you should try using the concurrent collector. See section
5.4,The Concurrent Low Pause Collector, in the 5.0 tuning guide at
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

Dynamic class unloading

i need to re-load / update some dynamically loaded classes. the error code i get when i try
to load a new version without "unloading" old version:
Exception in thread "main" java.lang.LinkageError: loader (instance of MyClassLoader): attempted duplicate class definition for name: "net/aaa/bbb/ccc/MyClassName"
at java.lang.ClassLoader.defineClass1(Native Method)
i reviewed this page:
http://blog.taragana.com/index.php/archive/how-to-unload-java-class/
but it has the phrase:
After you are done with the class you need to release all references to the class ...
i do not understand what this means with regards to how reflection works.
a class cannot know all the objects that it created. but objects have handles their class.
so what then do you do? create a collection of all objects for no reason other to identify
the handles pointing to the class object that needs reloading to null ?
for sure that starting a new jvm can resolve this.
so this is my technique:
send message over network to server that causes the server to:
(1) start a second jvm that is a twin.
(2) exit, and still have the twin jvm running.
i have tried something like this:
machine #1:
Socket sok = new Socket("192.168.0.2", 5432);
ObjectOutputStream oos = new ObjectOutputStream(sok.getOutputStream());
oos.writeObject("/tmp/reboot.exe");
machine #2:
Socket sok = serverSocket.accept();
ObjectInputStream ois = new ObjectInputStream(sok.getInputStream());
Sting cmd = (String) ois.readObject();
Runtime rt = Runtime.getRuntime();
rt.exec(cmd);
rt.exit(0);*# cat /tmp/reboot.exe*
+/usr/bin/java Server &+
note that my executing: */usr/bin/java Server &* works correctly when i type from shell.
i don't get errors.
rather, the first jvm exits, and the twin does not seem to start.
the security risks are a non-issue for me. thanks.
Edited by: kappa9h on Feb 26, 2008 2:24 AM

ok. i don't have it working just yet, but the understanding i work in is that a class's
namespace is not the package name alone. in reality, it is:
( net.kappa9h.test.MyClass ) + (class loader)
in so doing, i can have, in the same jvm , two objects that are instances of :
net.kappa9h.test.MyClass
but have different internal logic.
note:
i always use same interface.
and do not need an instance of the original net.kappa9h.test.MyClass to exist at same
time as updated version of net.kappa9h.test.MyClass .
note:
with regard to original response. thank you for this. however, i cannot use timer method. i need to
allow clients to signal servers to flush their dynamically loaded classes (that are cached), and re-load a newer version from a class server.
and i don't need to carry state. so i could just start a twin and then commit hara-kiri.
EDIT: One can not even say c r a p?? What the hell?i don't understand, but i hope i do not post something wrong in original post.
thanks for assisting in this confounding problem.

Java Class unloading

Can anybody clearly explain when exactly a Java class will be unloaded?
The scenario is as follows:
1. Deploy an ear
2. Access the application using the browser
3. Re-deploy the ear
4. Access the same application (same scenario)
it is observed that no class is unloaded after steps 3 and 4. I guess this should not be the case when a re-deployment happens. Can somebody explain the reason????

JobAttributes
public JobAttributes(int copies,
JobAttributes.DefaultSelectionType defaultSelection,
JobAttributes.DestinationType destination,
JobAttributes.DialogType dialog,
String fileName,
int maxPage,
int minPage,
JobAttributes.MultipleDocumentHandlingType multipleDocumentHandling,
int[][] pageRanges,
String printer,
JobAttributes.SidesType sides)
Constructs a JobAttributes instance with the specified values for every attribute.
Parameters
copies - an integer greater than 0.
defaultSelection - DefaultSelectionType.ALL, DefaultSelectionType.RANGE, or DefaultSelectionType.SELECTION.
destination - DesintationType.FILE or DesintationType.PRINTER.
dialog - DialogType.COMMON, DialogType.NATIVE, or DialogType.NONE.
fileName - the possibly null file name.
maxPage - an integer greater than zero and greater than or equal to minPage.
minPage - an integer greater than zero and less than or equal to maxPage.
multipleDocumentHandling - MultipleDocumentHandlingType.SEPARATE_DOCUMENTS_COLLATED_COPIES or MultipleDocumentHandlingType.SEPARATE_DOCUMENTS_UNCOLLATED_COPIES.
pageRanges - an array of integer arrays of 2 elements. An array is interpreted as a range spanning all pages including and between the specified pages. Ranges must be in ascending order and must not overlap. Specified page numbers cannot be less than minPage nor greater than maxPage. For example: (new int[][] { new int[] { 1, 3 }, new int[] { 5, 5 }, new int[] { 15, 19 } }), specifies pages 1, 2, 3, 5, 15, 16, 17, 18, and 19. Note that (new int[][] { new int[] { 1, 1 }, new int[] { 1, 2 } }), is an invalid set of page ranges because the two ranges overlap.
printer - the possibly null printer name.
sides - SidesType.ONE_SIDED, SidesType.TWO_SIDED_LONG_EDGE, or SidesType.TWO_SIDED_SHORT_EDGE.
Throws
IllegalArgumentException if one or more of the above conditions is violated.

Understanding class unloading

Hi All,
We are using weblogic 7 in our production server and we see lots of _jsp unloadings happening in our servers. This means that, JVM internally unloads these classes so that it can have some room to load some other class.
In our design we use lot of class level variables. Now here are my questions.
1. If JVM has to load the _jsp class again, it has to read 100k of data back (provided the class file is 100k in size).
2. If we use lot of class level variables (static variables), then it will be stored in some part of the heap. If they are primitive types they might get stored in the method area. But if they are objects like hashmaps they will be in some area in the heap and a reference will be there in the method area. If the class is referencing these objects, they will not be GCed.
3. So probably because of this, it is trying to unload the jsp classes?. Is my assumption on point number 2 correct?
4. If it is correct, then probably we may need to reduce the static class variables used in the project.
~Rajesh.B

Hi All,
We are using weblogic 7 in our production server and
d we see lots of _jsp unloadings happening in our
servers. This means that, JVM internally unloads these
classes so that it can have some room to load some
other class.
In our design we use lot of class level variables.
. Now here are my questions.
1. If JVM has to load the _jsp class again, it has to
read 100k of data back (provided the class file is
100k in size).
Loading a class, requires reading the class.
2. If we use lot of class level variables (static
variables), then it will be stored in some part of the
heap. If they are primitive types they might get
stored in the method area. But if they are objects
like hashmaps they will be in some area in the heap
and a reference will be there in the method area. If
the class is referencing these objects, they will not
be GCed.
If an instance of an object does not have a reference then it is collected. If the java.lang.Class instance is collected then the statics will also be collected.
3. So probably because of this, it is trying to unload
the jsp classes?. Is my assumption on point number 2
correct?
Huh? Classes are collected when the class loader is collected. It doesn't have anything to do with statics.
4. If it is correct, then probably we may need to
reduce the static class variables used in the
project.
No, it isn't correct.

Class unload / reload don't work with JWS

Hi, I wish to know if it's possible in some way unload an used class and reload a new or changed version of the same class from a jar file with JWS.
My program has a controling application part that load with a custom classloader the real working classes from a few others jar files.
Some events make the controling application close and finalize the working classes and download /reload /instantiate the working classes again to get the version.
This approach work fine when the applicaion is started locally with JAVA.EXE , but when it's started with Java Web Start , don't work.
Any help or comments will be appreciated.

Simply don't start the new version, continue to execute the older one until the app exit and JAWS start again.
I'm sure of release all objects loaded from the actual .jar file, clear cache, download the new .jar , reload the classes , but when they are executed it's the same version.
No error or complains.
The aproach to dinamically reload classes it's based in the sample at:
http://javaalmanac.com/egs/java.lang/ReloadClass.html
but with a URLClassLoader as parent class.

Gc and class unloading

Question:
Does the gc mechanism collect unreferenced objects only, or does it also unload classes that serve as blueprint for those unreferenced objects?
Does anybody know any reference answering this question?

The problem is that if I load all the classes that I might need unloaded in the future using my custom classloader, and follow the nullifying references/nuking classloader technique, I'll have to nullify all the unloadable objects based on several different classes each time I want to reload one class.
So I'll need to serialize all those objects, and than reload all the classes loaded/unloaded by the custom classloader, than recreate all the objects from their serialized version.
And if I create a seperate custom classloader object for each potentially unloadable class, the memory will be crowded.
So what can I do to reload a class without unloading all the classes loaded by the custom classloader?

GC performance and Class Loading/Unloading

We have EP 6.0, SP11 on Solaris with JDK 1.4.8_02. We are running Web Dynpro version of MSS/ESS and Adobe Document Services. This is a Java stack only Web AS.
We are experiencing very uneven performance on the Portal. Usually, when the Portal grinds to a halt, the server log shows GC entries or Class unloading entries for the entire time the Portal stops working.
I am thinking about setting the GC parameters to the same size to try and eliminate sudden GC interruptions. Also, what parameter can I set to allow as many classes to be loaded at startup and stay in memory for as long as possible?
Thanks,
Rob Bartlett

Hi Robert
Also, if the host running the WebAS is a multi processor machine, then setting the flags
-XX:+UseConcMarkSweepGC and
-XX:+UseParNewGC
will help reduce the pause time during the GC collection in old generation and the young genereation respectively, as the GC will happen using multiple threads
I can suggest you to check if the GC performs a minor collection or major collection by enabling the flags
-verbose:gc
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails. Based on this, try to tune the young or old generation.
Regards
Madhu

Forcing JVM to unload bytecode at runtime, to allow reloading of new class?

Hi all,
I would like to know a few things about classes once they are loaded. I believe a loaded class is nothing more than an Object in terms of its lifecycle, correct? If so, then to make a class "unload", you simply have to make sure there are no references to the class correct? So, what are the rules for making sure nothing references a class instance?
Below I'll list a couple of examples. In Example 1 below, I have class A, B and C. Class A creates a instance variable to class B. In the constructor of class A, it creates a temporary class C, passing to it a reference of itself, which C stores in a local variable. Now, in class C, since it is only created in a Constructor (or method) in class A, it goes out of scope at the end of the method/constructor, and thus its reference to class A is no longer any good, correct? Therefore, at this point, there are no references to class A and thus setting A = null (assuming a "central" class loads class A, B and C like a plugin engine would do) should properly dispose of class A. I know, the GC does NOT necessarily remove the class A bytecode from memory right away. So I guess a question here is in need. When does the class A bytecode actually get removed from the JVM memory, in such a way that a "new" call to create it would effectively tell the JVM to have to open the .class file, read its byte code and create a new instance of it in memory? The purpose of these questions is to figure out how, at runtime to reload a class AND get the actual new version of the code. The reason is, if you do everything possible to unload a class, but the JVM doesn't discard the bytecodes of the class before you tell it to load the same class, it will use the "old" bytecode it has in memory, rather than load the bytecode off the HD or URL location and discard the old bytecode. I need a way to get the JVM to discard the bytecode to reload a newer version of a class. But the reason for the examples below is to also help me understand how a class is actually permitted to be unloaded by the JVM. This is also so that the JVM is not wasting memory with multiple versions of the same class, if it even does that. I want to definitely reclaim any memory used by the older version of the class, before loading a newer version.
So, in example 2 below, the situation changes slightly. A is now keeping a reference to the class C it creates in the constructor. Because C also creates a reference back to A since the A instance is passed in to C's constructor, A can now not be freed and made available for unloading until the reference to A in C is set to null, is this correct? I seem to lack basic understanding of how the whole reference counting thing works for objects and when a JVM can actually unload the bytecode of an object, thus freeing up memory. I suppose a good book on the JVM would clear this up, but I am hoping one of you reading this will know and can help me understand this process. So in this example, am I correct in that the C reference to A must be set to null, then the A instance must be set to null to tell the JVM there is no more use for the A class? I do realize that if other classes also use A, that the bytecode for A would be kept in memory. Let's assume this is the only use of A, B and C (and looking at the examples, B serves no real purpose anyway, but I already wrote it down so I'll leave it).
So once again, my goal here is to understand the lifecycle of an object, specifically a Class object (they are one and the same, correct, in terms of lifecycle?), and when the JVM actually removes the bytecode from memory so that if a new version of the same class is now available at runtime, the JVM loads the new bytecode into memory.
Thanks very much for taking the time to read this and reply.
Example 1:
class A
B b = new B();
public A()
C c = new C(this);
class B
public B()
class C
A a = null;
public C(A a)
this.a = a;
Example 2:
class A
B b = new B();
C c = null;
public A()
c = new C(this);
class B
public B()
class C
A a = null;
public C(A a)
this.a = a;
}

Cross post (numerous times.)
http://forum.java.sun.com/thread.jsp?thread=292465&forum=37&message=1152136

Compile and call the class during the runtime

Hi guys,
I am struggling with a project, which allow user to modify the behavior of the program.
To do this, my Java code must be able to compile the Java code (*.java) and call the class from the code during the runtime.
Here are my code:
com.sun.tools.javac.Main javac = new com.sun.tools.javac.Main();
String[] options = new String[] {"d:\\javaExternal\\RunTimeCompilation.java"};
System.out.println(Main.compile(options));This allows me to compile the .java file into .class file. However, I can't find the way to access/use the .class file.
Do you guys have solution for this?
Thanks a lot.

You will also need to investigate class unloading and proxies since presumably they can modify the file and compile it again.
Might note that in general this seldom works for business solutions. It seems like allowing the users to add their own functionality would be a good idea so the programmers don't have to keep doing it. But the reality is that then the users must become programmers. And often must be pretty good at it as well since they must not only know the programming language but also the framework too. The second problem is that it also becomes a maintenance nightmare for the real developers to upgrade the existing system.

How can I notice whether a class is loaded or not?

In the case of a instance, finallize() method can do it. But when it is a class?
Does anyone know the way?

In old JVM, the gc will collect any classes without any reference, however, JDK1.2 uses a new tech to collect classes, that is only if all classes that loaded by the same class loader do not have any reference to them, they are unloaded. So, in JDK1.2, if all you classes are loaded by the same class loader, once the class is loaded, it will be there untill you exit the program. Only if you use your own class loader to load some classes, or the application is a distributed application (that is, multiple JVMs are in use), the class unload and reload could be a problem.
There is no direct finalize thing for classes, maybe JVM profile could help, since some application can use it to analysis the running program's memory usage (includes classes loaded). Or maybe a customized class loader could help. I'm not sure. Also the static initial codes could let you know the class is re-loaded, though it can't tell you when the class is un-loaded.

Jump in Young GG (ParNew) times after CMS-concurrent-reset

In one of our automated test scenarios following a CMS-concurrent-reset, young GC times dramatically increased. For instance, prior to the CMS reset, average young GC times average 0.15 seconds; after the CMS reset, times would spike to as high as 40 seconds. With our high-load scenario this does not happen. The difference in data load between these two tests is approximately 360:1.
Usually when this occcurs, the young GC times would stay consistently high (between 30 and 40 seconds). However, in one of our most recent test runs, something else happened. Young GC times would spike and then over a period of time gradually decrease back down to tolerable levels (over a period of 3.5+ hours). The log snippet below illustrates this behavior.
The application itself is a custom server built on Java 1.5.0_06 using Java 1.5.0_06erdist1. The hardware is a Dell PowerEdge 6800 running Windows 2003 Server 64-bit w/SP1. The server has 32GB of RAM, no swap file, and 8 logical CPU's (4 hyperthreaded Xeon processors). The system caches large amounts of data in a variety of strong, soft, and weak reference maps is using SleepyCat Software's DBJE for data storage.
We're working on getting memory dumps, but right now, we're thinking it might have something to do with large arrays in the old generation either being reallocated, or references back to the young generation that could be causing this. There is a slight possibility that there is also a large object being allocated in the young generation, although this seems like it is less likely (the average data packet is less than 1K in this test scenario and most object allocations are usually less than 4K in size -- byte arrays usually).
We're also looking at possibly testing with the latest 1.6 beta to see if the problem goes away, or at the very least we can profile the app when it gets into trouble without having to turn off CMS.
Does anybody have any thoughts on what might be causing this, or has anyone else run into something similar before?
The JVM Args used are:
-server
-Xms28G
-Xmx28G
-enableassertions
-XX:-UsePerfData
-XX:+PrintVMOptions
-XX:-TraceClassUnloading
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-verbose:gc
-XX:MaxTenuringThreshold=0
-XX:SurvivorRatio=20000
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0
-XX:+ParallelRefProcEnabled
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:ParallelGCThreads=7
-XX:NewSize=128M
-XX:MaxNewSize=128M
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing
-XX:CMSIncrementalDutyCycleMin=0
-XX:CMSIncrementalDutyCycle=10
-XX:CMSMarkStackSize=8M
-XX:CMSMarkStackSizeMax=32M
-XX:+UseLargePages
-XX:+DisableExplicitGC
64255.634: [GC 64255.634: [ParNew: 127304K->0K(131008K), 0.2955450 secs] 14370952K->14273019K(28671936K) icms_dc=0 , 0.2957102 secs]
64270.829: [GC 64270.829: [ParNew: 130944K->0K(131008K), 0.2805740 secs] 14403963K->14286161K(28671936K) icms_dc=0 , 0.2807523 secs]
64287.158: [GC 64287.158: [ParNew: 129676K->0K(131008K), 0.2908535 secs] 14415837K->14289089K(28671936K) icms_dc=0 , 0.2911033 secs]
64297.966: [GC 64297.966: [ParNew: 130602K->0K(131008K), 0.2682085 secs] 14419692K->14311368K(28671936K) icms_dc=0 , 0.2683754 secs]
64308.812: [GC 64308.812: [ParNew: 126613K->0K(131008K), 0.2965320 secs] 14437982K->14336914K(28671936K) icms_dc=0 , 0.2967070 secs]
64319.249: [GC 64319.249: [ParNew: 128966K->0K(131008K), 0.2878087 secs] 14465880K->14364326K(28671936K) icms_dc=3 , 0.2879923 secs]
64329.585: [GC [1 CMS-initial-mark: 14364326K(28540928K)] 14428075K(28671936K), 0.0367576 secs]
64329.622: [CMS-concurrent-mark-start]
64340.074: [GC 64340.074: [ParNew: 130758K->0K(131008K), 0.2824739 secs] 14495085K->14372339K(28671936K) icms_dc=3 , 0.2826438 secs]
64341.411: [CMS-concurrent-mark: 0.873/11.789 secs]
64341.411: [CMS-concurrent-preclean-start]
64341.411: [CMS-concurrent-preclean: 0.000/0.000 secs]
64341.557: [CMS-concurrent-abortable-preclean-start]
64341.557: [CMS-concurrent-abortable-preclean: 0.000/0.000 secs]
64350.684: [GC 64350.684: [ParNew: 130944K->0K(131008K), 0.2899810 secs] 14503283K->14395507K(28671936K) icms_dc=3 , 0.2901651 secs]
64363.365: [GC 64363.365: [ParNew: 130944K->0K(131008K), 0.2975003 secs] 14526451K->14421343K(28671936K) icms_dc=3 , 0.2976791 secs]
64372.076: [GC[YG occupancy: 83987 K (131008 K)]64372.076: [Rescan (parallel) , 0.0674530 secs]64372.144: [weak refs processing, 0.0308673 secs]64372.175: [class unloading[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor27]
64372.182: [scrub symbol & string tables, 0.0083922 secs] [1 CMS-remark: 14421343K(28540928K)] 14505331K(28671936K), 0.1281897 secs]
64372.206: [CMS-concurrent-sweep-start]
64376.703: [GC 64376.703: [ParNew: 130944K->0K(131008K), 0.3150279 secs] 14552287K->14443248K(28671936K) icms_dc=3 , 0.3152040 secs]
64393.182: [GC 64393.183: [ParNew: 130944K->0K(131008K), 0.2967053 secs] 14570664K->14441684K(28671936K) icms_dc=3 , 0.2968985 secs]
64395.855: [CMS-concurrent-sweep: 2.118/23.650 secs]
64395.856: [CMS-concurrent-reset-start]
64396.202: [CMS-concurrent-reset: 0.346/0.346 secs]
64404.846: [GC 64404.846: [ParNew: 130944K->0K(131008K), 11.8319372 secs] 452302K->326245K(28671936K) icms_dc=0 , 11.8321090 secs]
64420.865: [GC 64420.865: [ParNew: 130944K->0K(131008K), 11.8750319 secs] 457189K->352203K(28671936K) icms_dc=0 , 11.8752811 secs]
64435.536: [GC 64435.536: [ParNew: 130944K->0K(131008K), 11.8229769 secs] 483147K->374039K(28671936K) icms_dc=0 , 11.8231579 secs]
64448.564: [GC 64448.564: [ParNew: 130944K->0K(131008K), 12.2692927 secs] 504983K->376605K(28671936K) icms_dc=0 , 12.2694811 secs]
64462.276: [GC 64462.276: [ParNew: 130944K->0K(131008K), 12.0860714 secs] 507549K->401835K(28671936K) icms_dc=0 , 12.0862452 secs]
64478.522: [GC 64478.522: [ParNew: 126250K->0K(131008K), 12.3507999 secs] 528085K->428168K(28671936K) icms_dc=0 , 12.3509812 secs]
64492.047: [GC 64492.047: [ParNew: 130944K->0K(131008K), 11.7977262 secs] 559112K->450172K(28671936K) icms_dc=0 , 11.7979055 secs]
64505.333: [GC 64505.333: [ParNew: 130944K->0K(131008K), 11.6679971 secs] 581116K->475511K(28671936K) icms_dc=0 , 11.6681951 secs]
64523.377: [GC 64523.377: [ParNew: 130944K->0K(131008K), 12.1859479 secs] 606455K->496955K(28671936K) icms_dc=0 , 12.1861274 secs]
64537.004: [GC 64537.004: [ParNew: 130944K->0K(131008K), 12.3909395 secs] 627899K->500863K(28671936K) icms_dc=0 , 12.3911184 secs]
64550.836: [GC 64550.836: [ParNew: 130944K->0K(131008K), 13.3435750 secs] 631807K->522967K(28671936K) icms_dc=0 , 13.3437711 secs]
64565.421: [GC 64565.421: [ParNew: 130943K->0K(131008K), 12.1759533 secs] 653910K->551883K(28671936K) icms_dc=0 , 12.1761337 secs]
64578.968: [GC 64578.968: [ParNew: 129670K->0K(131008K), 11.7518116 secs] 681553K->565967K(28671936K) icms_dc=0 , 11.7519997 secs]
64595.156: [GC 64595.156: [ParNew: 130944K->0K(131008K), 12.7430090 secs] 696911K->588549K(28671936K) icms_dc=0 , 12.7431996 secs]
64609.154: [GC 64609.155: [ParNew: 127642K->0K(131008K), 13.4122057 secs] 716191K->613789K(28671936K) icms_dc=0 , 13.4123919 secs]
64623.588: [GC 64623.588: [ParNew: 130934K->0K(131008K), 11.8692832 secs] 744723K->634958K(28671936K) icms_dc=0 , 11.8694631 secs]
64636.690: [GC 64636.690: [ParNew: 130944K->0K(131008K), 12.2170544 secs] 765902K->640533K(28671936K) icms_dc=0 , 12.2172308 secs]
64652.592: [GC 64652.592: [ParNew: 130153K->0K(131008K), 12.5039780 secs] 770687K->670050K(28671936K) icms_dc=0 , 12.5041652 secs]
64665.798: [GC 64665.798: [ParNew: 130944K->0K(131008K), 11.8129872 secs] 800994K->683828K(28671936K) icms_dc=0 , 11.8131695 secs]
64678.710: [GC 64678.710: [ParNew: 130944K->0K(131008K), 12.2518054 secs] 814772K->686723K(28671936K) icms_dc=0 , 12.2519837 secs]
64692.491: [GC 64692.491: [ParNew: 128795K->0K(131008K), 12.4420712 secs] 815519K->711677K(28671936K) icms_dc=0 , 12.4422521 secs]
64706.761: [GC 64706.761: [ParNew: 130944K->0K(131008K), 12.1215915 secs] 842621K->733167K(28671936K) icms_dc=0 , 12.1217708 secs]
64720.486: [GC 64720.486: [ParNew: 130944K->0K(131008K), 12.4783432 secs] 864111K->736715K(28671936K) icms_dc=0 , 12.4785325 secs]
64734.374: [GC 64734.374: [ParNew: 129901K->0K(131008K), 12.6808484 secs] 866617K->763351K(28671936K) icms_dc=0 , 12.6810264 secs]
64748.544: [GC 64748.544: [ParNew: 130944K->0K(131008K), 13.0768090 secs] 894295K->772967K(28671936K) icms_dc=0 , 13.0769936 secs]
64762.836: [GC 64762.836: [ParNew: 130944K->0K(131008K), 12.6763159 secs] 903911K->797964K(28671936K) icms_dc=0 , 12.6764964 secs]
64777.255: [GC 64777.255: [ParNew: 125172K->0K(131008K), 11.3742001 secs] 923137K->823513K(28671936K) icms_dc=0 , 11.3743819 secs]
64789.913: [GC 64789.913: [ParNew: 130944K->0K(131008K), 12.6647870 secs] 954457K->845201K(28671936K) icms_dc=0 , 12.6649700 secs]
64803.944: [GC 64803.944: [ParNew: 127557K->0K(131008K), 12.4356678 secs] 972758K->870316K(28671936K) icms_dc=0 , 12.4358488 secs]
64818.674: [GC 64818.674: [ParNew: 130944K->0K(131008K), 12.1313661 secs] 1001260K->895535K(28671936K) icms_dc=0 , 12.1315657 secs]
64834.764: [GC 64834.764: [ParNew: 129555K->0K(131008K), 11.9518352 secs] 1025090K->925104K(28671936K) icms_dc=0 , 11.9520134 secs]
64848.138: [GC 64848.138: [ParNew: 130944K->0K(131008K), 12.9124929 secs] 1056048K->939587K(28671936K) icms_dc=0 , 12.9127034 secs]
64862.318: [GC 64862.318: [ParNew: 123806K->0K(131008K), 13.0569914 secs] 1063394K->964362K(28671936K) icms_dc=0 , 13.0571688 secs]
64877.530: [GC 64877.530: [ParNew: 130944K->0K(131008K), 12.3056353 secs] 1095306K->986163K(28671936K) icms_dc=0 , 12.3058150 secs]
64891.725: [GC 64891.725: [ParNew: 130944K->0K(131008K), 13.0376824 secs] 1117107K->1007903K(28671936K) icms_dc=0 , 13.0378846 secs]
76591.355: [GC 76591.355: [ParNew: 130944K->0K(131008K), 0.2791594 secs] 15265232K->15138597K(28671936K) icms_dc=0 , 0.2793572 secs]
76600.766: [GC 76600.766: [ParNew: 130944K->0K(131008K), 0.2752963 secs] 15269541K->15160685K(28671936K) icms_dc=0 , 0.2754887 secs]
76611.557: [GC 76611.557: [ParNew: 130944K->0K(131008K), 0.2790154 secs] 15291629K->15165049K(28671936K) icms_dc=0 , 0.2792048 secs]
76622.303: [GC 76622.303: [ParNew: 130944K->0K(131008K), 0.2849006 secs] 15295993K->15187817K(28671936K) icms_dc=0 , 0.2850920 secs]
76632.887: [GC 76632.887: [ParNew: 130944K->0K(131008K), 0.2689896 secs] 15318761K->15213844K(28671936K) icms_dc=0 , 0.2693092 secs]
76643.956: [GC 76643.956: [ParNew: 130879K->0K(131008K), 0.2662928 secs] 15344723K->15236015K(28671936K) icms_dc=0 , 0.2664782 secs]
76656.379: [GC 76656.379: [ParNew: 130944K->0K(131008K), 0.2872218 secs] 15366959K->15242404K(28671936K) icms_dc=0 , 0.2874433 secs]
76664.841: [GC 76664.841: [ParNew: 130868K->0K(131008K), 0.2931068 secs] 15373273K->15269283K(28671936K) icms_dc=0 , 0.2932965 secs]
76677.732: [GC 76677.732: [ParNew: 130920K->0K(131008K), 0.2475306 secs] 15400203K->15276884K(28671936K) icms_dc=0 , 0.2477292 secs]
76697.644: [GC 76697.644: [ParNew: 130944K->0K(131008K), 0.2879494 secs] 15407828K->15280611K(28671936K) icms_dc=0 , 0.2881359 secs]
76707.426: [GC 76707.426: [ParNew: 130944K->0K(131008K), 0.2911420 secs] 15411555K->15285072K(28671936K) icms_dc=0 , 0.2913233 secs]
76717.857: [GC 76717.857: [ParNew: 130944K->0K(131008K), 0.2701989 secs] 15416016K->15309374K(28671936K) icms_dc=0 , 0.2703928 secs]
76728.560: [GC 76728.561: [ParNew: 130944K->0K(131008K), 0.2931724 secs] 15440318K->15333673K(28671936K) icms_dc=0 , 0.2933609 secs]
76739.261: [GC 76739.262: [ParNew: 126315K->0K(131008K), 0.2973160 secs] 15459989K->15363224K(28671936K) icms_dc=0 , 0.2974960 secs]
76749.705: [GC 76749.705: [ParNew: 127396K->0K(131008K), 0.2972422 secs] 15490620K->15382987K(28671936K) icms_dc=0 , 0.2975240 secs]
76767.794: [GC 76767.794: [ParNew: 130944K->0K(131008K), 0.2838999 secs] 15513931K->15391591K(28671936K) icms_dc=0 , 0.2840901 secs]
76773.076: [GC 76773.076: [ParNew: 130944K->0K(131008K), 0.2552678 secs] 15522535K->15393025K(28671936K) icms_dc=0 , 0.2554467 secs]
76790.058: [GC 76790.058: [ParNew: 130860K->0K(131008K), 0.2934145 secs] 15523885K->15394843K(28671936K) icms_dc=0 , 0.2936080 secs]
76802.396: [GC 76802.396: [ParNew: 130604K->0K(131008K), 0.2972303 secs] 15525447K->15397713K(28671936K) icms_dc=0 , 0.2974271 secs]
76813.202: [GC 76813.202: [ParNew: 130169K->0K(131008K), 0.2880799 secs] 15527883K->15422970K(28671936K) icms_dc=0 , 0.2882746 secs]
76823.896: [GC 76823.896: [ParNew: 129924K->0K(131008K), 0.2832927 secs] 15552894K->15452588K(28671936K) icms_dc=0 , 0.2834869 secs]
76834.357: [GC 76834.358: [ParNew: 130767K->0K(131008K), 0.2764792 secs] 15583355K->15474140K(28671936K) icms_dc=0 , 0.2766770 secs]
76855.497: [GC 76855.497: [ParNew: 130897K->0K(131008K), 0.2894657 secs] 15605037K->15488217K(28671936K) icms_dc=0 , 0.2896626 secs]
76866.253: [GC 76866.253: [ParNew: 130944K->0K(131008K), 0.2999675 secs] 15619161K->15490659K(28671936K) icms_dc=0 , 0.3001493 secs]
76879.530: [GC 76879.530: [ParNew: 130944K->0K(131008K), 0.2816982 secs] 15621603K->15493104K(28671936K) icms_dc=0 , 0.2818897 secs]
76888.031: [GC 76888.031: [ParNew: 130944K->0K(131008K), 0.2760192 secs] 15624048K->15498672K(28671936K) icms_dc=0 , 0.2762118 secs]
76898.232: [GC 76898.232: [ParNew: 125483K->0K(131008K), 0.3109439 secs] 15624155K->15528482K(28671936K) icms_dc=0 , 0.3111342 secs]
76914.416: [GC 76914.416: [ParNew: 130944K->0K(131008K), 0.3065572 secs] 15659426K->15542745K(28671936K) icms_dc=0 , 0.3067479 secs]
76924.748: [GC 76924.748: [ParNew: 130883K->0K(131008K), 0.2937243 secs] 15673628K->15544088K(28671936K) icms_dc=0 , 0.2938988 secs]
76942.226: [GC 76942.226: [ParNew: 130944K->0K(131008K), 0.2960886 secs] 15675032K->15547980K(28671936K) icms_dc=0 , 0.2962779 secs]
76951.345: [GC 76951.345: [ParNew: 130944K->0K(131008K), 0.3050291 secs] 15678924K->15573683K(28671936K) icms_dc=0 , 0.3052196 secs]
76961.936: [GC 76961.936: [ParNew: 130944K->0K(131008K), 0.2914707 secs] 15704627K->15595952K(28671936K) icms_dc=0 , 0.2916589 secs]
76972.575: [GC 76972.575: [ParNew: 129330K->0K(131008K), 0.2838618 secs] 15725283K->15621207K(28671936K) icms_dc=0 , 0.2840550 secs]
76986.283: [GC 76986.284: [ParNew: 130939K->0K(131008K), 0.2933898 secs] 15752146K->15643239K(28671936K) icms_dc=0 , 0.2935624 secs]
76997.181: [GC 76997.181: [ParNew: 130944K->0K(131008K), 0.3075952 secs] 15774183K->15645463K(28671936K) icms_dc=0 , 0.3077828 secs]
77007.913: [GC 77007.913: [ParNew: 130944K->0K(131008K), 0.2958084 secs] 15776407K->15647422K(28671936K) icms_dc=0 , 0.2960437 secs]
77018.011: [GC 77018.011: [ParNew: 130910K->0K(131008K), 0.2964236 secs] 15778333K->15649978K(28671936K) icms_dc=0 , 0.2966224 secs]
77034.694: [GC 77034.694: [ParNew: 130944K->0K(131008K), 0.3092856 secs] 15780922K->15652024K(28671936K) icms_dc=0 , 0.3094763 secs]
77047.053: [GC 77047.054: [ParNew: 130944K->0K(131008K), 0.3015745 secs] 15782968K->15657359K(28671936K) icms_dc=0 , 0.3017561 secs]
77057.249: [GC 77057.249: [ParNew: 130944K->0K(131008K), 0.3185589 secs] 15788303K->15680967K(28671936K) icms_dc=0 , 0.3188166 secs]
77070.581: [GC 77070.581: [ParNew: 130944K->0K(131008K), 0.3062147 secs] 15811911K->15706444K(28671936K) icms_dc=0 , 0.3064015 secs]
77078.801: [GC 77078.801: [ParNew: 123632K->0K(131008K), 0.3221894 secs] 15830077K->15732164K(28671936K) icms_dc=0 , 0.3223794 secs]
77092.282: [GC 77092.282: [ParNew: 130944K->0K(131008K), 0.3141997 secs] 15863108K->15754279K(28671936K) icms_dc=0 , 0.3143788 secs]
77104.965: [GC 77104.965: [ParNew: 130936K->0K(131008K), 0.2957323 secs] 15885215K->15756444K(28671936K) icms_dc=0 , 0.2959160 secs]
77120.762: [GC 77120.762: [ParNew: 130944K->0K(131008K), 0.2967338 secs] 15887388K->15759133K(28671936K) icms_dc=0 , 0.2969243 secs]
77125.566: [GC 77125.566: [ParNew: 130944K->0K(131008K), 0.3192459 secs] 15890077K->15761500K(28671936K) icms_dc=0 , 0.3194239 secs]
77134.280: [GC 77134.280: [ParNew: 130930K->0K(131008K), 0.3128382 secs] 15892430K->15763820K(28671936K) icms_dc=0 , 0.3130111 secs]
77148.565: [GC 77148.565: [ParNew: 130944K->0K(131008K), 0.3146629 secs] 15894764K->15766067K(28671936K) icms_dc=0 , 0.3148481 secs]
77166.762: [GC 77166.762: [ParNew: 130944K->0K(131008K), 0.2902859 secs] 15897011K->15769686K(28671936K) icms_dc=0 , 0.2904642 secs]
77173.957: [GC 77173.957: [ParNew: 130944K->0K(131008K), 0.3132502 secs] 15900630K->15794955K(28671936K) icms_dc=0 , 0.3134416 secs]
77184.689: [GC 77184.689: [ParNew: 130944K->0K(131008K), 0.3122028 secs] 15925899K->15817089K(28671936K) icms_dc=0 , 0.3123857 secs]
77195.961: [GC 77195.961: [ParNew: 130944K->0K(131008K), 0.3101975 secs] 15948033K->15823153K(28671936K) icms_dc=0 , 0.3103801 secs]
77212.697: [GC 77212.697: [ParNew: 130944K->0K(131008K), 0.3109774 secs] 15954097K->15845044K(28671936K) icms_dc=0 , 0.3111528 secs]
77217.947: [GC 77217.947: [ParNew: 130933K->0K(131008K), 0.2913624 secs] 15975978K->15846428K(28671936K) icms_dc=0 , 0.2915358 secs]
77237.788: [GC 77237.788: [ParNew: 129457K->0K(131008K), 0.2967028 secs] 15975885K->15849363K(28671936K) icms_dc=0 , 0.2968859 secs]
77248.232: [GC 77248.232: [ParNew: 130441K->0K(131008K), 0.3249377 secs] 15979804K->15872164K(28671936K) icms_dc=0 , 0.3251147 secs]
77259.231: [GC 77259.231: [ParNew: 130939K->0K(131008K), 0.3262398 secs] 16003104K->15893957K(28671936K) icms_dc=0 , 0.3264322 secs]
77269.578: [GC 77269.578: [ParNew: 130944K->0K(131008K), 0.3244924 secs] 16024901K->15897801K(28671936K) icms_dc=0 , 0.3246682 secs]
77280.109: [GC 77280.109: [ParNew: 129785K->0K(131008K), 0.3440615 secs] 16027587K->15923895K(28671936K) icms_dc=0 , 0.3442430 secs]
77290.806: [GC 77290.806: [ParNew: 125725K->0K(131008K), 0.3185027 secs] 16049620K->15950674K(28671936K) icms_dc=0 , 0.3186805 secs]
77302.797: [GC 77302.797: [ParNew: 130859K->0K(131008K), 0.3043288 secs] 16081533K->15958590K(28671936K) icms_dc=0 , 0.3045180 secs]
77312.365: [GC 77312.365: [ParNew: 130944K->0K(131008K), 0.2918505 secs] 16089534K->15960772K(28671936K) icms_dc=0 , 0.2920314 secs]
77322.862: [GC 77322.863: [ParNew: 130944K->0K(131008K), 0.3015737 secs] 16091716K->15963449K(28671936K) icms_dc=0 , 0.3017476 secs]
77343.729: [GC 77343.729: [ParNew: 130944K->0K(131008K), 0.3236395 secs] 16094393K->15967208K(28671936K) icms_dc=0 , 0.3238134 secs]
77354.586: [GC 77354.586: [ParNew: 130944K->0K(131008K), 0.3131893 secs] 16098152K->15970188K(28671936K) icms_dc=0 , 0.3133721 secs]
77364.952: [GC 77364.952: [ParNew: 130944K->0K(131008K), 0.3102413 secs] 16101132K->15992949K(28671936K) icms_dc=0 , 0.3104283 secs]
77377.458: [GC 77377.458: [ParNew: 130935K->0K(131008K), 0.3312504 secs] 16123885K->16015429K(28671936K) icms_dc=0 , 0.3314204 secs]
77386.642: [GC 77386.642: [ParNew: 130944K->0K(131008K), 0.3294257 secs] 16146373K->16018109K(28671936K) icms_dc=0 , 0.3296290 secs]
77397.408: [GC 77397.408: [ParNew: 130944K->0K(131008K), 0.3466004 secs] 16149053K->16041639K(28671936K) icms_dc=0 , 0.3467640 secs]
77407.720: [GC 77407.720: [ParNew: 127181K->0K(131008K), 0.3291395 secs] 16168820K->16067781K(28671936K) icms_dc=0 , 0.3293197 secs]
77419.256: [GC 77419.257: [ParNew: 127292K->0K(131008K), 0.3417004 secs] 16195074K->16101594K(28671936K) icms_dc=3 , 0.3418733 secs]
77426.886: [GC [1 CMS-initial-mark: 16101594K(28540928K)] 16165188K(28671936K), 0.0349381 secs]
77426.921: [CMS-concurrent-mark-start]
77428.941: [GC 77428.941: [ParNew: 130944K->0K(131008K), 0.2950079 secs] 16232538K->16108380K(28671936K) icms_dc=3 , 0.2951910 secs]
77438.826: [CMS-concurrent-mark: 0.913/11.904 secs]
77438.826: [CMS-concurrent-preclean-start]
77438.826: [CMS-concurrent-preclean: 0.000/0.000 secs]
77439.028: [CMS-concurrent-abortable-preclean-start]
77439.028: [CMS-concurrent-abortable-preclean: 0.000/0.000 secs]
77439.480: [GC 77439.480: [ParNew: 126872K->0K(131008K), 0.3251631 secs] 16235253K->16139128K(28671936K) icms_dc=3 , 0.3253437 secs]
77447.411: [GC[YG occupancy: 66352 K (131008 K)]77447.411: [Rescan (parallel) , 0.0551127 secs]77447.466: [weak refs processing, 0.0308647 secs]77447.497: [class unloading[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor28]
77447.504: [scrub symbol & string tables, 0.0084419 secs] [1 CMS-remark: 16139128K(28540928K)] 16205480K(28671936K), 0.1156339 secs]
77447.528: [CMS-concurrent-sweep-start]
77450.331: [GC 77450.331: [ParNew: 127555K->0K(131008K), 0.3276881 secs] 16257886K->16148782K(28671936K) icms_dc=3 , 0.3278723 secs]
77471.167: [GC 77471.168: [ParNew: 130944K->0K(131008K), 0.3443864 secs] 16264980K->16156348K(28671936K) icms_dc=3 , 0.3445624 secs]
77484.330: [GC 77484.331: [ParNew: 130944K->0K(131008K), 0.3138211 secs] 16282337K->16155285K(28671936K) icms_dc=3 , 0.3139971 secs]
77490.323: [GC 77490.323: [ParNew: 130887K->0K(131008K), 0.3463333 secs] 16266084K->16158092K(28671936K) icms_dc=3 , 0.3465076 secs]
77503.075: [GC 77503.075: [ParNew: 130944K->0K(131008K), 0.3230820 secs] 16246239K->16117912K(28671936K) icms_dc=3 , 0.3232641 secs]
77513.508: [GC 77513.508: [ParNew: 130944K->0K(131008K), 0.3446744 secs] 16232772K->16104890K(28671936K) icms_dc=3 , 0.3449231 secs]
77526.076: [GC 77526.076: [ParNew: 130173K->0K(131008K), 0.3488064 secs] 16219569K->16093708K(28671936K) icms_dc=3 , 0.3490094 secs]
77535.048: [GC 77535.048: [ParNew: 130944K->0K(131008K), 0.3444742 secs] 16091984K->15984538K(28671936K) icms_dc=3 , 0.3447258 secs]
77540.284: [CMS-concurrent-sweep: 1.808/92.757 secs]
77540.285: [CMS-concurrent-reset-start]
77540.637: [CMS-concurrent-reset: 0.352/0.352 secs]
77547.483: [GC 77547.483: [ParNew: 130944K->0K(131008K), 21.2268491 secs] 569606K->465738K(28671936K) icms_dc=0 , 21.2270424 secs]
77570.056: [GC 77570.056: [ParNew: 129623K->0K(131008K), 21.8197998 secs] 595362K->492094K(28671936K) icms_dc=0 , 21.8200025 secs]
77592.450: [GC 77592.450: [ParNew: 130901K->0K(131008K), 22.4998156 secs] 622995K->513309K(28671936K) icms_dc=0 , 22.5000306 secs]
77615.471: [GC 77615.471: [ParNew: 130865K->0K(131008K), 24.1625520 secs] 644174K->515142K(28671936K) icms_dc=0 , 24.1627472 secs]

Might it be possible for you to check if the same behaviour reproduces
with the latest (b76?) Mustang JVM?
If so, let us know and we'll look into this more closely.
PS: Could you also pstack the process once it gets into
one of these long scavenges, and see if you find a lot
of "block_start" calls at the top of the stack (during card
scanning). It's almost certainly some performace pathology
related to block offset table accesses during card scanning
in the presence of large contiguous blocks would be my
guess.

Console on Wblogic 9.2 locking up administration server

I am upgrading a 7.0 server to 9.2. Its on a real slow and old sun box. Every 3 or 4 things that I do seems to cause the console to stop responding.
The console worked great in 7.0.
When I do a prstat on the server I see the process is taking up 47% of the cpu but it never seems to really do anything. The only way I can stop the servers in my WLS instance at this point is to do a kill -9. I have waited up to an hour to see if it ever returns, and it does not.
Any help would be appreciated.

Hi,
The lack of support is always frustrating. If you are getting paid support from BEA, and getting fuzzy answers, you should let them know.
My experience with BEA, and their support team is the opposite from what you are telling me, they were almost every time very prompt, and knowledgeable. Once every now and then, I do have some issues that they were not able to figure it out, but always very professional.
The parameter PermSize is a parameter to the JVM, this is independent of WL itself, and this is the minimal size of what is known as permanent generation fold. This is just a chunk of memory reserved to the class loading, class unloading, and class reflection information. Given that a web app server does a lot of class loading/unloading, and given that it looks like WL 9.x is really dependent on the introspection/reflection APIs, this extra memory helps WL performance. If you define the PermSize=128m on your development/testing environment without any issue, this same parameter should work with the production environment (with a production deployment/configuration.) Of course, if you have a server with just the admin console, and a managed server with your app, this should also help the performance (if you can handle the extra memory load.)
If you are outnumbered on the move to JBoss, you can do nothing, but just remember that JBoss is no heaven either.
Regards,
LG

Strange GC behaviour

We have an application which is very heavy on object creation. When we run the application after 4-6hours we get OutOfMemory(OOM) even though there seems to be enough memory and high enough permanent generation space (~256MB).
I have tried various options to use parallel young generation and CMS GC for olf generation. Also tried allowing class unloading from the permanent generation space. We do not get OOM now but the application grinds to halt with a very high CPU usage, which corresponds to long and contunuous GC that takes more than 10 second for minor collections.
I have tried various settings to help the promotion of objects in the YG to tenured space by lowering the size of YG and setting JVM parameters to compact the tenured space to prevent fregmentation.
Profiler does not show any suspicuos memory leak in our application.
However, there is something happening in the GC logs that I cannot understand. The following is from the GC output
12199.621: [GC 12199.622: [ParNew: 16256K->0K(16320K), 0.2017510 secs] 207698K->191557K(786368K), 0.2019374 secs]
12201.795: [GC 12201.795: [ParNew: 16256K->0K(16320K), 0.2048213 secs] 207813K->192260K(786368K), 0.2050363 secs]
12203.873: [GC 12203.873: [ParNew: 16256K->0K(16320K), 0.2146450 secs] 208516K->194418K(786368K), 0.2148564 secs]
12206.033: [GC 12206.033: [ParNew: 16256K->0K(16320K), 1.0297104 secs] 329458K->314748K(786368K), 1.0299117 secs]
12208.379: [GC 12208.379: [ParNew: 16256K->0K(16320K), 0.9179062 secs] 331004K->316549K(786368K), 0.9181090 secs]
12211.448: [GC 12211.448: [ParNew: 16256K->0K(16320K), 0.9260658 secs] 332805K->318359K(786368K), 0.9262664 secs]
If you look at the output in bold where the GC time jumps from 0.2148564 secs to 1.0299117 secs, the heap size after collection also jumps from 194418K to 314748K.
How could this be? A jump of 120330K is more than 7 times bigger that the YG size. This cannot be due to object allocation?
Only thing I can think of is a JVM bug with class loaders. I found a JVM bug with class loaders (5033614) which is according to release notes fixed with in 1.4.2_07. I have tried 1.4.2_08 with no success.
I observed this sort of jumps are happening wiht class unloading messages such as below where GC time jumps from 0.3070497 secs to 1.0390087 secs.
5231.303: [GC 5231.304: [ParNew: 16256K->0K(16320K), 0.3068234 secs] 386613K->370358K(786368K), 0.3070497 secs]
5231.866: [GC 5231.866: [ParNew: 12685K->0K(16320K), 0.4980721 secs]5232.365: [CMS[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor138]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor20]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor29]
[Unloading class sun.reflect.GeneratedMethodAccessor13]
: 370358K->195960K(770048K), 3.4865979 secs] 383043K->195960K(786368K), 3.9850061 secs]
5236.620: [GC 5236.620: [ParNew: 16256K->0K(16320K), 1.0387359 secs] 331000K->314830K(786368K), 1.0390087 secs]
AFAIK this would only happen when there is not enough space in the Permanent Generation space. This would even happen even with the -XX:PermSize=256m -XX:MaxPermSize=256m. Is there something else that triggers class unloading? (Tuning off class unloading did not help with the GC times)
The platform is 2 CPU Solaris 9, 1.4.2 Sun JDK, OC4J app server. And the log is produced with
java -server -XX:PermSize=192m -XX:MaxPermSize=192m -XX:NewSize=8m -XX:MaxNewSize=8m -Xms1024m -Xmx1024m -XX:SurvivorRatio=64 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:-CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -Djava.awt.headless=true -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -jar oc4j.jar
Any comment is greatly appreciated.

I do not have the heap statistics when OOM occurred but there were enoughtmemory available then. I am certain that permanenet generation space was not exceeded which was 256MB and never exceeds 128MB in my GC output analysis. I suspect it was something to do with heap resizing so I fixed -Xms and -Xmx to do same value and run parallel and CMS garbage collection and we did not get the OOM again.
However, the stack dump when OOM occurred consistently showed a line in our code with a thread in 'waiting on condition' state. The code that is implicated is only using log4j to log some messages.
"HttpRequestHandler-1450695169" prio=5 tid=0x00000001018bc6b0 nid=0x19 waiting on condition [ffffffff012ff000..ffffffff01301500]
I suspected of a thread deadlod but stack dump shows no deadlock message. Profiling of the app also did not point out any deadlocks. Is there a known issue with log4j in this area? (I could not find any reference to this on the Internet)
With the current settings we do not get OOM but we get some unusual behviour as I posted in my original post which shows a jump in old generation (probably permanent generation or C heap) that is 7+ time bigger than the objects allocated in that period.
At the moment I see continuous and slow GC without any apparent need -plenty of tenured and permanent space are available. The young generation collection is taking too long with CPU consumption stauck at ~95%. See below
19384.564: [GC 19384.564: [ParNew: 8064K->0K(8128K), 5.5018406 secs] 563049K->555965K(1048512K), 5.5020402 secs]
19390.254: [GC 19390.255: [ParNew: 8064K->0K(8128K), 5.2093746 secs] 564029K->556598K(1048512K), 5.2095620 secs]
19395.593: [GC 19395.594: [ParNew: 8064K->0K(8128K), 5.1898968 secs] 564662K->557699K(1048512K), 5.1900956 secs]
19400.904: [GC 19400.904: [ParNew: 8064K->0K(8128K), 5.1879878 secs] 565763K->558361K(1048512K), 5.1881776 secs]
I don't think promation of YG objects|fragmentation of tenured spaces is the problem as the YG is set to be very small 8MB (ond heap is 768MB) and compaction is done for tenured space (-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0).
I don't have a test case as I do not know the cause . The application is very large and under heavy load with plenty of reflection code but observation of GC output showed Permanent Generation remains under 128MB and we are having this problem with settings of -XX:PermSize=256m -XX:MaxPermSize=256m
I cannot understand GC behaviour I described in my original post but I did see similar bug entries with no satisfactory explanation from the Sun engineers.
I suspect C Heap might be strained and it might be it that is causing class unloading as I said it occurs even when there is plenty of Permanent Generation space is available (turning off class unloading did not help either).

Class unloading

Similar Messages

Maybe you are looking for