On Fri, Jun 17, 2011 at 5:10 PM, Charles Lowell <[email protected]>wrote:

> Mads,
>
> Basically, "handle soup" arises from the fact that there are two
> garbage collectors at work. Handle life cycle is managed by an
> external VM and its garbage collector, and there is a one-to-many
> relationship between that VM and isolates. Put another way, there is
> only one Ruby GC, and it has to work with every Ruby proxy no matter
> what isolate its handle came from.
>
> That said, I think I have a solution: when a proxy is allocated, it
> will be passed a reference to the current isolate's disposal queue.
> That way, if the isolate is disposed of before the handle, it can
> still be safely enqueued, even though nobody will ever dequeue it.
> That should work as long as disposing of an isolate will not leak
> those persistent handles which have not yet been disposed. So for
> example, how does this behave?
>
> https://gist.github.com/1031564
>


Pasting here to make it easier to follow:


using namespace v8;

int main(int argc, char** argv) {
  Isolate* isolate = Isolate::New();
  isolate->Enter();
  Persistent<Context> cxt = Context::New();
  isolate->Exit();
  isolate->Dispose();
  // is cxt, leaked?
}


The context here is not leaked because all resources for the isolate should
be freed up when disposing the isolate. However, you will have a stale
pointer in your persistent handle. You therefore need to make sure that you
clean out your data structures holding your handles when disposing an
isolate.

Cheers,    -- Mads

Thanks again for all the replies!
>
> cheers,
> Charles
>
>
>
> On Jun 16, 1:55 pm, Mads Sig Ager <[email protected]> wrote:
> > Charles,
> >
> > I don't think I understand how you would get into a situation where this
> is
> > needed. An object can only be used in the isolate from which it came. So
> > passing in handles from one isolate to another isolate does not
> > work. Therefore, the soup of handles from different isolates seems like
> an
> > unfortunate situation to get into. If you don't know which isolate a
> handle
> > belongs to you cannot use it correctly.
> >
> > Cheers,    -- Mads
> >
> > On Thu, Jun 16, 2011 at 3:55 PM, Charles Lowell <
> [email protected]>wrote:
> >
> >
> >
> >
> >
> >
> >
> > > Mads,
> >
> > > The problem as I see it is not when V8 GC runs, but when Ruby GC runs.
> > > At that time, I have one heterogeneous list of handles that could
> > > belong to any number of different isolates. It is then that I would
> > > like to partition these handles into a bag per isolate. That way, when
> > > V8 GC runs in the context of each isolate, I can call GetCurrent() and
> > > dispose of all the handles in that isolate's bag. Does that make more
> > > sense?
> >
> > > Note that I don't actually support multiple isolates at the moment,
> > > but I do foresee this as a potential problem in the future.
> >
> > > On Jun 15, 2:21 am, Mads Sig Ager <[email protected]> wrote:
> > > > Hi Charles,
> >
> > > > when you get the callback you will have to be using that isolate. So
> > > getting
> > > > the isolate should be as simple as doing Isolate::GetCurrent() and
> then
> > > add
> > > > the handle to the list for that isolate?
> >
> > > > Cheers,     -- Mads
> >
> > > > On Wed, Jun 15, 2011 at 9:17 AM, Jedrzej Nowacki
> > > > <[email protected]>wrote:
> >
> > > > > Hi,
> >
> > > > >  You can keep the isolate pointer inside an internal field.
> Depending
> > > on
> > > > > the
> > > > > handles template type:
> >
> > > > > Object::SetInternalField
> > > > > Script::setData
> > > > > Context::setData
> >
> > > > > Cheers,
> > > > >  Jedrek
> >
> > > > > On Tuesday 14. June 2011 22.50.08 ext Charles Lowell wrote:
> > > > > > Given a persistent handle, is it possible to find out the Isolate
> > > with
> > > > > > which it is associated. The reason I say is that I've change
> > > > > > therubyracer to queue up handles to be released in a single spot
> > > where
> > > > > > it is safe to lock V8 (not the Ruby GC thread). When ruby GC sees
> a
> > > > > > disposable handle, I'd like to add it to a queue associated with
> that
> > > > > > handle's Isolate so that the queue can later be emptied in the
> scope
> > > > > > of that Isolate.
> >
> > > > > > We don't support multiple Isolates yet, so I can get away with
> having
> > > > > > a single queue per Ruby process, but to add support in the
> future, it
> > > > > > would make things a easier. Ideas?
> >
> > > > > > cheers,
> > > > > > Charles
> >
> > > > > --
> > > > > v8-users mailing list
> > > > > [email protected]
> > > > >http://groups.google.com/group/v8-users
> >
> > > --
> > > v8-users mailing list
> > > [email protected]
> > >http://groups.google.com/group/v8-users
>
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
>

-- 
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users

Reply via email to