4 ms·

When desktop applications running in electron, just doesnt have enough web abstraction to keep up with mores law, a hero comes along, to ensure there can always

When desktop applications running in electron, just doesnt have enough web abstraction to keep up with mores law, a hero comes along, to ensure there can always be one more level of java script between you and a responsive UI.

Terr_ 3y ago
Speaking of Electron... when I start my Slack client for work, there are a series of processes where at least one reports 1.130 terabytes of virtual memory. (Shown in top as "VIRT".) Now, maybe that's just a potential usage that trust-me-bro it'll never actually try to use or access in RAM or on disk... but how on earth is that number for a chat client so much bigger than either Firefox with 100+ tabs or even Java-based IDEs like Webstorm?
- cangeroo 3y ago
  Virtual memory is allocated for isolation reasons. See v8 isolates.
  - Terr_ 3y ago
    > v8 isolates Javascript engines aside, that sounds like a great sci-fi movie macguffin material.
- mananaysiempre 3y ago
  Sounds like somebody is playing tricks with virtual addressing, yeah. See BIBOP (1980) [1] for an example, though it is not used literally in current garbage collectors as far as I am aware. Or look at what AddressSanitizer does with its nominal terabytes of “shadow memory”[2]. Chrome has a bewildering variety of low-level stuff in it, to save memory among other things[3], so it wouldn’t surprise me in the least to learn there was virtual-memory tagging somewhere in there, too. [1] https://foldoc.org/Big+bag+of+pages https://foldoc.org/Big+bag+of+pages [2] https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm https://github.com/google/sanitizers/wiki/AddressSanitizerAl... [3] https://v8.dev/blog/oilpan-pointer-compression https://v8.dev/blog/oilpan-pointer-compression
- frutiger 3y ago
  V8 allocates a “gigacage” around every wasm memory area on modern 64 bit processors and marks them so the OS will trap on an unexpected access. This is much more efficient than doing a bounds check on every access. These pages are not actually resident. “Big number is scary” is not a good way to understand performance.
  - iforgotpassword 3y ago
    No, but it means there is one less thing we can rely on to identify "process gone whacky". Plus, admittedly I didn't think about this thoroughly just now, this sounds like a cheap hack for speed. You could still have an OOB access that would land in some valid memory and thus lead to an exploit, right? It's just made very unlikely by making these areas very large and having ASLR. Proper bounds checks wouldn't have that problem.
    - tatref 3y ago
      The memory is still owned by the electron process, so ASLR is not involved here. Also in case of OOB, you still land into the electron process. VIRT is not a good measure of actual memory usage because it includes shared pages like file cache and libraries, RES is better. Shameless plug: I developed a tool that try to compute a better value for memory usage: https://github.com/tatref/linux-mem https://github.com/tatref/linux-mem

Terr_ 3y ago

Speaking of Electron... when I start my Slack client for work, there are a series of processes where at least one reports 1.130 terabytes of virtual memory. (Shown in top as "VIRT".) Now, maybe that's just a potential usage that trust-me-bro it'll never actually try to use or access in RAM or on disk... but how on earth is that number for a chat client so much bigger than either Firefox with 100+ tabs or even Java-based IDEs like Webstorm?

cangeroo 3y ago
Virtual memory is allocated for isolation reasons. See v8 isolates.
- Terr_ 3y ago
  > v8 isolates Javascript engines aside, that sounds like a great sci-fi movie macguffin material.
mananaysiempre 3y ago
Sounds like somebody is playing tricks with virtual addressing, yeah. See BIBOP (1980) [1] for an example, though it is not used literally in current garbage collectors as far as I am aware. Or look at what AddressSanitizer does with its nominal terabytes of “shadow memory”[2]. Chrome has a bewildering variety of low-level stuff in it, to save memory among other things[3], so it wouldn’t surprise me in the least to learn there was virtual-memory tagging somewhere in there, too. [1] https://foldoc.org/Big+bag+of+pages https://foldoc.org/Big+bag+of+pages [2] https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm https://github.com/google/sanitizers/wiki/AddressSanitizerAl... [3] https://v8.dev/blog/oilpan-pointer-compression https://v8.dev/blog/oilpan-pointer-compression
frutiger 3y ago
V8 allocates a “gigacage” around every wasm memory area on modern 64 bit processors and marks them so the OS will trap on an unexpected access. This is much more efficient than doing a bounds check on every access. These pages are not actually resident. “Big number is scary” is not a good way to understand performance.
- iforgotpassword 3y ago
  No, but it means there is one less thing we can rely on to identify "process gone whacky". Plus, admittedly I didn't think about this thoroughly just now, this sounds like a cheap hack for speed. You could still have an OOB access that would land in some valid memory and thus lead to an exploit, right? It's just made very unlikely by making these areas very large and having ASLR. Proper bounds checks wouldn't have that problem.
  - tatref 3y ago
    The memory is still owned by the electron process, so ASLR is not involved here. Also in case of OOB, you still land into the electron process. VIRT is not a good measure of actual memory usage because it includes shared pages like file cache and libraries, RES is better. Shameless plug: I developed a tool that try to compute a better value for memory usage: https://github.com/tatref/linux-mem https://github.com/tatref/linux-mem