[JS-internals] Generator bindings approaches

Ted and I had a fun conversation just now about bindings in generators. Jan, I'd like to know what you think about this. Currently, in generators, all bindings—arguments, locals, etc.—are marked as "aliased". It's slow. Two possible fixes: 1. LOCALS ON GENERATOR Add bytecode instructions fo

[JS-internals] nbp is on bug triage for January et seq

Hi everyone. Nicolas has agreed to take on bug triage for the JS engine components, at least for January, and probably for 6 months or so. I've been on triage duty since October. We're in OK shape. There are no new untriaged bugs in any of the six JS engine components. However, I imagine some stu

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

Thanks, everyone. Since there seems to be as much consensus about this as there ever is, I went ahead and made the change. "For reasonable-sized classes, put all the fields together, at the top, immediately after any necessary typedefs. For unreasonably large classes, do whatever seems best (but

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

On Thu, Sep 28, 2017 at 2:10 AM, Lars Hansen wrote: > I dislike this proposal. (a) A lot of the code I work with already have > fields-at-the-beginning as the predominant pattern in the smaller classes > (jit, wasm) so this would be major churn for no gain. (b) For large > classes this is an an

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

Hi everyone. I'd like to add a style rule: in a struct/class/union, put all the fields (that is, non-static member variables) together, at the end. Maybe this is dumb, but while working with Rust I got used to this. Rust doesn't allow methods to be defined within a struct or enum. And wow is it e

[JS-internals] How JS team members decide what to work on

I have no plans to type in my notes from the JS meeting. If you want them, ping me on IRC. But one thing I want to think about is how we decide what to work on, especially performance work. Today, it's like this: - If you're a volunteer, of course you decide what to pick up—we're just glad you're

[JS-internals] Links from the JS meeting

Miscellaneous links from today's JS meeting: * Ehsan's Big Complaint List: https://docs.google.com/document/d/1SIKIQIH2l0MYa99qDQSJyYs8JRWRyYb0CQV4zCUnLWg/edit This is interesting because Ehsan is clearly coming from such a different direction. (If you have trouble accessing the docume

[JS-internals] JS Team Meeting, Tuesday morning

Hi everyone. I'd like to have a team meeting next Tuesday, 7AM Pacific / 10AM Eastern / 4PM Europe. Things to talk about: - current state of the world - briefly, what we're working on - Quantum Flow, real-world performance measurement We can just do it in my Vidyo room. We'll cut it off at an ho

Re: [JS-internals] Improving Date.parse

On Thu, Jun 9, 2016 at 10:09 PM, Jim Blandy wrote: > The more I think about this, the more I'm coming around to Shaver's > position. The volume of code on the web is such that it's not a bad first > approximation to just think of it as a complete cover of every observable > behavior the APIs exhi

Re: [JS-internals] Rust JSAPI bindings in js/src?

On Tue, May 24, 2016 at 4:37 PM, Nick Fitzgerald wrote: > Following up on this discussion: I just landed bug ​ > 1273917 > ​ on inbound, which adds the SM(pkg) task. The SM(pkg) task bundles > SpiderMonkey sources up as a tarball release, untars it in another > directory, builds the shell, and fi

Re: [JS-internals] componentization and specialization, was Re: Clang-format

On Wed, May 18, 2016 at 5:11 PM, Bill McCloskey wrote: > On Wed, May 18, 2016 at 2:02 PM, Steve Fink wrote: > > The ignorance itself doesn't help, sure. But I still assert that there > are > > benefits to having fewer things in your head, to have your focus wholly > > consumed by a more limited

Re: [JS-internals] Clang-format

On Wed, May 11, 2016 at 1:31 PM, Bill McCloskey wrote: > I'm sorry to be so corny and didactic, but I've been feeling really > strongly about this problem given all the troubles that have arisen between > the platform and front-end teams lately. We all need to stick together and > be one Mozilla.

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

n should be migrated to use that class. Most other setPendingException() callers should be able to live with the engine just grabbing the current stack at that point... -j On Fri, May 6, 2016 at 4:17 PM, Jim Blandy wrote: > On Fri, May 6, 2016 at 8:51 AM, Jason Orendorff > wrote: > &g

Re: [JS-internals] Clang-format

On Fri, May 6, 2016 at 1:07 PM, Jakob Stoklund Olesen wrote: > On May 6, 2016, at 09:59, Jason Orendorff wrote: > > On Fri, May 6, 2016 at 10:43 AM, Jakob Stoklund Olesen < > jole...@mozilla.com> wrote: > >> Unfortunately, the way SpiderMonkey indents case labels is

Re: [JS-internals] Rust JSAPI bindings in js/src?

On Mon, May 9, 2016 at 3:41 PM, Jim Blandy wrote: > Hi, folks. How does the SpiderMonkey team feel about moving the Servo > project's Rust JSAPI bindings from the separate github repo > they're in now into js/src in > Mozilla > Central? > We talked about thi

Re: [JS-internals] Clang-format

On Fri, May 6, 2016 at 10:43 AM, Jakob Stoklund Olesen wrote: > Unfortunately, the way SpiderMonkey indents case labels is too odd for > clang-format. I don’t think it has a configuration flag that can do that > half-indent. Feel free to mass-change it to whatever Gecko does and update the styl

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

On Thu, May 5, 2016 at 12:39 PM, Jim Blandy wrote: > Of course we could store it off to the side, and thereby keep metadata > about non-Error exceptions. That's just not what was implemented. It'd take > some care to ensure that the metadata stayed attached to its exception > value. > I have kin

Re: [JS-internals] OOM exceptions

On Thu, Apr 21, 2016 at 4:00 PM, Bobby Holley wrote: > Note that a while back I added a mechanism where you can easily ban script from ever running again in a compartment - see [1] for a usage example. > > So this should be a trivial (and probably worthwhile) patch. Agreed! Separately from that

Re: [JS-internals] OOM exceptions

I want to understand your beefs before really responding... On Thu, Apr 21, 2016 at 4:05 PM, Shu-yu Guo wrote: > The first is ergonomic. I want phased workloads like parsing + BCE and JIT > compiling to be completely infallible. > What do you mean by "infallible" here? To me it seems like virtu

Re: [JS-internals] OOM exceptions

On Thu, Apr 21, 2016 at 2:23 PM, Nicolas B. Pierron < nicolas.b.pier...@mozilla.com> wrote: > On 04/21/2016 05:16 PM, Jan de Mooij wrote: > >> Is our only option doubling down on these fuzz bugs and adding more >> assertions, or can we do better with static analysis, the type system, >> annotation

Re: [JS-internals] OOM exceptions

> Dealing with OOM everywhere is complicated enough, but I think the >>> exception part makes it even more difficult to get right. >>> >> ...Incidentally, I still think OOM shouldn't be catchable, just as a matter of sane language behavior. It's too likely to re-fail during catch/finally blocks. L

Re: [JS-internals] OOM exceptions

On Thu, Apr 21, 2016 at 1:06 PM, Jason Orendorff wrote: > > Dealing with OOM everywhere is complicated enough, but I think the >> exception part makes it even more difficult to get right. >> > > I don't think it makes it appreciably harder. It does mean that bugs

Re: [JS-internals] OOM exceptions

On Thu, Apr 21, 2016 at 12:16 PM, Jan de Mooij wrote: > OOM fuzzing has been quite effective, but it feels like a game of > whack-a-mole. It also doesn't help us find and fix similar bugs outside > SpiderMonkey. > Agreed. Dealing with OOM everywhere is complicated enough, but I think the > exce

Re: [JS-internals] A finished object bottleneck would be handy

A possible middle ground would be to kep the branch in JSObject::create, but flip the meaning of the flag, so that the super-early callback is opt-in rather than opt-out ("JSCLASS_EARLY_METADATA_CALLBACK_IS_OK" or some such). -j On Thu, Mar 3, 2016 at 5:28 PM, Jim Blandy wrote: > Okay, so the

Re: [JS-internals] C++ Exception Handling

On Mon, Jan 4, 2016 at 1:55 PM, Mike Shaver wrote: > Has there been some innovation in EH since Cargill's spine-chilling > exploration of making a simple container strongly exception safe? I recall > the consensus being that it was quite difficult to actually be strongly > exception safe, but it

Re: [JS-internals] C++ Exception Handling

On Mon, Jan 4, 2016 at 12:08 PM, Luke Wagner wrote: > > I know from experience that it is NOT "extremely difficult" to write > > exception-safe code. It's really pretty simple: use RAII, use destructors > > for cleanup. > > Agreed. Or, as Bjarne used to say "no naked news" :) It feels like > we

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

You have to do this the same way you'd do it in JS: define accessor properties on the prototype object, and use a different function for each one. That way, each function is used to access a single specific property. So you won't need to know which property was requested. You can define accessor p

Re: [JS-internals] C++ Exception Handling

On Mon, Dec 21, 2015 at 10:26 AM, Ehsan Akhgari wrote: > There is also the issue of writing exception safe code, which is extremely > difficult to do, especially when you have piles of code assume there are no > exceptions. Yup. This is what I was referring to in my original post ("huge investm

Re: [JS-internals] C++ Exception Handling

I took the survey. I would be happy to use C++ exceptions in SpiderMonkey. The primary reason we don't is historical. Converting a large, existing codebase to use exceptions is a huge investment of time. (It also involves touching the build system.) -j On Fri, Dec 18, 2015 at 7:28 AM, Rodrig

Re: [JS-internals] Reminder: do not use JS_STATIC_ASSERT, use static_assert(cond, "reason") instead

On Fri, Jun 12, 2015 at 6:47 PM, Jeff Walden wrote: > SpiderMonkey has a JS_STATIC_ASSERT macro only because it's historically > had one. > That doesn't seem like a very good reason. Instead of advertising, wouldn't you be better off deleting the macro? You can set the reason-string to either "

Re: [JS-internals] JS_InitStandardClasses for non-global objects?

One way is to change the class and make it global. This is just a matter of setting some flags in the JSClass. But each global object lives in an isolated compartment, and values must be "wrapped" when they are transferred between compartments. This can be tricky to accomplish if you have a lot of

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

On Thu, Jun 4, 2015 at 9:50 AM, Jason Hill wrote: > '-std=gnu++0x', '-pthread', '-fvisibility=hidden', > '-fno-stack-protector', '-fomit-frame-pointer', '-fno-common', > '-fno-math-errno', '-fPIC', > '-Wno-mismatched-tags', '-Wno-missing-field-initializers', > '-Wno-unused-private-field', '-Wno-i

Re: [JS-internals] JS scope behavior difference

It's not a bug, but it's a known ...situation. Function statements inside blocks are not a standard feature. They've had different behavior in different JS engines basically forever, and the last time we tried to change the behavior we gave up because it broke web sites. If you tried that in stri

[JS-internals] ES6 series on hacks.mozilla.org

Hi, everyone. ES6 will be ratified by ECMA this summer. The spec is already at Release Candidate 2. So hacks.mozilla.org is planning a series of weekly posts on ES6 features. We'll have something to talk about every week for months. The only thing is, someone has to write the content. Please tak

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

On Wed, Feb 25, 2015 at 4:11 PM, obastemur wrote: > I'm trying a hack to see if I can remove my extension from SpiderMonkey's > core but not much hope so far. Am I missing something or there is no way to > turn a normal object into ArrayBuffer DataView ? or at least give it's > indexed access fea

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

On Tue, Feb 24, 2015 at 2:41 PM, Boris Zbarsky wrote: > Or if you want this to be completely invisible to everyone, use a weakmap > keyed on argument 0? > This is the way to go, if I understand the use case correctly. obastemur, in future, it'll be a big help if you can link to the API you're t

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

On Fri, Feb 13, 2015 at 9:16 AM, Tom Schuster wrote: > Or just use JS_ObjectIsRegExp :) > LOL -j ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-interna

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

All right. If you'll take the time to file a bug and attach the patch, I'll get it checked in. 1. File a bug * Get an account on bugzilla.mozilla.org * Click File a Bug, then under "Components" click Core * Set the Component to "JavaScript engine" * Fill in the Summary and

Re: [JS-internals] Updating JSClass of an Object?

On Tue, Feb 10, 2015 at 10:27 AM, Jason Hill wrote: > 1 - Is it possible to update an object properties created on the JS land ? > What I need to do is that setting private data / data slot into any Object > created on the JS land. > It is possible to store per-object information (in a WeakMap),

Re: [JS-internals] Optimization tracking API landed

Could this be exposed to the shell, and used in tests to assert that a particular optimization is applied in a particular situation? -j On Thu, Feb 5, 2015 at 6:20 PM, Shu-yu Guo wrote: > Greetings, fellow subtrahend incrementers! > > I recently landed bug 1030389 to track the high-level optimi

Re: [JS-internals] Helper Threads.. What could be wrong?

On Wed, Jan 14, 2015 at 3:39 PM, Jason Hill wrote: > The one from Gecko340. I don't know the exact corresponding SM version? > Any clearance here would be also really nice. > SM versions correspond with Gecko/Firefox versions. > I've sorted out by creating the thread using 'PR_CreateThread' .

Re: [JS-internals] Helper Threads.. What could be wrong?

1. No. SpiderMonkey creates several threads for its own internal use, mainly just to take advantage of multiple CPUs to go faster in certain situations. When the threads are working, they're speeding something up (if you have >1 core); when they're idle, they aren't hurting anything. 2. I'm not su

Re: [JS-internals] Gecko340xxx SpiderMonkey JIT only?

On 12/10/2014 03:29 PM, Jason Hill wrote: That sounds nice though. One another big change looks like there is no String to Value conversion anymore. I'd use to keep jsval references for everything since it was easy to switch into other types. Any details on this highly appreciated. `JS::Valu

Re: [JS-internals] Working on SpiderMonkey

On 11/03/2014 01:23 PM, George Thomas wrote: Hi, I am a student who is doing my Masters right now and wanted to be part of SpiderMonkey as the concept of java-script compiler exits me. I have worked on c++ code base in the past in GNASH project and also have debugged GCC a bit in the past. Is

Re: [JS-internals] Facebook Open Academy projects from SpiderMonkey?

On Wed, 2014-09-17 at 17:28 -0700, Mike Shaver wrote: > My experience looking for similar things for Seneca would recommend: > > - relatively isolated subsystem: they should have to internalize less than > 1KLOC > - multiple meaningful milestones > - good existing test coverage > - few/no spec loo

[JS-internals] Cake meetup

You are invited. What: 25 Minutes Of Cake And JavaScript (bring your own cake) A totally optional vidyo chat for random SM talk, show & tell, brainstorming, etc. When: 2nd and 4th Thursday of each month, including today, 10AM Mountain View Time. Where: my r

Re: [JS-internals] Potential Parser API bug

(cc-ing dev.tech.js-engine.internals) On 07/10/2014 05:07 PM, Marcell Vazquez-Chanlatte wrote: Hey, I was told you were someone who might care if there is a bug in the Parser API wiki or the parser. Specifically, for the LetStatement in the parser api (https://developer.mozilla.org/en-US/docs

[JS-internals] Cake JS Hangout today!

You are invited. What: 25 Minutes of Cake and JavaScript (bring your own cake) Optional vidyo chat for random SM talk, show & tell, brainstorming, etc. When: 2nd and 4th Thursday of each month, including today, 10AM Mountain View Time. Where: my room

Re: [JS-internals] Dynamic analysis meeting w/ devtools

On 07/01/2014 01:11 PM, Till Schneidereit wrote: Isn't this exactly what tracelogging does? Or, a subset of what tracelogging does, rather? Similar. I had the impression trace-logging data was more like IONFLAGS spew: mainly of interest to people working on the JITs. But if that data would

[JS-internals] Dynamic analysis meeting w/ devtools

Last Thursday, Nicolas (nbp) and I met with Nick Fitzgerald (fitzgen), Panos Astithas (past), and Jim Blandy (jimb) of the devtools team. Nick's our biggest fan on this effort and he'll be eagerly looking into whatever we build. The immediate targets will *not* be advanced dynamic analyses. The d

[JS-internals] Cake hangout today (at 11:00 PDT this time)

What: 25 Minutes of Cake and JavaScript (bring your own cake) A totally optional vidyo chat for random SM talk, show & tell, brainstorming, etc. When: 2nd and 4th Thursday of each month, including today, 11AM Mountain View Time. **This is not

[JS-internals] Cake JS hangout today!

What: 25 Minutes of Cake and JavaScript (bring your own cake) A totally optional vidyo chat for random SM talk, show & tell, brainstorming, etc. When: 2nd and 4th Thursday of each month, including today, 10AM Mountain View Time. Where: my room on v.mo

Re: [JS-internals] SpiderMonkey status report for Firefox 30–32

On 05/28/2014 07:16 PM, Chris Peterson wrote: Catching up for some overdue status reports from the SpiderMonkey team: Thanks for doing this! FIREFOX 32 highlights (in progress): * ES6 Symbols (bug 645416) may land (already in Chrome 33) I'm aiming for FF33 for this. I want to land it righ

[JS-internals] Cake hangout today!

OK, let's do this again. What: 25 Minutes of Cake and JavaScript (bring your own cake) A totally optional vidyo chat for random SM talk, show & tell, brainstorming, etc. When: 2nd and 4th Thursday of each month, starting today, 10AM Mountain View Time.

[JS-internals] Reminder: "Cake" hangout

"25 minutes of Cake and JavaScript" today at 10AM MV Time. Totally optional. On vidyo, my room. BYO cake. No agenda. BYO something cool to talk about. Here's a link. https://v.mozilla.com/flex.html?roomdirect.html&key=5HY8vvNxNyNd If you DON'T have an account on v.mozilla.com, you can enter yo

[JS-internals] The "Cake" hangout is tomorrow

Hi again. The "Cake" hangout is scheduled for tomorrow, 10AM Mountain View time. Totally optional as always. I'll post details a few hours before it starts. -j ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org h

[JS-internals] Reminder: "Cake" hangout

Hello, "25 minutes of Cake and JavaScript" today at 10AM MV Time. Totally optional. On vidyo, my room. BYO cake. No agenda. BYO something cool to talk about. Here's a link. https://v.mozilla.com/flex.html?roomdirect.html&key=5HY8vvNxNyNd If you DON'T have an account on v.mozilla.com, you can e

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

On 4/8/14, 10:36 AM, Boris Zbarsky wrote: > You plan to _imbibe_ the cake? What sort of cake is this, exactly??? It’s the open source kind of cake. Infinitely customizable, but if you don’t make it, and nobody else makes it, it doesn’t happen. The SM team is neutral to your cake preferences as lo

Re: [JS-internals] Cake

You are invited. What: 25 Minutes Of Cake And JavaScript (bring your own cake) A totally optional vidyo chat for random SM talk, show & tell, brainstorming, etc. When: 2nd and 4th Friday of each month, starting this Friday, 10AM Mountain View Time. Where: m

[JS-internals] OOM status

I'm working on OOM bugs in bug 988953 and descendents. Several of those are hidden out of paranoia. Let me know if you'd like a Cc. Please review the OOM rules: - If OOM happens, make sure js_ReportOutOfMemory(cx) is called. The only exceptions I know of are: - You don't have a cx.

Re: [JS-internals] Weird Header File jsinferinlines.h

On 4/6/14, 4:42 AM, Masquerade wrote: > I am hacking the Spidermonkey source code and have discovered that the > jsinferinlines.h got a bunch of #include BEFORE the #ifndef include guard. > Is that what you guys really want? By the way, jsinferinlines.h actually > includes itself in a cyclic mann

Re: [JS-internals] Pwn2Own 2014

On 3/11/14, 3:49 AM, Jan de Mooij wrote: > I'd be happy to help. European time zone, weekends are harder but I can > check my mail every now and then. I'll help out too. -j ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists

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

On 2/27/14, 5:02 AM, Brendan Eich wrote: > Fitzgerald, Nick wrote: >> Or in self hosted code, right? Maybe the iterator { value, done } >> objects? > > Are we optimizing away { value, done } objects that can't escape (from > iterators run afresh by for-of loops)? No, except in the relatively rare,

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

On 2/16/14, 11:18 PM, Nicholas Nethercote wrote: > The memory reporting code runs without a |cx|, so in my experimental > code I've just used obj->getClass()->name, and not treated proxies > specially. > > Does this sound reasonable? I think this is the right thing. -j __

Re: [JS-internals] Introducing a new saved stack representation to SpiderMonkey

On 2/12/14 5:25 PM, Jim Blandy wrote: > As hinted at previously, the DevTools group would like to introduce a > new representation of saved (not live) JS stacks to SpiderMonkey. Our > immediate need is to record the stacks at which JS objects are > allocated, for our memory profiling tools, but we'

Re: [JS-internals] MIPS backend

On 2/6/14 12:36 PM, Nicolas B. Pierron wrote: > On 02/06/2014 10:15 AM, Jan de Mooij wrote: >> The problem I see with this is that MIPS is a tier-3 platform afaik >> and we don't have real MIPS hardware to test on. So what do we do when >> we break the MIPS simulator build? > > I do not think we sh

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

On 2/4/14 10:54 AM, Jason Orendorff wrote: > Jeff also makes or hints at some other, separable points. Shorter: Yes, we should be looking to eliminate (a) duplication between Class and ProxyHandler and (b) legacy Class features. -j ___ dev-tech

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

On 2/4/14 9:02 AM, Boris Zbarsky wrote: > 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. Yeah, that’s the right direction. I won’t duplicate Boris’s r

Re: [JS-internals] JSWeakMap

On 12/19/13 3:21 AM, Andreas Schlegel wrote: > Hello Jason, > > for comparing "transparent" proxies I have to change some things for > WeakMap Map and Set. > > I should compare the key from a transparent Proxy with its object, e.g. > for getting the value . > > I found the lookup is in the HashTabl

Re: [JS-internals] JIT-Test: self-test/assertDeepEq.js

On 12/18/13 1:47 AM, Andreas Schlegel wrote: > Because of the debug the asBits method should be the same as > SameValue, is this correct? No, I would leave asBits alone and change SameValue, as you have already done. > I've changed StrictlyEqual which is called by SameValue. I've thought > this

Re: [JS-internals] JIT-Test: self-test/assertDeepEq.js

On 12/17/13 5:51 AM, Andreas Schlegel wrote: > The problem is, that in the HashableValue::operator==() function the > Context cx was given as nullptr to SameValue(): > JS_ASSERT(SameValue(nullptr, value, other.value, &same)); You can just delete that assertion. But you'll also have to look out for

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

On 12/17/13 8:37 AM, Till Schneidereit wrote: > Here's another use case for weak references that I don't think has been > mentioned yet: > > Caching of expensive-to-recreate data. If you actually did this, you would soon want some control over the cache: the ability to retain recently used entries

Re: [JS-internals] Question about the Parser API

On 12/15/13 3:45 AM, Florent FAYOLLE wrote: > I encounter some issues when playing with this API on Scratchpad > (browser mode) and when I pass the /builder/ parameter: > http://pastebin.com/ka7Wq8MM > > [...] Do you know what I do wrong with the API? Or do you know anyone > who could help me about

Re: [JS-internals] JIT-Test: self-test/assertDeepEq.js

On 12/14/13 5:29 AM, Andreas Schlegel wrote: > Hello, > > If I run the test with folowing command: > ../jit-test/jit_test.py ./js self-test -o --write-failure-output > --write-failures /home/fedora/workspace/mozilla/jit-tests > > I've only the following Error code in the log file: > self-test/asse

Re: [JS-internals] JIT-Test: self-test/assertDeepEq.js

On 12/13/13 9:59 AM, Andreas Schlegel wrote: > Hello Jason, > > can you explain me the followin test case of the JIT-Tests: > self-test/assertDeepEq.js: > > // cross-compartment > var g1 = newGlobal(), g2 = newGlobal(); > assertDeepEq(g1, g2); > > This test fails, but I don't know why. (copying th

[JS-internals] OOM rules

Christian Holler recently started fixing OOM bugs for us. He says it's easier than creating reproducible test cases. A happy outcome for everyone! :) But looking over the patches, I'm surprised to see us getting basic OOM handling wrong so often. Take a look, and make sure you know the rules:

Re: [JS-internals] Membranes vs Contracts vs Identity

On 12/6/13 7:00 PM, Sam Tobin-Hochstadt wrote: > On Wed, Dec 4, 2013 at 5:59 PM, Mark Miller wrote: >> Once we have such an open-ended projection-only abstraction, then all these >> questions about equality become interesting and pressing. > I'm unconvinced that this is genuinely a problem that ne

Re: [JS-internals] Transparency of JavaScript Proxies

On 12/5/13 6:10 PM, Brendan Eich wrote: > In general, if Andreas is just hacking patches never to land, for > research purposes, no problem. If the idea is to land changes, though, > I have to say it is extremely unlikely we would take any not on the > Ecma TC39 "Harmony" roadmap. I completely agr

Re: [JS-internals] Transparency of JavaScript Proxies

On 12/3/13 8:10 AM, Andreas Schlegel wrote: > I understand you. If the proxies differ in behavior, they should not be > transparent. But for our case we have multiple proxies representing the same > target, only with different contracts. These contracts should e.g. give > different access rights

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

On 12/2/13 4:27 PM, Bobby Holley wrote: > Moreover, it sounds like revocable proxies can be used by libraries to > achieve the same effects with respect to memory leaks, no? Andrew's response is spot-on, but I still think this is a good point. Revocable proxies are a deterministic feature that we

Re: [JS-internals] Transparency of JavaScript Proxies

On 12/1/13 5:16 AM, schlegel.andr...@gmail.com wrote: > Hello, > > I'm a student at the university of Freiburg. > > I write my master thesis about transparency of JavaScript proxies. > > The topic is, that the proxies are not really transparent, because the > Equal-Operators (== and ===) compare t

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

On 12/2/13 2:18 PM, Jason Orendorff wrote: > However, I've become unconvinced by the data binding use case. Yehuda > Katz and I discussed it, and after some pointed questions, he gave up, [...] The flavor of my pointed questions was like this: Yehuda said that WeakRefs would be a f

[JS-internals] WeakRefs and weak event listeners

Brendan, After talking it through with more people, I don't think weak event listeners are safer than full WeakRefs. So I retract that suggestion. However, I've become unconvinced by the data binding use case. Yehuda Katz and I discussed it, and after some pointed questions, he gave up, saying "i

Re: [JS-internals] SpiderMonkey documentation -- wiki, or in the tree?

On 11/20/13 6:23 AM, Till Schneidereit wrote: > We should do this. Having spent an entire doc sprint on updating the > wiki docs only to see large parts of them go out of date very quickly > after that, I think this is really important. And I agree: if we do a > push where everyone chips in a bit,

Re: [JS-internals] SpiderMonkey documentation -- wiki, or in the tree?

On 11/18/13 12:42 PM, Jeff Walden wrote: > Apparently the build system docs are now maintained in-tree, and they're > translated/mirrored automatically to a website. The system is build-specific > right now, but work is happening to make it whole-tree: > > https://bugzilla.mozilla.org/show_bug.c

Re: [JS-internals] Weak references

On 11/1/13 1:52 PM, David Bruant wrote: > In any case, I've stopped being against weakrefs after a message by > Mark Miller[...] I am now going to try to convince you that you shouldn't have been convinced by this use case. :) > To keep the object granularity across machines, in E, they've created

[JS-internals] Weak references

This proposal is before TC39 for inclusion in the next ECMAScript spec edition following ES6: http://wiki.ecmascript.org/doku.php?id=strawman:weak_references Mozilla GC hackers are opposed, for reasons they can articulate; I'm opposed because I can't stick the nondeterminism and because the tota

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

On 10/24/13 7:01 PM, Jason Orendorff wrote: > Mac-specific detail: When you build the way I do, the resulting js > shell executable expects NSPR libraries in the same directory as > itself (according to otool -L, the executable wants > /usr/lib/libz.1.dylib but @executable_path/libnss

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

On 10/24/13 6:51 PM, Jason Orendorff wrote: > This is one of those rare cases where the documentation actually > contains exactly the useful bits you need: [...] > > All this documentation work is due to Jim Blandy. It is of course exactly the kind of documentation work we didn&#

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

On 10/24/13 5:53 PM, Nicholas Nethercote wrote: > 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 This is one of those rare ca

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

On 10/24/13 5:32 PM, Nicholas Nethercote wrote: > 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 > happe

Re: [JS-internals] Do Not Land: AWFY is not responding.

On 10/15/13 12:40 PM, Nicolas B. Pierron wrote: > AWFY is our last barrier to prevent regressions. Currently, all > slaves are down! > > Until AWFY is fixed, I suggest that we do not land anything to the JS > Engine unless we provide benchmark results for sunspider and kraken. > V8 still runs on

Re: [JS-internals] Performance impact of Debugger

On 10/14/13 12:03 PM, Jim Blandy wrote: > [...]there's probably no need to separate bytecode instructions that > have no visible side effects from their successors. Filed bug 926528, " JSD2: Reduce the number of positions where a breakpoint can be placed". https://bugzilla.mozilla.org/show_bug.cgi?

Re: [JS-internals] Performance impact of Debugger

On 10/11/13 8:52 PM, Jim Blandy wrote: > Hi! I wrote a simple script to measure the impact of Debugger on > SpiderMonkey's performance. Thanks for the early results. OK, so in short: 1. disabling Ion: 3x slower 2. enabling debugger: 5x slower 3. enabling debugger with an onEnterFrame hook: 14x sl

Re: [JS-internals] how to get page url

On 10/8/13 8:35 PM, johnhypo wrote: As we know,in firefox when we request one url,firefox would call spidermonkey to interpret javascript.Now I want to get the url in function JS_NewExternalString().How can I get it?Is the url stored in the JSContext? You can use this function, declared in js

[JS-internals] Debugging Ion frames

In Toronto, Jim, Jan, and I made some debugger plans. Right now you can’t just create a Debugger object at any time and start debugging whatever’s on the stack. It sucks. Bug 716647 -[jsdbg2] allow Debugger to be enabled with debuggee frames on the stack https://bugzilla.mozilla.org/show_bug

Re: [JS-internals] new JS module owner

On 10/1/13 3:04 PM, Luke Wagner wrote: I watched (still watch) all new bugs on the JS component and CC myself to ones that seem relevant. I will do the same. I also get bugmail for new patches posted and bugs that are fixed, but I don't follow that as closely. I never followed all activ

Re: [JS-internals] new JS module owner

On 10/1/13 1:59 PM, Luke Wagner wrote: JS engine hackers, I'd like to make Jason Orendorff the new JS engine module owner. Thanks, Luke. Based on the above, I can see no reason not to hand over module ownership to Jason. Jason has graciously agreed, so a big 'than

[JS-internals] about:credits

Judging by `hg log js/src`, most of the work on the JS engine is being done by folks who are not listed in about:credits. - To add yourself, see http://www.mozilla.org/credits/faq/ - If you know of a volunteer who should be added, please let me know. -j

Re: [JS-internals] Differences between Parser API and Esprima harmony

Yusuke, thanks for bringing this up. Ariya, I think we should switch to ArrowFunctionExpression, so I filed a bug against Reflect.parse to make that change.[1] The names we use are listed in [2] in case you ever want to check. When you add new node types, please send mail to this list, and I'

  1   2   >