Look, every cache has a policy that says what objects get cached and when cache entries are expired. The problem to be solved, I guess, is that people dislike implementing policies. It's boring code. They want an easy default. But GC is the *worst* default.
-
Show this thread
-
Instead, a cache should estimate the cost of keeping stuff cached, and the likelihood of ever using it again, and periodically drop the lowest-value stuff. The estimate doesn’t have to be good; almost anything will be better than WeakRef.
1 reply 0 retweets 7 likesShow this thread -
Now: you can combine estimating functions with weak refs, producing a hybrid cache that expires entries mainly based on estimated value, but can bring them back if you happen to expire an entry but then need it before GC runs.
1 reply 0 retweets 2 likesShow this thread -
This is the actual theoretically valuable use case for WeakRefs. Raising cache entries from the dead when you thought they weren’t worth keeping, but you were wrong. This feature is supposedly SO important that it’s worth swallowing any amount of poison to get it.
2 replies 0 retweets 6 likesShow this thread -
Incidentally, the first example, in the proposal rationale, of WeakRefs in action, has a deliberate bug, to illustrate a common WeakRef pitfall—it has a memory leak (again,
for honesty and teaching technique)pic.twitter.com/b1xls7VzDu
1 reply 0 retweets 6 likesShow this thread -
The fixed version has to sidestep two more pitfalls. (It still isn’t as good as a native weak-valued map: it keeps keys around for an extra GC cycle after the values are GC’d. This is inherent in the design of finalizer groups. I don’t think it can be fixed.)pic.twitter.com/FnGPAUXrTj
2 replies 0 retweets 4 likesShow this thread -
Are there other use cases? People sometimes ask for weak listeners. These are also error prone. The picture below shows how weak listeners can literally fall apart if you chain them. Building blocks that can’t even stack.pic.twitter.com/XHQhxaEN5i
2 replies 0 retweets 2 likesShow this thread -
WeakRefs are not just hard to debug. They’re genuinely hard to reason about, to avoid creating unfixable bugs in the first place. You have to understand the heap graph, something that’s not even mentioned in the language spec.
1 reply 0 retweets 5 likesShow this thread -
This is also why some of the best minds working in web standards today have had a hard time writing a specification that says what a WeakRef does.pic.twitter.com/xqNd4AA3FH
1 reply 0 retweets 4 likesShow this thread -
People struggle to come up with use cases for WeakRefs! The
@v8js blog post announcing the feature just used the example cache code from the proposal, touched up a bit for readability. I don’t want to drag these guys too hard, they’re awesome, but lol that’s kinda lame :D :Dpic.twitter.com/KI8VhyTNmh
2 replies 0 retweets 7 likesShow this thread
I guess you didn’t check the history of the proposal’s README? @_gsathya and I wrote both the proposal README (first) and then also the http://v8.dev explainer. What’s “lame” about writing documentation and adapting it to different audiences?
-
-
No, I knew you wrote the readme. Did not know that
@_gsathya coauthored. Please don't be offended—the readme is a very, very good document, and I only meant to rib y'all a little about the unadvertised reuse.1 reply 0 retweets 0 likes -
Replying to @jorendorff @mathias and
...I guess I still feel like that's slightly funny? i dunno—sorry if I'm out of line here. in my defense I did note that you are awesome, which i felt was an important point
0 replies 0 retweets 0 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.