×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Firefox Javascript Engine Becomes Single Threaded

Unknown Lamer posted more than 2 years ago | from the software-engineers-hate-sharing dept.

Firefox 346

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

346 comments

frist pst (-1, Offtopic)

wzzzzrd (886091) | more than 2 years ago | (#38820283)

ye

Re:frist pst (-1, Offtopic)

Anonymous Coward | more than 2 years ago | (#38820897)

Your first post looks to contain what looks like a disk, a black flap, and a scorpion.

SINGLE THREADED IS THE DOPE KING !! (-1)

Anonymous Coward | more than 2 years ago | (#38820297)

God save the Queen !!

God saves his son 1st, Jesuchrist. (0)

Anonymous Coward | more than 2 years ago | (#38820429)

God save the Queen !!

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

Re:God saves his son 1st, Jesuchrist. (2, Funny)

K. S. Kyosuke (729550) | more than 2 years ago | (#38820771)

It's an evil sentence for saving the tiranny originated by the supposed saved Queen

I'm puzzled. Since when does the UK have such a strong pro-Albanian foreign policy?

Re:God saves his son 1st, Jesuchrist. (-1)

Anonymous Coward | more than 2 years ago | (#38821011)

You're insensitive clod that did this weird question.

Why should UK be exclusively the interested country for God?.

I said that above statement was evil, not the country.

And for our goodness, God is our transcendental entity for all us that respect the goodness, and we don't commit bloody evilnesses.

God is not limited to an only country for its own interests.

"God save the Queen" and "God bless America" are wrongful statements that God shouldn't hear them as valid in its glorified kingdom that's not here on this world. Damn the sinners who collaborated the promotion of these statements for their particular interests.

JCPM

You had me at.. (5, Funny)

Sez Zero (586611) | more than 2 years ago | (#38820309)

"memory savings".

Re:You had me at.. (0, Offtopic)

Anonymous Coward | more than 2 years ago | (#38820345)

You actually read the entire summary?!? Dude, I lost interest at "Javascript".

Re:You had me at.. (5, Funny)

Anonymous Coward | more than 2 years ago | (#38820467)

There's a reason they're the most efficient browser when it comes down to memory usage. They actively work at it.

Re:You had me at.. (1, Funny)

Lisandro (799651) | more than 2 years ago | (#38820593)

There's a reason they're the most efficient browser when it comes down to memory usage. They actively work at it.

Yeah, it's not like it leaks memory like a BP pipeline.

Re:You had me at.. (5, Informative)

hedwards (940851) | more than 2 years ago | (#38820749)

Which is why they always cream the competition in the benchmarks? Seriously, the only time I've ever seen it waste memory was during a session where Silverlight crashed. In general it tends to use very little in the way of memory.

OTOH, given your post, I can only assume that you're using lynx, tons of extensions or are some sort of troll.

Re:You had me at.. (1)

Lisandro (799651) | more than 2 years ago | (#38820893)

No trolling at all. Latest versions of Firefox are better behaved regarding memory usage than former ones, specially with only a few tabs open, but will still leak memory steadly over time.

Oh, and i like Opera, thank you very much.

Re:You had me at.. (2, Informative)

Enderandrew (866215) | more than 2 years ago | (#38821191)

Please cite a documented case that isn't caused by an extension.

Firefox hasn't had any major memory leak problems since Firefox 2.

Re:You had me at.. (2, Informative)

Anonymous Coward | more than 2 years ago | (#38821269)

I'm a Firefox fan, but even they've stated they had very bad memory problems.

See this link: https://wiki.mozilla.org/images/9/93/LCA2012.pdf

Re:You had me at.. (5, Informative)

kbg (241421) | more than 2 years ago | (#38821377)

What, the hell are you talking about?

Didn't you read this slashdot article: http://developers.slashdot.org/story/12/01/17/1338225/notes-on-reducing-firefoxs-memory-consumption [slashdot.org]

Here is one of the relevant parts from the Firefox developer:

"Finally, Firefox 4 had a new HTML5 parser. It had a bug which meant that every time you set an innerHTML property on an element, some memory would leak. And that’s a pretty common operation on many websites. "

Please think before you post again.

Re:You had me at.. (5, Insightful)

MightyYar (622222) | more than 2 years ago | (#38821481)

Me to friend: Use Firefox! It has these awesome extensions! Definitely install AdBlock Plus, NoScript, Tree-Style Tabs, Auto Pager, IE Tab2, GreaseMonkey, Firebug, and the Developer Toolbar!

Friend: Does your Firefox use every bit of your system's memory?

Me: Pffft, well, only if I use the extensions!

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.

OM NOM NOM! (1)

zooblethorpe (686757) | more than 2 years ago | (#38821555)

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,

Re:You had me at.. (0)

Anthony Mouse (1927662) | more than 2 years ago | (#38821753)

Extensions can't be Firefox's killer feature if they make it eat all of your RAM.

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.

Of course, you've got to feel sorry for the poor bastard who still has a 2GHz Pentium 4 with less RAM than a Galaxy Tab.

Re:You had me at.. (-1)

Anonymous Coward | more than 2 years ago | (#38821027)

You've got to be kidding, there's permanent defects in extensions like Firebug because they cannot shut off streaming because of a bug the FF team will not fix. These leak memory. I restarted FF yesterday it's already at 1GB on my work desktop. FF is a POS and most people wouldn't use it w/o the very useful extensions.

Re:You had me at.. (5, Informative)

Anonymous Coward | more than 2 years ago | (#38821237)

Sorry, "leaks memory like a BP pipeline" sounds like the best description for a browser which seems to absolutely refuse to free up RAM used by old images loaded by Javascript that have since been kicked off the page. I can set up a timer to reload an image every, say, half hour* (think "weather report precipitation map" or "webcam image") on a machine that should be up 24/7, come in the next day, and have Firefox's "This page has a script that is not responding" popup because the OS was too busy thrashing swap after physical RAM filled up and Firefox thought it was the script's fault. It's not often I see the Mem and Swap meters in GKrellm2 solidly maxed out. For debug purposes, I can have it reload that image every five seconds and watch the memory steadily creep up every five seconds without ever doing anything resembling GC. Of course, if I close that tab, the memory returns instantly.

Now, you might say that for a kiosk that should remain up 24/7 like that, I should consider a different means of presenting the data. And ultimately, I did consider a different means. Because neither Chrome/Chromium nor Opera have this problem. Using the exact same script on both browsers, once it reloaded the image, the old one was booted out of memory immediately, or at least quickly enough that any extra memory use was marginal and incidental, and certainly not to the point where it would suck down all of swap like Firefox did. In fact, this script is still running on a kiosk here, it has been for a couple weeks straight now, and there's no memory wasting in sight. Firefox wouldn't have lasted the first night without manually reloading the entire page.

So yes. It's Firefox. Firefox leaks memory. A lot. It does this due to very poor cache decisions and inferior GC techniques. Period. This has been a known problem for some time; a cursory glance through Stack Overflow will find numerous questions regarding this exact situation and Firefox, none of which have conclusive answers besides "stop using Firefox". And the only common thread in all of them is Firefox. The problem is Firefox. Firefox is the problem. It leaks memory.

*: Note that this is using the trick of appending the image's URL with a dummy timestamp variable to trick Firefox into not just loading the old image from cache despite pragmas and meta tags telling it not to. Point still stands, though: Chrome/Chromium and Opera understand enough to unload the previous image from RAM with the exact same script and usage.

Re:You had me at.. (1)

Anonymous Coward | more than 2 years ago | (#38821443)

Benchmarks don't cover certain real-world scenarios, e.g., four months of continuous usage without ever closing the browser window. Nobody does that with MSIE, for a variety of reasons (not least: people who use the web browser as a long-term task management system don't use MSIE, because it's not up to it). Chrome hasn't been mature enough to be used that way until rather recently (arguably: still isn't), so it doesn't tend to get used that way either. Firefox does -- and yeah, it does tend to accumulate memory footprint as the weeks go by (linearly with number of pages loaded, I think, or maybe linearly with the number of tabs opened, even after they've been long since closed). Eventually you have to restart it, just to reclaim the several gigabytes of memory it's not actually using any more. This is annoying, but it's only because we *have* a browser that *can* be used that heavily without crashing outright that we even notice it.

Re:You had me at.. (1)

Anonymous Coward | more than 2 years ago | (#38821485)

Dude, FF9 with two tabs open and no plugins active: 400+ MB ram. This is 150 MB more than MS Access, Outlook, Word, Windows Explorer, and Dropbox, (all with active documents/data) combined. You've got to be from Mozilla. They're about the only people left in such denial about FF memory hogging.

Re:You had me at.. (4, Informative)

squiggleslash (241428) | more than 2 years ago | (#38821623)

Benchmarks are one thing, real life is another. I'm having to restart Firefox on a regular basis on my BRAND NEW EIGHT GIGABYTE LAPTOP. That's right:

  • In an age in which 1G netbooks are extremely common, I have eight times as much memory
  • It's a new laptop = fresh install of everything. The only thing carried over from my old machine was via Firefox Sync

So if you're about to whine "But Squiggy! It must be your profile! And you need to get with the program and have 4G of RAM", there's your answer. I don't want to hear it.

I really don't understand people like you who insist there isn't a problem when:

  • There's a massive groundswell of frustration and anger about the issue
  • Slashdot posts another "Mozilla reports - we found the problem! Next release will not have those memory problems!" article EVERY MONTH
  • Usage of CHROME, which in every other respect is an inferior browser to Firefox, is going through the roof

You think we're making it up? You think everyone's just switching to Chrome for the hell of it? Clue: they're not switching because it's more compatible, or more user friendly, or has more features. Because nobody outside of a Google diehard would ever argue such a thing.

We use Firefox for a bit. Some time goes by. Maybe we launch another application. Perhaps we view a PDF. And then it starts. It takes a second or more for Firefox to notice we clicked on something. The scrollbar is no longer real time. Switching a tab causes nothing to happen for ten seconds. We try closing tabs. We go to "about:memory" and hit every button. It seems... slightly faster. Or was that our imagination? Hmmm, it's gone slow again.

I'm giving up. I downloaded Firefox 3.6 from Mozilla's website last night. I'm going to make it my default browser.

Re:You had me at.. (0)

Anonymous Coward | more than 2 years ago | (#38821691)

Benchmarks are not representative of real world use. I haven't seen a single benchmark that left browsers open for weeks at a time, nor any that were opening and closes dozens of tabs within that time.

With a benchmark, you're trusting a group of people with a piece of software that is supposed to test everything in a 5 minute span of time. It doesn't work that way in real life.

Re:You had me at.. (1)

Joce640k (829181) | more than 2 years ago | (#38821037)

Yeah, it's not like it leaks memory like a BP pipeline.

Used to. [mozilla.org]

So...can we put this cliche to bed now?

Re:You had me at.. (1)

ae1294 (1547521) | more than 2 years ago | (#38821221)

Yeah, it's not like it leaks memory like a BP pipeline.

Used to. [mozilla.org]

So...can we put this cliche to bed now?

Not until they clean up all the residual memory!

Re:You had me at.. (2, Interesting)

BlueStraggler (765543) | more than 2 years ago | (#38821303)

So...can we put this cliche to bed now?

Considering how appalling the memory leaks were for YEARS while the moz folks insisted there weren't any problems, it will probably take at least as many years before any of us believe anything they say about memory usage.

I for one, won't believe they have any competence in memory management until I have spent 5 years without having to restart Firefox every other day.

Re:You had me at.. (1)

hedwards (940851) | more than 2 years ago | (#38821525)

You do largely have a point, but during that time there was a workaround. If you for whatever reason didn't want to close the browser regularly there was a memory trim on minimize fix that would force it to trim memory. I found that to work effectively.

But, yes you are correct between the 2.0 release and the 3.5 release where it was fixed that was about 3 years. Although, I probably should give them some credit for the time during which they were fixing it.

Re:You had me at.. (0)

Anonymous Coward | more than 2 years ago | (#38821379)

327Mb with ONE tab and no extentions. Fuck off with the doesnt leak memory BS

Re:You had me at.. (0)

Anonymous Coward | more than 2 years ago | (#38821687)

Sounds like you are looking at virtual memory i.e. mapped libs and shit that doesn't really use RAM?

Re:You had me at.. (1, Insightful)

owlnation (858981) | more than 2 years ago | (#38821455)

So...can we put this cliche to bed now?

No. Let's not.

Simply because Firefox devs are some of the most complacent, or downright willfully arrogant folks out there. It took years, literally years, for them to even admit there were massive memory leaks in Firefox. Anyone who suggested it here was branded a troll by them -- but that was back in the day when people liked, believed, and trusted in Firefox, back in the days when it was on its ascendancy. Those days are well and truly over.

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. They are already vain and arrogant about their lunatic version number race, so let's not go back to the days of them being in complete denial about other problems too. By not frequently reminding them about memory leaks, you are opening the door to yet more bloat going forward.

It's important they understand we have not forgotten how many years it took them to deal with the memory leaks they pretended did not even exist.

Re:You had me at.. (4, Informative)

jellomizer (103300) | more than 2 years ago | (#38820847)

However memory usage is one of those moot points.
Often (Not all the time) you come to a trade off of performance vs memory usage.
Sometimes it is better to store a bunch of data in memory just for quick reference then having to calculate it over and over again or worse need to get it from slower storage such as a disk.
Now there are things you can do to optimize the memory usage so it isn't as wasteful. However if you goal on low memory foot print chances are you are going to be sacrificing performance to use less memory.

Re:You had me at.. (0)

Anonymous Coward | more than 2 years ago | (#38821329)

Not autimatically true. There have been tests that showed cases where it was to faster and/or more energy efficient to recalculate data than to reload them from cache or even worse main memory. Reason is the rising gap between advances in pure computing power and memory technology. Most programs are now memory bound instead of computation bound as it was in the last decades.

Re:You had me at.. (1, Insightful)

Lumpy (12016) | more than 2 years ago | (#38820913)

Then why does it suck horribly compared to Chrome?

Honestly, Chrome is 3X faster than Firefox. Plus I dont get chrome locking up right after I click on a download like Firefox does for 12-20 seconds.

Re:You had me at.. (4, Informative)

sirsnork (530512) | more than 2 years ago | (#38821069)

Have you told firefox not to remember all your downloads indefinately? It gets a little slow when it's remembered a couple of hundred downloads, and that was the default setting a long time ago, if you've been upgrading and never reinstalled your OS you've probably still got that default setting.

In saying that, I use chrome now, once they decided to start bumping major versions every month or so, and upgrading broke at least one extension for a week, it was time to move to chrome. Oddly when I did I still preferred the FF UI, course now they have changed that to be more like chrome anyway.

Re:You had me at.. (-1)

Anonymous Coward | more than 2 years ago | (#38821079)

Well, Chrome is made with C/C++, while Firefox is almost done entirely in JavaScript. Chrome is a real native application, while the Firefox native bit only have the minimum required to run a JavaScript interpreter

Re:You had me at.. (1)

ae1294 (1547521) | more than 2 years ago | (#38821241)

Well, Chrome is made with C/C++, while Firefox is almost done entirely in JavaScript. Chrome is a real native application, while the Firefox native bit only have the minimum required to run a JavaScript interpreter

Troll Harder!

Re:You had me at.. (1)

sourcerror (1718066) | more than 2 years ago | (#38821293)

Chrome always chrases me on this site: index.hu
It says the flash plugin froze, but it works flawlessly with Firefox.

Re:You had me at.. (5, Interesting)

KiloByte (825081) | more than 2 years ago | (#38821563)

Where do you pull that "3X faster" from? Without proper AdBlock, Chrome seems to be only about as fast as Firefox. With AdBlock installed and properly configured (ie, not just the defaults, including "non" (hah) intrusive ads), Firefox runs circles around Chrome. If you can't bother setting it up, try NoScript.

That's just speed. Now try to factor in privacy, features or configurability. For example, in their default setting, Chrome crashes to desktop if you close the only tab. Someone on the Firefox team had the "brilliant" idea to ape that, and sadly, Firefox does that by default as well now. But fear not: "Close Last Tab" restores sanity. Also, tabs on top: I find myself using keyboard to access tabs only ~50% of the time -- the tab bar is accessed at least an order of magnitude more often than the URL bar, thus it should be more accessible. Again, the Firefox team aped Chrome's misfeature, but you can restore sanity easily. Get rid of the useless search bar? Here you go. Get rid of Google's typo-jacking? browser.fixup.alternate.enabled=false and keyword.enabled=false (you can type "google goat porn" if you want to search; rename the default keyword to "g" for convenience). Fix the http:/// [http] being hidden for 1/3 sites that still didn't go SSL? browser.urlbar.trimURLs=false. And so on, so on.

SetTimeout (5, Interesting)

Anonymous Coward | more than 2 years ago | (#38820319)

Maybe I'm missing something, but then how will "threading" (i use that term extremely loosely) methods like SetInterval and SetTimeout be implemented?

Re:SetTimeout (0)

Anonymous Coward | more than 2 years ago | (#38820375)

Proactor pattern.

Can't tell if trolling or serious (1)

Gazzonyx (982402) | more than 2 years ago | (#38820755)

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?

Re:Can't tell if trolling or serious (1)

Alex Belits (437) | more than 2 years ago | (#38820895)

Proactor pattern? Is that really a thing?

No. It's a stupid name for long-running tasks running in a separate context and calling a handler on completion (in unspecified context because people who define this stuff are stupid).

It also has nothing to do with anything being discussed.

Re:SetTimeout (5, Informative)

The MAZZTer (911996) | more than 2 years ago | (#38820465)

I am going to assume you are aware of how those functions work (specifically that they cannot interrupt the current thread if it is busy; they are only handled if the thread is idle) and that they themselves are not multi-threaded or have anything to do with multi-threading. It's not 100% clear from your post, though.

Multi-threading in JS is handled by web workers [whatwg.org] .

Re:SetTimeout (5, Interesting)

The MAZZTer (911996) | more than 2 years ago | (#38820515)

Oh I read your post wrong; anyways I did answer your question in the first bit.

Code sample:

setTimeout("alert('This alert fires second.');", 0);
for (var i = 0; i < 10000000; i++) { // Maybe do something in here that takes awhile. }
alert("This alert fires before the other one.");

Either your browser will display the alerts in the proper order despite the 0ms timeout (because timers are only handled when idle because they are NOT threaded) or your browser will get angry at the 10,000,000 iteration-long loop.

*More* outsourcing?! Bloody "globalization"! (3, Funny)

zooblethorpe (686757) | more than 2 years ago | (#38821625)

Multi-threading in JS is handled by web workers [whatwg.org] .

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.)

Re:SetTimeout (5, Informative)

Anonymous Coward | more than 2 years ago | (#38820481)

The same way it's always been implemented. setTimeout is event driven; it adds an event to the event queue to be executed at a later time. Once your code returns, the browser can spin the event loop again. The timer event will come up in due course and the browser will reenter the js engine to call your function.

Oh, I know this one! (-1)

Anonymous Coward | more than 2 years ago | (#38820503)

Horribly.

But... (-1)

Anonymous Coward | more than 2 years ago | (#38820377)

Aren't single threaded programs bad?

Re:But... (3, Informative)

allcoolnameswheretak (1102727) | more than 2 years ago | (#38820449)

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.

Re:But... (1)

HarrySquatter (1698416) | more than 2 years ago | (#38820561)

whereas individual CPU performance has been stagnating

Except not. The cores themselves are also more efficient and performant as well. Performance != gigahertz rating.

Re:But... (1)

Anonymous Coward | more than 2 years ago | (#38820869)

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.

Re:But... (1)

ae1294 (1547521) | more than 2 years ago | (#38821275)

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!

Re:But... (1)

hedwards (940851) | more than 2 years ago | (#38820809)

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.

Re:But... (0)

Anonymous Coward | more than 2 years ago | (#38821417)

>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.

Re:But... (1)

hedwards (940851) | more than 2 years ago | (#38821575)

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.

Re:But... (1)

superwiz (655733) | more than 2 years ago | (#38821497)

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).

Re:But... (4, Informative)

msclrhd (1211086) | more than 2 years ago | (#38820731)

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.

Re:But... (1)

hedwards (940851) | more than 2 years ago | (#38821601)

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.

Re:But... (4, Informative)

0xABADC0DA (867955) | more than 2 years ago | (#38820743)

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.

Re:But... (1)

DragonWriter (970822) | more than 2 years ago | (#38820917)

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.

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.

Re:But... (0)

Anonymous Coward | more than 2 years ago | (#38821033)

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.

Oh noes! (0)

Alex Belits (437) | more than 2 years ago | (#38820379)

The great technology inspired by illustrous Windows developers building the whole applications as everything-should-access-everything model, was abandoned!

Re:Oh noes! (1)

superwiz (655733) | more than 2 years ago | (#38821559)

Not sure why this was modded down. Windows WAS the system in which tread paradigm dominated. It was a performance gain in a single processor machine. Now that we are moving away from multi-threaded and towards multi-core, I guess most people forget what one has to do with the other.

us to hoist a lot data currently (4, Insightful)

ShakaUVM (157947) | more than 2 years ago | (#38820401)

"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.

Re:us to hoist a lot data currently (1)

Anonymous Coward | more than 2 years ago | (#38820499)

https://bugzilla.mozilla.org/show_bug.cgi?id=720753#c0

Re:us to hoist a lot data currently (0)

Locutus (9039) | more than 2 years ago | (#38820549)

yeah, why have multi-threading when you can just use different processors to keep applications responsive. Sounds like a cop out due to poor implementations to me. And lets stop running more than one application at a time since we can run our OS and app in virtual machines while we're at it.

LoB

Re:us to hoist a lot data currently (0)

Anonymous Coward | more than 2 years ago | (#38820733)

Because as I read the architecture, the "web worker" already runs the javascript as a separate background process from the HTML page. Why multithread something that is already running as a separate process?

Re:us to hoist a lot data currently (1)

Locutus (9039) | more than 2 years ago | (#38821267)

ah, so the "web worker" implementation from HTML5 does a better job for threading in Javascript. got it. If that's what developers find easier and better to use then it makes sense to simplify the threading in their own runtime. Being a published standard helps too so I get it now.

LoB

Re:us to hoist a lot data currently (1)

superwiz (655733) | more than 2 years ago | (#38821669)

Sounds like a cop out due to poor implementations to me.

It's not a cop out. You don't gain an advantage from multi-threading if your threads run on different cores. The main advantage of threads was avoiding a context switch during a blocking call. This way switching to another thread was cheaper. And since they ran on the same processor, it meant that you HAD TO switch to another thread. But on multiple cores they often run simultaneously. So if you have (for example) 2 threads running and one blocks, you won't get the advantage of avoiding a context switch to change from blocking to the running thread (because the the running one is running on another core). And you will still pay the performance hit for switching context, because your 1st core now has to run a thread from a different process. Given that writing everything in multi-threadead paradigm requires more complex memory management, it doesn't make sense to do it anymore: there are fewer performance gains from it and there is a higher frequency of bugs due to code complexity.

Re:us to hoist a lot data currently (1)

Anonymous Coward | more than 2 years ago | (#38820643)

This is what it sounds like to me:

If you have a binder full of pages, each one can be pulled out, so it may have to have some copyright information on each page. But if you've binded the book together more rigorously, as with string and glue, you can move the copyright information to one particular place and let the pages share it.

You need a VP (0)

Anonymous Coward | more than 2 years ago | (#38820849)

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.

Re:us to hoist a lot data currently (3, Interesting)

PhrostyMcByte (589271) | more than 2 years ago | (#38820981)

They mean to replace multiple per-thread copies of data with one single copy of it, accessible by all threads. No doubt part of Mozilla's latest push to reduce memory consumption.

One feature of x86 is that, save for a specialized SSE streaming store instruction, any store made by one core is immediately visible to all the other cores—even when the old value was already in a core's cache.

Maintaining such cache coherency involves a lot of overhead, so to get better scalability multi-threaded apps will sometimes adopt a "share-nothing" model: all threads get their own copy of the data, and no other threads will ever get to touch it. You trade memory and complexity for speed.

It sounds like Mozilla has decided this trade off is no longer worth it, and so has done away with multi-threading all together. Perhaps they will use green threads [wikipedia.org] instead of native threads, though that brings along its own bag of complexities.

However, 10+ Years After 64-Bit (-1, Offtopic)

feuertod (2547372) | more than 2 years ago | (#38820709)

Operating systems were widely available, Firefox has still failed to make a 64-bit dist

Re:However, 10+ Years After 64-Bit (1)

ilikenwf (1139495) | more than 2 years ago | (#38820861)

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.

Re:However, 10+ Years After 64-Bit (1)

hedwards (940851) | more than 2 years ago | (#38820879)

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.

Re:However, 10+ Years After 64-Bit (1)

loufoque (1400831) | more than 2 years ago | (#38821493)

The AMD64 instruction set and the ABI are so much better than on i386/i686 that you definitely should.

Re:However, 10+ Years After 64-Bit (0)

Anonymous Coward | more than 2 years ago | (#38820959)

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.

Re:However, 10+ Years After 64-Bit (1)

Jeng (926980) | more than 2 years ago | (#38821165)

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?

I am confusedf (0)

Anonymous Coward | more than 2 years ago | (#38820713)

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 about Add-ons / Extensions? (0)

Anonymous Coward | more than 2 years ago | (#38820765)

Firefox Add-Ons (well, at least Extensions) are JavaScript code and chrome directives. Will these get a separate thread?

Re:What about Add-ons / Extensions? (1)

Anonymous Coward | more than 2 years ago | (#38820933)

No, they will get a separate PROCESS, why would they need a thread?

How hard is it to understand? Multiple processes, each with multiple thread support, but generally only one actual thread executing, is ugly and failhappy. Multiple processes, each with a single thread, is simple and clean -- and does the same damn thing.

A mistake (3, Informative)

claytongulick (725397) | more than 2 years ago | (#38820867)

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.

Re:A mistake (0)

Anonymous Coward | more than 2 years ago | (#38821365)

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.

Citation needed.

It sounds to me that your suggestion is not something that you graft on to an existing multi-threaded implementation.

Probably would be the same as ripping/replacing existing code, and then designing it properly.

They've done the rip/replace.

Sleeping tabs (1)

anyanka (1953414) | more than 2 years ago | (#38821287)

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.

Backwards, but ok.... (0)

medv4380 (1604309) | more than 2 years ago | (#38821381)

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.

server-side (0)

Anonymous Coward | more than 2 years ago | (#38821521)

So much for server-side javascript, where you actually need threads like nothing else.

Does this mean... (0)

Anonymous Coward | more than 2 years ago | (#38821603)

... it'll just leak memory more slowly?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...