The library loading stuff is used for ctypes as well, which is used by
Firefox. It was the last difficult piece to remove.
On 6/4/19 1:34 AM, Jan de Mooij wrote:
Oh I forgot about the PR_LoadLibraryWithFlags call in JS shell code. We
should make that optional too...
Jan
On Tue, Jun 4, 2019 at
Heh. I find the bug argument unconvincing. It's true that the
always-brace style is slightly less error-prone, but since this is only
used for very short clauses it seems like a very minor win in practice,
and much less significant to my eye than the benefits in evening out the
code density. I
On 11/16/17 5:42 PM, Steve Fink wrote:
I landed bug 1410528 earlier today, which will make crashes in linux64
spidermonkey jobs produce stack traces (finally!).
For now, this is only for linux64 (not linux32), and not even for the
SM(arm) nor SM(arm64) jobs. It's mostly just a matt
I landed bug 1410528 earlier today, which will make crashes in linux64
spidermonkey jobs produce stack traces (finally!).
For now, this is only for linux64 (not linux32), and not even for the
SM(arm) nor SM(arm64) jobs. It's mostly just a matter of implementation
to support Windows and OSX (I
sampling. I believe the
latter is what you're referring to?
On Wed, Apr 12, 2017 at 9:38 AM, Ehsan Akhgari
mailto:ehsan.akhg...@gmail.com>> wrote:
On 2017-04-12 5:33 AM, Jan de Mooij wrote:
> On Tue, Apr 11, 2017 at 11:25 PM, Steve Fink mailto:sf...@mozilla.com>&g
On 04/11/2017 02:05 PM, Jan de Mooij wrote:
On Tue, Apr 11, 2017 at 9:34 PM, Jason Orendorff
wrote:
- Bigger projects, like Waldo's work on parsing and djvj et al's work on GC
scheduling, are undertaken when we have stuff that has been showing up on
profiles "forever". This kind of work isn't
I just went through and found a bunch of places where we were including
windows.h directly. Which defines macros like min, max, GetProp, and
CONST. I didn't think this really mattered much, but coincidentally I
shortly thereafter encountered code that was doing contortions to work
around it, li
Let me see if I'm understanding this correctly.
The previous setup we had, that was largely considered a disaster, also
had JSContexts on different threads. The big difference here is that the
zone groups do not need to share data for the most part. So we don't
need the fine-grained locking li
On 01/26/2017 12:40 AM, Ms2ger wrote:
On 25/01/17 20:32, Shu-yu Guo wrote:
But, like, I'm pretty sure GH's SLA is better our own...
As someone who needs Github to do his job: it's definitely worse. (Also,
we're not talking about just Github outages, but the union of Github
outages and our own o
262, and
- Ability to exclude entire subdirectories
They supersede many of our tests and is the general source of compliance
truth for many corner cases. The increased running time is worth it for
correctness when implementing new features. JIT hackers can most likely get
by most of the time wit
On 01/25/2017 03:23 AM, Nicolas B. Pierron wrote:
Thanks for this email, and these investigations.
On 01/25/2017 05:47 AM, Steve Fink wrote:
[what is slower in Fx vs Chrome]>>- eliminate all or most bailouts
I will try to explain more the details here, and hopefully help
anba has done some major work to get test262 runnable as a CI test, and
I've been looking into creating taskcluster jobs for it. One thing that
could use input from a wider audience is how we want it to work with
running jstests manually. The tests replace the js/src/tests/test262
directory, wh
Hello #jsapi.
I wanted to report on some of the JS-centric results of the Google
Suites work week in Taipei, and hopefully get more eyes on these problems.
First, some background: Sean and I met up with about two dozen other
people involved in the Google Suites performance improvement effort.
arate them,
actually; I think of SpiderMonkey as part of Gecko. But it *is* a more
idiosyncratic corner than most, hence the original thread.)
On Wed, May 18, 2016 at 11:14 AM, Steve Fink <mailto:sf...@mozilla.com>> wrote:
On a related note, I think we're also organizationally
Plenty have people have weighed in on the pro-integration side, which I
largely agree with, but I think nbp's motivation is valid and worth
looking into as an indication of real problems that are only going to
get worse if we commit entirely to maximum integration.
On 05/12/2016 05:04 PM, Ehsa
On 05/11/2016 02:42 AM, Ms2ger wrote:
On 11/05/16 08:36, Jim Blandy wrote:
It looks like the lack of any CI of the SM-only distribution is a
non-trivial source of pain. That seems independent of where the Rust JSAPI
bindings live, and indeed, independent of Rust altogether.
The SpiderMonkey eng
On 05/09/2016 04:32 PM, Nicholas Nethercote wrote:
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 forge
On 05/03/2016 11:11 AM, Jakob Stoklund Olesen wrote:
On May 3, 2016, at 10:56, Boris Zbarsky wrote:
On 5/3/16 1:28 PM, Jakob Stoklund Olesen wrote:
It is not assertions that make unoptimized C++ really slow, it is the lack of
inlining which is critical to clean up template abstraction goop.
On 01/05/2016 08:44 AM, Luke Wagner wrote:
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
On 03/28/2015 08:54 PM, obastemur wrote:
Seems like the problem is GC'ed c++ side objects.
Let's say there is a persistent object on the c++ side(AddNamedRoot..)
JS::Heap host; <- AddNamedRoot.. called on this
at some point, I do create an object
X_OBJECT = (JS_NewObject(.))
host->setprop
On 03/27/2015 11:18 AM, obastemur wrote:
I do have a strange case where jsval_layout.asBits == 18445195965632677715 (JS
STRING TAG) this number MOD 8 == 3 hence something is wrong. BTW; no matter
what the number is the same. Seems this problem happens in the same order.
As far as I've tracked
On 02/24/2015 07:10 AM, obastemur wrote:
When an Object is created on the JS land, it doesn't have a private slot. I'm
adding an extra object property on the native side and managing the private
slot for these objects.
Are these your own objects, for which you have or could have your own
JSC
On 02/10/2015 11:11 AM, Erdal Mutlu wrote:
On Tuesday, February 10, 2015 at 6:59:20 PM UTC+2, Steve Fink wrote:
On 02/10/2015 01:06 AM, Erdal Mutlu wrote:
Hi,
I have been instrumenting the JS engine interpreter for logging memory updates
on JS scripts. My current instrumentation logs every
On 02/10/2015 01:06 AM, Erdal Mutlu wrote:
Hi,
I have been instrumenting the JS engine interpreter for logging memory updates
on JS scripts. My current instrumentation logs every use of the interpreter for
script execution which also includes browser (internal) script execution. I
wanted to a
This looks awesome!
What are the important limitations? I'm guessing it's not going to help
detect that if only X were true, the register allocator would have
avoided spilling any registers. I suppose that doesn't fit into
"high-level optimization decisions". But what sorts of things could hav
On 11/14/2014 10:15 AM, andy.zss...@gmail.com wrote:
> Hi, I am new to SpiderMonkey. Recently, I have tried to contribute a
> patch for IonMonkey bailout. The patch is now in "review+" and is
> submitted to the try server. But the summary report shows the "SM ggc"
> failed case. So I just refer to
On 10/31/2014 09:56 AM, Jon Coppeard wrote:
> I'm happy to announce that compacting GC tests have been enabled on
> mozilla-inbound.
>
> This means that changes that break compacting GC will get backed out now. If
> you think your changes might affect this you can run these tests locally by
> c
On 09/25/2014 11:45 AM, Steve Fink wrote:
> Second: All SM(...) jobs now run jsapi-tests, jstests, and jit-tests.
> The first two are new. jit-tests were already running. That means
> jstests are running both via the shell and the browser now (though some
> are marked shell-only, whic
First: You no longer have to use a system nspr or build nspr on your own
on any platform. configure --enable-nspr-build will build the in-tree
nsprpub/ directory and use that. Non-Windows builds continue to default
to --enable-posix-nspr-emulation, though note that that differs from our
tbpl SM(...
On 07/24/2014 07:26 AM, Jan de Mooij wrote:
> (3) Without any flags, we'll use the NSPR emulation code Bill added [2] (on
> POSIX platforms).
This is also available explicitly as --enable-posix-nspr-emulation.
(Dunno what that'll do on a non-POSIX platform.)
__
Sort of a mangled transcript of the embedding meeting at the 2014
Toronto JS work week.
Users
- AMO for linting etc.
- Gecko
- GNOME Shell
- MongoDB was, but switched to V8
If you want to validate against Spidermonkey, you kind of need to use
Spidermonkey. Or heuristics.
till: can we keep on
On Thu 13 Feb 2014 04:11:40 PM PST, Nicholas Nethercote wrote:
> 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'
On Thu 13 Feb 2014 03:03:23 PM PST, Mike Hommey wrote:
> On Thu, Feb 13, 2014 at 01:31:55PM -0800, Gary Kwong wrote:
>> On 2/13/14, 12:18 PM, Steve Fink wrote:
>>> Sounds like the sticking point is finding someone who will agree to
>>> keep them alive. There'
Sounds like the sticking point is finding someone who will agree to
keep them alive. There's no point in turning them on if they're going
to be broken for weeks/months at a stretch.
From skimming the discussion, one thing that's unclear to me is if
we're talking about Windows shell builds, or
On Fri 10 Jan 2014 01:52:55 AM PST, Andreas Schlegel wrote:
> Hello Steve,
>
> thank you for your reply.
>
> Am 09.01.2014 21:47, schrieb Steve Fink:
>> On 01/06/2014 09:25 AM, Andreas Schlegel wrote:
>>> Hello,
>>>
>>> I need the JSContext to dec
On 01/06/2014 09:25 AM, Andreas Schlegel wrote:
> Hello,
>
> I need the JSContext to declare JS::RootedObjects or Values.
> Especially for the case of WeakMap/Map/Set-Hasher I don't have the
> JSContext.
>
> At the moment I use the following implementation to get the JSContext
> (this is a code s
On Thu 02 Jan 2014 07:31:56 AM PST, Nicolas B. Pierron wrote:
> I think we can do better by implementing a regexp compiler which
> *targets* JavaScript instead of assembly. By generating asm.js-like
> code for regexp, we can have good generated code and we can easily
> apply all the rules we alrea
On 12/12/2013 12:45 PM, Kannan Vijayan wrote:
> 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.
No
On 12/12/2013 12:22 PM, Sean Stangl wrote:
> I second these experiences of working off m-i. Pushing patches manually is
> randomly frustrating, and so I've been using the "checkin-needed" keyword to
> avoid dealing with tree closures.
I've used that once or twice now too.
> The only problem wit
On 11/01/2013 11:52 AM, David Bruant wrote:
> That requires weakrefs in some way, I'm afraid. I'm interested if
> other solutions can be proposed to achieve object-granularity
> communication across machines (I'm sure Mark Miller will be interested
> as well).
>
Good use case. What if you had a se
On 11/01/2013 09:42 AM, Bobby Holley wrote:
> From the proposal:
>
> Note that makeWeakRef is not safe for general access since it grants access
>> to the non-determinism inherent in observing garbage collection.
>
> What does that mean? That they don't expect this to be exposed to the web?
> In th
On 09/24/2013 06:20 PM, Chris Peterson wrote:
> After collecting a list of the active SpiderMonkey projects [1], Naveed
> asked me to present the projects on a roadmap for the next four
> quarters. Here is a rough draft:
>
> https://wiki.mozilla.org/User:Cpeterson/Roadmap#Roadmap
>
> * Are any im
I would have still preferred the explicit Handle notation, but not
enough to argue the point. I'd rather have the matter settled.
To recap my arguments, for no particular reason:
- The main choice between template vs typedef is whether the information
being hidden is relevant or not. To me, the f
On Mon 29 Jul 2013 11:25:14 AM PDT, Brendan Eich wrote:
> Steve Fink wrote:
>> On Mon 29 Jul 2013 10:43:27 AM PDT, Brendan Eich wrote:
>>> BTW destructuring plus array return should be optimized to erase the
>>> allocation and use the stack instead. E.g.,
>>>
&g
On Mon 29 Jul 2013 10:43:27 AM PDT, Brendan Eich wrote:
> Steve Fink wrote:
>> It tickles my innate premature optimization kneejerk
>> reaction, though.
>
> I know this was in context of "fair enough" and "I think you're
> right", but I LOL
On Sun 28 Jul 2013 05:06:33 AM PDT, David Bruant wrote:
> Le 28/07/2013 08:53, Steve Fink a écrit :
>> * using an array for a tuple feels heavyweight. |return [a,b]|. Compare
>> with Python's tuples or Perl's multiple return values.
> The "tradition" in JS is
On Fri 26 Jul 2013 12:29:10 PM PDT, Brendan Eich wrote:
> Steve Fink wrote:
>> (2) writing JS still feels clunky in comparison to writing
>> Python,
>
> What's missing in your experience?
That question deserves a proper response, but it's tough remembering
t
On Fri 26 Jul 2013 10:32:09 AM PDT, Brendan Eich wrote:
> Norbert asked me yesterday whether we shouldn't start moving from
> Python to JS. The obstacle historically has been lack of build-prereq
> industry-grade "js shells" already installed. Does node change that?
Not in my opinion. It's common
Then the question becomes whether in this case the templates are an
implementation detail or a useful part of the type. bz has code that
makes use of the fact that they're templates. It sounds like our marking
code does something similar. Both of those imply that it is an aspect of
the types th
On 06/20/2013 07:21 AM, Till Schneidereit wrote:
All!
We still don't have a clear line on how to name handles, both in- and
outside of the engine. Or, if we do, it's pretty unevenly distributed.
The current policy is HandleT inside spidermonkey and xpconnect,
JS::Handle outside.
Seeing as
On 06/14/2013 03:11 PM, Bill McCloskey wrote:
This all sounds good to me. I just wanted to ask one question that's
nagged me from time to time. Maybe somebody knows the answer.
Are we actually allowed to use files with the same name in different
directories? Based on how stuff gets listed in m
Over in bug 835552, I'm trying to change the behavior of relative path
lookups.
Current behavior:
- load("foo/bar.js") will search relative to the current working directory
- read("foo/bar.txt") will search relative to the calling script's
filename on XP_UNIX (and relative to the current working
The root analysis builds, marked with SM(r), are now live and unhidden
on mozilla-inbound. That means the sheriffs will back changes out if
they break.
The builds will only be triggered for pushes that touch js/src.
You can run them on the try server by doing any push that gets a
linux64-debug bu
One more thing -- Brian Hackett implemented a static analysis that
identifies which functions can GC. See bug 829243. I slapped together a
very basic IRC bot that loads in the output of his analysis. The bot is
called "mrgiggles" and hangs out on #jsapi. (No, there is no particular
meaning to the n
On 12/18/2012 06:01 PM, sf...@mozilla.com wrote:
With Terrence on vacation, I'm writing the rooting analysis summary this week.
Ok, mostly I'm trying out my fancy schmancy new HTML mail version. I never had
the patience to extract meaning out of the textual version.
Ugh. And apparently the ma
From this thread, it sounds like one problem is that the JSAPI is
requiring users to deal with weird things called "compartments" that
are absolutely meaningless to the calling code. It's JSContexts all
over again. "Why are they needed? What are they for? Can't the engine
just figure it out?" A
The bindings problem was preexisting. Terrence recently fixed it. You
can probably update to the latest code to get rid of that, but I'm
doubtful that any problems reported will actually be relevant to your crash.
Perhaps the resident cycle collector expert, Andrew McCreight, can point
you in
On 08/02/2012 03:22 PM, Jim Blandy wrote:
For a long time, these have lived at:
http://hg.mozilla.org/users/jblandy_mozilla.com/archer-mozilla/ However,
I've started putting together a patch to integrate them into the Mozilla
tree, so that anyone who uses a Python-capable GDB will get them
automa
On Fri 13 Jul 2012 12:37:10 PM PDT, Brian Hackett wrote:
> Forwarding to the list, this got bounced by @googlegroups address (grumble)
>
> - Original Message -
>> From: "Brian Hackett"
>> To: "Steve Fink"
>> Cc: "mozilla dev tech
(apologies if you receive this twice; trying to fix 2 sending failures)
My current leaning:
- Use the current scheme of Rooted, MutableHandle, and Handle
- Add in an Unrooted
- Eliminate pretty much all bare pointers from the engine (except in
some of the GC code)
- Convert all member functio
60 matches
Mail list logo
