Planned work related to fixed-format serialization

[JukkaL]

We've discussed some changes to the fixed-format serialization format and library (librt.internal). The list below includes these and maybe one or two new ideas.

It would be nice to have the changes in the 1.19 mypy release and I'm planning to work on these -- but most of these aren't critical, as we don't guarantee that the cache format is stable.

• Support 2-byte format for integers, instead of just 1 and 8 (possibly also 4 byte format).
• Always use type tags (and end tags for composite data) to make the data "self-describing", i.e. we can have a generic tokenizer of .ff files and skip arbitrary objects easily without full deserialization.
• Perform some fuzz testing to ensure deserialization fails gracefully.
• Create a checked primitive type for Buffer so that the C functions don't need to check the Buffer parameter type repeatedly (export the type object via the capsule).
• Experiment with using more pointers instead of integer index fields in BufferObject in case it would improve performance.

cc @ilevkivskyi

[ilevkivskyi]

Thanks! Isn't this a duplicate of #19738 LOL? That said, I think:

• First two are probably more important than the rest. I was myself thinking about doing these two before 1.19 because they will change cache format.
• It would be great to review/merge Support writing/reading bytes in librt.internal #20069 first to avoid merge conflicts

[JukkaL]

Oops, forgot about #19738. I'll move the new things to that issue.

If you will be working on the first two, I can work on some of the rest first.

[ilevkivskyi]

OK, FWIW I think it may be possible to actually combine first two items. I am thinking that instead of using lowest bit(s) to distinguish between different integer formats (as we do now), we can simply have separate tags like INT_1_BYTE = 7; INT_2_BYTES = 8; ... etc., and similar for strings/bytes. This means we will have few more tags, but code will be logically simpler.

Btw another important thing to discuss is what to do with cache format being platform dependent:

1. Right now we use CPyTagged in some places which is either 4 or 8 bytes. This means cache generated on 32 bits archs will not work on 64 bit archs (and vice versa).
2. Do we need to worry about endiannes? Now we simply cast everything to char and put into buffer. I tried to find any info on this, and IIUC most modern platforms are little endian, but still wanted to double-check.

[JukkaL]

Hmm most of the tasks in #19738 have been done, so maybe it's better to keep this issue to track any remaining work.

Here's another thing (this may already have been implemented, but not sure):

• Make sure that having a too old version of librt installed won't cause segfaults or other unpredictable behavior when using librt in compiled code. This will be important at least when mypyc compiled code uses C functions from librt via a capsule. Is there a capsule version number we can check, and raise an exception if the capsule doesn't have all the fields we need?
• Related to the above item: Document when the version number needs to be updated and how to do it (whenever the structure of a capsule changes?).

[ilevkivskyi]

OK, I will close that other issue then.

For the first item I added an ABI version check a while ago

mypy/mypyc/lib-rt/librt_internal.h

Lines 56 to 58 in b38413d

	if (NativeInternal_ABI_Version() != LIBRT_INTERNAL_ABI_VERSION) {
	PyErr_SetString(PyExc_ValueError, "ABI version conflict for librt.internal");
	return -1;

I this sufficient? It should raise an exception if the ABI version stored in capsule during capsule import is different from ABI version during compilation.

[JukkaL]

I think it may be possible to actually combine first two items. I am thinking that instead of using lowest bit(s) to distinguish between different integer formats (as we do now), we can simply have separate tags

An interesting idea -- I want to think about this a bit more to better understand the tradeoffs. One tradeoff is that for the new parser we may want to have a new data type that is effectively "sequence/tuple of 4 integers" (i.e. line/column range), since these will be used a lot for ASTs. If we use the lower bits to determine the length of each integer, we'd only need one type tag per a group of 4 integers, and then if all the 4 integers are small, we'd only need 5 bytes for a line/column range. If we'd use the type tag to encode integer length, the most straightforward implementation would use at least 8 bytes (4 type tags, one per integer). Of course we could special case the encoding for the groups of 4 integers, but that would be a little inconsistent.

Right now we use CPyTagged in some places which is either 4 or 8 bytes. This means cache generated on 32 bits archs will not work on 64 bit archs (and vice versa).

I think the serialization format should not rely on mypyc implementation details such as CPyTagged. Everything should also be the same on 32-bit and 64-bit architectures probably.

Do we need to worry about endiannes?

All modern architectures are little endian, but I guess Debian Linux at least still supports big endian architectures. I don't think this is critical to fix, since there's no easy way to run tests on a big endian architecture. Big endian architectures could be changed later if somebody cares about them enough.

[JukkaL]

One more potential thing to consider:

• We need to ensure that if you update mypy to a newer version, reading old .ff cache files will behave predictably -- i.e. mypy will treat them as out of date, as they were generated using a different version. It's not fine to raise some random exception when trying to deserialize old data (at least unless we explicitly handle all possible exceptions), even if we make changes to the serialization format between mypy versions.

[ilevkivskyi]

We need to ensure that if you update mypy to a newer version, reading old .ff cache files will behave predictably

We already reject caches from old mypy versions, I guess what you mean here is when you update librt version (while keeping same mypy version), we still need to reject the cache if we know the format changed.

[JukkaL]

Another thing (this is pretty minor, but it's needed for other things I will be working on so I'll probably prioritize this):

• Automatically import the librt.internal capsule if any features from librt.internal are used in a file. Currently this seems to be controlled by a flag manually set in setup.py.

[ilevkivskyi]

Currently this seems to be controlled by a flag manually set in setup.py.

Yeah, that was a hack to save time. For anything in librt that is not internal it needs to be added automatically.

[JukkaL]

I started looking at tweaking the internal representation of Buffer, and it looks like things could be faster if we'd have separate buffer types for reading and writing -- reading from a bytes object could deserialize directly from the data buffer of the original bytes object, so it would avoid one malloc/free + one copy of the data to deserialize. I'll look at this first, since this change would be harder to do later on, and it could give a measurable perf improvement.