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 <maxleske@gmail.com> wrote:
Hi Clément
On 30 Dec 2014, at 12:36, Clément Bera <bera.clement@gmail.com <mailto:bera.clement@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%...>.
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