Garbage collection in Embedded system

Un bel giorno embedded_guy digitò:

As far as I know, garbage collecting is explicitly forbidden by most coding standards for real-time systems (the first that comes to mind is MISRA).

ng

I am sure real-time safe gc has been invented many times over. Perhaps the framers of that injunction were thinking of particular unsuitable implementations.

Un bel giorno toby digitò:

Coding standards have to consider general cases and statistical failures, their purpose is to avoid practices that in general have proven to be less safe than others. Garbage collecting and dynamic memory allocation are both practices that are prone to subtle coding and runtime errors (or at least more prone than others); thus, they have considered safer to avoid them in general.

In article , dalai lamah writes

Where does MISRA ban garbage collection?

Un bel giorno Chris Hills digitò:

I've checked out, actually there isn't any MISRA rule that explicitly bans garbage collecting. However, garbage collection by using memory de/allocation is forbidden by the rule that forbids dynamic heap memory allocation; even if you use static allocated structures, you are subjected to the rules regarding explicit pointer casts and pointer arithmetic (and probably others about scope/visibility that I don't remember). I have no idea if a MISRA-compliant software garbage collector exists or not, but I have doubts.

However, to answer to the OP question (MISRA was a little detour), I've found a document that could interest him:

A few years back I was looking at an implementation of embedded Java. Apparently the company, NewMonics

The product was called PERC. ISTR that at the time the designer of PERC had some white papers out about real-time garbage collection. Happy digging!

oding

)=2E

th

Permanently solved by a single tested library.

Hmm, explicit memory allocation and deallocation are prone to subtle coding and runtime errors; perhaps it should be considered safe to avoid them in general.

Granted, there are people that would strongly advocate a coding standard that forbids all general memory allocation. Ie, preallocate during program startup, use memory pools, etc. But many projects do need to deal with more general purpose dynamic memory allocation.

I think programmers are often prone to superstitions. That is they may follow rituals and techniques that may have served a valid purpose in the past but which are pointless now. For instance, "always type 'sync' twice before rebooting".

I think aversion to garbage collection based memory management fits into the category of superstition also. Part of the problem is that garbage collection was indeed slow in the past, and is most likely slow on the sorts of systems that many people run across. Ie, college programming assignments in Lisp on overloaded time share systems in the eighties, or seeing the garbage collection message in Emacs.

Incremental garbage collectors have been around for ages, and are compatible with real time requirements in that you can control just how much time will be spent during each quantum of collection. Smalltalk is being used for real-time and embedded applications.

-- Darin Johnson