[reordering]
Allen wrote:
We can understand the value of providing a clear method without talking about
GC at all.
I don't doubt there is a case to clear a data structure, but it can be
filled with clearless weakmaps. What I'm trying to find is a
differentiating factor. I agree that:
* clearable and clear-less weakmaps both have a use. Which is dominant
for developers has yet to be determined and only tastes and feelings
have been provided so far (including by myself).
* clearable weakmaps and clear-less weakmap can be symmetrically and at
close to no cost implemented on top of one another.
Until evidence (from other languages?) is provided that one case matters
more, I personally call this a tie. That's where my reflection is at.
I think a major remaining point is performance. If clear-less weakmaps
induce an incompressible significant GC cost, then, that is a valid
justification to have native .clear.
Now, implementors will have to deal with programs where some long-lived
weakmaps aren't manually cleared, the interesting question here is: how
far can they go to reduce the GC cost (without requiring a major
breakthrough in GC research of course ;-) )?
If the cost can be reduced to a marginal difference with manual .clear,
I call the performance argument a tie too (leaving the debate to a
taste/feeling debate)
Le 23/01/2013 00:36, Allen Wirfs-Brock a écrit :
On Jan 22, 2013, at 2:35 PM, David Bruant wrote:
So, to find out if a weakmap is dead, it has to come from another source than
the mark-and-sweep algorithm (since it losts its precision)...
Given the additional prohibitive cost weakmaps seem to have on the GC, maybe
things that would otherwise be considered too costly could make sense to be
applied specifically to WeakMaps. For instance, would the cost of
reference-counting only weakmaps be worth the benefit from knowing early that
the weakmap is dead? (I have no idea how much each costs, so it's hard for me
to compare the costs)
For WeakMapWithClear, reference counting would declare the weakmap dead as soon
as the new weakmap is assigned to the private property so that's good. It
wouldn't work if some weakmaps are part of a cycle of course... but maybe that
it's such an edge case that it's acceptable to ask users doing that to break
their weakmaps cycle manually if they don't want the GC not to be too mad at
them.
You know, as much as Jason and I enjoy talking about garbage collectors, this
probably isn't the place to revisit the last 40 years of a highly developed
area of specialized CS technology.
Even if there is a .clear method, it doesn't mean people will use it, so
the costs weakmaps induce on GC will have to be taken care of even if
people don't manually clear the weakmap [forking the thread for this
reason]. JS engine implementors will have to solve this problem
regardless of the introduction of a .clear method or not. Since JS
engines start having generational GC and WeakMaps, I feel here and now
might be a very good place and time to revisit these 40 years. Each
implementor will have to do this revisit anyway.
If anything, this thread may become a good resource for developers to
understand why some of their programs using WeakMaps have conjecturally
or inherently bad GC characteristics.
Of all points in this thread, the one that got stuck in my head is when
Jason said: "In our current implementation, creating a new WeakMap and
dropping the old one is very nearly equivalent in performance to clear()."
What this means is that something is lost when moving to a naive
generational GC regarding WeakMaps. The loss is the knowledge of when
exactly a weakmap is dead. And this loss has a cost related to weakmap
GC cost. Although Mark showed a linear algorithm, one can still wonder
if in practice this algorithm induce a significant cost (the worst-case
complexity doesn't say much about the most-frequent-case cost of an
algorithm).
What I'm trying to find out is whether there is a small-cost
weakmap-specific tracking system that could tell the GC that a weakmap
is dead as soon as possible. First and foremost, what did the research
find in these 40 years on this specific question?
Did it prove that any tracking system doing what I describe would cost
so much that it wouldn't save on what it's supposed to? If so, I'll be
happy to read the paper(s) and give up on the topic. I assume it's not
the case to continue.
Ideally, the tracking system would have the following properties:
* it costs nothing (or a small startup constant) if there is no weakmap
* the overall cost of the tracking system in normal cases is
significantly less than what it costs to have a weakmap falsely assumed
alive.
I say "in normal cases" because that's what modern GCs are already in
the business of. Generational GC is an optimistic optimization based on
the *observation* that in most real-life programs, most objects are
short-lived. It's possible to craft a pathological program where the
performance of the generational GC will be worse than the performance of
a non-generational GC (keep all objects alive and then, the generational
GC will spend most its time marking and moving objects from generation
to generation)
I've suggested weakmap-only reference counting and maybe it fulfills the
properties, maybe not. Other ideas welcome whether from 40 years of
previous research or creative people reading this message.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
