Let Go also support manual memory management, a good or bad idea?

[tapi...@gmail.com]

For example, by adding two new built-in functions: alloc and free, garbage collector will ignore the memory allocated by alloc. The memory allocated by alloc must be freed by calling the free function manually.

This would relieve the burden of GC for some Go programs (such as games).

[Dan Kortschak]

This can already be done using C.malloc and C.free. You won't have
access to map types using a Cgo allocator, but then you wouldn't if
you had to allocate using built-ins either.

[Ian Lance Taylor]

On Sun, Nov 15, 2020 at 5:38 PM tapi...@gmail.com <tapi...@gmail.com> wrote:
>
> For example, by adding two new built-in functions: alloc and free, garbage collector will ignore the memory allocated by alloc. The memory allocated by alloc must be freed by calling the free function manually.
>
> This would relieve the burden of GC for some Go programs (such as games).

I think this is a misunderstanding of where GC time goes. If you can
store a normal Go pointer in memory allocated using the new alloc
function, then memory allocated by alloc must still be scanned by the
GC.

Ian

[tapi...@gmail.com]

@kortschak

I think there are many benefits by using a pure Go implementation than a CGO one.

It would be even better to reuse/expose the internal tcmalloc.

@Ian

How about forbidding manual allocated memory references normal pointers?

[Ian Lance Taylor]

On Mon, Nov 16, 2020 at 5:49 AM tapi...@gmail.com <tapi...@gmail.com> wrote:
>
> @Ian
> How about forbidding manual allocated memory references normal pointers?

I suppose I don't understand how to do that without being either
memory unsafe or being unexpectedly slow.

(If it's OK to be memory unsafe, then I don't think Go would be the
preferred language. Go provides hooks to permit unsafe memory use,
but it doesn't make them particularly easy to use. That is
intentional and I don't think we're going to change that.)

Ian

> On Sunday, November 15, 2020 at 9:23:54 PM UTC-5 Ian Lance Taylor wrote:
>>
>> On Sun, Nov 15, 2020 at 5:38 PM tapi...@gmail.com <tapi...@gmail.com> wrote:
>> >
>> > For example, by adding two new built-in functions: alloc and free, garbage collector will ignore the memory allocated by alloc. The memory allocated by alloc must be freed by calling the free function manually.
>> >
>> > This would relieve the burden of GC for some Go programs (such as games).
>>
>> I think this is a misunderstanding of where GC time goes. If you can
>> store a normal Go pointer in memory allocated using the new alloc
>> function, then memory allocated by alloc must still be scanned by the
>> GC.
>>
>> Ian
>

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/21159b26-4a56-455d-9665-b4f1eeaf8f33n%40googlegroups.com.

[Henry]

There is a very little performance benefit to manual memory management with today's hardware. Someone mentioned games earlier. Many games are written in languages with GC. C# and Java are among the most popular languages for game development. A number of games are written in C++ but many developers end up writing their own GC. Other than in micro-benchmark, I don't see performance (as in speed) as a valid reason for having manual memory management.

Performance consistency is perhaps a more valid reason for having a manual memory management. If you are developing a mission-critical or a safety-critical application where you cannot afford to have GC millisecond pauses popping up during certain important chain of events, then you need to micromanage your memory. You need to make sure that your software performs exactly in the production environment as it would during development. If you add multi-cores, multi-threading and parallelism into the mix, it becomes even harder to fix performance consistency down to milliseconds. I am not sure how much calling runtime.GC would help in these scenarios, but Go is ill-equipped for such situations. To be fair, the market for such software is small and they usually rely on specialized hardware which makes the ubiquitous C hard to beat.

It is good to have manual memory management in Go, but it is not essential. It is better to direct the time and energy towards improving the Go compiler and its generated code.