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