The reasoning behind this change is that in the future we'll have FunctionTemplates that can be called through accessors without even allocating the JSFunction. Registering the last called value isn't possible in that case...
Perhaps rather than fully getting rid of the parameter we should change the API to pass undefined if there is no closure. In that case the FunctionTemplate would need to be instantiated manually through the API to get to the callee.
Wdyt Enrico?
Toon
--
--
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/d/optout.
The difference is that FunctionTemplates are (supposedly) unique for the entire isolate, whereas JSFunctions are instantiated per native context. So if you use multiple realms (iframes in a browser setting), you'd be getting multiple Callees (jsfunction) for the same callback (FunctionTemplate).
Preallocating all of those is expensive memory-wise and in terms of context-initialization. Getting to all-can-read accessors (jsfunction from the accessing context rather than the installed accessor) is either expensive performance-wise while accessing; or makes the memory and initialization issues even worse.
My thinking now is that we could hide the cost inside of info.Callee(), by instantiating the FunctionTemplate in the current (accessing) context if the value passed in was null or some other sentinel. That makes it slightly more expensive for regular templates (the null check), and quite a bit more for lazy instantiated templates that access Callee. The latter should just not be used in that scenario...
One alternative to using Callee for functions you created yourself is specifying the data parameter which is passed via FunctionCallbackInfo::Data
Data could be an External that points to a data structure holding a weak Global pointing back at the function.
Would that work for you?
I'm reverting in the meantime.
Enrico Pertoso
Software Engineer
Google Germany GmbH
Dienerstraße 12
80331 München
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank.
This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.
So it sounds like we can move forward with this change without too much hassle for embedders anyway. Awesome.