I'm normally in the `It's shit, end of discussion' camp, but recently I've been thinking that this is really caused by attempting to bolt it onto C-like languages. The problem is that GC has to, one way or another, at some point know exactly whether an allocated object is reachable from current context. What makes this hard is that you can take arbitrary references to an object in C/Java/Sepples/etc. If the following code were illegal:
o = create_some_big_object(); a = o; do_something_with_object(o); do_something_else_with_object(a);
Because a and o were both references to the same memory, GC would be a lot better. So if you had a language that operated kind of like this:
object *o, a, b; // All implicitly (or explicitly) NULL create_some_big_object(&o); // The memory is created with exactly one reference transfer_reference(&o, &a); // The memory still has exactly one reference - o is NULL'd // do_something_with_object(o); // This would be illegal, o is NULL do_something_with_object(a); // This is fine copy_reference(&a, &o); // Now the memory has exactly two references do_something_with_object(o); // This is now fine transfer_reference(&b, &o); // Still two references close_reference(&b); // Now one reference - a transfer_reference(&b, &a); // Now one reference - b close_reference(&b); // Now zero references, memory is reclaimed at exactly this point.
I think Rust is doing something along this path, with owned references and transferring references, but I haven't had time to look into Rust (partially because every time I look at it they've made major structural changes to the language, and I want to wait for it to settle down), and I'm sure there have been languages in the past that did this, but I haven't seen any. Obviously, the syntax is shit in my example, but I think the basic point: that you have to explicitly duplicate references, could make it work.
The bit where this would really work is in the case where you transfer a reference into a field of a structure, because close_reference could do a walk and sanely close out child references as well, and transfer_reference can sanely close references to its clobbered arg.
But obviously, this doesn't work too well when you have a language that allows programmers to skip close_reference, or to take pointers in any other method than from creation or copy_reference, etc. Sepples tried something like this with RAII, but I wouldn't exactly call Sepples a model of perfection for that. So in order to create this model as a usable language, I think C-ish syntax would have to be thrown away.
Name:
Anonymous2013-11-17 22:58
>>1,5 I'm in the ``It's great, except when it's implemented by idiots, which is most of the time'' camp.
I dislike forced manual deallocation because that it clutters up the code and it is overkill for small allocations/deallocations where escape analysis could automatically free memory instead. Conversely, I find it important to be able to manually deallocate things when the program flow is too complex for escape analysis to handle and not doing so would cause a large amount of memory/CPU-time to be wasted. However, I would ballpark that 99% of allocations don't need to have a deallocation point manually specified.
It seems like we don't have trouble coming up with the requirements for a language that would give all of that. But what implementations out there will do this? With letting you do manual allocations and deallocations when you want while the optimizing compiler determines allocation methods automatically for the other objects. Does D have an optimizing allocator like this?
Name:
Anonymous2013-11-18 1:57
>>7 I seem to recall reading that D used Boehm GC under the hood, but I may be wrong. If that's the case, Boehm is probably the thing to look at anyway.
It seems like we don't have trouble coming up with the requirements for a language that would give all of that. But what implementations out there will do this?
Probably no proper existing implementations, because if it ain't Lisp it's crap, and Lisp is shit, so everything is either shit or crap (maybe except Symta which is neither Lisp nor not Lisp).
while the optimizing compiler determines allocation methods automatically for the other objects.
It's really more about ``when is the earliest I can provably safely deallocate something?''. The only difference I can think of in the allocation method is if you want to do stack allocations instead of heap.
Name:
Anonymous2013-11-19 23:25
>>10 There is stack allocation versus heap allocation. But then there is also heap allocation where container deletes children when container is freed, reference counting where container removes references counts on children when the container is freed, and then more general garbage collection where the container just removes its links to its child objects when freed and the lifetime of the children are processed by the gc. And maybe there are more. That's all I can write off the top of my head.
But obviously, this doesn't work too well when you have a language that allows programmers to skip close_reference, or to take pointers in any other method than from creation or copy_reference, etc. Sepples tried something like this with RAII, but I wouldn't exactly call Sepples a model of perfection for that. So in order to create this model as a usable language, I think C-ish syntax would have to be thrown away.
Not quite. Rust enforces this through the type system.
A couple nights ago I was looking over the UEFI spec, and I realized it shouldn’t be too hard to write UEFI applications in Rust. It turns out, you can, and here I will tell you how. The thing that surprises me most about UEFI is that it now appears possible to boot your machine without ever writing a single line of assembly language.
Neuron pathways that aren't used "shrink", forming less and less connections over time, being activated less, consuming less resources, and eventually they are entirely relocated.
The brain also performs synaptic pruning[2] from the time you are born until after puberty, to select the most efficient configuration that will require minimal GC.
>>21 I'd love to implement a system where data that fell off too many levels of cache was simply thrown away. Got a circular reference dependency? No fucking problem! Haven't accessed this table of the first 100 million primes in 3.2 seconds? Well, it would probably be easier to regenerate them than to keep them around much longer! Lost data that was obtained from user input? Ask the user to repeat themself.