Issue: https://pharo.fogbugz.com/f/cases/14688/Change-CompiledMethod-header-serialization-to-use-signed-integer
Name: SLICE-Issue-14688-Change-CompiledMethod-header-serialization-to-use-signed-integer-MaxLeske.1 Author: MaxLeske Time: 8 January 2015, 7:22:34.50291 am UUID: a61fa3a2-c7c6-439f-8abf-39806a1411fa Ancestors: Dependencies: Fuel-MaxLeske.799 empty log message > On 08 Jan 2015, at 08:13, Max Leske <[email protected]> wrote: > > >> On 08 Jan 2015, at 07:02, Eliot Miranda <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Max, >> >> >> On Jan 7, 2015, at 1:42 PM, Max Leske <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Just to be sure: is the size of the header stil 32 bits? Or is it now 64 >>> bits? Or is it 32 bits for now and will then become 64 bits? If it will >>> become 64 bits anyway, we might aswell store 64 bits right away. That way >>> we won’t have to make another change later on. >> >> The method header is 32-bits;it's a SmallInteger. In the 64-bit VMs >> (standard and Spur) it is a 64-but integer but only 32-bits are used. If we >> were to use more bits then it would be very difficult to serialize and >> deserialize code between 64- & 32-bit images; it would require a recompile. >> Also the VMs would be a bit different and the image code for the compiler >> etc. so basically it's not going to happen. It breaks too many things. > > I see. So I’ll use a 32 bit signed int representation. > > Thanks > >> >>> >>> Cheers, >>> Max >> >> Eliot (phone) >> >>> >>>> On 07 Jan 2015, at 22:27, Max Leske <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi Clément >>>> >>>>> On 30 Dec 2014, at 12:36, Clément Bera <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> As some of you may know, Pharo is being enhanced with support for >>>>> multiple bytecode sets. This will allow to run at the same time compiled >>>>> methods with 2 different bytecode sets for experimentation and to add >>>>> easily the new bytecode set described in this ESUG paper >>>>> <http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_A%20bytecode%20set%20for%20adaptive%20optimizations.pdf>. >>>>> >>>>> >>>>> The virtual machine knows which bytecode set the compiled method uses for >>>>> its encoding based on the sign of its header. This means that on the >>>>> contrary to right now, a compiled method *can* have a negative header. >>>>> >>>>> The issue is that typically operations such as #bitAnd: or #+ to access >>>>> bits of the smallinteger does not work the same way on negative integers >>>>> (2 complement's implementation of integers), resulting in incorrect >>>>> values. I am fixing the problematic cases in Pharo. >>>>> >>>>> One case is in Fuel and I can't fix it myself. It's in: >>>>> >>>>> FLCompiledMethodCluster>>#serializeInstance: aCompiledMethodToSerialize >>>>> with: anEncoder >>>>> >>>>> "some code" >>>>> header := aCompiledMethod header. >>>>> "some code" >>>>> anEncoder encodeUint32: header >>>>> "some code" >>>>> >>>>> This looks problematic because now header is not a uint anymore but a >>>>> sint. >>>>> In addition, #encodeUint32: uses #bitAnd: which may work differently on >>>>> negative integers. >>>>> >>>>> What do you fuel experts think ? Is there anything to fix there ? >>>> >>>> Replacing the header serialization with #encodeInt32: should fix the >>>> problem. >>>> >>>> Every header will from now on be an sint, is that correct? >>>> >>>> I’ll make the change and integrate. >>>> >>>> Cheers, >>>> Max >>>> >>>>> >>>>> Best, >>>>> >>>>> Clement >>> >> _______________________________________________ >> Pharo-fuel mailing list >> [email protected] <mailto:[email protected]> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >> <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel>
