7 ms·

// 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

// 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.

pizlonator 3y ago
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.
- londons_explore 3y ago
  Indeed you did, 10 years ago. This is the (mega!) commit: https://github.com/WebKit/WebKit/commit/93a48aa964f25ce8ec9f90aeaa142d2a9fb5b678 https://github.com/WebKit/WebKit/commit/93a48aa964f25ce8ec9f... I often wonder how much more productive I could be if I didn't need to split changes like this into 50 small commits, where every intermediate commit is working and has passing tests...
  - pizlonator 3y ago
    Yeah sometimes you just have to write a megapatch. I’d be very sad if I had to work on a project that didn’t allow that.
    - bpye 3y ago
      I don't know what my largest commit has been, but I do find that merge conflicts end up being a real pain when you're touching so many files...
      - AlotOfReading 3y ago
        Mine was a very memorable ~2900 files changed. We missed an OS update cycle and had to consume all the changes in one giant patch. But upstream had migrated from Python 2 to 3 in-between and rewrote half their build scripts to accommodate. Each of those changes needed to be reviewed manually because we had modified things to support reproducible builds and the resulting merge conflict was monstrous. I contributed maybe 2300 of those before my sanity failed and called for help. Now we have a whole team to do that job more regularly.
    - phatskat 3y ago
      I understand the desire to make larger patches, but how do you effectively manage them in the review process? For super large commits in the past, I’ve had other engineers hop on a screen share to review the diff together and answer questions, but it feels inefficient.
      - 3y ago
- qingcharles 3y ago
  This is classic HN. "Look at this crazy, obscure code everybody!" *ORIGINAL DEVELOPER APPEARS*
  - astrange 3y ago
    Obscurity is mostly a property of the project it's in, so I don't know if it can really apply to WebKit.
- kentonv 3y ago
  Out of curiosity, what makes the aliased version less compact? Naively I'd think there's not much room to optimize the representation of a byte array.
  - pizlonator 3y ago
    Native code wants to think it’s a ref counted buffer that could be accessed from any thread including ones that don’t participate in GC. So it’s gotta be allocated in the malloc heap and it’s gotta have a ref count. JS code wants the buffer to be garbage collected. If native code doesn’t ref it (count is zero) and it’s not reachable via JS heap then it’s gotta die. So, it needs a GC cell and associated machinery (JSC object headers, mark bits, possibly other stuff). So, the reason why the aliased case is not as awesome as the owned case is that you need double the things. You need some malloc memory and you need a GC cell. You need a ref count and you need a GC header and some mark bits. Having both malloc/RC and cell/GC overhead isn’t like the end of the world or anything, but it means that allocations are slower and waste more memory than if it was either just a buffer owned by native code or just an object in the GC heap.
- solarkraft 3y ago
  Did you choose the name? Have there been any reactions to it? I like the name, but can easily imagine somebody preferring a more serious alternative.
  - pizlonator 3y ago
    That’s why it’s important to find a team and coworkers that aren’t so uptight.
    - slaymaker1907 3y ago
      With a project that could live on for many years, I’d object to this code, but only because it doesn’t really explain _why_ it’s necessary despite wasting time/memory. The humorous name is great, though. It might be explained in the VCS history, but people aren’t likely to look it up there and I’ve noticed the history tends to get lost for a lot of old projects.
      - eru 3y ago
        Fortunately, git helps you stitch together histories (without changing hashes), if you later recover it: https://git-scm.com/book/en/v2/Git-Tools-Replace https://git-scm.com/book/en/v2/Git-Tools-Replace
      - pizlonator 3y ago
        The name isn’t just funny. It’s also accurate. And it’s quite evidently stood the test of time. In a VM, often the most important kind of documentation is about labeling what is the fast path and what is the slow path. This method name alerts the code reader that they’re looking at one of the slow paths.
    - spopejoy 3y ago
      Isn't part of the goal with deliberately weird names like this is to alert callers that HERE BE DRAGONS so, like, don't call this unless you've read _and understood_ the source code?

pizlonator 3y ago

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.

londons_explore 3y ago
Indeed you did, 10 years ago. This is the (mega!) commit: https://github.com/WebKit/WebKit/commit/93a48aa964f25ce8ec9f90aeaa142d2a9fb5b678 https://github.com/WebKit/WebKit/commit/93a48aa964f25ce8ec9f... I often wonder how much more productive I could be if I didn't need to split changes like this into 50 small commits, where every intermediate commit is working and has passing tests...
- pizlonator 3y ago
  Yeah sometimes you just have to write a megapatch. I’d be very sad if I had to work on a project that didn’t allow that.
  - bpye 3y ago
    I don't know what my largest commit has been, but I do find that merge conflicts end up being a real pain when you're touching so many files...
    - AlotOfReading 3y ago
      Mine was a very memorable ~2900 files changed. We missed an OS update cycle and had to consume all the changes in one giant patch. But upstream had migrated from Python 2 to 3 in-between and rewrote half their build scripts to accommodate. Each of those changes needed to be reviewed manually because we had modified things to support reproducible builds and the resulting merge conflict was monstrous. I contributed maybe 2300 of those before my sanity failed and called for help. Now we have a whole team to do that job more regularly.
  - phatskat 3y ago
    I understand the desire to make larger patches, but how do you effectively manage them in the review process? For super large commits in the past, I’ve had other engineers hop on a screen share to review the diff together and answer questions, but it feels inefficient.
    - 3y ago
qingcharles 3y ago
This is classic HN. "Look at this crazy, obscure code everybody!" *ORIGINAL DEVELOPER APPEARS*
- astrange 3y ago
  Obscurity is mostly a property of the project it's in, so I don't know if it can really apply to WebKit.
kentonv 3y ago
Out of curiosity, what makes the aliased version less compact? Naively I'd think there's not much room to optimize the representation of a byte array.
- pizlonator 3y ago
  Native code wants to think it’s a ref counted buffer that could be accessed from any thread including ones that don’t participate in GC. So it’s gotta be allocated in the malloc heap and it’s gotta have a ref count. JS code wants the buffer to be garbage collected. If native code doesn’t ref it (count is zero) and it’s not reachable via JS heap then it’s gotta die. So, it needs a GC cell and associated machinery (JSC object headers, mark bits, possibly other stuff). So, the reason why the aliased case is not as awesome as the owned case is that you need double the things. You need some malloc memory and you need a GC cell. You need a ref count and you need a GC header and some mark bits. Having both malloc/RC and cell/GC overhead isn’t like the end of the world or anything, but it means that allocations are slower and waste more memory than if it was either just a buffer owned by native code or just an object in the GC heap.
solarkraft 3y ago
Did you choose the name? Have there been any reactions to it? I like the name, but can easily imagine somebody preferring a more serious alternative.
- pizlonator 3y ago
  That’s why it’s important to find a team and coworkers that aren’t so uptight.
  - slaymaker1907 3y ago
    With a project that could live on for many years, I’d object to this code, but only because it doesn’t really explain _why_ it’s necessary despite wasting time/memory. The humorous name is great, though. It might be explained in the VCS history, but people aren’t likely to look it up there and I’ve noticed the history tends to get lost for a lot of old projects.
    - eru 3y ago
      Fortunately, git helps you stitch together histories (without changing hashes), if you later recover it: https://git-scm.com/book/en/v2/Git-Tools-Replace https://git-scm.com/book/en/v2/Git-Tools-Replace
    - pizlonator 3y ago
      The name isn’t just funny. It’s also accurate. And it’s quite evidently stood the test of time. In a VM, often the most important kind of documentation is about labeling what is the fast path and what is the slow path. This method name alerts the code reader that they’re looking at one of the slow paths.
  - spopejoy 3y ago
    Isn't part of the goal with deliberately weird names like this is to alert callers that HERE BE DRAGONS so, like, don't call this unless you've read _and understood_ the source code?