Add Oilpan transition types for core/speech.

Add Oilpan transition types for core/speech.

Add Oilpan support to the SpeechInputResult interface object along
with its list version.

R=
BUG=340522
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=167687

[sof, 2014-02-19 07:14:03]

When you next have some time, please take a look.

[tkent, 2014-02-19 23:49:46]

https://codereview.chromium.org/170423004/diff/1/Source/core/speech/SpeechInp...
File Source/core/speech/SpeechInputResult.h (right):

https://codereview.chromium.org/170423004/diff/1/Source/core/speech/SpeechInp...
Source/core/speech/SpeechInputResult.h:44: static
PassRefPtrWillBeRawPtr<SpeechInputResult> create(const
RawPtr<SpeechInputResult>& source);
Why do you change the argument type?

[sof, 2014-02-20 06:48:00]

https://codereview.chromium.org/170423004/diff/1/Source/core/speech/SpeechInp...
File Source/core/speech/SpeechInputResult.h (right):

https://codereview.chromium.org/170423004/diff/1/Source/core/speech/SpeechInp...
Source/core/speech/SpeechInputResult.h:44: static
PassRefPtrWillBeRawPtr<SpeechInputResult> create(const
RawPtr<SpeechInputResult>& source);
On 2014/02/19 23:49:46, tkent wrote:
> Why do you change the argument type?

Passing in a GCed object by reference looked unsafe & non-standard - is that
allowed? I've been assuming not.

[tkent, 2014-02-20 07:01:41]

On 2014/02/20 06:48:00, sof wrote:
>
https://codereview.chromium.org/170423004/diff/1/Source/core/speech/SpeechInp...
> File Source/core/speech/SpeechInputResult.h (right):
> 
>
https://codereview.chromium.org/170423004/diff/1/Source/core/speech/SpeechInp...
> Source/core/speech/SpeechInputResult.h:44: static
> PassRefPtrWillBeRawPtr<SpeechInputResult> create(const
> RawPtr<SpeechInputResult>& source);
> On 2014/02/19 23:49:46, tkent wrote:
> > Why do you change the argument type?
> 
> Passing in a GCed object by reference looked unsafe & non-standard - is that
> allowed? I've been assuming not.

It's safe.  There are no difference between pointers and references in machine
code.  The conservative stack scan should work well for references.

[sof, 2014-02-20 07:06:34]

On 2014/02/20 07:01:41, tkent wrote:
> On 2014/02/20 06:48:00, sof wrote:
> >
>
https://codereview.chromium.org/170423004/diff/1/Source/core/speech/SpeechInp...
> > File Source/core/speech/SpeechInputResult.h (right):
> > 
> >
>
https://codereview.chromium.org/170423004/diff/1/Source/core/speech/SpeechInp...
> > Source/core/speech/SpeechInputResult.h:44: static
> > PassRefPtrWillBeRawPtr<SpeechInputResult> create(const
> > RawPtr<SpeechInputResult>& source);
> > On 2014/02/19 23:49:46, tkent wrote:
> > > Why do you change the argument type?
> > 
> > Passing in a GCed object by reference looked unsafe & non-standard - is that
> > allowed? I've been assuming not.
> 
> It's safe.  There are no difference between pointers and references in machine
> code.  The conservative stack scan should work well for references.

It's a const reference to a POD-like object - do you have guarantees that the
reference won't be unpacked?

[tkent, 2014-02-20 08:28:49]

On 2014/02/20 07:06:34, sof wrote:
> It's a const reference to a POD-like object - do you have guarantees that the
> reference won't be unpacked?

I don't know if we have guarantees. However, I don't think compilers can unpack
heap-allocated objects, and someone else have a pointer to the object even if
it's unpacked.

[sof, 2014-02-20 08:56:17]

On 2014/02/20 08:28:49, tkent wrote:
> On 2014/02/20 07:06:34, sof wrote:
> > It's a const reference to a POD-like object - do you have guarantees that
the
> > reference won't be unpacked?
> 
> I don't know if we have guarantees. However, I don't think compilers can
unpack
> heap-allocated objects, and someone else have a pointer to the object even if
> it's unpacked.

Presumably this issue isn't new in this context; is this (passing const refs to
GCed objects) something that have come up before and decided on safetywise?
Misplaced paranoia not to do it?

[sof, 2014-02-22 22:26:21]

On 2014/02/19 23:49:46, tkent wrote:
>
https://codereview.chromium.org/170423004/diff/1/Source/core/speech/SpeechInp...
> File Source/core/speech/SpeechInputResult.h (right):
> 
>
https://codereview.chromium.org/170423004/diff/1/Source/core/speech/SpeechInp...
> Source/core/speech/SpeechInputResult.h:44: static
> PassRefPtrWillBeRawPtr<SpeechInputResult> create(const
> RawPtr<SpeechInputResult>& source);
> Why do you change the argument type?

Dropped back to having the argument being a const ref.

[sof, 2014-02-24 07:22:33]

ping? :)

[tkent, 2014-02-24 07:50:15]

On 2014/02/20 08:56:17, sof wrote:
> Presumably this issue isn't new in this context; is this (passing const refs
to
> GCed objects) something that have come up before and decided on safetywise?
> Misplaced paranoia not to do it?

It seems we have never discussed the difference between pointers and references
before.

Also, I couldn't find any information about whether expanding a heap-allocated
object is valid or not. The C++ standard is not handy.

[tkent, 2014-02-24 07:50:42]

lgtm

[commit-bot: I haz the power, 2014-02-24 07:50:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sigbjornf@opera.com/170423004/150001

[sof, 2014-02-24 11:04:06]

On 2014/02/24 07:50:15, tkent wrote:
> On 2014/02/20 08:56:17, sof wrote:
> > Presumably this issue isn't new in this context; is this (passing const refs
> to
> > GCed objects) something that have come up before and decided on safetywise?
> > Misplaced paranoia not to do it?
> 
> It seems we have never discussed the difference between pointers and
references
> before.
> 
> Also, I couldn't find any information about whether expanding a heap-allocated
> object is valid or not. The C++ standard is not handy.

I looked at the literature on conservative GCs a bit over the weekend, and could
not find a mention of this being a problem.

[commit-bot: I haz the power, 2014-02-24 13:32:31]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sigbjornf@opera.com/170423004/150001

[commit-bot: I haz the power, 2014-02-24 13:36:03]

Change committed as 167687