Re: instanceof trap and default handler for Proxies

[Kam Kasravi]

I assume the answer is no, but can one proxy simple modules?




From: Tom Van Cutsem 
To: es-discuss 
Sent: Thu, October 28, 2010 6:02:11 AM
Subject: instanceof trap and default handler for Proxies

Hi,

I created a strawman page to host possible extensions to harmony:proxies:


It currently hosts two extensions:
- enabling proxies to trap instanceof
- standardizing the default "no-op" forwarding handler

At least the first will be on the agenda for the November TC39 meeting.

Please comment and discuss.

Cheers,
Tom___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: instanceof trap and default handler for Proxies

[Kam Kasravi]

How 'bout extending proxies to provide an introspection API?




From: Tom Van Cutsem 
To: es-discuss 
Sent: Thu, October 28, 2010 6:02:11 AM
Subject: instanceof trap and default handler for Proxies

Hi,

I created a strawman page to host possible extensions to harmony:proxies:


It currently hosts two extensions:
- enabling proxies to trap instanceof
- standardizing the default "no-op" forwarding handler

At least the first will be on the agenda for the November TC39 meeting.

Please comment and discuss.

Cheers,
Tom___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Concerns about weak refs and weak maps.

[Brendan Eich]

On Oct 29, 2010, at 4:01 PM, felix wrote:

> On 10/29/10 15:18, Jim Deville wrote:
>> C# 4.0 has WeakMap's too, and one of the goals was to work around the 
>> cyclical reference issue:
>> 
>> http://blogs.msdn.com/b/clrteam/archive/2009/05/18/the-conditional-weak-table-enabling-dynamic-object-properties.aspx
> 
> mono implements ConditionalWeakTable with Ephemeron tables registered with 
> the GC.  The registration does nothing with boehm-gc, but there is special 
> handling for Ephemerons in the experimental sgen-gc, and it looks to me like 
> it's similar to what's described on the ECMAScript wiki for WeakMap: 
> repeatedly scan Ephemeron key,value entries for values that are newly 
> reachable, until no more newly-reachable values are found.
> 
> http://github.com/mono/mono/blob/09ae7f243df64f6928ffcd89eb44ac1f688c689e/mono/metadata/sgen-gc.c
> 
> it's instrumented to count how many times it repeats the Ephemeron scan, so 
> it probably wouldn't be too hard to get practical data on how expensive it is 
> in real usage.


We have a patch in progress for SpiderMonkey, in this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=547941

It won't be in Firefox 4.

Instrumentation is easy, the hard part (as ever) is workload selection. That 
would be good to build up, in advance of implementations.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Concerns about weak refs and weak maps.

[felix]

On 10/29/10 15:18, Jim Deville wrote:

C# 4.0 has WeakMap's too, and one of the goals was to work around the cyclical 
reference issue:

http://blogs.msdn.com/b/clrteam/archive/2009/05/18/the-conditional-weak-table-enabling-dynamic-object-properties.aspx


mono implements ConditionalWeakTable with Ephemeron tables registered 
with the GC.  The registration does nothing with boehm-gc, but there is 
special handling for Ephemerons in the experimental sgen-gc, and it 
looks to me like it's similar to what's described on the ECMAScript wiki 
for WeakMap: repeatedly scan Ephemeron key,value entries for values that 
are newly reachable, until no more newly-reachable values are found.


http://github.com/mono/mono/blob/09ae7f243df64f6928ffcd89eb44ac1f688c689e/mono/metadata/sgen-gc.c

it's instrumented to count how many times it repeats the Ephemeron scan, 
so it probably wouldn't be too hard to get practical data on how 
expensive it is in real usage.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Concerns about weak refs and weak maps.

[Jim Deville]

C# 4.0 has WeakMap's too, and one of the goals was to work around the cyclical 
reference issue:

http://blogs.msdn.com/b/clrteam/archive/2009/05/18/the-conditional-weak-table-enabling-dynamic-object-properties.aspx



-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On 
Behalf Of Allen Wirfs-Brock
Sent: Friday, October 29, 2010 3:04 PM
To: Allen Wirfs-Brock; felix; Brendan Eich
Cc: Andreas Gal; es-discuss
Subject: RE: Concerns about weak refs and weak maps.

Oops, typo fixed  below

> -Original Message-
> From: es-discuss-boun...@mozilla.org [mailto:es-discuss- 
> boun...@mozilla.org] On Behalf Of Allen Wirfs-Brock
> Sent: Friday, October 29, 2010 12:24 PM
> To: felix; Brendan Eich
> Cc: Andreas Gal; es-discuss
> Subject: RE: Concerns about weak refs and weak maps.
> 
> > -Original Message-
> > From: es-discuss-boun...@mozilla.org [mailto:es-discuss- 
> > boun...@mozilla.org] On Behalf Of felix
> > Sent: Friday, October 29, 2010 12:18 PM
> > To: Brendan Eich
> ...
> > >
> > > Yet don't Java and .NET have weak-keyed maps of some sort?
> >
> > Java has WeakHashMap, which is a map of weak references to values, 
> > which can leak uncollectible garbage if you have a cycle of 
> > WeakHashMap entries holding references to objects that are not 
> > otherwise
> referenced.
 
Which is the problem addressed by the proposed ephemeron-like Weak Map solution 
for ECMAScript

___
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: Concerns about weak refs and weak maps.

[Allen Wirfs-Brock]

Oops, typo fixed  below

> -Original Message-
> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
> boun...@mozilla.org] On Behalf Of Allen Wirfs-Brock
> Sent: Friday, October 29, 2010 12:24 PM
> To: felix; Brendan Eich
> Cc: Andreas Gal; es-discuss
> Subject: RE: Concerns about weak refs and weak maps.
> 
> > -Original Message-
> > From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
> > boun...@mozilla.org] On Behalf Of felix
> > Sent: Friday, October 29, 2010 12:18 PM
> > To: Brendan Eich
> ...
> > >
> > > Yet don't Java and .NET have weak-keyed maps of some sort?
> >
> > Java has WeakHashMap, which is a map of weak references to values,
> > which can leak uncollectible garbage if you have a cycle of
> > WeakHashMap entries holding references to objects that are not otherwise
> referenced.
 
Which is the problem addressed by the proposed ephemeron-like Weak Map solution 
for ECMAScript

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Concerns about weak refs and weak maps.

[Allen Wirfs-Brock]

> -Original Message-
> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
> boun...@mozilla.org] On Behalf Of felix
> Sent: Friday, October 29, 2010 12:18 PM
> To: Brendan Eich
...
> >
> > Yet don't Java and .NET have weak-keyed maps of some sort?
> 
> Java has WeakHashMap, which is a map of weak references to values, which
> can leak uncollectible garbage if you have a cycle of WeakHashMap entries
> holding references to objects that are not otherwise referenced.

While is the problem addressed by the proposed ephemeron-like Weak Map solution 
for ECMAScript 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Concerns about weak refs and weak maps.

[felix]

On 10/29/10 10:51, Brendan Eich wrote:

On Oct 29, 2010, at 12:08 AM, Erik Corry wrote:


Let's be careful not to add things to the language that will limit
implementations from getting the sorts of modern GC implementations
that Java and .NET have.



Yet don't Java and .NET have weak-keyed maps of some sort?


Java has WeakHashMap, which is a map of weak references to values, which 
can leak uncollectible garbage if you have a cycle of WeakHashMap 
entries holding references to objects that are not otherwise referenced.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Concerns about weak refs and weak maps.

[Brendan Eich]

On Oct 29, 2010, at 12:08 AM, Erik Corry wrote:

> Let's be careful not to add things to the language that will limit
> implementations from getting the sorts of modern GC implementations
> that Java and .NET have.


Yet don't Java and .NET have weak-keyed maps of some sort?

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Concerns about weak refs and weak maps.

[Brendan Eich]

On Oct 29, 2010, at 3:57 AM, Erik Corry wrote:

> 2010/10/29 Brendan Eich :
>> On Oct 29, 2010, at 12:08 AM, Erik Corry wrote:
>> 
>>> One of the hallmarks of a real language implementation vs. a 'toy
>>> scripting language' ala PHP is a good GC.  I'd really like to see
>>> someone do a low-latency GC with weak maps before we hobble the
>>> language with something that can't be implemented efficiently.

Complex problems don't go away by renouncing any "in language" solution. The 
complexity moves to the pure-JS level and whatever solution can be hacked 
there, which then has to be downloaded, and which has bad performance or 
memory-leak hazards. This then tends to produce non-standard native 
implementations in various engines. Just noting this, more below.


>> Any chance you guys will implement the WeakMap proposal?
> 
> I can't see Google's V8 team doing that, but anyone can take V8 and do
> experiments on their branch of it.

Cool, maybe we can find a volunteer. Google has projects using JS to manage 
objects, where I believe in at least one case (Caja), WeakMaps would be a 
significant win. Such use-cases are not unique to Google, they're common in JS 
libraries and virtualization schemes. But my first thought is to scour Google 
for people who need WeakMaps and who could implement an experimental patch for 
V8.

As people have noted in this thread, you can't really make up for the lack of 
WeakMaps in JS currently without falling into O(n^2) complexity traps (arrays 
of objects, linear search). The strong references in such maps make for 
guaranteed memory leaks. If there's another alternative that lacks both GC 
complexity and user-facing leak and performance issues, we are all ears. Doing 
nothing is likely to bid forth extensions in browser JS implementations, which 
may lead to de-facto standardization.

We can keep experimenting with WeakMaps, but if we don't have an understanding 
of why demand for something like them exists and is likely to create a standard 
of some sort, we won't have a fruitful discussion, and we probably won't serve 
JS users well.

Renouncing WeakMaps certainly would keep GC implementations, e.g., in V8, 
simpler, but that's too narrow a point of view for Ecma TC39. And if Apple and 
other vendors do implement some kind of weak map, market pressure may force V8 
to follow. This is not the "Harmony" way to proceed, since it tends to make 
more non-interoperation and developer pain in the market, and take longer.

Nevertheless, it sounds like we should reconsider the move of WeakMaps into 
"harmony" status (http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps) 
based on your feedback, moreso than Rick's due to your representing the V8 
team. We can move the proposal back to strawman status, pending more results of 
experiments (plural, so we need help; SpiderMonkey is not enough). Is this your 
intention?

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Usage for weak-maps

[Bradley Meck]

I have used them in two ways in practical application.

A rather odd but quite interesting use case is short lived caches. Consider
a recursive static function such as the Fibonacci sequence. You could hold a
cache of the previous computations and allow them to be collected at the
GC's leisure.

Another use case is the ability to prevent memory leaks in situations where
you need to maintain a list of all the instances of an object to create
"class based" storage for Javascript Objects (generally through a
constructor).

Cheers,
Bradley

On Fri, Oct 29, 2010 at 10:33 AM, P T Withington  wrote:

> On 2010-10-29, at 04:50, Peter van der Zee wrote:
>
> > What's the use case for weak maps? What would you do with it that
> currently
> > impossible and why is the workaround (if any) problematic enough to
> warrant
> > a weak map implementation?
>
> Another use case was mentioned in the "New topic regarding Proxies:
> intercession for ===" thread.  If you want to write a value type, the
> constructor needs to return the same object for identical parameters for ===
> to work, which means it needs a table of all the objects it has ever made,
> but it doesn't need (or want) to hang on to objects that are no longer in
> use.  [The alternative being discussed in the proxy thread is to be able to
> customize === to give the same illusion.]
> ___
> 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: Usage for weak-maps

[Allen Wirfs-Brock]

Weak maps are used to create an association (based upon object identity)  
between an object (the key) and some arbitrary information.  They are necessary 
if you need to maintain such an association and you cannot modify the key 
object to directly record the association. 

Without some sort of weak reference mechanism, the data structure needed to 
maintain such an associations is inherently leaky because the use of an object 
as a key creates a reference to the object that prevents its and its associated 
value from being garbage collected even if the key reference is becomes the 
sole reference.

There are many use cases for such object identify based maps.  A basic one is a 
memoizing cache.  Assume that there is some expensive computation (for example 
a database access) based upon some object  and you want to memoize  the result 
of the computation. A weak map can be used for that purpose without create a 
memory leak.

Allen 


> -Original Message-
> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
> boun...@mozilla.org] On Behalf Of P T Withington
> Sent: Friday, October 29, 2010 8:34 AM
> To: Peter van der Zee
> Cc: es-discuss
> Subject: Re: Usage for weak-maps
> 
> On 2010-10-29, at 04:50, Peter van der Zee wrote:
> 
> > What's the use case for weak maps? What would you do with it that
> > currently impossible and why is the workaround (if any) problematic
> > enough to warrant a weak map implementation?
> 
> Another use case was mentioned in the "New topic regarding Proxies:
> intercession for ===" thread.  If you want to write a value type, the 
> constructor
> needs to return the same object for identical parameters for === to work, 
> which
> means it needs a table of all the objects it has ever made, but it doesn't 
> need (or
> want) to hang on to objects that are no longer in use.  [The alternative being
> discussed in the proxy thread is to be able to customize === to give the same
> illusion.] ___
> 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: Concerns about weak refs and weak maps.

[P T Withington]

On 2010-10-28, at 17:10, Hudson, Rick wrote:

> GC implementation
> Software stacks on multicores will need GCs to become increasingly concurrent 
> and latency free. Weak maps cause concurrent GCs and additional mutator 
> synchronizations.  While a concurrent GC already has to do some 
> synchronization, each additional synchronization point impedes scalability. 
> My concern is that the number of synchronization points might be proportional 
> to the number of  pairs in the weak maps (see below).

This is old information, but perhaps relevant.  Basically handling weak 
references in a standard hardware by emulating what a Lisp Machine would have 
done  [From http://bit.ly/b4xidb]

[...]

AWL has another special power: it enables better handing of barrier hits on 
weak objects. To explain the benefit we need to describe a problem first. The 
MPS uses a read-barrier to perform incremental garbage collection [@@ link to 
canned-for-client explanation of how a garbage collector works in broad terms]. 
When the client tries to read an object containing weak references the MPS may 
have protected it so that the MPS can process the object before the client gets 
to see it. The problem for weak objects is that the client may try and access 
the object at a point in the collection cycle when the MPS cannot yet determine 
the status of the objects that the weak object refers to. What the MPS does in 
this situation is assume that all the referenced objects are going to live. 
This assumption is correct but conservative; it may result in objects that are 
weakly referenced staying alive for longer than they need to. In the worst case 
this can result in a very large amount of memor
 y being used by objects that are no longer needed.

In order to combat this problem the MPS sometimes does the following: Instead 
of processing the entire weak object and unprotecting it so that the client can 
access the object the MPS may emulate the processor instruction. When this 
happens the MPS doesn't process the entire weak object, it only processes the 
exact location that was being accessed (typically a single word), it emulates 
the processor instruction, and it keeps the object protected. This happens 
invisibly from the client's perspective, it's exactly as if the instruction 
executed as normal. The MPS instead of processing the entire object processes 
just a single word.

[...]


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Concerns about weak refs and weak maps.

[Allen Wirfs-Brock]

Rick and Erik,

I share your concerns about the importance of efficient GC for JavaScript.  
However, based upon direct experience, I'm not particularly concerned about the 
impact of Weak maps.  The ES Harmony Weak Maps is derived from the Ephemeron 
concept first developed at Digitalk.  We first implemented them in the 
production GC for Visual Smalltalk and later in ParcPlace-Digitalk (now Cincom) 
VisualWorks Smalltalk.  These were both high performance, low latency, 
accurate, moving,  multi-generational collectors that have now been in 
production use for over 15 years.  In general, Smalltalk application seem to be 
are much more demanding upon a GC then most modern JavaScript applications (and 
correspondingly, my perceptions is that JavaSript GCs have not yet reached the 
sophistication and throughput levels that were typical of Smalltalk GCs).

While the above Smalltalk GCs are multi-generational, neither utilized any 
parallelism.  They clearly demonstrate that parallelism is not necessary to 
achieve low pause times in highly interactive GC'ed systems. Regardless, modern 
collectors exploiting parallelism exist for both Java and .Net that support 
various weak pointer abstractions.  I'm comfortable that they provide a 
sufficient existence proof for efficient parallel collectors supporting weak 
reference semantics.

It is unfortunate, that the use of WeakMaps/Weak pointers/Ephemerons do impose 
some overhead that is proportional to their  use. But the use of weak 
abstractions generally shows up in non-ephemeral use cases so this really isn't 
a problem. Still, they are a feature that shouldn't be used unnecessarily. 
However, when they are necessary, there really isn't any other good alternative.

I agree that current JavaScript GCs have a lot of issues that  derive from 
interactions with C/C++ based DOMs.  I think the long term solution is to 
allocate those objects in the JavaScript GC'ed heap.  My slogan from a recent 
talk (http://bit.ly/ahiGS1 ): "Build a great GC and then use it everywhere".

Allen


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Usage for weak-maps

[P T Withington]

On 2010-10-29, at 04:50, Peter van der Zee wrote:

> What's the use case for weak maps? What would you do with it that currently
> impossible and why is the workaround (if any) problematic enough to warrant
> a weak map implementation?

Another use case was mentioned in the "New topic regarding Proxies: 
intercession for ===" thread.  If you want to write a value type, the 
constructor needs to return the same object for identical parameters for === to 
work, which means it needs a table of all the objects it has ever made, but it 
doesn't need (or want) to hang on to objects that are no longer in use.  [The 
alternative being discussed in the proxy thread is to be able to customize === 
to give the same illusion.]
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Usage for weak-maps

[Boris Zbarsky]

On 10/29/10 4:50 AM, Peter van der Zee wrote:

What's the use case for weak maps? What would you do with it that
currently impossible and why is the workaround (if any) problematic
enough to warrant a weak map implementation?


One case this came up recently was for Firebug,  Firebug wants to cache 
information about DOM Windows (the set of scripts compiled for that 
window, etc) and map from a Window to the information, but it obviously 
doesn't want to change the state of the Windows by adding properties, 
nor does it want to leak every single Window object.


There is no in-language workaround for this use case; we solved it in 
Gecko by adding special out-of-band API that assigns a numeric ID to 
each window and exposes that ID on an object that is not the window 
itself and which content doesn't have access to, so that Firebug can use 
the IDs as the keys in its map.


The use case generalizes, of course, to any situation where you want to 
store information for/about objects without sticking it on the object 
itself.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Concerns about weak refs and weak maps.

[Erik Corry]

2010/10/29 Brendan Eich :
> On Oct 29, 2010, at 12:08 AM, Erik Corry wrote:
>
>> One of the hallmarks of a real language implementation vs. a 'toy
>> scripting language' ala PHP is a good GC.  I'd really like to see
>> someone do a low-latency GC with weak maps before we hobble the
>> language with something that can't be implemented efficiently.
>
> Any chance you guys will implement the WeakMap proposal?

I can't see Google's V8 team doing that, but anyone can take V8 and do
experiments on their branch of it.

>> By modern I mean generational and either parallel or concurrent.
>
> Parallel vs. concurrent GC is a good distinction to bring up. We're 
> interested in parallel GC too, and we have a WeakMap prototype under way, so 
> we'll have to report back in due course.
>
> Still, it seems premature to rule WeakMaps out right now. Rather than 
> strangle them in the cradle, I hope several browser-based engines can 
> implement and see what we find out. The use-cases in the language remain 
> pretty compelling, without a good fallback strategy (leaky strong maps? No 
> object reference keyed maps at all?).
>
> Concurrent is a different animal from parallel, and I remain skeptical about 
> JS implementations  deviating significantly from shared-nothing concurrency, 
> even as the JS embeddings use threads under the hood to utilize more cores.
>
> /be
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Usage for weak-maps

[Peter van der Zee]

What's the use case for weak maps? What would you do with it that currently
impossible and why is the workaround (if any) problematic enough to warrant
a weak map implementation?

There's been quite a bit of discussion because of it. Especially in the area
of covert channels and garbage collection. Yet I've missed the major cases
for wanting it in the language in the first place. Google doesn't seem to
help me much here.

I don't need an in depth explanation of what weak maps are, just practical
reasons for wanting it opposed to what's already possible... thanks :)

- peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Concerns about weak refs and weak maps.

[Brendan Eich]

On Oct 29, 2010, at 12:08 AM, Erik Corry wrote:

> One of the hallmarks of a real language implementation vs. a 'toy
> scripting language' ala PHP is a good GC.  I'd really like to see
> someone do a low-latency GC with weak maps before we hobble the
> language with something that can't be implemented efficiently.

Any chance you guys will implement the WeakMap proposal?


> By modern I mean generational and either parallel or concurrent.

Parallel vs. concurrent GC is a good distinction to bring up. We're interested 
in parallel GC too, and we have a WeakMap prototype under way, so we'll have to 
report back in due course.

Still, it seems premature to rule WeakMaps out right now. Rather than strangle 
them in the cradle, I hope several browser-based engines can implement and see 
what we find out. The use-cases in the language remain pretty compelling, 
without a good fallback strategy (leaky strong maps? No object reference keyed 
maps at all?).

Concurrent is a different animal from parallel, and I remain skeptical about JS 
implementations  deviating significantly from shared-nothing concurrency, even 
as the JS embeddings use threads under the hood to utilize more cores.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Concerns about weak refs and weak maps.

[Erik Corry]

I share Rick's worry about weak maps.  It's not clear how to make an
efficient GC in the presence of weak maps.

As Brendan rightly points out there is already a lot of complexity in
the GC of a typical JS implementation because it is interacting with
the (typically) reference counted, C++ based DOM.  Adding complexity
in the form of a new weak reference model looks like it could limit JS
implementations severely down the road.

One of the hallmarks of a real language implementation vs. a 'toy
scripting language' ala PHP is a good GC.  I'd really like to see
someone do a low-latency GC with weak maps before we hobble the
language with something that can't be implemented efficiently.  By
modern I mean generational and either parallel or concurrent.  (In a
parallel GC there are several threads doing GC in parallel while the
actual JS program is stopped.  In a concurrent GC there is one or more
threads doing GC while the JS program is still making progress).

It is true that the language is not multithreaded and never will be.
This does not limit the implementation from making use of several
threads/CPUs when doing garbage collection.  We actually have a V8
prototype that has a parallel GC
http://codereview.chromium.org/3615009/show though probably it won't
be landed in its current form.  We will likely be investigating a
slightly different approach.  But in principle this is quite possible:
 a single threaded JS implementation where part of the runtime is
multithreaded.

Just for clarity, since Brendan brought up the limitations of the V8
GC:  At the moment the V8 GC is accurate (not conservative), moving
(resistent to fragmentation) and generational (most pauses are small).
 But there is plenty of room for improvement in terms of very large
heaps, worst-case pause times and making use of multiple CPUs.

Let's be careful not to add things to the language that will limit
implementations from getting the sorts of modern GC implementations
that Java and .NET have.

-- 
Erik Corry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss