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 scope for the most part.
I'm skeptical that there are any advant
I think we're starting to conflate separate concepts. I absolutely believe
that code should be modular. SpiderMonkey is a great example: we're much
more productive because of how well separated it is from the rest of the
browser. On the other hand, *people* should not be modular. You don't need
to
On Wed, May 11, 2016 at 5:01 AM, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:
If the problem are the pointless arguments on dev.platform, which are
> mistakenly considering SpiderMonkey as Gecko's property, I would totally
> agree on moving SpiderMonkey into its own repository.
>
> I
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#679
For the Function stuff, it sounds like maybe those are the sh
- Original Message -
> From: "Jan de Mooij"
> To: "Bill McCloskey"
> Cc: "Benjamin Smedberg" , "JS Internals list"
>
> Sent: Thursday, February 27, 2014 10:56:22 AM
> Subject: Re: [JS-internals] Memory poisoning and other way
We poison the GC heap with 0xda on nightly and aurora [1]. Lots of our
processMarkStackTop are at this address [2]. It looks like we only poison Ion
code in debug builds [3]. That should be easy to fix by removing the #ifdef
DEBUG.
I don't think we've found GC heap poisoning to be all that help
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.
-Bill
On Tue, Jan 21, 2014 at 7:44 PM, Nicholas Nethercote wrote:
> Hi,
>
> I got some puzzling
- Original Message -
> From: "Jim Blandy"
> To: dev-tech-js-engine-internals@lists.mozilla.org
> Sent: Wednesday, January 22, 2014 11:33:21 AM
> Subject: Re: [JS-internals] Non-static, length 1, ASCII strings?
>
> On 01/22/2014 12:12 AM, Nicholas Nethercote wrote:
> > I don't know much ab
- Original Message -
> From: "Gregory Szorc"
> To: "Jeff Walden" ,
> dev-tech-js-engine-internals@lists.mozilla.org
> Sent: Tuesday, December 17, 2013 4:20:37 PM
> Subject: Re: [JS-internals] Improvements to the Sphinx in-tree documentation
> generation
>
> Thanks for the info Jeff. I'
Congrats, Jason!
I stopped watching the JS component about 6 months ago when I switched to e10s
work. At the time, I found it to be kind of nice to see every comment. Bugs
that started out uninteresting to me would occasionally take an interesting
turn. I did find that I skipped over pretty muc
Does anyone have any idea what's going on here? It seems like there are maybe 5
or 10 a day getting filed. Examples:
https://bugzilla.mozilla.org/show_bug.cgi?id=916388
https://bugzilla.mozilla.org/show_bug.cgi?id=916386
They all have the form "X is undefined" or "X is not a function" or some ot
> On 7/18/13 11:45 PM, Bill McCloskey wrote:
> > Well, these wouldn't be normal properties. There wouldn't be shapes for
> > them or anything. You would still access them using slot numbers that you
> > would have to lay out yourself. So I don't think there wo
Boris said:
> I think the idea is to try to have objects that are allocated in the JS
> heap but that are treated as Rust objects from Rust. That means that
> the actual object layout needs to be the same for all Node objects, say
> (if the Node members are stored in the JS-heap allocation).
Well
On 07/18/2013 02:01 PM, Boris Zbarsky wrote:
So three reserved slots are not enough to the extent that DOM objects
have more than three members (and they do!).
It seems like we could use non-reserved slots on proxies. Basically, we
could pass the number of slots we want into ProxyObject::New,
On 07/18/2013 01:46 PM, Josh Matthews wrote:
I'm experimenting with storing Servo DOM objects in the reserved slots of
the JS wrappers, but hitting a wall when it comes to DOM proxy objects.
Since we can't modify the number of reserved slots for a given proxy class,
Boris came up with a proposal
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 at all. It probably would make sense to rename ProxyClass to
something less confusing.
-Bill
- Original Message --
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 moz.build, it seems like
it wouldn't work. Mayb
On 03/18/2013 11:46 AM, Wes Garland wrote:
So, zones are roughly analogous to a JSRuntime from the embedder's POV?
When you call JS_NewGlobalObject, you now tell it what zone to put the
compartment into. By default, every global gets its own zone. However,
you could choose to put everything i
Hi everyone,
Zones landed over the weekend and it looks like it's going to stick this
time. I saw a few questions this morning on IRC about what the new
invariants are, so I wrote a comment explaining things as best I could
(bug 852229). I'm attaching it in the email. Any input would be welcom
> To clarify: it's only used in
> http://mxr.mozilla.org/mozilla-central/source/config/Preprocessor.py#132,
> which is "a very primitive line based preprocessor, for times when
> using a C preprocessor isn't an option."
>
> Even better: Benjamin tells me the "atline" option isn't set in the
> br
> bhackett's comment
> https://bugzilla.mozilla.org/show_bug.cgi?id=821040#c5 does not
> confirm.
> Anyone else try to reproduce?
To clarify, we know for sure that the problem was caused by switching to a
threadsafe build. We don't know why threadsafe builds are slower. I saw some
results that s
On 01/08/2013 01:35 PM, Bobby Holley wrote:
Wait, I'm confused. I was told that the Handle API isn't ready and
shouldn't be used in the browser. So why is browser usage considered a
regression here?
bholley
It's not a regression in the usual "track down the offender and make
them fix it" sens
I'm afraid I don't know much about this aspect of the code, but maybe someone
on the JS engine mailing list can help. Unfortunately, there isn't any easy way
to track down GC issues.
-Bill
- Original Message -
> From: "Norbert Lindenberg"
> To: "William McCloskey"
> Cc: "Norbert Linde
Hi everyone,
I've been working on a Firefox addon to help us improve garbage
collection pause times. It collects your GC pause times and sends them
to a server. It's a bit like the Memchaser extension combined with
Telemetry. It doesn't have any UI at all, so it shouldn't bother you
once it's
24 matches
Mail list logo
