Live data from Hacker News

HolyJit: A New Hope

blog.mozilla.org

101–110 of 219 posts

Re: HolyJit: A New Hope

#101
In the mean time, the performance for Firefox' Tree Style Tabs plugin have gone downhill. I'd be interested to know more about new browsers that put tabs on the side by default.

Re: HolyJit: A New Hope

#103
post #85

I 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…

Do they use tree style tabs though?

Re: HolyJit: A New Hope

#104
post #87

Earlier 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?

my coworker's previous employer blocked all code-sharing and question-and-answer sites for programmers because of a pathological fear of accidental IP dilution. it's a real thing.

Re: HolyJit: A New Hope

#105
post #98
post #92

Earlier 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?

Because trying to enumerate everything that could possibly be relevant to your work probably misses some valuable and relevant things.

Re: HolyJit: A New Hope

#106
post #98
post #92

Earlier 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?

Because, the ones who block stuff often don't keep up with what is work related. So in the end you have to write lots of e-mails until they notice that you are one of the few users that should be allowed to use the whole internet.

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

#107
post #98
post #92

Earlier 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?

1) Not work related typically really means “not whitelisted” so often sites that would be beneficial to the employee completing their jobs will also be inaccessible.

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

#109

No 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...

I'm truly sorry that GitHub is blocked where you work. Here's the pitch, taken from the repo's README [1]:

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.

[1]: https://github.com/nbp/holyjit/blob/master/README.md

Post reply on HN