I was asked to look at the use of FunctionTemplate objects as arguments in
apinatives.js, and to find ways to replace them with
real JS objects and values. Here are some proposed new designs for function
and object templates. My suggested solution is to
do nothing, and leave them as they are, but here are other possibilities.
First, the attached PDF is a diagram of the uses of FunctionTemplate as a
function argument, in C++ and in JS. Bold lines indicate
that the higher function calls the lower function with a FunctionTemplate
argument. Bold function names are C++ functions, light function
names are JS functions.
1) Function templates and object templates are used exclusively (?) by V8
embedders, using the API. These uses are crucial, though,
and must be supported in basically their present condition.
2) Function templates include parents, children, prototypes, and values that
are also function and object templates, so creating an instance of
a template often means creating instances of the contained template as well.
3) The code for instantiating a function template or object template
executes the JavaScript code in apinatives.js. This code includes control
flow, object allocation, mutual recursion, and assigning values to fields.
It is in JavaScript mainly because it involves so many object allocations,
connected by complex control flow. C++ code should execute at most one or
two allocations before possibly garbage collecting, and would
include many checks and retries, with objects all stored in handles, to
implement this.
4) In the API and JavaScript code, the FunctionTemplates are passed as type
Handle<Template>, a sibling type of Handle<Value>. All JS Objects and
primitives are subtypes of Value, and cannot be mistaken for Templates
without an explicit type cast. The API methods for calling functions and
for setting properties all take arguments of type Handle<value>, so
templates cannot be used improperly in the API in these methods. The
only API functions that take Handle<Template> as arguments are the methods
of FunctionHandle, ObjectHandle, and related classes.
5) The file apinatives.js contains the three JS functions that process
function and object templates. They are mutually recursive, since many
connected templates may need to be instantiated together. They are called
with templates, and pass templates back to C++ code that actually
creates the function objects by calling Runtime_CreateApiFunction. This
code is isolated from all other JS code, and is not called from other JS
code. This short file should be read to understand the current use of JS in
processing templates.
Possible changes:
A) Rewrite the functions in apinatives.js in C++, using explicit tests for
allocation failure and calls to the GC.
B) Rewrite all uses of function templates to use a function template class
that is based on JSObject or another real JS type.
This has the following disadvantages:
i) Templates are created by embedding apps before a V8 context has been
created. JSObjects need a context, though this
might be worked around.
ii) It then becomes possible to mix up templates with real JS objects,
and store and use them in other JS code, without noticing.
Currently, templates are not JS objects, they have a different type
tag in their maps, and they should cause rapid and obvious failure if they
are misused.
C) Leave the code as is. Currently, Handle<Template> objects are completely
distinct from Handle<Value> objects, and cannot be passed into JavaScript.
The only place they are cast, and passed in to apinatives.js, are in the
three C++ wrappers of the three functions in apinatives.js, in execution.cc.
A is not a completely ridiculous choice, since so much of apinatives.js code
consists of calls to C++ functions and tests of C++ data anyway.
B seems quite pointless and a huge amount of work.
C sounds good.
--
We can IMAGINE what is not
--~--~---------~--~----~------------~-------~--~----~
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
-~----------~----~----~----~------~----~------~--~---
