Weldon, I've created separate jira H-2158 called "native resource cleanup".
So you can proceed with closing H-2000.
Aleksey.
On 11/10/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> I wonder if you might want to create a new JIRA t
On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I wonder if you might want to create a new JIRA that's clear about what
the point is, and close the class unload JIRa for now.
I was hoping someone would suggest closing HARMONY-2000. Unless there are
objections in the next 24 hours
I wonder if you might want to create a new JIRA that's clear about what
the point is, and close the class unload JIRa for now.
geir
Pavel Pervov wrote:
On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Hang on - we aren't going to consider this patch quite yet, are we? We
have a v
Sorry for the confusion. We are getting ourselves all tangled up with
subconversations in this thread. There have been 90+ replies to the
original posting.
No patch containing class unloading will be committed until Harmony has a
design and the design has been implemented.
What is being discus
On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Hang on - we aren't going to consider this patch quite yet, are we? We
have a very active and fruitful discussion going on regarding alternate
approaches?
geir
This part of the patch does not contain class unloading implementation
b
Hang on - we aren't going to consider this patch quite yet, are we? We
have a very active and fruitful discussion going on regarding alternate
approaches?
geir
Aleksey Ignatenko wrote:
Weldon, I have attached updated patch to H-2000:
cleanup_sources_1558_merged.patch.
Please, see comments.
Weldon, I have attached updated patch to H-2000:
cleanup_sources_1558_merged.patch.
Please, see comments.
Aleksey.
On 11/10/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
Aleksey,
I tried to apply native_sources_cleanup_upd.patch. svn HEAD has changed
and
the patch no longer works. Part of
[snip]
Alexey,
it looks like what you are thinking about is *concurrent* collector,
and concurrent garbage collections brings substantial complexity
even without class unloading.
Salikh,
You are correct. Maybe I'm running ahead of the train, but my concern
is that "scalability" of unloading d
Ivan Volosyuk wrote:
On 11/9/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote:
Ivan Volosyuk wrote:
> We will get rid of false sharing. That's true. But it still be quite
> expensive to write those '1' values, because of ping-ponging of the
> cache line between processors. I see only one solution to
Aleksey,
I tried to apply native_sources_cleanup_upd.patch. svn HEAD has changed and
the patch no longer works. Part of the problem is that JIRA 1558 has been
committed. In addition to the below issues, I posted comments to
JIRA HARMONY-2000.
On 11/2/06, Weldon Washburn <[EMAIL PROTECTED]> wr
On 11/9/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote:
Ivan Volosyuk wrote:
> We will get rid of false sharing. That's true. But it still be quite
> expensive to write those '1' values, because of ping-ponging of the
> cache line between processors. I see only one solution to this: use
> separate
Etienne Gagnon wrote:
> Salikh Zakirov wrote:
>> 7) let the GC finish collection and reclaim unreachable objects -- this
>> reclaims java objects
>
> Just a bit of a warning... This should be integrated within the
> weak/soft/phantom + finalization framework. We definitely don't want
> the na
Etienne Gagnon wrote:
> Ivan Volosyuk wrote:
>> We will get rid of false sharing. That's true. But it still be quite
>> expensive to write those '1' values, because of ping-ponging of the
>> cache line between processors. I see only one solution to this: use
>> separate mark bits in vtable per GC t
Ivan Volosyuk wrote:
> We will get rid of false sharing. That's true. But it still be quite
> expensive to write those '1' values, because of ping-ponging of the
> cache line between processors. I see only one solution to this: use
> separate mark bits in vtable per GC thread which should reside in
Salikh Zakirov wrote:
> 7) let the GC finish collection and reclaim unreachable objects -- this
> reclaims java objects
Just a bit of a warning... This should be integrated within the
weak/soft/phantom + finalization framework. We definitely don't want
the native resources of a class loader t
Etienne Gagnon wrote:
>> 3) trace the heap
>> 4) scan vtable marks and "revive" marked class unloaders, by adding the
>> strong root
>> from the previously collected "unload list". Remove the revived
>> classloaders from unload list.
>> 5) repeat steps (3) and (4) until there is no cl
Ivan Volosyuk wrote:
> We will get rid of false sharing. That's true. But it still be quite
> expensive to write those '1' values, because of ping-ponging of the
> cache line between processors. I see only one solution to this: use
> separate mark bits in vtable per GC thread which should reside in
On 11/9/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote:
Salikh Zakirov wrote:
> Technically, it should not be too difficult to add an additional field to the
VTable
> structure, and require GC to write 1 there during object scanning.
> However, if the VTable mark is located in the same cache line
Salikh Zakirov wrote:
> Ah, I think I got it.
Yep.
> 3) trace the heap
> 4) scan vtable marks and "revive" marked class unloaders, by adding the
> strong root
> from the previously collected "unload list". Remove the revived
> classloaders from unload list.
> 5) repeat steps (3) and
Etienne Gagnon wrote:
> "Revival" is only needed if you use the finalization-like approach. If
> you only do class-unloading GC when the nursery is empty, then no
> revival is needed.
Ah, I think I got it.
You mean running a minor collection, and then "class unloading" full heap
collection
s
Etienne Gagnon wrote:
> Salikh Zakirov wrote:
>
>>I have another concern though:
>>just before starting "final unloading" collection, we scan vtable marks and
>>identify
>>the candidates for unloading. During the "final unloading" collection, the
>>candidate classloader roots are reported as wee
Salikh Zakirov wrote:
> I have another concern though:
> just before starting "final unloading" collection, we scan vtable marks and
> identify
> the candidates for unloading. During the "final unloading" collection, the
> candidate classloader roots are reported as week. At the end of the trace,
Etienne Gagnon wrote:
OK. My latest proposal (a few messages ago) was assuming that the
nursery was empty when the "end of epoch collection" is launched.
If it is not, you can do 2 things:
a) do a minor collection to empty it, or
b) i - use a finalization-like list of references to class loa
>> Etienne Gagnon wrote:
>> > My proposal already argued that vtable bit/byte/word marking is
>> > unnecessary for "nursery allocations". You only need to mark the
>> vtable
>> > of objects that survive collection and pretenured objects.
Alexey Varlamov wrote:
> I may have missed it, but I only
> OK. My latest proposal (a few messages ago) was assuming that the
> nursery was empty when the "end of epoch collection" is launched.
>
> If it is not, you can do 2 things:
>
> a) do a minor collection to empty it, or
>
> b) i - use a finalization-like list of references to class loader
>
Alexey Varlamov wrote:
>> > My proposal already argued that vtable bit/byte/word marking is
>> > unnecessary for "nursery allocations". You only need to mark the
>> vtable
>> > of objects that survive collection and pretenured objects.
>
>
> I may have missed it, but I only recall you argued tha
Alexey Varlamov wrote:
2006/11/9, Robin Garner <[EMAIL PROTECTED]>:
Etienne Gagnon wrote:
> Alexey Varlamov wrote:
>> Sorry if it was already discussed, but I believe this approach also
>> requires marking vtable bit/byte on each object allocation, unitl the
>> "unloading" GC pass is strictly st
Salikh Zakirov wrote:
> Technically, it should not be too difficult to add an additional field to the
> VTable
> structure, and require GC to write 1 there during object scanning.
> However, if the VTable mark is located in the same cache line as gcmap,
> it may severely hit parallel GC performanc
2006/11/9, Robin Garner <[EMAIL PROTECTED]>:
Etienne Gagnon wrote:
> Alexey Varlamov wrote:
>> Sorry if it was already discussed, but I believe this approach also
>> requires marking vtable bit/byte on each object allocation, unitl the
>> "unloading" GC pass is strictly stop-the-world full-heap c
Robin Garner wrote:
> Etienne Gagnon wrote:
>> 3- Why would it be so hard to add an unconditional write operation
>> during collection (e.g. during copying or marking of an object) in
>> drlvm? A detailed technical explanation is welcome. :-)
>
> I actually believe that this should be implementab
Etienne Gagnon wrote:
Alexey Varlamov wrote:
Sorry if it was already discussed, but I believe this approach also
requires marking vtable bit/byte on each object allocation, unitl the
"unloading" GC pass is strictly stop-the-world full-heap collection.
Robin, did you include this particular overh
Alexey Varlamov wrote:
> Sorry if it was already discussed, but I believe this approach also
> requires marking vtable bit/byte on each object allocation, unitl the
> "unloading" GC pass is strictly stop-the-world full-heap collection.
> Robin, did you include this particular overhead too in your
>
[snip]
> > My proposal has been measured at ~1% overhead in GC time, or 0.1% in
> > execution time (caveats as above). If there is some complexity in
> > establishing classloader reachability from this basis, I would assume it
> > can easliy be absorbed.
Sorry if it was already discussed, but
Uhm, Etienne overtook me with earlier posts.
Seems we are beginning to converge with design.
2006/11/9, Alexey Varlamov <[EMAIL PROTECTED]>:
2006/11/8, Robin Garner <[EMAIL PROTECTED]>:
> Robin Garner wrote:
> > Aleksey Ignatenko wrote:
> >> Robin.
> >>
> >>> OK, well how about keeping a weak re
2006/11/8, Robin Garner <[EMAIL PROTECTED]>:
Robin Garner wrote:
> Aleksey Ignatenko wrote:
>> Robin.
>>
>>> OK, well how about keeping a weak reference to the >j.l.ClassLoader
>>> object instead of a strong one. When the reference >becomes (strong)ly
>>> unreachable, invoke the class-unloading
Etienne Gagnon wrote:
3- Why would it be so hard to add an unconditional write operation
during collection (e.g. during copying or marking of an object) in
drlvm? A detailed technical explanation is welcome. :-)
I actually believe that this should be implementable in a GC-neutral
way, whether
Etienne Gagnon wrote:
I was making it more complex than it needs...
Here's an improvement...
1- During normal operation, the VM keeps hard references to all class
loader instances. [This prevents any premature class loader death].
2- At the start of an epoch (or just before), all vtable bits
Note: For preventing collection of class loaders related to active
method frames, there are various solutions. One could simply walk all
method frame stacks just before the end of epoch collection (my
preferred approach) and mark the bit of related vtables. Another
approach would be to add an un
I was making it more complex than it needs...
Here's an improvement...
1- During normal operation, the VM keeps hard references to all class
loader instances. [This prevents any premature class loader death].
2- At the start of an epoch (or just before), all vtable bits (or byte
or word) are cl
[First, let me say that, as I am not contributing a class unloading
*implementation* to drlvm, I will understand if the project was more
inclined to chose an actually contributed piece of code over a design
without contributed implementation. :-)]
There was a "-1" vote... Hmmm... As I voted "+1
On Thu, 2006-11-09 at 02:01 +0300, Ivan Volosyuk wrote:
> Robin,
>
> thank you for detailed description of the algorithm. IMHO, this was
> the most complicated place of the whole story: how to have a weak
> reference to classloader and still be able to get it alive again. This
> shouldn't be perfo
Robin,
thank you for detailed description of the algorithm. IMHO, this was
the most complicated place of the whole story: how to have a weak
reference to classloader and still be able to get it alive again. This
shouldn't be performance critical part and is quite doable. I
absolutely agree with y
Robin Garner wrote:
Aleksey Ignatenko wrote:
Robin.
OK, well how about keeping a weak reference to the >j.l.ClassLoader
object instead of a strong one. When the reference >becomes (strong)ly
unreachable, invoke the class-unloading phase.
If you have weak reference to j.l.Classloader - GC w
Aleksey Ignatenko wrote:
Robin.
OK, well how about keeping a weak reference to the >j.l.ClassLoader
object instead of a strong one. When the reference >becomes (strong)ly
unreachable, invoke the class-unloading phase.
If you have weak reference to j.l.Classloader - GC will collect it (with
Robin.
OK, well how about keeping a weak reference to the >j.l.ClassLoader
object instead of a strong one. When the reference >becomes (strong)ly
unreachable, invoke the class-unloading phase.
If you have weak reference to j.l.Classloader - GC will collect it (with all
appropriate jlClasses)
Pavel Pervov wrote:
Robin,
The kind of model I had in mind was along the lines of:
- VM maintains a linked list (or other collection type) of the currently
loaded classloaders, each of which in turn maintains the collection of
classes loaded by that type. The sweep of classloaders goes somethi
Robin,
The kind of model I had in mind was along the lines of:
- VM maintains a linked list (or other collection type) of the currently
loaded classloaders, each of which in turn maintains the collection of
classes loaded by that type. The sweep of classloaders goes something
like:
for (ClassL
Aleksey Ignatenko wrote:
Hi, Robin.
I do really like this proposed idea of marking VTables from objects via
additional word field in VTable.
But I have one question about detecting reachability of the classloaders
("sweep the vtables and check the reachability of the classloaders").
Possibly I m
Hi, Robin.
I do really like this proposed idea of marking VTables from objects via
additional word field in VTable.
But I have one question about detecting reachability of the classloaders
("sweep the vtables and check the reachability of the classloaders").
Possibly I missed something, but here
I've introduced class unloading test into harmony-2000 attachments:
Test_unloading_native_lib.zip. This test is drlvm class unloading
implementation specific.
Aleksey.
On 11/3/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
Weldon,
>I glanced at native_sources_cleanup.patch. It looks like c
Weldon,
I glanced at native_sources_cleanup.patch. It looks like code for
alloc/dealloc vtables and jitted code blocks. The original patch made
vtables into objects. Will native_sources_cleanup need to change if
vtables
are normal C structs instead? Also, I see reference to path
.../gcv4/.
Rana,
Aleksey, how would one test this?
FIrst of all acceptance tests should PASS. This is required because jitted
code allocation mechanism was changed. The second: I will try to provide
one simple test on class unloading today. We can use class unloading
implementation in Harmony-2000 to pass
On 11/2/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>Robin, thanks for all the clarifications. Now it seems clear to me >and
>I am convinced by this proposal. :-)
Yes, this proposal is the simplest and has the least perf impact. Thanks
Robin.
On 11/3/06, Robin Garner <[EMAIL PROTECTED]> wrote:
Xiao-Feng Li wrote:
> Robin, good idea.
>
> I understand the main difference between your design and Aleksey's
> proposal 1 is, the tracing in your design stops as vtable, but
> Aleksey's continues to classloader. On the other hand, your approac
Xiao-Feng Li wrote:
Robin, good idea.
I understand the main difference between your design and Aleksey's
proposal 1 is, the tracing in your design stops as vtable, but
Aleksey's continues to classloader. On the other hand, your approach
requires an extra step to sweep the vtables in order to det
Aleksey,
Excellent step forward -- breaking the patch into two pieces. This made
the patch(es) much more readable.
I glanced at native_sources_cleanup.patch. It looks like code for
alloc/dealloc vtables and jitted code blocks. The original patch made
vtables into objects. Will native_source
On 11/2/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
>Hi, everyone.
>I've splitted Harmony-2000 (see details:
>http://issues.apache.org/jira/browse/HARMONY-2000) patch >with automatic
>class unloading implementation into 2 independent parts:
>1. cleaning native resources (native_sources_cle
Hi, everyone.
I've splitted Harmony-2000 (see details:
http://issues.apache.org/jira/browse/HARMONY-2000) patch with automatic
class unloading implementation into 2 independent parts:
1. cleaning native resources (native_sources_cleanup.patch).
2. automatic unloading design implementation (auto_u
Robin, good idea.
I understand the main difference between your design and Aleksey's
proposal 1 is, the tracing in your design stops as vtable, but
Aleksey's continues to classloader. On the other hand, your approach
requires an extra step to sweep the vtables in order to determine the
classloade
Weldon Washburn wrote:
Its probably in the noise but it might be possible to
even reduce the overhead of clearing the vtable "mark" by using a epoch
number instead of a boolean. The idea is that after every major GC,
increment the value used for the mark. When sweeping the
On 11/1/06, Robin Garner <[EMAIL PROTECTED]> wrote:
Rana Dasgupta wrote:
> Robin,
>The basic difference of this with Etienne's method is that the flag
is
> on the vtable, instead of the CL instance. Do I understand correctly ?
The
> GC perf impact is therefore reduced because you need to loo
Rana Dasgupta wrote:
Robin,
The basic difference of this with Etienne's method is that the flag is
on the vtable, instead of the CL instance. Do I understand correctly ? The
GC perf impact is therefore reduced because you need to lookup
object->vtable instead of object->class->CLinstancewhen t
Robin,
The basic difference of this with Etienne's method is that the flag is
on the vtable, instead of the CL instance. Do I understand correctly ? The
GC perf impact is therefore reduced because you need to lookup
object->vtable instead of object->class->CLinstancewhen tracing the heap.
The s
On 11/1/06, Robin Garner <[EMAIL PROTECTED]> wrote:
> Interesting idea! It seems the real issue is "marking and sweeping"
the
> vtables. A stab at categorizing the approaches:
>
> a)
> Force vtables to be as similar to ordinary java objects as
possible. The
> upside: existing GC algorithms w
> Interesting idea! It seems the real issue is "marking and sweeping" the
> vtables. A stab at categorizing the approaches:
>
> a)
> Force vtables to be as similar to ordinary java objects as possible. The
> upside: existing GC algorithms will work unaltered. The downside is
> vtables
> of vta
Robin Garner wrote:
> - Allocate a byte (or word) in each vtable for the purpose of tracking
> class reachability.
Yep, there's no reason to keep the bits (or words, for performance) in
the class loader, even in the approach I've proposed. They could be
moved to the vtable.
Etienne
--
Etienne
+1 for this approach. It will give us some kind of class unloading
without much performance impact on GC.
--
Ivan
On 11/1/06, Robin Garner <[EMAIL PROTECTED]> wrote:
Actually, just thinking about how I would implement this in JikesRVM, I
would use the reachability based algorithm, but piggyback
Interesting idea! It seems the real issue is "marking and sweeping" the
vtables. A stab at categorizing the approaches:
a)
Force vtables to be as similar to ordinary java objects as possible. The
upside: existing GC algorithms will work unaltered. The downside is vtables
of vtables of vtable
Oops, sorry, misprinted in my suggestion:
if (cl->IsBootstrap() *||
*env->b_VTable_trace_is_not_supported_by_GC)
{
vm_enumerate_jlc(c);
if (c->vtable)
vm_enumerate_root_reference((void**)&c->vtObj,
FALSE);
Weldon,
A question for all involved. Is it possible to somehow make it appear that
the new objects related to unloading (VTable, ClassLoader, etc) are
always
reachable and thus never collected? I am trying to figure out a way to
make
integration of class unloading independent of correct
Actually, just thinking about how I would implement this in JikesRVM, I
would use the reachability based algorithm, but piggyback on the
existing GC mechanisms:
- Allocate a byte (or word) in each vtable for the purpose of tracking
class reachability.
- Periodically, at a time when no GC is ru
Weldon Washburn wrote:
On 10/30/06, Robin Garner <[EMAIL PROTECTED]> wrote:
Weldon Washburn wrote:
> On 10/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> Weldon Washburn wrote:
>> > Steve Blackburn was in Portland Oregon today. I mentioned the idea
of
>> > adding a reference
Ivan Volosyuk wrote:
Robin, thank you for this information. I want to ask a few questions
to check that I understand you correctly.
On 10/31/06, Robin Garner <[EMAIL PROTECTED]> wrote:
MMTk implements several algorithms for retaining the reachable objects
in a graph and recycling space used by
Aleksey Ignatenko wrote:
>> Am I wrong, or does this proposition imply collecting classes
>> independently from their class loader? If this is the case, I have to
>>...
>
> Yes, you are wrong. This proposition implies collection of classloader and
> clasess loaded by it at once. You can see what
On 10/30/06, Robin Garner <[EMAIL PROTECTED]> wrote:
Weldon Washburn wrote:
> On 10/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> Weldon Washburn wrote:
>> > Steve Blackburn was in Portland Oregon today. I mentioned the idea
of
>> > adding a reference pointer from object to
Robin, thank you for this information. I want to ask a few questions
to check that I understand you correctly.
On 10/31/06, Robin Garner <[EMAIL PROTECTED]> wrote:
MMTk implements several algorithms for retaining the reachable objects
in a graph and recycling space used by unreachable ones. It
Weldon Washburn wrote:
On 10/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Weldon Washburn wrote:
> Steve Blackburn was in Portland Oregon today. I mentioned the idea of
> adding a reference pointer from object to its j.l.Class instance.
MMTk
> was
> not designed with this idea in
Hello, Etienne.
Am I wrong, or does this proposition imply collecting classes
independently from their class loader? If this is the case, I have to
say that I disagree with the proposed approach.
Yes, you are wrong. This proposition implies collection of classloader and
clasess loaded by it a
Hi Weldon,
Weldon Washburn wrote:
> I read section 3.2.3 (Class-Loader-Specific Memory) of gagnon-phd.pdf.
> Please tell me if the following is a correct interpretation. You create
> a new memory manager that is uniquely associated with each new class
> loader.
Right.
> All the C data structur
Etienne,
I read section 3.2.3 (Class-Loader-Specific Memory) of gagnon-phd.pdf.
Please tell me if the following is a correct interpretation. You create
a new memory manager that is uniquely associated with each new class
loader. All the C data structures associated with a class loader (classes,
The point is not that it is unimportant because it is an optimization. It is
1) it seems something that is be good to have, but is not urgent
immediately 2) that given the nature of our best solution ( java tables etc.
) is risky, we may not want to experiment with it in the main branch. We
should
>>> If I get it right, in case of automagic unloading, GC does all the job
>>> without a knowledge whether it collects a class, a classloader or
>>> whatever else.
>>> Perhaps I'm missing something, but to provide a callback on class
>>> unloading, the GC must know the semantic of the object being
Hmmm... Yes, some more details would be nice.
If I get it right, in case of automagic unloading, GC does all the job
without a knowledge whether it collects a class, a classloader or
whatever else.
Perhaps I'm missing something, but to provide a callback on class
unloading, the GC must know the s
Hi, everyone.
I'd like to summarize the discussion about unloading here. Almost everyone
agreed that class unloading is very important for Harmony project and this
work should be continued.
There were discussed 3 proposals of class unloading designs. There are 2
initially proposed designs wher
On the 0x210 day of Apache Harmony Rana Dasgupta wrote:
> I completely agree.
>
> +1 for branch if Aleksey wants to experiment
are there any problems with Java VTables in any of the components? JIT
has no problems, as we discussed. GC should not suffer too, I
guess. If we meet some problems that
Ivan,
Ivan Volosyuk:
On 10/29/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
Mikhail Fursov:
> On 10/28/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
>>
>> Aleksey,
>>
>> > 1. Mark and scan based approach.
>> > 2. Automatic class unloading approach.
>>
>> In the #2, is there any chance for o
uh... reference counting for class loader, interesting.
One thing could you help to clarify: how can the classloader know
there is class (loaded by it) that has surviving objects? We need
trace the object header to find the class then to find the classloader
and then to mark the classloader? Is t
Etienne,
I like your ideas. It looks like it should work. We need to carefully look
at all the corner cases to make sure we don't restrict the development of GC
algorithms. For example, make sure concurrent GC algorithms can work with
your proposed scheme.
On 10/29/06, Etienne Gagnon <[EMAIL
I don't know about drlvm, but SableVM does keep a reference (i.e. a
local native reference) in each method activation frame to either the
instance (in case of an instance method) or to the class object (in case
of a static method). This is required for correctly (and efficiently)
implementing the
I like your idea. We can skip counting on young generation.
Good, this approach doesn't force us to convert VTables to java objects.
There is one more thing to clarify. Having no objects in heap we can
have running method in stack which holds classloader from unloading.
How can we deal with that
OK, my brain seems to be just waking up... I was thinking of per-class
to reduce indirections at allocation time. There's no need for
per-class data, only "one boolean per GC generation" in every class
loader. The boolean is set when an instance (of a class loaded by this
class loader) is moved
Wait a minute! I missed something. Actually, there is no need to track
allocations in the young generation! Only survivals. So, you apply the
boolean trick only for objects that survive the nursery collection.
So, there would be no bit overhead in objects, nor work overhead on
allocations. Ju
Ivan Volosyuk wrote:
> If I understand you correctly, you suggest to increment
> per-classloader object counter on allocation... It can be much
> overhead with the solution, as most of the objects die young.
> Do I miss something?
No, I was thinking about a "per-class" counter. Actually, a counte
If I understand you correctly, you suggest to increment
per-classloader object counter on allocation... It can be much
overhead with the solution, as most of the objects die young.
Do I miss something?
--
Ivan
On 10/29/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote:
I have missed some messages of
I have missed some messages of this thread, yet I do not remember seeing
a discussion of what seems to me the obvious solution to the problem.
So, here it is.
Why don't you simply add a reference count on classes which is
incremented on object allocation and decremented on object reclamation?
[In
On 10/29/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
Mikhail Fursov:
> On 10/28/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
>>
>> Aleksey,
>>
>> > 1. Mark and scan based approach.
>> > 2. Automatic class unloading approach.
>>
>> In the #2, is there any chance for other components to be n
Mikhail Fursov:
On 10/28/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
Aleksey,
> 1. Mark and scan based approach.
> 2. Automatic class unloading approach.
In the #2, is there any chance for other components to be notified about
unloaded classes?
Alex,
I asked Aleksey about the same
On 28/10/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/29/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
> From JLS:-
>
> ...
>
> And ...
>
> ..
>
> Anyway, I don't want to belabor this point forever, and my opinion is only
> one among many :-)
>
> Good point! Thanks.
I have never thought (
On 10/29/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
From JLS:-
...
And ...
..
Anyway, I don't want to belabor this point forever, and my opinion is only
one among many :-)
Good point! Thanks.
I have never thought (as Java developer) about class unloading
like an optimization. But if it i
On 10/28/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/28/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
> On 10/27/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> >
> >
> > >Yes. That's also my opinion. The _design_ of class unloading is >the
> > >focus of the discussion.
>
>
>
> I think th
1 - 100 of 153 matches
Mail list logo
