Thread pools on the JVM should usually be divided into the following three categories:
- CPU-bound
- Blocking IO
- Non-blocking IO polling
Each of these categories has a different optimal configuration and usage pattern.
I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.
This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea
(* The syntax of our calculus. Notice that types are represented in the same way | |
as terms, which is the essence of CoC. *) | |
type term = | |
| Var of string | |
| Appl of term * term | |
| Binder of binder * string * term * term | |
| Star | |
| Box | |
and binder = Lam | Pi |
trait Interp { | |
type Repr<T>; | |
fn lit(i: i32) -> Self::Repr<i32>; | |
fn add(a: Self::Repr<i32>, b: Self::Repr<i32>) -> Self::Repr<i32>; | |
} | |
struct Eval; | |
impl Interp for Eval { |
#! /usr/bin/bash | |
# $ echo -n Π U Z Π 0 Π 1 U Z > Id | |
# $ ./dtt.sh λ U Z λ 0 λ 1 β β β Id 2 1 0 | |
# INFER: Π U Z Π 0 Π 1 U Z | |
# EVAL: λ U Z λ 0 λ 1 β β β Id 2 1 0 | |
function head() { | |
echo $* | cut -d" " -f1 | |
} |
type term = | |
| Lam of (term -> term) | |
| Pi of term * (term -> term) | |
| Appl of term * term | |
| Ann of term * term | |
| FreeVar of int | |
| Star | |
| Box | |
let unfurl lvl f = f (FreeVar lvl) |
// >> inter(["a", "b", "c"], "d") | |
// ["a", "d", "b", "d", "c"] | |
function inter<T>(xs: T[], s: T): T[] { | |
return xs.flatMap((x, i) => i === xs.length - 1 ? [x] : [x, s]); | |
} | |
// >> extractTok("ab,cd,ef", ",") | |
// ["ab", ",", "cd", ",", "ef"] | |
function extractTok(tok: string, template: string): string[] { |
This is the predecessor of Mazeppa.
Supercompilation is a deep program transformation technique due to V. F. Turchin, a prominent computer scientist, cybernetician, physicist, and Soviet dissident. He described the concept as follows [^supercompiler-concept]:
A supercompiler is a program transformer of a certain type. The usual way of thinking about program transformation is in terms of some set of rules which preserve the functional meaning of the program, and a step-by-step application of these rules to the initial program. ... The concept of a supercompiler is a product of cybernetic thinking. A program is seen as a machine. To make sense of it, one must observe its operation. So a supercompiler does not transform the program by steps; it controls and observes (SUPERvises) the running of the machine that is represented by th