# String literal resolution in AOT-compiled code

To get string literal by its identifier application has to perform special runtime call. To improve performance in AOT
mode such runtime calls could be replaced with load from a special PLT-slot in AOT file. In that case compiled code 
loads a value from a slot associated with a string and checks if that value is valid pointer. If it's not then the
application have to perform `ResolveStringAot` runtime call that will return a pointer. That runtime call may also save
returned string pointer into the slot and subsequent executions of the same code will bypass runtime calls.

## Compiler support

During AOT compilation `LoadString` instruction could be either encoded as regular `ResolveString` runtime call or as
a PLT-slot check with `ResolveStringAot` runtime call as a fallback.
To use the latter encoding the following conditions have to be met:

- compiled method should not be a static class initializer (initializers get invoked only once and the first
  resolution attempt requires runtime call, so usage of regular `ResolveString` call reduces the overhead);
- `--compiler-aot-load-string-plt` option should be turned on (it is on by default).

If the condition is met then the compiler reserves a unique PLT-slot (with type `STRING_SLOT`) for the string and
emits load from that slot, followed by the check that the loaded value is a valid pointer and the slow path.

The slow path performs `ResolveStringAot` runtime call that returns resolved string.

## Runtime support

There are two options controlling when and how many string will be saved into PLT-slots:
- `--aot-string-gc-roots-limit` controls how many time the same string should be resolved before its pointer will be 
  saved into the associated PLT-slot;
- `--resolve-string-aot-threshold` controls how many strings could be save to PLT-slots (option applied to the whole
  application, not to a single AOT-file).

`RuntimeStringAot` runtime call resolves the string as a regular `RuntimeString` call, but also does the  following
things:
- checks the value already stored in `STRING_SLOT` PLT-slot - after AOT-file loading all such slots contain `0` and
  then each resolution attempt will increment value inside the slot until it either get replaced with a string pointer,
  or it reaches `PANDA_32BITS_HEAP_START_ADDRESS - 1` (after that invocations will not increment slot value);
- if PLT-slot's value is already a pointer then the resolved string gets returned;
- if amount of already filled PLT-slots is above `--resolve-string-aot-threshold` then the resolved string gets 
  returned;
- if PLT-slot's value is below `--aot-string-gc-roots-limit` then slot's value is incremented and the resolved string is
  returned;
- if PLT-slot's value is above `--aot-string-gc-roots-limit` then slot's value is replaced by string pointer, slot is
  registered as GC-root in `AotManager` and the resolved string is returned.

## GC support

String pointers stored inside PLT-slots have to be treated as GC-roots to prevent its scavenge in case there are no
references to it.
`AotManager` is responsible for storing PLT-slots containing references. It also provides methods to iterate over these
slots in order to scan and update them. As an optimization `AotManager` stores information about whether or not the 
PLT-slot is referencing to an object in young space. That information allow to significantly reduce amount of scanned 
PLT-slots during young GC, but it also requires update during update phase. As yet another optimization PLT-slots are 
updated only if `StringTable` was updated during GC, because both these structures are referencing to the same string (
PLT-slots referencing a subset of strings references by the `StringTable`).