Re: [JS-internals] Status of sharps and toSource

On Mon, Aug 13, 2012 at 10:49 AM, Terrence Cole tc...@mozilla.com wrote: I can't speak for the behavioural side of things, but I think sharpObjectMap can go now. Now that toSource is purely recursive, I think just using RootedObject should be fine. I'll craft a patch and get the fuzzers on

Re: [JS-internals] -Wshadow and decoration of parameters and class data members

Hi again, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=800659 about turning on -Wshadow in SpiderMonkey, and partly implemented it. It doesn't really work with our current naming style, unfortunately, as the comments in the bug explain. Nick

Re: [JS-internals] Tweak to SpiderMonkey's #include rules

On Wed, Apr 24, 2013 at 2:32 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I would modify the SM style guide, but it's currently AWOL due to https://bugzilla.mozilla.org/show_bug.cgi?id=861017 :( That's now been fixed, and on Luke's request, I've combined the C and C++ guidelines

[JS-internals] Fixing used but never defined warnings

Hi, Have you ever struggled with one of GCC's used but never defined warnings? I certainly have, and I've just now worked out a good way to work out what the problem is. Take this example: ../../gc/Barrier.h:489:17: warning: inline function ‘void js::HeapSlot::init(JSRuntime*, JSObject*,

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

Hi, The standardization of our #ifndef wrappers came up in bug 881579. Here are some examples: - jsapi.h: jsapi_h___ - gc/Barrier.h: jsgc_barrier_h___ - vm/Stack.h: Stack_h__ - ion/Ion.h: jsion_ion_h__ Observations: - Omitting the directory is dangerous if we ever have two files with

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

On Fri, Jun 14, 2013 at 5:32 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Sat, Jun 15, 2013 at 10:16 AM, Luke Wagner l...@mozilla.com wrote: Although 0 files do it already, we could switch to a single trailing _. Fine by me! I'll convert them next week. Emanuel submitted some

[JS-internals] YarrCanonicalizeUCS2.cpp

Hi, YarrCanonicalizeUCS2.cpp is autogenerated by YarrCanonicalizeUCS2.js, and yet we have a copy checked into the repository. Furthermore, if you run YarrCanonicalizeUCS2.js the output doesn't match our in-repo version of YarrCanonicalizeUCS2.cpp. Part of that is superficial changes, such as

[JS-internals] Proxy question

Hi, Here's some code from jsproxy.h: inline bool IsObjectProxyClass(const Class *clasp) { return clasp == js::ObjectProxyClass || clasp == js::OuterWindowProxyClass; } inline bool IsFunctionProxyClass(const Class *clasp) { return clasp == js::FunctionProxyClass; } inline bool

Re: [JS-internals] Proxy question

ProxyConstructor That's the one I like best so far. Nick ___ 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] What's in a (handle's) name?

I agree that doing the same thing inside and outside SpiderMonkey is preferable. I slightly favour using typedefs, to minimize keystrokes. For the weird bz case he can use explicit template syntax. Nick ___ dev-tech-js-engine-internals mailing list

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

On Sat, Jun 22, 2013 at 5:24 AM, Brendan Eich bren...@mozilla.com wrote: I think readability can favor typedefs too, though, and tried to say that. Sorry for being unclear about consumers. Readers do not benefit indefinitely (for every occurrence, say hundreds to thousands in a source file)

Re: [JS-internals] Proxy question

On Fri, Jun 21, 2013 at 3:55 AM, brandon.ben...@gmail.com wrote: On Thursday, June 20, 2013 9:53:01 AM UTC-7, Bill McCloskey wrote: It looks like ProxyClass is only used for the Proxy object that we add to the global (i.e., the thing that allows you to do Proxy.create). That object isn't

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

Hi, I started looking at https://bugzilla.mozilla.org/show_bug.cgi?id=896759 which makes me wonder what exactly is a native object? Here's what I've gleaned... - A native object is one that uses the default ObjectOps. - Also, the marking of reserved slots appears to be different for native vs.

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

On Thu, Jul 25, 2013 at 7:11 AM, Luke Wagner l...@mozilla.com wrote: IIRC, since the dawn of proxies, one of the goals was for proxy to eventually be synonymous with non-native object. That's very helpful from a high-level view. Thanks! Once we did get to this proxy = non-native state, I

Re: [JS-internals] Taint analysis in SpiderMonkey

On Fri, Aug 9, 2013 at 2:59 PM, Jim Blandy jbla...@mozilla.com wrote: The taint analysis applies to strings only, and has four parts: * It identifies certain *sources* of strings as tainted: document.URL, input fields, and so on. * The JavaScript engine propagates taint information on

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

On Thu, Aug 22, 2013 at 8:26 PM, Luke Wagner l...@mozilla.com wrote: Just so I understand, was your goal to remove the #include RootingAPI.h from jsapi.h and was the problem you had the inability to forward-declare a typedef, or was there more too it? Not quite. The problem is that some

[JS-internals] Super-slow shell builds?

Hi, My shell builds this morning are crawling. An everything-but-ICU rebuild just took over 4 minutes. Last time I timed it (a couple of weeks ago) it took about 1 minute. Has anybody else noticed this? Nick ___ dev-tech-js-engine-internals mailing

Re: [JS-internals] Super-slow shell builds?

On Mon, Sep 2, 2013 at 5:43 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: My shell builds this morning are crawling. An everything-but-ICU rebuild just took over 4 minutes. Last time I timed it (a couple of weeks ago) it took about 1 minute. Has anybody else noticed

[JS-internals] --enable-threadsafe on by default has broken my shell builds

Hi, I tried to build the JS shell today for the first time in a few days and got this: dist/system_wrappers_js/pratom.h:2:15: fatal error: 'pratom.h' file not found Apparently --enable-threadsafe is now the default. When did that happen? Some warning would have been nice -- I no longer know

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

On Sat, Dec 7, 2013 at 12:40 AM, Chris Peterson cpeter...@mozilla.com wrote: As Nightly 28 winds down, I would like to highlight some of the performance gains we've made on the Tom's Hardware Guide benchmarks (Web Browser Grand Prix aka WBGP). [...] We'll be tracking a number of benchmarks

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

On Thu, Dec 12, 2013 at 9:52 PM, Brendan Eich bren...@mozilla.com wrote: Let's not make yet another repo if we can avoid it. One more data point: I felt that killing off the tracemonkey repo was a good move and made my life easier. Like bz, I work on a decent number of patches that straddle

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

On Fri, Feb 7, 2014 at 6:06 AM, Jan de Mooij jandemo...@gmail.com wrote: Atoms also make string comparisons fast [...] String equality is also easy for the JITs to inline when you have two atoms Ah, yes. Thanks! Nick ___

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

For my own elucidation... If you choose to atomize a char sequence, it incurs costs. 1. Time: you have to check if the char sequence has been previously atomized. In our implementation, this involves a hash table lookup, which includes a hash computation. 2. Time: the GC has to deal with the

[JS-internals] Major non-determinism in the shell

Hi, For a long time I've had Cachegrind set up to run SunSpider in the shell. It's really useful being able to see instruction counts at the level of source code lines when optimizing. I just tried it today for the first time in a while, and I'm getting hugely variable results. For example, I

Re: [JS-internals] Major non-determinism in the shell

/228M, etc. I'm not sure what to make of that. Another data point: timed, native runs of Sunspider only show ~1% variation, as you'd expect. Nick On Sun, Feb 9, 2014 at 3:56 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: Hi, For a long time I've had Cachegrind set up to run SunSpider

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

On Fri, Feb 7, 2014 at 2:52 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: - My suggestion about hashing only the first and last N chars in the sequence is aimed at cost 1. It would reduce the hash computation cost for long strings, at the risk of causing more collisions. I've done

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

On Mon, Feb 10, 2014 at 8:24 AM, Kannan Vijayan kvija...@mozilla.com wrote: The collision rate control is the bad behaviour I'm referring to. If a webapp is written so as to allow a user to generate atoms (not too hard since they get created in a bunch of places, esp. property-access related

Re: [JS-internals] Better memory reporting of objects and shapes

On Tue, Feb 18, 2014 at 1:57 AM, Nicolas B. Pierron nicolas.b.pier...@mozilla.com wrote: I think it might make sense to special case the JSFunction class, such as we can get the object prototype name in addition to the JSFunction class. Interesting idea. What's the exact code for getting the

Re: [JS-internals] Better memory reporting of objects and shapes

One strange thing I've found: for a small fraction of the objects that have Function as their classname, isJSFunction() is false. Any ideas why this might be? Nick ___ dev-tech-js-engine-internals mailing list

Re: [JS-internals] Getting the allocation point of every object

On Wed, Feb 26, 2014 at 2:29 PM, Nicholas Nethercote n.netherc...@gmail.com Suggestions on how to do this properly would be appreciated. The object metadata stuff is probably a better way to proceed here... billm pointed me to http://mxr.mozilla.org/mozilla-central/source/js/src/builtin

Re: [JS-internals] Getting the allocation point of every object

On Wed, Feb 26, 2014 at 2:46 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Wed, Feb 26, 2014 at 2:29 PM, Nicholas Nethercote n.netherc...@gmail.com Suggestions on how to do this properly would be appreciated. The object metadata stuff is probably a better way to proceed here

Re: [JS-internals] Getting the allocation point of every object

I have this working now. In the output I see quite a few lines of the ??? (1) form, i.e. the NonBuiltinScriptFrameIter has zero elements. I'm not sure what this means... allocations triggered from within C++ code rather than JS code? Or in self hosted code, right? Maybe the iterator { value,

[JS-internals] object metadata hook

Hi, I'm trying to use the object metadata hook. I want to record the allocation point (filename + line number) where each object is allocated, in order to dump that info for each object measure by the JS memory reporter. The object metadata hook is odd. I suspect this is because it's not

[JS-internals] Fwd: object metadata hook

On Sun, Mar 2, 2014 at 10:42 PM, Bill McCloskey bill.mccloskey.b...@gmail.com wrote: Could you set the hook in JS_NewGlobalObject? That's where I originally had it, and I moved it to slightly later because I thought it might help. Not sure if it did, though. For the crashes, it's probably

Re: [JS-internals] object metadata hook

On Sun, Mar 2, 2014 at 9:32 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I'm trying to use the object metadata hook. fitzgen is actively working on this stuff in bug 961288 and 972045 and some others. So I'll leave it to him, and eagerly try it out when it's ready. Nick

Re: [JS-internals] object metadata hook

On Mon, Mar 3, 2014 at 2:56 PM, Fitzgerald, Nick nfitzger...@mozilla.com wrote: On 3/2/14 9:32 PM, Nicholas Nethercote wrote: The actual allocated object isn't available. This is because the metadata object becomes a part of the Shape, which is used to build the object. The object doesn't

Re: [JS-internals] Getting the allocation point of every object

On Wed, Feb 26, 2014 at 7:29 PM, Till Schneidereit t...@tillschneidereit.net wrote: I have this working now. In the output I see quite a few lines of the ??? (1) form, i.e. the NonBuiltinScriptFrameIter has zero elements. I'm not sure what this means... allocations triggered from within C++

Re: [JS-internals] Cake

On Tue, Apr 8, 2014 at 7:16 PM, Till Schneidereit t...@tillschneidereit.net wrote: One thing, though: it has been widely reported that the cake is a lie, and your very words make me suspect that that might be true. Still, I'll try to keep an open mind and reserve judgment until I see proof one

[JS-internals] Crashy BaseShapes

Hi, In bug 972712 I implemented class-based memory reporting. An example: │ │ │ │ ├───0.69 MB (00.64%) -- compartment([System Principal], resource://gre/modules/addons/XPIProvider.jsm) │ │ │ │ │ ├──0.45 MB (00.42%) -- classes │ │ │ │ │ │ ├──0.21 MB (00.20%) -- class(Function)

Re: [JS-internals] Mentored bugs and good first SpiderMonkey bugs

On Mon, Apr 21, 2014 at 4:27 PM, Benjamin Peterson b...@benjamin-peterson.org wrote: Actually, I think SpiderMonkey is a rather good place to start hacking on at least if you know C++. The codebase is self-contained and has been modernized nicely over the last few years. SM also doesn't take

Re: [JS-internals] Major non-determinism in the shell

On Mon, Feb 10, 2014 at 12:55 AM, Andy Wingo wi...@igalia.com wrote: For a long time I've had Cachegrind set up to run SunSpider in the shell. It's really useful being able to see instruction counts at the level of source code lines when optimizing. I just tried it today for the first time

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

Hi, Interesting paper from PLDI 2014 which was last week: http://iacoma.cs.uiuc.edu/iacoma-papers/pldi14.pdf 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! Nick

Re: [JS-internals] Shape mysteries

On Mon, Jul 14, 2014 at 6:48 PM, Bill McCloskey bill.mccloskey.b...@gmail.com wrote: I don't know about the duplicate length shape, although we do a lot of weird stuff related to that, so it's not too surprising. Maybe it's something related to this?

Re: [JS-internals] Shape mysteries

On Mon, Jul 14, 2014 at 7:52 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: In all three cases ObjectImpl::setFlag() gets called, which calls onto Shape::replaceLastProperty(), which ends up replacing the shape by creating one that's very similar but has a different flag

Re: [JS-internals] Shape mysteries

-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. Nick On Mon, Jul 14, 2014 at 6:08 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: Hi, I'm

[JS-internals] Growing arrays

Hi, Here's some code from pdf.js: function stringToArray(str) { var length = str.length; var array = []; for (var i = 0; i length; ++i) { array[i] = str.charCodeAt(i); } return array; } This kind of code shows up in a number of places in pdf.js. Pretty simple -- filling in an

Re: [JS-internals] Growing arrays

On Wed, Jul 16, 2014 at 11:08 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: Hi, Here's some code from pdf.js: function stringToArray(str) { var length = str.length; var array = []; for (var i = 0; i length; ++i) { array[i] = str.charCodeAt(i); } return array

Re: [JS-internals] Growing arrays

that it allocates min(length, 2048) elements. It's in bug 1040593. On Thu, Jul 17, 2014 at 8:40 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: On a related note: ObjectElements::VALUES_PER_HEADER is 2. Is this because 2 * sizeof(HeapSlot) is 16 bytes, which is equal to sizeof(ObjectElements

Re: [JS-internals] Growing arrays

On Thu, Jul 17, 2014 at 1:14 AM, Katelyn Gadd k...@luminance.org wrote: What happens if you combine 'new Array(length)' + 'array[length - 1] = default value'? That seems like it would produce the optimal behavior in all cases. Thanks for the suggestion! This does work for SpiderMonkey, at

Re: [JS-internals] Adding third-party sources to ion build

On Sat, Jul 19, 2014 at 6:06 PM, Byron Hawkins byron.c.hawk...@gmail.com wrote: Eventually I found that the build is specified by the moz.build file, so I can build with my additional sources now. Correct. The moz.build files are the basis of a custom build system that has a number of

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

Hi, 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? http://stackoverflow.com/questions/13866442/why-is-javascripts-in-operator-consistently-slower-than-strict-member-compari

Re: [JS-internals] An easy way to get the heap memory usage?

On Wed, Feb 18, 2015 at 6:09 PM, obastemur obaste...@gmail.com wrote: Some hours ago, we've released jxcore on github (a nodejs distro with SpiderMonkey) (https://github.com/jxcore/jxcore).. Thanks for this great JavaScript engine though! Showing the heap memory usage from underlying engine

Re: [JS-internals] OOM exceptions

On Fri, Apr 22, 2016 at 3:16 AM, Jan de Mooij wrote: > > I think in 'ancient' SpiderMonkey, we used to deal with OOM by returning > null/false. Other exceptions were reported to the JSContext. > > Then we changed this: ReportOutOfMemory now throws the "out of memory" >

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

On Thu, Apr 28, 2016 at 7:14 PM, Jan de Mooij wrote: > > Having only a few signatures for all of our JIT crashes conflates a lot of > different issues (imagine what would happen if most graphics or DOM crashes > had the same signature). Hopefully bug 1268029 will help a bit

Re: [JS-internals] Clang-format

My first 1 or 2 years at Mozilla I spent entirely working on Spidermonkey. I was happy with it, and I even joked that I never wanted to work on the browser proper because compile times were so long compared the to JS shell. But eventually I branched out and worked on other components, and I'm

Re: [JS-internals] Clang-format

If we do an auto-reformat I strongly recommend doing it in small chunks. Start with a few files at a time, to minimize risk. On Fri, May 13, 2016 at 7:21 PM, Shu-yu Guo wrote: > First, Bill, I'm flattered by your mention, thank you. > > I am in favor of unifying styles with

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

On Tue, May 3, 2016 at 3:26 PM, Julian Seward wrote: > >> Inspired by this, I've been thinking about introducing a "verification >> service". > > Ah, now there's an interesting idea. Ideally you'd want some kind of > low overhead continuous coverage, at least for

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

On Thu, Apr 28, 2016 at 9:36 PM, hv1989 wrote: > > We do have this for IonMonkey in debug builds > - After every pass we call AssertBasicGraphCoherency, AssertGraphCoherency > or AssertExtendedGraphCoherency. > - For every LIR we assert that the result is in the expected type

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

On Thu, May 5, 2016 at 3:14 AM, Jan de Mooij wrote: > > Results are here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1034706#c44 Thank you. Very useful data! Nick ___ dev-tech-js-engine-internals mailing list

Re: [JS-internals] OOM exceptions

On Tue, May 10, 2016 at 9:50 AM, Nick Fitzgerald wrote: > Or, if we don't want to boil too many oceans and have something closer to > our usage of bool and not worry about wrapping types: > > class Result > { > public: > enum class Type : uint32_t > { >

Re: [JS-internals] PSA: Crash reports from crashes in SpiderMonkey now have moz crash reasons

[CC'ing the stability list] Oh, nice! I hadn't even realized that this problem existed. 'moz crash reason' is really helpful when diagnosing crash causes from crash reports, so this is a great improvement. Thank you. Here is a search that shows all crashes submitted in the past 7 days that have

Re: [JS-internals] C++ coding style rule for keeping class fields together

I sometimes want to know the memory layout of a class/struct. Having all the fields together makes that a *lot* easier. Nick On Fri, Sep 29, 2017 at 5:35 AM, Jason Orendorff wrote: > On Thu, Sep 28, 2017 at 2:10 AM, Lars Hansen wrote: > > > I