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 Sat, 28 Oct 2006 01:35:25 GMT
On 10/27/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>
>
> >Yes. That's also my opinion. The _design_ of class unloading is >the
> >focus of the discussion.



 I think that before doing an optimization, it is a good idea to understand
why and where it is needed, and if the usage scenario fits what the software
is intending to do. So this discussion is not misplaced. I am not very
comfortable with adding a solution before we have understood the problem.
Probably the first step is to create a use case that can be used to see if
class unloading is the solution.

> > 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.
> >
> > I don't really agree.  It could be because of my background, but my
> > experience with java is in long-running, server-side processes, and
> > clean class-unloading is important.
>
> >I don't know what you "don't really agree". :-) My comment was >that we
> >need thorough study to enable the special design so that the >ongoing
> >development in other components are not impacted too much, >and there
> >are still some issues to be discussed and resolved in this design.


I have the same question. At this point, solution 2 looks more sensible than
solution 1. But that's about all. The design is quite invasive. If we want
to prototype this, my suggestion would be to do this in a branch, create a
use case, demonstrate its value, run stability tests, and then merge it.

> > 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.
> >
> > That's a different story :)  I'm not advocating one design over another,
> > but we have to be able to dump classloaders w/o leaking memory.
>
>

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