I guess the point of posting it here is to gather folks with pitchforks and torches demanding immediate attention to the issue. For a few months V8 team has been working hard on improving the GC (http://code.google.com/p/v8/source/browse/branches/experimen...) which was the major limiting factor here. I don't have an ETA of when it's going to be merged, but the new GC branch is in a pretty good shape.
Tip: to make V8 startup and context creation significantly faster add 'snapshot=on' to your scons command line. This serializes the default heap during compilation and quickly deserializes it on startup later.
In V8 Object.create(arg) is implemented roughly as var o = {}; o.__proto__ = arg. The first statement sets the default hidden class for the newly created object. Since hidden classes in V8 capture the prototype structure as well, it has to change in the second statement. Now the problem is that unlike with normal properties no hidden class transition happens and we get a brand new hidden class each time.
Being prepared for an interruption does not mean paying attention to your surroundings or actively seeking distraction (e.g. checking email). The problem here is that even if you've made an attempt to block everything out but have not prepared yourself for an interruption, it still may happen and will severely hurt your productivity when you try to return to what you were doing. Keeping even very informal todo lists (e.g. comments in code, todo.txt) helps greatly when you need to quickly restore your context. Even if an interruption does not happen they give you a sense of direction and you can also use them to prepare future contexts for exploring ideas you came up with while working on the current task.
This is not really a kernel bug. The exploit exhausts the address space of Xorg (which is already running as root) to make it possible to write to its stack using a shared memory segment. While the kernel can help prevent this kind of issues by simply denying to map a page from the top of stack segment, it's still an Xorg's problem that it allows to exhausts its address space. In that state an attacker has much higher chances of making the process do desired memory writes and using shared memory segments is not the only option (as described in the original article this post links to).
The reason why some frameworks roll out custom object systems is because they try to make JavaScript look like a language with classes, "this" semantics isn't what's driving them. In a language with classes developers are used to "this" being an instance of the current class, and this expectation creates a consfusion in JavaScript. If you don't look at it through the prism of classes, the rule for "this" is pretty simple: "this" is the receiver. Create a function, apply it to any object, and that object will be the receiver available as "this". It's that simple. Now the only confusion left is who's the receiver. In "foo.bar()" like cases it's obvious, and the only remaining case (if you don't count the discouraged "with" statement) is "bar()" which calls a function on the global object (like in Python).
Thanks for the pointer. I've pushed a commit that avoids __proto__, and produces this...
CoffeeScript:
Horse extends Animal
JavaScript:
Horse.__superClass__ = Animal.prototype;
Horse.prototype = new Animal();
Horse.prototype.constructor = Horse;
Calling super uses the __superClass__ reference. I hate to add it as an enumerable property, but there doesn't seem to be any other way to get at it, and at least it's on the class and not the object.
It seems you should use "Horse extends Animal.prototype" in your examples or just make "Horse extends Animal" compile to "Horse.prototype.__proto__ = Animal.prototype". Also a subclass constructor should call the one of the superclass. Otherwise, a single Animal instance is shared by all subclass instances and for no reason Animal is created simply to declare a subclass.
