comes to software engineering. To many of us who have been into programming languages, compilers and virtual machines for some time, this still
point of view, nor does it have a great standard library.
becoming the dominant technology on the server-/cloud-side (via Node.js), and even finding its way into the IoT space.
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.