Difference between revisions of "Project Ideas"
(→Lowerer) |
(→fork()-based Garbage Collector) |
||
Line 36: | Line 36: | ||
== <tt>fork()</tt>-based Garbage Collector == | == <tt>fork()</tt>-based Garbage Collector == | ||
+ | |||
+ | Gustavo Rodriguez-Rivera and Vincent Russo authored a [https://www.cs.purdue.edu/homes/grr/snapshot-gc.pdf paper] on an interesting take on a garbage collector: leverage efficient <tt>fork()</tt> implementations, which in many Unix systems take advantage of hardware-provided copy-on-write semantics for duplicated memory pages across processes. | ||
+ | |||
+ | This idea is already leveraged in the high-performance garbage collector for D implemented and used by Sociomantic. (A lingering issue is <tt>fork()</tt> and <tt>malloc()</tt> share a lock, which is [http://www.dsource.org/projects/tango/ticket/2087 problematic].) Leandro Lucarella, the engineer who wrote the implementation, has open sourced it [https://git.llucax.com.ar/w/software/dgc/cdgc.git here], but that is a bitrotten version that has fallen on the wayside. | ||
+ | |||
+ | Leandro would be glad to assist with questions by a motivated implementer. Gustavo has quite a few ideas for improvements, including for a possible Windows implementation, and may be able to even coauthor a paper. | ||
== Interfacing with C++ == | == Interfacing with C++ == | ||
== Linux debugger == | == Linux debugger == |
Revision as of 00:22, 4 November 2016
Lowerer
This tool would "translate" compilable D code to compilable D code. See initial idea discussed in Issue 5051. It would offer a variety of lowering services for purposes of tooling, debugging, and project management:
- do not output function bodies, .di style
- write deduced attributes for functions (useful when function bodies are not written)
- expand all possible mixins in the code
- execute lookup on all symbols and write the full symbol, e.g. writeln becomes .std.stdio.writeln
- explicitate all user-defined operators, e.g. a + b becomes a.opBinary!"+"(b)
- replace all wholesale imports with detailed imports that specify the symbols needed
- write specialized versions for all templates used within the module (this is likely to be tricky)
- lower all scope statements into try statements
- lower all foreach statements into for statements
- specify the exact symbols needed for each import statement (which means: if no symbols, the import is redundant - easy to mark as a warning by a subsequent tool)
- evaluate all static ifs possible
- lower code using version(), i.e. make the unused branch disappear
- make all comments disappear
- make only non-documentation comments disappear
- evaluate all possible CTFEs (tricky)
- introduce named values instead of temporaries wherever order of evaluations is defined
fork()-based Garbage Collector
Gustavo Rodriguez-Rivera and Vincent Russo authored a paper on an interesting take on a garbage collector: leverage efficient fork() implementations, which in many Unix systems take advantage of hardware-provided copy-on-write semantics for duplicated memory pages across processes.
This idea is already leveraged in the high-performance garbage collector for D implemented and used by Sociomantic. (A lingering issue is fork() and malloc() share a lock, which is problematic.) Leandro Lucarella, the engineer who wrote the implementation, has open sourced it here, but that is a bitrotten version that has fallen on the wayside.
Leandro would be glad to assist with questions by a motivated implementer. Gustavo has quite a few ideas for improvements, including for a possible Windows implementation, and may be able to even coauthor a paper.