-----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-----
