what's the correct lifetime for "random" attributes

8 views
Skip to first unread message

Jochen Eisinger

unread,
Oct 20, 2016, 9:51:06 AM10/20/16
to platform-architecture-dev, Domenic Denicola, Michael Starzinger
Hey,

e.g. XMLHttpRequest::response doesn't actually keep the response alive, i.e., if you call it repeatedly, and the compiler doesn't happen to keep the object in a temporary register, and gc happens, you'll get a fresh wrapper.

There's a layout test that says this should be otherwise (https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/xmlhttprequest/xmlhttprequest-responsetype-arraybuffer.html?sq=package:chromium&l=93) but if you look at the baseline, this is not actually what happens.

My question is, what is the right behavior here? Should all attributes always return the same wrapper? Or, if not, which should? Why does firstChild have this, but e.g. reponse doesn't?

best
-jochen

Kentaro Hara

unread,
Oct 20, 2016, 10:01:32 AM10/20/16
to Jochen Eisinger, platform-architecture-dev, Domenic Denicola, Michael Starzinger
There's no distinction between a wrapper and a C++ DOM object in the spec. They are the same object. So all DOM attributes must keep returning the same wrapper as long as the underlying C++ DOM object is the same.

Both Node::firstChild and XMLHttpRequest::response must return the same wrapper as long as the underlying C++ DOM object is the same.

So I'd say it's a bug of XMLHttpRequest::response.

 
best
-jochen

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALjhuifR6%3D9KbZMby9E4c41iCpe0q5eLab5d7M9JGdMCwNY_dA%40mail.gmail.com.



--
Kentaro Hara, Tokyo, Japan

Jochen Eisinger

unread,
Oct 20, 2016, 10:39:11 AM10/20/16
to Kentaro Hara, platform-architecture-dev, Domenic Denicola, Michael Starzinger
On Thu, Oct 20, 2016 at 4:01 PM Kentaro Hara <har...@chromium.org> wrote:
On Thu, Oct 20, 2016 at 2:50 PM, Jochen Eisinger <joc...@chromium.org> wrote:
Hey,

e.g. XMLHttpRequest::response doesn't actually keep the response alive, i.e., if you call it repeatedly, and the compiler doesn't happen to keep the object in a temporary register, and gc happens, you'll get a fresh wrapper.

There's a layout test that says this should be otherwise (https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/xmlhttprequest/xmlhttprequest-responsetype-arraybuffer.html?sq=package:chromium&l=93) but if you look at the baseline, this is not actually what happens.

My question is, what is the right behavior here? Should all attributes always return the same wrapper? Or, if not, which should? Why does firstChild have this, but e.g. reponse doesn't?

There's no distinction between a wrapper and a C++ DOM object in the spec. They are the same object. So all DOM attributes must keep returning the same wrapper as long as the underlying C++ DOM object is the same.

Both Node::firstChild and XMLHttpRequest::response must return the same wrapper as long as the underlying C++ DOM object is the same.

So I'd say it's a bug of XMLHttpRequest::response.

Since this is a custom getter - is this a bug in the handwritten code? i.e. would an auto-generated getter cache the value returned?
 

 
best
-jochen

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.



--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwPyzv_OB3t62tgxoanuM8AnqZbwH6GzHUShaVVjqTYnA%40mail.gmail.com.

Kentaro Hara

unread,
Oct 20, 2016, 11:11:49 AM10/20/16
to Jochen Eisinger, platform-architecture-dev, Domenic Denicola, Michael Starzinger
On Thu, Oct 20, 2016 at 3:38 PM, Jochen Eisinger <joc...@chromium.org> wrote:


On Thu, Oct 20, 2016 at 4:01 PM Kentaro Hara <har...@chromium.org> wrote:
On Thu, Oct 20, 2016 at 2:50 PM, Jochen Eisinger <joc...@chromium.org> wrote:
Hey,

e.g. XMLHttpRequest::response doesn't actually keep the response alive, i.e., if you call it repeatedly, and the compiler doesn't happen to keep the object in a temporary register, and gc happens, you'll get a fresh wrapper.

There's a layout test that says this should be otherwise (https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/xmlhttprequest/xmlhttprequest-responsetype-arraybuffer.html?sq=package:chromium&l=93) but if you look at the baseline, this is not actually what happens.

My question is, what is the right behavior here? Should all attributes always return the same wrapper? Or, if not, which should? Why does firstChild have this, but e.g. reponse doesn't?

There's no distinction between a wrapper and a C++ DOM object in the spec. They are the same object. So all DOM attributes must keep returning the same wrapper as long as the underlying C++ DOM object is the same.

Both Node::firstChild and XMLHttpRequest::response must return the same wrapper as long as the underlying C++ DOM object is the same.

So I'd say it's a bug of XMLHttpRequest::response.

Since this is a custom getter - is this a bug in the handwritten code? i.e. would an auto-generated getter cache the value returned? 

Yes, it's a bug of the handwritten code. The fact that the spec has XMLHttpRequest.response means that there is a strong reference from XMLHttpRequest to the response object. Hence V8 bindings need to create a strong reference from XMLHttpRequest's wrapper to the response object. The auto-generated code handles this in attribute.is_keep_alive_for_gc (c.f., auto-generated code).


 

 
best
-jochen

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.



--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

Jochen Eisinger

unread,
Oct 20, 2016, 11:24:39 AM10/20/16
to Kentaro Hara, platform-architecture-dev, Domenic Denicola, Michael Starzinger
Thanks, filed crbug.com/657851

On Thu, Oct 20, 2016 at 5:11 PM Kentaro Hara <har...@chromium.org> wrote:
On Thu, Oct 20, 2016 at 3:38 PM, Jochen Eisinger <joc...@chromium.org> wrote:


On Thu, Oct 20, 2016 at 4:01 PM Kentaro Hara <har...@chromium.org> wrote:
On Thu, Oct 20, 2016 at 2:50 PM, Jochen Eisinger <joc...@chromium.org> wrote:
Hey,

e.g. XMLHttpRequest::response doesn't actually keep the response alive, i.e., if you call it repeatedly, and the compiler doesn't happen to keep the object in a temporary register, and gc happens, you'll get a fresh wrapper.

There's a layout test that says this should be otherwise (https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/xmlhttprequest/xmlhttprequest-responsetype-arraybuffer.html?sq=package:chromium&l=93) but if you look at the baseline, this is not actually what happens.

My question is, what is the right behavior here? Should all attributes always return the same wrapper? Or, if not, which should? Why does firstChild have this, but e.g. reponse doesn't?

There's no distinction between a wrapper and a C++ DOM object in the spec. They are the same object. So all DOM attributes must keep returning the same wrapper as long as the underlying C++ DOM object is the same.

Both Node::firstChild and XMLHttpRequest::response must return the same wrapper as long as the underlying C++ DOM object is the same.

So I'd say it's a bug of XMLHttpRequest::response.

Since this is a custom getter - is this a bug in the handwritten code? i.e. would an auto-generated getter cache the value returned? 

Yes, it's a bug of the handwritten code. The fact that the spec has XMLHttpRequest.response means that there is a strong reference from XMLHttpRequest to the response object. Hence V8 bindings need to create a strong reference from XMLHttpRequest's wrapper to the response object. The auto-generated code handles this in attribute.is_keep_alive_for_gc (c.f., auto-generated code).


 

 
best
-jochen

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.



--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
Reply all
Reply to author
Forward
0 new messages