// We play this game because we want this to be callable even from places that
// don't have access to CallFrame\* or the VM, and we only allocate so little
// memory here that it's not necessary to trigger a GC - just accounting what
// we have done is good enough. The sort of bizarre exception to the "allocating
// little memory" is when we transfer a backing buffer into the C heap; this
// will temporarily get counted towards heap footprint (incorrectly, in the case
// of adopting an oversize typed array) but we don't GC here anyway. That's
// almost certainly fine. The worst case is if you created a ton of fast typed
// arrays, and did nothing but caused all of them to slow down and waste memory.
// In that case, your memory footprint will double before the GC realizes what's
// up. But if you do *anything* to trigger a GC watermark check, it will know
// that you *had* done those allocations and it will GC appropriately.
Kind of interesting, really. The method is clearly somewhat sarcastically named but usefully so: they know what they're doing is not optimal but still do it anyway for the reasons outlined. It's not like this is laziness or nefariousness.
That comment is not the reason for the function’s existence, but the details of how the function interacts with GC.
The reason for the function’s existence is that it allows typed arrays to dynamically switch between a fast/compact representation for the case that the JSVM owns the data, and a slightly slower and slightly less compact version for when the JSVM allows native code to share ownership of the data.
This function, slowDownAndWasteMemory, switches to the less efficient version that allows aliasing with native code.
Of course the name is sarcastic. The actual effect of having this is that JSC can handle both the owned case and the aliased case, and get a small will if you’re in the owned case while being able to switch to the aliased case at any time. Since there’s no way to support the aliased case without some slightly higher memory/time usage, we are sort of literally slowing down and wasting memory when we go aliased.
Source: I’m pretty sure I wrote most of this code.
I can't find the reference right now, but IIRC the Glasgow Haskell Compiler had a function called "unsafeDirectIo" which people were using too flippantly. So they renamed it to "evilUnholyDirectIo"
Big fan of these “sarcastically named” functions, there are a lot of good reasons to use them (mainly, every time you go to use it you’ll think about whether it’s really needed) and not many reasons to not use it (naming it “fastConvert” doesn’t make it any faster than naming it “slowConvert”).
Some of our internal tools have command line options along the lines of:
--yolo Yes, I really want to overwrite the production database and get us all fired.
where "--yolo" is our standard flag for such things. When I find myself about to type that, I go back and double, triple, quadruple check that I really intend to do the thing that I'm asking it to do.
One of those irrational times of my year is when I inevitably hit something that really deserves a good descriptor but there just isn’t a good word or two for it. So I end up with one of these monsters.
It’s not a real problem, but it’s a moment that doesn’t bring me joy.
I personally love these kinds of names. On a long enough timeline, using them either:
- prompts someone to tell you the actual name for the thing, and now you know a name for something
- calls out poorly considered dependencies/design
- leads to naming a thing that deserves a name
- calls out complexity which is inherent either to the domain or other aspects of the underlying architecture
Every one of those is a positive outcome, and a less verbose name will never* be a better tradeoff.
* There are many apparent real-world exceptions, but they always fall under the “naming a thing that deserves a name” category, even if the resulting name is less clear than the verbose one. And they’re almost always directly involved in core abstractions (i, acc, cons) or core domain concepts.
Edited to make this less mistakenly ignorant of lisp.
We used to make fun of Java / Spring for names like this, but it turns out it was just being used for absolutely gigantic systems before other languages.
(Yes I know your great uncle Bobert coded 644 million lines of Cobol for a massive app where all function names were less than 4 characters. I'm talking general trends here)
I like https://surf.suckless.org (which uses WebKit) but it seems like every time I use it and leave a window open for awhile, that process (WebkitWebProcess) will end up pegging a core for no obvious reason. It's not site dependent, and I think it's when JS is enabled.
Some of the identifier names are kind of casual here. I was amused by the class called DeferGCForAWhile. I'm guessing just from reading that it's a typical RAII pattern so the "while" that will be deferred may be the scope of the object, i.e. until its destructor is called.
// Consider the following objects and prototype chains:
// O (of global G1) -> A (of global G1)
// B (of global G2) where G2 has a bad time
//
// If we set B as the prototype of A, G1 will need to have a bad time.
// See comments in Structure::mayInterceptIndexedAccesses() for why.
//
// Now, consider the following objects and prototype chains:
// O1 (of global G1) -> A1 (of global G1) -> B1 (of global G2)
// O2 (of global G2) -> A2 (of global G2)
// B2 (of global G3) where G3 has a bad time.
//
// G1 and G2 does not have a bad time, but G3 already has a bad time.
// If we set B2 as the prototype of A2, then G2 needs to have a bad time.
// Note that by induction, G1 also now needs to have a bad time because of
// O1 -> A1 -> B1.
//
// We describe this as global G1 being affected by global G2, and G2 by G3.
// Similarly, we say that G1 is dependent on G2, and G2 on G3.
// Hence, when G3 has a bad time, we need to ensure that all globals that
// are transitively dependent on it also have a bad time (G2 and G1 in this
// example).
//
// Apart from clearing the VM structure cache above, there are 2 more things
// that we have to do when globals have a bad time:
// 1. For each affected global:
// a. Fire its HaveABadTime watchpoint.
// b. Convert all of its array structures to SlowPutArrayStorage.
// 2. Make sure that all affected objects switch to the slow kind of
// indexed storage. An object is considered to be affected if it has
// indexed storage and has a prototype object which may have indexed
// accessors. If the prototype object belongs to a global having a bad
// time, then the prototype object is considered to possibly have indexed
// accessors. See comments in Structure::mayInterceptIndexedAccesses()
// for details.
//
// Note: step 1 must be completed before step 2 because step 2 relies on
// the HaveABadTime watchpoint having already been fired on all affected
// globals.
//
// In the common case, only this global will start having a bad time here,
// and no other globals are affected by it. So, we first proceed on this assumption
// with a simpler ObjectsWithBrokenIndexingFinder scan to find heap objects
// affected by this global that need to be converted to SlowPutArrayStorage.
// We'll also have the finder check for the presence of other global objects
// depending on this one.
//
// If we do discover other globals depending on this one, we'll abort this
// first ObjectsWithBrokenIndexingFinder scan because it will be insufficient
// to find all affected objects that need to be converted to SlowPutArrayStorage.
// It also does not make dependent globals have a bad time. Instead, we'll
// take a more comprehensive approach of first creating a dependency graph
// between globals, and then using that graph to determine all affected
// globals and objects. With that, we can make all affected globals have a
// bad time, and convert all affected objects to SlowPutArrayStorage.
Love that printInternal method. If the caller wants to map the enum to the string, make them know about a PrintStream that they have to instantiate.
(And possibly write their own derivation, if there isn't one that captures output into a string.)
[+] [-] afavour|2 years ago|reply
[+] [-] pizlonator|2 years ago|reply
The reason for the function’s existence is that it allows typed arrays to dynamically switch between a fast/compact representation for the case that the JSVM owns the data, and a slightly slower and slightly less compact version for when the JSVM allows native code to share ownership of the data.
This function, slowDownAndWasteMemory, switches to the less efficient version that allows aliasing with native code.
Of course the name is sarcastic. The actual effect of having this is that JSC can handle both the owned case and the aliased case, and get a small will if you’re in the owned case while being able to switch to the aliased case at any time. Since there’s no way to support the aliased case without some slightly higher memory/time usage, we are sort of literally slowing down and wasting memory when we go aliased.
Source: I’m pretty sure I wrote most of this code.
[+] [-] Alifatisk|2 years ago|reply
https://github.com/WebKit/WebKit/blob/ab10a90523e06df54bbb8a...
[+] [-] u_name|2 years ago|reply
[+] [-] the_mitsuhiko|2 years ago|reply
[+] [-] Tade0|2 years ago|reply
[+] [-] Sohcahtoa82|2 years ago|reply
https://android.googlesource.com/platform/frameworks/base/+/...
[+] [-] didntcheck|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] fwlr|2 years ago|reply
[+] [-] kstrauser|2 years ago|reply
[+] [-] 8n4vidtmkvmk|2 years ago|reply
[+] [-] fuu_dev|2 years ago|reply
Quote for people without account or rate limited:
"When you do uint8array.buffer in JSC the first time, it calls slowDownAndWasteMemory()" -- links to the github
The tweet has ~60k views, and 24 retweets.
[+] [-] olliej|2 years ago|reply
[+] [-] Waterluvian|2 years ago|reply
One of those irrational times of my year is when I inevitably hit something that really deserves a good descriptor but there just isn’t a good word or two for it. So I end up with one of these monsters.
It’s not a real problem, but it’s a moment that doesn’t bring me joy.
[+] [-] eyelidlessness|2 years ago|reply
- prompts someone to tell you the actual name for the thing, and now you know a name for something
- calls out poorly considered dependencies/design
- leads to naming a thing that deserves a name
- calls out complexity which is inherent either to the domain or other aspects of the underlying architecture
Every one of those is a positive outcome, and a less verbose name will never* be a better tradeoff.
* There are many apparent real-world exceptions, but they always fall under the “naming a thing that deserves a name” category, even if the resulting name is less clear than the verbose one. And they’re almost always directly involved in core abstractions (i, acc, cons) or core domain concepts.
Edited to make this less mistakenly ignorant of lisp.
[+] [-] nikanj|2 years ago|reply
(Yes I know your great uncle Bobert coded 644 million lines of Cobol for a massive app where all function names were less than 4 characters. I'm talking general trends here)
[+] [-] jakeogh|2 years ago|reply
[+] [-] pizlonator|2 years ago|reply
[+] [-] anthk|2 years ago|reply
[+] [-] Alifatisk|2 years ago|reply
Do you mean https://surf.suckless.org ?
[+] [-] lloydatkinson|2 years ago|reply
[+] [-] asveikau|2 years ago|reply
[+] [-] Jarred|2 years ago|reply
https://github.com/WebKit/WebKit/blob/b305f64a67e288b714a84f...
[+] [-] rurban|2 years ago|reply
[+] [-] kazinator|2 years ago|reply
[+] [-] nektro|2 years ago|reply
[+] [-] traes|2 years ago|reply
https://github.com/WebKit/WebKit/blob/ab10a90523e06df54bbb8a...
[+] [-] mrpf1ster|2 years ago|reply
[+] [-] dang|2 years ago|reply
[+] [-] exabrial|2 years ago|reply
[deleted]
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] vGPU|2 years ago|reply
[deleted]