There are significant constraints that are being imposed on other parts of
the codebase to support this extra architecture branch. From the
perspective of a production spidermonkey build, it often lags behind in
feature support, correctness, and bugfixes. It imposes API requirements on
the masm,
I'm a "yes" on this as well. I really don't care much either way in terms
of personal preference, but the consistency argument works for me as it
does for sfink.
Kannan
On Tue, Sep 4, 2018 at 12:04 PM Steve Fink wrote:
> Heh. I find the bug argument unconvincing. It's true that the
> always-br
It's possible to expose in the profiler UI, although the granularity might
be too high and skew might be an issue. Really this is more of a
telemetry-style metric - we can accumulate counts for how often fallbacks
are hit (or how often we generalize into a polymorphic stub) and report
that as a si
Hi Susruthan,
Your code is not producing an error because it is valid code. Bare braces
represent blocks of code. They don’t always have to have an ‘if’, ‘while’, or
‘for’ statement associated with them. For example:
function foo() {
// some code
{ # block begins here
Should be no problem. Optinfo hangs off of the JitcodeGlobalTable's
IonEntry entries. There are also IonCacheEntry structs that we could
hang optinfo for ICs from. We are already hanging some opt-info off of
the BaselineEntry structs. These are used when we fail to Ion-compile -
so we attac
or ping me on irc.mozilla.org
#jsapi (my nick is djvj). If I'm not around or not responding, you can
also potentially ask jandem, nbp, or h4writer about stuff.
Cheers!
Kannan
On 2014-07-31, 10:35 AM, Kannan Vijayan wrote:
Hi Ting,
Of course, that's fantastic :) I can mentor the
?
Thanks,
Ting
- Original Message -
From: "Kannan Vijayan"
To: dev-tech-js-engine-internals@lists.mozilla.org
Sent: Wednesday, July 30, 2014 9:44:12 PM
Subject: Re: [JS-internals] 'in' operator is slow?
The simple reason is that we don't optimize this case in Ion yet.
Looking
The simple reason is that we don't optimize this case in Ion yet.
Looking at IonBuilder's handling of JSOP_IN, it optimizes the case where
the property being checked for is a dense element and the object is
well-known, but it doesn't optimize property checks.
The "full treatment" of this op w
On 2014-07-17, 4:35 AM, Jan de Mooij wrote:
On Thu, Jul 17, 2014 at 8:34 AM, Nicholas Nethercote
wrote:
Oh wait. It depends on the value of |length|. If it's 2050 or less,
then the right-sized array is allocated immediately. Otherwise, it
allocates 10 elements and then does the doubling thing.
Thanks for linking, Nicholas, that was an interesting read.
With respect to SpiderMonkey, some but not all of the problems they
identify exist.
On the issue of map-explosion due to function proto generation we have a
lesser variant of the problem they describe. TypeObjects in TI are
paramet
Nice! Congrats Terrence :)
Kannan
On 2014-05-13, 2:38 PM, 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 JavaScript Garbage Colle
On 2/7/2014, 4:55 PM, Nicholas Nethercote wrote:
And as I said before, choosing to not atomize based on length is a bad
idea: if 99% of the strings you deal with in a particular place are
atomized, but 1% are not, then you can't use pointer equality.
Forgot to reply to this earlier. I don't th
On 2/7/2014, 4:55 PM, Nicholas Nethercote wrote:
On Fri, Feb 7, 2014 at 1:40 PM, Kannan Vijayan wrote:
Not hashing the entire string sounds like a collision attack vector. Any
app or page coded in such a way as to enable an attacker to create interned
strings would open the browser to a DoS
On 2/7/2014, 4:11 PM, Nicholas Nethercote wrote:
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
String literals are used heavily in run-time reflection, e.g.:
Object.getOwnPropertyDescriptor(obj, 'foo')
typeof(x) === "object")
String literals are also used to represent symbolic values in JS. It's
not uncommon to see things like:
var Days = { Monday:'Monday', Tuesday:'Tuesday', ...
Isn't part of the reason for that the fact that TraceMonkey (and with
Jaeger, Ion, and with Baseline, etc.) wasn't really a JS-specific tree?
They were jit-specific trees, and the jits generally have a lot of
cross-talk with the main JS VM.
I would expect far less overlap between "general bro
I second this. If JS devs push a broken patch, it would be confined to
the JS tree and not block other landings on the main tree. Likewise for
broken m-i blocking JS landings. m-i bustage is becoming a bit of a
bottleneck.
Kannan
On 12/12/2013, 3:08 PM, Brian Hackett wrote:
I think mozill
You're hitting slowpath named property accesses (JSOP_GETELEM style)
which are going through an Ion IC, but which are not getting optimized
stubs added to handle them.
Tracking down the relevant code with the in-browser might be helpful...
The gecko profiler addon should be able to help here.
Sounds like a reasonable move. Congrats Jason :)
Kannan
On 13-10-01 2:59 PM, Luke Wagner wrote:
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
On 13-09-10 6:08 PM, Bobby Holley wrote:
On Tue, Sep 10, 2013 at 2:25 PM, Kannan Vijayan wrote:
I think in addition to those steps, we could also change the semantics of
__noSuchMethod__ such that it only gets called for lookups of non-existant
properties, as opposed to all lookups which
On 13-09-10 4:41 PM, Luke Wagner wrote:
Is the baseline JIT enabled in whatever sandbox/execution-environment these
addons using the addon SDK run in?
I don't know. But as Kannan says, the JITs still do the
__noSuchMethod__ thing in the common case.
Oh, I missed that, I was assuming we just ne
Method__ usecases with proxies. (Or will be, once bug 878605 lands.)
On Tue, Sep 10, 2013 at 5:35 PM, Kannan Vijayan wrote:
I'd like to dredge up this topic and resolve it once and for all. Please
see bug 912303 for why I'm bringing this up now:
https://bugzilla.mo
e in the compartment or
whatever the right unit of isolation is? IIRC we did this for mutated
Array.prototype at one point.
Mike
On Tuesday, September 10, 2013, Kannan Vijayan wrote:
I'd like to dredge up this topic and resolve it once and for all.
Please see bug 912303 for why
I'd like to dredge up this topic and resolve it once and for all. Please
see bug 912303 for why I'm bringing this up now:
https://bugzilla.mozilla.org/show_bug.cgi?id=912303
As it stands, our current JITs (neither Ion nor Baseline, nor Jaeger
before that) do not respect __noSuchMethod__ seman
This makes a lot of sense to me and I think Jan is the right person for
the job. Agreed on both counts.
Kannan
On 13-07-29 8:24 PM, Luke Wagner wrote:
JS engine hackers,
for the last five years, we've had an exciting sequence of jit compilers added,
redesigned and removed. With the recent
On my macbook:
ION + JM:
Richards11180
Deltablue 10916
Crypto 15238
Raytrace7681
EarleyBoyer 13064
Regexp 2022
Splay 11539
NavierStokes22854
pdf.js 6201
Mandreel9316
GB Emulator
26 matches
Mail list logo
