Announcement

Collapse
No announcement yet.

Google Uncovers CPU Bug For Geminilake, Affecting At Least Firefox & Chrome

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Guest's Avatar
    Guest replied
    Originally posted by pal666 View Post
    jitted javascript probably runs in separate process anyway
    There's no way you could be more wrong. Main thread JavaScript (not a WebWorker) runs in a single thread along with things like layout and styles, rendering, and pretty much everything related to a given tab. There is a reason why bad scripts make websites run like garbage, and that's because they block the main thread.

    Leave a comment:


  • coder
    replied
    Originally posted by carewolf View Post
    As usual you have no idea what you are talking about.
    No, pal666 is always right. If his statements don't comport with reality, then it must be a bug in reality.

    Leave a comment:


  • coder
    replied
    Originally posted by pal666 View Post
    you guessed wrong
    You don't have enough information to say that! If it's a CPU bug, then the underlying trigger is not necessarily isolated along process or thread boundaries.

    Leave a comment:


  • coder
    replied
    Originally posted by pal666 View Post
    l2 misses are affected by memory footprint, not by jit recompiling
    Yeah, and how do you think one gets such a large memory footprint of frequently-executed code?

    Most software spends the majority of its time in a few hot spots. Hence, not many ICache misses. However, with a bunch of tabs open, each running large amounts of spy-ware infested Javascript that the browser has dutifully transformed into native executable code, I would expect to see a much larger active footprint of code executing.

    Leave a comment:


  • carewolf
    replied
    Originally posted by pal666 View Post
    they had crash in c++ code (v8::internal::LoadIC::UpdateCaches). jitted javascript probably runs in separate process anyway
    As usual you have no idea what you are talking about. JIT code calls into C++ code all the time, and it does run in a separate process, but only relative to the hosting process, JIT code runs in the same separate process that renders the webpage and generates the JIT code to be run, the process that crashes in this case.
    Last edited by carewolf; 06 October 2019, 05:37 AM.

    Leave a comment:


  • pal666
    replied
    Originally posted by carewolf View Post
    I would guess JIT
    you guessed wrong

    Leave a comment:


  • pal666
    replied
    Originally posted by DoMiNeLa10 View Post
    JavaScript is JITed these days, so with it's constant code generation you run a greater risk of creating a stream of instructions that causes this bug to trigger.
    they had crash in c++ code (v8::internal::LoadIC::UpdateCaches). jitted javascript probably runs in separate process anyway

    Leave a comment:


  • pal666
    replied
    Originally posted by coder View Post
    Just a wild guess, but browsers are continuously JIT-compiling loads of code - quite likely more than fits in L2 cache (and perhaps invalidating Instruction Cache lines, as they do it). Meanwhile, other code running on the CPU might be less likely to generate cache misses. Just two ways in which browsers might differ from most software.
    l2 misses are affected by memory footprint, not by jit recompiling

    Leave a comment:


  • carewolf
    replied
    Originally posted by milkylainen View Post
    Sounds like a pretty severe and basic bug.
    I'm surprised it hasn't triggered all sorts of havoc all over the place?
    Maybe it isn't a hardware bug after all?
    What's so special about the browsers that they keep (apparently?) triggering the bug?
    Considering this is in V8. I would guess JIT. Writing instructions to a piece of memory and then executing that memory.

    Leave a comment:


  • carewolf
    replied
    Originally posted by discordian View Post
    Sounds more like it's a hard to reproduce bug that depends (amidst other things) on where the linker places stuff.

    Hard to blame Google if a cpu can be singled out. Especially if at the same time Mozilla did the "don't care/works for me" instead of investigating.
    Mozilla didn't close the bug, the reporter did because the problem went away. And Google only worked around the bug in one specific case with one specific function. Firefox has nothing to fix if the linker no longer places a function on an offset that triggers the issue.

    Leave a comment:

Working...
X