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 Mon, 30 Oct 2006 07:36:38 GMT
Hi, everyone.



I'd like to summarize the discussion about unloading here. Almost everyone
agreed that class unloading is very important for Harmony project and this
work should be continued.

There were discussed 3 proposals of class unloading designs. There are 2
initially proposed designs where automatic class unloading design was chosen
to be the best. Looks like the latest discussion leads to the possible
proposal of the third reference counting design. The best design is going to
be chosen by community on the basis of performance, complexity, unification
and some other criteria.

Discussion led to one very important additional criterion of class unloading
design, it is modifications efforts of class unloading implementation. It is
considered a very important moment as it affects gc_cc, gc_gen, gcv4, mmtk
and possibly some future developments.



I've put automatic class unloading implementation into JIRA (
issues.apache.org/jira/browse/HARMONY-2000) (see limitations: IA32 and gcv4,
gc_cc is in the progress yet).



There are realized 2 main ideas of class unloading feature:

   1. Native class resources cleanup (which is common for any class
   unloading design).
   2. Introduced automatic class unloading mechanism implementation.



*Native class resources cleanup.*

This cleanup is done when some j.l.Classloader was unloaded. Class related
structures, jit code, are to be cleaned up. There are also common used
collections (like Method_lookup_table), which should be updated relative to
changed number of classes (to avoid crashes and other different
unpredictable situations).

I want to mention one very important cleanup implemented – jit code. You can
see mem_alloc.h/cpp files to see code pool which is used for code and stubs
memory allocations. This is archaic static pool which uses one lock for all
allocations synchronization. It does not allow freeing code memory for
definite unloaded class loader. The patch contains new Code pool attached to
Classloader, all memory allocation are done inside Class loader's pool, so
it could be simply destroyed, plus there is done some optimization on memory
allocation in that pool.



*Introduced automatic class unloading mechanism implementation.*

Struct VTable moved to be VTable object. First of all, having in mind, that
changing object layout (changing VTable* to reference to VTable object in
object header) requires a lot of changes on both VM/GC sides no changes were
done in object layout. Now implementation specifics: struct VTable is
inlined in VTable object, that means that VTables object contains struct
VTable in it's body, so there is formula: (ManagedObject* vtObj; VTable*
vt;) vt =  vtObj + object_header_size(). It means that Vtable object differs
from struct VTable only by object header offset and we can simply convert
VTable object to struct VTable and vice versa. The only change which is done
to struct VTable is adding ManagedObject* jlC; field which is mapped to
reference to appropriate j.l.Class field in VTable Object and automatically
traced by GC. As there is no changes in object layout GC is to calculate
VTable object vtObj from Struct VTable pointer vt (vtObj = vt –
object_header_size()) and trace it for every object (see mark_scan.cpp
changes).

There is a question why VTable object could be needed in object header
(object layout change)? The answer is trivial: this could be required to
avoid GC tracing VTable objects in special way. We can make additional
reference field for every class by reference zero (where VTable is located)
to let GC know that there is references field by zero offset. Then GC will
trace VTable object automatically. I can provide changes in object layout
but I actually prefer not to do this or to do it incrementally (to the
current patch) to avoid additional implementation complications (because it
affects VM/GC + JIT and stubs).

Conclusions:

- Automatic unloading design does not require changing object layout.
Changing object layout could be considered as an enhancement.

- All changes in the patch are done with requirement of minimum code changes
overhead.

- 50% of class unloading task (native class resources cleaning) is done
independent to class unloading mechanism.

Please, ask your questions,

Aleksey.


On 30 Oct 2006 11:40:36 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
>
> On the 0x210 day of Apache Harmony Rana Dasgupta wrote:
> > I completely agree.
> >
> > +1 for branch if Aleksey wants to experiment
>
> are there any problems with Java VTables in any of the components? JIT
> has no problems, as we discussed. GC should not suffer too, I
> guess. If we meet some problems that take long to fix (and many people
> to do it all), then it may become reasonable to make a branch. But not
> earlier. AFAIR, nobody died of a couple of interdependant JIRAs yet.
>
> So, I would suggest to hold on with braching until it is a strong
> reason.
>
> >
> > On 10/27/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > >
> > > All, I think the problem now is mainly about the class unloading
> > > design not about whether class unloading happens in server
> > > environment.
> > >
> > > Class unloading is definitely a feature required in future; but with
> > > the significance of the required modifications in JVM by this class
> > > unloading design 2 (using Java object for Vtable), it is probably
> > > safer to move this work into a branch at the moment until all other
> > > components are ready for it, and after we have thorough evaluation on
> > > it since there are still issues to be resolved or discussed.
> > >
> > > Or we can keep it in JIRA and keep the discussion and evaluation going
> > > on before we decide to support the special design (Java Vtable) in
> > > other components.
> > >
> > > How about it?
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > > On 10/27/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > > >
> > > >
> > > > Rana Dasgupta wrote:
> > > > > My knowledge in this area is limited. But my understanding was
> that
> > > web
> > > > > servers and other similar hosts recycled processes periodically as
> > > > > standard procedure, thereby tearing down all associated resources.
> > > >
> > > > Yes, but that has nothing to do with what would be happening in the
> app
> > > > server the web server talked to, if one had an architecture where a
> web
> > > > server "fronted" for the app server.
> > > >
> > > > > So
> > > > > classes loaded, but not used for a while went away anyway;
> > > >
> > > > Nope - they aren't loaded in the context of the webserver (when
> using
> > > > httpd).
> > > >
> > > > > this level of
> > > > > resource management was not really urgent. I know that IIS does
> this,
> > > I
> > > > > am not sure about httpd. I am not sure about other host
> environments.
> > > >
> > > > But a process fork model (or thread model) of a webserver has
> nothing to
> > > > do with what's going on in the VM.
> > > >
> > > > I'm talking about servlet engines and app servers like Tomcat and
> > > > Geronimo which have nothing to do with httpd.  Architecturally, they
> are
> > > > separated from the web server (unless you don't use an external
> > > > webserver, and just use the httpd connector in tomcat) and are
> separate,
> > > > independent processes.
> > > >
> > > >      httpd  <------>  Tomcat
> > > >
> > > > The java-based app servers are long running processes, running for
> weeks
> > > > or months.  We need to do clean class unloading.
> > > >
> > > > geir
> > > >
> > > >
> > > > >
> > > > >
> > > > > On 10/27/06, *Geir Magnusson Jr.* <geir@pobox.com
> > > > > <mailto:geir@pobox.com>> wrote:
> > > > >
> > > > >
> > > > >
> > > > >     Rana Dasgupta 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?
> > > > >      >
> > > > >
> > > > >     If I understand what you're asking correctly, you'll find this
> > > pattern
> > > > >     in servlet engines or J2EE servers, where deployed apps can be
> > > dumped
> > > > >     and reloaded repeatedly either during development or during
> > > production
> > > > >     deployment, w/o taking the server down.
> > > > >
> > > > >     geir
> > > > >
> > > > >
> > > >
> > >
>
> --
> Egor Pasko, Intel Managed Runtime Division
>
>

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