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.
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.