On 1 March 2010 21:34, Neil Davies
I don't know that hanging your hat on the deterministic coat hook is the right thing to do. The way that I've always looked at this is more probabilistic - you want the result to arrive within a certain time frame for a certain operation with a high probability.
That's where I would think the difference between hard and soft real-time lies, as I understand it. Of course, "real" hard real-time of course is practically impossible on modern hardware due to caches, branch prediction, out-of-order execution and such like.
There is always the probability that the h/w will fail anyway - you could even reason that the software taking too long is just a transient fault that clears - random (non-correlated - preferably a bernoulli choice) failures are OK, non-deterministic ones aren't. This probabilistic, low probability of being at the tail of timing, approach would give a lot more flexibility in any form of (say incremental) GC - you may not be able to bound the incremental steps absolutely but a strong probabilistic bound might well be more achievable.
The Garbage-First paper showed some promising but not spectacular successes in keeping the soft real-time goal. I don't know the correct numbers off the top of my head, but I think they missed the deadline in > 5% of the cases. I would assume that it should be < 1% if you want to treat it as a random failure. I understand that in a fault-tolerant systems you have to handle worse things than that, but you make assumptions about the likelihood of each kind of error (otherwise you may run into QoS issues). As Job and John have pointed out, though, laziness per se doesn't seem to be an issue, which is good to hear. Space leaks might, but there is no clear evidence that they are particularly harder to avoid than in strict languages. As Röjemo and Runciman put it: "By using heap profiles on a lazy language we find problems with lazy languages. Using it on a strict language we would find problems with strict languages too." [1] (very recommended paper, btw.) [1]: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.1219 -- Push the envelope. Watch it bend.