RE: escaping - in /u RegExp
I think it s a bug, and I think your proposal is appropriate. From: al...@wirfs-brock.com Subject: escaping - in /u RegExp Date: Tue, 13 Jan 2015 13:23:54 -0800 To: es-discuss@mozilla.org Would those of you who consider yourselves RegExp experts take a look at https://bugs.ecmascript.org/show_bug.cgi?id=3519 Is this a bug? If so, what is the fix? This construction for Identity Escape goes back to Norbert's original proposal http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/index.html Perhaps we need to add a: ClassAttom[U] :: [+U] \- production or some such to the pattern grammar. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Sharing a JavaScript implementation across realms
I don't think there is any difference in self-hosting JavaScript or JS-engine in C++. For example, use the example case `Array.prototype.map`, in C++, we could code a native function and create a corresponding object for each realm (note that the only shared part is the native function). In JS-based JS engine, we can create multiple objects sharing the same [[Call]] internal slot - exactly same as it is in C++ implementations. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Implicit coercion of Symbols
From: Domenic Denicola d...@domenic.me To: Rick Waldron waldron.r...@gmail.com, es-discuss es-discuss@mozilla.org Cc: Date: Mon, 12 Jan 2015 18:02:17 + Subject: RE: Implicit coercion of Symbols I re-read through this whole thread and realized nobody brought up the fact that this *specific* change, of making `String(symbol)` work while `symbol+` throws, was discussed and agreed upon previously: - https://esdiscuss.org/topic/string-symbol - https://github.com/tc39/tc39-notes/blob/master/es6/2014-09/sept-23.md#41-spec-status-report I realize people are presumably having second thoughts, but I thought it'd be worth linking to the previous thread for anyone who hasn't seen it and thinks this is a new debate. Good catch. I wouldn't have been surprised if nobody even thought of it until now (in this discussion, anyways). -- Isiah Meadows ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Sharing a JavaScript implementation across realms
On Tue, Jan 13, 2015 at 4:21 AM, Anne van Kesteren ann...@annevk.nl wrote: A big challenge with self-hosting is memory consumption. A JavaScript implementation is tied to a realm and therefore each realm will have its own implementation. Contrast this with a C++ implementation of the same feature that can be shared across many realms. The C++ implementation is much more efficient. If we want to get further with turning the web platform into a giant JavaScript library, we need to tackle this somehow. Has anyone been thinking about how to do this and what changes it would require from JavaScript proper? We're now at the point where we can implement platform objects in terms of JavaScript, but JavaScript loses out due to lack of efficiency. PS: Alternative explanation available here: https://annevankesteren.nl/2015/01/javascript-web-platform My hypothesis is that it *requires* no further changes to JavaScript proper beyond ES5 strict mode, ES6 modules, and the inter-realm (aka global) Symbol registry. But some future changes under discussion may help, such as extensible value types, if done right. First, an impractical straw man (straw man in the negative sense that is) that would have worked even in ES3 days, just to make a point: When the same url-full-path.js file is loaded multiple times to populate multiple realms, the browser cache hopefully typically hits, avoiding actually loading the source code over the web multiple times. Such cacheable urls might, for examples, be urls on a CDN. The string representing this source code can then of course be shared across realms, and even between workers sharing an address space. With enough cleverness, large strings can even be shared between address spaces. All the code generation derived from this string can be re-derived from this string, so all that generated code can be in a memory-budget limited cache. As long as the cache is big enough for the working set of code that needs to be run, a finite cache + some per-realm bookkeeping can handle an unbounded number of realms loading the same sources. The per-realm bookkeeping has to preserve the correspondence of the identity and state of function objects to the code describing their behavior. The code part of these function objects at a minimum can refer to its source string and the position in that source string of its own source code. Regarding remaining identity and state, all this is still per realm with no further economizing, but this is true for builtin (C++, Rust, etc) functions as well. The above scenario solves the memory consumption problem, but at a cost of regenerating the code from string source on a generated-code-cache-miss. Much of the time spent regenerating from string sources is lexing and parsing, which are context independent even in ES3, so we can cache some immutable representation of the parsed form rather than the source strings, probably taking more space, but reducing the regeneration time. Next is scope analysis, which is stable up to free variables (typically globals) in ES5 strict mode code, so this can be cached inter-realm as well. ES6 modules brings even more stability of scope analysis, given that our cache-hit test takes transitive imports into account as well. The inter-realm Symbol registry gives us an inter-realm namespace that we can use for reliable runtime inter-realm brand testing, public slot naming, and duck typing. Note that all modern JS engines JIT compile to generate the actual machine code, which they invalidate when assumptions change, so all actual machine code is in an invalidate-able cache that cannot be shared between realms. This is an irreducible cost compared to a builtin (C++, Rust, etc) implementation. The point of the inter-realm cache is to reduce the time taken to repopulate this unsharable part. Both caches can be memory-budget limited. Unfortunately, browser caches do not test cache hits on a sound basis. Really, we need soundly cacheable code URLs to carry a cryptographic hash in the URL, where the browser only considers the loaded content to be valid if its hash matches. Then, a browser can cache and reuse soundly based on hash match. https://www.tahoe-lafs.org/trac/tahoe-lafs refers to such URLs as self-authenticating designators. See also the threads rooted at http://www.eros-os.org/pipermail/e-lang/2000-January/003188.html http://www.eros-os.org/pipermail/e-lang/2000-January/003194.html and the message at http://www.eros-os.org/pipermail/e-lang/2009-April/013098.html on hashing the transitive closure on import dependencies, rather than hashing each module independently. In retrospect, I expect this further logic to be past the point of diminishing returns. But none of this has been subjected to any measurements. A political problem arises in the first step -- the browser cache. No one expects a browser to provide an affordance to remove its C++ builtins, forcing them (if there were such an option) to be
Re: Sharing a JavaScript implementation across realms
Le 13/01/2015 13:21, Anne van Kesteren a écrit : A big challenge with self-hosting is memory consumption. A JavaScript implementation is tied to a realm and therefore each realm will have its own implementation. Contrast this with a C++ implementation of the same feature that can be shared across many realms. The C++ implementation is much more efficient. Why would a JS implementation *has to* be tied to a realm? I understand if this is how things are done today, but does it need to be? Asked differently, what is so different about JS (vs C++) as an implementation language? It seems like the sharings that are possible in C++ should be possible in JS. What is (or can be) shared in C++ that cannot in JS? PS: Alternative explanation available here: https://annevankesteren.nl/2015/01/javascript-web-platform From your post : More concretely, this means that an implementation of |Array.prototype.map| in JavaScript will end up existing in each realm, whereas an identical implementation of that feature in C++ will only exists once. Why? You could have a single privileged-JS implementation and each content-JS context (~realm) would only have access to a proxy to Array.prototype.map (transparently forwarding calls, which I imagine can be optimized/inlined by engines to be the direct call in the optimistic case). It would cost a proxy per content JS, but that already much much less than a full Array.prototype.map implementation. In a hand-wavy fashion, I'd say the proxy handler can be shared across all content-JS. There is per-content storage to be created (lazily) in case Array.prototype.map is mutated (property added, etc.), but the normal case is fine (no mutation on built-ins means no cost) One drawback is trying Object.freeze(Array.prototype.map). For this to work with proxies as they are, either the privileged-JS Array.prototype.map needs to be frozen (unacceptable, of course), or each proxy needs a new target (which is equivalently bad than one Array.prototype.map implementation per content-JS context). The solution might be to allow proxies in privileged-JS contexts that are more powerful than the standard ones (for instance, they can pretend the object is frozen even when the underlying target isn't). This is a bit annoying as a suggestion, because it means JS isn't really implemented in normal JS any longer, but it sounds like a reasonable trade-off (that's open for debate, of course). The problem with proxies as they are today is that they were retroffited in JS which severely constrained their design making use cases like the one we're discussing (or even membranes) possible, but cumbersome. Privileged-JS taking some liberties from this design sounds reasonable. (It was pointed out to me that SpiderMonkey has some tricks to share the bytecode of a JavaScript implementation of a feature across realms, though not across threads (still expensive for workers). And SpiderMonkey has the ability to load these JavaScript implementations lazily and collect them when no longer used, further reducing memory footprint. However, this requires very special code that is currently not available for features outside of SpiderMonkey. Whether that is feasible might be up for investigation at some point.) For contexts running in parallel to be able to share (read-only) data in JS, we would need immutable data structures in JS, I believe. https://mail.mozilla.org/pipermail/es-discuss/2014-November/040218.html https://mail.mozilla.org/pipermail/es-discuss/2014-November/040219.html David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Sharing a JavaScript implementation across realms
Before we go tl;dr on this topic, how about some data to back up the asserted problem size? Filip gently raised the question. How much memory does a realm cost in top open source engines? Fair question, empirical and (I think) not hard to answer. Burdened malloc/GC heap full cost, not net estimate from source analysis, would be best. Cc'ing Nick, who may already know. Thanks, /be David Bruant wrote: Why would a JS implementation *has to* be tied to a realm? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Sharing a JavaScript implementation across realms
A big challenge with self-hosting is memory consumption. A JavaScript implementation is tied to a realm and therefore each realm will have its own implementation. Contrast this with a C++ implementation of the same feature that can be shared across many realms. The C++ implementation is much more efficient. If we want to get further with turning the web platform into a giant JavaScript library, we need to tackle this somehow. Has anyone been thinking about how to do this and what changes it would require from JavaScript proper? We're now at the point where we can implement platform objects in terms of JavaScript, but JavaScript loses out due to lack of efficiency. PS: Alternative explanation available here: https://annevankesteren.nl/2015/01/javascript-web-platform -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Handling error in Promises
A `promise.done()` method that throws if it receives a rejected promise has
been discussed, but the consensus seems to be that browsers instead should
report on rejected unhandled promises that are garbage collected. This is
already implemented in Firefox (at least in the DevTools edition), where
the following code will end up with an error in the console:
```js
var p = new Promise(function(){throw new Error(oh noes);})
p = null;
```
Since there is no way to handle the thrown error outside the promise (the
exception is thrown after the function returns) there isn't any reason for
the exception to travel up the stack. Either the exception must be handled
as a rejected promise or it must be handled in something like
`window.onerror`.
Marius Gundersen
On Tue, Jan 13, 2015 at 12:35 PM, Boopathi Rajaa legend.r...@gmail.com
wrote:
```
Promise
.resolve()
.then(function(){
throw new Error('asdf');
});
```
Bluebird: (errors thrown - Good)
http://jsbin.com/kahuzi/1/edit?html,js,console
native ES6:(errors not thrown)
http://jsbin.com/qivobibowa/3/edit?html,js,console
Shouldn't all Uncaught errors be thrown, instead of catching it inside the
promise only ? For example, If I use Promise within a promise, the uncaught
error in the inner Promise will never be exposed to the outside world and
there is no way to bubble it up to the outside blocks.
`.catch(function(err) { throw err; }) `
will also be caught and nothing would be thrown.
- Boopathi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Handling error in Promises
You might try reading through some of the previous threads that talk
about the trickiness of surfacing promise errors in the general case.
Unfortunately these threads usually devolve into an endless thread of
discussion and debate that become next to impossible to actually read
through later without several hours of spare time and a bottle of
whiskey... But here's a recent one that's not *too* long and kind of
talks about a couple of ideas:
https://esdiscuss.org/topic/async-await-improvements (long, but talks
about a couple potential/proposed solutions)
-Jeff
On 1/13/15 7:44 AM, Marius Gundersen wrote:
A `promise.done()` method that throws if it receives a rejected
promise has been discussed, but the consensus seems to be that
browsers instead should report on rejected unhandled promises that are
garbage collected. This is already implemented in Firefox (at least in
the DevTools edition), where the following code will end up with an
error in the console:
```js
var p = new Promise(function(){throw new Error(oh noes);})
p = null;
```
Since there is no way to handle the thrown error outside the promise
(the exception is thrown after the function returns) there isn't any
reason for the exception to travel up the stack. Either the exception
must be handled as a rejected promise or it must be handled in
something like `window.onerror`.
Marius Gundersen
On Tue, Jan 13, 2015 at 12:35 PM, Boopathi Rajaa
legend.r...@gmail.com mailto:legend.r...@gmail.com wrote:
```
Promise
.resolve()
.then(function(){
throw new Error('asdf');
});
```
Bluebird: (errors thrown - Good)
http://jsbin.com/kahuzi/1/edit?html,js,console
native ES6:(errors not thrown)
http://jsbin.com/qivobibowa/3/edit?html,js,console
Shouldn't all Uncaught errors be thrown, instead of catching it
inside the promise only ? For example, If I use Promise within a
promise, the uncaught error in the inner Promise will never be
exposed to the outside world and there is no way to bubble it up
to the outside blocks.
`.catch(function(err) { throw err; }) `
will also be caught and nothing would be thrown.
- Boopathi
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Handling error in Promises
Awhile back I did my best to summarize some of the previous es-discuss
threads on a related GitHub thread:
https://github.com/iojs/io.js/issues/11#issuecomment-65971175
Please see the immediately following comment as well for some clarification
on how Bluebird surfaces unhandled rejections.
On Tue, Jan 13, 2015 at 11:27 AM, Jeff Morrison lbljef...@gmail.com wrote:
You might try reading through some of the previous threads that talk
about the trickiness of surfacing promise errors in the general case.
Unfortunately these threads usually devolve into an endless thread of
discussion and debate that become next to impossible to actually read
through later without several hours of spare time and a bottle of
whiskey... But here's a recent one that's not *too* long and kind of talks
about a couple of ideas:
https://esdiscuss.org/topic/async-await-improvements (long, but talks
about a couple potential/proposed solutions)
-Jeff
On 1/13/15 7:44 AM, Marius Gundersen wrote:
A `promise.done()` method that throws if it receives a rejected promise
has been discussed, but the consensus seems to be that browsers instead
should report on rejected unhandled promises that are garbage collected.
This is already implemented in Firefox (at least in the DevTools edition),
where the following code will end up with an error in the console:
```js
var p = new Promise(function(){throw new Error(oh noes);})
p = null;
```
Since there is no way to handle the thrown error outside the promise (the
exception is thrown after the function returns) there isn't any reason for
the exception to travel up the stack. Either the exception must be handled
as a rejected promise or it must be handled in something like
`window.onerror`.
Marius Gundersen
On Tue, Jan 13, 2015 at 12:35 PM, Boopathi Rajaa legend.r...@gmail.com
wrote:
```
Promise
.resolve()
.then(function(){
throw new Error('asdf');
});
```
Bluebird: (errors thrown - Good)
http://jsbin.com/kahuzi/1/edit?html,js,console
native ES6:(errors not thrown)
http://jsbin.com/qivobibowa/3/edit?html,js,console
Shouldn't all Uncaught errors be thrown, instead of catching it inside
the promise only ? For example, If I use Promise within a promise, the
uncaught error in the inner Promise will never be exposed to the outside
world and there is no way to bubble it up to the outside blocks.
`.catch(function(err) { throw err; }) `
will also be caught and nothing would be thrown.
- Boopathi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing
listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Sharing a JavaScript implementation across realms
We have been trying to improve sharing in JSC for a while now. We can share bytecode between realms, but this is mostly about reducing parse time rather than space saving - the bytecode has to be linked before a realm uses it, which involves making a copy of most of the data structures. I don't think that full sharing is impossible in the current language. Turning off the link step - or eliminating the need for a full copy - is almost doable, but would have some cost for variable resolution performance in the early iterations of a function. I've been toying with sharing JIT code at the lowest JIT tier, which would have similar trade offs. Something that JSC does have going for it if we had a larger library footprint is that we interpret bytecode for the first 100 or so executions of any function. Even when we have to splat a copy of the bytecode, it still takes less memory than machine code at any level of optimization. So, I'm curious what issues you were specifically concerned about. -Filip On Jan 13, 2015, at 4:21 AM, Anne van Kesteren ann...@annevk.nl wrote: A big challenge with self-hosting is memory consumption. A JavaScript implementation is tied to a realm and therefore each realm will have its own implementation. Contrast this with a C++ implementation of the same feature that can be shared across many realms. The C++ implementation is much more efficient. If we want to get further with turning the web platform into a giant JavaScript library, we need to tackle this somehow. Has anyone been thinking about how to do this and what changes it would require from JavaScript proper? We're now at the point where we can implement platform objects in terms of JavaScript, but JavaScript loses out due to lack of efficiency. PS: Alternative explanation available here: https://annevankesteren.nl/2015/01/javascript-web-platform -- https://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
escaping - in /u RegExp
Would those of you who consider yourselves RegExp experts take a look at https://bugs.ecmascript.org/show_bug.cgi?id=3519 Is this a bug? If so, what is the fix? This construction for Identity Escape goes back to Norbert's original proposal http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/index.html Perhaps we need to add a: ClassAttom[U] :: [+U] \- production or some such to the pattern grammar. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
