Announcing PVM2: Reimagining PVM towards standard RISC-V

Background

PVM is the instruction set architecture (ISA) of PolkaVM. This is the planned ISA to be deployed on the JAM Chain, advertised to be fast. In March, we started Grey (later known as JAR). JAR’s virtual machine JAVM is based on PVM ISA, and we managed to accomplish a 2x speed up for many of our PVM workloads compared with PolkaVM.

Our design has diverged a lot from JAM, challenging many of the JAM’s design rationales. We have since had, notably, a capability-based system and a real kvm microkernel which give us some impressive performance results and security properties. But until recently, we still kept PVM ISA almost unmodified.

The PVM ISA is the part we think that is also worth some deep thinking for us. PVM ISA has an entirely custom encoding definition. So we asked ourselves a simple question: do we really need it? If we move PVM towards a mostly standard-compliant RISC-V, can we get the same performance?

Specification: Defining PVM2

So we designed PVM2. A new ISA that is kept as close to the RISC-V spec as possible. How we define it is like this. We define a new base ISA. Supposedly, this will be the only thing we want to modify. Then we apply RISC-V extensions cleanly on top.

Our entire base ISA is defined as a short differential from RV64E, with just the following changes:

• Memory address space
• New meaning of pc
• Disabled auipc, jalr (and c.jalr).
• Standard-compliant custom-0 RISC-V instructions, trap, ecall.jar, ecalli.jar, br_table and fallthrough.

That’s basically it.

We then apply unmodified standard RISC-V extensions: m, c, zbb, zba, zbs, zicond, zicclsm.

Rationale: Future-proofing the spec

Some of the designs in PVM is questionable, or at least, debatable. An example is bitmask, which bloats the binary size by 12.5%. Supposedly, this is for random access to the program. Yet, the new gas metering requires a pre-validation round, completely defeating the purpose. There’s no flexibility in any of this: as an ISA spec, you either have it, or you do not. The middle ground is the worst of all places.

One of the rationales for PVM2 is to side-step this. We use the standard whenever possible. Avoid reinventing the wheels when it’s not necessary.

A mostly-standard RISC-V ISA also has significant advantage in its tooling: if LLVM ships any optimizations, we get it immediately. No bikeshedding with the transpiler to “re-support”. In addition, even our custom-0 instructions are defined in a standard-compliant way. This means we can easily utilize, for example, Rust’s asm macro, in a way that is not straightforward on PVM.

Our design also allows us to support new RISC-V extensions at ease.

Findings: You don’t need PVM

Our findings are quite clear: you don’t need PVM – we implemented the PVM2 ISA for JAVM, and managed to get a recompiler that is as fast as the old custom ISA. Our benchmark results are as follows.

Benchmarking comparison

We measured recompile + execute time. JAVM (PVM2) runs as fast as JAVM (PVM) on most workloads. And JAVM (PVM) itself is around 2x faster than PolkaVM.

In-house delta

The below table shows the in-house delta between JAVM (PVM2) and JAVM (PVM).

Binary size comparison

The binary size of PVM2 is also competitive. This is probably mainly due to PVM’s insistence of keeping bitmask, a 12.5% overhead. The reason that PVM2 can effortlessly enable a few more standard RISC-V extensions also helped.