RSS Bilingual Reader

Background and bytecode design The ZJIT compiler compiles Ruby bytecode (YARV) to machine code. It starts by transforming the stack machine bytecode into a high-level graph-based intermediate representation called HIR. We use a more or less typical 1 control-flow graph (CFG) in HIR. We have a compilation unit, Function , which has multiple basic blocks, Block . Each block contains multiple instructions, Insn . HIR is always in SSA form, and we use the variant of SSA with block parameters instead...

GDB is great for stepping through machine code to figure out what is going on. It uses debug information under the hood to present you with a tidy backtrace and also determine how much machine code to print when you type disassemble . This debug information comes from your compiler. Clang, GCC, rustc, etc all produce debug data in a format called DWARF and then embed that debug information inside the binary (ELF, Mach-O, …) when you do -ggdb or equivalent. Unfortunately, this means that by defau...

Another entry in the Toy Optimizer series . A long, long time ago (two years!) CF Bolz-Tereick and I made a video about load/store forwarding and an accompanying GitHub Gist about load/store forwarding (also called load elimination) in the Toy Optimizer. I said I would write a blog post about it, but never found the time—it got lost amid a sea of large life changes. It’s a neat idea: do an abstract interpretation over the trace, modeling the heap at compile-time, eliminating redundant loads and ...

Originally published on Rails At Scale . ZJIT is a new just-in-time (JIT) Ruby compiler built into the reference Ruby implementation, YARV , by the same compiler group that brought you YJIT. We (Aaron Patterson, Aiden Fox Ivey, Alan Wu, Jacob Denbeaux, Kevin Menard, Max Bernstein, Maxime Chevalier-Boisvert, Randy Stauner, Stan Lo, and Takashi Kokubun) have been working on ZJIT since the beginning of this year. In case you missed the last post, we’re building a new compiler for Ruby because we wa...

Brief one today. I got asked “does YJIT/ZJIT have support for [Linux] perf?” The answer is yes, and it also works with samply (including on macOS!), because both understand the perf map interface . This is the entirety of the implementation in ZJIT 1 : fn register_with_perf ( iseq_name : String , start_ptr : usize , code_size : usize ) { use std :: io :: Write ; let perf_map = format! ( "/tmp/perf-{}.map" , std :: process :: id ()); let Ok ( file ) = std :: fs :: OpenOptions :: new () .create ( ...

I noticed that the URLs were all a little off (had two slashes instead of one) and went in and fixed it. I did not think everyone's RSS software was going to freak out the way it did. PS: this is a special RSS-only post that is not visible on the site. Enjoy.