https://codereview.chromium.org/649563006/diff/20001/include/v8.h
File include/v8.h (right):
https://codereview.chromium.org/649563006/diff/20001/include/v8.h#newcode520
include/v8.h:520: V8_INLINE void SetPhantom(P* parameter,
I'll revise my answer to the second part slightly: If you do:
Local<Object> obj = Local<Object>::New(isolate, p)
then you get a new handle, which will keep alive the object, and the
callback will never be called.
On the other hand, internally you can do:
Handle<Object> handle(global_handle.location())
and this gives you a handle that points at the same location as the
global handle (persistent in external terminology). This can be abused,
but this is not through the API.
https://codereview.chromium.org/649563006/diff/20001/src/global-handles.cc
File src/global-handles.cc (right):
https://codereview.chromium.org/649563006/diff/20001/src/global-handles.cc#newcode256
src/global-handles.cc:256: DCHECK(*handle ==
Smi::FromInt(kPhantomReferenceZap));
On 2014/10/20 14:29:03, jochen wrote:
On 2014/10/20 at 14:25:32, Erik Corry wrote:
> On 2014/10/20 14:11:46, jochen wrote:
> > should we set handle to a null-handle here?
>
> I think that's not so useful. The callback then doesn't have an
indication of
which handle is being cleared. By just zapping the contents, the
callback still
has the location to key on if it has a hash map or similar. This is
the value
the callback gets by doing operator* on the handle.
>
> There is the parameter, but often that is used to identify the
per-isolate
object that holds state, not the individual reference that is dying.
We could
add a second parameter, but that seems over-engineered somehow.
but the address of the handle is completely new, it's allocated in the
handle
scope two lines above. it's a fresh address, and it points to garbage.
the embedder will have to put all infos in the params anyways
We could replace
Handle<Object> handle(*object, isolate)
with
Handle<Object> handle(object)
and then it would not be a new fresh address, but share the location.
However although that gives access to the location in the callback, the
API user can't get at the location when registering, because we don't
let them get at the location that backs a persistent (only a local). I
think there are good reasons for that, so I'll go with your suggestion
for now (API user can't use location, has to use the parameter), and see
how usable that is.
https://codereview.chromium.org/649563006/diff/20001/test/cctest/test-api.cc
File test/cctest/test-api.cc (right):
https://codereview.chromium.org/649563006/diff/20001/test/cctest/test-api.cc#newcode7492
test/cctest/test-api.cc:7492:
On 2014/10/20 14:26:02, ulan wrote:
Could you please also test we don't mark through a dying phantom
handle?
I mean that phantom handle and its value die in the same GC.
I haven't done this yet.
https://codereview.chromium.org/649563006/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
