4 ms·

Go doesn't allow you to switch off the GC on critical code sections. The switch-off is only for debug/dev purpose.

pjmlp 9y ago
True, Go still needs some help, but there are ways even with the current set of language features. 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.
- themihai 9y ago
  >> manually managing memory at Go level 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.
  - pjmlp 9y ago
    Sure it does, you just have to do it like in the good old days. 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.

True, Go still needs some help, but there are ways even with the current set of language features. 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.

themihai 9y ago
>> manually managing memory at Go level 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.
- pjmlp 9y ago
  Sure it does, you just have to do it like in the good old days. 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.