Thanks for your informative reply.
Compl
On Friday, September 21, 2018 at 8:19:01 AM UTC+8, Keith Randall wrote:
>
> 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.
