V8 also has garbage collection and multi-programming language support as well as spawning multiple threads. The difference is that V8 handles all those features differently.

The V8 language support is a bit different, but we know almost hundreds of languages which compile to JavaScript (ES3) or JavaScript (ES5) and asm.js (soonish WebAssembly - very similar to bytecode you know from the JVM).

In the V8 land, you also can't allocate memory or free memory as you wish; V8 handles it just like the JVM. The V8 garbage collector continuously checks for references before marking used memory as free again.

V8 has also multi-threading, but it doesn't pass that feature down to JavaScript or ams.js, unlike the JVM.

The reason for those differences between V8 and JVM are quite clear to me. V8 operates in the browser and browsers are only slowly partitioning UI tasks into chunks of computations ready to spread across multiple processing cores. Extracting V8 from the browser and stuff into an independent executable (which we know as Node.js) isn't enough to get compiler based language support or ready to use multi-threading.

I have hope that WebAssembly will change many of those aspects. We just need one or some languages with concurrent operational feature support which compile to WebAssembly bytecode. JavaScript doesn't need multithreading, IMO.

In terms of adoption, maybe. It has a long way to go but it has a momentum.

In terms of feature parity, probably not. The JVM is a beast of a platform with tons of features that I personally don't use. I hope Node.js remains mean and lean.