SaaSHub helps you find the best software and product alternatives Learn more →
Riscv-j-extension Alternatives
Similar projects and alternatives to riscv-j-extension
-
Graal
GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
feedback
Discontinued Public feedback discussions for: GitHub for Mobile, GitHub Discussions, GitHub Codespaces, GitHub Sponsors, GitHub Issues and more! [Moved to: https://github.com/github-community/community]
-
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
riscv-j-extension discussion
riscv-j-extension reviews and mentions
- RISC-V J extension: makes RISC-V a target for JIT/interpreted languages
-
Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware
The gains seem to not have been high enough to sustain that project. Nowadays CPUs plan, fuse and reorder so much of micro-code that lower-level languages can sort of be considered virtual as well.
But Java and similar languages extract more freedom-of-operation from the programmer to the runtime: no memory address shenanigans, richer types, and to some extent immutability and sealed chunks of code. All these could be picked up and turned into more performance by the hardware; with some help from the compiler. Sort of like SQL being a 4th-gen language, letting the runtime collect statistics and chose the best course of execution (if you squint at it in the dark with colored glasses)
More recent work about this is to be found on the RISC-V J extension [1], still to be formalized and picked up by the industry. Three features could help dynamic languages:
* Pointer masking: you can fit a lot in the unused higher bits of an address. Some GCs use them to annotate memory (refered-to/visited/unvisited/etc.), but you have to mask them. A hardware assisted mask could help a lot.
* Memory tagging: Helps with security, helps with bounds-checking
* More control over instruction caches
It is sort of stale at the moment, and if you track down the people working on it they've been reassigned to the AI-accelerator craze. But it's going to come back, as Moore's law continues to end and Java's TCO will again be at the top of the bean-counter's stack.
[1] https://github.com/riscv/riscv-j-extension
- JDK 20 G1/Parallel/Serial GC Changes
-
Hacker News top posts: Mar 12, 2022
RISC-V J extension – Instructions for JITs\ (40 comments)
-
RISC-V J extension – Instructions for JITs
There's a document in there about pointer masking: https://github.com/riscv/riscv-j-extension/blob/master/point...
It seems like the objective of this is to implement different access privileges... but why do you need specialized instructions for this? This is typically done by the OS and memory protection. The pointer masking extension would be to have multiple levels of privilege within a single process? I'm assuming that this is to protect the JIT from a JITted program? Except it's not completely safe, because there might still be bugs in the JIT that could allow messing with the pointer tags. Struggling to think of a real use case.
-
A note from our sponsor - SaaSHub
www.saashub.com | 13 Dec 2024
Stats
riscv/riscv-j-extension is an open source project licensed under Creative Commons Attribution 4.0 which is not an OSI approved license.
The primary programming language of riscv-j-extension is Makefile.