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 dislike this proposal. (a) A lot of the code I wor
There's an easier way. Define JS_USE_CUSTOM_ALLOCATOR and then you can
provide your own definitions of js_malloc et al, which must be in a file
called jscustomallocator.h.
Nick
On Mon, Jan 2, 2017 at 10:17 PM, wrote:
> Hello,
> is it a bad idea to declare js_malloc, js_calloc, js_realloc, js_fr
[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 a
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 Gecko, though I have a
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
glad
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
> {
> Ok,
> Oom,
>
On Sat, Apr 23, 2016 at 9:29 AM, Nicholas Nethercote
wrote:
>
> one thing I've been thinking about is using
> MOZ_WARN_UNUSED_RESULT more.
> It isn't useful for the "return null on failure" case, because the
> result will always be used even if you forget th
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
dev-tech-js-engine-internals@lists.mo
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 m-c/aurora/beta. I'm
> imagining
On Fri, Apr 29, 2016 at 9:34 PM, Julian Seward wrote:
>
> There are still quite some detectable races [1] [2] [3], at least when
> running the browser as a whole (xpcshell tests). I can't tell whether
> they are harmful, but in any case we should IMO have a zero-tolerance
> policy for races like
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 (wrt to TI
> info)
>
On Thu, Apr 28, 2016 at 10:35 PM, Nicolas B. Pierron
wrote:
>
> For the JIT, what would improve our life a lot, would be if we could dump
> the code of the compiled function which is currently being executed. If we
> have that, I think we can make a tool to reverse engineer the trace of
> functio
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 there.
It looks like t
Hi,
Project Uptime (https://wiki.mozilla.org/Platform/Uptime) is underway.
Its goal is to reduce the crash rate of Firefox (desktop and mobile).
And SpiderMonkey accounts for a significant fraction of those crashes.
SM provides some particular challenges, in particular the JITs and the GC.
First
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"
> string. This allowed scripts
On Fri, Mar 27, 2015 at 10:25 AM, Robert O'Callahan
wrote:
>
> Switching method names to start with a capital letter would be helpful too
> ... especially where it's leaked into MFBT.
FWIW, here is the contents of mfbt/STYLE:
> MFBT uses standard Mozilla style, with the following exceptions.
>
>
On Wed, Feb 18, 2015 at 6:09 PM, obastemur 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 is one of the
On Mon, Dec 15, 2014 at 4:15 AM, wrote:
>
>> Any idea why Elm is so super garbage heavy?
>> Sounds like it needs some optimizations.
>
> I don't know how to quantify "super garbage heavy" yet. If you work really
> really hard, you can avoid per-frame allocation completely. But Elm
> definitely
Hi,
TL;DR: I wrote a crude yet useful JS memory profiler. I told jimb
about it at the work week and am posting the details here in case it's
of interest to anyone.
Earlier this year I made some large memory usage improvements to
pdf.js
(https://blog.mozilla.org/nnethercote/2014/06/16/an-even-sli
, Apr 17, 2014 at 9:32 AM, Nicholas Nethercote
wrote:
> 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)
> │ │ │ │
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
discusse
On Sat, Jul 19, 2014 at 6:06 PM, Byron Hawkins
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 improvements over Makefiles, but
On Thu, Jul 17, 2014 at 1:14 AM, Katelyn Gadd wrote:
> What happens if you combine 'new Array(length)' + 'array[length - 1] =
> '? That seems like it would produce the optimal
> behavior in all cases.
Thanks for the suggestion! This does work for SpiderMonkey, at least
in some case, but it might
atch so that it allocates min(length, 2048)
elements. It's in bug 1040593.
> On Thu, Jul 17, 2014 at 8:40 AM, Nicholas Nethercote
> wrote:
>> On a related note: ObjectElements::VALUES_PER_HEADER is 2. Is this
>> because 2 * sizeof(HeapSlot) is 16 bytes, which is equal to
&
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)?
Nick
On Wed, Jul 16, 2014 at 11:34 PM, Nicholas Nethercote
wrote:
> On Wed, Jul 16, 2014 at 11:08 PM, Nicholas Nethercote
> wrote:
On Wed, Jul 16, 2014 at 11:08 PM, Nicholas Nethercote
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);
&
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 arr
nkids=0
id "isTrusted" g/s 0x7f0686031240/(nil) slot -1 attrs 55 (enumerate
permanent getter shared) flags 0 nkids=0
...
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 frustratin
On Mon, Jul 14, 2014 at 7:52 PM, Nicholas Nethercote
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.
On Mon, Jul 14, 2014 at 6:48 PM, Bill McCloskey
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?
> http://mxr.mozilla.org/mozilla-central/source/js/src/jsarray.cpp#67
On Mon, Jul 14, 2014 at 6:48 PM, Bill McCloskey
wrote:
>
> For the Function stuff, it sounds like maybe those are the shapes for
> stuff like Array.join, Array.reverse, ... (as opposed to
> Array.prototype.join, Array.prototype.reverse, ...). Array is just a
> function after all.
Aha! I didn't kn
Hi,
I'm looking closely at shapes and property trees. I've been using the
dump() and dumpSubtree() methods, among other things, and I'm seeing
some strange things.
Here's some reasonable-looking output:
class Array emptyShape
id "length" g/s 0x7f06ae61fb10/0x7f06ae61fbf0 slot -1 attrs 44
(perma
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
__
On Tue, Jun 10, 2014 at 4:09 AM, wrote:
>
> - The about:config option javascript.options.ion.parallel_compilation gets
> renamed to javascript.options.ion.parallel_compilation
I suspect the latter should be javascript.options.ion.offthread_compilation?
Nick
On Mon, Feb 10, 2014 at 12:55 AM, Andy Wingo 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 in a wh
Great news! Well done, Terrence.
Nick
On Tue, May 13, 2014 at 11:38 AM, Naveed Ihsanullah
wrote:
> Hello Team,
>
> Please join me in congratulating Terrence Cole in his new role as a
> Supervisor on the JavaScript team. Terrence joined Mozilla back in September
> of 2011. He was focused on Jav
On Mon, Apr 21, 2014 at 4:27 PM, Benjamin Peterson
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 forever
> to build, and
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)
On Tue, Apr 8, 2014 at 7:16 PM, Till Schneidereit
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 way or the
> other.
On Wed, Feb 26, 2014 at 7:29 PM, Till Schneidereit
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++
>> >> cod
On Mon, Mar 3, 2014 at 2:56 PM, Fitzgerald, Nick
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
On Sun, Mar 2, 2014 at 9:32 PM, Nicholas Nethercote
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 i
On Sun, Mar 2, 2014 at 10:42 PM, Bill McCloskey
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 best to start by figuring out
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 actually
>> 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
On Wed, Feb 26, 2014 at 2:46 PM, Nicholas Nethercote
wrote:
> On Wed, Feb 26, 2014 at 2:29 PM, Nicholas Nethercote
>>
>> Suggestions on how to do this properly would be appreciated. The
>> object metadata stuff is probably a better way to proceed here...
>
>
On Wed, Feb 26, 2014 at 2:29 PM, Nicholas Nethercote
>
> 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/TestingFunctions
Hi,
I'm doing some profiling of pdf.js, and I would like to get the
allocation point for every object, either when it's allocated, and/or
when the JS memory reporter runs. This is for some ad hoc profiling --
I just want to dump the info to stderr so I can post-process it -- so
it doesn't need to
On Sat, Feb 22, 2014 at 1:47 PM, Chris Peterson wrote:
>
> The discussion ended with Luke suggesting:
>
> - fork irregexp
>
> - significantly refactor the code to use SM rooting, assembler, Vector,
> LifoAlloc, etc APIs
> - declare open season on stylistic refactorings to make irregexp match SM
One strange thing I've found: for a small fraction of the objects that
have "Function" as their classname, is() is false. Any
ideas why this might be?
Nick
___
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https
On Tue, Feb 18, 2014 at 1:57 AM, Nicolas B. Pierron
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 object
prototype name from a
Hi,
Currently, about:memory shows data for objects separately from shapes,
and there are fixed buckets, like so:
├──125.51 MB (53.64%) -- compartments
│ ├───65.20 MB (27.86%) -- objects
│ │ ├──48.80 MB (20.86%) -- gc-heap
│ │ │ ├──18.45 MB (07.88%) ── function
│ │ │ ├──15.98 MB (06.83
On Thu, Feb 13, 2014 at 4:11 PM, Nicholas Nethercote
wrote:
> We're even close to having warnings-as-errors shell builds on TBPL on
> any platform, are we? My local builds certainly don't think so.
Dammit, that should be "We're
We're even close to having warnings-as-errors shell builds on TBPL on
any platform, are we? My local builds certainly don't think so.
N
On Thu, Feb 13, 2014 at 3:59 PM, Steve Fink wrote:
> On Thu 13 Feb 2014 03:03:23 PM PST, Mike Hommey wrote:
>> On Thu, Feb 13, 2014 at 01:31:55PM -0800, Gary Kw
On Mon, Feb 10, 2014 at 8:24 AM, Kannan Vijayan 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
> operations), the
On Fri, Feb 7, 2014 at 2:52 PM, Nicholas Nethercote
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 d
On Sun, Feb 9, 2014 at 4:45 PM, Nicholas Nethercote
wrote:
>
> One interest data point: my Cachegrind script does two runs for each
> Sunspider test, so I can compare two different shells. If I tell it to
> run the same shell both times, the before/after results are always the
>
118M, then 228M/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
wrote:
> Hi,
>
> For a long time I've had Cachegrind set u
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 ran
On Fri, Feb 7, 2014 at 2:52 PM, Nicholas Nethercote
wrote:
>
> 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,
> whi
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 ato
On Fri, Feb 7, 2014 at 1:40 PM, Kannan Vijayan wrote:
>>
>> However, it's not the only cost -- there's also the hashing (time)
>> cost. For very long strings this cost is high. I wonder if we should
>> change AtomHasher to look at only the first N and last N chars in the
>> string when computing t
On Fri, Feb 7, 2014 at 8:31 AM, Kannan Vijayan wrote:
>
> Atomizing string literals is definitely a good idea, although it might make
> sense to put a length limit - say 32 or 64 chars (do we already do this,
> maybe?).
We don't. If there were some places where we might atomize and might
not, the
On Fri, Feb 7, 2014 at 6:06 AM, Jan de Mooij 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
___
dev-tech-js-engine-internals mailing list
Hi,
During tokenization, we atomize identifiers. This makes sense to me,
because identifiers are almost certain to appear multiple times.
But we also atomize string literals. These are much less likely to
appear multiple times. Is it necessary?
A more general question: what exactly is atomizatio
On Tue, Jan 21, 2014 at 8:19 PM, Bill McCloskey
wrote:
> We do have static atoms for all those strings, but we don't atomize on every
> path that creates a string. If you can find the path where these strings are
> created, we might be able to atomize there.
I think they're coming from js_NewScri
Hi,
I got some puzzling about:memory measurements for a zone belonging to
a pdf.js window. Full details are below, but here's an illustrative
example:
│ │ │ │ │ └───6.74 MB (01.79%) -- string(length=1, copies=176787, ".")
│ │ │ │ │ ├──5.40 MB (01.43%) ── gc-heap
│ │ │ │ │
On Mon, Jan 20, 2014 at 1:03 PM, hv1989 wrote:
>
> Just that measuring an empty loop is kinda pointless.
For anyone with a twitter account: "Microbenchmarks suck!" easily fits
into 140 chars.
N
___
dev-tech-js-engine-internals mailing list
dev-tech-js-
On Thu, Dec 12, 2013 at 9:52 PM, Brendan Eich 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 JS-land and non-JS-
On Sat, Dec 7, 2013 at 12:40 AM, Chris Peterson 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 weekly and you can
On Wed, Nov 27, 2013 at 12:24 AM, Varadarajan S wrote:
>
> Dear All,
>
> To have a simple tool for Firefox browsers which can give us the leaking
> objects and its corresponding file name and line number, I referred to Bug
> 722749 and changed the files in the Mozilla-central repository ( locall
On Mon, Nov 4, 2013 at 12:19 AM, Brendan Eich wrote:
> How about bisecting, if the symptom is observable in a few minutes of
> running a nightly?
It's not that reliable, unfortunately. I'll try profiling, as Kannan suggest.
Nick
___
dev-tech-js-engine
Hi,
Recently my trunk builds have been sluggish at times. It varies a
lot, but some days I have lots of pauses. It seems to happen when I
have lots of bugzilla tabs open, though I'm not certain that's a
factor. I also use Chatzilla, which may be a factor.
A number of the times it's happened I'
Hi,
I had the with-NSPR builds working recently, but today I'm getting a
linking error:
/usr/bin/ld.bfd.real: cannot find
/home/njn/moz/mc/co64/dist/include/nspr: File format not recognised
/home/njn/moz/mc/co64/dist/include/nspr is present and is a directory
containing the NSPR header files,
On Thu, Oct 24, 2013 at 5:36 PM, Jason Orendorff wrote:
>
> Everyone please at least consider fixing up your dev environment to
> build with NSPR.
Where are the instructions?
Nick
___
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-interna
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
Hi,
I want to add a precise memory reporting test. One that uses the
JSAPI to build some objects and strings whose exact size is knowable,
so that I can check that the reported sizes match. (We don't have
anything like that currently.)
The obvious way to do this is via a jsapi-test, but there's
On Thu, Sep 26, 2013 at 1:27 PM, Gregor Wagner wrote:
> I don't know if the roadmap is the right place for this but I would also love
> to see
> some effort dealing with OOM situations.
>
> I don't know what the right approach is. Maybe a testing framework or static
> analysis for
> proper OOM e
On Mon, Sep 2, 2013 at 5:43 PM, Nicholas Nethercote
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 this?
Thi
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 l
On Sat, Aug 24, 2013 at 2:32 AM, Luke Wagner wrote:
>
> - The you-can't-forward-declare-typedefs problem. I think we can address
> this as Brendan pointed out by forward declaring Handle and putting the
> HandleX typedefs in jspubtd.h (perhaps with a comment above saying "See
> js/public/Rooti
Hi,
|jsid| is a struct in debug builds and an integral type in opt builds.
From jspubtd.h:
/*
* In release builds, jsid is defined to be an integral type. This
* prevents many bugs from being caught at compile time. E.g.:
*
* jsid id = ...
* if (id) // error
*...
*
* s
On Thu, Aug 22, 2013 at 8:26 PM, Luke Wagner 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 code outside
On Thu, Jun 20, 2013 at 7:21 AM, Till Schneidereit
wrote:
>
> We still don't have a clear line on how to name handles, both in- and
> outside of the engine.
>
> Options:
> 1. don't use any typedefs at all, so always use (js:: and JS::)Handle
> 2. change the template to the form Handle, roughly mat
On Mon, Aug 19, 2013 at 11:00 AM, Nicolas B. Pierron
wrote:
>
> So having hooks on the string allocation sounds like a terrible idea.
A couple of highly predictable branches? Maybe. Fortunately it
should be easy to measure.
Jim and Nicolas clearly have different ideas about the right way
forwa
On Fri, Aug 9, 2013 at 2:59 PM, Jim Blandy 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 strings.
>
Hi,
I just landed the patch in
https://bugzilla.mozilla.org/show_bug.cgi?id=880088, which added a
|check-style| make target that does some style checks on SpiderMonkey.
The current checks are all related to header files and #includes:
- No cyclic dependencies between header files.
- No normal h
On Mon, Jul 29, 2013 at 5:24 PM, Luke Wagner wrote:
>
> Thus, I'd like to propose we create a new 'jit' sub-module [1] of the
> JavaScript module [2] to allow the jit module owner to focus on the above
> goals.
>
> For the new owner of this module I'd like to propose Jan de Mooij.
+1 to both pr
On Thu, Jul 25, 2013 at 7:11 AM, Luke Wagner 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 think we co
On Wed, Jul 24, 2013 at 9:19 PM, Nicholas Nethercote
wrote:
>
> "what exactly is a native object"?
sfink wrote about this in
https://bugzilla.mozilla.org/show_bug.cgi?id=896759#c2. I've quoted
it below.
Nick
In my mind, isNative()'s meaning is a gooey gob of stuff,
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
> 2) There is something strange going on with Splay GGC. We could be much
> faster on it. It seems like we are stuck in baseline on splay.js:49 for a lot
> of time! That function is doing nothing but returning a value, but somehow
> that takes 25% of the execution time (excluding gc). I guess so
On Fri, Jun 21, 2013 at 3:55 AM, 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 actually a proxy a
Hi,
SpiderMonkey has numerous inlines.h/-inl.h files. Please avoid
putting code in these as much as possible. If something needs to be
inlined and it can go in a vanilla .h file, put it there. If it
doesn't need to be inlined, put it in the .cpp file. Only put things
in inlines.h/-inl.h files
On Sat, Jun 22, 2013 at 5:24 AM, Brendan Eich 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) from using exc
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
dev
> 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
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 IsProx
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 the
On Fri, Jun 14, 2013 at 5:32 PM, Nicholas Nethercote
wrote:
> On Sat, Jun 15, 2013 at 10:16 AM, Luke Wagner 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 patches
1 - 100 of 122 matches
Mail list logo
