A first skeleton for introducing Harmony proxies

A first skeleton for introducing Harmony proxies.

1) Add new type JSProxy for representing proxy objects.
   Currently devoid of functionality, i.e., all properties are undefined.

2) Some rudimentary global $Proxy functions to create proxies.

Next step: Hook up getProperty and getOwnProperty handlers. Will probably
require introducing a new LookupResult type, which is a mixture of
INTERCEPTOR (handles any property) and CALLBACK (calls back to JS).
Can we unify this somehow?

TODO: Should probably rename existing Proxy type to something like
"Foreign", to avoid confusion.

Committed: http://code.google.com/p/v8/source/detail?r=7887

[Kevin Millikin (Chromium), 2011-05-13 08:08:30]

This LGTM as a start.

There is not yet any sharing of maps for proxies.  We will have to sort out if
and  how we might do that when we begin to optimize performance.

http://codereview.chromium.org/6932068/diff/1/include/v8.h
File include/v8.h (right):

http://codereview.chromium.org/6932068/diff/1/include/v8.h#newcode3670
include/v8.h:3670: static const int kJSObjectType = 0xa2;
Wow, that's brittle.

http://codereview.chromium.org/6932068/diff/1/src/objects.cc
File src/objects.cc (right):

http://codereview.chromium.org/6932068/diff/1/src/objects.cc#newcode136
src/objects.cc:136: if (IsSmi()) {
Not your code, but this looks clumsy.  Isn't

Isolate* isolate = Isolate::Current();
Context* global_context = isolate->context()->global_context();
holder = ...

the same but better?

http://codereview.chromium.org/6932068/diff/1/src/proxy.js
File src/proxy.js (right):

http://codereview.chromium.org/6932068/diff/1/src/proxy.js#newcode64
src/proxy.js:64: if (type != "object" && type != "function") proto =
$Object.prototype
You should write this as if (!IS_SPEC_OBJECT(proto)).

http://codereview.chromium.org/6932068/diff/1/src/runtime.cc
File src/runtime.cc (right):

http://codereview.chromium.org/6932068/diff/1/src/runtime.cc#newcode592
src/runtime.cc:592: HandleScope scope(isolate);
We can remove this HandleScope and call the Heap:: instead of Factor:: version
of the allocation function.

[rossberg, 2011-05-13 09:21:53]

I added a TODO about map sharing to heap.cc. We probably will want to cache maps
keyed by prototype and handler. But as we discussed off-line, before seeing some
real code it is difficult to tell what the best strategy is.

http://codereview.chromium.org/6932068/diff/1/include/v8.h
File include/v8.h (right):

http://codereview.chromium.org/6932068/diff/1/include/v8.h#newcode3670
include/v8.h:3670: static const int kJSObjectType = 0xa2;
On 2011/05/13 08:08:30, Kevin Millikin wrote:
> Wow, that's brittle.

Indeed, I honestly was shocked when I saw it.

http://codereview.chromium.org/6932068/diff/1/src/objects.cc
File src/objects.cc (right):

http://codereview.chromium.org/6932068/diff/1/src/objects.cc#newcode136
src/objects.cc:136: if (IsSmi()) {
On 2011/05/13 08:08:30, Kevin Millikin wrote:
> Not your code, but this looks clumsy.  Isn't
> 
> Isolate* isolate = Isolate::Current();
> Context* global_context = isolate->context()->global_context();
> holder = ...
> 
> the same but better?

I guess so. I simplified that code.

http://codereview.chromium.org/6932068/diff/1/src/proxy.js
File src/proxy.js (right):

http://codereview.chromium.org/6932068/diff/1/src/proxy.js#newcode64
src/proxy.js:64: if (type != "object" && type != "function") proto =
$Object.prototype
On 2011/05/13 08:08:30, Kevin Millikin wrote:
> You should write this as if (!IS_SPEC_OBJECT(proto)).

Done.

http://codereview.chromium.org/6932068/diff/1/src/runtime.cc
File src/runtime.cc (right):

http://codereview.chromium.org/6932068/diff/1/src/runtime.cc#newcode592
src/runtime.cc:592: HandleScope scope(isolate);
On 2011/05/13 08:08:30, Kevin Millikin wrote:
> We can remove this HandleScope and call the Heap:: instead of Factor:: version
> of the allocation function.

Done.

[rossberg, 2011-05-13 09:26:14]

I added a TODO to AllocateJSProxy. We probably will want to cache proxy maps
keyed by handler and prototype. But as we discussed off-line, it is hard to say
what the best strategy will be before seeing some real code.

[Vyacheslav Egorov (Chromium), 2011-05-22 14:45:49]

DBC

There is a GC related problem bug see comment in object-visiting.cc.

http://codereview.chromium.org/6932068/diff/9002/src/heap.cc
File src/heap.cc (right):

http://codereview.chromium.org/6932068/diff/9002/src/heap.cc#newcode3220
src/heap.cc:3220: if (!maybe_map_obj->ToObject(&map_obj)) return maybe_map_obj;
I introduced a helpful templated To<T> accessor to avoid boilerplate code:

if (!maybe_map_obj->To<Map>(&map)) ...

http://codereview.chromium.org/6932068/diff/9002/src/objects-visiting.cc
File src/objects-visiting.cc (right):

http://codereview.chromium.org/6932068/diff/9002/src/objects-visiting.cc#newc...
src/objects-visiting.cc:92: return GetVisitorIdForSize(kVisitDataObject,
This introduces a subtle GC problem: JS_PROXY is not a data object. Data objects
do not contain pointers in their bodies.

We should either pretend that JS_PROXY is a struct (kVisitStruct,
kVisitStructGeneric) or introduce a separate kVisitJSProxy. 

I think pretending that JS_PROXY is a struct should be fine especially because
proxies are probably not going to need any special handling by visitors.

[rossberg, 2011-05-23 08:45:28]

Hi Slava, thanks, I gonna send you a patch shortly.

http://codereview.chromium.org/6932068/diff/9002/src/heap.cc
File src/heap.cc (right):

http://codereview.chromium.org/6932068/diff/9002/src/heap.cc#newcode3220
src/heap.cc:3220: if (!maybe_map_obj->ToObject(&map_obj)) return maybe_map_obj;
On 2011/05/22 14:45:50, Vyacheslav Egorov wrote:
> I introduced a helpful templated To<T> accessor to avoid boilerplate code:
> 
> if (!maybe_map_obj->To<Map>(&map)) ...

Ah, nice. Done.

http://codereview.chromium.org/6932068/diff/9002/src/objects-visiting.cc
File src/objects-visiting.cc (right):

http://codereview.chromium.org/6932068/diff/9002/src/objects-visiting.cc#newc...
src/objects-visiting.cc:92: return GetVisitorIdForSize(kVisitDataObject,
On 2011/05/22 14:45:50, Vyacheslav Egorov wrote:
> This introduces a subtle GC problem: JS_PROXY is not a data object. Data
objects
> do not contain pointers in their bodies.
> 
> We should either pretend that JS_PROXY is a struct (kVisitStruct,
> kVisitStructGeneric) or introduce a separate kVisitJSProxy. 
> 
> I think pretending that JS_PROXY is a struct should be fine especially because
> proxies are probably not going to need any special handling by visitors.

Done.