Reg. Class Unloading issue in 640 WebAS SP15

[Former Member]

Hi

I am running 640 SP15 engine to measure the PermSize utilization and Loaded Classes using ESS scenarios.

The ESS scenarios are performed once and the measurements are taken and the ESS application is re-deployed again to the engine.

After re-deployment, I performed the ESS scenarios again and I forced full GCs several times and found that only few of the ESS classes are unloaded(classes that were loaded prior to re-deployment). But I expect all the

ESS classes (that were loaded previously) to be unloaded at this step.

During some Full GCs, I did not see any classes getting unloaded but the PermSize(utilized permanent space)came down. I tried to figure out any possible reasons for this but could not find. Any insights into this will be greatly helpful!!!

I used 'jvmstat' from SUN in conjunction with 'sherlok' from SAP for measuring PermSize and Loaded/Unloaded classes.

Thanks and Regards

Madhu

[monika_kovachka-dimitrova · Accepted solution]

Hi Madhu,

During the redeployment and the stop of each application the deploy service unregisters the classloader and in some point of time it should be garbage collected. However there are 2 known reasons which might cause the experienced problem:

1.The ESS application(s) have passed some objects to other application(s), which did not have declared reference, so the deployment could not restart the other applications, and they are still holding references to objects created by the previous classloaders of ESS.

2.There is still a running thread which was created from the first application loader and the loader will be kept until the thread is alive. The thread should exit on the application stop in order to make the cleanup.

In both of the cases above the obsolete classloader will not be released until the object(s)/thread(s) are not fully released. And thus the classloader can stay for indefinite time.

I guess the colleagues from the ESS should take a look at the problem and identify in which case they may have such behavior and fix it otherwise the application classloader will not be garbage collected even though it was released from the deploy service, and a new one is created with the redeployed version of the application.

Best regards,

Monika

[Former Member · Accepted solution]

Hi Monika

Thanks for your reply but I already checked (prior to posting this message) the instances of classloaders with the help of JProfiler to see if they are getting accumulated and if so try to find out the root but unfortunately, the old classloader instances were freed up when a GC is forced. Also, it was made sure that no previous threads were alive before forcing a GC.(waited for a session time-out period)

So my question here is: The old classloader instances are freed up but there is no decrease in the permsize during initial forced GCs and similaryl during next forced GCs, there are no unloaded classes but a decrease in the permsize is observed. what could be the reason for this?

Is this the problem with the tools or something??

Thanks and Regards

Madhu

[Former Member · Accepted solution]

Hi,

I have profiled similar effects in the past. When it comes down to finding causes (references) for not garbage collected class files, I suggest trying YourKit Profiler. While JProfiler wasn't even showing that there were two class files definitions of class X in my memory (in two different class loaders), YourKit was able to find the complete reference path for both class files.

This may be related to the fact that JProfiler is using static fields as a garbage collection root (without resolving to the "real" root)

Regards,

Dieter

[Former Member]

Madhu,

please, could you give some details on how you managed to use 'jvmstat'? I tried the same with NetWeaver EP 04 SP14, but I couldn't attach to the jcontrol processes because I did not see them, no matter what I tried...

I'd be glad to spend as many points I can on !

Thanks in advance,

Victor