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.
