Is it possible that a hybrid memory management could be implemented?

[tapi...@gmail.com]

For example, some local memory allocations could be detected no used elsewhere so that they can may be freed immediately when out of reach instead of waiting to be freed in the GC phase.

[Tyler Compton]

I may be misunderstanding what you're suggesting, but I believe Go already tries to detect when a value can be placed on the stack. Then, it will be freed automatically when it falls out of scope.

On Sun, Nov 15, 2020 at 5:20 PM tapi...@gmail.com <tapi...@gmail.com> wrote:

For example, some local memory allocations could be detected no used elsewhere so that they can may be freed immediately when out of reach instead of waiting to be freed in the GC phase.

--
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/5c38b239-fe56-44ce-aaf6-61636a682707n%40googlegroups.com.

[tapi...@gmail.com]

Aha, I forgot this fact. You are totally right.

It is a bad example. A better example: is it possible to detect that some values are always single-owner (and their out-of-reach time point are also detectable)?

[Robert Engels]

It is the same. If it can escape the allocation frame you need GC. 

On Nov 15, 2020, at 7:34 PM, tapi...@gmail.com <tapi...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7c7fcfde-14a3-4c6d-b53c-3c44f31d1568n%40googlegroups.com.

[陶青云]

FYI  

https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc/    

[Jan Mercl]

On Mon, Nov 16, 2020 at 11:14 AM 陶青云 <qing...@gmail.com> wrote:

> FYI
> https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc/

A CGo-free manual memory allocator might be a better fit sometimes:
https://godoc.org/modernc.org/memory

[tapi...@gmail.com]

Thank both the information. I do prefer pure-Go implementations.

In fact, it would be even better if the internal tcmalloc could be reused and exposed as builtin functions.

(BTW, it looks these should be more suitable to discuss in the other thread: https://groups.google.com/g/golang-nuts/c/o0VAKfCyKS4

This thread is intended to discuss other auto ways of memory management.)

[tapi...@gmail.com]

On Sunday, November 15, 2020 at 10:24:05 PM UTC-5 ren...@ix.netcom.com wrote:

It is the same. If it can escape the allocation frame you need GC. 

It could be viewed as advanced escape analyzing (by supporting run-time escape analyzing).

For example, a value might be used by many goroutines at run time,

but at any time point, it is only be used by one goroutine.

[Robert Engels]

Then you have reference counting or tracing GC. 

Tracing GC a which Go has - has been proven superior to reference counting. 

On Nov 16, 2020, at 8:02 AM, tapi...@gmail.com <tapi...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4b798d4e-269d-487c-a85a-835078c6625an%40googlegroups.com.

[tapi...@gmail.com]

On Monday, November 16, 2020 at 9:17:50 AM UTC-5 ren...@ix.netcom.com wrote:

Then you have reference counting or tracing GC. 

Tracing GC a which Go has - has been proven superior to reference counting. 

I feel there still room between the two to explore, though I have not a clear thought on this  yet.

[Jesper Louis Andersen]

On Mon, Nov 16, 2020 at 4:04 PM tapi...@gmail.com <tapi...@gmail.com> wrote:

I feel there still room between the two to explore, though I have not a clear thought on this  yet.

Many of the tricks tend to coincide with both allocator strategies as you work more on them. The methods are much more two sides of the same coin than they are different.

It is easy to have manually managed memory areas: just force a data copy in and out of said area whenever you access them. Then the pointer spaces can be kept separated from each other and you don't have to run GC for the data space. This is what Erlang's ETS system is all about (If you want a pointer, lookup Linda tuple spaces for an explanation). If you allow pointers to point between spaces, then you have to handle that in some way. One way is to keep forward sets of the pointers so you can handle them, but this is usually easier if you have generational GCs as they have to do this anyway for most languages (again, Erlang is the exception to the rule here).

I'm more inclined to believe that careful handling of memory in Go is more than adequate for handling a low latency scenario such as a game. If your target is 60fps, the 16.7ms window per frame should be rather easy to reach with the current GC, especially if you have some extra CPU resources to spare.

[Robert Engels]

Yes, Go’s lack of a generational collector can make moving certain large read only structures off heap make sense but a careful design of these structures (no pointers) often removes this need. 

On Nov 16, 2020, at 11:12 AM, Jesper Louis Andersen <jesper.lou...@gmail.com> wrote:



--
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/CAGrdgiVfZD-F9-5jyN5bdHPh64UZfBDUX4ooJuRjjaeS0zCj6A%40mail.gmail.com.