Constellation

We, Apple JavaScriptCore team, are hiring a senior stability engineer, focusing on stability of JavaScriptCore. If you are interested, submit resume via the URL! Let's make JavaScriptCore steady and rock solid! #WebKit #Apple jobs.apple.com/en-us/details/…

なんか温かい飲み物ほしいな

RSC の, 流石に 2025 年にやるような脆弱性じゃなくないですかこれ…

食べすぎた気がする…

Today is my first day at @bunjavascript

チーズ美味しい

暖かくなってきた

I'm officially a WebKit Reviewer! I would like to thank all the JSC Reviewers who reviewed my patches and @Constellation for nominating me.

あのダンスで幸せのパンを思い出した

I think that the way that VMs do safepointing is the most underappreciated aspect of modern multithreaded VM/GC tech. It forms the foundation of Fil-C's accurate stack scanning, safe signal handling, and safe forking. It also forms the foundation of accurate GC, debugging, and profiling in modern JVMs. What does it do? It's a lightweight synchronization mechanism that allows threads in a VM to make assumptions about the VM's state. For example, it allows threads to assume that a pointer loaded from the heap will point to a live object even if the pointer hasn't been registered as a root yet (so it prevents mutator-load/GC-sweep races). It also enables the VM to snapshot thread state at any time. And it enables Fil-C's signal handling shenanigans. Here's a brief braindump on how I implement it. Other implementations are either functionally equivalent or only subtly different (not everyone is aiming for the same tradeoffs). - Each thread has a lock and condition variable controlling the thread's state. Additionally, each thread has a status byte controlling the thread's state. The status byte can be modified by CAS by the thread that owns it. The status byte can be read using a relaxed read by the thread that owns it. All other threads are required to modify the status byte with CAS *and* while holding the lock. - The status byte has to indicate at least: if a pollcheck is requested (more on that below) and whether the thread is "entered" (aka has VM access, aka has heap access - different folks call this different things). That's two bits. - An entered thread is guaranteed to run a pollcheck (a check to see if a pollcheck was requested) on a regular cadence (roughly, every O(1) instructions executed). So, locking the thread's state, then CASing the handshake requested bit, and then waiting for the thread to respond is a O(1) operation. Pollchecks are cheap: load the thread's status byte using a relaxed (i.e. not atomic) load, and branch on its bits. There is a ton of literature on how to make pollchecks even cheaper than this. - An exited thread won't run pollchecks. The exited state is good for making syscalls or calling out of the VM (hence why I call it "exited" - you've exited the VM). Requesting a pollcheck of an exited thread means doing the work that the pollcheck would do on the thread's behalf while holding the thread's lock. - Threads exit and enter by CASing on the fast path. The fast path of exit/enter is: assert that the thread has no pollchecks requested, and then change the state from entered to exited (or vice versa). If a pollcheck was requested, the thread takes slow path and grabs the lock, potentially servicing the pollcheck or notifying (using the condition variable) that the thread is exiting. That's most of the story. There are more shenanigans to do with thread start and stop (need to make sure that someone trying to request pollcheck of all threads doesn't miss threads that were just started). Additional shenanigans are needed if you want to support stopping the world (a special kind of pollcheck request that causes all threads to wait on their condition variables until the world is resumed). Fil-C hooks into this for signal handling. When the OS delivers a signal, and the thread is entered, the Fil-C runtime's signal handler just raises the signal requested bit (another bit in the status byte not unlike the pollcheck requested bit), and the next pollcheck will run the signal handler. This ensures signal handlers run at well-defined points that the runtime understands, which allows signal handlers to safely allocate GC memory (needed for stack allocations in Fil-C; and as a byproduct it means that Fil-C's malloc is signal-safe). If the thread is exited, then the signal is delivered immediately. This is a super old technique! There are lots of variations on it in different VMs. The most sophisticated and mature implementations tend to be in JVMs (in my experience). Fil-C's implementation is quite complete though; you can see how it works by looking at filc_pollcheck/filc_enter/filc_exit in filc_runtime.c.

今年はとても review 業をしている気がする

D.C. 主人公が手から和菓子出すの覚えててえらい

JavaScriptCore is leading-edge production JIT compiler and runtime. Significant perf is obtained by extreme runtime adaptivity, which poses novel challenges for stability! There are a lot of exciting opportunities, and improvements directly impact on massive amount of users!

We, Apple JavaScriptCore team, are hiring a senior stability engineer, focusing on stability of JavaScriptCore. If you are interested, submit resume via the URL! Let's make JavaScriptCore steady and rock solid! #WebKit #Apple jobs.apple.com/en-us/details/…

ジャブジャブ様ってこんな不気味なBGMだったか m.nintendo.com/shared/ja-JP/J…

ISUCA, イタチが出てくるたびにイタチ報告するだけでめちゃくちゃ楽しかったですよね

来年2025年ということは、アブソリュート・デュオ、新妹魔王の契約者、銃皇無尽のファフニール、聖剣使いの禁呪詠唱の4本が揃って話題だった……うえに戦国無双とISUCA-イスカ-というド級のサイコー作品があったクールから10年ってことか

僕たちは生きた。木戸ひゃんの代表作「帰宅部活動記録」「お兄ちゃんだけど愛さえあれば関係ないよねっ」「レーカン！」「彼女がフラグをおられたら」「精霊使いの剣舞」で語れた時代を確かに生きたんだ──

今帰宅部活動記録の話始めるの悪すぎる

@AvimanyuRoy3 @VictorTaelin @jarredsumner Right. We need optimization here. Right now, it is not on a priority list, but our long term plan includes revise of BigInt implementation and perf improvement.

Bun.js is amazing, but sadly it is 10x slower than Node.js on programs that use U64, it seems. I guess JSC doesn't optimize for it?