harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Fri, 27 Oct 2006 07:10:52 GMT
  Thanks for the answers, please see inline.

On 10/26/06, Aleksey Ignatenko <aleksey.ignatenko@gmail.com> wrote:
> >Rana,
> >- 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 sounds like an Eclipse bug or strange design to me that they don't
maintain state.

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

That was my point. That we are trying to do an invasive optimization for a
problem that does not exist yet. We don't have these cyclic scenarios on
memory constrained systems.

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

Yes, I understand that you break the recursion by creating a self
referential structure when the vtables stop being unique. Thanks. That was
why I asked if the Vtable class is a special class.

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

Let's wait to hear from other GC developers as well, what do you think? Eg.,
one solution can be to allocate pinned objects at the edge, or outside the
main Java heap, but these have several implications on performance or on the
success of your proposed method.

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

I agree with the overall statement that adding a reference to each object as
opposed to each class( vtable ) would possibly create more heap pressure. I
can't do more theoritical analysis than that. But  java vtables have other
issues, as discussed on this thread...an impact to devirtualization, need
for pinning, etc. The question is whether we need this optimization, and all
the associated changes now. And if this is the best way to implement it.


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