-1

Which ecosystems allow to create multiple heaps right now?

AppDomains don't create new heaps (there is still one heap for all domains). So, what one need to do to launch several different GC inside the single process?

Which syntactic primitives does one need to create? How a runtime should support that primitives?

trincot
  • 317,000
  • 35
  • 244
  • 286
xsp-server-hater
  • 55
  • 1
  • 1
  • 9

1 Answers1

0

Which ecosystems allow to create multiple heaps right now?

One obvious answer would be "C++" (feel free to fill in surrounding pieces as you see fit, if you don't consider a language to be an "ecosystem" in itself).

C++ allows you to specify heaps along a few different axes. One is by the type of an object--you can specify allocation for a particular type by overloading operator new and operator delete for that type:

class Foo { 
    static void *operator new(size_t size);
    static void operator delete(void *block, size_t size);
};

It's then up to you to connect these heap management functions to an actual source of memory. You might allocate that via ::operator new, or you might (for example) go directly to the OS, such as with something like GlobalAlloc or VirtualAlloc on Windows, sbrk on UNIX-like systems, or just have pre-specified blocks of memory on a bare-metal embedded system.

Along a somewhat different axis, all the containers in the C++ standard library allocate and free memory via Allocator classes. The Allocator for any particular collection is specified as a template parameter, so (for example) a declaration for std::vector looks something like this:

template <class T, class Alloc=std::allocator<T>>
class vector {
    // ...
};

This lets you specify a heap that will be used to allocate objects in that collection. Much as with operator new and operator delete, this really only specifies the interface by which the collection will allocate and free memory--it's up to you to connect that to code that actually manages the heap.

Garbage Collection

As far as garbage collection goes: I personally find it annoying, and advise against its use as a general rule. The problem is that it while it can (at least from one perspective) fix some types of problems with memory management, it does nothing to help management of other resources--and (unfortunately) I haven't seen anything like a tracing collector for file handles, network sockets, database connections, and so on. RAII provides a uniform method for dealing with resource management in general.

That said, if you really insist on using GC, C++ does support that as well. Prior to C++11, GC was entirely usable on a practical level, but led to what was technically undefined behavior under a few obscure circumstances, such as:

  • storing a pointer in a file, and reading it back in, or
  • modifying the bits of a pointer, later un-doing that modification

...and later taking the re-constituted pointer and dereferencing it. Obviously, while the pointer wasn't visible to the CPU, the pointed-to block of memory became eligible for GC, so the later dereference caused problems. C++11 defined these circumstances, and added a few library calls (e.g., declare_reachable, undeclare_reachable) to deal with them (e.g., if you call decalare_reachable(block);, that block is not eligible for collection, regardless of whether a pointer to it is visible). As such, if you want to use GC with C++ you can, and the bounds of defined behavior are thoroughly specified. The only problem is that essentially no code ever calls declare_reachable and/or undeclare_reachable, so in real use they're likely to be of little or no help (but pointer swizzling and/or storage in a file are sufficiently rare that this is unlikely to pose a real problem).

For a practical example, you might want to look at the Boehm-Demers-Weiser collector (if you haven't already).

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111