Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Golang's big miss on memory arenas

avittig.medium.com

Post reply on HN
Print view View original

141–150 of 157 posts

Re: Golang's big miss on memory arenas

#141

Post by 9rx »

jshen wrote: post #138
9rx wrote: post #85

Earlier quoted context omitted.

> Go just isn’t the tool we thought for some jobs Go made it explicitly clear when it was released that it was designed to be a language that felt dynamically-typed, but with performance closer to statically-typed languages, for only the particular niche of developing network servers. Which job that needs to be a network server, where a dynamically-typed language is a appropriate, does Go fall short on? One thing tha…

Which dynamically typed languages perform like a statically typed language?

It says "more like", not "like". Javascript now performs more like a statically-typed language, as one example. That wasn't always the case. It used to be painfully slow — and was so when Go was created. The chasm between them has shrunk dramatically. A fast dynamically-typed language was a novel curiosity when Go was conceived. Which is why Go ended up with a limited type system instead of being truly dynamically-typed.

Re: Golang's big miss on memory arenas

#142

Post by kernal »

riku_iki wrote: post #49
kernal wrote: post #46

Earlier quoted context omitted.

java.lang.foreign.Arena

My understanding is that that arena allows you to allocate memory segments, but you can't do much with it, you can't allocate var or object on it like in C++ for example, so its almost useless.

https://docs.oracle.com/en/java/javase/21/core/memory-segmen...

Re: Golang's big miss on memory arenas

#143

Post by riku_iki »

kernal wrote: post #142
riku_iki wrote: post #49

Earlier quoted context omitted.

My understanding is that that arena allows you to allocate memory segments, but you can't do much with it, you can't allocate var or object on it like in C++ for example, so its almost useless.

https://docs.oracle.com/en/java/javase/21/core/memory-segmen...

That Arena is not integrated into language. You can't do something like:

var myObj = new(my_arena) MyClass();

Re: Golang's big miss on memory arenas

#144

Post by riku_iki »

pjmlp wrote: post #109
riku_iki wrote: post #49

Earlier quoted context omitted.

My understanding is that that arena allows you to allocate memory segments, but you can't do much with it, you can't allocate var or object on it like in C++ for example, so its almost useless.

You certainly can, as they were designed as JNI replacement, with the goal to fully support the C ABI of the host platform. You can either do the whole boilerplate manually with Panama set of APIs, or write a C header file and let jextract do the work of boilerplate generation.

> You certainly can

I am wondering if there is working code example, or this is just speculation?

Re: Golang's big miss on memory arenas

#145

Post by dontlaugh »

9rx wrote: post #85
sheepscreek wrote: post #80

Earlier quoted context omitted.

I personally loved using Go 8 years ago. When I built a proof of concept for a new project in both Go and Rust, it became clear that Rust would provide the semantics I’m looking for out of the box. Less fighting with the garbage collector or rolling out my own memory management solution. If I’m doing that with a lot of ugly code - I might as well use idiomatic Zig with arenas. This is exactly the point the author tri…

> Go just isn’t the tool we thought for some jobs Go made it explicitly clear when it was released that it was designed to be a language that felt dynamically-typed, but with performance closer to statically-typed languages, for only the particular niche of developing network servers. Which job that needs to be a network server, where a dynamically-typed language is a appropriate, does Go fall short on? One thing tha…

I don’t know about that, it was called a systems language when it came out. By any common usage of the term, it’s definitely not that.

Re: Golang's big miss on memory arenas

#146

Post by cafxx »

pjmlp wrote: post #136
cafxx wrote: post #130

Earlier quoted context omitted.

Not sure what you are referring to. There are no knobs involved in the things I mentioned (aside from the one to enable the experiment, but that's just temporary until the experiment completes - one way or the other).

The knobs are the values that can be given to GOGC environment variable. Also I kind of foresee they will discover there are reasons why multiple GC algorithms are desired, and used in other programming ecosystems, thus the older one might stay anyway.

Your previous message was referring to Go "getting" knobs, but GOGC has always been there.

The older GC algorithm won't stay, IIRC the plan is for it to be removed in 1.27 (it's kept for now just to give a fallback in case of bugs in the first release).

Re: Golang's big miss on memory arenas

#147

Post by pjmlp »

cafxx wrote: post #146
pjmlp wrote: post #136

Earlier quoted context omitted.

The knobs are the values that can be given to GOGC environment variable. Also I kind of foresee they will discover there are reasons why multiple GC algorithms are desired, and used in other programming ecosystems, thus the older one might stay anyway.

Your previous message was referring to Go "getting" knobs, but GOGC has always been there. The older GC algorithm won't stay, IIRC the plan is for it to be removed in 1.27 (it's kept for now just to give a fallback in case of bugs in the first release).

GOGC was introduced in Go 1.5, and I thought the problem was solved.

https://go.dev/blog/go15gc

> Go 1.5’s GC ushers in a future where stop-the-world pauses are no longer a barrier to moving to a safe and secure language. It is a future where applications scale effortlessly along with hardware and as hardware becomes more powerful the GC will not be an impediment to better, more scalable software. It’s a good place to be for the next decade and beyond.

Re: Golang's big miss on memory arenas

#148

Post by cafxx »

pjmlp wrote: post #147
cafxx wrote: post #146

Earlier quoted context omitted.

Your previous message was referring to Go "getting" knobs, but GOGC has always been there. The older GC algorithm won't stay, IIRC the plan is for it to be removed in 1.27 (it's kept for now just to give a fallback in case of bugs in the first release).

GOGC was introduced in Go 1.5, and I thought the problem was solved. https://go.dev/blog/go15gc > Go 1.5’s GC ushers in a future where stop-the-world pauses are no longer a barrier to moving to a safe and secure language. It is a future where applications scale effortlessly along with hardware and as hardware becomes more powerful the GC will not be an impediment to better, more scalable software. It’s a good place t…

> GOGC was introduced in Go 1.5

yes, that's quite literally what I meant by "GOGC has always been there". 1.5 was released 10 years ago, just 3 years after 1.0.

So to summarize: there is one knob (that has been there from basically the beginning), plus a second one (if you squint hard enough: GOMAXMEM), and absolutely no plans to add further ones, or to add alternative GCs.

Re: Golang's big miss on memory arenas

#149

Post by foobiekr »

bilbo-b-baggins wrote: post #77
foobiekr wrote: post #48

Earlier quoted context omitted.

Two big issues in Golang are that you can't actually build an arena allocator that can be used for multiple types in a natural way. The other is that almost no library is written in such a way that buffer re-use is possible (looking at you, typical kafka clients that throw off a buffer of garbage per message and protobuf). The latter could be fixed if people paid more attention to returning buffers to the caller.

You totally can build it using unsafe and generics. I’ve done it with mmap-backed byte slices for arbitrary object storage.

I have done the same; it's not natural to do it this way. Go should actually express an explicit mechanism to do this. When I did it, it felt exactly like trying to use epoll from Go: you can do it, it just feels like crap.

Re: Golang's big miss on memory arenas

#150

Post by pjmlp »

cafxx wrote: post #148
pjmlp wrote: post #147

Earlier quoted context omitted.

GOGC was introduced in Go 1.5, and I thought the problem was solved. https://go.dev/blog/go15gc > Go 1.5’s GC ushers in a future where stop-the-world pauses are no longer a barrier to moving to a safe and secure language. It is a future where applications scale effortlessly along with hardware and as hardware becomes more powerful the GC will not be an impediment to better, more scalable software. It’s a good place t…

> GOGC was introduced in Go 1.5 yes, that's quite literally what I meant by "GOGC has always been there". 1.5 was released 10 years ago, just 3 years after 1.0. So to summarize: there is one knob (that has been there from basically the beginning), plus a second one (if you squint hard enough: GOMAXMEM), and absolutely no plans to add further ones, or to add alternative GCs.

That would be since Go exists, literally.
Post reply on HN