How garbage-collector considers unsafe.Pointer

[David DENG]

Some questions about unsafe.Pointer:

1. If an object is reference only be a unsafe.Pointer, will this object be collected?
2. If the fields of the object contain some pointers as well, how about those pointers, will they be collected?
3. If the answers are both NO, how does it do it? Does unsafe.Pointer save the type information internally?
4. If one of the answers is YES, it means the Pointer will be an illegal pointer, right?

Thanks!

David

[Ian Lance Taylor]

On Fri, Mar 1, 2013 at 2:18 PM, David DENG <david...@gmail.com> wrote:
> Some questions about unsafe.Pointer:
>
> If an object is reference only be a unsafe.Pointer, will this object be
> collected?

Yes.

> If the fields of the object contain some pointers as well, how about those
> pointers, will they be collected?

Yes.

> If the answers are both NO, how does it do it? Does unsafe.Pointer save the
> type information internally?
> If one of the answers is YES, it means the Pointer will be an illegal
> pointer, right?

I'm not sure what you mean by "illegal pointer" here. When the GC
sees an unsafe.Pointer, it collects the block to which it points
conservatively.

Ian

[John Asmuth]

Any unsafe.Pointer corresponds to a real pointer somewhere else - that is, you can't construct one without doing unsafe.Pointer(anotherPointer). Given that, I imagine the GC still treats things pointed to by unsafe.Pointer as valid references.

[David DENG]

For illegal pointer, I actually meant dangling pointers.

If so, it should be clearly pointed out in the document, I think. It seems not everybody thinks it in that way.

David

[Ian Lance Taylor]

On Fri, Mar 1, 2013 at 2:36 PM, David DENG <david...@gmail.com> wrote:
> For illegal pointer, I actually meant dangling pointers.
>
> If so, it should be clearly pointed out in the document, I think. It seems
> not everybody thinks it in that way.

Sorry, I'm still not sure what you are getting at.

Yes, you can construct a dangling pointer using unsafe.Pointer. Don't
do that. It's unsafe.

It won't break the GC, though. The GC will simply ignore a pointer
value that does not point into the GC heap area.

Ian

> On Saturday, March 2, 2013 6:26:18 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Fri, Mar 1, 2013 at 2:18 PM, David DENG <david...@gmail.com> wrote:
>> > Some questions about unsafe.Pointer:
>> >
>> > If an object is reference only be a unsafe.Pointer, will this object be
>> > collected?
>>
>> Yes.
>>
>> > If the fields of the object contain some pointers as well, how about
>> > those
>> > pointers, will they be collected?
>>
>> Yes.
>>
>> > If the answers are both NO, how does it do it? Does unsafe.Pointer save
>> > the
>> > type information internally?
>> > If one of the answers is YES, it means the Pointer will be an illegal
>> > pointer, right?
>>
>> I'm not sure what you mean by "illegal pointer" here. When the GC
>> sees an unsafe.Pointer, it collects the block to which it points
>> conservatively.
>>
>> Ian
>

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[⚛]

On Friday, March 1, 2013 11:18:36 PM UTC+1, David DENG wrote:

Some questions about unsafe.Pointer:

1. If an object is reference only be a unsafe.Pointer, will this object be collected?

 

If the unsafe.Pointer points to a Go object, the garbage collector will know about the object and the memory belonging to the object will not be freed.

The above does not apply if the memory pointed to by the unsafe.Pointer was allocated outside of Go (for example C.malloc).

 

2. If the fields of the object contain some pointers as well, how about those pointers, will they be collected?

If the garbage collector found the unsafe.Pointer, and the object was allocated by Go, the garbage collector will also traverse all pointers stored in the object.

 

3. If the answers are both NO, how does it do it? Does unsafe.Pointer save the type information internally?

In case the object was allocated by Go: there is no type information stored directly in the unsafe.Pointer itself. If the unsafe.Pointer points to a memory block allocated by Go, there usually is type information associated with the pointer. If the type information exists, it is stored in a place that belongs to Go's memory allocator.   If the type information does not exist, the garbage collector resorts to a conservative strategy (this means: the object will not be freed and the garbage collector will find all pointers stored in the object).

 

4. If one of the answers is YES, it means the Pointer will be an illegal pointer, right?

If a particular unsafe.Pointer has become valid at any point in time during the execution of a Go program, and it hasn't changed its value, then the Go runtime guarantees that it will stay valid until the end of the program. A direct assigment from one unsafe.Pointer to another unsafe.Pointer is always safe. Some indirect assignments between unsafe.Pointers are programming errors, so the programmer needs to be careful in such situations. Moving an unsafe.Pointer to a variable of type uintptr may be a programming error.

Go ignores any memory allocated by functions such as C.malloc. If C memory contains a pointer to Go memory, the program needs to make sure that the pointer is also stored in a Go variable, struct or array.

 

Thanks!

David

[David DENG]

Thanks for detailed reply!

But what you say is different from Lance, so is there any fragments in the official documents that my support the point.

For you replied, in 'a conservative strategy', how a compiler find the pointer in the object without knowing the type information?

David

[Ian Lance Taylor]

On Sat, Mar 2, 2013 at 4:17 PM, David DENG <david...@gmail.com> wrote:
>
> But what you say is different from Lance, so is there any fragments in the
> official documents that my support the point.

I think that we said essentially the same thing.

> For you replied, in 'a conservative strategy', how a compiler find the
> pointer in the object without knowing the type information?

By simply looking at each word in the object to see if it is a valid pointer.

Ian

[⚛]

On Sunday, March 3, 2013 1:17:09 AM UTC+1, David DENG wrote:

Thanks for detailed reply!

But what you say is different from Lance, so is there any fragments in the official documents that my support the point.

For you replied, in 'a conservative strategy', how a compiler find the pointer in the object without knowing the type information?

The runtime (not the compiler) knows the locations of all blocks that are allocated. In conservative garbage collection, an object is just a sequence of numbers stored in computer memory. If a number (64-bit number on amd64) in the object points to the start of an allocated block or into the middle of an allocated block, then the number is a pointer.

[David DENG]

What if it is just an int or uint with the value that a valid pointer can also have.

David

[David Anderson]

That's why the GC is called conservative. It may not collect all collectable memory, but definitely will not collect something that it shouldn't. It's a tradeoff.

Note that on a 64-bit system, the probability of coincidence is vanishingly small. On 32-bit systems, it's more of a problem, and has been a known issue for years.

- Dave

[⚛]

On Sunday, March 3, 2013 8:44:14 AM UTC+1, David Anderson wrote:

That's why the GC is called conservative. It may not collect all collectable memory, but definitely will not collect something that it shouldn't. It's a tradeoff.

Note that on a 64-bit system, the probability of coincidence is vanishingly small. On 32-bit systems, it's more of a problem, and has been a known issue for years.

The garbage collector issues on 32-bit systems are much less severe in Go tip.

[David DENG]

I finally write some code to test and find that answers to both questions are NO.

David

[David DENG]

Finally, I think I understand. I haven't realized the GC can make some trade-off like that.

So unsafe.Pointer is just like a C++'s void* and the reference is counted by GC.

Thanks for you guys!

David

[Ian Lance Taylor]

On Sun, Mar 3, 2013 at 12:17 AM, David DENG <david...@gmail.com> wrote:
> I finally write some code to test and find that answers to both questions
> are NO.

I'm sorry, I misunderstood your question. I thought you were asking
whether the GC would look at the pointer. You were actually asking
whether the GC would *not* look at the pointer.

Ian

[David DENG]

It's OK. My English was fairly poor. :-P Anyway, I got the answer I'm looking for, which did change my understanding of unsafe.Pointer and go's GC. That's great!

David