You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Mike Williams <md...@users.sourceforge.net> on 2001/09/10 12:06:07 UTC
suggestion: use WeakHashMap to implement the introspection cache
>>> On Mon, 10 Sep 2001 05:11:18 +0200,
>>> "Paulo" == "Paulo Gaspar" <pa...@krankikom.de> wrote:
Paulo> Still, the Introspector cache must cause a huge memory leak when you
Paulo> place the Velocity jar in lib/apps and reload applications: Any classes
Paulo> that are introspected (and cached) will not be GCed even after their
Paulo> WebApp is stopped. And to make it worse, that means that their Class
Paulo> Loader will also not be GCed together with any static objects that loaded
Paulo> by that same CL.
You guys thought about using java.util.WeakHashMap to implement the
introspection caches?
A hashtable-based Map implementation with weak keys. An entry in a
WeakHashMap will automatically be removed when its key is no longer in
ordinary use. More precisely, the presence of a mapping for a given key
will not prevent the key from being discarded by the garbage collector,
that is, made finalizable, finalized, and then reclaimed. When a key
has been discarded its entry is effectively removed from the map ...
--
cheers, Mike
"Life is like an analogy."
Re: suggestion: use WeakHashMap to implement the introspection cache
Posted by Attila Szegedi <sz...@freemail.hu>.
I'll take a look at that, it seems intriguing. Thanks for the link.
Meanwhile, we have dropped the idea of using weak references in favor of a
heuristic that detects class reloads when it sees two different class
objects with the same qualified name.
Attila.
----- Original Message -----
From: "Lane Sharman" <la...@san.rr.com>
To: <ve...@jakarta.apache.org>
Sent: 2001. szeptember 11. 1:14
Subject: Re: suggestion: use WeakHashMap to implement the introspection
cache
> Attila Szegedi wrote:
>
> > EAlso, when you do a lookup in WeakHashMap (containsKey, get, remove) it
will
> >
> > create a new, temporary WeakReference for purposes of comparing it to
other
> > keys (which are also WeakReferences). This can take time. Also, each
method
> > calls a reference queue processor loop that removes entries with cleared
> > references from the map, also adding to the overhead.
>
> Be sure to benchmark a caching provider that holds elements for shared
access.
> My tests found Weak/Soft references to add an unacceptable cost to overall
> throughput. The thread which does the remove has to be synchronized with
the
> thread doing the get().
>
> I implemented a generational caching provider. There is no contention or
> synchronization because mutations are done to a provisional generation
which
> becomes the working generation on a periodic basis AND when there is
longish
> period of cache idelness. http://engineering.acctiva.org/vfc for details
on a
> generational cache manager.
>
> -lane
>
>
Re: suggestion: use WeakHashMap to implement the introspection cache
Posted by Lane Sharman <la...@san.rr.com>.
Attila Szegedi wrote:
> EAlso, when you do a lookup in WeakHashMap (containsKey, get, remove) it will
>
> create a new, temporary WeakReference for purposes of comparing it to other
> keys (which are also WeakReferences). This can take time. Also, each method
> calls a reference queue processor loop that removes entries with cleared
> references from the map, also adding to the overhead.
Be sure to benchmark a caching provider that holds elements for shared access.
My tests found Weak/Soft references to add an unacceptable cost to overall
throughput. The thread which does the remove has to be synchronized with the
thread doing the get().
I implemented a generational caching provider. There is no contention or
synchronization because mutations are done to a provisional generation which
becomes the working generation on a periodic basis AND when there is longish
period of cache idelness. http://engineering.acctiva.org/vfc for details on a
generational cache manager.
-lane
Re: suggestion: use WeakHashMap to implement the introspection cache
Posted by Attila Szegedi <sz...@freemail.hu>.
Each time you store something in a WeakHashMap, you'll create another
WeakReference. It's an object, and it takes up space. If I remembered
correctly, each reference object has 3 fields (one for referred object, for
reference queue, and for next reference in the queue) so it takes at least
12 bytes of storage + storage required for java.lang.Object.
Also, when you do a lookup in WeakHashMap (containsKey, get, remove) it will
create a new, temporary WeakReference for purposes of comparing it to other
keys (which are also WeakReferences). This can take time. Also, each method
calls a reference queue processor loop that removes entries with cleared
references from the map, also adding to the overhead.
Attila.
----- Original Message -----
From: "Mike Williams" <md...@users.sourceforge.net>
To: <ve...@jakarta.apache.org>
Sent: Tuesday, September 11, 2001 12:25 AM
Subject: Re: suggestion: use WeakHashMap to implement the introspection
cache
> Mike> You guys thought about using java.util.WeakHashMap to implement
the
> Mike> introspection caches?
>
> Geir> Read back. That was Attila's first suggestion,
>
> Whoops ... sorry.
>
> Geir> but if you read along, a scheme was cooked up that avoids it.
>
> Okay, so now you're discarding the cache whenever there's a class re-load,
> right?
>
> Attila> It is somewhat worse than using weak references [...] however it
> Attila> has the advantage of having no negative memory or performance
> Attila> impact on behalf of Introspector.
>
> Just out of interest, what's the negative memory/performance impact of the
> WeakHashMap approach?
>
> --
> cheers, Mike
>
>
Re: suggestion: use WeakHashMap to implement the introspection cache
Posted by Mike Williams <md...@users.sourceforge.net>.
Mike> You guys thought about using java.util.WeakHashMap to implement the
Mike> introspection caches?
Geir> Read back. That was Attila's first suggestion,
Whoops ... sorry.
Geir> but if you read along, a scheme was cooked up that avoids it.
Okay, so now you're discarding the cache whenever there's a class re-load,
right?
Attila> It is somewhat worse than using weak references [...] however it
Attila> has the advantage of having no negative memory or performance
Attila> impact on behalf of Introspector.
Just out of interest, what's the negative memory/performance impact of the
WeakHashMap approach?
--
cheers, Mike
Re: suggestion: use WeakHashMap to implement the introspection
cache
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 9/10/01 12:06 AM, "Mike Williams" <md...@users.sourceforge.net> wrote:
>>>> On Mon, 10 Sep 2001 05:11:18 +0200,
>>>> "Paulo" == "Paulo Gaspar" <pa...@krankikom.de> wrote:
>
> Paulo> Still, the Introspector cache must cause a huge memory leak when you
> Paulo> place the Velocity jar in lib/apps and reload applications: Any classes
> Paulo> that are introspected (and cached) will not be GCed even after their
> Paulo> WebApp is stopped. And to make it worse, that means that their Class
> Paulo> Loader will also not be GCed together with any static objects that
> loaded
> Paulo> by that same CL.
>
> You guys thought about using java.util.WeakHashMap to implement the
> introspection caches?
>
> A hashtable-based Map implementation with weak keys. An entry in a
> WeakHashMap will automatically be removed when its key is no longer in
> ordinary use. More precisely, the presence of a mapping for a given key
> will not prevent the key from being discarded by the garbage collector,
> that is, made finalizable, finalized, and then reclaimed. When a key
> has been discarded its entry is effectively removed from the map ...
:)
Read back. That was Attila's first suggestion, but if you read along, a
scheme was cooked up that avoids it.
Will be checked in in a moment...
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
If you look up, there are no limits - Japanese Proverb