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 17:05:17 GMT
On 10/28/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> On 10/28/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> >
> > 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.
> Rana, I do not understand why do you call class unloading 'an
> optimization'. In this case any GC is optimization too. Class
> unloading is fundamental feature of
> Java language. I would even say that if your application uses custom
> classloader and you never thought about class unloading the design of your
> application is not complete.
> We can never claim that Harmony supports Java 1.5 or even Java 1.2 if it
> does not support unloading for classloaders. As for me, this is very
> important to have this feature and Aleksey's patch is quite a good
> beginning. At least in JIT it does not require any changes at all.

>From JLS:-

"Rationale: Class unloading is an optimization that helps reduce memory use.
Obviously, the semantics of a program should not depend on whether and how a
system chooses to implement  an optimization such as class unloading.....".

And ...

 "Strictly speaking, it was never essential that the issue of class
unloading be discussed by the Java Language Specification, as it is an
optimization. However, it is a subtle issue, and so it was mentioned by way
of clarification. Unfortunately, misunderstandings arose, aggravated by the
the class unloading behavior of JDK 1.1. This behavior  was not mandated by
the Java Language Specification. Indeed, it contradicted the specification;
it was simply a bug. The bug has been fixed in JDK 1.2, and the
specification clarified to avoid such misunderstandings in the future."

Anyway, I don't want to belabor this point forever, and my opinion is only
one among many :-)


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