Slashdot Mirror
Firefox Javascript Engine Becomes Single Threaded
An anonymous reader writes with news about work on Mozilla's Javascript engine. Quoting Mozilla engineer Luke Wagner's blog: "With web workers in separate runtimes, there were no significant multi-threaded runtime uses remaining. Furthermore, to achieve single-threaded compartments, the platform features that allowed JS to easily ship a closure off to another thread had been removed since closures fundamentally carry with them a reference to their original enclosing scope. Even non-Mozilla SpiderMonkey embeddings had reportedly experienced problems that pushed them toward a similar shared-nothing design. Thus, there was little reason to maintain the non-trivial complexity caused by multi-threading support. There are a lot of things that 'would be nice' but what pushed us over the edge is that a single-threaded runtime allows us to hoist a lot data currently stored per-compartment into the runtime. This provides immediate memory savings."
"memory savings".
Maybe I'm missing something, but then how will "threading" (i use that term extremely loosely) methods like SetInterval and SetTimeout be implemented?
The great technology inspired by illustrous Windows developers building the whole applications as everything-should-access-everything model, was abandoned!
Contrary to the popular belief, there indeed is no God.
"us to hoist a lot data currently stored"
I really wish I knew what this phrase meant. It sounds fascinating.
But seriously, if there's no performance gain from multithreading, it can be a really good idea to move away from the complexity of it. There's a lot of traps people can fall into with concurrent code if they don't know what they're doing.
It's an evil sentence for saving the tiranny originated by the supposed saved Queen, so many believers of this simple statement are simply fooled. Why to believe in their damn words instead of saving themselves?
For religion, the more correct statement should be: God saves his dear son 1st, Jesuchrist..
The Javascript Engine is single threaded because when it is in the client-side, the client-side's process is supposed to be a single thread. The issue is totally different when the Javascript Engine is used in the server-side that almost processes of many web servers are concurrent (aka multi-threaded).
Javascript is not a CPU-powerful language, so it's better to re-design the language (or to create one new) and its paradigm (e.g. instead of slot-based, untyped and single threaded, it should class-based, typed and multi-threaded) for gaining something luxurious of CPU performance and to be lesser memory-hog.
JCPM
Single threaded is the safest way to program. Creating a multithreaded application without a strong multithreaded architecture is asking for trouble.
The only problem with this is the limited performance and the fact that modern computers are packing more and more CPU's whereas individual CPU performance has been stagnating. Sooner or later people will have to work out the tools to create safe multithreaded applications without requiring a special degree in parallellization.
whereas individual CPU performance has been stagnating
Except not. The cores themselves are also more efficient and performant as well. Performance != gigahertz rating.
Wait, I thought that the goal all along was to move AWAY from the Giant Single Thread of Javascript model?
Oh.
I see what you did there.
What the article is saying is that each instance of the JavaScript runtime runs in one thread. If you want multi-threaded JavaScript, you need multiple runtime instances (one per thread). This is how WebWorkers work.
Basically in a dynamically typed language like JavaScript every property access, function call, or any other thing that can be changed dynamically could be changed at runtime by another thread. So you need locking for every method call, property access, etc to make sure it isn't changed by another thread while it's accessed in another.
There are some generally fast locking algorithms for when locks are used mostly by the same thread... for instance in Java locks can be owned by a thread and that thread never has to lock or unlock at all, but instead it periodically checks if another thread has written a flag saying it wants to become the owner, then there is synchronization to pass off ownership. This works ok for Java, where there are fewer things that can change at runtime and they are explicitly listed out (using 'synchronized'), but in a dynamic language it's usually just too much overhead.
Just for comparison V8 is even more extremely single-threaded, with execution that can only be interrupted at some certain points in the JS code.
The sad thing is that patterns have become so many and so complicated that I can't tell if you're joking or not. Proactor pattern? Is that really a thing?
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Firefox Add-Ons (well, at least Extensions) are JavaScript code and chrome directives. Will these get a separate thread?
http://www.gotw.ca/publications/concurrency-ddj.htm
I was curious about that myself. Multithreaded should better for performance when one has multiple scripts and multiple tabs.
But, I do see your point, if the tools aren't there to make things work together, I kind of wonder if that isn't part of the problem I've been having lately with scripts not responding and the interface freezing randomly.
I really wish I knew what this phrase meant
You need to talk to the Executive Vice President of Sales and Marketing. Call for an appointment.
Not really, take a look at the nighties. They just don't officially support it because of the trouble that can happen dealing with browser plugins on windows.
My initial sense of this, is that they are making a huge mistake here. I'll have to do more research, but my feeling is that they are moving in the wrong direction with this decision.
One of the really cool "baked in" things with functional style language is their fundamental support for horizontal scaling across CPUs. My hope has been that javascript evolves towards this, so that the generic suite of functional methods become massively performant on a larger scale with map/reduce/fold/each calls.
Closures present a bottleneck here, but it seems like a reasonable runtime could make some intelligent prediction about whether the isolated function is a closure or not, and ship it off to a different CPU/thread depending on optimization strategies, or even estimated closure size. Even better, this could be done at runtime with some runtime optimization based on execution metrics of an anonymous/declared function in-context.
At the point of calling the map/reduce/fold/each function, the runtime should be able to decide whether to parallelize out the call, or even use some language extensions to let the developer specify the threading.
The point is, now that they're making this decision, all of those options are gone from FF. And at a terrible time too. As we move toward CPU architectures that encourage parallelism, Mozilla is taking js off the table as a first-class language able to easily exploit those new architectures. That strikes me as a huge mistake, and I'm struggling to understand the rationale.
Drinking habits can be dangerous. You can choke on the cloth and the nuns will wonder where their clothes are.
Relatively speaking, core performance growth has slowed down drastically. Most of your integer based logic and math have a throughput and latency of 1 cycle. Hard to get much lower than 1 cycle. The only real advancements in speeds are multi-cycle instructions, and most of those are SIMD now.
Just because you have 64-bits doesn't mean you have to use them for everything. I suppose you insist upon using a 64-bit text editor as well. Considering how much time and energy the developers spend trying to minimize memory use, I'm not really sure why they would go and undo all that just to use 64bits.
This has little to do with dynamic typing; anytime you share mutable state between threads, anything mutable in the shared state could be changed at any time by any thread (in particular, statically typed languages which allow arbitrary pointer manipulation -- like C/C++ -- have this problem just as much as dynamically-typed languages like JavaScript.)
You correctly note that Java has a mechanism for managing this issue, but that doesn't have any real relation to static typing.
" With so much happening in the computing world, now seemed like the right time to write "Welcome to the Jungle" - a sequel to my earlier "The Free Lunch Is Over" essay. "
Why complain over the lack of 64bit? What benefit would making it 64-bit give it? Access to more memory . . no thanks. Sure the wow overhead eats a bit, but 64bit would only improve how much memory that application can access.
I would much rather their devel time go towards making all plugings and javascript run in a separate jailed thread where if they misbehave they are easily killed and their effects are limited.
SpiderMonkey originally had those optimizations. See the original post (which, for some reason, isn't linked in the summary: http://blog.mozilla.com/luke/2012/01/24/jsruntime-is-now-officially-single-threaded/). They were complex, though.
Unless 32-bit support is being dropped from operating systems can you explain why it is bad that there is not a 64-Bit version?
Don't know something? Look it up. Still don't know? Then ask.
Relatively speaking, core performance growth has slowed down drastically. Most of your integer based logic and math have a throughput and latency of 1 cycle. Hard to get much lower than 1 cycle. The only real advancements in speeds are multi-cycle instructions, and most of those are SIMD now.
Lets go Irrational then!
Sounds good to me. Multi-threaded synchronization is notoriously hard to get right, so why risk it unless you *really* need the multicore performance?
And the thing with browsers isn't that they need access to more resources – they should have *less* resources (CPU, memory) and use them better. I'm not particularly happy with dedicating 25% of a CPU just to have a browser window with some tabs open while I'm working on something else – particularly not while I'm on battery. Why can't I get Firefox (and/or Chromium) to suspend the JS engine and any plugins on tabs that aren't visible anyway? Yes I know that you *sometimes* want to listen to audio from another tab, but most of the time even that is just annoying.
Oh, and just sandbox the damn stuff, and get rid og 93% of the possible security issues...
But am I annoyed enough to file wishlists in Bugzilla or start writing patches? Not really, but that's possibly because I believe complaining on Slashdot should be more than enough to get things fixed.
I don't like this because it's clearly a step backwards. Yes, Shared Nothing does work but it puts a limit on how many cores you can ultimately use. You won't get speedups from processors with more and more cores.
I'll agree that it's a pain to try and make good parallel/concurrent code work. I've seen too many cases of we'll optimize with this parallel algorithm, but it only is faster in extream cases like sorting 100,000 items. I rarely need to sort anything like a 1000 items in a web page so I'd rarely use a parallel sort like that, but what they are doing sounds more like giving up rather then continuing to search for an answer for using multiple cores long term.
Just what are we going to do when we have 32 cores? Most apps I've worked on couldn't be separated into 32 separate shared nothing tasks, but I might have a couple loops that could be partitioned into N tasks.
>Single threaded is the safest way to program
Especially given how crappy and fragile most web apps are. Sadly, people are far more forgiving to web apps when they hang, and lousy UIs, but expect far more from a standalone app. The attitude is usually, "well its a web app" as in what more do you expect from it?
Too bad rich UIs on the web didnt pan out due to high bandwidth demand in downloading the app and bloated crap Sun put out to be called later as Craplets.
Sadly, JavaScript took the spot due to bandwidth needs.
The AMD64 instruction set and the ABI are so much better than on i386/i686 that you definitely should.
Sooner or later people will have to work out the tools to create safe multithreaded applications without requiring a special degree in parallellization.
Maybe as soon as they figure out IPCs. Before answering the question "aren't single-thread programs bad", you have to mention the difference between a thread and a process. Once one realizes that the main advantages of a multi-threaded paradigm were in single-processor space (because it allowed to avoid a context switch necessary for changing memory space to that of a different process), you won't even have to explain the rest. Most people have already come to expect that multi-core is a Good Thing(TM).
Any guest worker system is indistinguishable from indentured servitude.
So much for server-side javascript, where you actually need threads like nothing else.
So wait, if you run that in Songbird Browser does it become an Angry Bird? : )
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
In all seriousness, they need to do something about the extensions. Refuse to host leaky ones or something. Extensions can't be Firefox's killer feature if they make it eat all of your RAM.
I can't agree more. Things are much better than they used to be, but oofda. So much for 640K -- FF is currently using up almost 1GB with about a dozen tabs open, and with AdBlock Plus, NoScript, IE Tab2, Firebug, User Agent Switcher.
Cheers,
"What in the name of Fats Waller is that?"
"A four-foot prune."
That's training.
As the internet continues to develop and fewer people started out with dial up, I'm not sure how long that's going to remain the case. I remember having to use a crappy web app at a previous job logging things and it would freeze or crash so frequently that standard practice was to log everything on paper first and then copy that into the application.
That makes a lot more sense than the title suggested. The Firefox devs have been working for quite a while to split the browser up to better make use of multicore processors and it seemed a bit odd that they would be going backwards and cramming all javascript into one process.
Of course the article said as much that these containers are on a per tab basis and hopefully that will help people who have tons of tabs open at once still be able to browse when one unrelated script freezes on a different tab.
... it'll just leak memory more slowly?
Multi-threading in JS is handled by web workers.
Oh, great! So now we're outsourcing even more textile jobs to anyone willing to work online, is that it? Sheesh!
(On a more serious note, thank you for that informative link.)
"What in the name of Fats Waller is that?"
"A four-foot prune."
It's the same reason your mom goes to Tyrone to get fucked by his 10-inch black dick over your dad's 2 incher.
32-bit Inel assembly is crap - extremely limited registers, and an instruction set full of legacy baggage form the 8-bit days. AMDs add-ons for 64-bit are modern, lots of registers and a set of sensible instructions to use them.
So it's a trade-off: 32-bit uses less memory (including for the instructions), and is therefor morelikey to get processor cache hits , while 64-bit gives you more registers, which allow signficantly faster code when (as is normal in non-scientific programinng) everything you care about in a given funtion fits in the register set.
It's also the case that the most likey reason any given C/C++ code was late to the 64-bit bit was that it was such crap code that it couldn't be "ported", where well-written code would just build 64-bit with minor fixes. Not directly applicable to FF, but there's a general reason people came to look down on code that couldn't make the jump.
Socialism: a lie told by totalitarians and believed by fools.
We live in a world where 8GB of RAM costs $50. I'm not sure how much I actually care whether Firefox uses 500MB vs. 2GB anymore.
If only four applications you keep open all the time feel the same way you start caring quickly.
Swap is still annoying. Even when you have an SSD and cannot hear it...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Web Browsers are much more sophisticated than a text editor. If all you used them for was rendering html, then 32-bits would probably be fine. But, 64-bit could potentially be nice for things like 64-bit plugins and extensions - true, most plugins/extensions are just fine as 32-bit apps, but there could be some specialized plugins which might benefit from access to full memory.
So while they may have fixed most of the memory leaks (it still runs like shit on a Mac), let us not allow them to get complacent again. [snip] By not frequently reminding them about memory leaks, you are opening the door to yet more bloat going forward.
I believe there's a parallel with a common fable:
You saw a wolf. I said I shot many, that the wolf situation should be improved, but you kept seeing wolves. This repeated many times and made you angry.
Now lots of others are saying that there really are fewer wolves these days. Indeed, you have no reason to believe that they're wrong.
But because of the offense done to you some time ago, you're going to continue crying wolf, even given no evidence at all?
I don't understand. I guess this is an attempt to punish us? Is it that you feel like we harmed you with our lies, so you should try to harm us with yours? I'm afraid that by crying wolf, and encouraging others to do the same, may just cause us to ignore you all, which is exactly the outcome you don't want.
I'm very sorry you feel like Mozilla deceived and harmed you. But the malicious attitude here and elsewhere in this thread is getting old. Use Chrome, if you like! But don't encourage people to waste developers' time with false claims.
For me it only counts to blame the leak on a plug-in if they tell me which plug-in to nuke. If I disable 15 plug-ins, it's not even the same browser by the time I'm done. Why do all these extension leaks persist? Because there's no feasible way to push a complaint into the right bug queue. Who is responsible for this sorry state of affairs? FF-core.
In my opinion, any lost memory not attributed to a specific culprit is a leak in Firefox, the product.
I'm thrilled with the progress they've made with FF-core, once they fessed up. And I'm looking forward to more of the same with the add-ons, too. No grudges here, so long as the truth is served.
FWIW, I participated heavily during the original FF 3 beta cycle. With fewer plug-ins than now, my browser was leaking at the rate of 300MB/day. Under a heavily laden 3.6.3 that's down to about 50MB/day. Livable, but I'm not dancing a jig in the streets.
But now I've got Unity to complain about, so this seems like small fish.
Just because you have 64-bits doesn't mean you have to use them for everything.
Yeah, but that's a broad statement fixated on memory optimization. Programmers sometimes jump through hurdles (ouch) to make values fit nicely in 32 bits or less - and it complicates the code in ways that aren't helpful. So, I'd consider sometimes wasting memory the lesser of two evils, especially since having more memory is a 64-bit perk and with the source code it's easier to remedy wasted memory in less time than split-up obfuscated expressions.
I'm not really sure why they would go and undo all that just to use 64bits.
Generally, I laud 64-bit architectures because of experience and hindsight. Recently I wrote an algorithm (in C, not ...) to very quickly process a binary stream and there were many points where I had to optimize the code by splitting the buffer into two separately handled 32-bit integers, because the bitshifts were significantly faster that way. Because of that, there were many hideous expressions (even for bitwise ops) and more time spent debugging.
For highest performance it was necessary on a 32-bit processor, but there wouldn't have been a penalty for using 64 bit operations on a 64-bit processor (except memory bandwidth when swapping from registers).
And likewise, mixing types in an expression steals performance to save memory (...mixed 8/16/32 types in an expression go through conversion to the largest type when evaluated - the conversion overhead becomes apparent in loops)... But, that's crazy talk and I must go put the leaches on myself now...
S:P ~(i wont unroll loops, i wont unroll loops, ...)
That's too complex for me!
for instance in Java locks can be owned by a thread and that thread never has to lock or unlock at all, but instead it periodically checks if another thread has written a flag saying it wants to become the owner, then there is synchronization to pass off ownership. This works ok for Java, where there are fewer things that can change at runtime and they are explicitly listed out (using 'synchronized'), but in a dynamic language it's usually just too much overhead.
So, I write Java a lot (java/jogl actually) and we do quite a bit with multi-threading. usually we use reentrant locks where anyone that wants to read/modify needs to lock/unlock, even the lock owner. you can't just assume the owner can check if nobody is owning it because, if it is currently changing something and then another object in another thread requests the lock, the owner won't know; it needs to lock the lock as well so other threads know to wait.
// stuff }. This CAN be a flag on a method like 'public synchronized void doStuff() { // stuff }' but that's really the same as 'public void doStuff() { synchronized(this) { // stuff } }'. you need to synchronize on an object that won't go away or be null ('this' usually works okay) and if you use something else, you can get warnings for not synchronizing when it is accessed but it won't stop you from doing so. You could be a horrible programmer and forget to synchronize and still break everything; java won't necessarily care.
Also, synchronized is not a way to denote what can change but a cheap lock built into java. it isn't an initialization flag like volatile, final, or static, but a block like if, else, or try and everything inside the block is synchronized on the object in question ie. synchronized(this) {
Maybe I misunderstood your meaning, but if not, I hope I explained it well.
-SaNo
Oh, get real.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
Nooo - don't look at their nighties!! that's so embarrassing! :P I hear their favorites have little pictures of ESR and RMS dueling with liitle swords.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
As a separate data point, I've never had to restart firefox either on my 8GB work laptop running linux or on my 3GB home laptop running Win7.
Does this mean Firefox will stop freezing up every couple seconds while I'm trying to do complicated tasks like scrolling down a page?
...you should have just said so.
But with the added perk of increased cache footprint.
Baptise your browser!
it needs to lock the lock as well so other threads know to wait.
So, it's locks all the way down?
You have twice as many registers, which are each twice as big.
Spilling to memory is much more costly than a cache miss.
Sorry, I meant to say more *critical*, not more *costly*.
(When will we be able to edit our posts?)
Maybe we should go back to UNIX design with single threaded
Unix always had processes with efficient FIFO-style communications and IO-controlled scheduling implemented between them. The idea of using shared memory (what would be an equivalent of multithreading) in such environment was seen as a very special case for exchanging bulk data or handling shared read-only resources.
The idea of this design was exactly the same as what was described in the article -- reduce the amount of things to track, keep private data to whatever limited scope it belongs. Plus, of course, security because Unix processes also provide security boundaries.
Threads were always seen as a horrible, unsafe hack, justified more often by Windows upbringing of the developer than by any legitimate advantages.
non-premptive kernels
Are you ignorant or stupid?
with horrible scaling properties
Over the whole history, Unix-based and Unix-like systems were, and remain superior in performance and scalability over Windows.
Contrary to the popular belief, there indeed is no God.
Oh, get real.
Lets END this before it starts.
I do a lot of photo editing, sometimes swap is simply required.
I also so no need to make my laptop noisy and power draining again with the inclusion of a spinning disk.
Yes it wears out the SSD quicker; who cares? I'm pretty sure I'll be replacing the SSD (or laptop) long before that ever might become an issue.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
80 users, 32GB, and suddenly a browser that gorges itself on RAM to fake performance optimization isn't as attractive any more. I'm looking at you, Chrom(ium).
BTW, Firefox running on my TS farm of 10 machines for 3+ years, *zero* memory related issues, and crashes are in the low 1-2% of session range after 4+ hours of uptime per session. I don't know what the fuck people are doing with their browsers to make them crash all the time. Also, flashblock is a godsend on terminal servers.
Well probably something like this http://www.youtube.com/watch?gl=US&v=_dErAZL1Hr8
There are two rules for success:
1. Never tell everything you know.
I think this affects me, as I understand it, no separate thread for web-workers.
It was my intention to use this in my Javascript Vic-20 emulators to run low ipc (1 kb/s) peripheral devices like disk drives.
As on core 2 duos it consumes most of one thread on Firefox to just do the computer emulation.
http://www.mdawson.net/vic20chrome/vic20.php
NaN!
It's not Firefox's fault that you choose to use an "64-bit" OS where 95% of the programs happend to be 32 bit. (i.e. Windows) Try running IE in 64-bit mode and see how many things won't work.
I looked at the Programs Folders sizes on a Win 7 64-bit machine recently:
Program Files : 819MB
Program Files (x86) : 40.43GB
Windows is still a very long way from allowing you to run a full 64-bit enviroment, but you can do that today on Linux if you like.
Do what thou wilt shall be the whole of the Law
I wouldnt settle for anything below 4 gig, and I prefer 8gig for general use. Server side, 16gig is so cheap, id make it default
Liberty freedom are no1, not dicks in suits.
As an exercise in insanity, I tried to install a modern Linux distro on an old Pentium II system with only 128M of RAM. Used btrfs for the heck of it. It was all going well until I tried to run Firefox 9.0.1. Thrashed that system mercilessly. Never mind actually showing a web page, just starting up blank was extremely slow. Sometimes I saw the "unresponsive script" popups on Firefox's own Javascript. I hacked out everything that used memory, dumping the LXDE desktop environment for a plain old window manager (jwm), and this helped, but it's not enough. Turned off images and disabled Javascript. It still thrashes swap.
Chrome didn't do any better. Firefox 3.5 worked okay on an even smaller system (96M of RAM). Version 3.6.8 + LXDE works fine on a system with 192M of RAM. Here's hoping their MemShrink effort scores more big wins.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
There you go, no flash, I bet other problems are caused by flash, i know often flash can leak too but appear as firefox.
We need to kill flash.
Liberty freedom are no1, not dicks in suits.
Pentium II is from 1998. You should use a browser from a comparable age. FF 3 is about at the limit of what you can expect to run on that hardware reasonably well. Anything more recent has been developed with more CPU and RAM in mind but you might check LuaKIT. Definitely not intuitive but slim.
Process switching causes TLB and other context flushes. This breaks almost all CPU speculative execution.
That depends on the hardware and OS, and may be applicable to context switching for processes, threads or even simple interrupts handling. OS and hardware design is supposed to achieve as little invalidation as possible, however you, knowing nothing but Windows, believe that context switch between processes is a horribly heavyweight operation everywhere.
Synchronizing shared memory between processes is expensive.
Shared memory is not synchronized, you dolt -- it's physically shared. Cache is synchronized, by hardware. Access to writable shared memory is expensive to synchronize, what is my whole point -- it is avoided through use of interprocess communication.
But the fact is traditional UNIX design does not exist anymore. Linux and other modern UNIX based OSs have already worked around the horrible UNIX design via hacks and patches. Linux famously has struggled and continues to struggle on SMP/Multi-core systems.
You know absolutely nothing about Unix and Linux design. All modern operating systems went from single-CPU to multi-CPU design by establishing a clumsy common kernel lock, then splitting it and switching to other synchronization mechanisms wherever possible. This had absolutely nothing to do with OS design, and was more relevant to things like interrupt handling, where hardware design forces resources to be shared regardless of the software developers' intentions. Some monstrosities already had billions of tiny little locks in place because their design sucked ass on any number of CPUs, however that did not help them to achieve anything useful.
How cute. This one thinks Windows and UNIX are the only two operating systems.
No, there were two kinds of operating systems -- "Unix-like" and "horrible shit". Windows is firmly in the second category. So is VMS, but for other reasons.
While there are much better designs than NT.. NT design is superior to Linux in every single aspect.
For all practical purposes, there is no such thing as "NT design". NT kernel was developed in hope to create and follow some sane design, however all advantages were immediately and completely negated by placing a horrible piece of shit Win32 as the only interface available to applications. If there are any remnants of sanity in NT/2000/XP/... line of Windows, they are buried under piles of crap.
Linux is like the low-quality made-in-china shit that everybody uses because its free/cheap.
I see, Microsoft started another "Get the Facts" campaign. Die in a fire.
Contrary to the popular belief, there indeed is no God.
If you had looked at system requirement, you would have seen FF9 recommends 512 MB of RAM. Earlier versions necessitate less, linked to the most common configuration (read: amout of avaible RAM) at the time.
btrffs sucks for frequent filesyetem sync calls, even the author of btrfs says that.
Firefox is known to do many filesystem sync calls.
So I'm not surprised the combination sucked.
You should try ext4, you could even choose to use ext4 without journaling.
New things are always on the horizon
I can see the why this is a problem, I have seen memory usage upwards of 1 Gig in real memory, so yes it seems like a good choice but is this not severely restricting the future of this browser? I mean Memory management is a problem, stopping processes, (threads that have already begun is the issue and that is client side)
Multi-threading, is the future think of it like a multi dimensional array, where you can productively access several products at one time, with the web becoming more and more of a SAAS based property this move is severely restrictive of what could be a great thing.
I am glad I heard this story because I was developing a product exclusively for use with Firefox now I am going to have to move it over to Google Chrome.
The simple fact is that the desktop is slowly moving over to SAAS and with a single thread, the result will be a slow unresponsive browser that sucks
I'd be interested to know how the latest Opera runs.
To infinity, and beyond!
You insist these are only "one guy". You should have left that out if you wanted to prove your point. I'm not sure if you're familiar with filing bugs, but if one guy reports something, and another guy reports the same thing, one of those will be closed as a duplicate. If one guy is having that issue, it most likely means more than one guy is seeing it, and either not noticing, not reporting, or watching that bug report because either he found it was already reported or his was closed as a dupe.
Also, the fact that there is no reply doesn't mean it's not an issue. Effectively no insight can be had, it does not prove there are or are not memory leaks.
Given the history of FireFox, where devs insisted for *years* that there were no problems, and then suddenly a pile of memory allocation problems got fixed, I give no more credence to a developer saying it's "probably" not an issue than a user reporting it as an issue. It's a dead split in terms of reputation, and as long as it remains open I give the reporter the benefit of the doubt. I think that's fair.
It sounds like you believe FireFox is rock-solid, and are looking for any evidence to bolster your case, rather than being dispassionate and accepting and evaluating evidence on its own merits. Maybe if you try again, you might be able to re-phrase this in a way that might away someone who does not already agree with you.
Well, it locks during whatever it does. It can cause deadlocks, yes, if something it calls itself also tries to access the same lock.
-SaNo
in particular, statically typed languages which allow arbitrary pointer manipulation -- like C/C++ -- have this problem just as much as dynamically-typed languages like JavaScript.
Thing is, C++ doesn't have mutable vtables (you can roll your own, but the standard ones are not; whereas in JS, you effectively have mutable per-object "vtables").
"any other thing that can be changed dynamically could be changed at runtime by another thread."
What kinds of application level objects need synchronous access (does that include atomic reference swaps)?
I think you got that troll problem from insulting the fine Mozilla on Windows people. Threads were meant originally for concurrency and not parallelism. Maybe one day CSP + data parallelism rises again with all the heterogeneity going on.
Shared memory is not synchronized, you dolt -- it's physically shared. Cache is synchronized, by hardware. Access to writable shared memory is expensive to synchronize, what is my whole point -- it is avoided through use of interprocess communication
Its obvious what I meant by synchronization. You have to protect concurrent write-access across processes. Threads can have finer control over this and you can in many cases avoid taking a lock when you can guarantee atomicity.
lol IPC. lol. Seriously? have you written a single high performance application in your life? Any IPC overhead will reduce performance compared to shared memory via threads.Also IPC has to implemented through kernel threads causing even more horrible usermode to kernel mode switching.
This had absolutely nothing to do with OS design, and was more relevant to things like interrupt handling, where hardware design forces resources to be shared regardless of the software developers' intentions.
Traditional single processor UNIX design was shitty as hell. All system calls were were blocking in kernel mode for the period of the time slice. Only way around this was to manually release control via wait() (in kernel mode). Linux was the same till 2.4.
I see, Microsoft started another "Get the Facts" campaign. Die in a fire.
Nah. I don't work for them. But I am forced to ship a mulit-platform library at work and have to deal with shitty unix design daily. All people like you should be laughed at and ridiculed. Its obvious you have never looked at the shortcomings this shit called UNIX. You are nothing but a cheerleader with an empty head.
Thanks! That could explain why I saw btrfs processes using so much CPU time. btrfs-endio sometimes used more than Firefox itself.
Thing I don't like about the ext's is they're not very space efficient, and that can make a difference on tiny hard drives such as the 8G this system has. Reiserfs is pretty good with space, and reiser4 was even better. Been wishing for btrfs to mature quickly, as reiser4 is probably dead. I found at least 1 gotcha with xfs. If you don't tune the parameters (block size and such), deletion of a large tree such as the Linux kernel source can take a very long time. Haven't tried any other file systems.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Its obvious what I meant by synchronization. You have to protect concurrent write-access across processes.
Actually, when shared memory is used for interprocess communications, you just should avoid concurrent write access (or write concurrent with read) like the plague. Then, if you can't avoid it, you should check if you are not, by any chance, an idiot, and if so, leave software development forever. Only then, if you have a reliable confirmation that it's unavoidable and you are not an idiot, you should think of a locking scheme.
lol IPC. lol. Seriously? have you written a single high performance application in your life? Any IPC overhead will reduce performance compared to shared memory via threads.Also IPC has to implemented through kernel threads causing even more horrible usermode to kernel mode switching.
Actually yes, I did. Unix pipes and sockets are considered to be "I/O" and affect scheduler, so it can optimize the timing and order of waking up the processes involved. Shared memory is considered memory access, and does not affect anything at all unless it's unlucky enough to cause a page-in, so actual scheduling happens in locking/semaphores. In its turn, multitude of semaphores (managed explicitly by applications but all affecting the scheduler) causes suboptimal scheduling compared to scheduler-managed waiting/sleep by applications (one state per file descriptor).
On multicore/multi-CPU systems the superiority of the Unix model is even more noticeable because processes can avoid sleeping even when they are closely related -- kernel just passes data asynchronously. Shared memory can be used for bulk data handling, to reduce copying while all handling of data-passing operations happen asynchronously.
This is not the case on Windows because Windows IPC is written by idiots.
Traditional single processor UNIX design was shitty as hell. All system calls were were blocking in kernel mode for the period of the time slice. Only way around this was to manually release control via wait() (in kernel mode). Linux was the same till 2.4.
Except, of course:
1. From the process' point of view all system calls cause the process to sleep regardless of the model used. The question is only for how long.
2. It's a matter of quality of implementation for kernel, for how long it may have to run without causing scheduler to be invoked. On SMP, it's even less of a problem as long as there is no global lock (what you are probably pretending to be describing).
3. On system with preemptive kernel, latency is reduced, while performance mostly stays the same or decreases due to more context switches while performing the same work. Please note that in Unix, a process will be woken up sooner if another process is trying to communicate with it, so "pipeline" processing stays optimal regardless of the scheduler invokation model. Process sleep time is not a matter of performance or scalability but latency, and it was long ago solved in all Unix-like systems without affecting their overall design.
4. wait() is a system call, so I seriously doubt that any Unix used such function name for an equivalent of sched_yield().
Nah. I don't work for them. But I am forced to ship a mulit-platform library at work and have to deal with shitty unix design daily. All people like you should be laughed at and ridiculed.
I have seen plenty of "multi-platform" development that was actually Windows development with thin wrapping that shoehorns it into all other systems. For those projects, indeed, nothing but Windows works because they follow a broken Windows-oriented application design. We need less of those projects and less of developers with Windows-bent minds.
Its obvious you have never looked at the shortcomings this shit called UNIX. You are nothing but a cheerleader with an empty head.
Over whole 90's I couldn't read half a kilobyte of any computer-related text without seeing anti-Unix propaganda stuffed in it by people like you. It was full of shit then, and it is full of shit now.
Contrary to the popular belief, there indeed is no God.
On a core-by-core basis, my AMD Phenom II system is about 60% faster than the old Athlon XP system it replaced in terms of GFLOPs. The main speed boost is from the Phenom II system having six cores versus the old single core computer. Now that you mention it, the new system is also about 60% faster by clock speed (2.0 vs 3.3 Ghz) though AMD did rate the old chip as a "3000+" which means at the time they thought it performed like a 3GHz chip. So in some ways the main advancement over a period of about 7 years was to figure out how to cram 600% more cores in the same space with only about a 50% rise in power usage, though that isn't really fair as that is ignoring a lot of other stuff like 64-bit.
Freezing UI does sound alot like a threading problem. I'm not sure what language and tools you're using, but you might want to google "Swing single thread rule" and read into the results to learn alot about the problem of multithreading UI's. Most of the results will be Java specific, but I'm sure they also apply to other technologies.
No crashes in two days. Firefox is for the most part responsive despite the tests being done (deliberately) in the worst environment I could think of - my work Ubuntu VM. The only time it crawled was using Blogger to write a blog entry, and once I finished, it stopped crawling, which... well, that was itself a massive improvement, if I did something to make it crawl, typically the only way to stop Firefox crawling was to restart it. No longer.
Yahoo Mail and Twitter, together with less memory intensive tabs like GMail, are still sitting there and are usable. I can never figure out what the actual memory figure is, but with a lot of tabs open, it's somewhere between 600M and 1200M (explicit vs vsize); typically I'd expect the figures to be over 1G/over 2G respectively within an hour or two of restarting the browser.
I have to say I'm absolutely delighted. My favorite browser is usable again.
Thank you. Thank you thank you thank you! You've done a wonderful thing.
You are not alone. This is not normal. None of this is normal.