pnkfelix (from Mozilla) has been doing lots of investigation into custom allocators[0], custom GCs, and embedding Rust into places where a GC is already active. He also recently published some blog posts outlining the problem of GC interop[1][2]. Quoting aturon[3]:

> To be clear, a major goal of this project -- outlined in the earlier blog posts -- is "GC as Interoperation Feature". That is, we want to embed Rust code into contexts with existing GCs (such as the V8 or SpiderMonkey Javascript engines), and so Felix is trying to find ways to accommodate a relatively wide range of GC approaches, with maximally safe, efficient, and ergonomic support on the Rust side.

Might be a while off before good support for custom GCs for pure Rust code, but it's definitely being thought about.

[0]: https://github.com/rust-lang/rfcs/pull/1398

[1]: http://blog.pnkfx.org/blog/2015/11/10/gc-and-rust-part-1-spe...

[2]: http://blog.pnkfx.org/blog/2016/01/01/gc-and-rust-part-2-roo...

[3]: https://www.reddit.com/r/rust/comments/3zqtoc/gc_and_rust_pa...

Nim allows you to disable the GC if I'm not mistaken. D also, but to a lesser extent.

Jai [1], Jonathan Blow's language in progress, has a ton of customizable features. For example, the memory allocator is quite straightforward to swap natively without any hacks.

[1]: https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md

Rust does that. Rc type is implemented in Rust. (https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html) There's also arena allocation available as a library. (https://crates.io/crates/typed-arena/) You can add your own memory management abstractions as libraries.

Very interesting.

I'm also interested in one particular kind of memory abstraction: abstracted access to memory mapped files. Here the problem is that the base address of the memory mapped area might change whenever you perform the mapping. And you would like to use standard data-structures (like maps, lists, etc.) inside the memory mapped area.

Mmaped files are already available it seems (https://crates.io/crates/mmap/), although I've never tried it. You'd have to implement the interesting structures on top of that yourself however.

Relative pointers are great in memory map data structures. All pointers are relative to current offset. That way it's almost always also possible to get away with just 32-bit pointers -- you get +- 8 GB range.

A library that can do that in Rust would be great.

A signed 32 bit "offset" value gives you 2GB in each direction, not 4GB in each direction.

Only if you use byte aligned relative pointers. For data structures you don't need better than 32-bit aligned pointers. So you get +- 8GB relative offsets. It's not all that unreasonable to use 64-bit or even 128-bit alignment, for +-16 GB and +-32 GB respectively.

Hmm, it seems this library only provides the basic I/O.

The main problem is not opening the mmapped file. The problem is having a kind of pointer that allows arbitrary offsetting, and using this pointer inside standard data structures.

Rust has typesafe arenas, when one allocates small objects from a bigger chunk of memory and typesystem ensures that small objects do not outlive the chunk. I suppose mmap files could be treated similarly when assembling a pointer from an offset stored in the mmaped file is treated as an allocation.