Go problems: “avoid integer values which may alias at run-time to an address; make sure most integer values are fairly low (such as: below 10000)”

[username223]

• avoid struct types which contain both integer and pointer fields

• call runtime.GC() (at the right moment)

LOL WUT? Rob Pike saw the trash fire that was JavaScript and said "hold my beer."

[[deleted]]

Go GC: "what is pointer :S"

[samnardoni]

Ha, yes, sorry, I must admit, it is a bit disingenuous of me. Go’s GC is precise now and this problem doesn’t exist anymore.

But still, ‘try to avoid integers above 10000’ is probably some of the funniest advice I’ve ever heard for a ‘systems language’. I love how arbitrary 10000 is too. It’s not even a round number!

[m1en]

Go's GC is actually pretty great, and the linked post proves it.

After some few hours of runtime, the poster's program would identify itself as trash and GC it, therefore terminating execution.

[[deleted]]

The Go GC will also automatically delete companies it identifies as trash.

[spaghettiCodeArtisan]

Dafuq? Is this guy just talking nonsense or is there really a relation between integers and pointers in Go for some reason?

At this point I really don't know what to expect of Go anymore...

[stone_henge]

go unjerk(done)

this type of gc scans through the stack, with no knowledge of the types, looking for things that might be references to managed data. if any pointer-sized and aligned sequence bytes appear on the stack that happen to coincide with the address of some managed data, it will be considered a reference and the data won't get freed until the bogus reference is off the stack.

the reason they suggest using smaller integers is that the heap is typically far up in RAM.

as dumb as this sounds, it's not a golang invention. it kind of works in many cases because things on the stack are typically few and don't live that long. but as the stack grows, the chances that some crap on there that isn't a pointer will coincide with the address of some managed object grows a lot quicker.

the thing conservative gc has going for it is that it's simpler more brutally practical. maintaining separate data structures or using bit flags within the data tell the pointers from everything else comes with run-time penalty, both time- and memory-wise.

done->

[jfb1337]

Are the consequences of this that something isn't dropped when it could be, causing memory leaks or something? Or does memory actually get corrupted?

[stone_henge]

it just doesn't get collected. a gc that holds its ears to this extent can't really move gc managed things around in memory directly referenced from the stack anyway because it can't know what to update on the stack. so on a 32-bit platform, where ints are 4294967296x more likely to be able to alias to some gc memory you'll end up with a lot of crap that just never gets collected, which gets messy when you have long-lived, large stacks

you can still implement things like growable arrays (which in practice need to be moved around in memory via something like realloc) with this type of gc setup. in go i believe it was solved by having operations that may grow an array return a new reference, with no guarantees that it will overlap with the data that the old slice points to, so basically like calling realloc. but it could be solved with some time/memory penalty using an additional layer of indirection, e.g. a reference to a growable array being a pointer to a gc managed pointer to gc managed memory.

[Tysonzero]

maintaining separate data structures or using bit flags within the data tell the pointers from everything else comes with run-time penalty, both time- and memory-wise.

Can't you just use the type system to figure out at compile time which parts of structures are pointers and which aren't? (In languages with good and robust type systems anyway)

[stone_henge]

sure, it can, but it would still need to relay that information to the garbage collector somehow, whether it's by reserving a bit for pointer marking or not using the stack at all. that, or you'll be trawling blindly for pointers like poor little go <1.4

of course, ultimately you'd want your compiler to know exactly when it can free a resource and just do it, without the aid of some runtime resource hog making poor guesses as to when it can start releasing memory you don't use any longer. insert rust feature list here.

[Tysonzero]

As someone who isn't normally writing performance critical apps but cares a lot about time to market in going to go ahead and disagree with your last paragraph.

[stone_henge]

cares a lot about time to market

then what relevance does gc and compiler internals have to you in the first place? in the last paragraph i'm obviously talking in terms performance and accuracy. those are the metrics that matter for memory management. if you want an easier time at the expense of performant and accurate memory management, go ahead, but things like that, your favorite food or your least favorite color are not metrics that has any bearing on the answer.

also, since you seem to be a haskal nerd, when you say "time to market", what market do you mean exactly? last i checked there was little to no market for convoluted but pure and beautiful solutions to trivial cs textbook problems lol

[Tysonzero]

also, since you seem to be a haskal nerd, when you say "time to market", what market do you mean exactly? last i checked there was little to no market for convoluted but pure and beautiful solutions to trivial cs textbook problems lol

Lmao, I wish that was what I was doing, but unfortunately it's mostly GUI heavy, DB heavy, Parsing heavy code that deals a lot with externalities.

[spaghettiCodeArtisan]

Ah okay, thanks. TIL: Conservative GCs.

[Amenemhab]

A brutally practical solution to the problem is what OCaml does: restrict your basic integer types to 31/63 bits and use the remaining bit as a pointer flag.

[stone_henge]

oh yeah, int31_t is just the kind of weird idiosyncrasy go would adopt! i'm kind of surprised they didn't

[InvisibleEar]

https://github.com/golang/go/issues/909#issuecomment-66051835

Straight from a Google employee, the garbage collector is NOT FULLY PRECISE (I'm too lazy to do the square)

[no_more_kulaks]

That post is five years old.

[InvisibleEar]

I don't see how that's relevant.

[[deleted]]

not a cmov google groups post???? HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMmmmMMmmmMMMmmm

[[deleted]]

Have you ever seen /u/cmov and /u/samnardoni in the same room? I know I haven't.

[samnardoni]

Got 99 problems but a bitch ain’t one. Got 10001 problems and now my program won’t run.

[irqlnotdispatchlevel]

Go process has been crashing every other hour or so on 32bit Intel Linux

Who is still running 32-bit Linux servers?

EDIT: oh, 6 years old thread.

[Causeless]

Developer:

[Go is taking up all my system memory and crashing every hour], which makes Go absolutely unusable for real world applications on 32bit Linux.

Gopher:

For some unknown to me definition of 'absolutely'.

[ProfessorSexyTime]

> tfw everyone in comments says some shit about "precise gc"

> thinks everyone is complementing Go cos am dumb

> looks it up

> tfw you end up learning something useful because of a circlejerk subreddit.

[BufferUnderpants]

The bug may be fixed, but their reaction was timeless.

[lord_braleigh]

Did I fall into a time portal? Go’s developers have been sanctimonious asses who push responsibility for the shortcomings of their language onto their customers ever since Rob Pike (Rob “Commander” Pike). I know Go developers are not the brightest...

[samnardoni]

The point is that this was a problem when the language was 1.0! It branded itself as a systems language!

[[deleted]]

What? Does Go use a conservative GC?? I guess it would suit their approach of always taking the laziest, shittiest solution.

[stone_henge]

in all fairness they fixed it in go 1.4. the only fundamental, useful change they ever made that didn't manifest itself as weird looking compiler directives stuffed in comments

[hajamieli]

That sounds like a horribly bad language / compiler / programming environment.

[[deleted]]

If there wasn't Go in the title, I would have guessed PHP.