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 <[EMAIL PROTECTED]> 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
>
> .
