harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Fri, 27 Oct 2006 04:41:58 GMT
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 <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
> >
> > .
>
>


-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message