They are lazily loaded.
cheers,
Saravanan
On 12/6/10 10:34 PM, Sergio Bossa wrote:
> 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
