Re: Intent to ship: Hashbang syntax in JS (a "#!" line at the very start of a script is a single-line comment)

Thank you for doing this! It's a minor, but real, source of potential web-compat issues, so it's nice to have it handled. On Thu, Feb 28, 2019 at 11:00 PM Jeff Walden wrote: > ## Support in other browser / JS engines > > https://github.com/v8/v8/commit/0cd67eb7c57e109aa4cbc8b8bdff6b9eaf8c1286 >

Re: Intent to ship: BigInt

On Thu, Feb 21, 2019 at 9:56 AM L. David Baron wrote: > On Thursday 2019-02-21 15:44 +0100, Andy Wingo wrote: > > ## Support in other browser / JS engines > > > > Chrome / V8 implements the draft spec. > > > > Safari / JavaScriptCore has a partial implementation that is being > > completed on an

Re: Dead-code removal of unused Rust FFI exports

CC'ing mw, who is working on cross-language LTO. On Tue, Aug 28, 2018 at 3:20 PM Mike Hommey wrote: > On Tue, Aug 28, 2018 at 09:14:02AM -0400, Jeff Muizelaar wrote: > > We don't LTO yet on Mac. > > We don't LTO across languages on any platform yet. Rust is LTOed on all > platforms, which

Re: Firefox and clang-cl

On Mon, Aug 14, 2017 at 9:27 AM, Julian Seward wrote: > On 13/08/17 03:40, Ehsan Akhgari wrote: > > As you may have heard by now, Chromium has started to switch their > Windows > > builds to use clang-cl instead of MSVC [1]. This has improved their > > Speedometer v2 benchmark

Re: Async Iteration is available on non-release-only, for testing purpose

I think disabling in chrome code is a good idea. We have done these kinds of non-release-only features in the JS engine in the past, and it hasn't always gone well precisely for the reasons that have you concerned. OTOH, adding a pref is annoyingly complicated for JS engine features (we should

Re: Switching to async/await from Task.jsm/yield

On Sun, Mar 26, 2017 at 8:16 PM, Ehsan Akhgari wrote: > On 2017-03-17 7:41 PM, Kris Maglione wrote: > > On Fri, Mar 17, 2017 at 07:30:46PM -0400, Ehsan Akhgari wrote: > >> Have we measured the performance of our async/await implementation? I > >> think we should

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Tue, Feb 14, 2017 at 12:00 PM, 段垚 <duan...@ustc.edu> wrote: > > > 在 2017/2/14 18:10, Till Schneidereit 写道: > >> On Tue, Feb 14, 2017 at 12:14 AM, 段垚 <duan...@ustc.edu> wrote: >> >> I guess all popular softwares have exploits being traded. How

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Tue, Feb 14, 2017 at 12:14 AM, 段垚 wrote: > I guess all popular softwares have exploits being traded. How this fact >>> invalidates my argument? >>> >> I was responding to your point about the threat declining because of the >> declining usage of Flash. This is demonstrably

Re: Intent to disable service workers and push in 52 ESR

On Wed, Jan 18, 2017 at 5:43 PM, Ben Kelly <bke...@mozilla.com> wrote: > On Wed, Jan 18, 2017 at 10:58 AM, Till Schneidereit < > t...@tillschneidereit.net> wrote: > >> That'll mean that Windows XP/Vista users won't have them. >> >> Might be ok, but means

Re: Intent to disable service workers and push in 52 ESR

That'll mean that Windows XP/Vista users won't have them. Might be ok, but means the bar for a decision like this should be somewhat higher than usual, I think. On Wed, Jan 18, 2017 at 4:49 PM, Ben Kelly wrote: > Hi all, > > I'd like to disable service workers in 52 ESR.

Re: Tamarin

e any good like ActionScript. I was looking at asm.js > and it does use a strict subset of javascript.Also Emscripten and I do > have Unreal 4. > > On Fri, Aug 12, 2016 at 8:21 AM, Till Schneidereit > <t...@tillschneidereit.net> wrote: > > On Fri, Aug 12, 2016 at 1:45 PM,

Re: Tamarin

nce mode there, too. > > All the best, > > Jonathan. > > On Fri, Aug 12, 2016 at 5:03 AM, Till Schneidereit > <t...@tillschneidereit.net> wrote: > > Hi Jonathan, > > > > first, I'll strongly recommend that you take a look at WebAssembly as

Re: Tamarin

Hi Jonathan, first, I'll strongly recommend that you take a look at WebAssembly as a possible alternative to what you're trying to do. It'll be integrated into the web platform more and more over the coming years, and might just satisfy your needs. That being said, you can find the Tamarin

Re: the looming wasm chasm was Re: Requiring SSE2 on all 32-bit x86 OSs

On Sun, May 22, 2016 at 10:43 PM, Cameron Kaiser wrote: > On 5/18/16 10:41 PM, Jan de Mooij wrote: > >> They do get the baseline compiler, which can still be significantly >>> faster than the interpreter, but Ion requires SSE2. Since the runtime >>> detection does just turn

Re: help:browser tool box debugger is not stopped

On Mon, Apr 25, 2016 at 8:41 AM, oonuma ryouyu wrote: > I think this is not bug. > Or normally firefox memorized breakpoints before restart? > You're right: breakpoints aren't remembered across restarts, so that part isn't a bug. The breakpoint being ignored, however,

Re: An analysis of content process memory overhead

I filed bug 876173[1] about this a long time ago. Recently, I talked to Gabor, who's started looking into enabling multiple content processes. One other thing we should be able to do is sharing the self-hosting compartment as we do between runtimes within a process. It's not that big, but it's

Re: any concerns with dropping the talos test v8 and using AWFY Octane instead?

On Mon, Jan 11, 2016 at 3:08 PM, wrote: > Currently we run a very outdated version of V8 (version 7) in Talos. This > has since been replaced with Octane in the world of benchmarks. > > AWFY (arewefastyet.com), has been running Octane and catching regressions > faster than

Re: Dan Stillman's concerns about Extension Signing

On Thu, Nov 26, 2015 at 10:02 AM, Thomas Zimmermann <tzimmerm...@mozilla.com > wrote: > Am 25.11.2015 um 20:16 schrieb Jeff Gilbert: > > On Wed, Nov 25, 2015 at 3:16 AM, Till Schneidereit > > <t...@tillschneidereit.net> wrote: > >> FWIW, I received questions ab

Re: Dan Stillman's concerns about Extension Signing

FWIW, I received questions about this via private email and phone calls from two people working on extensions that support their products. Their extensions sit in the review queue with not chance of getting through it before the signing requirement kicks in. This puts them into a situation where

Re: Decreasing quality?

On Wed, Aug 19, 2015 at 3:18 AM, Gavin Sharp ga...@gavinsharp.com wrote: It's possible this bug was being confused with bug 1195030. That seems likely, yes. Being responsible for this particular regression, I can say that neither is it at all related to the other bugs mentioned, nor can it

Re: Array.concat

On Tue, Jul 21, 2015 at 12:19 PM, Mike de Boer mdeb...@mozilla.com wrote: Hi Amit, These are called ‘Generics’ and are available in Firefox as of JavaScript 1.6 - see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods

Re: The e10s throbber

On Tue, Apr 7, 2015 at 5:05 PM, Bill McCloskey wmcclos...@mozilla.com wrote: I think we probably want to use a longer delay than 300ms before we show the spinner. We'd also like to look into why it takes so long to re-create the layer tree when we switch to a tab. Sometimes it's caused by a

Re: Enhancing Gecko as a WebGL game platform

On Tue, Jan 13, 2015 at 8:24 PM, Luke Wagner lwag...@mozilla.com wrote: Do you know what they actually mean when they use the term hardware pointer? I believe what he's referring to is the type of hardware-accelerated cursor support discussed here:

Re: Array.prototype.includes available in Nightly *only* String.prototype.contains renamed to includes

, Nov 21, 2014 at 5:10 AM, Till Schneidereit t...@tillschneidereit.net wrote: Greetings! TC39 has decided to solve the web-compat issues with Array.prototype.contains that forced us to back out the feature on October 1st by renaming the method to includes. This has now landed on Nightly

Array.prototype.includes available in Nightly *only* String.prototype.contains renamed to includes

Greetings! TC39 has decided to solve the web-compat issues with Array.prototype.contains that forced us to back out the feature on October 1st by renaming the method to includes. This has now landed on Nightly. However, it is Nightly-only for now, so don't use it in production code that's

Re: PSA: Array.prototype.contains is going away again

On Thu, Oct 2, 2014 at 2:24 PM, Philip Chee philip.c...@gmail.com wrote: On 02/10/2014 17:30, David Rajchenbach-Teller wrote: On 02/10/14 10:49, James Graham wrote: Unfortunately js libraries aren't like web browsers; you can't just ship a new version and upgrade all existing users in a

Re: PSA: Array.prototype.contains is going away again

On Wed, Oct 1, 2014 at 7:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-10-01, 1:20 PM, Till Schneidereit wrote: That's a great point. It would be great if we can adopt https://wiki.mozilla.org/WebAPI/ExposureGuidelines for new JS fatures as well. Yes, I think we

Re: PSA: Array.prototype.contains is going away again

On Thu, Oct 2, 2014 at 4:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-10-02, 9:58 AM, Till Schneidereit wrote: The full answer to that is actually ridiculously complicated. The part relevant here is, though: very early on in at least some cases. Too early to rely on preferences

PSA: Array.prototype.contains is going away again

Unfortunately, it turns out that Array.prototype.contains breaks the web. Or, the MooTools-using parts of the web, at least. So I'm preparing a backout right now. What's more pressingly unfortunate is that Array.prototype.contains enjoys a surprisingly spectacular popularity: it's already used in

Re: PSA: Array.prototype.contains is going away again

That's a great point. It would be great if we can adopt https://wiki.mozilla.org/WebAPI/ExposureGuidelines for new JS fatures as well. Yes, I think we should consider that. The situation is somewhat different in that we usually only implement features that are stable, specced, and agreed

Re: easiest way to contribute .

On Thu, Sep 25, 2014 at 9:45 PM, Mike Hoye mh...@mozilla.com wrote: This page: https://developer.mozilla.org/en-US/docs/Introduction ... has some good information about getting your development environment set up so you can contribute to Firefox. And so does this: http://codefirefox.com/

Re: Intent to implement: image-rendering: pixelated CSS property-value

On Wed, Sep 24, 2014 at 7:21 PM, Daniel Holbert dholb...@mozilla.com wrote: On 09/24/2014 07:38 AM, Ehsan Akhgari wrote: This makes the implementation considerably simpler, which is great. It also means that pixelated will essentially just be a more-interoperable version of

Re: Review Board Preview

I agree with Ehsan: this is really exciting! Do you also plan to add integration with external repositories at a later point? I'm working on the Shumway project, and we do our bug tracking in BMO, but have our source in github (largely for historical reasons, but a reason for not moving away

Re: Review Board Preview

On Mon, Sep 15, 2014 at 4:40 PM, Mark Côté mc...@mozilla.com wrote: Yes, we plan on supporting more than just mozilla-central. The initial deployment will only support Mercurial, but we plan on adding git support soon after--and there's no reason it couldn't work with GitHub as well.

Re: What are the most important new APIs to document in Q3/Q4?

Some ES6 features would be great to have documentation for. Symbols and Template Strings come to mind, both of which have recently landed at least partially. On Fri, Jun 27, 2014 at 6:03 AM, Eric Shepherd esheph...@mozilla.com wrote: On 2014-06-26 23:07:40 +, Brian Birtles said: I hope

Re: C++ standards proposals of potential interest, and upcoming committee meeting

On Mon, Jun 9, 2014 at 9:45 PM, Benoit Jacob jacob.benoi...@gmail.com wrote: I would like the C++ committee's attention to be drawn to the dangers, for committee, to try to make decisions outside of its domain of expertise. I see more potential for harm than for good in having the C++ committee

Re: Google announces Chrome builds for Win64

On Thu, Jun 5, 2014 at 2:36 PM, Philip Chee philip.c...@gmail.com wrote: On 04/06/2014 22:32, jmor...@mozilla.com wrote: We have a good understanding of the work required. The development work, as you might suspect, is largely done. We still produce 64 bit builds. The notable areas

Re: Intent to implement: DOMMatrix

On Wed, Jun 4, 2014 at 1:17 AM, Rik Cabanier caban...@gmail.com wrote: On Tue, Jun 3, 2014 at 3:48 PM, Till Schneidereit t...@tillschneidereit.net wrote: On Wed, Jun 4, 2014 at 12:26 AM, Rik Cabanier caban...@gmail.com wrote: Actually, inverse() is already spec'd to throw

Re: Intent to implement: DOMMatrix

On Wed, Jun 4, 2014 at 12:26 AM, Rik Cabanier caban...@gmail.com wrote: Actually, inverse() is already spec'd to throw if the inversion fails. In that case (assuming we keep it that way) there is no need at all for any isInvertible kind of method. Note that in floating-point arithmetic

Re: Standardized assertion methods

Should we adopt these for SpiderMonkey's test suites, too? Porting tests between suites isn't something that's done frequently, but there are people writing tests for more than one suite, and being able to use the same assertion methods everywhere would be helpful for that. On Mon, Jun 2, 2014

Re: Policing dead/zombie code in m-c

(CC'ing people who have worked on the ICU integration) On Thu, Apr 24, 2014 at 2:31 PM, Henri Sivonen hsivo...@hsivonen.fi wrote: However, especially in the context of slimming down our own set of encoding converters, it's rather demotivating to see that at least on desktop, we are building

Re: Using rr to track down intermittent test failures

On Wed, Apr 16, 2014 at 1:52 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2014-04-15, 7:14 PM, Gijs Kruitbosch wrote: On 16/04/2014 00:05, Robert O'Callahan wrote: We just released rr 1.2 and I think this would be a good time for people to try to use it for one of the tasks it was

Re: Wasted bytes due to padding (bug 492185)

On Fri, Feb 21, 2014 at 7:15 AM, Gabriele Svelto gsve...@mozilla.comwrote: On 20/02/2014 18:57, arpad.bor...@googlemail.com wrote: And yes, allocation counts would be awesome. Any idea how to get to those? Or even better: number of average live objects, since short lived allocations do not

Re: Individual files should have a reviewer reference

On Fri, Feb 14, 2014 at 10:35 AM, Nick Alexander nalexan...@mozilla.comwrote: On 2/13/2014, 1:23 PM, Honza Bambas wrote: An optional /* @reviewer: m...@foo.com */ comment under the license would do. If not present, find reviewer the usual way (not always hitting the right person). -1

Re: Cairo being considered as the basis of a standard C++ drawing API

On Mon, Feb 10, 2014 at 12:00 PM, Brian Smith br...@briansmith.org wrote: On Sun, Feb 9, 2014 at 2:54 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Feb 10, 2014 at 11:49 AM, Brian Smith br...@briansmith.org wrote: It seems likely that if something like Moz2D became the standard

Re: Intent to ship DOM Promises

On Wed, Jan 29, 2014 at 9:07 PM, nsm.nik...@gmail.com wrote: On Wednesday, January 29, 2014 10:35:24 AM UTC-8, Nikhil Marathe wrote: As off January 28, our DOM Promises implementation implements the es6 promises spec. [1] It is feature complete, and passes the Promises/A+ tests. [2]

Re: using LLDB to debug Gecko

This is fantastic, thank you so much! a few months ago, I started looking into porting the pretty printers and niceties for various SpiderMonkey things that live in js/src/gdb, but the way much of this works is very different from gdb, so I didn't get too far back them. This makes me want to pick

Re: Terminating xulrunner?

Hi Gio, please read the previous messages in this thread: they contain answers to all these questions. In fact, they're pretty much all answered right in the first message[1]. [1]: https://groups.google.com/d/msg/mozilla.dev.platform/o99wQZBjIJw/4eBoWbjEzjAJ On Tue, Jan 21, 2014 at 7:02 AM,

Re: Decommissioning dumbmake

(Some messages in this thread seem to be taking an absurdly long time to arrive, so I apologize if what I'm talking about has long been addressed.) On Thu, Jan 16, 2014 at 2:00 PM, Philip Chee philip.c...@gmail.com wrote: On 15/01/2014 02:37, Matt Brubeck wrote: On 1/13/2014 8:05 PM, Mike

Re: Decommissioning dumbmake

On Thu, Jan 16, 2014 at 6:05 PM, Ted Mielczarek t...@mielczarek.org wrote: On 1/16/2014 11:26 AM, Till Schneidereit wrote: I'd be extremely unhappy if this disappeared without any replacement. Changing a cpp file under js/src and running `mach` takes about 2 minutes for me, whereas

Re: JavaScript Style Guide. Emacs mode line.

On Wed, Jan 8, 2014 at 9:25 AM, ishikawa ishik...@yk.rim.or.jp wrote: BTW, do java or javascript programmers use Eclipse with its built-in editor with suitable editor configuration, and that is the end of the story for such Eclipse users when they tinker with Mozilla source code? I use

Re: Bug 641509

My point is that your arguments have been brought forward in the discussion, and your post didn't bring anything new to the table. You might disagree with the decision the contributors and owners of the affected module have come to, and that's your right. Snide remarks and shooting down

Re: style guide proposal

On Thu, Dec 19, 2013 at 5:02 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: -- Ehsan http://ehsanakhgari.org/ On Thu, Dec 19, 2013 at 4:32 AM, Mike Hommey m...@glandium.org wrote: How about we just use clang-format? http://www.irill.org/videos/euro-llvm-2013/jasper-hires.webm

Re: [RFC] Cleaning up sessionstore.js

On Thu, Nov 28, 2013 at 11:56 AM, David Rajchenbach-Teller dtel...@mozilla.com wrote: As many of you know, Session Restore is something of a performance hog, for many reasons – we have reports of. One of the reasons is that we store so very many things in sessionstore.js and sometimes keep

Re: [RFC] Cleaning up sessionstore.js

On Thu, Nov 28, 2013 at 1:55 PM, David Rajchenbach-Teller dtel...@mozilla.com wrote: On 11/28/13 1:33 PM, Till Schneidereit wrote: This would all be tackled after we did other things like getting rid of all history entries for iframes, which won't be restored in any case, right? We're

Re: W3C Proposed Recommendations: Performance Timeline, User Timing, JSON-LD

I don't know how well (or if at all) the current push for performance devtools is coordinated with these proposals, but it would certainly be worth looking into that. CCing Axel Kratel. On Tue, Nov 26, 2013 at 12:31 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/25/13 7:07 PM, L. David Baron

Re: Intent to replace Promise.jsm and promise.js with DOM Promises

On Wed, Nov 20, 2013 at 12:51 PM, Anne van Kesteren ann...@annevk.nlwrote: On Tue, Nov 19, 2013 at 5:30 PM, Boris Zbarsky bzbar...@mit.edu wrote: We could report all rejections, but I'm a bit leery of adding so much noise that people start ignoring the report altogether; a common problem in

Re: Intent to replace Promise.jsm and promise.js with DOM Promises

On Wed, Nov 20, 2013 at 4:04 PM, David Rajchenbach-Teller dtel...@mozilla.com wrote: On 11/20/13 1:09 PM, Till Schneidereit wrote: How about logging them with console.info? That seems the right logging level to me, and it's easy to turn off if it gets in the way. Well, the problem

Re: Mozilla development bootcamp

On Sun, Nov 3, 2013 at 11:07 PM, bbo...@gmail.com wrote: On Sunday, November 3, 2013 12:02:15 PM UTC-5, Alexandre BM wrote: I see a lot of VS and .exes, any plans for development on Unix ? (make, gcc, gdb, g* tools ?) ~ rednaks Yes these are just starting videos, but I was planning to

Re: Synchronous workers

- Original Message - How common are the blocking API calls? Can we somehow predict whether the SWF will need that, and optionally use a worker/non-worker context based on that? Fairly common: many SWFs use ExternalInterface at least once, and even more use BitmapData#draw, which

Re: Synchronous workers

Didn't see this before now, sorry. On Mon, Oct 14, 2013 at 6:15 PM, Benjamin Smedberg benja...@smedbergs.us wrote: On 10/14/2013 12:06 PM, Bobby Holley wrote: How common are the blocking API calls? Expect them to be very common or almost universal for real Flash. Much less common for simple

Re: Synchronous workers

On Mon, Oct 14, 2013 at 6:30 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Mon, Oct 14, 2013 at 6:21 PM, Till Schneidereit t...@mozilla.com wrote: Nobody's proposing to expose any of this to web content. The question is whether we want to fully expose it as an official capability of Gecko

Re: Synchronous workers

On Mon, Oct 14, 2013 at 10:16 PM, Benjamin Smedberg benja...@smedbergs.us wrote: On 10/14/2013 4:12 PM, Robert O'Callahan wrote: On Mon, Oct 14, 2013 at 11:03 AM, Benjamin Smedberg benja...@smedbergs.us mailto:benja...@smedbergs.us wrote: Having this blocking interface will also support

Re: Synchronous workers

On Mon, Oct 14, 2013 at 11:31 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Oct 14, 2013 at 4:29 PM, Till Schneidereit t...@tillschneidereit.net wrote: From talking to Kyle, it sounds like getting WebGL into workers is much closer than getting all of Context2D, too. Specifically

Re: What platform features can we kill?

On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto gsve...@mozilla.com wrote: On 10/10/2013 02:36, Zack Weinberg wrote: In that vein, I think we should take a hard look at the image decoders. Not only is that a significant chunk of attack surface, it is a place where it's hard to innovate;

Re: What platform features can we kill?

On Thu, Oct 10, 2013 at 6:56 PM, Brian Smith br...@briansmith.org wrote: I'm not sure. Things like this seem like really good ideas: http://blogs.msdn.com/b/ie/archive/2013/09/12/using-hardware-to-decode-and-load-jpg-images-up-to-45-faster-in-internet-explorer-11.aspx Obviously, I am linking

Re: Extensibility of JavaScript modules

Interesting. I wonder if the monkey patching will even still work once we have es6 modules and use them in the platform. Jason and Eddy, you probably know, but I'm under the impression that monkey patching an es6 module requires funneling it through a custom module loader. Maybe the platform

Re: Implementing Pepper since Google is dropping NPAPI for good

On Tue, Sep 24, 2013 at 5:19 PM, Zack Weinberg za...@panix.com wrote: On 2013-09-23 4:29 PM, Hubert Figuière wrote: PS: I truly believe that we should drop plugin support all together, but that's not what I'm discussing here. I think if we think our options going forward are implement

Re: Best way to make xpcshell provide consistent stack limits?

On Sat, Jun 29, 2013 at 12:52 AM, Benjamin Smedberg benja...@smedbergs.uswrote: On 6/26/13 7:06 PM, Andrew Sutherland wrote: d) Change xpconnect to use jsnativestack.cpp's ability to tell us what the platform stack size actually is and/or nsThread's knowledge of the stack size it was

Re: Best way to make xpcshell provide consistent stack limits?

Thanks for bringing this up. I agree that we should do something about this, and if only for testing purposes. I would tend to favor g) Add a command line argument to set the stack quota to the lowest any of our platforms support. That way, you can be sure that your script really does run on all

Re: Proposal to make Firefox open in the foreground on Mac when launched from terminal

Oh yes, please, a thousand times yes! On Thu, May 30, 2013 at 12:09 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: Typically when you use the terminal to open an application on Mac, the application is opened in the background. This means that for example when you use mach run or mach

Re: Rethinking the amount of system JS we use in Gecko on B2G

On Thu, Apr 25, 2013 at 7:41 AM, Caspy7 cas...@gmail.com wrote: I'm not a developer and so apologize if my understanding is oversimplified or naive. I had been under the impression that C++ (previously) was not being used at all, apart from Gecko itself, for security and stability reasons.

Re: Accelerating exact rooting work

There's a rooting guide on the wiki here: https://developer.mozilla.org/en-US/docs/SpiderMonkey/GC_Rooting_Guide It's not very thorough, but it's something. On Tue, Apr 23, 2013 at 3:14 PM, Tom Schuster t...@schuster.me wrote: You wont have to bother with HandleObject or RootedObject etc.

Re: Rethinking the amount of system JS we use in Gecko on B2G

There are a few things we're working on in SpiderMonkey that should improve this situation quite a bit: Terrence already mentioned generational GC, which certainly is the largest piece by far. Getting rid of all or almost all memory lost to fragmentation makes the tradeoff a considerably

Re: Rethinking the amount of system JS we use in Gecko on B2G

On Mon, Apr 22, 2013 at 9:48 PM, Justin Lebar justin.le...@gmail.comwrote: This is all great stuff, but as mentioned elsewhere, B2G branched at version 18 and so they need improvements that that can land quickly on the relevant branches. I understand that (but should certainly have made

Re: The future of PGO on Windows

In the long run, 1 and 3 are the same. If we know we're going to turn it off, why not bite the bullet and do it now? Because we're still missing plenty of optimizations in our code to be fast in microbenchmarks. It would be quite huge pr loss if we suddenly were 10-20% slower in

Re: The future of PGO on Windows

On Thu, Jan 31, 2013 at 4:42 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2013-01-31 10:33 AM, Till Schneidereit wrote: In the long run, 1 and 3 are the same. If we know we're going to turn it off, why not bite the bullet and do it now? Because we're still missing plenty