Hacker News Reader

Comment by calebwin | Hacker News Reader

Would you mind elaborating on the "compile time reference counting"? Is this new? How does it handle cycles?

It is so new I haven't even documented it yet.. hence why I said the timing for this HN post isn't great.

So imagine the current implementation does a lifetime analysis somewhat similar to Rust, but then where Rust would error out, this implementation simply inserts a runtime refc increase. This gets rid of most runtime refc overhead without the programmer needing to be clever about it.

Then, I intend to add an optional type annotation that gets you the Rust behavior, for those cases where you want maximum control. I don't think its the right default though.

The algorithm is more lenient than Rust, since I don't have any shared memory concurrency for example.

I intend to write up more thorough details about the algorithm, but again, haven't gotten to it.

It does not handle cycles. If you create cycles that you do not manually break, you'll get a cycle report at program exit that prints the kind of values that weren't reclaimed. You're then expected to fix your code accordingly :)

Any chance you could you share some references on this kind of type inference? It sounds very interesting!

It is not an implementation of an existing paper or anything.. I am going to write it up soon, promise!

Feel free to email or msg me if you want to be notified.

You could try: http://liu.diva-portal.org/smash/get/diva2:20899/FULLTEXT01....

That sounds more similar to Swift's approach, where the compiler does aggressive optimisation to elide reference counts were possible. Do you agree?

Yes, it is more similar to Swift than Rust. I guess people are more familiar with Rust.. since Swift hasn't actually implemented it yet?

https://github.com/apple/swift/blob/master/docs/OwnershipMan...

The compiler has implemented a lot of the infrastructure for reasoning about ownership, and has had optimisation for eliding reference counting operations for a long time (but the ownership stuff makes them simpler).

This at first glance actually looks similar to http://liu.diva-portal.org/smash/get/diva2:20899/FULLTEXT01....

And this style of static analysis has been taken even further by Luc Blaeser: http://concurrency.ch/Content/publications/Blaeser_Component...

The cycle checker I'll have to have a look at - I'd like to crib parts of it for an OS I'm trying to cobble together. Your project looks very interesting, thanks!

Thanks for those, I hadn't seen them. The Ritzau paper indeed appears to be doing something very similar, where in 5.2 he describes "inner references" whose lifetime is bounded by the outer one, I call that "borrowing", where the outer definition (the owner) gets locked from mutation during the borrow.

What I do is a bit more involved though, as for every language construct I indicate if it wants to own or borrow its children (and wether it wants the parent to own or borrow), to remove maximum refcounts, also for cases which are not simply variables. Again, I will describe this in detail.

The second paper I don't see how it relates to what I am doing.

http://aardappel.github.io/lobster/memory_management.html

> I don't think its the right default though.

I think Rust should allow this kind of relaxed ownership, with ARC behind the scenes, as lots of user level code should not require fussing over ownership details. A "get shit done" mode.

Rust supports proc macros, you know-- you can do literally anything with your code. So what you describe is already possible! Make a good proof of concept and submit a proper RFC for it, and it might even be adopted as part of Stable Rust!

Yes, that is exactly my intention, for the majority of code this compile time reference counting is good enough.

You can of course use Rc types in Rust, but that is verbose, and throws all ownership out the window, unlike Lobster.

More on the compile time reference counting here: http://aardappel.github.io/lobster/memory_management.html

A comparison to Swift's ARC would also be of interest :)

Yup, I will write up the algorithm some time soon.

I've seen Swift's intentions to add lifetime analysis to ARC, but from what I could see it is much more complicated in Swift, requires annotations, and with significant runtime overhead remaining.

Arc isn’t that stuff, Arc is what it already does today. “Automatic reference counting.”

I'm aware of that, I said "add lifetime analysis to ARC", as in, ARC is what I call regular runtime reference counting, and with lifetime analysis some of it can move to compile time.

Yep oops, sorry.

Anyway, psyched to see more people experimenting with this kind of thing!

Yes, I frankly feel this design space is the future of memory management. GC, begone!

http://concurrency.ch/Content/publications/Blaeser_Component...

This seems to scale out very well - it's kind of static GC analysis with RAII and erlang-style messaging.

http://aardappel.github.io/lobster/memory_management.html

Reply on news.ycombinator.com