usman bashir wrote:
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
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 f
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.,
Hello,
> It is useful to be able to specify certain characteristics of the
> virtual memory regions, eg that the nursery is at higher addresses,
> because the efficiency of the read and write barriers depends on being
> able to quickly identify nursery objects, and having the nursery in high
> add
> I don't see why both methods of memory allocation and clean up may not
be
> employed. The classLoader may manage it's own memory area and create
> objects that only it uses in the main memory area. The main memory area
> objects would be true objects and be gc'ed just like normal (So long as
> th
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
El jue, 08-09-2005 a las 15:51 +0100, Peter Edworthy escribió:
(...snip...)
> [long version]
> Cleaning up Strings that are only used in a particular classloader has
> a
> slight catch; because of the 'Strings containing the same characters
> are
> the same object' clause. This requires keeping a l
Hello,
I don't see why both methods of memory allocation and clean up may not be
employed. The classLoader may manage it's own memory area and create
objects that only it uses in the main memory area. The main memory area
objects would be true objects and be gc'ed just like normal (So long as
the
Xiao-Feng Li wrote:
Archie, thanks for the info, the approach looks like the second one I
suggested. We can take it at first.
Hmmm.. guess I don't understand what you meant by "The former approach
can reclaim as more as possible VM objects".. could you explain?
Btw, there are some situations
Archie, thanks for the info, the approach looks like the second one I
suggested. We can take it at first.
Btw, there are some situations I am not sure if the approach you
mentioned is possible. For example, we may want to reclaim also VM
structures for strings that is not associated with a class l
Xiao-Feng Li wrote:
They are basically two approaches to unload the classes, one is to
encode the VM object similarly as App object with a header, then GC
can treat them uniformly (almost); the other approach treats class
unloading specially, which reclaims a class loader together with all
its as
I totally agree with Xiao feng's proposal
Best Regards,
William Wu
Software Engineer
Sybase Shanghai R&D Center
Room 1202-1206, Building One,
Zhangjiang Semiconductor Industry Park
3000 Longdong Avenue
Pudong, Shanghai 201203
Tel: 8621-68799918 ext 3081
Fax: 8621-68790199
Email: [EMAIL PROTEC
Hi, folks,
Class unloading is an optimization Harmony wants to have, and it
should be straightforward to implement the class unloading semantics
proposed by Java Language Specification. We want to push this a bit
further to allow more VM data structures be reclaimed. We call them VM
objects w.r.t
13 matches
Mail list logo
