Alexey Khrabrov

> We need to add the overhead of the list infrastructure (two extra pointers per node), so ~660 KB. It's manageable though. One `next` pointer in each record (intrusive linked...

> Since the record types will be kept in their own sections, can the record types be ordered so that the resulting snapshot file will still be sorted? Yes, see...

Once we have the snapshot mechanism implementation we'll be able to measure the overhead (in particular wall-clock and CPU time to write one) which will help guide some of the...

After giving it a bit more thought, merging snapshots doesn't seem too complicated, at least algorithmically. Here is a high level sketch of the algorithm to merge two snapshots. It...

> Regarding loading the snapshot in the background while other compilations that might want to use it are progressing we have two options: > > 1. Create a dedicated thread...

I generally agree with the approach of implementing a `SharedCache` subclass to act as a "front-end" for the deserializer. I haven't looked into the relocation and SVM infrastructure in a...

> I've been focusing on this initial problem for now, but fresh server AOT compilations would be good to support. Not just good, but necessary for this feature to be...

> I planned on testing my work with JITServer AOT caches that have already been populated (by a previous run or a loaded persistent cache). Using a pre-populated persistent AOT...

> @mpirvu mentioned using the current Liberty image and its read-only embedded SCC with the JITServer AOT cache in connection with this issue, but maybe he was imagining fresh server...

> One complication could be the fact that the client already has a local SCC (marked read-only). So, some bits of information need to be extracted from this SCC and...