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

Go does not need a Java-style GC

erik-engheim.medium.com

Post reply on HN
Print view View original

141–150 of 226 posts

Re: Go does not need a Java-style GC

#141

Post by fh973 »

sam_bishop wrote: post #39
avita1 wrote: post #10

Cool article, I'm not sure I agree with the headline. I used to write low-scale Java apps, and now I write memory intensive Go apps. I've often wondered what would happen if Go did have a JVM style GC. It's relatively common in Go to resort to idioms that let you avoid hitting the GC. Some things that come to mind: * all the tricks you can do with a slice that have two slice headers pointing to the same block of memo…

Pooling objects (for the purposes of minimizing GC) is consider a bad practice in modern Java. The article suggests that compacting, generational collectors are a bad thing, but they can dramatically speed up the amount of time it takes to deallocate memory if most of your objects in a given region of memory are now dead. All you have to do is remove objects that are still alive, and you're done: that region is now a…

Does object pooling still make sense for direct ByteBuffers nowadays?

Re: Go does not need a Java-style GC

#142

Post by aktau »

hashmash wrote: post #35

The author doesn't really understand how Java escape analysis works, and just focuses on one key aspect: "It does not replace a heap allocation with a stack allocation for objects that do not globally escape." The author then implies that escape analysis is only used to reduce lock acquisition. Java escape analysis will replace a heap allocation with a stack allocation if the code is fully inlined. This is known as s…

I don't know much about this, but upthread various people say that scalar replacement happens very rarely if at all, currently. E.g.: https://news.ycombinator.com/item?id=29324132.

Could you perhaps comment on that, since you seem to have experience?

Re: Go does not need a Java-style GC

#143

Post by DeathArrow »

Lots of flaws in the article. Rust doesn't need a Java like GC because Rust doesn't have a need for GC. C# has pointers. "Old" languages like C and C++ also don't need a Java like GC, so it's not something related to "modern" languages.

Re: Go does not need a Java-style GC

#145

Post by winrid »

DeathArrow wrote: post #144

I like how memory management is done in Nim [1]. You can chose among several garbage collectors, manual memory management or no memory management at all, depending on what better fits your use case. [1] https://nim-lang.org/docs/gc.html

The default memory manager also won't do any stop the world pauses due to the way that cross thread communication works.

That's not to say the latest Java GCs aren't incredibly impressive - they are.

Re: Go does not need a Java-style GC

#146

Post by mayama »

sigmaml wrote: post #115
tossaway32 wrote: post #86

Earlier quoted context omitted.

Look at the Go benchmark program: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Needs to be faster? Use a pool like the C benchmark programs, but super simple: just a slice, local to the goroutine. Trivially make the Go program 10x faster, 5 minutes of work, a few edits: type Tree struct { Left int Right int } func itemCheck(id int, pool []Tree) uint32 { tree := &pool[id] if tree.Left != -1 && tree.…

Several (about 10) years ago, I submitted essentially the same program. It was one of the fastest of all the implementations across all the languages. However, Isaac rejected it, saying it violated the conditions.

Can this benchmark be written using sync.Pool mentioned in the article? If so, then that should be accepted since sync.Pool comes in stdlib.

Re: Go does not need a Java-style GC

#147

Post by legulere »

omnicognate wrote: post #132
pjmlp wrote: post #63

Earlier quoted context omitted.

Additionally he doesn't seem to know that much about C#, which also has advanced GC, while allowing for C++ like memory management, if needed.

C# makes it possible to do C (not C++) like memory management but it does not make it easy. Unsafe C# code is really, really, really unsafe, much more unsafe than equivalent C code, and does not compose well. It's improving, with Span/Memory, etc, but it remains an absolute last resort.

There's also ref which is almost like pointers and safe. Span/Memory do not remain an absolute last resort, they are becoming the standard way for string formatting/parsing/(de)serialization and IO.

Re: Go does not need a Java-style GC

#148

Post by pjmlp »

omnicognate wrote: post #132
pjmlp wrote: post #63

Earlier quoted context omitted.

Additionally he doesn't seem to know that much about C#, which also has advanced GC, while allowing for C++ like memory management, if needed.

C# makes it possible to do C (not C++) like memory management but it does not make it easy. Unsafe C# code is really, really, really unsafe, much more unsafe than equivalent C code, and does not compose well. It's improving, with Span/Memory, etc, but it remains an absolute last resort.

C and C++ memory managements are alike, C# doesn't need reference counted library types.

If you mean RAII, they can be easily done with IDisposable, using and Rosylin analysers that throw errors when usings are forgotten.

And yes, manually memory management should be last resource, proven by profiler data.

Re: Go does not need a Java-style GC

#149

Post by sigmaml »

lifthrasiir wrote: post #139
sigmaml wrote: post #115

Earlier quoted context omitted.

Several (about 10) years ago, I submitted essentially the same program. It was one of the fastest of all the implementations across all the languages. However, Isaac rejected it, saying it violated the conditions.

Of course. The problem description [1] specifically calls for the following: When possible, use default GC; otherwise use per node allocation or use a library memory pool. As a practical matter, the myriad ways to tune GC will not be accepted. As a practical matter, the myriad ways to custom allocate memory will not be accepted. Please don't implement your own custom "arena" or "memory pool" or "free list" - they wil…

My submission did violate the conditions. I was just recollecting what happened; it is not a complaint.

I am at variance with those conditions, though. I refer to the benchmarks suite itself, broadly. When programs dip into GMP, PCRE, etc., we are no longer comparing the speeds of the different language implementations per se. Now, they are mixed with FFI speeds of those implementations, the choices of the foreign language libraries/algorithms, etc..

In the same vein, as you remark in your second footnote, for a fair comparison, the same algorithm should be used in all programs. That will shed light on the strengths and weaknesses of the different language implementations better. I don't intend to say that the current system is useless; I am saying that using the same set of algorithms is likely to be more illustrative.

Re: Go does not need a Java-style GC

#150

Post by omnicognate »

legulere wrote: post #147
omnicognate wrote: post #132

Earlier quoted context omitted.

C# makes it possible to do C (not C++) like memory management but it does not make it easy. Unsafe C# code is really, really, really unsafe, much more unsafe than equivalent C code, and does not compose well. It's improving, with Span/Memory, etc, but it remains an absolute last resort.

There's also ref which is almost like pointers and safe. Span/Memory do not remain an absolute last resort, they are becoming the standard way for string formatting/parsing/(de)serialization and IO.

I didn't say Span/Memory are a last resort, I said C style memory management (AllocHGlobal/Free), despite being somewhat improved by Span/Memory, remains an absolute last resort. Span/Memory aren't primarily aimed at handling unmanaged memory, though they're useful for it.
Post reply on HN