When we run out of JIT memory, we don't compile the iseq, so jit_entry will be forever NULL. This means that the JIT call counters (jit_entry_calls and jit_exception_calls) will continue to increase on every call. This is bad for copy-on...peterzhu2118 (Peter Zhu)
base_label isn't used very often in iseq and we can dynamically derive it from the label (of the current iseq or the local_iseq). We can remove this field to save 8 bytes.peterzhu2118 (Peter Zhu)
We keep a singleton of iseq wrappers (RubyVM::InstructionSequence). However, this is rarely used and causes 8 bytes to be wasted on all iseq objects. Since we now have the 32-byte slot size in the default GC, we can save that memory.peterzhu2118 (Peter Zhu)
We cannot have YJIT and ZJIT enabled at the same time, so we can use a single jit_payload pointer in iseq_constant_body to reduce the size by 8 bytes.peterzhu2118 (Peter Zhu)
On 64-bit systems, we used 4 bytes to determine if there is a collision in the entry. This is a waste because it only needs 1 bit. This commit separates each item in rb_id_table into three parts: items (8 byte elements), keys (4 byte el...peterzhu2118 (Peter Zhu)
In iseq_scan_bits, we only update original_iseq if the element at code moved. However, this isn't correct as it's possible that code has already gotten updated but not original_iseq. This will cause original_iseq to not get updated.peterzhu2118 (Peter Zhu)
We shouldn't record JIT information before the JIT is actually enabled. This change doesn't seem to affect ZJIT or YJIT performance beyond the margin of error: ZJIT: -------------- ------------ ------------ --------------...peterzhu2118 (Peter Zhu)
peterzhu2118 (Peter Zhu)03:51 AM Ruby Revision d571f80b (git): Stop incrementing the JIT call counter when not compiled