You can expect performance to be no better than a full-fledged native compiler for the language, if the native compiler was somewhat mature.

In this particular case, Frege is compiling to Java source code (not JVM bytecode), and Java does not give precise control over how things should be done at runtime, such as object representations. Additionally, while the main Java compiler is reasonably mature, its optimizations are certainly tailored for idiomatic Java, which includes a lot of mutation, strict evaluation, and use of object-oriented programming. Haskell in particular has unevaluated expressions everywhere (thunks) because of lazy evaluation, and heavy use of first-class and recursive functions.

You nailed it.

OTOH, one experience we did make is that the JVM is not so bad in running pure code, as far as the JIT and GC is concerned.

The biggest hurdles on the JVM are: absence of value types (e.g. tuples), the smallish, fixed stack, and lack of tailcall bytecode.

Generally, >=

Uh, care to explain why you think something like compiling Haskell to Java will yield better performance than writing an optimizing compiler such as GHC, with its native backend and optimizations that are tailored specifically for the types of programs written in Haskell (including things like the runtime system such as the garbage collector)?

Sorry, riscy, with >= I mean, Frege programs will take longer than native ones.

Ah, okay. :)

Can you explain why? I'm not an expert but I know that GHC relies on some sort of stack reduction machinery. Implement something like this on top of an existing VM, and you would lose some performance, I would say.