On Wed, Aug 22, 2018 at 8:20 AM, 'Florian Uekermann' via golang-nuts
wrote:
> On Tuesday, August 21, 2018 at 7:31:28 AM UTC+2, Keith Randall wrote:
>>
>> There is no conservativeness to unsafe.Pointer. The type information for
>> any object in the heap is recorded at allocation time, and is unrela
On Tuesday, August 21, 2018 at 7:31:28 AM UTC+2, Keith Randall wrote:
>
> There is no conservativeness to unsafe.Pointer. The type information for
> any object in the heap is recorded at allocation time, and is unrelated to
> the type of the reference currently held to it (be it unsafe.Pointer,
There is no conservativeness to unsafe.Pointer. The type information for
any object in the heap is recorded at allocation time, and is unrelated to
the type of the reference currently held to it (be it unsafe.Pointer,
[]byte, *int64, or whatever).
So for 2.2, the answer is no, you are incorrect.
That information is old now - Go has a precise GC now. There is some sort
of metadata stored for each variable related to whether the type contains
pointers (as Jan alluded to earlier in the thread).
On Monday, August 20, 2018 at 7:28:51 AM UTC-7, Florian Uekermann wrote:
>
> From the GC POV, th
>
> From the GC POV, the only interesting thing about an unsafe.Pointer is if
> its value falls anywhere into a GC managed memory block for liveness
> analysis, AFAIK.
>
And then it will check that memory block for stuff that looks like a
pointer (not caring what the actual type being pointed t
On Mon, Aug 20, 2018 at 3:48 PM 'Florian Uekermann' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
>> The garbage collector does not care about the values of items of a []T
when T is not a pointer type nor a type containing transitively any
pointers.
>
> Just to make sure I understand you
>
> The garbage collector does not care about the values of items of a []T
> when T is not a pointer type nor a type containing transitively any
> pointers.
>
Just to make sure I understand you correctly. Are you saying I could hold
an unsafe.Pointer to an array of uint64 and the GC will still
On Mon, Aug 20, 2018 at 2:49 PM 'Florian Uekermann' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> ... which would put unnecessary strain on the GC iirc, because the memory
pointed to would be scanned conservatively (basically assuming everything
in there could be a pointer).
The garbag
Thanks Axel.
Good to know the first part. I have a couple of comments regarding your
answer to the second part.
In regards to your second question: That would require having an array type
> for every possible size, which isn't really tenable.
>
The idea was to use the same array type (`[(^uint
I'm not 100% sure, but… pretty sure? that the GC does not look at the
len/cap fields of slices. Reason being that that would require significant
alias-analysis, as two slices of the same underlying array can have
different lengths and capacities. So treating the underlying array not as
"one object"
Mistake in the second struct. The data field should have the type:
*[(^uint(0)) >> 17]uint64
--
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
11 matches
Mail list logo
