Re: [JS-internals] Wrappers

x27;t > cross the JS->wasm boundary at all at the moment. So it's literally zero > effort to deal with this now, I'm more worried about the longer term. > > --lars > > On Mon, Sep 10, 2018 at 3:57 PM, Luke Wagner wrote: > >> You're right that, to correctly

Re: [JS-internals] Wrappers

You're right that, to correctly handle transparent wrappers, wasm would have to do a lot of work to deal with them (they can't simply be unwrapped) and I agree that we don't want to do that. After Jan's work, the only case where normal Web content would see transparent wrappers would be the case w

Re: [JS-internals] Proposal: always use braces for if/for/while statements

+1 for consistency I was wondering about the timing of any big clang-format changes too; makes sense to do this sooner than later if the clang-format changes aren't imminent. On Tue, Sep 4, 2018 at 11:48 AM, Bobby Holley wrote: > +1 > > The one downside of doing this now is that we'll eventuall

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

I don't have an opinion on at-top vs. at-bottom and churn vs. benefits of regularity, but I do really dislike it when fields are mixed with methods. I often like to know I've seen everything so I can feel like I have a handle on the whole state machine of the class and for this purpose I find it us

Re: [JS-internals] Clang-format

Very much agreed on all these points. Also, beyond fixing bugs, crossing components often allows for fundamentally simpler and more efficient designs. (Also, fwiw, 2-space indent seems fine, even preferable, to me.) On Wed, May 11, 2016 at 1:31 PM, Bill McCloskey wrote: > On Wed, May 11, 2016 a

Re: [JS-internals] OOM exceptions

Due to 32-bit + fragmentation, even "modest" allocations of 300mb can regularly fail, so it seems important to allow apps to gracefully handle these situations and put up some UI that informs the user. You can also consider cases where the allocation failure doesn't mean the whole app is dead, jus

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

Jan 5, 2016 at 8:57 PM, Robert O'Callahan wrote: > On Tue, Dec 22, 2015 at 5:11 AM, Luke Wagner wrote: >> >> I think there was also a performance reason: IIUC, the non-zero-cost >> exception handling strategy is baked into the Win32 ABI >> (https://www.microsoft.

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

> 2. In order to detect whether a resource leaks if something throws, you need > to know what conditions are considered as a "leak". It's trivial to know > that for object allocations, but not for logical resources (for example an > OS handle that you received from a C API, which is an integer as

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

> right now!), writing exception safe code is not just a matter of using RAII > and dtors to clean up. Please see for > example. Yes; noone is suggesting there's an automatic conversion; it'd be a lot of careful work. This particular classic EH hazard should be

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

> 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've been gradually migrating to the codebase to this style *anywa

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

I think there was also a performance reason: IIUC, the non-zero-cost exception handling strategy is baked into the Win32 ABI (https://www.microsoft.com/msj/0197/exception/exception.aspx) and thus enabling EH has a runtime cost for frames containing auto objects with destructors (which in modern SM

Re: [JS-internals] ASM.JS compileAndGo

Good news: I think compileAndGo is no longer a problem; I filed bug 1135428 to remove it. (If you're in a hurry, you can delete the "if (!compileAndGo)" test in EstablishPreconditions in AsmJSValidate.cpp.) On Sat, Feb 21, 2015 at 6:52 PM, obastemur wrote: > node.js compiles a script first and

Re: [JS-internals] bad frame pointer values on the stack

> Yes, I think we need to do this. However, in addition, we need to add the > #ifdef back for DEBUG. We have to be able to walk back our stack > completely in debug builds to get good assertion information. That seems reasonable. In fact, this change would actually increase our bug-finding cov

Re: [JS-internals] bad frame pointer values on the stack

On x86, the jits use ebp as a general purpose register (16.6% more gprs!) so corruption is expected if you try to walk the stack using the classic ebp/saved-ebp-linked-list traversal that nsStackWalk.cpp:894 is trying to do. I vaguely recall that, some time ago, we preserved ebp #ifdef MOZ_PROFILI

Re: [JS-internals] Replacing YARR

I don't think a pure (2) approach is our cheapest option. Even with Yarr, it took Chris a whole bunch of work to import and it also took Dave/Dave a long time each time they pulled a new version. It sounds like irregexp would be much worse. Furthermore, having a whole hunk of code you can't j

Re: [JS-internals] new JS module owner

u had this surprising ability to appear in a bug out of nowhere :) back in the day. I assume that following all activity in the JS component these days would be prohibitively time consuming, but maybe I'm wrong. - Original Message ----- > Luke Wagner wrote: > > So what doe

[JS-internals] new JS module owner

JS engine hackers, I'd like to make Jason Orendorff the new JS engine module owner. My reasoning: Since creating the js/jit submodule and making Jan the owner, I've been thinking about the new meaning of the role of js module owner. Since pretty much everything related to performance has one

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

> > 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. Oh, I missed that, I was assuming we just never called it from the JIT c

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

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

Is that based on an addons-mxr search? - Original Message - > 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

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

Ah, good! IIRC, telling get-prop apart from call-prop was previously the major issue with the proxy-based approach. We've been steadily removing non-standard features from SM esp. when there is a standardized alternative, so I'm in favor of removal. The fact that no one has complained that ou

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

That is a lot faster. I assume beautification happens on the whole file at once (hopefully in a WebWorker :)? For a concrete basis, I timed zimbra_combined.js (in parsemark) and it took 1x with the native Reflect.parse, so the 7x factor would definitely be noticeable. This is a pretty strong

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

but I suspect we'd have a much easier time with a parse tree. Having a more concrete idea of what you might want to desugar in the parser, do you think this would work? - Original Message - > On Fri 06 Sep 2013 18:32, Luke Wagner writes: > > > This brings up a related

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

This brings up a related question: what is the proposed future of the builtin Reflect.parse now that we have pure-JS alternatives like Esprima? On the 'keep' side, I've found jsreflect to be simple, well-written, and easy to maintain. Also, there seem to be a existing uses of Reflect.parse from

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

> Oh, wait, not quite. What's the policy on Rooted and Handle types within > .cpp files, for one-offs or rarely-used types? We have a number of > these, mostly for Rooted, and it seems weird to use a local typedef when > you're probably only using it to avoid losing type information in the > first

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

I see several aesthetic/ergonomic reasons to prefer using typedefs everywhere, inside and outside the engine: - When we are not in namespace js or JS, I think everyone should be able to agree that JS::Handle is definitely too verbose. (We have this problem in SM headers too.) - It is the gene

Re: [JS-internals] jsid: struct vs int

> > I'm wondering if this whole game is even necessary. Could we use the > > struct version in opt builds as well? The only reason I can think not > > to is if some compilers do not optimize a struct containing a single > > integer as well as they would a naked integer. That's right, in particul

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

> I can offer one new data point. I've been working on jsapi.h include > minimization (bug 908050). That's pushed me into the option 1 camp, > because having to deal with the typedefs complicates things -- i.e. > forward declarations for Handle aren't enough; you have to include > js/RootingAPI.

Re: [JS-internals] new js jit sub-module and owner

Update: based on rampant consensus and no disagreements from m.governance, the module has been created: https://wiki.mozilla.org/Modules/Core#JavaScript_JIT Cheers, Luke - Original Message - > JS engine hackers, > > for the last five years, we've had an exciting sequence of jit compile

Re: [JS-internals] new js jit sub-module and owner

> Small related question: wouldn't it also make sense to rename the dir from > "ion" to "jit" too? ISTR that being the plan in early baseline planning meetings. Perhaps we could do that to inaugurate the new submodule. ___ dev-tech-js-engine-internals

[JS-internals] new js jit sub-module and owner

JS engine hackers, for the last five years, we've had an exciting sequence of jit compilers added, redesigned and removed. With the recent completion of the IonMonkey and Baseline projects, I think we're finally in a position where, although our jit efforts will continue unabated, we'll be bui

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

> >Once we did get to this proxy = non-native state, I think we could simplify > >the world a lot; e.g., removing ObjectOps and making js::Class store a > >BaseProxyHandler* directly (NULL for non-proxies). > > How would removing ObjectOps work? Plenty of native types have custom > versions of so

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

> 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? I'll have to admit I didn't read that thread. I haven't thought through all the details, but 'yes' it does seem possible. __

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

> - The only examples of non-native objects in SM are ObjectProxy, > OuterWindowProxy, FunctionProxy, ArrayBuffer, and the typed arrays > (Int8Array, etc). IIRC, since the dawn of proxies, one of the goals was for "proxy" to eventually be synonymous with "non-native object". The main outlier is

Re: [JS-internals] Tracelogging revived

This is really really cool! One thing that I think would be really informative is how much time is spent in C++ stubs called from the baseline/ion. They happen frequently enough that you probably wouldn't want them to be interleaved on the graph, but maybe the time could be summed and attached

Re: [JS-internals] Clarify and/or improve tree rules regarding performance regressions

Thanks for taking the time to write this up! (I was on PTO for the week so I'm just seeing this now.) It seems like there haven't been too many comments which I'll assume means mostly agreement from the group? > My proposal would be something like: > ---

Re: [JS-internals] Proxy question

Agreed. Hard to think of a name that isn't ambiguous with ObjectProxyClass/FunctionProxyClass. Perhaps ProxySingletonClass? - Original Message - > 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.crea

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

Both proposals sound good to me. As for the issue with _ _ being reserved (I was aware of *leading* _ _ being reserved, but not _ _ anywhere in the name); I guess I'm not too concerned since I've never heard of a problem with our usage. Although 0 files do it already, we could switch to a sing

Re: [JS-internals] [GSoC 2013] Project Ideas

Hi Wei Wu, I'm glad to hear that you are interested. I'd like to comment on #2: > 2. Cache compiled asm.js codes and IR to avoid runtime overhead. > Mozilla proposed asm.js as a low-level, efficient target language for > compilers[4]. Emscripten is the main producer of asm.js codes > currently.

Re: [JS-internals] Long-running compilation steps

There are also a bunch of phases in backend codegen that take a bunch of time. (To wit, IonBuilder doesn't run for OdinMonkey.) From profiling asm.js, phi-removal and register allocation are the expensive phases. Unfortunately, each compilation step has it's own driving loop. I think one nic

Re: [JS-internals] Remaining cruft

I don't know of any reason why it wouldn't just be a (minute) savings of ((# windows - 1) * sizeof(JSContext)). This is no CPG ;) - Original Message - > What's the estimated memory hit of doing this? > > /be > > Luke Wagner wrote: > > - alth

Re: [JS-internals] Remaining cruft

Off the top of my head: - I was under the impression we could redirect all of our remaining uses of jsdtoa.cpp to the new thing dota code we imported from Google (bug 744814). - dependent on the new baseline jit, removal of ScriptAnalysis::analyzeTypes and a lot of related machinery (bug 8046

[JS-internals] one more Handle helper

I forgot the last one: we can now implicitly construct a Handle from the new NullPtr type: HandleObject h = NullPtr(); void foo(HandleObject g); foo(NullPtr()); ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozil

[JS-internals] new succient Handle helpers

Two small notes: - we can now write "h.isInt32()" for a HandleValue h, instead of "h.get().isInt32()" (via a Handle specialization). - cx->global() now returns a non-null Handle Happy Handling, Luke ___ dev-tech-js-engine-internals mailing list dev-te