I doubt that implementing moveable private objects/pointers would be [really] useful.
Firstly, Qt can't control the location of the memory block allocated by new/malloc, so the assumption that some [random] reallocations will improve the contiguity of allocated memory looks quite naive. Secondly, d-ptr allocation is (in most cases) the first operation performed by an object constructor, so there's some (not too little, I think) chance the private object will be placed directly after its "public" buddy. In this case, destruction of both objects won't create any excess "holes" in allocated/free memory. And, at last but not at least, moving private objects around would unnecessarily complicate Qt's internals (reallocation itself, code for deciding when and where the d-ptr should be moved, etc.) and, probably, make it less predictable in terms of performance (reallocating d-ptr without reallocating "sub-pointers" makes little sense IMHO, and moving all that stuff around can be expensive). Yes, the idea is interesting, but crazy. :) On Wed, Aug 22, 2012 at 9:27 PM, Jason H <scorp...@yahoo.com> wrote: > C++ on .NET functions as it does now, however the compiler introduces the > operator of ^ as a type modifier like * (pointer) > ^ are handles to managed objects, as * are addresses of objects. The runtime > then handles dereferencing the handles for you. jsut like your compiler uses > the appropriate instructions with a pointer. > > Now, here's my crazy idea. If we have small objects - say Qt's interface > classes, and large objects, say Qt's private classes, then could we do some > d-ptr trickery where Qt can reallocate and copy/move the memory around and > reassign a d-ptr? We can't get all the coolness of .NET's GC, but we can > come close, at least for "large" objects (objects using d-ptrs). We've > already talked about the GUI, but what is more interesting to me is a > QObject hierarchy (not necessarily QWidgets) in that you could say for this > large, old tree of objects, do something that would result in "better" (more > contiguous) memory allocations. > > > > > ________________________________ > From: Konrad Rosenbaum <kon...@silmor.de> > To: interest@qt-project.org > Sent: Wednesday, August 22, 2012 4:50 AM > > Subject: Re: [Interest] memory fragmentation? > > Hi, > > On Tuesday 21 August 2012 12:01:49 Bo Thorsen wrote: >> Memory fragmentation is defined as the problem where you allocate a >> bigger chunk of memory than what is available, even if the total amount >> of free memory is available. >> >> Do you know if the ^ implementation in .NET actually does the realloc >> stuff, or do they only say that it's a possibility? I ask because this >> sounds hard to do well. You either have a really slow operation running >> often (just moving stuff back) or an almost impossible task (move things >> *you will keep for a long time* to the front of temporary objects. > > I'm not entirely certain how "C++" is implemented on .NET - it is an alien > in > that world, since it normally expects allocation that does not move around. > My > guess would be that it marks objects assigned to Type* style pointers as > "unmovable". > > See http://msdn.microsoft.com/en-us/library/ee787088.aspx for a detailed > (and > for MS untypically readable) description of the .NET Garbage Collector. > > The short version: > > .NET uses a generational and segmented garbage collector: small objects are > created in an "ephemeral" memory area (large objects are presumed to be > long- > lived from the start) and are marked "generation 0". When the GC discoveres > that it promoted most of the objects to "generation 1" (not temporary > anymore) > or "generation 2" (long lived object) it marks the whole segment as > "generation 2", which just makes the GC sweeps happen less often. A new > segment is chosen as "ephemeral" then. > > When the GC actually runs on a segment it does so in several phases. The 1st > phase "mark" is: the GC checks which objects are there to stay and which > ones > can be removed (i.e. they do not have any connection to a running thread). > Phase 2 is "sweep": it actually removes those objects. After that comes > phase > 3 "compact": it reallocates objects to the start of their segment to > eliminate > fragmented space. If necessary it can even reallocate objects to other > segments. > > In other words: .NET manages memory in large chunks and automatically > compacts > those chunks when it feels this is necessary. So object references are > pointers into a lookup table that contains the real memory location, which > can > change during GC runs. > >> The one case where you might have a problem is if you do have >> allocs/deallocs done often (for example list views that change content >> often) and you sometimes alloc a big chunk of the memory in one go. > > As far as I've seen in this discussion this falls into two categories: > > 1) Software on small and/or real-time systems that has critical parts and Qt > as display. [I.e. physical memory is the limit.] > > 2) Software that crunches lots of data and is combined with a GUI - > scientific > applications, data analysis, etc. [I.e. pointer size is the main limit, > memory > can be extended for money] > >> Things you can do to combat this is mostly to make your objects smaller. >> For example, use linked lists instead of arrays. The lists will add 4 >> bytes to each object, but the the object sizes are much smaller. >> >> If you want to go even further, you should add code to do memory >> intensive stuff on the disc - much much slower, but at least it will run. > > Both solve the problem for category 2 software (data/number crunching with a > GUI). I would in all earnesty add: go 64bit! Your target audience can easily > use the added flexibility of 64bit pointers (some of them could use more if > they could get it). > > For category 1 (real time, small memory FP) I can only suggest: separate the > processes. Have one that does the critical stuff in a deterministic manner > with pre-allocated memory and another process for the display - if there is > a > memory problem in the display process it does not hurt much to just kill it, > restart and resync with the main process. Yes, that is quite a bit of extra > effort, but if you have serious worries about this it may be a lot easier > than > making something as complex as Qt predictable. (The one time I did program > such a tool I even had the critical part in its own microcontroller.) > > > Konrad > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > > > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest