Saving a Third of Our Memory by Re-Ordering Go Struct Fields (2020)

Re:Saving a Third of Our Memory by Re-Ordering Go Struct Fie... by pjmlp on Monday January 10, 2022 @05:54AM (#29872947)

Swift is one of the few AOT compiled languages where they went the extra mile to ensure some kind of ABI compatibility across language versions, Go just did the usual stuff and no guarantees are given.

As for the documentation,

Check -dynlink and -shared on "go compile"

https://pkg.go.dev/cmd/[email protected]

Also -buildmode and -shared on "go link"

https://pkg.go.dev/cmd/link#hdr-Command_Line

You can either create a dynamic linked package, that will dynamically link with other Go compiled code (from same toolchain), or expose a C ABI from a Go compiled .so (which may or may not include the runtime as well).

As for one possible example,

https://www.ardanlabs.com/blog/2020/07/extending-python-with...

[ Parent | on HN ]

Re:Saving a Third of Our Memory by Re-Ordering Go Struct Fie... by Joker_vD on Monday January 10, 2022 @06:19AM (#29873136)

Huh. So it's basically undocumented w.r.t. the actual implementation details, I was mostly interested in how they manage to bolt interfaces onto structs when they're separately compiled: e.g. if libFoo.so has "struct Foo {}" and "func (x Foo) Frob() { ... }" in it, and if libFrob.so has "interface Frobber { func Frob() }", and then they're linked together to the main application, will Foo actually implement Frobber? If yes, how?

[ Parent | on HN ]

Re:Saving a Third of Our Memory by Re-Ordering Go Struct Fie... by pjmlp on Monday January 10, 2022 @01:33PM (#29879273)

I guess that is the whole point of not having a stable ABI, you also won't find much documentation how C++ compilers do it, beyond reading the code.

[ Parent | on HN ]