Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a Minimalistic Virtual Machine

pointersgonewild.com

Post reply on HN
Print view View original

31–40 of 72 posts

Re: Building a Minimalistic Virtual Machine

#31

Post by ternaryoperator »

kaba0 wrote: post #21
maxime_cb wrote: post #15

Earlier quoted context omitted.

For one the JVM is a huge piece of software. Large enough that only a large corporation could realistically reimplemented or maintain it. It also exposes many APIs with a large surface area. Then there's the issue of Oracle and how you feel about them as a company. UVM has obviously nowhere near the ecosystem, but you can draw pixels to a frame buffer with two function calls, and your UI will be guaranteed to look th…

JVM is a specification which can be implemented (and has been plenty of times, completely independently of each other) by a single developer in like half a years tops. It is a simple stack-machine with 100+ basic instructions, a simple exception mechanism and a heap. A GC is not even necessary if we are talking about minimalistic approaches, but a basic tracing GC is also not hard. It is only a (huge) plus that it ca…

It's not close to as easy as you represent. To start with, there are 204 instructions, some of them, far more complex than what you term "basic," such as invokedynamic. The exception mechanism is also far from "simple," -- it's simple conceptually but extremely difficult to get exactly right when it involves finally clauses both in the exception handler and the original excepting code. There are many subtleties that can lead to completely wrong results if not designed very, very carefully. It's far from "simple."

Re: Building a Minimalistic Virtual Machine

#33

Post by kaba0 »

ternaryoperator wrote: post #31
kaba0 wrote: post #21

Earlier quoted context omitted.

JVM is a specification which can be implemented (and has been plenty of times, completely independently of each other) by a single developer in like half a years tops. It is a simple stack-machine with 100+ basic instructions, a simple exception mechanism and a heap. A GC is not even necessary if we are talking about minimalistic approaches, but a basic tracing GC is also not hard. It is only a (huge) plus that it ca…

It's not close to as easy as you represent. To start with, there are 204 instructions, some of them, far more complex than what you term "basic," such as invokedynamic. The exception mechanism is also far from "simple," -- it's simple conceptually but extremely difficult to get exactly right when it involves finally clauses both in the exception handler and the original excepting code. There are many subtleties that…

Out of those 204 plenty are the exact same functionality for different types though.

Sure, there is invokedynamic/static/virtual that is a bit more complicated (they basically do runtime linking at first run), but I have implemented them and it is not harder than other pieces of a runtime.

Every method has an exception handler description, which is basically a series of instruction address ranges — if the thrown exception came from there, it jumps to the handler specified by the first match. If not, it propagates up. “Finally” clause is syntactic sugar only.

Sure, these are hard to get right, but that is inherent in the domain to a degree. You need many many “integration” tests - I wrote a test runner that runs the same program with OpenJDK and my implementation and compared their outputs.

Re: Building a Minimalistic Virtual Machine

#34

Post by samsquire »

maxime_cb wrote: post #17
samsquire wrote: post #10

Earlier quoted context omitted.

Could you explain what you did to build in mind for JIT? I feel WASM has the opportunity to create a truly audiovisual API for interacting with computers.

I go into some of the design decisions I made to make JIT optimizations easier here: https://github.com/maximecb/uvm/blob/main/doc/design.md

You mention parallel computation and being open for discussion.

My favourite area of computing is parallel computing and multithreading.

My toy multithreaded interpreter in Java can communicate integers between threads with message passing. I never got around to communicating complicated objects because I'm not sure how to solve the garbage collection problem with compound data structures/object graphs AND sending objects between threads. I'm currently relying on Java garbage collection at this time but I have played with a garbage collector written by Matthew Plant (http://maplant.com/gc.html), so if I were to implement my language in C I could also be inspired by Pony's reference capabilities.

Since my interpreter is a simple imaginary assembly interpreter I have instructions for "sendcode" "receivecode" which tell a thread to do a remote jump. There is also a "send" and "receive" instruction for sending data between threads in a thread safe manner. This uses actor style mailboxes behind the scenes.

Re: Building a Minimalistic Virtual Machine

#36

Post by samsquire »

whartung wrote: post #25
samsquire wrote: post #8

This is awesome. Thank you for sharing. My ancient ruby code and nodejs code all broke because I didn't pin dependencies. As a result I've got software that is unrunnable. More software shall be unrunnable as time goes on, I don't know many trends that prevent software from being unbuildable and unrunnable due to change except maybe repeatable builds and hermetic builds. Given platform toolchains complexity and libc…

The JVM is an interesting use case. Indeed, at a compiled level, byte code is mostly long lasting. I haven’t fired up a 10 year jar file recently but it would not surprise me if it Just Worked. The success of that is twofold. First is simply that whatever changes are being made to the JVM, they’re mostly forward looking and don’t deprecate running code. The other is that the conventional packaging mechanic is, essent…

Thank you for your thoughtful and interesting comment.

I too like Java a lot and think it's a great technology.

I can see how a runtime for a compiler (such as the JVM) doesn't need to change much over time: if the compiler produces the right code in 2000, then the code is probably still right in 2020, it just could use more features of the ISA that were introduced since then.

On the other hand, the design of platform, library code and framework code is an ecosystem that is desperate to transform over time as better approaches to solving technical and business problems are found.

Re: Building a Minimalistic Virtual Machine

#37

Post by maxime_cb »

tambourine_man wrote: post #30
samsquire wrote: post #8

This is awesome. Thank you for sharing. My ancient ruby code and nodejs code all broke because I didn't pin dependencies. As a result I've got software that is unrunnable. More software shall be unrunnable as time goes on, I don't know many trends that prevent software from being unbuildable and unrunnable due to change except maybe repeatable builds and hermetic builds. Given platform toolchains complexity and libc…

That’s one of the many advantages of building for the web. It won’t ever be unsupported (for some reasonable definition of never). You get text rendering, canvas, audio, webgl… it’s a pretty wide platform.

Except that's just not true. It's already broken/incompatible in many places across browsers. You may not notice if you're just doing basic HTML/CSS, but if you do anything slightly more dynamic, you're going to notice. An ever-expanding set of complex APIs also makes it more and more likely that bugs will go unseen and unfixed. See two examples I detailed in the blog post.

Re: Building a Minimalistic Virtual Machine

#38

Post by maxime_cb »

narag wrote: post #35

Very interesting for embedded or kiosk. Or in general, if the VM is run as a server inside a host: encryption in a box, instead of a library. Curious about what kind of multitask will be added.

I could actually use some feedback when it comes to the design of the parallelism model for UVM. I have a few ideas but it's not my area of expertise, so I would welcome feedback and suggestions.

Re: Building a Minimalistic Virtual Machine

#39

Post by narag »

maxime_cb wrote: post #38
narag wrote: post #35

Very interesting for embedded or kiosk. Or in general, if the VM is run as a server inside a host: encryption in a box, instead of a library. Curious about what kind of multitask will be added.

I could actually use some feedback when it comes to the design of the parallelism model for UVM. I have a few ideas but it's not my area of expertise, so I would welcome feedback and suggestions.

I have experience as a user, implementation is way over my head. Depending on the minimum host supported, you could only use lightweight threads or write a scheduler. IIRC, JVM started using its own thread implementation and later used the one provided by the host OS, when available.

Best of luck!

Re: Building a Minimalistic Virtual Machine

#40

Post by maxime_cb »

kaba0 wrote: post #29
maxime_cb wrote: post #23

Earlier quoted context omitted.

Implementing a good GC is incredibly hard. The JVM may have just "100+ basic instructions", but it also has classes, objects, arrays, and a whole set of APIs it provides. Your JVM is kind of useless if it doesn't ship with all of the user interface primitives (and other APIs/classes) people expect, for instance. Otherwise what you have is not what people expect to find in a JVM. I'm also under the impression that bui…

> Implementing a good GC is incredibly hard If you are interpreting instructions a simple one will be more than enough. Classes are its primitives, you just create a basic runtime representation for them with name, superclass, implemented interfaces and the methods’ bytecodes. Then an object can be as simple as a header containing a pointer to the class’s representation and then a listing of its fields, which can all…

> With all due respect, you ain’t going to beat the JVM with your UVM’s JIT compiler, not even close.

I think I may be able to get very close to native performance. I don't want to sound like an asshole by appealing to authority, but you aren't talking to a teenager writing an interpreter from their parent's basement. I have 21 years of programming experience, a PhD in compiler design and multiple published papers. I have some idea what I'm talking about.

> Why do you think creating a similarly good JIT compiler to a very similar design would be any easier in case of UVM?

The design is superficially similar to the JVM but it's also quite different. UVM's bytecode is untyped. It maps fairly directly to the x86-64 and ARMv8 instruction sets. If you want an idea of how a simple JIT compiler for a bytecode like that can perform, you should look at the performance of Apple's Rosetta. But, I actually think I can build something that yields better performance than that :)

Post reply on HN