Difference between revisions of "Project Ideas"

From D Wiki
Jump to: navigation, search
(Interfacing with C++)
(fork()-based Garbage Collector)
Line 41: Line 41:
 
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.
 
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.
+
Leandro would be glad to assist with questions by a motivated implementer. Gustavo has quite a few ideas for improvements, including a possible Windows implementation, and may be able to even coauthor a paper.
  
 
== Interfacing with C++ ==
 
== Interfacing with C++ ==

Revision as of 00:42, 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 a possible Windows implementation, and may be able to even coauthor a paper.

Interfacing with C++

Walter Bright has gotten the compiler to the point where it is possible to write declarations for C++ types and functions (including certain templates) and even throw an exception from C++ and catch it in D.

The next step is to define D interfaces for the data structures and functions in the C++ standard library, which would go e.g. in core.stdcpp in druntime (modeled after core.stdc). This is a high-impact project because it would allow D code to interface easily with legacy C++ code using standard library artifacts such as std::string and std::vector.

Linux debugger