| 17:44 | <bradleymeck> | targos per https://github.com/nodejs/node/pull/32202 , make test with `--without-intl` seems to fail to build at all for me locally due to eslint wanting to use the non-intl form how are you running your build/test |
| 21:39 | <jorendorff> | does anyone have the graph of edges in the builtins, maybe as a dot file? |
| 21:40 | <ljharb> | edges? |
| 21:40 | <ljharb> | what constitutes a node and a line between them in your graph |
| 21:41 | <jorendorff> | a node is an object, let's say, and an edge is (informally speaking) a gc-strong reference. |
| 21:41 | <jorendorff> | more formally, if x.[[Prototype]] is y, then there's an edge x -> y; if x has a property whose value, getter, or setter is y, then x -> y; and so on |
| 21:42 | <ljharb> | so like, you want to know which builtins strongly point to which others (initially), and which builtins internally reference intrinsics? |
| 21:43 | <devsnek> | jorendorff: you can probably generate that |
| 21:44 | <jorendorff> | hmmm. do builtins effectively reference their realm's intrinsics? I don't remember how the spec works w.r.t. things like calling a function across realms |
| 21:44 | <devsnek> | do you mean well known intrinsics? |
| 21:44 | <devsnek> | well known intrinsics are strongly referenced by the realm itself |
| 21:45 | <jorendorff> | In any case I am happy to do without references from builtins to intrinsics due to their algorithms |
| 21:45 | <devsnek> | https://gist.github.com/devsnek/377e4a52d83e786613997af82710d4db |
| 21:45 | <devsnek> | this is from a bit of test code i have but it walks over everything accessible from `globalThis` |
| 21:46 | <ljharb> | jorendorff: i mean, in that case it's just an object property graph, yes? |
| 21:47 | <jorendorff> | ljharb: I don't know. |
| 21:47 | <devsnek> | anything they reference with %ThisNotation% is strongly referenced by the realm |
| 21:47 | <jorendorff> | at least should cover [[Prototype]] which isn't a property |
| 21:47 | <devsnek> | hm i should add [[Prototype]] to my walker |
| 21:48 | <ljharb> | jorendorff: `__proto__` is, but sure. what's the goal? |
| 21:48 | <jorendorff> | I want to know if it is possible to find cycles (that are not .constructor/.prototype cycles) |
| 21:51 | <jorendorff> | I want to know if there are any other than the ones that look like |
| 21:51 | <jorendorff> | m ---> %FunctionPrototype% ---> %ObjectPrototype% ----> m |
| 21:51 | <jorendorff> | where m is some nonstatic method of Object |
| 21:53 | <ljharb> | it's not just methods, `Number.MAX_VALUE.constructor.MAX_VALUE` |
| 21:54 | <ljharb> | `String.constructor.name.constructor.name`, etc |
| 21:54 | <jorendorff> | those aren't cycles in the graph I'm asking for... |
| 21:54 | <ljharb> | ok so you don't want constructor/prototype but you do want [[Prototype]]? |
| 21:55 | <jorendorff> | I can write code that walks this graph, and notices, constructor/prototype cycles, and disregards them |
| 21:55 | <jorendorff> | it's ok for the graph to have those |
| 21:56 | <devsnek> | now that i think about it |
| 21:56 | <devsnek> | engine262's gc might be useful since it sees all the internal properties |
| 21:56 | <devsnek> | and its easy to modify |
| 21:56 | <jorendorff> | the property of cycles i'm interested in here |
| 21:56 | <jorendorff> | is that an implementation that populates the builtins lazily |
| 21:57 | <jorendorff> | needs a strategy for these |
| 21:57 | <jorendorff> | it could atomically fill in one strongly connected component at a time, without issues; |
| 21:57 | <jorendorff> | or try to replace some edges with tripwires that trigger more lazy initialization; |
| 21:57 | <devsnek> | does anything actually do that? |
| 21:57 | <jorendorff> | etc. etc. |
| 21:58 | <jorendorff> | SpiderMonkey does, and actually ... surely all the browsers do for the HTML builtins, because that namespace, woof |
| 21:58 | <devsnek> | wasn't there a proposal to whatwg or smth about making it easier for engines to lazily load things and the engines basically said "that doesn't matter" |
| 21:58 | <rkirsling> | JSC has lazy-loading of builtins but I don't believe it's done in a tiered fashion per se |
| 21:59 | <rkirsling> | oh I wasn't even thinking about stuff above 262; definitely necessary there |
| 22:00 | <devsnek> | actually what is meant by lazy loading builtins |
| 22:00 | <jorendorff> | ...indeed :) |
| 22:00 | <devsnek> | like lazily creating the actual heap objects? |
| 22:00 | <jorendorff> | yes |
| 22:01 | <devsnek> | and engines do that instead of just serializing precreated heaps? |
| 22:01 | <jorendorff> | "just" |
| 22:02 | <jorendorff> | yeah, apparently |
| 22:02 | <devsnek> | interesting |
| 22:03 | <jorendorff> | total memory usage for a fully populated global is no joke either |
| 22:04 | <rkirsling> | https://github.com/WebKit/webkit/blob/master/Source/JavaScriptCore/runtime/JSGlobalObject.cpp#L924 |
| 22:05 | <ljharb> | … fun how all commonly used polyfill systems end up fully enumerating the global object |
| 22:06 | <devsnek> | lol |
| 22:06 | <ljharb> | as a result, i wonder what percentage of sites would actually benefit from lazy loading |
| 22:06 | <ljharb> | (without some kind of heuristic around the detection mechanisms, at least) |
| 22:06 | <Bakkot> | presumably those sites don't actually care much about performance |
| 22:06 | <devsnek> | i wish i could find this issue |
| 22:06 | <jorendorff> | that's a really good point |
| 22:06 | <ljharb> | i wouldn't say they don't care |
| 22:07 | <ljharb> | i'd say correctness trumps perf |
| 22:07 | <Bakkot> | easy to be correct without doing that; just don't use things which need polyfilling |
| 22:07 | <devsnek> | porque no los dos a la v8's heap snapshots |
| 22:07 | <ljharb> | lol |
| 22:07 | <Bakkot> | I am kind of joking but kind of not; that's what my team does, and we support back to ie9 |
| 22:08 | <ljharb> | yes but that's only doable for very targeted use cases with devs that have very niche knowledge |
| 22:08 | <ljharb> | it's not practical for the vast majority |
| 22:08 | <Bakkot> | depends how much you care about performance |
| 22:09 | <devsnek> | going by how the web performs |
| 22:09 | <Bakkot> | though I dunno, it's not that hard |
| 22:09 | <devsnek> | i'd say most people don't |
| 22:09 | <Bakkot> | right, yes |
| 22:11 | <rkirsling> | agree with Bakkot's perspective; there's a lot you can do with transforms without needing full polyfills |
| 22:12 | <ljharb> | rkirsling: not for instance methods, without types |
| 22:12 | <ljharb> | also there's tons of random brokenness in various versions of shipped builtins that requires repairing |
| 22:12 | <ljharb> | ie, it's not just about missing things |
| 22:12 | <devsnek> | just use jquery |
| 22:30 | <rkirsling> | but if you're gonna polyfill S.p.matchAll you're not gonna be instantiating anything you wouldn't otherwise |
| 22:31 | <rkirsling> | and I'm not sure why an app wouldn't have to be aware of "brokenness" |
| 22:31 | <rkirsling> | in the browsers it supports |
| 22:32 | <rkirsling> | hence I think if you're aiming for perf, you're not gonna be polyfilling in an unconsciously broad way |