harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From usman bashir <grip...@gmail.com>
Subject Re: [Arch] Class unloading and VM objects reclaim
Date Wed, 28 Sep 2005 07:55:44 GMT
I might be wrong but i few thougths as well:
i think When loading a class loader let him manage his heap i.e. a memory
should be associated per class loader for general objects (i.e. objects that
will be garbadge collected) however as for as Strings are concerns thay must
be shared gloablly as to follow the requirements imposed by the Java specs.
The main concern is how they will be vanished depends upon the references to
them and it could be managed entirly separtelly by providing a stack manage
that can link between the class loaders and the Strings and this will ensure
that Stack mem manager could reclaim the objects when there is no link to a
 similarlly buffers should be on the class loaders disposal as i think they
must eb controlled from the objects being gc'd and if the objects are being
reclaimed then these buffers should too.However if we see that buffers are
being shared then we can provide a buffers manager which can do the same
trick that is adopted in the string pattren.
 it will track the links between the two and if found zero referenced
buffer, then it can reclaim the memory.
 so providing stack memory manager/ or i would say linker (classloaders and
their string objects) and then buffer manager/linker we can acheive the
required goal with some overhead though.

 On 9/13/05, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Archie Cobbs wrote:
> > Santiago Gala wrote:
> >
> >> IIRC, the (JVM spec v2) requirement for .equals String literals to be
> >> (==)identical only holds for Strings in the same .class file, but I
> >> could be wrong.
> >
> >
> > I believe the requirement is stronger than that. Any two
> > String literals (i.e., String constants from class files)
> > that are the same string must be the same object (==).
> > It doesn't matter if they come from different classes.
> I agree. All identical string literals must refer to the same instance.
> http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#73272
> >> In any case, interning all VM Strings in some sort of global weak set
> >> would do the trick, as shared literals would remain referenced on
> >> classloader collection, while unreferenced ones would be eligible for
> >> collection. This is typically how symbols in lisp or smalltalk are
> >> managed (most implementations don't even bother to use a weak
> structure,
> >> so symbols are never collected). Basically this is what String.intern()
> >> does, and nothing impedes us to actually use it for all Strings in the
> >> VM.
> >
> >
> > This is how Classpath works. Strings are intern'd using a weak
> > hash map and String.intern() is implemented in pure Java.
> > The JVM does nothing special for strings, with the exception
> > that when it creates them from class files it also interns them.
> I'd speculate that the VM interns many more strings loading classes than
> typical Java code calls to the API, so provided the call into Java is
> low-cost this works fine.
> > -Archie
> >
> >
> __________________________________________________________________________
> > Archie Cobbs * CTO, Awarix * http://www.awarix.com
> >
> --
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.

Usman Bashir
Certified IBM XML Solution Developer
Certified UML Developer
Brainbench Certified Internet Perfessional[advance](BCIP)
Brainbench Certified Java Perfessional (BCJP)
Brainbench Certified .NET Perfessional
Brainbench Ceritified C++ Perfessional (BCCP)
Software engineer IT24
Faculty Member Operation Badar Lahore

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