> It exists (and I should have mentioned that in my previous email,
> sorry about that.) Maybe you found them already:
> `Isolate::VisitHandlesWithClassIds()` and
> `Isolate::VisitWeakHandles()`
I saw these, but didn't want to piggyback on the v8 profiler interface,
just in case if it's not a
On Mon, Mar 5, 2018 at 3:44 PM, A.M. wrote:
> Thanks again for your insights, Ben. I ended up tracking all weak handles,
> as well as all allocations, so combining weak handle callbacks with walking
> all allocations after the isolate has been disposed of seems to cover all
> memory allocations wi
Thanks again for your insights, Ben. I ended up tracking all weak handles,
as well as all allocations, so combining weak handle callbacks with walking
all allocations after the isolate has been disposed of seems to cover all
memory allocations without any interference from v8 background threads.
On Wed, Feb 28, 2018 at 6:19 AM, A.M. wrote:
>> The answer is "it depends." If you're not going to call into V8 at
>> all it's _probably_ safe but most V8 APIs can kick off a GC run. Call
>> `v8::Isolate::Dispose()` first to be safe.
>
> Is there a best-practices way to dispose of application ob
>
> The answer is "it depends." If you're not going to call into V8 at
> all it's _probably_ safe but most V8 APIs can kick off a GC run. Call
> `v8::Isolate::Dispose()` first to be safe.
>
Is there a best-practices way to dispose of application objects stored in
internal fields that didn't
On Sat, Feb 24, 2018 at 11:20 PM, A.M. wrote:
> My understanding is that garbage collection can be done either in the idle
> notification call made by the application or when some context is being
> disposed of or in one of the v8 background threads. I'm not concerned about
> phantom handles and t
