harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] Class unloading support
Date Fri, 27 Oct 2006 12:38:23 GMT


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?

> 
> 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 <rdasgupt@gmail.com> 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 <aleksey.ignatenko@gmail.com> 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
>> >
>> > .
>>
>>
> 
> 

Mime
View raw message