Making an Embedded DBMS JIT-friendly · HackerPapers discussions

Making an Embedded DBMS JIT-friendly — mentioned by BenoitP

Sat, 21 Jan 2017 10:50:50 GMT

Posting this mainly for the "fused VM" idea that I have seen floating around here: Having the language and the systems it talks to fused by a JIT that eliminates the communication overhead; which is something that (does?|can?|could?|will?) happen in this case. This is in the browser, but could apply to Node. In the JVM land we have the Truffle+Graal "one VM to rule them (languages) all" initiative which does this overhead elimination. wasm could be a serious contender with the JVM bytecode in the server space in this regard. On top of it, its platform offers more options for having the client…

Paper and discussion history. A mention is not an endorsement.

Making an Embedded DBMS JIT-friendly — mentioned by pron

Sun, 29 May 2016 04:34:38 GMT

> I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, and whose codebases are just as unoptimised for the perspective of the humans who have to work with them. I would, and I've been developing in Java for over ten years now, after ten years of C/C++. I think that your complaints have nothing to do with Java, and much to do with a coding style that became popular in the '90s. You could see the very same in C++ applications back then, but then Java took over. The big enterprise applications of the '90s…

Paper and discussion history. A mention is not an endorsement.

Making an Embedded DBMS JIT-friendly — mentioned by pron

Wed, 25 May 2016 23:01:18 GMT

Aside from Erlang which is far too slow (most Erlang apps use C for the data plane) the others are far too risky choices in terms of hiring, future support and general maintainability. Also there are far too many unknowns about them. Rust shows a lot of promise and may very well be suitable for this kind of things, but it may still be too young for an important infrastructure project at Twitter. It is also harder to program than in Java, although for an infrastructure project such as this, this may not be a deal breaker. Another reason to run on the JVM is that often your applications run on…

Paper and discussion history. A mention is not an endorsement.