code review 52110044: reflect: give proper types to the argument/return areas

reflect: add precise GC info for Call argument frame.

Give proper types to the argument/return areas
allocated for reflect calls.  Avoid use of iword to
manipulate receivers, which may or may not be pointers.

Update issue 6490

[khr, 2014-01-14 19:18:04]

Hello golang-dev@googlegroups.com,

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

[gobot, 2014-01-14 19:21:34]

Replacing golang-dev with golang-codereviews.

To the author of this CL: 

If you are using 'hg mail -r golang-dev' to mail the CL, use simply 'hg mail'
instead.

If you did not name golang-dev explicitly and it was still added to the CL,
it means your working copy of the repo has a stale codereview.cfg
(or lib/codereview/codereview.cfg).
Please run 'hg sync' to update your client to the most recent codereview.cfg.
If the most recent codereview.cfg has defaultcc set to golang-dev instead of
golang-codereviews, please send a CL correcting it.

Thanks very much.

[rsc, 2014-01-15 04:40:42]

LGTM

in general the first line of the CL description should stand alone, so that it
can be used in summaries. in this case something like
   reflect: record precise gc info for Call argument frame

i am wondering about tests, not just for this but for the gc bitmaps in general.
not for this CL, but i wonder if we could have a debugging routine that takes an
allocated block and (say) sets every slot that holds a pointer to ~0. then a
test could check that the expected slots were edited.

[khr, 2014-01-15 21:54:17]

On 2014/01/15 04:40:42, rsc wrote:
> LGTM
> 
> in general the first line of the CL description should stand alone, so that it
> can be used in summaries. in this case something like
>    reflect: record precise gc info for Call argument frame
> 
> i am wondering about tests, not just for this but for the gc bitmaps in
general.
> not for this CL, but i wonder if we could have a debugging routine that takes
an
> allocated block and (say) sets every slot that holds a pointer to ~0. then a
> test could check that the expected slots were edited.

That seems reasonable.  I opened issue 7135 for that.

[khr, 2014-01-15 21:57:00]

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

reflect: add precise GC info for Call argument frame.

Give proper types to the argument/return areas
allocated for reflect calls.  Avoid use of iword to
manipulate receivers, which may or may not be pointers.

Update issue 6490

R=rsc
CC=golang-codereviews
https://codereview.appspot.com/52110044