22 ms·

Firstly, I think that .NET is an excellent reference here. Its platform for language integration is a good model for the kind of thing I want to achieve. Honest

• pjmlp 10y ago
  The original idea of .NET was to migrate the whole Windows stack to it, hence why MSIL is much more flexible than JVM bytecode, as it had to be language neutral and even support C++. Initially Microsoft was going to make it fully native and based on COM, it was called Ext-VOS project from Microsoft Research and the runtime COM+ Runtime. Eventually they decided to create the CLR instead and things never fully worked out that way. However with Windows 8 they have gone back to the original idea and WinRT was born. Which is basically the same COM+ Runtime ideas, but using .NET metadata instead of COM type libraries. On Windows .NET follows a similar idea as mainframes do language interoperability by having the runtime being part of the OS. The whole problem with GC and JIT implementations as library is that they will never be as good as the ones that work together with the compiler. There are many types of optimization algorithms that require an helping hand of the compiler how the data structures and specific code patterns get generated. Of course it depends what are the goals in terms of performance, throughput and latency.
  • Manishearth 10y ago
    See my comment above, Rust may (probably will) get intrinsics and traits that let you write a gc that works with the compiler. Not as awesome as a GC irrevocably designed into the compiler, but good enough.
    • pjmlp 10y ago
      I saw it, interesting reply. But in the end what you get is a kind of compiler plugin and not a generally purpose library, right?
      • Manishearth 10y ago
        No, everything will be available via intrinsics, traits, and internal plugins. (as in, autoloaded #[derive()] syntax extensions as a part of rustc that the library has no part in defining) The library will look like regular rust code, and will be loaded the regular way (extern crate my_gc). There may be a special codegen flag that rust will ask you to explicitly enable (we haven't decided on this yet) which will be something cargo can do for you. But otherwise, just a library. In fact, so far it looks like it might be possible to even have multiple GCs active at once. Not always a good idea, but a potentially useful thing to have. Whether or not the gcs should be allowed to mix is a hard question, but it is one that GC implementors can worry about -- the type system lets them forbid this behavior. Forbid is basically the default (not forbidding the behavior is harder to express and more explicit, but doable). Its the difference between implementing a concrete trait and implementing a generic trait with specialization. The design is ultimately a magic trait that signals what should be considered a root, and an intrinsic that lets you walk these roots. There are some other traits and stuff making this palatable, but its all something that can be used in a library-esque way.
        • pjmlp 10y ago
          But that is what I mean, it is a pseudo-library because the code needs to integrate with those compiler hooks you just described. Just like, for example Turbo Pascal, Delphi or .NET allow us to replace the memory allocator by initializing the runtime with an user provided library that obeys to a specific certain ABI. Good luck with the work. Are you aware that these guys are using Rust for language research in VM implementation? http://microvm.github.io/ http://microvm.github.io/ They just published "Rust as a Language for High Performance GC Implementation".
          • 10y ago
• Manishearth 10y ago
  In fact, Rust is working on hooks for GC-as-a-library. I'll be writing a blog post on this very soon. The gist of it is that you'll some intrinsics for rooting, and some useful traits, on which you can build a GC or write safe bindings to a GCd language. In line with Rust philosophy, this won't cost anything unless you use it. (rust-gc already exists, but it can be far more efficient with some compiler support. I would recommend waiting for that.)
  • mike_hearn 10y ago
    The main integration points between compilers and GCs are pointer maps and write/read barriers. I don't see a good way to do a GC-as-a-library given the need for the GC to contribute barrier code, which has to be tightly optimised. That's one reason Java/.NET use JIT compilers: there's not yet any one-size-fits-all GC algorithm, and all the best ones need tight compiler integration, so allowing you to pick your GC on the command line and then that impacts how the code is compiled represents a way to square the circle.
    • Manishearth 10y ago
      Pointer maps (stack maps) are basically what rust will get in its gc support. Rust has a stricter view on mutability, so GCs would be immutable-by-default like Rc is -- mutation would be very explicit and thus barriers are easy to insert. Yes, some optimization opportunities are lost ... but I'm optimistic :) Ultimately it will never be as good as what Go (or whatever) can do, but it might just be good enough for the application. For cases where you are interoperating with an existing GC or using gcs for a persistent datastructure or something, the GC isn't pervasive so perf doesn't factor in as much as in, say, Java, where everything lives on the heap and the GC has to optimize a lot of extraneous stuff. Non-pervasive usage of GCs mean that the programmer is using the GC only where needed, so consequently less optimization is needed :) What the post proposes will require a pervasive gc, however. But that GC will be pervasive in the language living on top of rust -- and that compiler/transpiler can attempt to perform optimizations. Can't exactly JIT to rust, though, so it might end up slower. Not sure by how much.