Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

[luoyonggang]

It's seems they are all dead.
在 2016/1/14 20:02, Philip Chee  写道:

   On 04/01/2016 20:13, 罗勇刚(Yonggang Luo)  wrote:

On Mon, Jan 4, 2016 at 7:22 PM, Bobby Holley  wrote:


If you're forking mozilla-central, that shouldn't be a problem, right?


I am asking for some help, seeking for problems when I was trying to
implement XPCOM  connect with js-ctypes.
So far, the garbage collection would be the biggest problem.
Even though WebIDL has it's own advantages, but XPCOM are more
language-neutral.

   Have you looked at libraries such as SpiderApe or libjspp?
   Phil


- Send from WPS Mail -
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Feedback needed on proposal to add a web primitive for queuing microtasks

[David Rajchenbach-Teller]

I also think that this makes sense. Can we already start thinking about
countermeasures, though?

It looks to me that catching a long-running/infinite microtask loop is
much easier to detect and interrupt than a long-running sequential loop.
However, if we wish to pause a page with such a microtask loop to
display some UX, trigger a breakpoint or even to leave some CPU to other
pages in the same process, is there anything specific we need to do to
guarantee that no network/user input/layout/apz... can be processed
during the interrupt?

Cheers,
 David

On 14/01/16 00:35, Ehsan Akhgari wrote:
> I think this makes sense.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Feedback needed on proposal to add a web primitive for queuing microtasks

[Anne van Kesteren]

On Thu, Jan 14, 2016 at 10:44 AM, David Rajchenbach-Teller
 wrote:
> I also think that this makes sense. Can we already start thinking about
> countermeasures, though?

Whatever we do for while(true) we should reuse here. There's no
observable difference to the user. (And as stated this can already
happen with promises and mutation observers.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

[Philip Chee]

On 04/01/2016 20:13, 罗勇刚(Yonggang Luo)  wrote:
> On Mon, Jan 4, 2016 at 7:22 PM, Bobby Holley  wrote:
> 
>> If you're forking mozilla-central, that shouldn't be a problem, right?
>>
> I am asking for some help, seeking for problems when I was trying to
> implement XPCOM  connect with js-ctypes.
> So far, the garbage collection would be the biggest problem.
> Even though WebIDL has it's own advantages, but XPCOM are more
> language-neutral.

Have you looked at libraries such as SpiderApe or libjspp?

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

SharedArrayBuffer and Atomics will ride the trains behind a pref

[Lars Hansen]

Until now the new SharedArrayBuffer constructor and the new Atomics global
object [1] have been enabled on Nightly only.  Starting with Firefox 46,
those bindings will still be enabled by default on Nightly but they will
also be available on Aurora, DevEd, Beta, and Release by flipping the value
of javascript.options.shared_memory to true in about:config.

--lars

[1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Thomas Zimmermann]

Hi,

I saw the lightning talk you gave in Orlando in this topic. I was
wondering if you considered implementing Transactional Memory for
SharedArrayBuffer. JS seems like the perfect environment for TM. Are
there reasons for 'only' providing atomic ops? Just asking out of
curiosity...

Best regards
Thomas


Am 14.01.2016 um 14:16 schrieb Lars Hansen:
> Until now the new SharedArrayBuffer constructor and the new Atomics global
> object [1] have been enabled on Nightly only.  Starting with Firefox 46,
> those bindings will still be enabled by default on Nightly but they will
> also be available on Aurora, DevEd, Beta, and Release by flipping the value
> of javascript.options.shared_memory to true in about:config.
>
> --lars
>
> [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Thomas Zimmermann]

Thanks!

Am 14.01.2016 um 15:08 schrieb Lars Hansen:
> On Thu, Jan 14, 2016 at 2:49 PM, Thomas Zimmermann 
> wrote:
>
>> Hi,
>>
>> I saw the lightning talk you gave in Orlando in this topic. I was
>> wondering if you considered implementing Transactional Memory for
>> SharedArrayBuffer.
>
> ​I have not (or, not in earnest).
> ​
>
>
>> JS seems like the perfect environment for TM. Are
>> there reasons for 'only' providing atomic ops? Just asking out of
>> curiosity...
>>
> ​The use cases that drive this work are access to multicore performance
> from JS as well as asm.js as a compilation target for conventional
> multithreaded C++; actually the asm.js case is the more important one at
> this time.  Hence the focus for this first version of the spec has been on
> (very) low level mechanisms that can serve those use cases in
> straightforward ways.
>
> Personally I'd like to see us add additional higher-level mechanisms that
> are a better fit for straight JS programming.  I'm hoping that we can use
> the current low level mechanisms to prototype higher level ones, and
> eventually standardize some of them.  I don't know how well we can
> prototype TM like that - but it's early days still.
>
> --lars
>
>
>> Best regards
>> Thomas
>>
>>
>> Am 14.01.2016 um 14:16 schrieb Lars Hansen:
>>> Until now the new SharedArrayBuffer constructor and the new Atomics
>> global
>>> object [1] have been enabled on Nightly only.  Starting with Firefox 46,
>>> those bindings will still be enabled by default on Nightly but they will
>>> also be available on Aurora, DevEd, Beta, and Release by flipping the
>> value
>>> of javascript.options.shared_memory to true in about:config.
>>>
>>> --lars
>>>
>>> [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Lars Hansen]

On Thu, Jan 14, 2016 at 2:49 PM, Thomas Zimmermann 
wrote:

> Hi,
>
> I saw the lightning talk you gave in Orlando in this topic. I was
> wondering if you considered implementing Transactional Memory for
> SharedArrayBuffer.


​I have not (or, not in earnest).
​


> JS seems like the perfect environment for TM. Are
> there reasons for 'only' providing atomic ops? Just asking out of
> curiosity...
>

​The use cases that drive this work are access to multicore performance
from JS as well as asm.js as a compilation target for conventional
multithreaded C++; actually the asm.js case is the more important one at
this time.  Hence the focus for this first version of the spec has been on
(very) low level mechanisms that can serve those use cases in
straightforward ways.

Personally I'd like to see us add additional higher-level mechanisms that
are a better fit for straight JS programming.  I'm hoping that we can use
the current low level mechanisms to prototype higher level ones, and
eventually standardize some of them.  I don't know how well we can
prototype TM like that - but it's early days still.

--lars


> Best regards
> Thomas
>
>
> Am 14.01.2016 um 14:16 schrieb Lars Hansen:
> > Until now the new SharedArrayBuffer constructor and the new Atomics
> global
> > object [1] have been enabled on Nightly only.  Starting with Firefox 46,
> > those bindings will still be enabled by default on Nightly but they will
> > also be available on Aurora, DevEd, Beta, and Release by flipping the
> value
> > of javascript.options.shared_memory to true in about:config.
> >
> > --lars
> >
> > [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement/Ship: document.elementsFromPoint

[Kyle Machulis]

*Summary*: We don't currently support documents.elementsFromPoint, while IE
and Chrome do (I'm not sure if Opera and Safari have gotten around to it
yet). It's making important things like IRCCloud angry. There's also an
elementsFromRect, but I think I may wait on that since it doesn't even have
a spec yet (https://www.w3.org/Bugs/Public/show_bug.cgi?id=27837).

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1164427

*Link to standard*:
http://dev.w3.org/csswg/cssom-view/#dom-document-elementfrompoint

*Platform coverage*: All platforms.

*Estimated or target release*: Firefox 46, might see about uplifting
farther if it lands quickly (w-p-t's at least pass with current patch)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebKitCSSMatrix

[L. David Baron]

On Thursday 2016-01-14 14:06 -0800, William Chen wrote:
> *Summary*: WebKitCSSMatrix has been available for years in WebKit based
> browsers and has seen widespread usage on the web. This feature is
> currently available in Chrome, Safari and Edge. Mike Taylor has been
> working on standardizing the feature and it is being implemented in Gecko
> to improve web compatibility.
> 
> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=717722
> 
> *Link to standard*:
> https://compat.spec.whatwg.org/#webkitcssmatrix-interface
> 
> 
> *Platform coverage*: All platforms.
> 
> *Estimated or target release*: Firefox 46

It seems to me this is important to have behind a preference that is
specific to new webkit-prefixed features, given the compatibility
risks of shipping support for some but not all webkit-prefixed
features.

(It's possible it could be the same preference as other new
webkit-prefixed CSS features.)

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebKitCSSMatrix

[Jonas Sicking]

Ship it!

On Thu, Jan 14, 2016 at 2:06 PM, William Chen  wrote:
> *Summary*: WebKitCSSMatrix has been available for years in WebKit based
> browsers and has seen widespread usage on the web. This feature is
> currently available in Chrome, Safari and Edge. Mike Taylor has been
> working on standardizing the feature and it is being implemented in Gecko
> to improve web compatibility.
>
> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=717722
>
> *Link to standard*:
> https://compat.spec.whatwg.org/#webkitcssmatrix-interface
> 
>
> *Platform coverage*: All platforms.
>
> *Estimated or target release*: Firefox 46
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Robert O'Callahan]

On Fri, Jan 15, 2016 at 12:01 PM, Nick Fitzgerald 
wrote:

> Console, debugger, performance: these panels are ​a clear "always show" to
> me. The web audio tool is very niche and so I don't think it would make
> sense to show it by default. The memory tool falls in between in my mind.
> I'm open to suggestions!
>

Why not make them context-sensitive? Show the Web Audio tool if the page
uses Web Audio, Shader Editor if the page uses WebGL, Canvas if the page
has a 2D canvas, Storage if the page uses IndexedDB, Memory if the page
uses memory :-). Well, for memory, use some heuristic like if the page
spends more than 16ms in a single GC.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Brian Grinstead]

> On Jan 14, 2016, at 3:01 PM, Nick Fitzgerald  wrote:
> Also, what is the plan for making tools like the Memory view appear in a 
> default install? In other words, without having to go to the Settings. I 
> worry that users may not know to click on the Settings and just think that 
> other browsers offer more tools than we do.
> 
> ​This is a good conversation to have, but I don't have any good answers. We 
> have a lot of panels in the devtools, many of which are fairly niche, and it 
> isn't clear how to simultaneously give them visibility and not overwhelm 
> users.
> 
> Console, debugger, performance: these panels are ​a clear "always show" to 
> me. The web audio tool is very niche and so I don't think it would make sense 
> to show it by default. The memory tool falls in between in my mind. I'm open 
> to suggestions!

There are some designs in flight that would make selecting a non-default panel 
much easier by adding an arrow after the last one, which would open a popup 
with all panels available.  So you could avoid a trip to the settings panel.  
I’ve filed a bug 1239859 for this since I couldn’t find another one on file.

Brian
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

FYI - Autophone down for maintenance

[Bob Clary]

Autophone  is going down this 
afternoon for several hours while the devices are being switched to new 
hosts.


bc
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Nick Fitzgerald]

Reply inline below.

On Thu, Jan 14, 2016 at 2:49 PM, Jared Wein  wrote:

> From your screenshot, there are a lot of instances of "objects > Array",
> "objects > Object", etc. Is the a way to display the variable name used for
> those objects?
>

​The node might not be in a JS variable (eg​ is a C++ implementation detail
that is not exposed to JS) or it might be referred to by many variables in
different parts of the JS code or it might be referred to not by any
variables in the JS code, but by something in the C++ world.

So, I think the "real" (or at least more general) solution is to show the
first N shortest paths from the GC roots to the thing. This is the next
feature I will be working on for the memory tool. I wanted to do dominator
trees first because it tells you which objects to pay attention to; the
shortest paths will tell you more about how a specific object is kept
alive. It didn't make sense to do the latter before the former.

Stay tuned!


> Also, what is the plan for making tools like the Memory view appear in a
> default install? In other words, without having to go to the Settings. I
> worry that users may not know to click on the Settings and just think that
> other browsers offer more tools than we do.
>

​This is a good conversation to have, but I don't have any good answers. We
have a lot of panels in the devtools, many of which are fairly niche, and
it isn't clear how to simultaneously give them visibility and not overwhelm
users.

Console, debugger, performance: these panels are ​a clear "always show" to
me. The web audio tool is very niche and so I don't think it would make
sense to show it by default. The memory tool falls in between in my mind.
I'm open to suggestions!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ESLint checks are now running on the nightly trees on checkin

[Andrew Halberstadt]

On 14/01/16 12:24 PM, Dave Townsend wrote:

All hail the mighty releng folks who have made it so ridiculously easy
to prototype and deploy new taskcluster tests!


I just want to emphasize the significance here. A developer unaffiliated
with either releng or the ateam and with only minimal support, just
stood up a new job in continuous integration, while only modifying files
that live in-tree.

A year or two ago, this would have been the quarterly goal of someone
who knew what they were doing. Big props to the taskcluster team!

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Lars Hansen]

Yes, disabled by default on all branches, enabled by default on Nightly.
(It's also supported on ARM, so it should be possible to test it on
Android, again by flipping the pref.)

--lars

On Thu, Jan 14, 2016 at 9:14 PM, Jonas Sicking  wrote:

> Hi Lars,
>
> So if I understand correctly, this will still remain disabled by
> default on all branches. However it will now be possible to test out
> on all branches by flipping a pref?
>
> If so that sounds great to me.
>
> / Jonas
>
> On Thu, Jan 14, 2016 at 5:16 AM, Lars Hansen  wrote:
> > Until now the new SharedArrayBuffer constructor and the new Atomics
> global
> > object [1] have been enabled on Nightly only.  Starting with Firefox 46,
> > those bindings will still be enabled by default on Nightly but they will
> > also be available on Aurora, DevEd, Beta, and Release by flipping the
> value
> > of javascript.options.shared_memory to true in about:config.
> >
> > --lars
> >
> > [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Robert O'Callahan]

Sounds good to me too. What's blocking us from enabling by default?

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Feedback needed on proposal to add a web primitive for queuing microtasks

[Boris Zbarsky]

On 1/14/16 4:44 AM, David Rajchenbach-Teller wrote:

However, if we wish to pause a page with such a microtask loop to
display some UX, trigger a breakpoint or even to leave some CPU to other
pages in the same process, is there anything specific we need to do to
guarantee that no network/user input/layout/apz... can be processed
during the interrupt?


We punt on that for the slow script dialog right now, fwiw.

But yes, this is a problem we need to solve in general...

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Feedback needed on proposal to add a web primitive for queuing microtasks

[Boris Zbarsky]

On 1/14/16 6:27 AM, Anne van Kesteren wrote:

Whatever we do for while(true) we should reuse here. There's no
observable difference to the user. (And as stated this can already
happen with promises and mutation observers.)


I dunno what the situation is right now with mutation observers, but for 
promises we do in fact try reuse exactly what while(true) does.


Except I think we fail.  I filed 
https://bugzilla.mozilla.org/show_bug.cgi?id=1239817 on that part.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ Core Guidelines

[Henri Sivonen]

On Wed, Jan 13, 2016 at 12:53 AM, Ehsan Akhgari  wrote:
> I'll investigate integrating gsl-lite into m-c.

Thank you.

On Mon, Jan 11, 2016 at 10:03 PM, Brian Smith  wrote:
> mozilla::pkix::Input/Reader will never throw an exception or abort the
> process; instead it always returns an explicit success/failure result. It
> seems GSL will either abort or throw an exception in many situations. Since
> aborting is terrible and exceptions are not allowed in Gecko code, it seems
> Input/Reader is safer.

For uses where bound checks are merely a seat belt to avoid remote
code execution or memory disclosure vulnerabilities in case of a
programming error, aborting the process in probably better than asking
the caller to have error handling code that hopefully never runs.

(Out-of-bounds access of slices on the Rust side of FFI panics anyway.)

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ESLint checks are now running on the nightly trees on checkin

[Dave Camp]

This is great, big thanks to everyone involved.

-dave

On Thursday, January 14, 2016, Dave Townsend  wrote:

> Just a heads up, a full ESLint check of the tree is now being run on
> every checkin to mozilla-central or the other integration branches.
> The check is also available on tryserver [1], you can run it locally
> with "mach eslint" or why not make life easy and install the mercurial
> extension [2].
>
> Not many rules are enforced yet so mostly this is stopping you from
> using non-standard JS and preprocessing.
>
> All hail the mighty releng folks who have made it so ridiculously easy
> to prototype and deploy new taskcluster tests!
>
> [1] try: -b o -p eslint-gecko
> [2] http://www.oxymoronical.com/blog/2015/12/Running-ESLint-on-commit
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org 
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Jonas Sicking]

Hi Lars,

So if I understand correctly, this will still remain disabled by
default on all branches. However it will now be possible to test out
on all branches by flipping a pref?

If so that sounds great to me.

/ Jonas

On Thu, Jan 14, 2016 at 5:16 AM, Lars Hansen  wrote:
> Until now the new SharedArrayBuffer constructor and the new Atomics global
> object [1] have been enabled on Nightly only.  Starting with Firefox 46,
> those bindings will still be enabled by default on Nightly but they will
> also be available on Aurora, DevEd, Beta, and Release by flipping the value
> of javascript.options.shared_memory to true in about:config.
>
> --lars
>
> [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

[Luke Wagner]

For additional rationale, you might be interested to read:
  
https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/

On Thu, Jan 14, 2016 at 8:11 AM, Thomas Zimmermann
 wrote:
> Thanks!
>
> Am 14.01.2016 um 15:08 schrieb Lars Hansen:
>> On Thu, Jan 14, 2016 at 2:49 PM, Thomas Zimmermann 
>> wrote:
>>
>>> Hi,
>>>
>>> I saw the lightning talk you gave in Orlando in this topic. I was
>>> wondering if you considered implementing Transactional Memory for
>>> SharedArrayBuffer.
>>
>> I have not (or, not in earnest).
>>
>>
>>
>>> JS seems like the perfect environment for TM. Are
>>> there reasons for 'only' providing atomic ops? Just asking out of
>>> curiosity...
>>>
>> The use cases that drive this work are access to multicore performance
>> from JS as well as asm.js as a compilation target for conventional
>> multithreaded C++; actually the asm.js case is the more important one at
>> this time.  Hence the focus for this first version of the spec has been on
>> (very) low level mechanisms that can serve those use cases in
>> straightforward ways.
>>
>> Personally I'd like to see us add additional higher-level mechanisms that
>> are a better fit for straight JS programming.  I'm hoping that we can use
>> the current low level mechanisms to prototype higher level ones, and
>> eventually standardize some of them.  I don't know how well we can
>> prototype TM like that - but it's early days still.
>>
>> --lars
>>
>>
>>> Best regards
>>> Thomas
>>>
>>>
>>> Am 14.01.2016 um 14:16 schrieb Lars Hansen:
 Until now the new SharedArrayBuffer constructor and the new Atomics
>>> global
 object [1] have been enabled on Nightly only.  Starting with Firefox 46,
 those bindings will still be enabled by default on Nightly but they will
 also be available on Aurora, DevEd, Beta, and Release by flipping the
>>> value
 of javascript.options.shared_memory to true in about:config.

 --lars

 [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
>>>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Dominator tree memory analysis now in Nightly

[Nick Fitzgerald]

Hi folks!

Dominator trees give you fine-grained insight into memory retention.

In a graph rooted by some node R, a node A is said to dominate B iff every
path to B starting from R passes through A. In the context of a heap graph,
another way to say this would be that A is retaining B: if the garbage
collector found A to be unreachable and eligible for reclaiming, than B
would also be unreachable and eligible for reclaiming.

We also use this to calculate the "true" memory cost of a node in the heap
graph. This is the "retained size" and contrasts with the naive "shallow
size". For example, imagine a large binary tree where there are no outside
references into subtrees, only to the root. The root node itself has a
small shallow size: a left branch pointer, a value, and a right branch
pointer. However, it is retaining the whole rest of this large tree's
structure, and so its retained size is significant.

Here is a screenshot of the dominator tree (combined with allocation stack
tracking) in action to debug the memory overhead of loading large source
files in a CodeMirror editor: http://i.imgur.com/sGsVJb9.png

And here is a reminder of how to enable to memory tool within the devtools:
http://i.imgur.com/hEPTqrT.png

If you would like to use this tool for the whole runtime rather than scoped
to a single tab, use the browser toolbox. Here are instructions for
enabling and using the browser toolbox:
https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox

Please try it out, give me your feedback, and file bugs in the "Firefox"
product and "Developer Tools: Memory" component!

My thanks to the folks who reviewed patches for this feature: Jordan
Santell, Steve Fink, Boris Zbarsky, and Jim Blandy.

Cheers,

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: WebKitCSSMatrix

[William Chen]

*Summary*: WebKitCSSMatrix has been available for years in WebKit based
browsers and has seen widespread usage on the web. This feature is
currently available in Chrome, Safari and Edge. Mike Taylor has been
working on standardizing the feature and it is being implemented in Gecko
to improve web compatibility.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=717722

*Link to standard*:
https://compat.spec.whatwg.org/#webkitcssmatrix-interface


*Platform coverage*: All platforms.

*Estimated or target release*: Firefox 46
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform