On 1/27/2017 12:06 PM, Julian Seward wrote:
It would be really good if testing for data races with TSan could be
an integral, routine part of this development process.
++!
We do have bug 1291954 on file for getting an SM(tsan) job up and
running in automation, but it doesn't look like
What an exciting time!
On Fri, Jan 27, 2017 at 7:36 AM, Brian Hackett
wrote:
>
> To help avoid threading bugs during and after this transition,
>
> bug
> 1325050 also adds a ProtectedData class, which is a template that can
> be used on class fields to specify the
Hey JS team!
Please try to use ClassSpec when adding a new built-in object. This
means you don't have to manually define all your properties and
methods and instead let the ClassSpec mechanism take care of this. It
will also link the prototype and stuff like that, so overall a much
nicer system.
On Fri, Jan 27, 2017 at 3:56 PM, Ehsan Akhgari
wrote:
> On 2017-01-27 11:24 AM, Brian Hackett wrote:
> > On Fri, Jan 27, 2017 at 8:55 AM, Benjamin Smedberg
> > wrote:
> >> Is there something that explains a little more what gains this will buy
>
Bug 1323066 is moving the JS engine to a model where multiple threads
can run JS and otherwise interact with a runtime. Initially, threads
running JS will be cooperatively scheduled, so at most one thread is
running at once, but the target for bug 1323066 is preemptive
multithreading where
Is there something that explains a little more what gains this will buy us
or how it will be used at the DOM level?
What will these multiple threads actually be doing, running script from a
single webpage?
How frequent will locking be, and what will locking overhead do to
performance? Will there
On 1/27/17 10:36 AM, Brian Hackett wrote:
Any thoughts or comments?
Oh, one more thing: will a result of this be that jsids can be used
across threads (at least if you appropriately pin them and whatnot)?
Right now Gecko has some per-thread jsid tables that duplicate
information; it would
These should be the main places where API clients will need changes:
- When creating compartments / zones the zone group to use needs to be
specified.
- The persistent roots API will need some changes to be threadsafe.
- I'm not sure about the details yet, but GC tracing APIs might need
changes
On 1/27/17 11:44 AM, Brian Hackett wrote:
These per-thread jsid tables are used to accommodate the separate
worker runtimes, right?
That's correct.
then they'll be able to share jsids and separate per-thread tables
won't be necessary.
Excellent. ;)
-Boris
On 27/01/17 16:36, Brian Hackett wrote:
> Any thoughts or comments?
It would be really good if testing for data races with TSan could be
an integral, routine part of this development process. We've seen in
the past that after-the-fact race detection and fixing is a slow and
difficult process,
10 matches
Mail list logo