This includes a couple changes related to the recently merged top-level value caching PR.
It changes the value serialization format back to an extension of the v4 format. That way, all old values are parsed/serialized in exactly the same way as before. Only code that is newly recognized as cacheable is serialized in a different way. Old implementations would be unable to recognize such serialized code, but they will know they are failing to recognize something and give an error, rather than continuing to parse things in an erroneous way.
This was motivated by cloud, and the above error case shouldn't be a problem, because the server will not typically be sending code values back to the client. So, not incrementing the version allows it to communicate the values it does send back in a format that the client should be able to understand. It doesn't fix a similar problem of servers communicating with one another while partially upgraded, but that seems less urgent.
Also included is some code support for having the values cached in the JIT. All the code generation should be there (as far as I know), but it's turned off at the moment because I cannot easily sort the definitions in a way that racket will accept. Once that problem is fixed it can be enabled to get similar performance enhancements on the JIT. I already had this written, so it was easier to just include it now than leave it rotting somewhere.
Here's an additional question. I could make it so that the for-hash serializer pays no attention to the cacheability status. This would make it so that code values that are newly recognized as being hashable retain the same hash as they did before. Should I do that or not bother?
This includes a couple changes related to the recently merged top-level value caching PR.
v4format. That way, all old values are parsed/serialized in exactly the same way as before. Only code that is newly recognized as cacheable is serialized in a different way. Old implementations would be unable to recognize such serialized code, but they will know they are failing to recognize something and give an error, rather than continuing to parse things in an erroneous way.Here's an additional question. I could make it so that the for-hash serializer pays no attention to the cacheability status. This would make it so that code values that are newly recognized as being hashable retain the same hash as they did before. Should I do that or not bother?