03_31_2025_masm_api_update.md

03_31_2025_masm_api_update.md

A short update on the current AOT api:

We discussed previously whether ImmPtr is suitable for AOT interception.

• ImmPtr should be the right place to catch runtime ptrs being emitted through the masm. However there are some issues:

  1. a few uses of ImmPtr(nullptr) prevent a verified reverse lookup

  2. Not all ImmPtrs may want relocs, even if they do contain real addresees.

  3. Most importantly: AbsoluteAddress is also used to emit runtime pointers, so ImmPtr alone doesn't provide total coverage.

  To address this, AOT relocations are now explicit with RelocImmPtr which is a wrapper of ImmPtr. This is a shallow abstraction, but it does let us MOZ_CRASH when a reverse lookup can't be found. The main downside being some AbsoluteAddreess must be rewritten to use RelocImmPtr

  Some points in the code which help tell the story:

  • AOTIndirectionTable ReverseLookup
  • RelocImmPtr example usage
  • movePtr Overload
  • Filling AOT table in JITRuntime init
  • Enum with AOT slot kinds

Some strengths:

• A single pointer type lets codegen opt-in to AOT relocations and a single choke point in the MASM movePtr overloaded on RelocImmPtr does the reverse lookup and emission.

Some weaknesses:

• Requires rewriting AbsoluteAddress -> RelocImmPtr if a runtime pointer is emitted through the former. Alternatively, we could leave the AbsoluteAddress and do more interception in masm.

• AOT reloc system still reliant on BaselineFrame. As we approach the "optimziing JS builtin" story, Ion compiling builtins with AOT relocations seems more compelling. But to do that, a pinned register is probably necessary.

• Shared masm routines like loadJSContext must hit the overloaded movePtr even if called from a non-aot context. While the MOZ_UNLIKELY branch hint helps, there is still an extra function call.

• Generally lots of boilerplate to serialize / deserialize through the binary format.

A couple questions:

1. Shouldn't ImmPtr(nullptr) be something we just whitelist; it won't be different between runs
2. Can you give an example of an ImmPtr that has a real address that doesn't want to be relocatable (given we only care about this in the AOT generation step?)

Overall, the story you tell, I quite like.

From a software engineering perspective we could do a first-cut assist by making AbsoluteAddress assert if you find an AOT slot for the address.

I'm interested in hearing more about the baseline frame requirements. There's a part of me which would like to see a variation on this where the baseline frame dependent AOT stuff is kept slightly distinct from the totally runtime independent stuff. Just makes the cuts more obvious.

I wouldn't worry about codegen emission differences of one well predicted branch.

Serialization and deserialization in C++ tends towards the verbose, not sure there's great answers.

Thanks for the response.

1. Yes we could just whitelist ImmPtr(nullptr) in the reverse lookup, good point.

2. The original example I had in mind was shared masm routines, such as
   loadJSContext, which would hit from a masm that doesn't want AOT.
   But actually, we have the AOT state in masm specifically to skip relocations in
   such circumstances. I think this was confusion on my part.

I think we should be able to get by purely w/ ImmPtr

re AbsoluteAddress: Yes in that case, especially if we move back to all ImmPtr,
having the interfaces which receive an AbsolutePointer also take part in the
reverse-lookup + reloc emission would definitely be the least codegen invasive
approach.