Fill the header of an Instructions object with null

Fill the header of an Instructions object with null

Fixes debug mode failure discovered on mips bot.

R=rmacnak@google.com

Committed: https://github.com/dart-lang/sdk/commit/6b622133ca8da0fc79e04e4f8246ab6283ebe9fa

[Cutch, 2015-09-30 17:04:35]

johnmccutchan@google.com changed reviewers:
+ rmacnak@google.com

[rmacnak, 2015-09-30 17:06:15]

lgtm

[Cutch, 2015-09-30 17:06:35]

Committed patchset #1 (id:1) manually as
6b622133ca8da0fc79e04e4f8246ab6283ebe9fa (presubmit successful).

[Florian Schneider, 2015-09-30 19:11:13]

fschneider@google.com changed reviewers:
+ fschneider@google.com

[Florian Schneider, 2015-09-30 19:11:13]

dbc: Only the slot with the code backpointer has to be null-initialized, right?
It is visited by GC.

Also, smi 0 would be better than Object::null() since it does not change between
runs of the VM - otherwise the precompiled snapshot differs between runs of the
same input, which I tried to avoid using the break-instructions as fillers.

[Cutch, 2015-09-30 19:30:11]

On 2015/09/30 19:11:13, Florian Schneider wrote:
> dbc: Only the slot with the code backpointer has to be null-initialized,
right?
> It is visited by GC.
> 

Strictly speaking, yes. With my change the size field and the code field are
both initialized to null.

> Also, smi 0 would be better than Object::null() since it does not change
between
> runs of the VM - otherwise the precompiled snapshot differs between runs of
the
> same input, which I tried to avoid using the break-instructions as fillers.

We can't use smi 0 because the heap validation done in debug mode StorePointer
verifies that the value being overwritten was also a pointer. 

This will all go away shortly once I implement the real solution anyways.

John

[koda, 2015-09-30 19:33:57]

On 2015/09/30 19:11:13, Florian Schneider wrote:
> dbc: Only the slot with the code backpointer has to be null-initialized,
right?
> It is visited by GC.
> 
> Also, smi 0 would be better than Object::null() since it does not change
between
> runs of the VM - otherwise the precompiled snapshot differs between runs of
the
> same input, which I tried to avoid using the break-instructions as fillers.

Also, just as a general reminder, if any field ever needs to be initialized to
anything other than null/Smi, please use RawObject::Store{Pointer,Smi,...},
which ensure any present or future write barrier is correctly applied.

[koda, 2015-09-30 19:42:11]

On 2015/09/30 19:33:57, koda wrote:
> On 2015/09/30 19:11:13, Florian Schneider wrote:
> > dbc: Only the slot with the code backpointer has to be null-initialized,
> right?
> > It is visited by GC.
> > 
> > Also, smi 0 would be better than Object::null() since it does not change
> between
> > runs of the VM - otherwise the precompiled snapshot differs between runs of
> the
> > same input, which I tried to avoid using the break-instructions as fillers.
> 
> Also, just as a general reminder, if any field ever needs to be initialized to
> anything other than null/Smi, please use RawObject::Store{Pointer,Smi,...},
> which ensure any present or future write barrier is correctly applied.

... and to clarify, since Store* does indeed verify the previous value, you'd
need to either do it after writing a (redundant) null (and after the call to
VerifiedMemory::Accept), or add a C++ version of Assembler::InitializeField,
etc., which we use in generated code.