Originally Posted by attila77

QPointer and friends *sort of* do this. My code is mostly devoid of class* thingies because it's easier and safer to use Qt's smart pointer classes. While this does not do object movement in memory (*now* - as said above, benefits of that can be ambiguous), it does affect memory management, as it provides reference counting, CoW operations, shared data, etc.

Originally Posted by Capt'n Corrupt

Smart pointers sound interesting, I will look into this class. QPointers are also interesting. However, my idea was to mimic the pointer system via class that controlled a contiguous block (or blocks) and methods for controlling it. This is somewhat different than guarded pointers.

Out of curiosity (and don't answer if you don't want to), what type of programming do you do?

Originally Posted by attila77

Which brings things us to the (repeated) bottom line - C++ as such does not *require* a certain type of memory management, it's not part of the language, so if you have a fancier, smarter way of dealing with allocated memory, give it a go.

Originally Posted by zimon

The fancier smarter way, like defragmentation when needed,

At first, a moving GC strategy may seem inefficient and costly compared to the non-moving approach, since much more work would appear to be required on each cycle. In fact, however, the moving GC strategy leads to several performance advantages, both during the garbage collection cycle itself and during actual program execution:

* No additional work is required to reclaim the space freed by dead objects; the entire region of memory from which reachable objects were moved can be considered free space. In contrast, a non-moving GC must visit each unreachable object and somehow record that the memory it alone occupied is available.
* Similarly, new objects can be allocated very quickly. Since large contiguous regions of memory are usually made available by the moving GC strategy, new objects can be allocated by simply incrementing a 'free memory' pointer. A non-moving strategy may, after some time, lead to a heavily fragmented heap, requiring expensive consultation of "free lists" of small available blocks of memory in order to allocate new objects.
* If an appropriate traversal order is used (such as cdr-first for list conses), objects that refer to each other frequently can be moved very close to each other in memory, increasing the likelihood that they will be located in the same cache line or virtual memory page. This can significantly speed up access to these objects through these references.

Originally Posted by zimon

The fancier smarter way, like defragmentation when needed, will be more inefficient in C++ than with Java JIT. Java JIT can use real pointers in its JIT'ed code, but C++ with a "fancy" memory management should have all pointers then indirect (or do code morphing). When GC in JVM notices there is fragmentation or the ratio of pagefaults has increased, it can re-arrange the objects and re-JIT the affected hotspots.

Originally Posted by attila77

Sorry. C++ can also be JIT-ed, garbage collected, and VM memory management is by no means a holy grail (if nothing else, the VM does not know about physical memory layout and architecture, which will always be an issue). C++ has moved past the '80s and Stroustrup, honest, and mobile contexts are a fairly unexplored area for JIT and proactive fancypants memory management.

Originally Posted by zimon

Read for example this:
And in all OOP-programs which have many variable size variable life time objects, you cannot really archive both high object locality and small fragmentation ratio, unless you use some kind of "moving-GC".

Originally Posted by zimon

@v13: I think we are talking about little different heap memory fragmentation problems and effects here. I am mainly concerned (in this Java vs C++ issue) the increased pagefaults due to increasing heap memory fragmentation in long living OOP programs like www-browser. The problem with fragmentation is that locality of the objects is getting worse.

Originally Posted by zimon

I do see Firefox still taking too much available RAM when it is runnign long time, but that is not why I restart it every few days, because the machine do not start swapping yet. But firefox seem to get slow, and restarting it makes a real difference. I notice this also if I disable flash. Javascript engine in Firefox has pretty good GC nowadays, so I don't think that is a problem but C++ memory management itself.