Re: [JS-internals] js vs wasm and js vs js across browsers

On 12/18/18 11:38 PM, Lars Hansen wrote: I have not dug into it in detail, but I worry especially about the tremendous negative spikes in our JS performance for the non-closure-compiled case I'm a bit concerned about the non-webasm performance here in general. Is there a bug tracking this? -

Re: [JS-internals] JS engine multithreading

On 1/27/17 11:44 AM, Brian Hackett wrote: These per-thread jsid tables are used to accommodate the separate worker runtimes, right? That's correct. then they'll be able to share jsids and separate per-thread tables won't be necessary. Excellent. ;) -Boris

Re: [JS-internals] JS engine multithreading

On 1/27/17 10:36 AM, Brian Hackett wrote: Any thoughts or comments? Oh, one more thing: will a result of this be that jsids can be used across threads (at least if you appropriately pin them and whatnot)? Right now Gecko has some per-thread jsid tables that duplicate information; it would be

Re: [JS-internals] JS engine multithreading

On 1/27/17 10:36 AM, Brian Hackett wrote: Any thoughts or comments? How much (if any) of this work is visible via the public API? -Boris ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozil

Re: [JS-internals] Generating an ErrorReport from a thrown value

On 5/4/16 11:40 AM, Ehsan Akhgari wrote: 1. If the JS code throws an ErrorObject (such as |throw new Error("foo");|) I get the line and column info as expected, but if it throws something else (such as |throw new "foo";|) then the line and column number seem to always be 0. That's because we do

Re: [JS-internals] Reducing SpiderMonkey's crash rate

On 5/3/16 1:28 PM, Jakob Stoklund Olesen wrote: It is not assertions that make unoptimized C++ really slow, it is the lack of inlining which is critical to clean up template abstraction goop. It depends on the assertions. In the case of the JS engine, the particular assertions under discussi

Re: [JS-internals] Reducing SpiderMonkey's crash rate

On 5/2/16 7:29 PM, Nicholas Nethercote wrote: I doubt anyone is doing large amounts of browsing in debug builds. dbaron does, last I checked: --enable-debug --enable-optimize builds. -Boris ___ dev-tech-js-engine-internals mailing list dev-tech-js-en

Re: [JS-internals] Self-hosted DOM - meetings summary

On 11/26/15 5:01 PM, smaug wrote: One concern, or more like 'a thing to keep in mind', memory management, more precisely *collector optimizations. Cycle collector has the advantage that it deals with the possible-garbage objects, not live objects and it is easy and usually fast to optimize out ce

Re: [JS-internals] strict mode and string index

On 6/10/15 10:51 AM, Boris Zbarsky wrote: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-string-exotic-objects says: Both the code unit data properties and the "length" property are non-writable and non-configurable. Or if you prefer the actual normative text is prob

Re: [JS-internals] strict mode and string index

On 6/10/15 3:45 AM, obastemur wrote: Couldn't find the corresponding ecma spec on this restriction. http://people.mozilla.org/~jorendorff/es6-draft.html#sec-string-exotic-objects says: Both the code unit data properties and the "length" property are non-writable and non-configurable. Th

Re: [JS-internals] Big Performance Difference Between JSShell vs Embedded App

On 6/4/15 2:52 PM, Jason Hill wrote: 40 is stable like 38 ? Not yet. compileAndGo is default true now! In 40 it's just gone, fwiw. There's a new thing for weird cases when you're not running against a global scope that may or may not be relevant to you but is handled automatically anyway

Re: [JS-internals] Big Performance Difference Between JSShell vs Embedded App

On 6/4/15 12:37 PM, Jason Hill wrote: Found it. First it looked unimportant but when I set setCompileAndGo(false) the perf is so bad. What could be the reason? Turning off compileAndGo disables Ion altogether for toplevel scripts and makes global variable access really slow in general. Why are

Re: [JS-internals] Big Performance Difference Between JSShell vs Embedded App

On 6/4/15 7:28 AM, Jason Hill wrote: All the ion, baseline settings are enabled. May I ask what the code enabling them looks like on your end? Also, which version of SpiderMonkey is this? -Boris ___ dev-tech-js-engine-internals mailing list dev-tech

Re: [JS-internals] SpiderMonkey 370 - JSNative vs JSPropertyOp

On 3/28/15 11:48 PM, obastemur wrote: I have getter/setter implementation that makes a JS side object (an object created on the JS land, which doesn't have private slot or extra slots. OK, that's fine. I'm saying your getter or setter can have extra slots to store the property name in. I'm

Re: [JS-internals] SpiderMonkey 370 - JSNative vs JSPropertyOp

On 3/28/15 11:08 PM, obastemur wrote: "Use different JSNatives for different properties. Or a single JSNative, but allocate the function yourself and use extra reserved slots on it to store the property name... " Unfortunately this may not be an option for many scenarios. Which "this"? I offe

Re: [JS-internals] SpiderMonkey 370 - JSNative vs JSPropertyOp

On 3/27/15 9:24 AM, obastemur wrote: AFAIK all the getter setter stuff are moved from JS_DefineProperty.. to JSNative types. Correct. JSPropertyOp is on the chopping block, certainly on a per-property basis. Its semantics aren't really a match for anything in the ES spec, unlike JSNative a

Re: [JS-internals] JS scope behavior difference

On 3/17/15 2:10 PM, obastemur wrote: Still, considering the today's JavaScript usage, and this one is already handled by an other browser(s) In different ways, note. And worse yet, as Jason said, websites do UA sniffing and depend on the different ways that browsers handle this syntactic con

Re: [JS-internals] JSObject / JS::Value Private Slot

On 2/24/15 3:39 PM, Boris Zbarsky wrote: Use a symbol-named property? Or if you want this to be completely invisible to everyone, use a weakmap keyed on argument 0? -Boris ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals

Re: [JS-internals] JSObject / JS::Value Private Slot

On 2/24/15 12:02 PM, obastemur wrote: FS_OBJECT.NATIVE_METHOD_1 { save a pointer to 'this(fs_object)' into argument 0 } Use a symbol-named property? -Boris ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org

Re: [JS-internals] JSObject / JS::Value Private Slot

On 2/24/15 11:06 AM, obastemur wrote: Private slot holds the native wrapper object. Backing up for a sec Do you need to associate "native wrapper objects" to arbitrary JS objects? Or only some JS objects? How do you determine which objects need a "native wrapper object"? -Boris _

Re: [JS-internals] JSObject / JS::Value Private Slot

On 2/24/15 11:06 AM, obastemur wrote: Private slot holds the native wrapper object. Is there another way to keep a memory reference on a JSObject other than private slot or (indexed slots) ? Metadata, right? Also, what do you plan to do with objects that _do_ already have a private slot and

Re: [JS-internals] JSObject / JS::Value Private Slot

On 2/24/15 10:10 AM, obastemur wrote: Add/Enable private slot for a JS land object or an object without a private slot. - JS_Add/EnablePrivateSlot So this requires: 1) Moving the object (since its size will change). Maybe not a problem now that GC can move things too. 2) Changing the o

Re: [JS-internals] Destroying inner JSContext safely

On 2/15/15 4:24 PM, obastemur wrote: --->JS_ASSERT(!cx->compartment()); This is asserting that no one is using the context you're destroying, no? If you destroy it. whenever the thing that's using it tries to reset the compartment back to null will crash because the object is dead, I'd

Re: [JS-internals] Public API:: JS_IsRegExpObject

On 2/14/15 11:06 PM, obastemur wrote: On Friday, February 13, 2015 at 5:06:31 PM UTC+1, Boris Zbarsky wrote: Note that this does not do the same thing as obastemur's proposed API. Whether it does what he actually wants is an interesting question, of @bzbarsky, what do you mean ?

Re: [JS-internals] Public API:: JS_IsRegExpObject

On 2/13/15 10:16 AM, Tom Schuster wrote: Or just use JS_ObjectIsRegExp :) Note that this does not do the same thing as obastemur's proposed API. Whether it does what he actually wants is an interesting question, of course. -Boris ___ dev-tech-js-e

Re: [JS-internals] Exploring GC latency limitations to smooth animation

On 12/14/14, 12:15 PM, jwmerr...@gmail.com wrote: How would I find this out myself? Set the "javascript.options.mem.log" preference to true in about:config and then look at Tools > Web Developer > Browser Console (at least on Mac; not sure where the devtools are in the menu structure on Windo

Re: [JS-internals] Firefox's JS throttling heuristics?

On 12/8/14, 3:18 PM, Chris Peterson wrote: Are Firefox's JS throttling heuristics (e.g. for background tabs) documented somewhere? Is this policy controlled by SpiderMonkey or Gecko? The policy is controlled by Gecko. The throttling policies are as follows: 1) Nested setTimeout/setInterval i

[JS-internals] The rooting guide seems to have some footguns

I was just reading a patch by someone who read https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/GC_Rooting_Guide to figure out how to deal with GCThings. The result was that they had a Heap that they were not tracing. I'm not quite willing to start hacking my own opinions

Re: [JS-internals] 'in' operator is slow?

On 7/30/14, 9:25 AM, Nicholas Nethercote wrote: The following jsperf microbenchmark suggests that |p in o| is much slower than |o.p !== undefined|: http://jsperf.com/in-vs-not-undefined Can someone explain why? First of all, for a jsperf test what really matters is what ion does with the cons

Re: [JS-internals] Shape mysteries

On 7/15/14, 6:36 AM, Boris Zbarsky wrote: That said, I'd think since shape doesn't cover function values events that are the same event type would share the same shape, no? Oh, wait, this is a getter, not a method. So this probably does mean we're giving each Event instance

Re: [JS-internals] Shape mysteries

On 7/15/14, 12:08 AM, Nicholas Nethercote wrote: And there are another 360-odd just like that. Lots of different generated DOM bindings classes that have an isTrusted method, basically. It's a little frustrating that we have so much generated code that is really similar. This case is a bit weir

Re: [JS-internals] Improving JavaScript Performance by Deconstructing the Type System

On 6/20/14, 12:19 AM, Boris Zbarsky wrote: So a few interesting things jump out at me: Oh, and thank you for posting the link, Nicholas! -Boris ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https

Re: [JS-internals] Improving JavaScript Performance by Deconstructing the Type System

On 6/19/14, 8:56 PM, Nicholas Nethercote wrote: It's an analysis of V8, and describes how it is over-specialized for benchmarks vs. real code and how they fixed it. Required reading for some of the people on this list! So a few interesting things jump out at me: 1) The |new function() { ... }

Re: [JS-internals] Standardized assertion methods

On 6/2/14, 7:49 AM, Mike de Boer wrote: all the test suites/ runners we have end up using the same assertion methods. Note that the ones you listed don't match the ones the W3C testharness uses, so all the tests imported from that won't match the other ones... not that they do now anyway.

Re: [JS-internals] Cake (& other beverages)

You plan to _imbibe_ the cake? What sort of cake is this, exactly??? -Boris ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals

Re: [JS-internals] Changes to the Promise ES6 spec

On 2/18/14 10:59 AM, David Bruant wrote: What I meant was "it'd be excellent if Blink and Moz made the test suite more complete" Ah, OK. Yes, that would be a good idea. :) I guess contributing to the Promise/A+ repo works. Assuming they care about the subclassing issues and whatnot. Yes

Re: [JS-internals] Changes to the Promise ES6 spec

On 2/17/14 4:32 PM, Brendan Eich wrote: SpiderMonkey still needs to nativize the DOM/XPCOM-based implementation, both to follow the spec (including subclassability) The DOM can easily support subclassability once SpiderMonkey itself does. The problem is, SpiderMonkey has no subclassing suppor

Re: [JS-internals] Changes to the Promise ES6 spec

On 2/17/14 4:27 PM, David Bruant wrote: That said, it'd be excellent if Blink and Moz completed the current test suite (Promise/A+) Mozilla did, until we just removed cast(). Or at least we passed the test suite at http://domenic.me/aplus-tests-against-the-browser/ sure they implement the

Re: [JS-internals] Why atomize strings in code?

On 2/7/14 4:40 PM, Kannan Vijayan wrote: Not hashing the entire string sounds like a collision attack vector. Are we talking about not using the whole string when computing the hashcode or about not using the whole string for the equality compare on collisions? It sounded to me like Nichola

Re: [JS-internals] JIT Inspector

On 2/6/14 5:34 AM, Nicolas B. Pierron wrote: I do not think we would have much value as dumping the assembly of Baseline, especially ICs might be harder. On the other hand, I think it would be easy to dump ICs chains as part of the PC Count interface. So here are some specific things I've want

[JS-internals] JIT Inspector

JIT Inspector is a pretty awesome tool, but it's bitrotted slightly... In particular: 1) It doesn't seem to know anything about baseline. 2) I've had a hard time making parts of it other than "Ion Activity" work. Is there any interest in updating it to deal with the current state of the worl

Re: [JS-internals] Documenting long-term plans that aren't being directly/actively/specifically worked on

On 2/4/14 11:54 AM, Jason Orendorff wrote: Class::getProperty/setProperty etc. are stupid and we should be trying to kill them off. Yes, totally agreed. If you need that sort of stuff you should be using the proxy API or something similar, since that gets to the heart of shapes being useless

Re: [JS-internals] Documenting long-term plans that aren't being directly/actively/specifically worked on

On 2/4/14 1:37 AM, Chris Peterson wrote: Jeff, regarding proxies and JSClass Note that we're currently sort of moving in the opposite direction: we just gave proxies distinct JSClasses. More importantly, currently "proxy" implies all sorts of behaviors lumped into one, starting with "no sha

Re: [JS-internals] Capturing JS stacks quickly

On 1/17/14 5:26 PM, Jim Blandy wrote: It seemed to me that we could minimize the actual lookups by representing code positions using a type that was quick to construct, and put off doing the lookups until asked. Yes, absolutely! We did something like that on a somewhat smaller scale (still fi

Re: [JS-internals] My Christmas wishlist for the Devtools

On 12/21/13 6:17 AM, David Bruant wrote: I imagine function expression, generator expressions, RegExp literals, JSON.parse, etc. count too? And exceptions being thrown, and DOM methods that allocate, etc, yes. -Boris ___ dev-tech-js-engine-internals

Re: [JS-internals] Reviving a JS specific tree

On 12/12/13 4:30 PM, Jeff Walden wrote: On 12/12/2013 01:09 PM, Jeff Walden wrote: Try working on anything that touches JSAPI or friend API. Or try working on the GC. Or even try the make-generator-frames-store-locals-in-the-heap work. Or try any of the wrappers stuff. Or really XPConnect

Re: [JS-internals] Firefox 28 optimizations for Web Browser Grand Prix benchmarks

On 12/7/13 3:40 AM, Chris Peterson wrote: * Bug 892687 - Make returning object values not require fallible methods I don't think this one matters much for performance here anymore; we've decided that can-fail-due-to-oom-on-return-value is not a reason to avoid DCE of a method call that can ot

Re: [JS-internals] WeakRefs and weak event listeners

On 12/3/13 4:43 AM, Brendan Eich wrote: Andrew McCreight wrote: As far as I understand it, weak references are useful to avoid leaks when you don't know (1) who is referring to you or (2) what your lifetime should be. Yes. Doesn't nsIObserver still need XPCOM weak refs due to the conjunction o

Re: [JS-internals] Weak references

On 11/1/13 3:10 PM, David Bruant wrote: Why so? function f(e){} (function(){ var iframe = document.getElementByTagName('iframe')[0]; iframe.addEventListener('someEvent', f); })() This is very fragile. It assumes that nowhere up the scopes that f is closing o

Re: [JS-internals] Feedback on SpiderMonkey roadmap?

On 9/26/13 4:35 PM, Benjamin Peterson wrote: How much is this a JS problem compared to a Gecko one? IIRC, almost everywhere outside of JS just crashes if it can't allocate memory. It depends. Almost everywhere outside JS crashes on failure of _small_ allocations. Large allocations (esp ones w

Re: [JS-internals] Feedback on SpiderMonkey roadmap?

On 9/26/13 4:27 PM, Gregor Wagner wrote: I don't know what the right approach is. Maybe a testing framework or static analysis for proper OOM error propagation but we will see these kinds of problems more often once people start writing apps with higher memory requirements for b2g. Will those

Re: [JS-internals] Revisiting the removal of __noSuchMethod__

On 9/10/13 3:15 PM, Luke Wagner wrote: Is that based on an addons-mxr search? Yes. https://mxr.mozilla.org/addons/search?string=__nosuchmethod__&tree=addons "Too many hits, displaying the first 1000". Some of these are from the addons SDK, but a bunch more are just people using __noSuchMet

Re: [JS-internals] Revisiting the removal of __noSuchMethod__

On 9/10/13 3:40 PM, Luke Wagner wrote: Is the baseline JIT enabled in whatever sandbox/execution-environment these addons using the addon SDK run in? I don't know. But as Kannan says, the JITs still do the __noSuchMethod__ thing in the common case. So, IIRC, old addons built with the addo

Re: [JS-internals] Revisiting the removal of __noSuchMethod__

On 9/10/13 1:39 PM, Brandon Benvie wrote: On 9/10/2013 10:20 AM, Luke Wagner wrote: (mxr shows a few Gecko uses to remove, though.) Specifically, the only two uses outside of tests/debugging In m-c. Addons are a very different story. Lots of __noSuchMethod__ there. -Boris

Re: [JS-internals] What's in a (handle's) name?

On 8/30/13 4:16 PM, Jeff Walden wrote: On 08/26/2013 10:30 AM, Steve Fink wrote: - JS::Handle is indeed ugly. But you can't compare to HandleValue; it'd still be JS::HandleValue. It sounds like people aren't crazy about 'using namespace JS' or 'using JS::Value', so it's probably "JS::Handle vs J

Re: [JS-internals] Conformance testing of "the" JavaScript engine(s?)

On 8/11/13 9:00 AM, David Bruant wrote: And I was wondering if conformance and regression tests were run against all 3-4 engines (since each compilation step may introduce its own bugs) or whether only the combination was tested. This is actually nontrivial to do, I suspect. For example, as I

Re: [JS-internals] Native vs. non-Native objects

On 7/25/13 7:11 AM, Luke Wagner wrote: making js::Class store a BaseProxyHandler* directly (NULL for non-proxies). That's basically my proposal in the earlier "allowing proxy objects to have extra reserved slots" thread, right? Is it really blocked on making typed arrays native? -Boris __

Re: [JS-internals] Allowing proxy objects to have extra reserved slots

On 7/19/13 12:47 AM, Boris Zbarsky wrote: That's OK; neither do I. This is all pretty fuzzy so far... Well, I do understand the overall kinda goal: Having the JS GC manage all page-exposed memory so that there is no need for a cycle collector, explicit trace hooks, etc. Basically, t

Re: [JS-internals] Allowing proxy objects to have extra reserved slots

On 7/19/13 12:33 AM, Bill McCloskey wrote: I don't understand. Why do you need nodes that are not proxies? What would they be instead? Normal objects. Most nodes are normal objects, in fact. Two types of nodes have proxy-like behavior: forms and documents. Those are proxies. We _could_ m

Re: [JS-internals] Allowing proxy objects to have extra reserved slots

On 7/18/13 11:45 PM, Bill McCloskey wrote: Well, these wouldn't be normal properties. There wouldn't be shapes for them or anything. You would still access them using slot numbers that you would have to lay out yourself. So I don't think there would be any issues with different objects having

Re: [JS-internals] Allowing proxy objects to have extra reserved slots

On 7/18/13 5:21 PM, Bill McCloskey wrote: It seems like we could use non-reserved slots on proxies. I think the idea is to try to have objects that are allocated in the JS heap but that are treated as Rust objects from Rust. That means that the actual object layout needs to be the same for a

Re: [JS-internals] Allowing proxy objects to have extra reserved slots

On 7/18/13 4:55 PM, Bill McCloskey wrote: Could you elaborate on the problem a little more? Is Servo creating its own proxy handlers Presumably yes, just like Gecko is right now. Basically one proxy handler per WebIDL interface that has proxy-like behavior. We already have three reserved s

Re: [JS-internals] Allowing proxy objects to have extra reserved slots

On 7/18/13 4:46 PM, Josh Matthews wrote: Does this sounds reasonable? I'd like to put it into practice if there are no objections. One more thing: if different handlers mean different JSClass for proxies, that makes doing TI for proxies that much simpler: TI would just keep track for proto +

Re: [JS-internals] #include and #ifndef wrapper stuff

On 6/14/13 6:11 PM, Bill McCloskey wrote: Finally, are we allowed to use filenames that overlap with filenames elsewhere in gecko? How well do debugger "break filename:lineno" commands handle that? -Boris ___ dev-tech-js-engine-internals mailing list

Re: [JS-internals] #include and #ifndef wrapper stuff

On 6/14/13 8:32 PM, Nicholas Nethercote wrote: ps: just for laughs, I looked at what Gecko does. Consistency does *not* abound, and double and triple underscores are frequent. New additions to Gecko have been using basically what you'd put in the #include string, with '/' and '.' replaced by

Re: [JS-internals] Improvements to compartment handling?

On 12/3/12 11:14 PM, Bobby Holley wrote: The problem happens when people try to find and access said reflection, usually by way of the wrapper cache. The problem comes when one has to work with a JS gcthing of any sort. That includes strings, but yes also objects. A related problem is that

Re: [JS-internals] Improvements to compartment handling?

On 11/21/12 5:18 PM, Mike Shaver wrote: Would it work to sample the compartment checks? That's an interesting idea. As long as the codepaths involved are actually exercised on the web, this would work. At least it would give slightly us better test coverage. I'd be for this if it's not to

Re: [JS-internals] Improvements to compartment handling?

On 11/21/12 2:13 PM, Bobby Holley wrote: 1 - Objects cannot reach cross-compartment objects without going through a cross-compartment wrapper (and thus receiving a security audit from XPConnect). This is empirically false in Gecko. See testcase in your email. This invariant _would_ be true i

Re: [JS-internals] jstypedarray.cpp bustage?

On 8/17/12 1:38 AM, Brendan Eich wrote: LOL, I'm on Snow Leopard still, can you believe it? Sure. I am too. ;) Ok, so how do I force configure to use clang? Most simply, by putting CC=clang CXX=clang++ in your mozconfig. On Snow Leopard, you may want to also install the version of

Re: [JS-internals] jstypedarray.cpp bustage?

On 8/17/12 12:49 AM, Brendan Eich wrote: http://pastebin.mozilla.org/1760856 I'm at $ hg log -r tip changeset: 102564:a79132ac2f05 tag: tip parent: 102530:1ecca798b1fb parent: 102563:773ecacea4f7 user:Ryan VanderMeulen date:Thu Aug 16 20:50:16 2012 -0400 sum

Re: [JS-internals] how does "with" statement impact on js engine optimization?

On 6/25/12 5:43 AM, 李玉北 wrote: according to this is test, why there are so huge impact on the js performance. Because "with" means you can't really do things like http://en.wikipedia.org/wiki/Inline_caching and similar techniques. -Boris ___