harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Ignatenko" <aleksey.ignate...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Fri, 27 Oct 2006 05:18:11 GMT
Rana,



>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?



- One example is Eclipse, when you build something with ant. E.g. building
kernel classes with ant in Eclipse will create separate class loader every
time developer performs build operation, so it means that sources rebuilding
will initiate VM native memory accumulation (memory leaks: class related
data, JIT code and so on) on Eclipse. This process is very similar to normal
development process, so developer as soon as he has native memory over on
his PC will have to stop drlvm and rerun Eclipse to eliminate memory
overflow problem caused by class unloading absence. Also I think that drlvm
would not be able to pass some cyclic many days scenarios which use separate
class loader for every step, e.g. some reliability testing.

>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 <http://j.l.cl/> instance a weak refernce and the reverse not a
weak reference?



- class registry means *strong references* from j.l.Classes to their
defining j.l.Classloader and *strong references* from j.l.Classloader to
j.l.Classes loaded by it. We provide weak roots (weak references inside VM)
to every j.l.Classloader because we have to detect the moment when VM can
start unloading of appropriate class loader. It means that as soon as there
are fulfilled 3 class unloading conditions (see in the first letter *)
j.l.Classloader object will be collected by GC and weak root to it is
zeroed, so this is the moment when VM detects that current classloader was
unloaded and it destroys its native sources.

>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.......



- You are partially right, as I already said in some letter number of
VTables is *proportional* (no equal) to number of classes. Now details:

Every object  is described with VTable object, but VTable object is also a
full Java object, it means it is to have its own VTable object. But there 1
little specifics that prevents us from infinite sequence of VTables. VTable
describing object has variable size according to the objects class specifics
(number of methods). Lets name VTable of object as VT. Now VT should have
own VTable, name it VTable_for_VT. This VTable_for_VT describes VT (e.g.
size of VT as it's different for different classes), but in its turn
VTable_for_VT has always the same size (as VT is specific and has no methods
in its class). Therefore all VTable_for_VT objects could be described with
only one last VTable object, name it VTable_for_VTable. So, we have the
following structure:

VTable_for_VTable -> VTable_for_VT -> VT -> object. VTable_for_VTable object
is the only one object for the whole VM, VTable_for_VT and  VT objects are
created for every class loaded.

So as you can see this is not an infinite sequence of VTable "tail" for
every object. Probably, this could a bit unclear first, then probably I
could draw some pictures to show the idea.



>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?



-Yes. To avoid heap fragmentation GC should allocate pinned objects via
special malloc like function like gc_pinned_alloc (see
issues.apache.org/jira/browse/HARMONY-1935).

>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?

- Heap pressure is to be measured when unloading is done, but I feel
optimistic on that because number of VTable object is small comparing to the
total number of objects on heap. Adding j.l.Class reference to every object
will lead to great memory footprint increase. This about object overhead.
Right now it is 8 bytes for every object (IA32, Compressed mode). Adding
additional reference to the object header will increase object overhead on 4
bytes (IA32). Lets consider some application having about 1 million of
objects, them memory footprint will increase on 4Mb. I'm not familiar what
is the number of objects on Eclipse launch. Does anyone have this data?

Initially there was an idea to trace j.l.Class via native struct VTable
(simply doable of gcv4 versions of GC) that led to the problem: slot
referencing to j.l.Class was out of the Java heap and there would be
problems with next version of GC. I think, Ivan, could explain it in
details.



The current automatic unloading design is heavily connected to the current
drlvm architecture and implementation specifics, therefore we have to choose
between pinning and memory overhead or maybe something else to get uniform
support of class unloading.

Aleksey.


On 10/27/06, Weldon Washburn <weldonwjw@gmail.com> 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.
>
> 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