Garbage collection, really?

Archive
#1

We’ve been using the .Net Micro framework and Gadgeteer hardware for about 6 months now developing an oceanographic instrument platform that has to run completely unattended for years at a time. The whole .Net Micro/Gadgeteer ecosystem has proven really effective (but not without it’s own set of frustrations like why is it so damn hard to figure out what assemblies we need to reference for some library calls and why are some string operations intolerably slow?).

However, I digress. My real question is given that Gadgeteer hardware is intended for embedded applications, which implies at least a minimal level of deterministic response for many applications, doesn’t it make sense to be able to turn off Garbage Collection if we’re willing to accept the responsibility for managing memory in our own application? As far as I can tell this isn’t possible with the current development environment but is it possible it may be an option in the future?

I’ll be interested to hear other, more experienced, opinions.

Cheers - Gene

#2

GC is a fundamental part of the .Net It would be really hard to do what you are suggesting.

There are options available thought, if you are willing to build your own firmware.

#3

The first caveat of the Micro Framework is it is NOT real time.

C# has no delete keyword. Garbage collection is the analysis of current objects to determine which no longer have an active reference to them. These objects are then disposed and the memory freed. This can happens a “long” time after the object is no longer active.

“Minimally” deterministic is open to definition. If you are careful in the way you manage your objects, you can keeps GC to around 2-3 msec. That could be considered minimally deterministic.

If you allocate and release lots of objects, you are going to be hit by GC often. When I have a situation where GC could be a problem, I never release objects. I put them into a free queue, and next time I need one I get it from the free queue.

Manipulating strings will cause GC. If you must do a lot of string manipulation, then you might consider writing a custom mutable string class.

It is possible to tame GC, but it takes a lot of work.

#4

Thanks for the input. We actually have come to the same conclusions and results you have. With really careful attention to how we (more accurately, my colleague the software engineer who has suffered the vast majority of pain and agony on this project) use memory, he’s been able to keep the GC down in the several msec range.

My issue is more fear of the unknown. .Net Micro/Gadgeteer has proven incredibly effective for our engineering prototyping where determinism is not much of an issue. So effective we’re conducting an engineering experiment to see how effective it will be in our go-to-sea version. GC is probably the biggest unknown affecting the outcome of our little experiment and I would hate for our experiment to fail and be forced to drop back to our old development environment.

Anyway, thanks again for the input.

Gene

#5

@ Gene

MF is great for the right applications. It is not the solution to every problem. 1… 2… 3… I guess it was OK to say that. I was not hit by lightening. :slight_smile:

Good luck with your experiment.

#6

You can effectively “turn off” the GC by not allocating objects. It makes it difficult, and definitely reduces the appeal of the platform, but it’s certainly possible.

I believe Cuno posted on this very subject recently…?

#7

Yes, https://www.ghielectronics.com/community/forum/topic?id=12602&page=1.