As it is, this hack could have some SEVERE side-effects, but chances are, if you are trying to debug a memory leak, you won’t care about these side-effects because everything else will be driving you MAD (and, you’ll probably be able to find these side-effects much more easily than the leak itself).

It is very simple; here is how to do it for ListItemView:

SC.mixin(SC.ListItemView, { create: function() { return new SC._ListItemView(this, arguments); } });
 
SC._ListItemView = function(base_type, args){
  base_type.call(this, args);
};
 
// for extra safety (should get around most potential side-effects):
SC.mixin(SC._ListItemView, SC.ListItemView);
 
SC._ListItemView.prototype = SC.ListItemView.prototype;

Now, ListItemViews will show up as SC._ListItemView in the heap profile. Hooray!

P.S. This revealed for me that the objects leaking were not SC.ListItemViews. I still have no idea what is leaking, and am giving up for now—but at least I’ll have better tools when I come back to it. :)

Other people using the same software recommend using the USPS’s library. That’s fine and all, but we don’t want to write a C program for each job — writing in C or C++ can be quite time consuming. And it requires compiling, creating projects, etc. In short, a lot of hassle.

While this may not be the course we end up following, I decided, tonight, that although I was half-asleep, I’d attempt to add scripting support for USPS’s library. At around 10:00, I downloaded the software from USPS. Now, roughly fifty minutes later, I have managed to write a script that uses the USPS barcode.

Here’s the script:

function main(input, output)
{
	var inputFile = new InputStream(input);
	var outputFile = new OutputStream(output);
 
	while (inputFile.ok)
	{
		//get line
		var line = inputFile.getLine();
 
		//split
		var fields = line.splitQuoted(",");
 
		//if there aren't the required amount of fields, continue to next line (if any)
		if (fields.length < 2)
		{
			outputFile.writeLine(line);
			continue;
		}
 
		//get needed fields
		var track = fields[0].trim(), route = fields[1].trim();
 
		//set output
		line = line + ",\"" + USPSBarcode.encode(track, route) + "\"";
 
		//write
		outputFile.writeLine(line);
	}
}
 
<!-- snipped: the splitQuoted string function -->

The Framework’s Script Engine made adding this to the Shell very easy (really, it should be moved into Spec, and Shell should get it from there, but for now…).

I will, over the course of the next couple of days, figure out a workflow for how I can get this code online without breaking the build for compiles without the library. Perhaps a command line switch? I will probably also move it to where it belongs: in Spec.

I will, however, go ahead and post the majority of the code here. I could have done it much quicker with a single function in global scope, but I prefer the cleanliness of using a JavaScript object (I could have still used an empty dummy object, but that wouldn’t have been proper).

#ifndef SHELL_WRAPPERS_USPSBARCODEWRAPPER_H_
#define SHELL_WRAPPERS_USPSBARCODEWRAPPER_H_
 
#ifdef SHELL_WITH_USPS_BARCODE
 
#include <string>
 
extern "C" {
	int USPS4CB( char *TrackPtr, char *RoutePtr, char *BarPtr);	
}
 
namespace Shell
{
	class USPSBarcodeProvider
	{
	public:
		USPSBarcodeProvider()
		{
 
		}
 
		std::string encode(std::string tracker, std::string route)
		{
			if (tracker.size() != 20)
			{
				return "";
			}
			if (
				route.size() != 11 && 
				route.size() != 5 && 
				route.size() != 9 &&
				route.size() != 0)
			{
				return "";
			}
 
			char res[66];
			int result = USPS4CB(
								 const_cast<char *> (tracker.data()), 
								 const_cast<char *> (route.data()), 
								 res
			);
			if (result != 0)
				return "";
 
			res[65] = NULL;
 
			return res;
		}
	};
}
 
ScriptBaseNative(Shell::USPSBarcodeProvider);
 
namespace Shell
{
	SWrap(USPSBarcodeWrapper, USPSBarcodeProvider)
	{
	public:
		USPSBarcodeWrapper()
		{
			set("encode", $(encode));
			className = "USPSBarcodeProvider";
		}
 
		SMember(encode)
		{
			if (extract(self))
			{
				return $(extract(self)->encode(arguments[0]->stringValue(), arguments[1]->stringValue()));
			}
 
			return $();
		}
	};
 
}
 
#endif
 
#endif

v8, when it “goes away” at program end, does not collect its garbage. Not usually a problem, as most of the time, the operating system will clean up after you. But I didn’t need the memory cleared. I needed a destructor called.

The output file wrapper was wrapping a class which wrapped ostream. The standard library stream usually uses a buffer, and only calling flush() or destroying the stream flushes it to the actual output. I needed this to happen automatically, so I wrote up a simple template class, AutoDestroy, along with a helper function, autoDestroy.

I call it roughly like this, but with smart pointers and other code mixed in:

//create a stream
OutputStream *stream = new OutputStream();
 
//set auto destroy
autoDestroy(stream);
 
//stream is deleted
delete stream;
 
//cancel auto destroy
cancelAutoDestroy(stream);

The code itself is pretty simple. There are probably some ways that are even simpler, more elegant, and take fewer lines of code, but this does seem to work:

/*
 * This template class is a very simple class which allows registration of items
 * needing destruction.
 *
 * Very simple: a set of items to destroy, and a map to keep track of how many
 * destruction references there are (allowing add and remove to be called
 * more than once).
 *
 * It is split into two parts (the AutoDestroy class and Destroyer) so that
 * the actual destruction call can be overridden (by specializing Destroyer).
 */
 
 
#include <set>
#include <map>
 
namespace Shell
{
	template <typename T> class Destroyer
	{
	public:
		Destroyer(T *what)
		{
			this->ptr = what;
		}
 
		void destroy()
		{
			delete ptr;
		}
 
	protected:
		T *ptr;
	};
 
	template <typename T> class AutoDestroy
	{
	public:
		static void Add(T *what)
		{
			Instance()->add(what);
		}
 
		static void Remove(T *what)
		{
			Instance()->remove(what);
		}
 
		virtual ~AutoDestroy()
		{
			typename std::set<T *>::iterator i;
			for (i = autoDestroy.begin(); i != autoDestroy.end(); i++)
			{
				Destroyer<T> destroyer(*i);
				destroyer.destroy();
			}
		}
 
		static AutoDestroy *Instance()
		{
			static AutoDestroy instance;
			return &instance;
		}
	protected:
		std::map<T *, int> references;
		std::set<T *> autoDestroy;
 
		void add(T *what)
		{
			//if it doesn't exist yet, add it.
			if (autoDestroy.count(what) < 1)
			{
				//insert into auto destroy list
				autoDestroy.insert(what);
 
				//set reference to 1
				references[what] = 1;
 
				//return because references is already 1
				return;
			}
 
			//increment reference
			references[what]++;
		}
 
		void remove(T *what)
		{
			//if it doesn't exist, return
			if (autoDestroy.count(what) < 1)
				return;
 
			//decrement references, and if there aren't any, remove from list.
			if (--references[what] <= 0)
			{
				autoDestroy.erase(what);
				references.erase(what);
			}
		}
	};
 
	/* Helper functions to make things dead simple */
	template<typename T> void autoDestroy(T *what)
	{
		AutoDestroy<T>::Add(what);
	}
 
	template<typename T> void cancelAutoDestroy(T *what)
	{
		AutoDestroy<T>::Remove(what);
	}
}

static v8::ImplementationUtilities::HandleScopeData current_;
const v8::ImplementationUtilities::HandleScopeData previous_;

The way HandleScopes work is simple: each handle is allocated in the current handle scope (HandleScope::current_). When a new HandleScope is created, it sets its previous_ to the previous one, and changes current_ to itself. The current handle scope is stored statically — in short, shared between all threads.

Logic dictates that this would cause problems in multithreading. Big time.

Consider the following overly simplified example:

//thread 1
HandleScope handle_scope;
 
//thread 2
HandleScope handle_scope;
 
//thread 1
Local<Value> test = String::New("test"); //allocated in thread 2's context scope!
 
//thread 2 closes, destroying its handle scope, and thus
//test, which was allocated inside of it
return;
 
//thread 1 continues, and likely crashes, as it tries to use test, which was
//mistakenly allocated inside of thread 2's handle scope (and thread 2's
//handle scope has now ended).
if (test->IsString())
{
 
}

“That’s why that is no work.”

Update: With enough locking, it is possible. v8 even has a Locker object to help. But it is still quite tricky, and appears to be prone to failure. I haven’t tested it much myself, as I currently don’t have a need for threading.

It would still be quite dangerous, especially if one unlocks while inside of a HandleScope.

I also mentioned that I clear V8′s reference to the native object when C++ “forces” a destroy.

Everything worked, except one thing: when I cleared the reference to the native object, I did not clear the reference from the map. Lo and behold, at some later point in time, when such an object is created again, the pointer to the original is still in my map. So, when I ask the map if a wrapper exists, it does. And its reference is NULL. So, I just passed a non-NULL object to JavaScript, and JavaScript got a NULL value.

All I needed to do to fix it was add a std::set of things to alert to the clearing of the reference, add the map-containing object to that set, and call a function which erases the entry in the map-containing object when the reference is cleared.

It is quite lucky for me that this bug occurred. It occurred due to an unintended consequence of normal object destruction. Accidentally, when the object was destroyed even through a process initiated from JavaScript, the “force destruction” message was sent out. Had this unintended side-effect to destruction not been there, I would not have noticed anything, and some wacky consequences of reusing wrappers for unrelated objects could have been extremely difficult to debug.

A bug a day keeps the doctor away?

There are two things that can happen: an object can be deleted two soon, while it is still being used elsewhere — causing some particularly delicious crashes — or, an object can be deleted too late (or not at all), causing memory leaks.

Consider the point wrapping function from my previous post:

Handle<Object> wrapPoint(Point *pointToWrap) 
{
    //enter a handle scope
    HandleScope handle_scope;
 
    //create a new point instance
    Local<Object> point_instance = point_templ->NewInstance();
 
    //set that internal field
    point_instance->SetInternalField(0, External::New(pointToWrap));
 
    //to prevent the point_instance from being destroyed when its
    //scope handle_scope is, use the Close() function
    return handle_scope.Close(point_instance);
}

What would happen if you passed a point wrapped using this function to JavaScript, and whatever JavaScript code you had decided to store it? It would then be a very bad idea to destroy it from C++: JavaScript would not know it was destroyed. If, for example, an accessor was called, it would call the C++ function corresponding to the accessor, and that C++ function would try to operate on the pointer stored in the internal field — the pointer to the point you destroyed.

There are a few possible solutions to the problem:

• Let JavaScript destroy it. For this, you need to know when JavaScript is no longer using the object. Thankfully, this is possible.
• Have C++ alert JavaScript to the destruction. For this, you’d have to keep track of the JavaScript object, which means you’d have to keep an active reference to it. As normal local handles get destroyed when their context scope goes away, you need a way to make sure the object sticks around in JavaScript, or a way to know that if it is no longer referenced in JavaScript, or both.
• Use smart pointers. In this case, you might store a pointer to a smart pointer to the object in the internal field. You’d still need to know when the object was no longer being used in JavaScript so you could get rid of that smart pointer, but in this case, the object will stick around so long as there is a reference to it from either C++ or JavaScript.
• Hybrid. Perhaps you will need to have the ability to keep objects alive by referencing them from JavaScript, but there are some situations in which you simply want to get rid of them (and JavaScript should no longer be able to access them). In this case, you need to keep track of the objects and use a smart-pointer like methodology. I won’t go into this, as it is (at least the method I use) a bit too tedious to go over in detail.

Note: Keeping track of the wrapped C++ objects in JavaScript can be useful for reasons other than memory management. The technique (which is also used in Google’s Chrome browser) also allows you to generate and reuse a single wrapper for any given object. In addition to being more memory efficient, this also allows JavaScript to add things to the object that will be remembered even if it jumps between languages a few times.

All of these techniques have one thing in common: they require the use of persistent handles.

Persistent Handles

A persistent handle is much like a C++ pointer:

//something like Value *value = new String("Hello, World");
Persistent<Value> value = Persistent<Value>::New(String::New("Hello, World"));
 
//something like delete value
value.Dispose();
 
//something like value = NULL;
value.Clear();

Persistent handles seem to be a bit like a handle pointing to a handle. The handle being pointed to will not be destroyed until it is specifically told to.

For instance, the following will cause memory leaks:

//something like Value *value = new String("Hello, World");
Persistent<Value> value = Persistent<Value>::New(String::New("Hello, World"));
 
//like setting value = new String("Hello, World 2"); Where does the previous string go?
//answer: it floats.
value = Persistent<Value>::New(String::New("Hello, World 2"));
 
//and what about if we don't dispose of our persistent pointer
//if we don't do the equivalent of calling "delete value;"
return NULL;

You might be able to see how this could be used to keep a reference in a map between C++ objects and JavaScript objects, so that you could clear the JavaScript object’s internal field:

std::map<Point *, Persistent<Object> > jsPoints;

And then you could force the deletion of one something like this:

void destroyJSPointReference(Point *point)
{
    //get the corresponding object
    Persistent<Object> object = jsPoints[point];
 
    //clear internal field
    object->SetInternalField(0, NULL);
 
    //dispose and clear so that it will go away when nothing points to it
    object.Dispose();
    object.Clear();
}

Weak Handles

But what if we wanted to know when JavaScript no longer uses an object? For that, we make the persistent handle weak. A weak persistent handle triggers a callback function when only weak handles point at an object. So, an adjusted wrapping function might look like this:

Handle<Object> wrapPoint(Point *pointToWrap) 
{
    //enter a handle scope
    HandleScope handle_scope;
 
    //store the wrappers in a map so that we don't double-delete. It's like double-dipping,
    //but seven times worse.
    if (jsPoints.count(pointToWrap) > 0)
        return jsPoints[pointToWrap];
 
    //create a new point instance and point to it with a persistent handle
    Persistent<Object> point_instance = 
    Persistent<Object>::New(point_templ->NewInstance());
 
    //make the handle weak, with a callback
    point_instance.MakeWeak(pointToWrap, weakPointCallback);
 
    //add it to the map
    jsPoints[pointToWrap] = point_instance;
 
 
    //set that internal field
    point_instance->SetInternalField(0, External::New(pointToWrap));
 
    //to prevent the point_instance from being destroyed when its
    //scope handle_scope is, use the Close() function
    return handle_scope.Close(point_instance);
}
 
void weakPointCallback(Persistent<Value> object, void *parameter)
{
    Point *point = static_cast<Point *> (parameter);
 
    //remove it from the map
    jsPoints.erase(point);
 
    //javascript no longer uses the object
    //if we are certain C++ isn't using it, we could "Let JavaScript destroy it":
    delete point;
 
    //clear the reference to it
    object.Dispose();
    object.Clear();
}

Now, using smart pointers in the mix is relatively easy, but will depend on what kind of smart pointer methodology you use — my example may not apply to you. If you really really don’t want to use smart pointers, you can still achieve a bit of the same effect — although I don’t recommend it. Consider:

std::set<Point *> usedInCPP;
std::set<Point *> usedInJS;
 
void JSDeletePoint(Point *point)
{
    usedInJS.erase(point);
    if (usedInCPP.count(point) == 0)
        delete point;
}
 
void CPPDeletePoint(Point *point)
{
    usedInCPP.erase(point);
    if (usedInJS.count(point) == 0)
        delete point;
}

Something like this could allow you to keep track of references.

Using smart pointers is much easier. Note: my smart pointer type is named R:

 
Handle<Object> wrapPoint(R<Point> pointToWrap) 
{
    //enter a handle scope
    HandleScope handle_scope;
 
    //store the wrappers in a map so that we have only one wrapper per object
    if (jsPoints.count(pointToWrap) > 0)
        return jsPoints[pointToWrap];
 
    //create a pointer to a smart pointer by making a new smart pointer
    R<Point> *point = new R<Point> (pointToWrap);
 
    //create a new point instance and point to it with a persistent handle
    Persistent<Object> point_instance = 
    Persistent<Object>::New(point_templ->NewInstance());
 
    //make the handle weak, with a callback
    point_instance.MakeWeak(point, weakPointCallback);
 
    //add it to the map
    jsPoints[pointToWrap] = point_instance;
 
 
    //set that internal field to the pointer to the smart pointer
    point_instance->SetInternalField(0, External::New(point));
 
    //to prevent the point_instance from being destroyed when its
    //scope handle_scope is, use the Close() function
    return handle_scope.Close(point_instance);
}
 
void weakPointCallback(Persistent<Value> object, void *parameter)
{
    R<Point> *point = static_cast<R<Point> *> (parameter);
 
    //remove it from the map
    jsPoints.erase(*point);
 
    //delete the smart pointer
    delete point;
 
    //clear the reference to it
    object.Dispose();
    object.Clear();
}

That’s roughly what I do in the script engine, but I also have the ability to force the deletion of an object entirely. I do this by not actually giving a pointer, or a pointer to a smart pointer, to JavaScript at all, but instead giving it a smart pointer to a class which wraps the object. This wrapper can then be alerted when the object is destroyed, and its reference to the object will then be cleared.

I hope some people will find this helpful — I would have liked to have it when I was starting out with V8 a couple of weeks ago.

Please feel free to correct me or ask questions if you see anything fishy or strange.

Update: I realized I was forgetting to dispose of the persistent handle in the two examples above (lines object.Dispose and object.Clear). I have corrected this.

I wanted to account for two possibilities in the Script Engine: Passing existing objects from C++ to JavaScript, and creating new C++ objects from JavaScript. The act of passing a native object into scripting languages is usually referred to as wrapping (although, at one point inside the engine, I actually refer to a part of the process as unwrapping).

The code I would like to be able to use is:

//create a point
Point *point = new Point(.42, 42);
 
//pass it to some JavaScript function
myJavaScriptFunction->Call(pointWrap(point), 0, NULL);

//create a Point
var point = new Point();
 
//set its X value
point.x = 4.2;
 
//call some C++ function using it
myCPPFunction(point);

So how did I manage this in the engine? Well, as I am prone do, I overcomplicated it.

I started by finding examples. V8 being as young as it is, there weren’t many. However, I did manage to find one in some older posts on the v8-users discussion group. Modeling my code off that, I came, unfortunately, to the wrong conclusion. Instead of covering the wrong conclusion first, which I feel will merely lead to confusion, I’ll cover the way I discovered was correct.

First, a summary of class and prototype paradigms.

Paradigms

If you think about a class, you’ll realize there are a few different elements:

• Constructors
• Properties
• Functions
• (Maybe) Destructors

To wrap an object in a V8-accessible form (a v8::Object) you will want to connect some or all of these to JavaScript.

In JavaScript, if an object has a constructor, it is in fact an instance of that constructor. Consider:

//make a constructor
var MyClass = function(argument) {
    this.value = argument;
}
 
//add functions all instances should have
MyClass.prototype.say = function() {
    alert(this.value);
}
 
//make an instance
var testClass = new MyClass("test");
testClass.say(); //alerts "test"

This creates a new instance of the MyClass function. Creating an instance calls the function, setting this.value to argument, which, in this case, equals “test.”

Google does not give you C++ APIs that work in the JavaScript paradigm. Nor do they give APIs that work in the C++ paradigm. I think they were trying to make it so that you could pretend the model was a class model (like C++), but there is only so far you can go while still maintaining the full ability to manipulate the JavaScript model. This adds a bit of confusion.

Wrapping

So, how do you force the rigid C++ class structures into this JavaScript prototype-based paradigm? There are two parts of this problem. The first is how to create new objects (constructors). The next is how those objects should act once they are responding.

We shall start with the second, because things are easier if you do them in that order.

Objects themselves (not their constructors) must be wrapped in V8 templates. I use FunctionTemplates to wrap the objects. The process is simple, and an example is on V8′s website. I’ve modified it a bit. They use ObjectTemplates. I use FunctionTemplates because they are more proper: not only does JavaScript use them to initialize objects, but they (not ObjectTemplates) are the only ones able to inherit from other templates (though I do not actually use that feature).

So, to prepare a template for, say, a Point, you might do something like this:

//create your function template
Handle<FunctionTemplate> point_template = FunctionTemplate::New();
 
//get the point's instance template
Handle<ObjectTemplate> point_instance_template = point_template->InstanceTemplate();
 
//set its internal field count to one (we'll put references to the C++ point here later)
point_instance_template->SetInternalFieldCount(1);
 
//add some properties (x and y)
point_instance_template->SetAccessor(String::New("x"), GetPointX, SetPointX);
point_instance_template->SetAccessor(String::New("y"), GetPointY, SetPointY);

Tada! Now you have a template.

Now that you have a template, you will want to wrap it:

Handle<Object> wrapPoint(Point *pointToWrap) 
{
    //enter a handle scope
    HandleScope handle_scope;
 
    //create a new point instance
    Local<Object> point_instance = point_templ->NewInstance();
 
    //set that internal field
    point_instance->SetInternalField(0, External::New(pointToWrap));
 
    //I'm skipping some Persistent MakeWeak goodness right here
 
    //to prevent the point_instance from being destroyed when its
    //scope handle_scope is, use the Close() function
    return handle_scope.Close(point_instance);
}

That’s pretty simple. Now, what about constructors?

There are two ways to do this. The first is the way I ended up using.

This way is very simple. In it, you do not use the same FunctionTemplate for the constructor as you do for the template. That’s what I did at first, and I’ll explain why it didn’t work in a moment. While it may be a function, that does not mean it automatically works as a constructor.

Instead of reusing the same FunctionTemplate and simply giving it a C++ function to call, you can make a brand new FunctionTemplate:

//get your scope
v8::HandleScope handle_scope;
 
//Get your V8 Context
Handle<v8::Context> context = myContext;
 
//Start a context scope
v8::Context::Scope context_scope(context);
 
//Get the context's global scope (that's where we'll put the constructor)
v8::Handle<v8::Object> global = context->Global();
 
//create function template for our constructor
//it will call the constructPoint function
v8::Handle<v8::FunctionTemplate> function = v8::FunctionTemplate::New(constructPoint);
 
//set the function in the global scope -- that is, set "Point" to the constructor
global->Set(v8::String::New("Point"), function->GetFunction());

And, of course, the function it calls:

v8::Handle<v8::Value>constructorCall(const Arguments &args)
{
	// throw if called without `new'
	if (!args.IsConstructCall()) 
		return ThrowException(String::New("Cannot call constructor as function"));
 
	//start a handle scope
	v8::HandleScope handle_scope;
 
	//get an x and y
	double x = args[0]->NumberValue();
	double y = args[1]->NumberValue();
 
	//generate a new point
	Point *point = new Point(x, y);
 
	//return the wrapped point
	return wrapPoint(point);
}

Pretty simple. We simply create a point, and pass it to the point wrapper. Ironically, something akin to this is what I attempted first, although I did it wrong. I then looked for examples, and found one that did it incorrectly. Finally, I spent several hours debugging, until I finally figured out this seemingly proper, and very simple way (anyone, feel free to correct me). While my actual code is not quite as simple as this (as I do several memory management- and abstraction-related things in there as well), this covers the point.

So what did I do wrong?

What I Did Wrong

The mistake I made was to try to use only one FunctionTemplate. Instead of having two separate ones, I made one single one. It was both the constructor and the template. Both functions had their own wrapping code (I had tried calling the wrapping function from the constructor, but it caused a recursion error, for reasons that will become clear).

Constructing worked great, I couldn’t have been happier. But wrapping had problems. I noticed that even when I tried to wrap an existing object, the constructor function was called, creating a brand new one! After a bit of debugging, I traced it down to the function’s NewInstance function.

Remember that JavaScript, when it creates a new instance of a function, calls the function. Well, I was creating a new instance of the function, and so, since I had a function (the constructor) to be called, it was. This caused a new C++ object to be created whenever I wrapped an existing one. That object would then go float around in memory, as it was replaced by the wrapping function’s SetInternalField call.

Due to the way I was managing memory, this extra allocation of objects did not seem to cause a memory leak. Still, having an extra object floating around for an object’s lifespan did not sound good, so I had to find a way to fix it. And, finally, I did.

It did take a few hours, however, and, unfortunately, I was not on the clock at the time.

Update: As Matthias Ernst pointed out, my example was adding properties directly to the FunctionTemplate instead of to the Function Template’s instance template.

Update: The Second Way: Copy Constructor Method

Thanks to Christian Plesner Hansen for giving another way around this problem!

Instead of having two FunctionTemplates, you can use one, and just pass the constructor an argument pointing to the existing object:

v8::Handle wrapPoint(Point *value) {
  v8::HandleScope scope;
  v8::Handle cons = pointConstructor->GetFunction();
  v8::Handle external = v8::External::New(value);
  v8::Handle result = cons->NewInstance(1, &external);
  return scope.Close(result);
}

Within the constructor you check if the first argument is an external, and if it is you don’t construct a Point:

v8::Handle constructorCall(const v8::Arguments& args) {
  v8::HandleScope scope;
  v8::Handle external;
  if (args[0]->IsExternal()) {
    external = v8::Handle::Cast(args[0]);
  } else {
    int x = args[0]->Int32Value();
    int y = args[1]->Int32Value();
    Point *p = new Point(x, y);
    external = v8::External::New(p);
  }
  args.This()->SetInternalField(0, wrapper);
  return args.This();
}

Chrome’s Method

In web pages, most elements are not created using constructors. Instead, they are created using the document.createElement() function. One notable exception is the img element, which may also be created using a constructor.

Chrome handles this, from what I can tell by reading their code generators, etc., by running a script similar to the following in V8:

function Image() {
                        return document.createElementNS(
                          'http://www.w3.org/1999/xhtml', 'img');
                      };
                      Image

I think they do this so they can lazy-load the Image function, as many pages don’t use it at all.