Aleksey,
> 1. Mark and scan based approach.
> 2. Automatic class unloading approach.
In the #2, is there any chance for other components to be notified about
unloaded classes?
I can imagine many scenarios when a component needs to keep some data
associated with the classes. If a class gets unloaded, then other
components may need to clean up internal data as well.
The use cases I can think of are:
- a JIT that does whole program optimizations and associate some data
with the classes - a profile data for example.
- a GC that again uses some class-related data. For example to improve
locality of allocated objects basing on their types.
Perhaps there are other scenarios exist.
Or may be you have a proposal how to associate a resources with the
classes in such cases?
--
Thanks,
Alex
Aleksey Ignatenko wrote:
Hello all!
As you probably know current version of harmony DRLVM has no class
unloading
support. This leads to the fact that some Java applications accumulate
memory leaks leading to memory overflow and crashes.
In this message I would like to describe two approaches for class unloading
in DRLVM and propose to implement one of them as basic. Pros and cons for
both approaches are presented below. Lets name these approaches:
1. Mark and scan based approach.
2. Automatic class unloading approach.
*Current DRLVM implementation specifics.*
All Java.lang.Class (j.l.Class) and java.lang.Classloader (j.l.Classloader)
instances are enumerated as strong roots inside VM, which leads to the
state
when all j.l.Class and j.l.Classloader instances are always reachable.
To unload class loader CL three conditions are to be fulfilled (*):
1. j.l.Classloader instance of CL is unreachable.
2. Classes (j.l.Class instances) loaded by CL are unreachable.
3. No object of any class loaded by CL exists.
Here is brief description for the both approaches:
*Mark and scan based approach.*
Java heap trace is performed by VM Core at the beginning of stop-the-world.
If some class loader and its classes are unreachable and there is no object
of these classes, then exclude this class loader from enumeration to
make GC
collect it. After GC happens and appropriate j.l.Classloader instance is
collected – remove native resources from C heap: class loader and all
classes loaded by it, jitted code and so on. Corresponding Java objects
should already be collected by GC at this moment.
Pros:
- Simplicity – requires only additional mark&scan functionality on VM side
to detect classes for unloading + few changes in enumeration algorithm.
Cons:
- Requires additional GC/VM functionality to trace j.l.Class and
j.l.Classloader instances from each object.
- Duplicates mark&scan functionality on VM side.
- Affects every plugged GC.
- "Stop-the-world" state of VM is required, i.e. all threads except the one
performing unloading should be suspended.
- Possibly some additional limitations on new GCs.
*Automatic class unloading approach.*
"Automatic class unloading" means that j.l.Classloader instance is unloaded
automatically (w/o additional enumeration tricks or GC dependency) and
after
we detect that some class loader was unloaded we destroy its native
resources. To do that we need to provide two conditions:
1. Introduce reference from object to its j.l.Class instance.
2. Class registry - introduce references from j.l.Classes to its
defining j.l.Classloader and references from j.l.Classloader to
j.l.Classes loaded by it (unloading is to be done for
j.l.Classloaderand corresponding
j.l.Classes at once).
*Introduce reference from object to its j.l.Class instance.*
DRLVM has definite implementation specifics. Object is described with
native
VTable structure, which has pointers to class and other related data.
VTables can have different sizes according to object class specifics. The
main idea of referencing j.l.Class from object is to make VTable a special
Java object with reference to appropriate j.l.Class instance, but give it a
regular object view from GC point of view. VTable pointer is located in
object by zero offset and therefore can be simply considered as reference
field. Thus we can implement j.l.Class instance tracing from object via
VTable object. VTable object is considered to be pinned for simplification.
In summary, having class registry and reference from object to its
j.l.Classinstance we guarantee that some class loader CL can be
unloaded only if
three conditions are fulfilled described above (*). To find out when Java
part of class loader was unloaded j.l.Classloader instance should be
enumerated as weak root. When this root becomes equal to null – destroy
native memory of appropriate class loader.
Pros:
- Unification of unloading approach – no additional requirements from GC.
- Stop-the-world is not required.
- GC handles VTables automatically as regular objects.
Cons
- Number of objects to be increased.
- Memory footprint to be increased both for native and Java heaps (as
VTable
objects appear).
*Conclusion. *
I prefer automatic class unloading approach due to the described set of
properties (see above). It is more flexible and perspective solution. Also
JVM specification is mostly related to automatic class unloading approach
while mark and scan based approach looks more like class unloading
workaround.
Please, do not hesitate to ask questions.
Best regards,
Aleksey Ignatenko,
Intel Enterprise Solutions Software Division.
