Just a correction to previous letter. The following had just an opposite meaning to what I was meant to say: > It is also obvious that whenever GC allocates an object it has > to put a reference/handle to this object in one or another > internal list..
Should be: It is also obvious that for each allocated object, sooner or later GC should put a reference/handler to this object in one or another internal list... -Valery. -----Original Message----- From: Valery Pryamikov Sent: Tuesday, April 30, 2002 12:27 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] lock - how expensive is it to call? Btw: about memory consumption. AFAIK current implementation adds 8 bytes for each object - RTTI/vptr (or whatever you want to call it) and SyncBlockIndex. It's guaranteed that RTTI/vptr will be always naturally aligned, to avoid split access. It is also obvious that whenever GC allocates an object it has to put a reference/handle to this object in one or another internal list, means it would add at least one another natural processor integer to the totally consumed memory.. Whenever you use lock on the object, the system allocates another internal structure (SyncBlock) which is put in some internal list, and SyncBlockIndex of the object is set to point to the real SyncBlock. I don't really know what amount of memory is used by the SyncBlock, but it will definitely be no less than two natural processor integers. It's quite possible that SycnBlock is implemented internally by using CriticalSection... Object visible data is guaranteed to be aligned to the natural boundaries (up to native integer boundary) by CTS (see. 11.6.2 of PartitionIMetadata) unless different explicit layout was specified for such field. The same 11.6.2 of PartionI highly recommend natural alignment whenever possible, that means that visible object data that has one and only float64 field (without explicit layout) will be aligned to 64 bit boundary even on 32 bit processors. Depending on the alignment of VES object structure (VPTR+SyncBlock) it could be that adding 4 bytes to such an object would not change memory consumption at all. If size of visible object's data mod. sizeof natural processor integer isn't 0 then it will no matter if object adds another sizeof(integer)-(sizeof(visibleObjectData)%sizeof(integer)); bytes of memory, memory consumption still be the same. And at last - memory is really cheap nowadays, who really care about counting bits?;-). -Valery. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
