HolyJit: A New Hope
101–110 of 219 posts
Re: HolyJit: A New Hope
#102Can we just drop the JS VM and embed some nicer VM (JVM, DartVM) instead?
Re: HolyJit: A New Hope
#103I admire how mozilla is so passionate about what they develop but still, in 2017, firefox needs restart every couple of hours for performance reasons. I kinda of feel like they have the proof of concept working but its never good enough for the wider audience.
In class there are at least 30 out of 40 people using Firefox on Ubuntu with no such issues. On my laptop I use Firefox on Debian with no such issues. Also previously on Windows XP, 7 or 8, both in virtual machines and on hardware, I never had such issues, but that's a while ago so not really applicable anymore. You might want to submit a bug with your specific hardware to see if anyone can identify the cause, becaus…
Re: HolyJit: A New Hope
#104Earlier quoted context omitted.
That's all well and good, but github is blocked where I work.
That's all well and good, but you need to raise that with your IT department if it is an inconvenience rather than complaining to us. It seems odd that github would be blocked especially given HN isn't unless your company has some sort of pathological fear of accidental IP dilution, so perhaps it is a mistake that will be quickly corrected once pointed out?
Re: HolyJit: A New Hope
#105Earlier quoted context omitted.
in a lot of places (if you are not a developer) everything non-work related is blocked. It's stupid, but i've seen this often with friends.
> everything non-work related is blocked. It's stupid Why is it stupid?
Re: HolyJit: A New Hope
#106Earlier quoted context omitted.
in a lot of places (if you are not a developer) everything non-work related is blocked. It's stupid, but i've seen this often with friends.
> everything non-work related is blocked. It's stupid Why is it stupid?
Eventually, one day they will find out that their blocking is too strict and that they should restrict the blocking to sites which actively try to attack the users computer...
So it is more of an execution problem, but as it fails quite often you could call it stupid to invest into such a feature.
Re: HolyJit: A New Hope
#107Earlier quoted context omitted.
in a lot of places (if you are not a developer) everything non-work related is blocked. It's stupid, but i've seen this often with friends.
> everything non-work related is blocked. It's stupid Why is it stupid?
2) Since everyone has smartphones they will just access the same sites with their personal device which is more time-consuming.
Re: HolyJit: A New Hope
#108Re: HolyJit: A New Hope
#109No offense, but the blog post is seriously missing a better (or any?) explanation of what's the new JIT all about. At first I even thought my browser loaded only half the page...
1) holyjit aims to be easy:
> As a user, this implies that to inline a function in JIT compiled code, one just need to annotate it with the jit! macro.
jit!{
fn eval(script: &Script, args: &[Value]) -> Result
= eval_impl
in script.as_ref()
}
fn eval_impl(script: &Script, args: &[Value]) -> Result {
// ...
// ... A few hundred lines or ordinary Rust code later ...
// ...
}
fn main() {
let script = ...;
let args = ...;
// Call it as any ordinary function.
let res = eval(&script, &args);
println!("Result: {}", res);
}
> Thus, you basically have to write an interpreter, and annotate it properly to teach the JIT compiler what can be optimized by the compiler.> No assembly knowledge is required to start instrumenting your code to make it available to the JIT compiler set of known functions.
2) holyjit aims to be safe:
> Security issues from JIT compilers are coming from: > * Duplication of the runtime into a set of MacroAssembler functions. > * Correctness of the compiler optimization.
> As HolyJiy extends the Rust compiler to extract the effective knowledge of the compiler, there is no more risk of having correctness issues caused by the duplication of code.
> Moreover, the code which is given to the JIT compiler is as safe as the code users wrote in the Rust language.
> As HolyJit aims at being a JIT library which can easily be embedded into other projects, correctness of the compiler optimizations should be caught by the community of users and fuzzers. Thus leaving less bugs for you to find out.
3) holyjit aims to be fast
> Fast is a tricky question when dealing with a JIT compiler, as the cost of the compilation is part of the equation.
> HolyJit aims at reducing the start-up time, based on annotation made out of macros, to guide the early tiers of the compilers for unrolling loops and generating inline caches.
> For final compilation tiers, it uses special types/traits to wrap the data in order to instrument and monitor the values which are being used, such that guard can later be converted into constraints.
> Moreover, the code which is given to the JIT compiler is as safe as the code users wrote in the Rust language.
> As HolyJit aims at being a JIT library which can easily be embedded into other projects, correctness of the compiler optimizations should be caught by the community of users and fuzzers. Thus leaving less bugs for you to find out.