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.
Cheers, Max > On 07 Jan 2015, at 22:27, Max Leske <maxle...@gmail.com> wrote: > > Hi Clément > >> On 30 Dec 2014, at 12:36, Clément Bera <bera.clem...@gmail.com >> <mailto:bera.clem...@gmail.com>> 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
