On 10/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Weldon Washburn 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. How does MMTk support class unloading then?
MMTk has no special support for class unloading. This may have something to do with the entire system being written in Java thus class unloading come along for free. If there needs to be a modification to support special case objects in DRLVM, someone will need to fixup MMTk and provide onging support of this patch in Harmony. I have zero idea how big this effort would be. It would also be good to hear what the impact will be on GCV5. If the immediate goal for svn HEAD is stability, changing something as fundamental as object layout may not be a good idea. On the other hand, its good to provide an environment where folks can publicly experiment on things like object layout and different class unloading schemes without dragging along GCV5, MMTk, etc. Maybe a branch makes sense?
> 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
