using proxy garbage collector in C# / Java...
Chris M. Thomasson
beneficial usage cases for a proxy garbage collector algorithm in garbage
collected languages such as C# and Java. For instance, imagine trying to
implement a lock-free stack algorithm in C#. Okay, it's pretty easy because
the "native" GC solves the memory reclamation issue and ABA problem.
However, why put unneeded pressure on the native GC? Who knows how long the
GC is going take to actually let the program reuse nodes as it's a
completely non-deterministic process. Unfortunally, this behavior can end up
creating a sh%tload of nodes under periods of load and completely swamp the
GC which simply cannot be a good thing in any way, shape or form. I am
thinking that sending the nodes through a proxy garbage collector possibly
could significantly help things out. One reason is that the overall
algorithm I have in mind:
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/a53f24de178b419f
is deterministic in the sense that objects can be reclaimed as soon as the
last thread releases a reference to it's previously acquired proxy collector
object. This means that nodes can most likely be reused much sooner than if
you let the "native" GC handle everything. That has to be a good thing
because it can help reduce the total number of nodes created thus taking
pressure off of the native GC.
Is this making sense to everybody? I would really enjoy hearing your
thoughts on the issue!
Thanks!
:^)
Dmitriy Vyukov
> I know this sounds a bit odd, but I think there could be some fairly
> beneficial usage cases for a proxy garbage collector algorithm in garbage
> collected languages such as C# and Java. For instance, imagine trying to
> implement a lock-free stack algorithm in C#. Okay, it's pretty easy because
> the "native" GC solves the memory reclamation issue and ABA problem.
> However, why put unneeded pressure on the native GC? Who knows how long the
> GC is going take to actually let the program reuse nodes as it's a
> completely non-deterministic process. Unfortunally, this behavior can end up
> creating a sh%tload of nodes under periods of load and completely swamp the
> GC which simply cannot be a good thing in any way, shape or form. I am
> thinking that sending the nodes through a proxy garbage collector possibly
> could significantly help things out. One reason is that the overall
> algorithm I have in mind:
>
>
> is deterministic in the sense that objects can be reclaimed as soon as the
> last thread releases a reference to it's previously acquired proxy collector
> object. This means that nodes can most likely be reused much sooner than if
> you let the "native" GC handle everything. That has to be a good thing
> because it can help reduce the total number of nodes created thus taking
> pressure off of the native GC.
>
> Is this making sense to everybody? I would really enjoy hearing your
> thoughts on the issue!
As far as I remember, Joe Seigh mentioned here some time ago that he
developing web back-end server in Java and that he uses own PDR.
However, I suspect that he did it partially just because he can :)
I think that in some situations proxy-collector can be beneficial in
Java. For example, assume that prompt PC cuts working set of a program
so that now it fits into cache.
Other PDR techniques can be of help too. Consider very light-weight
batching PDR, with which one can reclaim N objects by just aggregating
per-thread epoch counters (N can be set to any value).
Why it's not wide-spread practice?... well, probably just because some
people work with Java but unable to develop own PDR, and other people
able to develop own PDR but do not want to work with Java... just a
joke :)
Seriously, I think that it's an interesting research topic. Try to
apply various PDR techniques to various Java/C# programs and to see
for performance/memory consumption.
--
Dmitriy V'jukov