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 14:07:13 GMT
On 10/27/06, Geir Magnusson Jr. <geir@pobox.com> 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 <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