I don't recognise this exact class.
There was a problem before 2.4.4 with proxy classes
not getting garbage collected due to their methods
being cached and not released.
You don't mention any version numbers, OS/JBoss/VM
How many is thousands? The garbage collector can
be unpredictable at times. Sometimes you get
stuff lying around the heap, but the garbage doesn't
seem to be interested. Using System.gc() reveals
there really is no problem.
Did you get this information from hprof?
What is the stacktrace for the site (the number in
the last column before the class name)?
I am using JBoss 2.4.4, Windows 2000 Server (and Professional) and JDK 1.4 RC. I am using OptimizeIT so I have not got any information from hprof.
I don't think this is a garbage collection problem, because the number of instances is zero. The problem is that the class is loaded. After about 15 minutes of running I have 2000 classes of this sort loaded, and it increases fast.
Perhaps you can explain what you're app is doing?
Maybe you could post a simple version that has the same
problem. I'll have a look to see whether it is a leak
within JBoss or just a lazy garbage collector :-)
But, I don't have JDK 1.4
I have done a very simple bean and client (attacted to this message). Even with this simple example I see that there are loaded hundreds of classes named sun.reflect.GeneratedSerializationConstructorAccessorXXXX,there XXXX is a running number. I also se a small memory leak.
I would be very thankful if you could run this example in OptimizeIt and give me some help. (The problem is the same with JDK1.3).
I haven't got optimizeIt, but I have used hprof.
Interestingly, that class does not appear.
I have got a class called that has 1575
live references out of a total of 1577 allocated,
this is probably the class you are referring to.
Anyway, using hprof, there is only one jboss reference
left over from the test.
This is the SecurityAssociation that gets attached
the thread. This won't get garbage collected until
the thread ends.
The other objects not garbage collected are all
as I would expect.
Caching of Jar entries for the classes loaded
Caching of security
Caching of RMI worker objects
Once you start using RMI it creates some helpers that are
kept for future use. I think the class you are referring
to is one of these. The number of live objects doesn't
change, regardless of the number of iterations.
P.S. I wouldn't recommend creating an InitialContext in
a loop. I think you know this, and you are only testing :-)