Status of @nogc with the runtime

[Martin Nowak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 02/17/2018 07:03 PM, Peter Campbell wrote:
> My understanding from the vision documents and what Andrei
> mentioned at his DConf presentations is that the runtime itself
> will be modified to not rely on the GC, allowing for you to
> continue using features such as associative arrays and array
> concatenation, but without requiring the garbage collector. Is my
> understanding correct? If so is work still being done to make this
> happen and is there an easy way to follow the progress?

@nogc containers will most likely come in the form of a library.
We plan to move built-in hashes to a templated druntime implementation
(https://github.com/dlang/druntime/pull/1282), and at best make array
and hash literal syntax available for user defined types (w/ an
approach similar to C++'s initializer_list).
Our current std.container package does not use the GC
(https://dlang.org/phobos/std_container.html), but isn't really up to
par. Your best options atm. would be
[emsi_containers](http://code.dlang.org/packages/emsi_containers) for
containers and [automem](http://code.dlang.org/packages/automem) for
smart pointers.
Both libraries support custom allocators
(https://dlang.org/phobos/std_experimental_allocator.html).
Writing containers and smart pointers isn't rocket science, so it's
the least of our worries.

While heading for @nogc we've decided that we don't want to give up
@safe-ty (remember that GC based allocations don't suffer from memory
corruptions).
Walter has spent a lot of effort on preventing escaping of aliases
(DIP1000).
I'm currently working on a proposal (DIP) and implementation called
"limited lifetimes" that is targeted at preventing use-after-free bugs
at compile time without impeding usability too much.
We hopefully will have at least a prototype implementation for this
year's DConf in May.
This should become the foundation for `@safe @nogc` RC/Uniq/Weak
primitives, onto which we can layer `@safe @nogc` libraries.

In parallel Andrei and his students are investigating alternative
approaches to reduce GC overhead or prevent use-after-free errors at
runtime.

We've somewhat stopped to work on our GC, to focus on
unique/ref-counted memory management. Though soon the GC
implementation can be replaced with custom GCs from our package
manager dub (https://github.com/dlang/druntime/pull/1924). This should
open the door for low-latency GCs, based on CoW and dirty page flags.
We don't want to add write-barriers to the language due to the ~5%
overall slowdown, so generational GCs are out of reach, but there is
an interesting paper on using type information to perform partial
collections ([Connectivity-Based Garbage
Collection](https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf)).

At the moment there is no good way to track progress, as a lot is
being worked on behind the scenes by many distributed actors.
I think we are the ones most annoyed that this transition takes so
long, but our plans are also very ambitious, targeting minimal memory
footprint, optimal performance while supporting a @safe language
subset and advanced features like custom allocators or region based
allocations.

- -Martin
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlqJ7CsACgkQsnOBFhK7
GTnTyQ//axaUtY8B1VhjW3Y/cMs4GESDmwa68r3IU/3XnyUelZfbMhAnA14aQh23
7y9D9MpPLYbgRQDbsrbUU7BoXMIiguFDQmR/265I7ZlhugVbG8VerQv+cIfXjiz9
fNKNgZHjp6hBPDIcHruiOcFNmqg73ymSg/9VWmEIzS1HUSMtZpBslz9uPWwKCacV
axv8a/oPOBo5C8WcHqwtXHPeNZYKiwAcBaE6cXordN9r0dK1OC/JtvbjLRQnbv72
d0Xifdj4IkLM4krJvEZVX7jEPOvq15P48ns/gxMiem8e2qn6pHW+FIPHRx/y9Wv0
K5RGsivkBETDX6xrohwKdSEf5vIx4qQavI1pAA/8NIVsI2AlBs0OYivUnd+pTHA6
mLLI/Ask8NmWoA4FNFdWI0+zC/zTs1e06sTl1nsMs2NHCCaRL3CSTJmExeLVDrYD
iz/5XvKMsZUh1wSlFvoqFX4UvmjZH3HseZfh1WhKaYnSculc0RzhDIYzbftCKqJR
1nCOnNyhS8kuxGT881oYZmbTyevoy2uU3tBStmXcGcRTfpHkd9xaFY7vlqF0Aa41
eUI0z6r4SG+ZmDmwHlnZD58kcIvBVvWZaAoo4hz0138LW0LNd9tRiBPTyUfE9PJL
qCmEbVvB25nz2yge9iEOGERJYRI8P1fssfUX3bjNcDoeLTMokPo=
=wnx7
-----END PGP SIGNATURE-----