I started to investigate the error today, and it wasn't an easy one. It handled the handle_CALL_KW, which was not completed or buggy at the SSA IR generation side, and decided to fix it, so my only options were to

A. Delete call_ops.cpp entirely if no functions are used
B. Fix call_ops.cpp::handle_CALL_KW to match jit_core.cpp and potentially refactor to use it
C. Leave as-is since the working code is in jit_core.cpp

I thought the B It would be an interesting fix and easier for future debugging.

So, I was sure to decide that the decision was to fix call_ops.cpp to work, then wire it up to replace the inline code in jit_core.cpp. This creates a clean, modular architecture.

which wasn't an easy one for me, and I was also noticing a few errors, Memory leak - unused pos_tuple and kwargs_dict

I wanted the best tools for detecting memory leaks and segfaults in native C++ code

And the problem was I was using Windows, so I googled the solution and found

1. Dr. Memory (Free, Best for your use case)

  • Detects memory leaks, use-after-free, buffer overflows, uninitialized reads
  • Works on Windows without recompilation

I installed this one through Winget, but it crashed due to

Dr. Memory crashed internally - this happens because it has compatibility issues with Python 3.13 and LLVM JIT code (dynamic code generation is hard to instrument).

This was the answer I found on Google.

So I first took my search from c plus plus to Python, I researched and found that Python had an inbuilt library

tracemalloc- its main use was to track the memory usage of the Python interpreter during run time

And the tracemalloc results show:

  • Peak memory: 0.54 MB (very low)
  • Most allocations are from Python's standard library (importlib, dis, opcode)
  • No obvious memory leaks detected at the Python level

So, my secondary was Valgrind,

as usual, research about Valgrind,

Valgrind is a suite of dynamic analysis tools for debugging and profiling programs, primarily used to detect memory management and threading errors.

I had to install WSL, which I then did. I used Claude AI to help me check memory leaks and segmentation faults from both the Python end and the C++ end

The Results are :

Memory Safety Analysis: justjit Python JIT Compiler

TL;DR

After extensive testing with Valgrind on Linux, justjit has zero memory safety issues. No segmentation faults, no use-after-free bugs, no buffer overflows, no uninitialized memory access.

====leaks====

What About Those 432 Bytes?

The only "definitely lost" memory is in LLVM's exception handling frame registration (__register_frame in libgcc_s.so). This is not a justjit bug - it's standard LLVM ORC JIT behavior. When LLVM compiles code at runtime, it registers exception handling frames with the system. These are intentionally kept until process exit for unwinding support.

Heap Statistics

total heap usage: 672,829 allocs, 663,713 frees

256 MB allocated over test lifetime

justjit generates native x86-64 machine code at runtime using LLVM. One wrong pointer and you get a segfault - or worse, silent memory corruption. Our test proves the implementation is solid.

The critical operations we validated:

  1. CALL_KW - Keyword argument handling (fixed bug where kwargs were ignored)
  2. CALL_FUNCTION_EX - Unpacking *args and **kwargs
  3. Reference counting - Python object lifecycle management
  4. Stack management - Proper cleanup on all code paths

Conclusion

justjit passes Valgrind's strictest memory checks with zero errors. The JIT compiler correctly manages:

  • Python object references
  • LLVM IR construction
  • Native code generation
  • Function call conventions
  • Exception handling paths
  • 68 opcodes are implemented, still working on adding opcodes.
  • thanks for reading .