[Pharo12] Simplify CompiledMethod trailer: just support fixed sourcePointers
Hi, We did (im Pharo12) a simplification of how method trailers are handled. Below is the class comment of the now Deprecated and empty class CompiledMethodTrailer. The issue https://github.com/pharo-project/pharo/issues/13512 has a list of all the intermediate steps done. ========== CompiledMethodTrailer was removed in Pharo12 It was responsible for encoding and decoding various kinds of compiled method trailer data, but that had many downsides: ⢠variable length trailers forced often called methods like CompiledMethod>>#endPC to instantiate an instance ⢠setting a sourcePointer that required a different length trailer (e.g embedding sources) needed to create a new compiled method and do a become ⢠to avoid that, the compiler supported to use an existing trailer and delegated instance creation of CompiledMethod to it. ⢠using 1 byte for the trailer kind lead to the need use Variable length encoding already for our ~40MB source file for some methods. All in all, the CompiledMethodTrailer added a lot of complexity for nothing. What do we do now? ⢠use use a fixed-length trailer (see #trailerSize) ⢠writing and reading that is not that complex (see #setSourcePointer, #sourcePointer:) Q: I used to hand a trailer to the compiler, what should I do now? The compiler now creates always CompiledMethods with a fixed, but empty trailer. Just use #sourcePointer to set it after. Q: I used to clear the trailer using #copyWithTrailerBytes:, what should I do now? There is now #cearSourcePointer. Just use #copy before if you want a copy. Q: I want to have a non-installed method, but with source code. The compiler now sets a #source property (and setting a source pointer via #sourcePointer: removes it). If you use the compiler, you need to do nothing special anymore! All methods come with source via the property by default.
Thanks for the detailed explanation. Little behind the scenes improvements like this are always so interesting and appreciated, even if not immediately visible during normal usage.
The last PR now changes the trailer size to 5. https://github.com/pharo-project/pharo/pull/13580 <https://github.com/pharo-project/pharo/pull/13580> This way .changes/sources size can be 512GB. The most important things is, though, that this validates that we can change the space easily, e.g use 64bit and store some ObjectID... The fixed trailer does have an impact on speed for bytecode interpretation (via the Context). e.g. when looking for senders of special selectors, it has to fall back to use InstructionStream scanFor:, as the selectors are not in the literals. [#+ senders] bench Pharo11 : "'3.891 per second'" Pharo12 : "'4.913 per second'" This is some 25% faster, due to not having to instantiate a CompiledMethodTrailer for #endPC. Marcus
On 28 Apr 2023, at 11:07, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
We did (im Pharo12) a simplification of how method trailers are handled. Below is the class comment of the now Deprecated and empty class CompiledMethodTrailer.
The issue https://github.com/pharo-project/pharo/issues/13512 has a list of all the intermediate steps done.
==========
CompiledMethodTrailer was removed in Pharo12
It was responsible for encoding and decoding various kinds of compiled method trailer data, but that had many downsides:
⢠variable length trailers forced often called methods like CompiledMethod>>#endPC to instantiate an instance ⢠setting a sourcePointer that required a different length trailer (e.g embedding sources) needed to create a new compiled method and do a become ⢠to avoid that, the compiler supported to use an existing trailer and delegated instance creation of CompiledMethod to it. ⢠using 1 byte for the trailer kind lead to the need use Variable length encoding already for our ~40MB source file for some methods.
All in all, the CompiledMethodTrailer added a lot of complexity for nothing.
What do we do now?
⢠use use a fixed-length trailer (see #trailerSize) ⢠writing and reading that is not that complex (see #setSourcePointer, #sourcePointer:)
Q: I used to hand a trailer to the compiler, what should I do now?
The compiler now creates always CompiledMethods with a fixed, but empty trailer. Just use #sourcePointer to set it after.
Q: I used to clear the trailer using #copyWithTrailerBytes:, what should I do now?
There is now #cearSourcePointer. Just use #copy before if you want a copy.
Q: I want to have a non-installed method, but with source code. The compiler now sets a #source property (and setting a source pointer via #sourcePointer: removes it). If you use the compiler, you need to do nothing special anymore! All methods come with source via the property by default.
participants (2)
-
Marcus Denker -
sean＠clipperadams.com