Interesting Problems with GC
Joe Seigh
http://blogs.azulsystems.com/cliff/2007/08/why-weakhashmap.html
GC, far from making memory management completely transparent to
the programmer, can have interesting side effects. What's more,
the effects can vary widely depending on the form of GC being
used. So an algorithm that performs well w/ one form of GC can
suck rather badly w/ another.
The other interesting thing is the use of java.lang.ref.WeakReference
for caching which in most cases probably implies LRU caching. Suppose
you had a perfect GC that collected objects the instant they became
unused. Wouldn't be too good of a cache.
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software.
Dmitriy Vyukov
> An interesting blog entry herehttp://blogs.azulsystems.com/cliff/2007/08/why-weakhashmap.html
See also this blog entry:
http://www.coversant.net/Coversant/Blogs/tabid/88/EntryID/9/Default.aspx
There are described interesting problem with GC memory allocator and
memory pinning.
Dmitriy V'jukov
Chris Thomasson
news:g1oDi.6157$eD5.1575@trnddc07...
and another problem:
> GC, far from making memory management completely transparent to
> the programmer, can have interesting side effects. What's more,
> the effects can vary widely depending on the form of GC being
> used. So an algorithm that performs well w/ one form of GC can
> suck rather badly w/ another.
IMO, all of the GC algorithms that end up enforcing a so-called
"collect-the-world" policy basically suck.
> The other interesting thing is the use of java.lang.ref.WeakReference
> for caching which in most cases probably implies LRU caching. Suppose
> you had a perfect GC that collected objects the instant they became
> unused. Wouldn't be too good of a cache.
GC and caching don't get along _sometimes_... From the applications point of
view an object in the cache is in a quiescent state. However, from the GC
perspective a node in the cache is a pointer to a "live object".
Joe Seigh
> "Joe Seigh" <jsei...@xemaps.com> wrote in message
> news:g1oDi.6157$eD5.1575@trnddc07...
>> An interesting blog entry here
>> http://blogs.azulsystems.com/cliff/2007/08/why-weakhashmap.html
>
> and another problem:
>
> http://groups.google.com/group/microsoft.public.dotnet.languages.vc/browse_frm/thread/35c58e3e1d902aec
>
>
>> GC, far from making memory management completely transparent to
>> the programmer, can have interesting side effects. What's more,
>> the effects can vary widely depending on the form of GC being
>> used. So an algorithm that performs well w/ one form of GC can
>> suck rather badly w/ another.
>
> IMO, all of the GC algorithms that end up enforcing a so-called
> "collect-the-world" policy basically suck.
In this case it was a concurrent collector which had problems because
it didn't "stop the world".
>
>
>> The other interesting thing is the use of java.lang.ref.WeakReference
>> for caching which in most cases probably implies LRU caching. Suppose
>> you had a perfect GC that collected objects the instant they became
>> unused. Wouldn't be too good of a cache.
>
> GC and caching don't get along _sometimes_... From the applications
> point of view an object in the cache is in a quiescent state. However,
> from the GC perspective a node in the cache is a pointer to a "live
> object".
>
The use of WeakReference was the problem in this case. If you want to
do caching, you need to write an explicit program to do so. I'm surprised
it hasn't been been done yet. LRU algorithms have been around forever.
It wouldn't be that hard to do.