Live data from Hacker News

Viewing profile — gsvelto

gsvelto

HN member
Joined
Thu, Jan 16, 2020, 9:24 AM UTC
HN karma
246
Public activity
27 items

About gsvelto

No profile information was provided.

Recent public activity

  1. comment
    Comment #33731653

    You're assuming that Firefox is eating all your commit space, but it's not, far from it, I can see it from the crash reports. You've got other applications running and they are als…

  2. comment
    Comment #33729654

    From the looks of it you have a minuscule page file (16MiB), that's why you're running out of commit space. I suggest setting it to auto-resize (the Windows default) which should p…

  3. comment
    Comment #33717226

    Could you open a bug on our tracker, and point to those crash reports? I'm very interested in analyzing real-world scenarios where this happens to figure out where those committed …

  4. comment
    Comment #33717216

    Yes it does, we've disabled tab unloading on Linux because low-memory detection just didn't work. We will re-enabled it sometimes down the line but only to avoid swap, not crashes.…

  5. comment
    Comment #33711299

    But is it? I wanted it to be tongue-in-cheek but the title is actually a rather accurate description of the contents of the article. This is a ~20 lines weird hack that we threw at…

  6. comment
    Comment #33708491

    Here's the thing: they're not! The reason those users where crashing was because something, somewhere (possibly in the graphics stack) was reserving ton of space without using it. …

  7. comment
    Comment #33708364

    I'm glad you noticed! We did indeed roll an improvement on Linux too, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1771712 In a nutshell we're directing the OOM killer towards…

  8. comment
    Comment #33160207

    They do and so does jemalloc in Firefox, however that lowers contention, it doesn't let you do away with synchronization. Consider this simple scenario: a thread allocates a chunk …

  9. comment
    Comment #33160194

    You're confusing general purpose locks with special-purpose ones used in the memory allocator. Firefox has its own GP locks, you can find them here: https://searchfox.org/mozilla-c…

  10. comment
    Comment #33156739

    No specific hardware support is needed to implement a lock. The atomic operations are all accessible from user-space - they are platform dependent though. The problem with locks is…

  11. comment
    Comment #33156722

    In a word: no. Efficient locks can only be implemented with significant involvement from the kernel. The best locks that can be implemented entirely in user-space will still suffer…

  12. comment
    Comment #33156379

    If you could grab a profile of the problem with the Firefox profiler and file a bug it would be greatly appreciated. From the sounds of it it's probably an edge-case we're not awar…

  13. comment
    Comment #33155659

    Post author here, `__ulock_wait2` is used under the hood by `os_unfair_lock()`. I considered it but it would have required more scaffolding, especially to support all the versions …

  14. comment
    Comment #28764867

    Recent Linux kernels allow you to measure memory consumption from a QoS point-of-view via pressure stall information: https://www.kernel.org/doc/html/latest/accounting/psi.html Thi…

  15. comment
    Comment #28764768

    Unfortunately those crashes do not appear to be related to low memory scenarios. They seem to be genuine bugs in the screen reader. I think the right bug tracking them is this one:…

  16. comment
    Comment #28764725

    Detecting low memory scenarios is surprisingly hard on desktop operating systems, but trivially simple on Android/iOS. Firefox for Android already made extensive use of this featur…

  17. comment
    Comment #27244533

    Arch already uploads symbols for their Firefox builds so that's OK, it's the dependencies that are missing. Unwinding information is used to produce accurate stacks. If it's lackin…

  18. comment
    Comment #27217548

    Only public symbols and unwinding information is extracted from Arch packages because they don't have debuginfo like other distros. It's better than nothing.

  19. comment
    Comment #27213576

    That's a really tough problem to solve on Linux. We're actively working on it in order to make Firefox better behaved when memory gets tight but it's not easy. You can follow the w…

  20. comment
    Comment #27211841

    Yes, that's one of the benefits. Firefox has a very large user-base compared to other FOSS projects so we will often spot bugs that others haven't noticed simply thanks to the shee…

  21. comment
    Comment #27211801

    You're very welcome! If you're interested in the topic we've got a working group [1] and a very active channel on chat.mozilla.org [2]. Besides the actual stability work we've also…

  22. comment
    Comment #27211601

    I think I started scraping symbols from Fedora 34 builds on Monday, we probably haven't looked at those crashes yet.

  23. comment
    Comment #27211584

    We do gather symbol information on Windows too, but it's a lot less detailed than what we get from Linux. It also requires jumping through a lot of hoops. For example we get minima…

  24. comment
    Comment #25624441

    It's rasdaemon these days: https://www.setphaserstostun.org/posts/monitoring-ecc-memory...

  25. story