Rana,
You state that DRLVM does not implement the class unloading optimization, and this may create memory pressure on some applications that load many classes. Do we have a real case / example where an application is stuck for insufficient memory because it uses a lot of classes initially and then stops using them, but these are not unloaded? One can imagine a web browser doing something like this. Is a web browser a typical use case for the Harmony JVM?
- One example is Eclipse, when you build something with ant. E.g. building kernel classes with ant in Eclipse will create separate class loader every time developer performs build operation, so it means that sources rebuilding will initiate VM native memory accumulation (memory leaks: class related data, JIT code and so on) on Eclipse. This process is very similar to normal development process, so developer as soon as he has native memory over on his PC will have to stop drlvm and rerun Eclipse to eliminate memory overflow problem caused by class unloading absence. Also I think that drlvm would not be able to pass some cyclic many days scenarios which use separate class loader for every step, e.g. some reliability testing.
Regarding your engineering choices, choice 2 seems nicer, but again I have some questions. 1. In the class registry, is the reference from the j.l.class instance to the j.l.CL <http://j.l.cl/> instance a weak refernce and the reverse not a
weak reference? - class registry means *strong references* from j.l.Classes to their defining j.l.Classloader and *strong references* from j.l.Classloader to j.l.Classes loaded by it. We provide weak roots (weak references inside VM) to every j.l.Classloader because we have to detect the moment when VM can start unloading of appropriate class loader. It means that as soon as there are fulfilled 3 class unloading conditions (see in the first letter *) j.l.Classloader object will be collected by GC and weak root to it is zeroed, so this is the moment when VM detects that current classloader was unloaded and it destroys its native sources.
2. I am missing something about the java vtable object. Is it a first
class
java object with its own java class? In this case the vtable object would have its own vtable which is a java object, but that also would have a vtable and so on...??? In other words if every java object has a vtable, which is a also a java object.......
- You are partially right, as I already said in some letter number of VTables is *proportional* (no equal) to number of classes. Now details: Every object is described with VTable object, but VTable object is also a full Java object, it means it is to have its own VTable object. But there 1 little specifics that prevents us from infinite sequence of VTables. VTable describing object has variable size according to the objects class specifics (number of methods). Lets name VTable of object as VT. Now VT should have own VTable, name it VTable_for_VT. This VTable_for_VT describes VT (e.g. size of VT as it's different for different classes), but in its turn VTable_for_VT has always the same size (as VT is specific and has no methods in its class). Therefore all VTable_for_VT objects could be described with only one last VTable object, name it VTable_for_VTable. So, we have the following structure: VTable_for_VTable -> VTable_for_VT -> VT -> object. VTable_for_VTable object is the only one object for the whole VM, VTable_for_VT and VT objects are created for every class loaded. So as you can see this is not an infinite sequence of VTable "tail" for every object. Probably, this could a bit unclear first, then probably I could draw some pictures to show the idea.
3. If I am misunderstanding the above( I hope ), the vtable objects would need to be pinned to avoid patching virtual calls after GC, efficient dispatching etc. Does this not put a requirement on compatible GC's to be able to deal with pinned objects?
-Yes. To avoid heap fragmentation GC should allocate pinned objects via special malloc like function like gc_pinned_alloc (see issues.apache.org/jira/browse/HARMONY-1935).
4. Why cannot one have a j.l.class reference in the object header, as
Weldon
mentions, instead of this new vtable java type? Is the peformance impact known and do we understand it as compared to heap pressure due to the new vtable object?
- Heap pressure is to be measured when unloading is done, but I feel optimistic on that because number of VTable object is small comparing to the total number of objects on heap. Adding j.l.Class reference to every object will lead to great memory footprint increase. This about object overhead. Right now it is 8 bytes for every object (IA32, Compressed mode). Adding additional reference to the object header will increase object overhead on 4 bytes (IA32). Lets consider some application having about 1 million of objects, them memory footprint will increase on 4Mb. I'm not familiar what is the number of objects on Eclipse launch. Does anyone have this data? Initially there was an idea to trace j.l.Class via native struct VTable (simply doable of gcv4 versions of GC) that led to the problem: slot referencing to j.l.Class was out of the Java heap and there would be problems with next version of GC. I think, Ivan, could explain it in details. The current automatic unloading design is heavily connected to the current drlvm architecture and implementation specifics, therefore we have to choose between pinning and memory overhead or maybe something else to get uniform support of class unloading. Aleksey. On 10/27/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
Steve Blackburn was in Portland Oregon today. I mentioned the idea of adding a reference pointer from object to its j.l.Class instance. MMTk was not designed with this idea in mind. It looks like you will need to fix this part of MMTk and maintain it yourself. Steve did not seem thrilled at adding this support to MMTk code base. Have we looked at other class unloading designs? From what I have read in open literature on object layout, I don't recall any special fields to support class unloading. On 10/26/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > Aleksey, > I had a couple of questions. > You state that DRLVM does not implement the class unloading > optimization, > and this may create memory pressure on some applications that load many > classes. Do we have a real case / example where an application is stuck > for > insufficient memory because it uses a lot of classes initially and then > stops using them, but these are not unloaded? One can imagine a web > browser > doing something like this. Is a web browser a typical use case for the > Harmony JVM? > > Regarding your engineering choices, choice 2 seems nicer, but again I have > some questions. > > 1. In the class registry, is the reference from the j.l.class instance to > the j.l.CL instance a weak refernce and the reverse not a weak reference? > 2. I am missing something about the java vtable object. Is it a first > class > java object with its own java class? In this case the vtable object would > have its own vtable which is a java object, but that also would have a > vtable and so on...??? In other words if every java object has a vtable, > which is a also a java object....... > 3. If I am misunderstanding the above( I hope ), the vtable objects would > need to be pinned to avoid patching virtual calls after GC, efficient > dispatching etc. Does this not put a requirement on compatible GC's to be > able to deal with pinned objects? > 4. Why cannot one have a j.l.class reference in the object header, as > Weldon > mentions, instead of this new vtable java type? Is the peformance impact > known and do we understand it as compared to heap pressure due to the new > vtable object? > > Thanks, > Rana > > > > > > On 10/24/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote: > > > > > > Egor, > > > >But it has 1 more "cons" -- JIT should change it's devirtualizer > > > >accordingly to the VTable change. Doable, of course. > > > There is no need to change struct VTable structure - it could be > simply > > > inlined in pinned VTable object + 1 additional reference field to > > > j.l.Class. > > > So there won't be too much work to do on JIT side. > > > > > > >BTW, is it reasonable to "compress" or "enumerate" references to > > > >j.l.Class in each object to reduce the footprint? How many classes > are > > > >alive in heavy-duty applications? not very much probably. > > > We are to trace j.l.Class from every object via VTable to detect if > > > there is > > > any live object of that j.l.Class. This one of requirements of class > > > unloading. > > > As for footprint - there is already pointer to struct VTable in every > > > object, so changing this pointer to reference to VTable Object will > have > > > no > > > effect on footprint. Compressed VTable pointers will be changed to > > > compressed references. The only effect is that VTable object is a full > > > Java > > > object and in its turn it is to have own VTable, so number of VTable > > > objects > > > will encrease for every class. As Vtable is a small object footprint > > > will > > > encrease only for tens of bytes for every loaded class, and as I know, > > > there > > > are loaded several thousands classes on Eclipse startup, therefore > > > footprint > > > increase is negligible. > > > > > > Aleksey Ignatenko, > > > Intel Enterprise Solutions Software Division > > > > . > > -- Weldon Washburn Intel Enterprise Solutions Software Division
