On Fri 11 Aug, Byron Hale wrote:
> I don't mean that threads are non-deterministic, but that the execution
> time of a GC thread seems to be non-deterministic. Large collections need
> more time than small ones and the time required is some function of the
> store to be collected, is it not?
Sort of, but I think it depends what you mean by non-deterministic.
If you mean you don't know exactly how long garbage collection will take,
or when and how often it will occur, then I agree with you.
This probably is a serious problem for 'real time' systems, but not all
embedded applications are 'real-time'. (Those written in Erlang presumably
aren't, for example.)
> If the store to be collected is created
> at a greater rate than it can be collected, then a garbage-collected system
> would seem to be be expected to crash eventually.
Yes, I think this is by far the biggest problem for any system which is
required to be robust. Conking out do to lack of heap space may be
acceptable (though undesirable) on a PC or workstation, but for most
real world applications this is unacceptable.
> ML-Kit has implemented some work on compile-time memory management using
> regions. I wonder if that might not be more practical than garbage
> collection, in real-time systems.
I've had a quick look at this. I would say that the approach taken is
good from the point of view of saving time, but unless I'm missing something,
there is still the problem of ensuring that the program will run in
bounded space if you use the 'infinite' regions (as it seems you must
for recursive data types). It seems it's still pretty much the programmers
responsibility to ensure this. But seeing as ML is strict, it's probably
much easier for the programmer to get this right than it would be in Haskell.
Regards
--
Adrian Hey
