So this is my attempt to start a series of blog posts about what’s going on behind the scenes of V8 in order to bring more transparency to what we do for
Node.js and Chrome, and how this affects developers targeting either Node.js or Chrome. I’ll
a few tooling/embedder related issues.
For the last couple of months we - together with some awesome Ember folks - have
been hunting a terrible bug in V8, that I used to call “the Ember issue”, because this bug especially affects
websites based on the Ember.js framework. Ember.js was never really great in Chrome - i.e. there have been reports of serious
performance problems in 2013 already, when I had just joined the V8 team - but it seems like
it got worse recently, leading to increased load time and pretty serious jank - up to two second pauses - even though we spent a lot of resources
on techniques like the Idle-Time Garbage Collection Scheduling and
other jank related
improvements that should avoid exactly these problems.
performance recently, where performance means both peak performance (as in throughput of long running computations)
as well as user visible latency (as in time wasted not doing useful work towards completing a computation or rendering a
The Strato Linux V-Servers always reset their hostnames to
hXXXXXX.stratoserver.net on boot, no matter what you put in
/etc/hostname and there’s no way to fix this (it’s actually intended behavior). If you happen to have a Strato V-Server running Debian, here’s a simple failsafe way to fix the hostname early during boot and have all daemons use your desired hostname.
I spent some time getting a decent cross compiler toolchain for
arm-linux-gnueabi running on Mac OS X, including GNU binutils 2.22, gcc 4.6.2 and OCaml 3.12.1. The cross compiler toolchain targets ARM boards running Debian/armel squeeze or later.
I decided that it was about time to get used to OASIS, that new all-in-one build system generator for OCaml projects. So I started by getting it up and running using various local MacPorts. Once everything was up and running, I started to switch my implementation of Red-Black Trees for OCaml to use OASIS instead of my custom
Makefile-based approach. That went amazingly well, and so here’s my first release, version 0.1.0, of
ocaml-rbtrees featuring an OASIS-generated build system.
This paper presents the current state of our work on an interactive toplevel for the OCaml language based on the optimizing native code compiler and runtime. Our native toplevel is up to 100 times faster than the default OCaml toplevel, which is based on the byte code compiler and interpreter. It uses Just-In-Time techniques to compile toplevel phrases to native code at runtime, and currently works with various Unix-like systems running on x86 or x86-64 processors.