k: Homebrew OpenJDK breaks `kserver`

The kserver currently serves 3 purposes:

• eliminate the startup time by running in the same JVM
• reduce thread contention. We use a lot of threads, and having a single synchronized threadpool helps with performance
• reuse caches. Since we run in a single process, we don’t have to reload cached parsers and definitions for each test.

From my understanding, GraalVM would help with the first one but not 2 and 3. The other thing I was worried about was having a new dependency. K already has so many things that it requires. We had to invent kup because people found it very hard to install our tools.

I personally would prefer graalvm because of the advantage of not having to start a server, but people had concerns about the cons I mentioned above when we considered it previously.

We’re essentially maintaining the code we use ourselves at this point, in our fork of nailgun. We can consider other options, but I think it’s fine to maintain it ourselves… It doesn’t require much maintenance overall.

That being said, graalvm is the way to go if we don’t want to use nailgun anymore.

Pros:

• almost as fast as nailgun
• Don’t have to maintain it ourselves
• doesn’t require you to start a server
• code to get k working is already written

Cons:

• not quite as fast as nailgun
• doesn’t support arbitrary reflection, requiring you to keep track of exactly which attributes you reflectively access
• Less platform independent
• tends to cause the application to crash if you try to do something and it’s not configured correctly