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

121–130 of 157 posts

Re: Golang's big miss on memory arenas

#121

Post by srott »

pjmlp wrote: post #11
catigula wrote: post #5

>If you choose TypeScript or Python, you’ll hit a performance wall the moment you venture outside of web apps, CRUD servers, and modeling. This really isn't very accurate. It is for Python, but JavaScript is massively performant. It's so performant that you can write game loops in it provided you work around the garbage collector, which, as noted, is a foible golang shares. The solution is the same, to pre-allocate m…

Even Python is kind of debatable, if PyPy had a bit more of mainstream love.

What are the reasons why PyPy hasn't caught on? I know about PyPy for ages, but I still haven't given it a try, I still feel the aftertaste of anaconda...

Re: Golang's big miss on memory arenas

#122

Post by 0xjnml »

bilbo-b-baggins wrote: post #74

Man this person is mediocre at best. You can do fully manual memory management in Go if you want. The runtime is full of tons of examples where they have 0-alloc, Pools, ring buffers, Assembly, and tons of other tricks. If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. But like… the write up completely missed that manual memory management exists…

> If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type.

Only if the type is not a pointer per se or does not contain any inner pointers.

Otherwise the garbage collector will bite you hard.

Re: Golang's big miss on memory arenas

#123

Post by pjmlp »

srott wrote: post #121
pjmlp wrote: post #11

Earlier quoted context omitted.

Even Python is kind of debatable, if PyPy had a bit more of mainstream love.

What are the reasons why PyPy hasn't caught on? I know about PyPy for ages, but I still haven't given it a try, I still feel the aftertaste of anaconda...

The biggest issue has been that CPython exposes its internals to native libraries, thus since many Python libraries are actually thin bindings to native libraries, this reduces the interest in using PyPy.

There is now new ABI proposal that should work across Python implementations, proposed by PyPy, but the uptake seems slow.

https://discuss.python.org/t/c-api-working-group-and-plan-to...

https://doc.pypy.org/en/latest/extending.html

With a good enough JIT, the amount of native libraries wouldn't be needed to the extent it is..

Re: Golang's big miss on memory arenas

#124

Post by 9rx »

pjmlp wrote: post #108
9rx wrote: post #59

Earlier quoted context omitted.

They did. That is how they learned arenas are the wrong abstraction and why the project is now looking at memory regions instead.

Doesn't look like it, in the end it will be like generics, half way there.

Looks like the opposite of generics. Go's generics story is intrinsically linked to Java. It was the Java team that told the Go team to not implement generics until they were perfectly satisfied with the solution, and it was the same guy who ultimately designed both Java's and Go's generics. You cannot take a closer look at Java's generics than that.

Re: Golang's big miss on memory arenas

#125

Post by ncruces »

cafxx wrote: post #87
bilbo-b-baggins wrote: post #74

Man this person is mediocre at best. You can do fully manual memory management in Go if you want. The runtime is full of tons of examples where they have 0-alloc, Pools, ring buffers, Assembly, and tons of other tricks. If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. But like… the write up completely missed that manual memory management exists…

> If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. A word of caution. If you do this and then you store pointers into that slice, the GC will likely not see them (as if you were just storing them as `uintptr`s)

You need to ensure that everything you put in the arena only references stuff in the same arena.

No out pointers. If you can do that, you're fine.

Re: Golang's big miss on memory arenas

#126

Post by nu11ptr »

mappu wrote: post #92
nu11ptr wrote: post #50

A better route for something like Go IMO is to move to a compacting collector, this would allow them to move to a bump allocator like Java for super fast allocations and would make deallocation effectively "free" by only moving live objects. They may need to make it generational so they aren't constantly moving long lived objects, but that is a memory vs cpu trade off (could be one more GC flag?). If I recall, the pr…

Go exposes raw pointers to the programmer, and its current GC is entirely non-moving. Even excluding cgo, I think a moving one would probably break real programs that rely on pointer values.

True, I forgot about unsafe package. They would probably have to make it a Go 2 thing and add indirection to raw pointers or a need to "pin" them. Since pinning would already exist for CGo I suspect that would make more sense and wouldn't have performance penalty.

Re: Golang's big miss on memory arenas

#127

Post by pjmlp »

9rx wrote: post #124
pjmlp wrote: post #108

Earlier quoted context omitted.

Doesn't look like it, in the end it will be like generics, half way there.

Looks like the opposite of generics. Go's generics story is intrinsically linked to Java. It was the Java team that told the Go team to not implement generics until they were perfectly satisfied with the solution, and it was the same guy who ultimately designed both Java's and Go's generics. You cannot take a closer look at Java's generics than that.

Except the Go's implementation is not as capable as Java's one.

Phil Walder delivered a design within Go's team goals.

Java team has told nothing to Go's team, they have acknowldeged their bias anti-generics.

". They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."

https://go.googlesource.com/proposal/+/master/design/go2draf...

Re: Golang's big miss on memory arenas

#128

Post by 9rx »

pjmlp wrote: post #127
9rx wrote: post #124

Earlier quoted context omitted.

Looks like the opposite of generics. Go's generics story is intrinsically linked to Java. It was the Java team that told the Go team to not implement generics until they were perfectly satisfied with the solution, and it was the same guy who ultimately designed both Java's and Go's generics. You cannot take a closer look at Java's generics than that.

Except the Go's implementation is not as capable as Java's one. Phil Walder delivered a design within Go's team goals. Java team has told nothing to Go's team, they have acknowldeged their bias anti-generics. ". They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been wel…

> Except the Go's implementation is not as capable as Java's one.

I have no idea what you think is on the other side of that exception. Please clarify.

Re: Golang's big miss on memory arenas

#129

Post by zbentley »

0xjnml wrote: post #122
bilbo-b-baggins wrote: post #74

Man this person is mediocre at best. You can do fully manual memory management in Go if you want. The runtime is full of tons of examples where they have 0-alloc, Pools, ring buffers, Assembly, and tons of other tricks. If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. But like… the write up completely missed that manual memory management exists…

> If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. Only if the type is not a pointer per se or does not contain any inner pointers. Otherwise the garbage collector will bite you hard.

Types with inner pointers add difficulty to be sure, but it’s still possible to use them with this pattern. You have to make sure of three things to do so: 1) no pointers outside of the backing memory; 2) an explicit “clear()” function that manually nulls out inner pointers in the stored object (even inner pointers to other things in the backing slice); 3) clear() is called for all such objects that were ever stored before the backing slice is dropped and before those objects are garbage collected.

Re: Golang's big miss on memory arenas

#130

Post by cafxx »

pjmlp wrote: post #111
cafxx wrote: post #86

There's a bunch of activity ongoing to make things better for memory allocation/collection in Go. GreenTeaGC is one that has already landed, but there are others like the RuntimeFree experiment that aims at progressively reduce the amount of garbage generated by enabling safe reuse of heap allocations, as well as other plans to move more allocations to the stack. Somehow concluding that "By killing Memory Arenas, Go…

That one is kind of interesting given the past criticism of Java and .NET having too many GCs and knobs. With time Go is also getting knobs, and turns out various GC algorithms are actually useful.

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).
Post reply on HN