From 4f63a0b39ef27ac9a9158b9161edfd05f4a5dcd4 Mon Sep 17 00:00:00 2001 From: adam Date: Fri, 13 Feb 2004 06:18:07 +0000 Subject: [PATCH] added bug report note to Cache.java; investigate later darcs-hash:20040213061807-5007d-a99cfb527736dfcccf78f20ea944c2ea800cbd11.gz --- src/org/ibex/util/Cache.java | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/src/org/ibex/util/Cache.java b/src/org/ibex/util/Cache.java index 47f4faf..af88c88 100644 --- a/src/org/ibex/util/Cache.java +++ b/src/org/ibex/util/Cache.java @@ -5,6 +5,35 @@ // the portion of clause 6a after the semicolon (aka the "obnoxious // relink clause") +/* + +Bug report from a user: + +I looked at your Cache.java and tried to make good use of it, but I was +out of luck - it wouldn't run here. Digging deeper into the code, I came +across something that might be considered a bug. But maybe it's just a +feature :-) + + +Starting with an empty cache, Cache.put() immediately followed by +Cache.get() on same keys / same object will set Node lru back to null in +Node.remove() which is called in get(). + +Assuming this put()-get() sequence is fixed, it will fill the cache, but +lru will remain null. + +When cache is filled 100%, we have, at the end of the get(), where +size>maxSize is checked, a state that mru == lru == n (from +if(lru==null) thus deleteting the newly inserted object. Oops. + + +Hope I made this clear enough. Maybe it's not a problem in xwt due to a +different usage scheme of the cache. + + + +*/ + package org.ibex.util; // FIXME needs to be a weak hash -- 1.7.10.4