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
