Herman: Shipping Rust in Firefox

Posted Jul 19, 2016 15:05 UTC (Tue) by marcH (subscriber, #57642)
In reply to: Herman: Shipping Rust in Firefox by mathstuf
Parent article: Herman: Shipping Rust in Firefox

> on a pedestal

More like: in the foundation.

Memory is the lowest level, most basic resource. The lower level is a programming language, the closer it is to a memory management system. C is little more than a (manual and tedious) memory manager.

Also, isn't memory the only local resource that the language has exclusive control over? Except for memory mapped I/O which is rarely seen in user space.

> sometimes the resources you're managing aren't less important than memory,

Even from a pure security standpoint?

Herman: Shipping Rust in Firefox

Posted Jul 19, 2016 15:57 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (5 responses)

If I have a temporary directory, I might like it to be cleaned up no matter how the function exits (except things like poweroff, abort() or SIGKILL; not much anyone can do there). Currently, I have to explicitly try/catch or try/else for this to happen since the language doesn't let me use its memory management facilities for any other resource. Why can't I just have an object which cleans stuff up whenever it goes out of scope, not just when I remember to try/catch around its usage?

> Even from a pure security standpoint?

Yes. Memory problems indicate other errors in the program which can be fixed. An ideal program (which I admit is an extremely rare find) wouldn't care if it were on a GC or some RAII setup with respect to memory. However, the RAII setup allows me to ensure that my program cleans up after itself on the filesystem, over the network, or whatever other resource might be needing managed without issue; a GC setup leaves me back in the world of C's memory management assistance instead for such things. I know D's GC doesn't guarantee destructors are called (genius that, but probably something about undecidablility of the proper call order at program shutdown), but C# and Java don't even *have* destructors for such things.

Herman: Shipping Rust in Firefox

Posted Jul 19, 2016 19:37 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

> If I have a temporary directory, I might like it to be cleaned up no matter how the function exits (except things like poweroff, abort() or SIGKILL; not much anyone can do there). Currently, I have to explicitly try/catch or try/else for this to happen since the language doesn't let me use its memory management facilities for any other resource.

Which language is that? I remember (in the early 80s) using Fortran77 and getting exactly the functionality you're after (except it was buggy :-) The Ops staff swore at me because I accidentally deleted several important files before I realised what was happening and they had to restore them from backup ... :-) (You could declare a file as temporary, and it was deleted on close. The problem was, if you re-used that file descriptor, it ignored any attempt to declare the new file permanent, and deleted that on close, too :-)

The problem with programs is they like to open files anywhere. If they followed the standards and opened temporary files in /tmp, or c:\temp, or wherever they were supposed to, then the operating system would clean up behind them (any real OS that is, I don't think WinDos does it properly).

Cheers,
Wol

Herman: Shipping Rust in Firefox

Posted Jul 19, 2016 20:37 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

I'm more thinking where there's a directory I created that should not persist outside of the function which created it; claiming ownership of files which already exist would probably not use such an RAII object the same way. `TempDir foo = TempDir::new()` versus `TempDir bar = TempDir::take(path)`.

Herman: Shipping Rust in Firefox

Posted Jul 20, 2016 6:55 UTC (Wed) by oever (guest, #987) [Link] (2 responses)

If I have a temporary directory, I might like it to be cleaned up no matter how the function exits (except things like poweroff, abort() or SIGKILL; not much anyone can do there).

In C++, you can clean up in the destructor of an object. This is simple RAII. In Java, you could clean up in the finalize() function. The C++ destructor is called immediately when the scope ends. finalize() is called by the garbage collector which runs a few times per second. In Java and C# most variables are pointers to objects and Java does not have a way to automatically call a function directly when the last pointer to an object leaves scope and neither does C#.

A refreshing aspect of Rust is that the syntax for dealing with objects is nice and safe. It has the best of both worlds: no need for manual memory deallocation but the ability to run any type of cleanup when the last reference to an object leaves scope. Defining a destructor is optional and done via the Drop trait.

Herman: Shipping Rust in Firefox

Posted Jul 20, 2016 7:01 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> In Java, you could clean up in the finalize() function.
No, you can not. Finalize method is only guaranteed to run some time in future - like next hour or next day.

The way to manage resources in Java now is try-with-resources statement.

Herman: Shipping Rust in Firefox

Posted Jul 20, 2016 9:12 UTC (Wed) by farnz (subscriber, #17727) [Link]

It's not even guaranteed to be called in Java; it's called if the GC determines that this object has no references and is thus eligible for collection.

In practice, this means that if your process exits before the GC decides that your object is ready for collection, the finalizer is not called at all - e.g. because there happens to have been no memory pressure between the object being allocated, and the process exiting cleanly for a restart.

Herman: Shipping Rust in Firefox

Posted Jul 19, 2016 16:57 UTC (Tue) by excors (subscriber, #95769) [Link]

At the bottom level of language (/language runtime) implementation, dynamically-allocated memory is just a limited resource provided by the OS from sbrk/mmap syscalls. Similarly, file descriptors are a limited resource provided by the OS from open syscalls. Same for threads, GPU memory, network sockets, etc. Why should dynamically-allocated memory get so much more special treatment than any of those other resources that look so similar? (And that's before looking at resources provided by other processes rather than the OS.)

Garbage collection is simulating a computer with an infinite amount of memory. There are some languages that simulate a computer with a near-infinite capacity for threads, using green threads etc, but many don't. In theory a language could probably simulate support for an infinite number of file descriptors, but in practice they never seem to bother - if you try to open ~1024 files they'll happily return a "too many open files" error and let you solve the problem yourself. (Sometimes they'll go part way by GCing file objects to close ones they know can never be accessed in the future, but that only really works in languages with a refcounting GC or with RAII, and if you might access those files again then you're left to manually implement some pooling scheme yourself, so the language still isn't helping as much as it could.)

Nowadays virtual address space pretty much is infinite, and the cost of physical memory seems to still be decreasing exponentially, but many of the other limited resources have remained constant for ages. So I think an exclusive focus on managing memory is not good enough for a modern language - they really ought to assist with managing those other resources just as well.