1. No. Go will never scan objects outside of the Go-allocated heap. That
includes mmap'd memory.
That means you can't have pointers from such memory into the Go heap.
Pointers within the mmap'd area are fine.
> that also means no regular Go pointer should be defined into such structs
Right.
On Wednesday, September 19, 2018 at 7:39:33 PM UTC-7, Compl Yue wrote:
>
> Hi Gophers,
>
> I'm new to Go and excited by it's elegancy and potentials :D
>
> I'm investigating into the Go way to serve massive structured data which's
> backed by few huge files mmap-ed.
>
> As I researched so far, boltdb has done similar things pretty successful,
> but it received criticism about its transactional performance, so I wonder
> if it is be coz of poor GC interactions (besides global write locking), and
> searched the actively maintained bbolt codebase, I found no GC related
> coordination code.
>
> I read about in this group, that GC will scan memory with missing runtime
> type for any words look like pointers, as to be `conservative`, so I came
> to the question:
>
> 1. If a regular `*struct{...}` pointer is obtained via
> `unsafe.Pointer()` by reinterpreting a `[]byte` offset from mmap-ed
> memory,
> obviously it has no runtime type info from Go allocator, then will it
> invoke GC to scan the bytes it points to ?
> 2. And if 1.=> True, will GC treat pointer-like words within the
> struct as Go pointers thus keep pointed-to object alive ?
>
> If both 1. and 2. are True, then those structs living in mmap-ed memory
> can fully function as Go objects (i.e. with pointer fields), but I worry
> about too much performance impact will limit number of such pointers to be
> held at runtime, then Go pointers need to be reinterpreted on-demand, from
> offsets on-the-fly, at last not easily be correct to hold pointer fields.
>
> So I hope 1.=>False then intensive use of such pointers causes no
> performance penalty, but that also means no regular Go pointer should be
> defined into such structs. I think boltdb did this and I can live with it.
>
> Thanks with best regards,
> Compl
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
