
Firefox vs. rthreads - tbirdz
http://www.tedunangst.com/flak/post/firefox-vs-rthreads
======
kpcyrd
In other news, the next firefox release is going to have W^X

[https://www.mozilla.org/en-
US/firefox/46.0beta/releasenotes/](https://www.mozilla.org/en-
US/firefox/46.0beta/releasenotes/)

[http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-
in-...](http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-firefox/)

~~~
bubuga
> In other news, the next firefox release is going to have W^X

That's nice and all, but if the people behind firefox keep on taking away the
features that convince people to use it (Panorama, for starters) then these
little accomplishments don't accomplish much.

~~~
sp332
It's always been Firefox's position that features that don't get used by very
many people are better off as add-ons. That way you don't end up with a
browser with 1,000 features each of which adds complexity and slows
development. The official recommendation is to use this add-on, which was
created from the original Firefox Panorama code.
[http://fasezero.com/addons/](http://fasezero.com/addons/)

Edit: The page that made the above recommendation
[https://support.mozilla.org/en-US/kb/tab-groups-
removal](https://support.mozilla.org/en-US/kb/tab-groups-removal)

~~~
nbb
That's fine, until they decided to neuter their add-on API.

~~~
Spivak
As long as they're committed to maintaining the feature add-ons under the new
API I couldn't care less how it works under the hood.

------
aorth
I appreciate Tedu's musings on technical issues, and how he freely
acknowledges when there's a problem on their side. I wonder how Chrome's
performance is on OpenBSD?

~~~
evmar
I worked on the original port of Chrome to Linux. At that time Firefox was
much slower than Chrome on Linux. I think one reason was because Firefox
relied more on calls into X for drawing (e.g. I believe they used xrender for
compositing alpha channels), where Chrome bypassed all of that (just did all
its work in a pixel buffer, which is also why we had so many problems with
system fonts and system widgets etc.). Unfortunately especially on a platform
like Linux where graphics drivers aren't great you're often better off
avoiding the system. I imagine OpenBSD is similar -- like if they're using
OpenBSD's malloc instead of their faster jemalloc that likely costs a lot.

I also know Chrome also makes a million calls to gettimeofday so it is
effectively relying on the Linux vdso performance.

When you are running the same software on multiple OSes side by side (like
Chrome on Windows followed immediately on Linux) it sets your expectation for
what is acceptable performance. (It's probably worth mentioning here that
Firefox on Linux today is much better than used to be.) I appreciate that
OpenBSD has a different culture and goals but I feel sorry for them that they
don't get a good browser because of it.

~~~
cm3
At least for me current Firefox on Windows locks up more often than on Linux,
but that's most likely due to Windows having more coarse grained locks hanging
around in the subsystems than Linux does.

------
codys
I found this most surprising:

> As you’ll recall from page two of your Building a Multithreaded Kernel
> textbook, when a high priority thread waits on a lock, it’s supposed to gift
> its priority to the lock holder to ensure progress is made. We (I) never
> quite got around to implementing that, and for several years it seemed we
> just might get away with it. The history of rthreads is pretty much maybe
> tomorrow, maybe not.

It sounds like OpenBSD has gotten away without having priority inheritance for
most (all?) of it's history.

~~~
kbenson
OpenBSD has been fairly niche for most of it's existence. They got SMP support
in 2004, but that was 8 years after the project started. They just recently
upgraded much of the network stack to use multiple processors more efficiently
(or at all?) when processing packets, and that that's one of the core use
cases for OpenBSD. In a perfect world, they would have done all this long ago.
I'm pretty sure it's just a matter of not enough developers (or not enough
developers of enough skill) to accomplish all the things they want to do.

~~~
ben_bai
From my point of view it's the "measure before you optimize" mantra. Now with
10Gbit cards a single threaded pf and network stack could no longer keep up
with the throughput of the NICs, so something had to be done

------
askyourmother
The key part here is that OpenBSD take a conservative approach to things, but
when they do fix things, it is usually an elegant fix, not a hack to save time
now, at a cost of security later.

~~~
gpvos
The key part that I got was that, while OpenBSD (rightly) prioritizes security
over performance, all those little performance degradations can add up if you
don't pay attention to them.

~~~
ben_bai
it runs on some very underpowered machines, so i guess it's not that much of a
performance hit.

------
hsivonen
Regarding the troubles with malloc, Firefox as developed by Mozilla doesn't
use system malloc. (It uses bundled jemalloc.)

~~~
masklinn
Mandatorily on all platforms, or just by default? Because of the security &
debugging features in OpenBSD's malloc framework[0] I wouldn't be surprised if
the OpenBSD port used the system malloc, I'm guessing that's just a compile-
time switch away.

[0] [http://man.openbsd.org/OpenBSD-
current/man5/malloc.conf.5](http://man.openbsd.org/OpenBSD-
current/man5/malloc.conf.5)

~~~
yxlx
>I wouldn't be surprised if the OpenBSD port used the system malloc

I thought so too but then when I looked for such changes, I couldn't find any.

    
    
        cvs -qd anoncvs@anoncvs.ca.openbsd.org:/cvs get -P ports/www/mozilla-firefox
        cd ports/www/mozilla-firefox
        grep -Ri malloc .
    

All that was found was a few irrelevant things which matched because "malloc"
was in the name of the referenced files:

    
    
        ./patches/CVS/Entries:/patch-js_src_ctypes_libffi_src_dlmalloc_c/1.4/Tue Sep  2 16:43:04 2014//
        ./patches/patch-js_src_ctypes_libffi_src_dlmalloc_c:$OpenBSD: patch-js_src_ctypes_libffi_src_dlmalloc_c,v 1.4 2014/09/02 16:43:04 landry Exp $
        ./patches/patch-js_src_ctypes_libffi_src_dlmalloc_c:--- js/src/ctypes/libffi/src/dlmalloc.c.orig   Wed Jul 23 05:13:14 2014
        ./patches/patch-js_src_ctypes_libffi_src_dlmalloc_c:+++ js/src/ctypes/libffi/src/dlmalloc.c Thu Jul 24 20:47:22 2014

------
gpvos
The article mentions that vDSOs have negative security implications. After
reading up on what a vDSO is, it is apparently (in Linux) a security fix on an
earlier implementation called vsyscall. Can anyone enlighten me what security
issues are left in the vDSO system?

~~~
geofft
Right, I don't understand this and I couldn't find an explanation of why
OpenBSD has rejected it, at least for gettimeofday(). I can imagine the
following:

* The vDSO is mapped at a fixed address in every process, making return-to-libc-style attacks easy. This doesn't seem to be necessary, though, since it's a virtual _dynamic shared object_ , and you can ASLR it just like you can ASLR any other dynamic library. Just tell the program where you put it.

* The vDSO (or at least the vsyscall page, not sure if this is still true) includes a syscall instruction, making it a _juicy_ target for return-to-libc-style attacks. But for gettimeofday() you don't need that. Just include the instruction to read some dedicated read-only page from memory-mapped timer hardware, or run RDTSC, or whatever, and make your ABI such that it permits the vDSO call to fail and regular libc code might have to make a real syscall if it does. Or that the vDSO isn't guaranteed to be present, and is missing if hardware support is missing.

Any further information here?

~~~
brandmeyer
The vDSO mapping is definitely randomized by ASLR on my system. You can
confirm with 'ldd $(which ls)' on your system.

------
krakensden
Firefox is pretty terrible on Linux, too. Presumably there's something about
their posix threading or X11 integration that's busted, but it's hard to tell.

~~~
cpburns2009
I've been running Firefox on Linux for 7 years, and I've hardly had any
problems.

~~~
krakensden
Try running it on a similar Windows or OS X system. Or try Chrome. Worlds of
difference in UI responsiveness.

~~~
floatboth
Make sure you have OpenGL off-main-thread composition enabled. I think it's
still disabled by default on X11 systems, because they don't trust the drivers
yet. Check about:support for "GPU Accelerated Windows".

about:config → layers.acceleration.force-enabled = true,
layers.offmainthreadcomposition.testing.enabled = true, gfx.xrender.enabled =
false.

Also, some "beta quality" features: browser.tabs.remote.autostart = true (e10s
multiprocess) + layers.async-pan-zoom.enabled = true (exactly what it says,
async scrolling like in Chromium, IIRC it requires e10s).

With all these enabled in stable Firefox on FreeBSD, the experience is
excellent.

~~~
cm3
I have neither enabled and Firefox+X11 is the smoothest Firefox on the same
machine. May depend on drivers, versions, and config, obviously.

~~~
floatboth
May depend on CPU performance :) On my 3.4GHz 4-core desktop, it is pretty
much always smooth. But on my 1.7GHz 2-core laptop, async pan&zoom makes a
noticeable difference.

~~~
cm3
FWIW I'm using it on an old Core2Duo and a mobile Sandy Bridge Dual Core, so
nothing fast by today's standards.

