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

Go: Severe memory problems on 32bit Linux

groups.google.com

Post reply on HN
Print view View original

141–150 of 159 posts

Re: Go: Severe memory problems on 32bit Linux

#141

Post by luriel »

blinkingled wrote: post #113
4ad wrote: post #112

Earlier quoted context omitted.

Again, this has nothing to do with physical memory. It only has to do with the virtual address space. Of course if you bump into this, it's a real leak, who said otherwise? And yes, it's possible to artificially generate the collision on 64 bit as it's the same mechanism as with 32 bit. It's about whether it happens frequent enough under normal usage patterns to be a concern. Youtube, and everybody who tried Go in pr…

Care to explain why? You keep insisting without explaining. Have you checked #C32 and how it clearly says it is a memory leak on both 32 and 64 bit platforms? What is your explanation as to why this is not a memory leak and only a address space leak? [EDIT POST YOUR UPDATE] Ok - so we are on the same page. I wasn't arguing about the likelihood at all - just the fact that it is possible troubled me as a bad GC design.…

It is possible to artificially fool any GC into leaking memory, only question is whatever it happens in practice.

In practice the Go GC never leaks memory on 64bit systems and for most programs never on 32bit systems either.

Re: Go: Severe memory problems on 32bit Linux

#142

Post by 0xABADC0DA »

4ad wrote: post #84
0xABADC0DA wrote: post #27

It's amazing how nonchalant they are about this 'oh sure we'll fix it in a year or so' when the garbage collector is basically all there needs to be in a Google Go runtime Some comments were asking why early Java's GC wasn't this bad even though it was conservative. The reason is that Java can't take references to fields of an object, so the data mistaken as a pointer has to actually point to an object header. In Goo…

It's not Google Go, it's simply Go, there's not a single Google reference on the web page and that's intentional. Looking at your previous posts here and on Reddit I see you are a notorious anti-Google troll that adds "Google" to "Go" so that your negative posts will be associated with both Google and Go. It's absurd to call it Google Go when there's a first class GNU implementation that has been in development from…

I suppose you fail to see the irony in complaining about me writing "Google Go" because "Go" is an unsearchable name and then answering how to search for it with a custom search engine, needed because the name is unsearchable. Not to mention that ctrl-f doesn't support regular expressions so no ctrl-f "\".

I only use that construction with ambiguous or unsearchable names (for instance I would also say Google Maps). I don't think I am along in using this form and I feel it is appropriate to refer to Google Go this way.

Frankly I fail to understand why this bothers you so much, as it clearly does. I would expect Google Go advocates to be delighted to have Google's good reputation for engineering imparted onto this language.

Re: Go: Severe memory problems on 32bit Linux

#143

Post by burgerbrain »

0xABADC0DA wrote: post #142
4ad wrote: post #84

Earlier quoted context omitted.

It's not Google Go, it's simply Go, there's not a single Google reference on the web page and that's intentional. Looking at your previous posts here and on Reddit I see you are a notorious anti-Google troll that adds "Google" to "Go" so that your negative posts will be associated with both Google and Go. It's absurd to call it Google Go when there's a first class GNU implementation that has been in development from…

I suppose you fail to see the irony in complaining about me writing "Google Go" because "Go" is an unsearchable name and then answering how to search for it with a custom search engine, needed because the name is unsearchable. Not to mention that ctrl-f doesn't support regular expressions so no ctrl-f "\ ". I only use that construction with ambiguous or unsearchable names (for instance I would also say Google Maps).…

The "clearing up ambiguity" thing is bullshit. Nobody is going to fail to use context clues to figure out what is meant by "Go" in this discussion. Where such disambiguation is actually needed, "Go (language)" or simply "go-lang"/"golang" is preferred. You know, since they are not incorrect.

"Frankly I fail to understand why this bothers you so much, as it clearly does."

It is annoying because it is incorrect, because you have been corrected multiple times, and because what you are attempting to do is transparent as hell. I, and I imagine many others, do not have a strong appreciation for botched attempts at subtlety.

Re: Go: Severe memory problems on 32bit Linux

#144

Post by 0xABADC0DA »

burgerbrain wrote: post #143
0xABADC0DA wrote: post #142

Earlier quoted context omitted.

I suppose you fail to see the irony in complaining about me writing "Google Go" because "Go" is an unsearchable name and then answering how to search for it with a custom search engine, needed because the name is unsearchable. Not to mention that ctrl-f doesn't support regular expressions so no ctrl-f "\ ". I only use that construction with ambiguous or unsearchable names (for instance I would also say Google Maps).…

The "clearing up ambiguity" thing is bullshit. Nobody is going to fail to use context clues to figure out what is meant by "Go" in this discussion. Where such disambiguation is actually needed, "Go (language)" or simply "go-lang"/"golang" is preferred. You know, since they are not incorrect . "Frankly I fail to understand why this bothers you so much, as it clearly does." It is annoying because it is incorrect, becau…

For instance:

http://www.cnn.com/2011/TECH/mobile/05/12/google.maps.androi...

Or:

http://en.wikipedia.org/wiki/Google_Maps

> It is annoying because it is incorrect

Maybe some English professor, technical writer, or journalist reading this can chime in and explain how so. It seems to be the standard practice and I intend to use the best grammar and construction that I am capable of, as bad as that may be. This isn't Twitter.

Re: Go: Severe memory problems on 32bit Linux

#145

Post by 4ad »

0xABADC0DA wrote: post #144
burgerbrain wrote: post #143

Earlier quoted context omitted.

The "clearing up ambiguity" thing is bullshit. Nobody is going to fail to use context clues to figure out what is meant by "Go" in this discussion. Where such disambiguation is actually needed, "Go (language)" or simply "go-lang"/"golang" is preferred. You know, since they are not incorrect . "Frankly I fail to understand why this bothers you so much, as it clearly does." It is annoying because it is incorrect, becau…

For instance: http://www.cnn.com/2011/TECH/mobile/05/12/google.maps.androi... Or: http://en.wikipedia.org/wiki/Google_Maps > It is annoying because it is incorrect Maybe some English professor, technical writer, or journalist reading this can chime in and explain how so. It seems to be the standard practice and I intend to use the best grammar and construction that I am capable of, as bad as that may be. This isn't T…

It's incorrect for the same reason Apple LLVM or Juniper FreeBSD is incorrect, and it's bullshit because in a thread about Go, people know what Go refers to.

FWIW, the Windows, Plan 9, OpenBSD and NetBSD ports were done entirely by the community.

AT&T C? That's even less specific than Go. What about gccgo? Google/GNU Go? What about the commercial implementations?

Re: Go: Severe memory problems on 32bit Linux

#146

Post by binarycrusader »

zvrba wrote: post #79

Interesting piece of information below in the thread: in reply to "Go being advertised as a systems PL", David Symonds replies with: "It's not. It used to be, but it's not any more."

Except, it still is advertised as one (or at least implied to be):

  "Go is a general-purpose language designed with systems programming in mind."
  http://golang.org/ref/spec#Introduction
You could nit-pick and say that it says "in mind", but the point still stands that they're trying to imply that it's suitable for systems programming. It is not; certainly not at the level of an operating system kernel, etc.

Re: Go: Severe memory problems on 32bit Linux

#147

Post by burgerbrain »

0xABADC0DA wrote: post #144
burgerbrain wrote: post #143

Earlier quoted context omitted.

The "clearing up ambiguity" thing is bullshit. Nobody is going to fail to use context clues to figure out what is meant by "Go" in this discussion. Where such disambiguation is actually needed, "Go (language)" or simply "go-lang"/"golang" is preferred. You know, since they are not incorrect . "Frankly I fail to understand why this bothers you so much, as it clearly does." It is annoying because it is incorrect, becau…

For instance: http://www.cnn.com/2011/TECH/mobile/05/12/google.maps.androi... Or: http://en.wikipedia.org/wiki/Google_Maps > It is annoying because it is incorrect Maybe some English professor, technical writer, or journalist reading this can chime in and explain how so. It seems to be the standard practice and I intend to use the best grammar and construction that I am capable of, as bad as that may be. This isn't T…

> http://en.wikipedia.org/wiki/Google_Maps

Yes, and then we see:

http://en.wikipedia.org/wiki/Go_(programming_language)

Give me a fucking break. You are clearly not worth engaging in discussion; I'm done.

Re: Go: Severe memory problems on 32bit Linux

#148

Post by petrohi »

ArbitraryLimits wrote: post #111
ghusbands wrote: post #87

Earlier quoted context omitted.

On 32-bit systems, the problem is that there's a very high chance of non-pointer data looking like pointers to existing data, which, in turn might have its own pointer-like data. This means that you can end up keeping an excessive amount of unreferenced data. However, a 64-bit address space is so much larger that you can't really suffer the same issue. Unlike on 32-bit systems, neither high entropy data nor text will…

Can someone help me out here with a TL;DR? This is my first exposure ever to any technical aspect of Go, and this discussion makes it sound from this discussion like it doesn't use any tag bits in its pointers, but has its garbage collector run heuristics on the data it examines to see whether it "looks like text" to decide whether to collect it? I know that can't possibly be correct.

Good explanation on wikipedia:

http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc...

Re: Go: Severe memory problems on 32bit Linux

#149

Post by complexmath »

moilolita wrote: post #69
el_muchacho wrote: post #63

Earlier quoted context omitted.

D is pretty strong at concurrency today. See for instance http://www.informit.com/articles/article.aspx?p=1609144 and http://ddili.org/ders/d.en/parallelism.html

It's strange that with all those threading examples, they didn't notice the need for a WaitGroup primitive. I know that you could implement it yourself. You could simulate the goroutines, implement channels and SCGI/FCGI and so on, but why bother when there is Go ?

Did you mean something like core.sync.barrier?

Re: Go: Severe memory problems on 32bit Linux

#150

Post by moilolita »

complexmath wrote: post #149
moilolita wrote: post #69

Earlier quoted context omitted.

It's strange that with all those threading examples, they didn't notice the need for a WaitGroup primitive. I know that you could implement it yourself. You could simulate the goroutines, implement channels and SCGI/FCGI and so on, but why bother when there is Go ?

Did you mean something like core.sync.barrier?

barrier is not a suitable primitive for a WaitGroup. The ideea is simple. You accept sockets in a loop and handle the connections in parallel threads.At one point you want to stop this loop and the main thread must wait for all the active threads to finish before exiting, otherwise some clients may receive "connection reset by peer". With a WaitGroup, every starting thread increments a counter, and every finishing thread decrements it;when the counter is zero -> all the threads finished.The main thread calls WaitGroup.Wait and it remains blocked until all the worker threads finish the jobs. I guess you could simulate it with core.sync.condition
Post reply on HN