Thanks much for your response, it's crystal clear now.
Just one question: when the map is faulted in from disk back to memory, are all
its mappings faulted in too, or are they lazily loaded when used?
Sergio Bossa
Sent by iPhone
Il giorno 07/dic/2010, alle ore 02:56, Saravanan Subbiah
<ssubb...@terracottatech.com> ha scritto:
> Object Manager holds state objects for each shared object. The State Object
> hold the state information of the object. ObjectIDs are mere identifiers
> given to each objects. The state objects are evicted from the memory
> according to the heap usage and access pattern.
>
> So in your case the map state object only holds the information about the
> mappings not the actual object itself. The map state obejct will contain
> something like map{ K1 -> ObjectID1, K2 -> ObjectID2 } where K1 and K2 itself
> can be objectIds. The Keys and values can be individually flushed to disk but
> the mapping still stays in memory as long as the map object is not flushed to
> disk.
>
> Most likely you are using the map object more often so its pinned in the
> memory until it is under a lot of pressure to evict and then it ends up
> evicting the map. Depending on the size of the map, it might release a lot of
> memory hence you might see that its evicting a small amount of object, but
> the heap goes down a lot. It is true that the objects are not of equal weight
> in terms of memory requirement, but usage pattern is the one that drives the
> decision around which is needed to be in memory and which can be flushed to
> disk.
>
> you are probably seeing all those ObjectIDs as a part of the map state object
> holding the mapping in memory until it gets flushed out at some point later.
>
> Hope that gives you an idea about the workings of ObjectManager.
>
> cheers,
> Saravanan
>
> On 12/06/2010 05:34 AM, Sergio Bossa wrote:
>> Hi guys,
>>
>> did anyone have the chance to take a look at the problem I described?
>>
>> I've made some more tests in the meantime and it seems that the GC
>> doesn't free memory even if the ObjectManagerImpl has just very few
>> cached objects because of indirect references.
>> Let me explain this.
>> Let's say the ObjectManagerImpl holds 4 objects: 1 map and 3 contained
>> objects (not counting keys), so references size is 4. The CacheManager
>> performs then the eviction of the 3 objects: the ObjectManagerImpl now
>> holds just the map object, which still holds the 3 evicted objects, so
>> even if the references size is 1, there are still 4 objects alive that
>> the GC can't collect *until* the map is itself evicted.
>> Is that correct?
>>
>> Obviously, feel free to ask any questions if my explanation isn't clear
>> enough.
>>
>> On Mon, Nov 29, 2010 at 9:06 PM, Sergio Bossa<sergio.bo...@gmail.com> wrote:
>>> Some more updates ...
>>>
>>> After several GC cycles, the heap suddenly decreased with no apparent
>>> reason, freeing all those ObjectID instances.
>>> So I took a deeper look at the server logs and the heap dumps: I
>>> noticed that the heap decreased after a cache eviction of just a few
>>> hundreds objects (which is strange given it previously evicted
>>> thousand objects with no result), so I took a look at the dumps and
>>> noticed that objects doesn't have all the same "weight".
>>> I mean, there are a few objects which seem to hold many other objects
>>> (ManagedObjectImpl), but the indirect references aren't held by the
>>> references map in the object manager, so they doesn't seem to count
>>> against the eviction. In other words, the "references_size()" method
>>> in ObjectManagerImpl doesn't seem to take into account indirect
>>> references, so the references size is apparently low, but the actual
>>> weight is pretty heavy.
>>>
>>> I don't know if it makes any sense ... feel free to ask if you have
>>> any questions ... just take into account I'll be away in the next few
>>> days so I may answer with some delay.
>>>
>>> Cheers!
>>>
>>> Sergio B.
>>>
>>> On Mon, Nov 29, 2010 at 5:34 PM, Sergio Bossa<sergio.bo...@gmail.com>
>>> wrote:
>>>> Hi guys,
>>>>
>>>> while testing my Terracotta-based application I noticed that the
>>>> master almost saturates its memory (2 GB) with about 5 million map
>>>> entries, running as a consequence into more and more GC cycles.
>>>> By analyzing the heap dump I noticed there's a huge number of
>>>> com.tc.object.ObjectID instances, which is almost equal to the total
>>>> number of map entries: those objects seems to be retained by the
>>>> ObjectManagerImpl, and by looking at the source code it seems it
>>>> actually holds a map of reference objects.
>>>>
>>>> So, how does ObjectManagerImpl actually work? Doesn't it flush objects on
>>>> disk?
>>>>
>>>> --
>>>> Sergio Bossa
>>>> http://www.linkedin.com/in/sergiob
>>>>
>>>
>>>
>>>
>>> --
>>> Sergio Bossa
>>> http://www.linkedin.com/in/sergiob
>>>
>>
>>
>>
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
