[dead]
I have written a JVM in Rust
131–140 of 185 posts
Re: I have written a JVM in Rust
#132Earlier quoted context omitted.
I find that Rust is like maybe 1.5-2x more productive to code in than say C or C++. Part of that is the tooling has so much less arcane baggage, part of that is that I need to reach less for external tools for metaprogramming, part of that is fewer crazy macro/template compiler errors, and part of that is less time spent debugging. It all adds up.
I've heard very inconsistent things about this, which is interesting. Often people say Rust is less productive, as there's often "makework" involved with satisfying the borrow checker. I suspect a lot of it revolves around how you perceive that sort of thing: it can be cast as both productivity (satisfying it can potentially rule out bugs) or a loss of productivity (you were already satisfied the code was correct). B…
There is definitely a hump to get over (maybe you are never fully as "productive" as languages that just let you shoot yourself in the foot, I say as a full-time Go developer for a few years now). Simple, straightforward code is often harder to write. Don't even get me started on stuff that uses async.
But IMO it's very worth it. What do you get out of wrestling with the unholy, fractured C/C++ ecosystem? The privilege of being able to _use other people's code_. You get that without much hassle in Rust.
Re: I have written a JVM in Rust
#133That is pretty awesome! When I joined the Java effort in '92 (called Oak at the time) the group I was with was looking at writing a full OS in Java. The idea being that you could get to just the minimal set of things needed as "machine code" (aka native methods) you could reduce the attack surface of an embedded OS. (originally Java was targeted to run in things like TV's and other appliances). We were, of course, wo…
This idea has definitely been tried a few times [0, 1].
[0] - https://en.wikipedia.org/wiki/Singularity_(operating_system)
[1] - https://en.wikipedia.org/wiki/Midori_(operating_system)
Re: I have written a JVM in Rust
#134Earlier quoted context omitted.
In what world did you convince yourself asking a chatbot was a source of real knowledge? respect yourself enough to look at primary sources
How about respect other people instead of rushing to condescending judgement? the stakes are incredibly low here, I asked ChatGPT for fun, like tens of millions of others are doing every day.
It's not asking ChatGPT that is anti social but posting it, diluting the entropy of the conversation. Thousands of brains read every posted word before they can discard redundant information. Together we can keep a high quality shared medium, which benefits everyone!
Re: I have written a JVM in Rust
#135Earlier quoted context omitted.
Embedded JVM is actually huge/pervasive and runs things as benign as the chip on your credit card.
After reading your comment I was surprised to find out that credit card chips have any processing capabilities whatsoever, which they apparently do, though at least according to gpt4, they are far too basic to run java/jvm. ?
oh, yeah, they do. They often have multiple 'applications' on them, for different purposes (for example, withdrawing from an ATM with a card is a different application to making a purchase, which is different from the ill-conceved idea of using your card and PIN as a two-factor authentication token)
Re: I have written a JVM in Rust
#136Re: I have written a JVM in Rust
#137Earlier quoted context omitted.
I seriously doubt the ratio of Scala vs C++ for implementing the JVM is 1:300.
I'm sure it's not complete, but I also wouldn't be surprised if 99% of what's in HotSpot is optimization tweaks and performance boosts which aren't essential to the JLS.
It's mostly GC and JIT and a huge amount of corner case interactions between them. And also the many supported instruction sets.
Re: I have written a JVM in Rust
#138Earlier quoted context omitted.
Embedded JVM is actually huge/pervasive and runs things as benign as the chip on your credit card.
After reading your comment I was surprised to find out that credit card chips have any processing capabilities whatsoever, which they apparently do, though at least according to gpt4, they are far too basic to run java/jvm. ?
“According to gpt4”…. Uhhh. LLMs are text generators. Not a good source for facts or information, if accuracy is desired.
Re: I have written a JVM in Rust
#139Earlier quoted context omitted.
This lists a few things using Java Cards (likely stuff that's in your wallet, surprisingly): https://stackoverflow.com/questions/47731005/practical-use-o... (fwiw I have a bit of prior experience here)
That's pretty neat. It sounds like Java Card (or at least some other cards) actually "boot up" by way of inductive coupling, ie, via the "contactless" card readers where you just hold your card in proximity to the reader thing. Did not know that, I assumed it was just reading a key via NFC or something.
A lot of people assume this, but with contactless EMV there is a whole transaction flow between the card and the reader going on.
You know those 4 lights on a contactless card reader? They indicate different transaction stages between the card and the terminal. I don’t find them that useful because it’s so fast they all appear to light at the same time, but that’s what they are!
If they were just passive tags, they wouldn’t be very secure, they have cryptographic processors onboard with private keys that can sign stuff for the terminal and your bank. The specs for the interaction are all public if you’re interested (I wouldn’t be!) and lookup contactless EMV.
Re: I have written a JVM in Rust
#140I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386 (486) AT clones. :-)
There's a no-std tutorial on how to write a demo kernel in Rust. https://os.phil-opp.com osdev.org, sandpile.org, RBIL, and freevga. The biggest PITA is hardware support. There are many good vintage hardcopy books with recipes for things like reliable port IO and undocumented hardware tricks. - Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4 - M…
> 2. POSIX compatibility layer. Even embedded OSes without the concept of threads or processes can implement POSIX.
Do you have resources about this? I can't quite fathom how it would work, but then again I have no expertise.
> 3. Hypervisor. They're much easier to add with intel's VT-[xd]. Failing that, fall back to emulation. Translational emulation is very performant.
Speaking of which, QubesOS was on HN recently. The essence is having many VMs to minimize cross-app attack surface and privilege escalation.
> 6. The failure of pure microkernel was the added complexity and management of sequencing multiple resources in a transactional manner. There are great theoretical security and operational advantages in microkernel architectures but they never caught on widely in a pure form.
I recently saw an interesting brief article[0] about how memory-safe languages can supercede the compartmentalization that microkernels provide. I'm reminded of Theseus[1], written in rUsT, which happens to reflect the sentiment. I've actually been putting off rereading the Theseus USENIX paper. Again, I'm not nearly qualified to answer whether the security of this is comparable to the best of that of microkernels, barring formal verification. Still, I think it should be explored more.
[0] https://catern.com/microkernels.html (Write modules, not microkernels)
[1] https://www.usenix.org/conference/osdi20/presentation/boos