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
On Mon, Nov 16, 2020 at 5:49 AM 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
@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?
On Sunday, November 15, 2020 at 9:23:54 PM UTC-5 Ian Lance
On Sun, Nov 15, 2020 at 5:38 PM 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
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.
On Sun, 2020-11-15 at 17:37 -0800, tapi...@gmail.com wrote:
> For example, by adding two new built-in functions: alloc
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).
--
You
