Glad to see Persistent getting so much love. I'd just like to drop my 2 cents worth of pain recently.
For better performance I've created an allocator that grabs a large chunk of memory, divides it and hands those off via SetIndexedPropertiesToExternalArrayData. The minimum number of steps I've found to accomplish this are broken into two parts. First for a new large chunk: - Create a new Persistent<Object> with an Object::New(), in the global scope. This basically acts as a placeholder for v8's gc. - MakeWeak and pass the char* as the parameter - AdjustAmountOfExternalAllocatedMemory Then for allocating a chunk: - SetIndexedPropertiesToExternalArrayData - Then, to make sure v8 knows when to gc the Persistent, attach the global Persistent to the js object via SetHiddenValue, SetInternalField, etc. Now when no more js objects are pointing to the Persistent, it will call the MakeWeakCallback. Which will then perform cleanup, etc. There are two non-trivial issues with this approach. First; if js objects hang around pointing to small parts of the data then large portions hang around unused. Second; this process is extremely expensive, and much more so if each object were to be made it's own Persistent for independent tracking. So what I'd like for consideration are: - Creation of a much less expensive API for attaching a Persistent to a js object for the explicit purpose of knowing when to gc. - A way to track what js objects are still pointing to memory. Possibly like a method on Persistent that allows to step through all attached js objects. If these are currently possible with the existing API I apologize, but so far I haven't been able to find a way to allocate many small-ish chunks of external memory w/o slowing down performance considerably. trev On Monday, March 25, 2013 6:47:30 AM UTC-7, [email protected] wrote: > > * > > Hi, > > due to fundamental problems in the design of the Persistent handle API, we > feel the need to considerably change the V8 API to ensure that the > Persistent class is safe to use. Currently, it is extremely difficult to > use safely and can easily lead to heap corruption. To get an understanding > of the problem, see https://code.google.com/p/v8/issues/detail?id=1889. > > At the moment we’re considering the following major changes: > > > - > > Making Persistent an independent class (no longer deriving from > Handle). > > - > > Deprecating Local and eventually removing it in favor of just having > Handle. > > - > > Changing all callbacks that return Handle<Value> to return void and > instead pass the return value in as a parameter. > > > > The last change is not inherently required by the changes to Persistent > but rather to maintain performant callbacks which return Persistent. The > old style of callbacks we want to be deprecate and eventually remove. In > the meantime, old style callbacks can support the return value parameter > when an empty handle is returned, providing a transition path. > > I have created two patches that attempt this transformation (most of it > anyway). They are https://codereview.chromium.org/12729023/ and > https://codereview.chromium.org/12494012/. > > Not everything is yet set in stone, and I expect a certain amount of > change to the overall implementation path as we work through implementation > issues and receive feedback. > > Dan > > * -- -- v8-users mailing list [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
