Creating persistent weak handles on primitive values did not collected by GC?

[Dmitry Azaraev]

Hi.

My question initially originated from CEF V8 integration, described on next issues: https://code.google.com/p/chromiumembedded/issues/detail?id=323 , https://code.google.com/p/chromiumembedded/issues/detail?id=960 .

In short problem looks as:

CEF creates persistent and weak handles for every created V8 value ( Boolean, Integers ). And in this case i found memory leak, when for example our native function returns primitive value. For complex values (Object), this is did not appear at all.

So it is possible that persistent weak handles built on top of primitive values did not collected?

And additional question: it is safe return persistent handle via raw return handle; instead of return handle_scope.Close(handle); ?

[Vyacheslav Egorov]

> So it is possible that persistent weak handles built on top of primitive values did not collected?

Boolean values are eternal --- they never die. Small integers (31 bits on ia32 and 32bits on x64) are not even allocated in the heap, they are *values* essentially so weak reachability is undefined for them. 

> it is safe return persistent handle via raw return handle; instead of return handle_scope.Close(handle); ?

Yes. You need to use Close only for Local handles. If you return Persistent handle you can just return that directly.

  

--

Vyacheslav Egorov

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Vyacheslav Egorov

Software Engineer

Google Danmark ApS - Skt Petri Passage 5, 2 sal - 1165 København K - CVR nr. 28 86 69 84

[Dmitry Azaraev]

> Boolean values are eternal --- they never die. Small integers (31 bits on ia32 and 32bits on x64) are
> not even allocated in the heap, they are *values* essentially so weak reachability is undefined for them.

   Thanks. I'm trying allocate non-SMI values too - and got same result, so looks, that exists some additional rule. May be exist easy way to detect which values can be used as weak headles or no?

You received this message because you are subscribed to a topic in the Google Groups "v8-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-users/616ZM3UWh2k/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to v8-users+u...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Best regards,
   Dmitry

[Ben Noordhuis]

On Sat, Apr 27, 2013 at 10:36 AM, Dmitry Azaraev
<dmitry....@gmail.com> wrote:
>> Boolean values are eternal --- they never die. Small integers (31 bits on
>> ia32 and 32bits on x64) are
>> not even allocated in the heap, they are *values* essentially so weak
>> reachability is undefined for them.
> Thanks. I'm trying allocate non-SMI values too - and got same result, so
> looks, that exists some additional rule. May be exist easy way to detect
> which values can be used as weak headles or no?

As a rule of thumb, you should only turn Objects* and Strings into
Persistent handles. Even then it may be a worthwhile tradeoff to just
take the hit and construct a new object every time rather than caching
it in a Persistent handle. (Caveat emptor: as with all
performance-related advice, don't take it on face value - benchmark
it.)

If you find yourself returning a lot of non-SMI numbers, it may be
worth it to return them in a pre-allocated typed array rather than
directly. We use that trick in node.js to avoid excessive heap
allocations.

* That includes Arrays but if your array contains only numeric values,
you can often use the typed array trick.

[Dmitry Azaraev]

Ben, thanks for points.

I already found that it works only with 'complex' objects, and it is not depends SMI/non-SMI values via some kind of performance benchmark, which i'm use to measure/detect memory leak. It means that for heap-allocated integer + persistent weak handle also can't be collected by GC.

My main concern is how it is must be implemented rightly to avoid memory leaks. I'm little discouraged that rules about using weak handles is not documented everywhere.

So now question is clear (there is V8 feature :) ). Thanks again for you help!

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to a topic in the Google Groups "v8-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-users/616ZM3UWh2k/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Best regards,
   Dmitry

[Vyacheslav Egorov]

Non-smi values are allocated on the heap so they should be collected sooner or later. Though they might be temporary stuck in some cache. 

As Ben recommends it's better to put only Objects&Strings into weak persistent handles. [though strings can also be stuck in some cache for indefinite amount of time] 

Vyacheslav Egorov

On Sat, Apr 27, 2013 at 10:36 AM, Dmitry Azaraev <dmitry....@gmail.com> wrote:

[Dmitry Azaraev]

Caching... it can be answer to my question.

For clarification:

In intensive creating string or non-smi values for example via calling v8::String:New , actual string value cached first and then when i'm create persistent handle - this handle reference cached string object. Once this caching object will be freed, - all persistent weak handles also must be freed? But actually there is can happens very later.

For me it is ok do not create persistent handles at all for primitive and strings, i think.

 

Thanks.

[Jochen Eisinger]

On Fri, Apr 26, 2013 at 9:54 PM, Vyacheslav Egorov <veg...@chromium.org> wrote:

> So it is possible that persistent weak handles built on top of primitive values did not collected?

Boolean values are eternal --- they never die. Small integers (31 bits on ia32 and 32bits on x64) are not even allocated in the heap, they are *values* essentially so weak reachability is undefined for them. 

> it is safe return persistent handle via raw return handle; instead of return handle_scope.Close(handle); ?

Yes. You need to use Close only for Local handles. If you return Persistent handle you can just return that directly.

Note, however, that we're currently working on removing the common base class between Persistent and Local. In the future, you'll have to explicitly convert the  Persistent to a Local and return it via handle_scope.Close().

Passing back a Persistent handle effectively creates a new Handle pointing to the same global cell. If you now invoke Dispose on the Persistent handle, the copy will point to an invalid memory location. By first creating a Local handle and then returning it, you can avoid this situation.

best

-jochen