avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eung-ju Park" <co...@apache.org>
Subject Re: excalibur.cache.LRUCachePolicy
Date Wed, 09 Jan 2002 00:25:24 GMT

----- Original Message -----
From: "MCCAY,LARRY (HP-NewJersey,ex2)" <lawrence_mccay-iii@hp.com>
To: "'Avalon Developers List'" <avalon-dev@jakarta.apache.org>
Sent: Wednesday, January 09, 2002 7:43 AM
Subject: RE: excalibur.cache.LRUCachePolicy


> Eung-ju,
>
> > 1. ( null == map.get( key ) ) != ( map.containsKey( key ) )
> >
> > do not use null == map.get( key ) for cache item existence check.
> > DefaultCache.containsKey is misimplemented.
> I'm not sure what this is in reference to...

   public Object get( Object resourceName )
   {
      Object result = m_newCache.get(resourceName); // try new space
      if (result != null)
        return result;
      result = m_oldCache.get(resourceName); // try old space
      if (result != null)
      {
        if( size() > m_capacity ) // cache full?
        {
           copySpaces();
        }
        m_oldCache.remove( resourceName ); // remove from old space
        m_newCache.put( resourceName, result ); // move to new space
      }
      return result;
   }

there is two item existence check.

      Object result = m_newCache.get(resourceName); // try new space
      if (result != null)

and

      result = m_oldCache.get(resourceName); // try old space
      if (result != null)

above is just null result check or item existence check? below is right
code?

    if ( m_newCache.containsKey( resourceName ) )
    {
        return m_newCache.get( resourceName );
    }

    if ( m_oldCache.containsKey( resourceName ) )
    {
        if ( isFull() )
        {
            copySpaces();
        }
        ....
        ...
    }

>
> > 2. Why use ( size() > m_capacity )?
> > It is commented "cache full?"
> > isFull() is defined in AbstractCache like below
> Fixed - this was legacy code left over from a previous effort.
>
> > 3. How about FlipSpacesStore for its name?
> Done.
>
> Also, my reference to a 2 Data Spaces pattern refers to an algorthm
> typically used in garbage collection that is also known as Two Space Copy
> and Stop and Copy Garbage Collection - the following link is an
interesting
> read:
> http://www.cs.brown.edu/courses/cs173/2000/Lectures/2000-11-20.pdf

Thanks you.

>
> enjoy.
>
> Larry
>
> > -----Original Message-----
> > From: Eung-ju Park [mailto:colus@apache.org]
> > Sent: Tuesday, January 08, 2002 7:25 AM
> > To: Avalon Developers List
> > Subject: Re: excalibur.cache.LRUCachePolicy
> >
> >
> > I see the source.
> >
> > 1. ( null == map.get( key ) ) != ( map.containsKey( key ) )
> >
> > do not use null == map.get( key ) for cache item existence check.
> > DefaultCache.containsKey is misimplemented.
> >
> > I will write more documentation. sorry.
> >
> > 2. Why use ( size() > m_capacity )?
> > It is commented "cache full?"
> > isFull() is defined in AbstractCache like below
> >
> > public boolean isFull()
> > {
> >     return size() >= capacity();
> > }
> >
> > remove "cache full" comment if " (size() > m_capacity) "
> >
> > 3. How about FlipSpacesStore for its name?
> >
> >
> >
> > ----- Original Message -----
> > From: "MCCAY,LARRY (HP-NewJersey,ex2)" <lawrence_mccay-iii@hp.com>
> > To: "'Avalon Developers List'" <avalon-dev@jakarta.apache.org>
> > Sent: Tuesday, January 08, 2002 2:35 AM
> > Subject: RE: excalibur.cache.LRUCachePolicy
> >
> >
> > > Eung-Ju,
> > >
> > > Attached is an implementation of a CacheStore that you may find
> > interesting.
> > >
> > >
> > > It does not, however, require a CachePolicy.
> > >
> > > It is based on the 2 Data Spaces pattern for LRU caching.
> > >
> > > I modified the LRUCacheTestCase just to test it before
> > sending it - I'll
> > let
> > > you determine if you actually roll it in.
> > >
> > > enjoy.
> > >
> > > Larry
> > >
> > > > -----Original Message-----
> > > > From: Eung-ju Park [mailto:colus@apache.org]
> > > > Sent: Monday, January 07, 2002 2:03 AM
> > > > To: Avalon Developers List
> > > > Subject: Re: excalibur.cache.LRUCachePolicy
> > > >
> > > >
> > > > Hi.
> > > >
> > > > ----- Original Message -----
> > > > From: "Alexis Agahi" <al@agahi.com>
> > > > To: "'Avalon Developers List'" <avalon-dev@jakarta.apache.org>
> > > > Sent: Monday, January 07, 2002 8:17 AM
> > > > Subject: excalibur.cache.LRUCachePolicy
> > > >
> > > >
> > > > > Hi,
> > > > >
> > > > > I've checked the cache implementation from excalibur scratchpad
> > > > > and notice that LRUCachePolicy use the ListCachePolicy
> > LinkedList
> > > > > to perform the LRU mecanism.
> > > > >
> > > > > To have a LRU 'hit' effect, it removes the object from the list
> > > > > and put it at the top.
> > > > > What if the list is really huge? I mean, to perform the
> > remove it
> > > >
> > > > It is not a Cache if it is really huge. ;-) Just kidding.
> > > >
> > > > > has to scan the whole list, since it doesn't have an index (or
> > > > > I'm wrong)?
> > > > >
> > > > > I would suggest having another approach using a logical clock
> > > > > value and 'time' hashmap.
> > > > >
> > > > > Something like:
> > > > > When a 'hit' is called, it gets the current object and set its
> > > > > 'value' to the current logical time.
> > > > > To remove the oldest, it gets the oldest value in the time map.
> > > > >
> > > > > To be really honest, this approach is not necessarily the best:
> > > > > the remove case is slower that the linked list one, but
> > the 'hit'
> > > > > could be faster. Now it depends on the hit/remove ratio. But I
> > > > > guess in an LRU cache, you should have a maximum of 'hit' call.
> > > >
> > > > Yes. If you want that kind of ReplacementPolicy. Just
> > > > implement it. and use
> > > > like bellow.
> > > >
> > > > final Cache cache = new DefaultCache( new TimeMapLRUCachePolicy(),
> > > > MemoryCacheStore( 1000000000 ) );
> > > >
> > > > and test it.
> > > > and send to this list.
> > > >
> > > > Thanks.
> > > >
> > > > >
> > > > >
> > > > > Regards
> > > > >
> > > > > --
> > > > > mailto:alag@users.sourceforge.net -
> > > > > http://sourceforge.net/projects/jabaserver
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <mailto:avalon-dev-help@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:avalon-dev-help@jakarta.apache.org>
> > >
> > >
> >
> >
> > --------------------------------------------------------------
> > --------------
> > ----
> >
> >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:avalon-dev-help@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:avalon-dev-help@jakarta.apache.org>
>
>


----------------------------------------------------------------------------
----


> --
> To unsubscribe, e-mail:
<mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:avalon-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message