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. >----- Original Message ----- >From: "Henk de Koning" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Monday, April 29, 2002 11:28 PM >Subject: Re: [DOTNET] lock - how expensive is it to call? > > >> Yeah. Those sizes surprised me. I'm running on a 2 processor box, using V1, >> no service packs. Did the simple test, create a bunch of objects and print >> out the address where they're located. No boxing, so I should see the real >> sizes. >> >> Could have sworn last time I tested this, I got the same sort of results you >> did. The only difference I can see is that I'm running on a MP box now. But >> surely the number of processors shouldn't change the size of my objects ... >> Maybe the sync stuff takes more space. I'm running a strange configuration >> BTW because I have W2k Professional on a 2 processor box, meaning I don't >> get mscorsrv.dll but let mscorwks.dll handle the syncing. >> >> -- Henkk >> You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
