[Interest] memory fragmentation?

Thiago Macieira thiago.macieira at intel.com
Thu Aug 23 12:33:23 CEST 2012

On quinta-feira, 23 de agosto de 2012 11.18.09, André Somers wrote:
> Op 23-8-2012 3:54, Tony Rietwyk schreef:
> > Hi Jason,
> > 
> > If there are 5 public objects whose d-pointers reference the same
> > private object address, how are you going to update them when you
> > relocate the private object?
> > 
> > I don't think .Net stores addresses, just handles, so the relocate
> > only needs to update the handle info.   That's why you have to go
> > through all of the marshalling crap when you do want to pass the
> > address somewhere!
> Couldn't that be solved by making d-pointers not MyClassPrivate* but
> MyClassPrivate**? Then, you'd only need to update one address...

All problems in computing can be solved with another level of indirection.

Well, all problems but one: that of too many indirections. And in this case, 
you're adding too many indirections. There are two problems with this 

1) you still need a fixed, non-relocating memory region where to store the 
pointers to the actual objects

2) this requires hitting two cache lines and doing twice the amount of memory 
accesses to get to the data.

> I do think the idea is really crazy, but that does not mean that it
> isn't interesting anyway. I guess you'd need your own allocator for the
> objects as well. How else are you going to keep track of the actual
> fragmentation? To complicate it even more: the program could even
> 'learn' between runs by keeping some stats between runs on memory usage,
> to influence its own memory allocation strategies... And yes, I
> understand that such things would be *very* complicated to do well, and
> might not even work properly.

And again: all of this is not thread-safe.

You can only move the objects if you guarantee that all threads are blocked 
from accessing it. Something like keeping a QReadWriteLock per relocatable 
pointer, if you don't want a Big Application Lock.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120823/db5ead97/attachment.sig>

More information about the Interest mailing list