code review 117000043: cmd/ld: mark hostobj sections as containing no pointers

cmd/ld: mark hostobj sections as containing no pointers
Currently they are scanned conservatively.
But there is no reason to scan them. C world must not contain
pointers into Go heap. Moreover, we don't have enough information
to emit write barriers nor update pointers there in future.
The immediate need is that it breaks the new GC because
these are weird symbols as if with pointers but not necessary
pointer aligned.

[dvyukov, 2014-07-21 09:19:09]

Hello golang-codereviews@googlegroups.com (cc: iant@golang.org, khr@golang.org,
rlh@golang.org, rsc@golang.org),

I'd like you to review this change to
https://dvyukov%40google.com@code.google.com/p/go/

[rlh, 2014-07-21 12:14:56]

On 2014/07/21 09:19:09, dvyukov wrote:
> Hello mailto:golang-codereviews@googlegroups.com (cc: mailto:iant@golang.org,
mailto:khr@golang.org,
> mailto:rlh@golang.org, mailto:rsc@golang.org),
> 
> I'd like you to review this change to
> https://dvyukov%40google.com@code.google.com/p/go/

Is this the last of the conservative scanning? If so I would have expected to
see the conservative scan code having been deleted. If not where do we still do
conservative scanning?

[dvyukov, 2014-07-21 12:18:10]

On 2014/07/21 12:14:56, rlh wrote:
> On 2014/07/21 09:19:09, dvyukov wrote:
> > Hello mailto:golang-codereviews@googlegroups.com (cc:
mailto:iant@golang.org,
> mailto:khr@golang.org,
> > mailto:rlh@golang.org, mailto:rsc@golang.org),
> > 
> > I'd like you to review this change to
> > https://dvyukov%40google.com@code.google.com/p/go/
> 
> Is this the last of the conservative scanning? If so I would have expected to
> see the conservative scan code having been deleted. If not where do we still
do
> conservative scanning?

Some objects in runtime C code are allocated w/o type info; also C stacks are
still imprecise.

[rlh, 2014-07-21 12:49:25]

Do these sources of imprecise pointers have the same problem? If so how do
we work around this problem?


On Mon, Jul 21, 2014 at 8:18 AM, <dvyukov@google.com> wrote:

> On 2014/07/21 12:14:56, rlh wrote:
>
>> On 2014/07/21 09:19:09, dvyukov wrote:
>> > Hello mailto:golang-codereviews@googlegroups.com (cc:
>>
> mailto:iant@golang.org,
>
>> mailto:khr@golang.org,
>> > mailto:rlh@golang.org, mailto:rsc@golang.org),
>> >
>> > I'd like you to review this change to
>> > https://dvyukov%40google.com@code.google.com/p/go/
>>
>
>  Is this the last of the conservative scanning? If so I would have
>>
> expected to
>
>> see the conservative scan code having been deleted. If not where do we
>>
> still do
>
>> conservative scanning?
>>
>
> Some objects in runtime C code are allocated w/o type info; also C
> stacks are still imprecise.
>
> https://codereview.appspot.com/117000043/
>

[dvyukov, 2014-07-21 12:55:02]

On Mon, Jul 21, 2014 at 4:49 PM, Rick Hudson <rlh@golang.org> wrote:
> Do these sources of imprecise pointers have the same problem?

> If so how do > we work around this problem?

We don't. We have conservative GC.



>
>
> On Mon, Jul 21, 2014 at 8:18 AM, <dvyukov@google.com> wrote:
>>
>> On 2014/07/21 12:14:56, rlh wrote:
>>>
>>> On 2014/07/21 09:19:09, dvyukov wrote:
>>> > Hello mailto:golang-codereviews@googlegroups.com (cc:
>>
>> mailto:iant@golang.org,
>>>
>>> mailto:khr@golang.org,
>>> > mailto:rlh@golang.org, mailto:rsc@golang.org),
>>> >
>>> > I'd like you to review this change to
>>> > https://dvyukov%40google.com@code.google.com/p/go/
>>
>>
>>> Is this the last of the conservative scanning? If so I would have
>>
>> expected to
>>>
>>> see the conservative scan code having been deleted. If not where do we
>>
>> still do
>>>
>>> conservative scanning?
>>
>>
>> Some objects in runtime C code are allocated w/o type info; also C
>> stacks are still imprecise.
>>
>> https://codereview.appspot.com/117000043/
>
>

[rsc, 2014-07-22 03:42:53]

LGTM

[dvyukov, 2014-07-22 08:10:25]

*** Submitted as https://code.google.com/p/go/source/detail?r=da1002b78b19 ***

cmd/ld: mark hostobj sections as containing no pointers
Currently they are scanned conservatively.
But there is no reason to scan them. C world must not contain
pointers into Go heap. Moreover, we don't have enough information
to emit write barriers nor update pointers there in future.
The immediate need is that it breaks the new GC because
these are weird symbols as if with pointers but not necessary
pointer aligned.

LGTM=rsc
R=golang-codereviews, rlh, rsc
CC=golang-codereviews, iant, khr
https://codereview.appspot.com/117000043

[gobot, 2014-07-22 08:23:15]

This CL appears to have broken the windows-amd64 builder.
See http://build.golang.org/log/d4352f59ddaff6103b292c3068d0c143412b22b4

[rlh, 2014-07-22 14:35:30]

LGTM


On Tue, Jul 22, 2014 at 4:23 AM, <gobot@golang.org> wrote:

> This CL appears to have broken the windows-amd64 builder.
> See http://build.golang.org/log/d4352f59ddaff6103b292c3068d0c143412b22b4
>
> https://codereview.appspot.com/117000043/
>