4 ms·

No, everything will be available via intrinsics, traits, and internal plugins. (as in, autoloaded #[derive()] syntax extensions as a part of rustc that the libr

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".
- steveklabnik 10y ago
  I was not aware of this. Thanks for the link.
- Manishearth 10y ago
  What do you mean by compiler hooks here? I just mean intrinsics and magic traits. sizeof() is an intrinsic. It looks like a function, but isn't. Copy is a magic trait. It works like a trait but signals additional meaning to the compiler. So is Add. Implementing Add looks like implementing any other trait, except that it conveys extra meaning to the compiler. The GC support will involve basically the same thing. In fact, that intrinsic will probably be wrapped in a slightly higher level api, so you're not even directly calling an intrinsic. Like I said, the GC will look like a normal library and be loaded the normal way. It doesn't hook into the compiler like a plugin (no library code is run at compile time), it just makes use of magic traits and functions which signal meaning to the compiler. Such traits and functions already exist in rust for non-gc purposes and get used all the time. Rust also has that replace-allocator support you mentioned, BTW. If anything, allocator crates are more "special" that GC crates -- GC crates look like any other crate, but allocator crates have some special annotation. I think I read a preprint of that paper, not sure (cant read the paper from here right now). It addresses the other half of the rust GC problem -- one half is designing a safe GC interface (which is solved by rust-gc or these hooks), the other is writing a good and useful GC algorithm.
  - pjmlp 10y ago
    Magic traits and intrisics are also a form of compiler hooks, without them the compiler will not have any idea what to do with the library. In any case looking forward to it.
    - Manishearth 10y ago
      Right, but this is no different from implementing Add or Copy or FnMut or Placer, or calling sizeof or transmute or black_box, or using UnsafeCell. So its not "special" in any way. I don't disagree that its a compiler hook; that's what I called it in the first place :) I disagree that its makes the library in any way "special" or a pseudo library. I can write a linear algebra library that gives you Vec3d and Matrix4d and the ability to multiply/add such types using regular multiplication operators. I can also write a Gc<T> library that lets you wrap some values in a GC heap allocation, which will have some extra stack maps being generated. It doesn't feel much different to me, both are equally worthy of being called libraries. Anyway, expect a blog post soon. :)

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

steveklabnik 10y ago
I was not aware of this. Thanks for the link.
Manishearth 10y ago
What do you mean by compiler hooks here? I just mean intrinsics and magic traits. sizeof() is an intrinsic. It looks like a function, but isn't. Copy is a magic trait. It works like a trait but signals additional meaning to the compiler. So is Add. Implementing Add looks like implementing any other trait, except that it conveys extra meaning to the compiler. The GC support will involve basically the same thing. In fact, that intrinsic will probably be wrapped in a slightly higher level api, so you're not even directly calling an intrinsic. Like I said, the GC will look like a normal library and be loaded the normal way. It doesn't hook into the compiler like a plugin (no library code is run at compile time), it just makes use of magic traits and functions which signal meaning to the compiler. Such traits and functions already exist in rust for non-gc purposes and get used all the time. Rust also has that replace-allocator support you mentioned, BTW. If anything, allocator crates are more "special" that GC crates -- GC crates look like any other crate, but allocator crates have some special annotation. I think I read a preprint of that paper, not sure (cant read the paper from here right now). It addresses the other half of the rust GC problem -- one half is designing a safe GC interface (which is solved by rust-gc or these hooks), the other is writing a good and useful GC algorithm.
- pjmlp 10y ago
  Magic traits and intrisics are also a form of compiler hooks, without them the compiler will not have any idea what to do with the library. In any case looking forward to it.
  - Manishearth 10y ago
    Right, but this is no different from implementing Add or Copy or FnMut or Placer, or calling sizeof or transmute or black_box, or using UnsafeCell. So its not "special" in any way. I don't disagree that its a compiler hook; that's what I called it in the first place :) I disagree that its makes the library in any way "special" or a pseudo library. I can write a linear algebra library that gives you Vec3d and Matrix4d and the ability to multiply/add such types using regular multiplication operators. I can also write a Gc<T> library that lets you wrap some values in a GC heap allocation, which will have some extra stack maps being generated. It doesn't feel much different to me, both are equally worthy of being called libraries. Anyway, expect a blog post soon. :)