create blog

go home go home
  1. about
  2. code
  3. wiki
  4. blog

Archive for the ‘V8’ Category

Making SproutCore Objects Show in Chromium’s Heap Profiler

Tuesday, December 15th, 2009

It’s a hack. If Chromium+v8 would just support displayName, it could all be nice and clean and part of SproutCore (please go tell the Chromium folks how helpful this would be).

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. :)

Tags: , , ,
Posted in Code, Script, SproutCore, V8, Web | 2 Comments »

Script & the USPS Intelligent Mail Barcode

Monday, March 16th, 2009

We need a way to integrate the new USPS Intelligent Mail Barcode nicely into our existing workflow. The software we use for most of our composition seems to have some… disagreements (or something)… with it at times, even though it officially supports 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.

(more…)

Posted in Barcode, Framework, Script, Shell, USPS, V8 | No Comments »

v8, Application Exit, and Destructors

Friday, February 20th, 2009

While working on a utility that may perhaps evolve into the next version of the Engine, written primarily in JavaScript, I ran into a small problem when I tried to wrap output files for use in JavaScript.

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.

(more…)

Posted in Script, V8 | No Comments »

On V8 and Multithreading

Monday, February 2nd, 2009

V8 is not thread-safe. Just look at the code for HandleScopes, located in handles.h:

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.

Tags:
Posted in V8 | No Comments »

Interesting Bug #1: The Case of the Sticky Object

Monday, February 2nd, 2009

In my post on persistent handles, I mentioned that it is good to keep a map between native C++ objects and their JavaScript wrappers, so that you can reuse the wrappers.

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?

Posted in Bugs, Script, V8 | No Comments »

Persistent Handles

Saturday, January 31st, 2009

You probably don’t like memory leaks. I don’t. But, if you have one object that needs to pass between two languages — C++ and JavaScript — each of which may keep that object indefinitely, it can become tricky to make sure that any given object is destroyed, and that it is destroyed at the right time.

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.

(more…)

Posted in Script, V8 | No Comments »

V8 Objects

Thursday, January 29th, 2009

So, a problem arose.

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.

(more…)

Posted in Script, V8 | 11 Comments »