Re: [jbosscache-dev] JCIP annotations
by Manik Surtani
On 8 Feb 2007, at 20:49, Bela Ban wrote:
> I already have GuardedBy and Immutable in JGroups. However, we
> should think about a common shared library of annotations that
> might express even a bit more complex predicates (e.g. using
> temporal logic).
Are these from JCIP.net? Or have you written your own GuardedBy and
Immutable in org.jgroups.xxx?
>
> We should come up with a lits of useful annotations...
+1. What else do you have in mind, in addition to the JCIP ones
(Immutable, GuardedBy, ThreadSafe and NotThreadSafe)?
>
> Manik Surtani wrote:
>> What do folks think about including jcip-annotations.jar from
>> jcip.net into JBC 2.0.0? Allows us to use annotations like
>> GuardedBy, Immutable, etc. and although they don't DO much except
>> be informative at the moment, it is possible that compile-time
>> checks or tests could be implemented later to make sure such
>> contracts are adhered to.
>>
>> http://jcip.net/
>> http://jcip.net/annotations/doc/index.html
>>
>> Cheers,
>> --
>> Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>>
>> Email: manik(a)jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik(a)surtani.org
>> Yahoo/AIM/Skype: maniksurtani
>>
>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
>
> --
> Bela Ban
> Lead JGroups / JBoss Clustering team
> JBoss - a division of Red Hat
>
18 years, 10 months
eviction policies
by Mircea Markus
Hi guys,
I've walked around eviction policies and here are some thoughts
1) There is an eviction policy algorithm more efficient than LRU (which I
found quite popular) - Adaptive Replacement Policy. The basic idea is to not
rely only on the time of last access to the node, but also on the number of
time(frequency) a given node was accessed. Here it is a nice description of
how it works: http://en.wikipedia.org/wiki/Adaptive_Replacement_Cache.
2) One other type of eviction which I found handy is a time based eviction,
i.e. the node will be removed from the cache after a certain time(countdown
starts when it is added). A common use case for this is when one needs an
info from database, which might be changed, but is not critical to have it
visible in real time.
3) Memory based eviction policy. Very useful in the case in which cache is
used for storing very heterogeneous objects - from the size point of view.
If the objects are large one is assured that the cache won't exhaust system
memory and in the case of small objects the cache manages to store much more
than it does if it would use a static defined policy, like LRU. The most
appropriate way (I found) for measuring object size is shipped within JDK5,
through Instrumentation.getObjectSize. The MAJOR drawback is performance:
method returns only the size of the base object; for all aggregated objects
one will have to iterate recursively over the object graph and calculate
size - costly both as performance and as memory. I don't have the complete
picture on the JBC usage scenarios (e.g. this might be useful in a scenario
in which addition is rare and memory size is critical) so perhaps you guys
can point out whether or not this is feasible. Perhaps in the case of
PojoCache in which object are introspected anyway?
Any thoughts?
Cheers,
Mircea
18 years, 10 months
