If your embedded system is a Raspberry Pi 3 controlling a few leds or talking with something over UART or whatever, then it won't matter a whole lot whether you have a GC or not.
On the other hand, if your embedded system is a 50Mhz 8-bit microcontroller with a whooping 8KB of "RAM" (and 16KB of program memory) doing ~20k sensor reads per second, then it WILL matter.
They seem to be targeting armv7 and their reference device (Wanboard Quad) has a 1GHz clock and 2GB of ram, which is a monster compared to most embedded systems I've worked on.
That gives them plenty of cycles and memory to waste doing garbage collection, a luxury SOME of us can't afford.
Nowadays anything from 16kB to 2GB of RAM gets called "embedded". Storage is the same but x10.
I would be surprised if there's nothing to use Go for in all that design space, but generalizations are probably plain impossible.
And maybe it should. I think as far as software is concerned embedded development is not all that special anymore. Everything is running advanced ARM SoCs that have the same power you'd have on a workstation ~15 years ago.
It's still meaningful if you're working on electronics though, you generally have wildly different constraints regarding ECM, power draw, heat dissipation, environmental constraints etc...
Despite what the maker-movement and IoT-hype would have you believe, most embedded systems are not running Linux.
Bear in mind that the vast majority of processors sold these days are micro-controllers and go into things like electricity meters, light switches, alarm clocks, etc.... mundane stuff.
There's benefit for companies to do that too, developers who can work efficiently on an MMU-less bare metal/small RTOS system tend to be experienced and cost a lot. Now if you run Linux (or maybe even android these days) on your embedded product you can basically have any half competent junior coder develop on it without problem.
At the rate this is going I would only be half surprised if my electricity meter ran Linux in a decade, especially since the trend is into making "smarter" ones.
Also while Cortex-M are definitely more microcontroller-ish than the A versions they're still pretty impressive beasts compared to the microcontrollers of yore. They can run at frequencies on the order of hundreds of MHz, often come with advanced IPs like USB, ethernet, DMA and more. Maybe we should have an intermediate category for "millicontrollers".
MicroEJ is operating since 2004.
If they had practically zero customers, they would have closed doors by now.
Not always used tho.
Go has structs and defaults to avoiding boxed values. It also has escape analysis and tries to do stack allocation before putting objects on the heap.
Compared to Java, it is a lot easier to write your code in a way that minimises or even avoids generating garbage that has to be collected in the first place.
Have a look at Project Oberon, Mesa/Cedar at Xerox PARC, Modula-3 at DEC/Olivetti, Singularity/Midori at Microsoft
https://en.wikipedia.org/wiki/Oberon_(operating_system)
http://www.ocp.inf.ethz.ch/wiki/Documentation/Front
https://en.wikipedia.org/wiki/SPIN_(operating_system)
https://archive.org/details/bitsavers_xeroxparcteCedarProgra...
http://joeduffyblog.com/2015/11/03/blogging-about-midori/
https://www.infoq.com/presentations/csharp-systems-programmi...
All of them produced workable graphical workstations that were used for a couple of years until the projects were shutdown for political/monetary reasons.
Oberon GUI is the genesis how Plan 9/Inferno GUIs work, specially the ACME text editor.
For something with more constraints, Real-Time Java implementations are powering battleship weapons tracking systems, here two examples
http://www.military.com/equipment/aegis-weapon-system
http://www.marketwired.com/press-release/ibm-raytheon-delive...
Having said this, of course there are environments where not having a GC at all is a better approach for the use case being solved.
What many in the anti-GC crowd don't realise it that these GC enabled systems languages also allow to switch off the GC on critical code sections, or make use of manual memory management in unsafe code.
So it it not necessary to throw away the productivity to get the full benefit of performance, if the language offers the necessary knobs.
1 - Use a memory profiler to ensure the memory usage is kept on constant level;
2 - Reduce GC pressure by manually managing memory at Go level;
3 - If still not enough,
3.1 - if there is an OS underneath call its allocation/release APIs directly,
3.2 - running on bare metal, implement a manual allocator with a mix of package unsafe and Assembly for CPU register access
It is not the same as using untraced references in Modula-3, but it does the job.
Also I should note that even ANSI C requires use of Assembly in libc to implement malloc()/free() on bare metal.
What exactly do you mean? Go doesn't allow you to manage memory. At most you can give some hints to the compiler but they may or may not work depending on the compiler/version.
>> 3.1 - if there is an OS underneath call its allocation/release APIs directly, 3.2 - running on bare metal, implement a manual allocator with a mix of package unsafe and Assembly for CPU register access
That seems to require some patches to the runtime and compiler not to mention that you start to depart from what you might remember as being Go language/development. You create more problems to fix the GC problem. I believe a real solution would be an opt-in subset of Go using Rust-like memory model. Swift(Apple) seems to work on a such solution.
The easy way is to make use of object pooling via sync/pool.
The hard way is to declare a static array allocated as global variable in a package for the set of data that one needs to manage and make use of pointers to free slots.
What patches to runtime and compiler?
You are mixing up programming language and implementation.
There are no pure ANSI C compilers for bare metal programming, 100% of them require language extensions.
real-time == deterministic, and this is what GC is not. At all times you must know what code is able to execute in order to meet worst-case deadlines.
The easiest way of managing this is to disallow any non-deterministic processes in the real-time levels of your application (this means dynamic memory allocation and by inference also GC, but it also applies to anything else).
Also bear in mind that most hard-real-time systems are also safety-related and need high-reliability. systems are expected to stay running indefinitely (or at least for years) without a reset on systems with Kilobytes of RAM.
For these types of systems you work out your worst-case load and statically allocate everything. This makes it much easier to reason about.
Could you please tell some of them? thanks
- Engine management systems (e.g. timing of firing in an IC engine)
- Missile detection systems (e.g. need to react to a detection within time to activate countermeasures).
- Medical systems (e.g. timing of valve closing/opening is critical to dosage).
- Phone protocol stacks (e.g. transmitting during allocated time-slots).
- Metering systems (e.g. must read measurement devices at correct time to ensure accuracy).
- Audio systems (e.g. avoiding glitches requires deterministic processing)
...and lots, lots more.
In general, things that interact with the real physical world require deterministic control.
Nowadays partly written in Real Time Java, can gladly provide examples from military web sites.
Bear in mind that there are typically many levels to something like an ESM system, the lower levels would always be in something like C/C++/ADA (or possibly FPGA) but if Java does come into it, it would be for the UI but even that is more likely C# these days. This is not the RT level code.
Am I being too closed minded and a garbage collector that ran quickly enough would still allow for a useful design space?