4 ms·

Pretty neat, go is now written in go "Go 1.5 has no C code in the tool chain or runtime.", go shared libraries interoperable with c. I'm really a go tinkerer,

Pretty neat, go is now written in go "Go 1.5 has no C code in the tool chain or runtime.", go shared libraries interoperable with c. I'm really a go tinkerer, but I like the langauge. I didn't realize Garbage Collection was so expensive that the goal is to only have it run 20% of the time. But its a good goal. "Run Go application code for at least 40ms out of every 50ms."

dbaupp 11y ago
That goal is referring to latency spikes. GC is usually much less than 20% of the time on average, but it may take, say, 200ms in one go and then run for 2 seconds without another collection. It seems their goal is to ensure there's no large pauses like that, so the 200ms would be spread across the 2 seconds as smaller time slices instead.
danieldk 11y ago
go shared libraries interoperable with c. How does this work? As far as I understand Go is moving to a copying collector, so any pointers passed to C may become wild pointers when garbage collection is performed. On go-nuts, Go's developers have been warning that passing arrays to C by getting the address of the first element of the slice will be unsafe for this reason.
- Daemon404 11y ago
  Dang, I always figured that would be unsafe eventually. I wonder, does this make stuff like this unsafe: var thing C.thing; C.somefunc(&thing) i.e. can stack address change now?
  - danieldk 11y ago
    The Go spec does not contain the stack or heap, so I guess that in principle it's fair game for the collector to relocate it in memory. In some future version it's only safe to use memory in C-land that was allocated in C-land.
    - AnimalMuppet 11y ago
      Wouldn't it be safe to use in C-land as long as you kept a reference to it in Go-land? Something like: Create memory in Go-land Use memory in C-land Dispose of reference to memory in Go-land That becomes a bit problematic if the C-land use is for a long-running process - you need a go object that owns the memory that has a lifetime that (at least) matches the lifetime of the C code execution.
      - danieldk 11y ago
        Currently, yes. Once Go has a moving garbage collector (soon-ish), no. A moving garbage collector can move objects around. This would invalidate pointers in C, since the GC can run concurrently with C code (even if it didn't, it would invalidate pointers to object allocated in Go in C structs). To make things work, you have to allocate date used in C in C and pass Go variables only by value.
- blt 11y ago
  some GC languages pause garbage collection while calling out to native code. under this scheme it's no problem to call C to do something like multiply matrices or compute hash functions. the problems come when you want the C code to call back into GC code, for example an event loop or a huge computation that wants to report its progress. it's hard. mixing manual and automatic memory management is tricky.
Kurtz79 11y ago
I actually was expecting it to have a greater hit on performance. After all, a go executable can be 2x - 8x slower than a C one (which is still good enough for many uses).

dbaupp 11y ago

That goal is referring to latency spikes. GC is usually much less than 20% of the time on average, but it may take, say, 200ms in one go and then run for 2 seconds without another collection. It seems their goal is to ensure there's no large pauses like that, so the 200ms would be spread across the 2 seconds as smaller time slices instead.

danieldk 11y ago

go shared libraries interoperable with c. How does this work? As far as I understand Go is moving to a copying collector, so any pointers passed to C may become wild pointers when garbage collection is performed. On go-nuts, Go's developers have been warning that passing arrays to C by getting the address of the first element of the slice will be unsafe for this reason.

Daemon404 11y ago
Dang, I always figured that would be unsafe eventually. I wonder, does this make stuff like this unsafe: var thing C.thing; C.somefunc(&thing) i.e. can stack address change now?
- danieldk 11y ago
  The Go spec does not contain the stack or heap, so I guess that in principle it's fair game for the collector to relocate it in memory. In some future version it's only safe to use memory in C-land that was allocated in C-land.
  - AnimalMuppet 11y ago
    Wouldn't it be safe to use in C-land as long as you kept a reference to it in Go-land? Something like: Create memory in Go-land Use memory in C-land Dispose of reference to memory in Go-land That becomes a bit problematic if the C-land use is for a long-running process - you need a go object that owns the memory that has a lifetime that (at least) matches the lifetime of the C code execution.
    - danieldk 11y ago
      Currently, yes. Once Go has a moving garbage collector (soon-ish), no. A moving garbage collector can move objects around. This would invalidate pointers in C, since the GC can run concurrently with C code (even if it didn't, it would invalidate pointers to object allocated in Go in C structs). To make things work, you have to allocate date used in C in C and pass Go variables only by value.
blt 11y ago
some GC languages pause garbage collection while calling out to native code. under this scheme it's no problem to call C to do something like multiply matrices or compute hash functions. the problems come when you want the C code to call back into GC code, for example an event loop or a huge computation that wants to report its progress. it's hard. mixing manual and automatic memory management is tricky.

Kurtz79 11y ago

I actually was expecting it to have a greater hit on performance. After all, a go executable can be 2x - 8x slower than a C one (which is still good enough for many uses).