You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@directmemory.apache.org by Chetan Mehrotra <ch...@gmail.com> on 2013/07/10 09:02:01 UTC
Sharing MemoryManagerService between multiple CacheService
We are trying to use DirectMemory in Jackrabbit Oak project [1]. We
have couple of caches which needs to be backed by DM. I am looking for
the most optimum way of configuring DM.
One approach I can think of is as follows.
1. Have a single MemoryManager which is configured with required
memory limit. I want to avoid specifying memory limits for underlying
L2 cache. Instead I want the L2 cache to be shared between all the L1
caches
2. Have multiple CacheService and where each service use the same MemoyManager
3. These CacheService can have independent lifecycle
If above is correct way to use DM then I see following issues with
current implementation of CacheServiceImpl in DM
1. CacheService.clear [2] also clears the underlying MemoryManager. It
should probably only remove the memory for the keys it owns
2. CacheService.close closes the underlying MemoryManager - if
MemoryManager is explicitly passed to it as part of constructor then
it should not it be left to the calling code to clean/close the
MemoryManager
is the above approach correct ... or I should use some other way?
Chetan Mehrotra
[1] https://issues.apache.org/jira/browse/OAK-891
[2] https://github.com/apache/directmemory/blob/trunk/directmemory-cache/src/main/java/org/apache/directmemory/cache/CacheServiceImpl.java#L282
Re: Sharing MemoryManagerService between multiple CacheService
Posted by Christoph Engelbert <no...@apache.org>.
Am 10.07.2013 10:32, schrieb Chetan Mehrotra:
> Hi Christoph,
>
>> From my point of view it's just a matter of the
>> CacheService to clean not the complete MemoryManager but just
>> removing all of it's keys so that way it would be possible to create
>> a shared MemoryManager for all caches.
> From my limited understanding of the code thats what I was thinking of the same
>
> 1. CacheService only frees Pointers that it owns
> 2. It does not close the MemoryManager on its own
Sounds like a reasonable idea at least for the new implementation
which preallocates a hugh block of memory and splits it up into
small (configurable) fragments of the same size. If you need more
space a chain of fragments is created. This way it could waste a
small bunch of bytes if you not fill a full fragment but this is up
to you to find a good match between waste and speed.
I'll remember the sharing of the MemoryManager and try to make a
working version of DM using the reimplementation on weekend.
Chris
> Chetan Mehrotra
Re: Sharing MemoryManagerService between multiple CacheService
Posted by Chetan Mehrotra <ch...@gmail.com>.
Hi Christoph,
> From my point of view it's just a matter of the
> CacheService to clean not the complete MemoryManager but just
> removing all of it's keys so that way it would be possible to create
> a shared MemoryManager for all caches.
>From my limited understanding of the code thats what I was thinking of the same
1. CacheService only frees Pointers that it owns
2. It does not close the MemoryManager on its own
Chetan Mehrotra
Re: Sharing MemoryManagerService between multiple CacheService
Posted by Christoph Engelbert <no...@apache.org>.
Hi Chetan
I started a new MemoryManager implementation some time ago (which
hopefully will be finished when there's time to get back to DM but
since it's pretty similar to the current one it does not yet support
incremental clearing (without just removing all data using the keys).
What do you think should an implementation for a shared cache should
look like? From my point of view it's just a matter of the
CacheService to clean not the complete MemoryManager but just
removing all of it's keys so that way it would be possible to create
a shared MemoryManager for all caches.
Chris
Am 10.07.2013 10:11, schrieb Chetan Mehrotra:
> Hi Raffaele,
>
>> If you have two caches you should end up using two cache
>> services - that are not supposed to share the same memory service
> I can go with that approach. However it might lead to wastage of
> memory space if one of the cache is not used much. The free memory
> there would remain locaked up for that cache/ Further it would require
> extra effort of properly sizing the memory for each type of cache.
> However if they can share the MemoryStore then it would enable sharing
> same memory across all the caches reducing possible wastage of memory.
>
> Hence I was looking into for a way to share the MemoryManager. Is
> there any other design constraint which limits the sharing of
> MemoryManager?
>
> Chetan Mehrotra
>
>
> On Wed, Jul 10, 2013 at 12:50 PM, Raffaele P. Guidi
> <ra...@gmail.com> wrote:
>> Well, each cache service has to be considered as an independent "bucket" - a
>> store on its own. If you have two caches you should end up using two cache
>> services - that are not supposed to share the same memory service.
>>
>> Ciao,
>> R
>>
>>
>> On Wed, Jul 10, 2013 at 9:02 AM, Chetan Mehrotra <ch...@gmail.com>
>> wrote:
>>> We are trying to use DirectMemory in Jackrabbit Oak project [1]. We
>>> have couple of caches which needs to be backed by DM. I am looking for
>>> the most optimum way of configuring DM.
>>>
>>> One approach I can think of is as follows.
>>>
>>> 1. Have a single MemoryManager which is configured with required
>>> memory limit. I want to avoid specifying memory limits for underlying
>>> L2 cache. Instead I want the L2 cache to be shared between all the L1
>>> caches
>>> 2. Have multiple CacheService and where each service use the same
>>> MemoyManager
>>> 3. These CacheService can have independent lifecycle
>>>
>>> If above is correct way to use DM then I see following issues with
>>> current implementation of CacheServiceImpl in DM
>>>
>>> 1. CacheService.clear [2] also clears the underlying MemoryManager. It
>>> should probably only remove the memory for the keys it owns
>>> 2. CacheService.close closes the underlying MemoryManager - if
>>> MemoryManager is explicitly passed to it as part of constructor then
>>> it should not it be left to the calling code to clean/close the
>>> MemoryManager
>>>
>>> is the above approach correct ... or I should use some other way?
>>>
>>> Chetan Mehrotra
>>> [1] https://issues.apache.org/jira/browse/OAK-891
>>> [2]
>>> https://github.com/apache/directmemory/blob/trunk/directmemory-cache/src/main/java/org/apache/directmemory/cache/CacheServiceImpl.java#L282
>>
Re: Sharing MemoryManagerService between multiple CacheService
Posted by Chetan Mehrotra <ch...@gmail.com>.
Hi Raffaele,
> If you have two caches you should end up using two cache
> services - that are not supposed to share the same memory service
I can go with that approach. However it might lead to wastage of
memory space if one of the cache is not used much. The free memory
there would remain locaked up for that cache/ Further it would require
extra effort of properly sizing the memory for each type of cache.
However if they can share the MemoryStore then it would enable sharing
same memory across all the caches reducing possible wastage of memory.
Hence I was looking into for a way to share the MemoryManager. Is
there any other design constraint which limits the sharing of
MemoryManager?
Chetan Mehrotra
On Wed, Jul 10, 2013 at 12:50 PM, Raffaele P. Guidi
<ra...@gmail.com> wrote:
> Well, each cache service has to be considered as an independent "bucket" - a
> store on its own. If you have two caches you should end up using two cache
> services - that are not supposed to share the same memory service.
>
> Ciao,
> R
>
>
> On Wed, Jul 10, 2013 at 9:02 AM, Chetan Mehrotra <ch...@gmail.com>
> wrote:
>>
>> We are trying to use DirectMemory in Jackrabbit Oak project [1]. We
>> have couple of caches which needs to be backed by DM. I am looking for
>> the most optimum way of configuring DM.
>>
>> One approach I can think of is as follows.
>>
>> 1. Have a single MemoryManager which is configured with required
>> memory limit. I want to avoid specifying memory limits for underlying
>> L2 cache. Instead I want the L2 cache to be shared between all the L1
>> caches
>> 2. Have multiple CacheService and where each service use the same
>> MemoyManager
>> 3. These CacheService can have independent lifecycle
>>
>> If above is correct way to use DM then I see following issues with
>> current implementation of CacheServiceImpl in DM
>>
>> 1. CacheService.clear [2] also clears the underlying MemoryManager. It
>> should probably only remove the memory for the keys it owns
>> 2. CacheService.close closes the underlying MemoryManager - if
>> MemoryManager is explicitly passed to it as part of constructor then
>> it should not it be left to the calling code to clean/close the
>> MemoryManager
>>
>> is the above approach correct ... or I should use some other way?
>>
>> Chetan Mehrotra
>> [1] https://issues.apache.org/jira/browse/OAK-891
>> [2]
>> https://github.com/apache/directmemory/blob/trunk/directmemory-cache/src/main/java/org/apache/directmemory/cache/CacheServiceImpl.java#L282
>
>
Re: Sharing MemoryManagerService between multiple CacheService
Posted by "Raffaele P. Guidi" <ra...@gmail.com>.
Well, each cache service has to be considered as an independent "bucket" -
a store on its own. If you have two caches you should end up using two
cache services - that are not supposed to share the same memory service.
Ciao,
R
On Wed, Jul 10, 2013 at 9:02 AM, Chetan Mehrotra
<ch...@gmail.com>wrote:
> We are trying to use DirectMemory in Jackrabbit Oak project [1]. We
> have couple of caches which needs to be backed by DM. I am looking for
> the most optimum way of configuring DM.
>
> One approach I can think of is as follows.
>
> 1. Have a single MemoryManager which is configured with required
> memory limit. I want to avoid specifying memory limits for underlying
> L2 cache. Instead I want the L2 cache to be shared between all the L1
> caches
> 2. Have multiple CacheService and where each service use the same
> MemoyManager
> 3. These CacheService can have independent lifecycle
>
> If above is correct way to use DM then I see following issues with
> current implementation of CacheServiceImpl in DM
>
> 1. CacheService.clear [2] also clears the underlying MemoryManager. It
> should probably only remove the memory for the keys it owns
> 2. CacheService.close closes the underlying MemoryManager - if
> MemoryManager is explicitly passed to it as part of constructor then
> it should not it be left to the calling code to clean/close the
> MemoryManager
>
> is the above approach correct ... or I should use some other way?
>
> Chetan Mehrotra
> [1] https://issues.apache.org/jira/browse/OAK-891
> [2]
> https://github.com/apache/directmemory/blob/trunk/directmemory-cache/src/main/java/org/apache/directmemory/cache/CacheServiceImpl.java#L282
>