[squeak-dev] What happened to CompiledMethod>>#numLiterals in Spur?

Chris Muller ma.chris.m at gmail.com
Thu Nov 13 20:24:14 UTC 2014


Hi Eliot and all, while moving some serialized objects from a Cog
image into a Spur image, I am encountered an issue materializaing a
CompiledMethod instance in the target Spur image due to the new
implementation of #numLiterals.  In Cog it's:

     numLiterals
          "Answer the number of literals used by the receiver."
          | header |
          ^(header := self header) < 0
               ifTrue: [header bitAnd: 65535]
               ifFalse: [(header bitShift: -9) bitAnd: 16rFF]

but in Spur, only the negative header condition is present:

     numLiterals
          "Answer the number of literals used by the receiver."
          ^self header bitAnd: 65535

The header was positive in the source Cog image, in fact, there are NO
instances of CM's with negative headers in either my Cog or Spur
images.  So after constructing the CompiledMethod for materialization
within the Spur image with the same #header it had in Cog, it reports
the wrong #numLiterals and can't finish the materialization because of
that.

I'm able to force a correct materialization by changing the place
where I access "numLiterals" to the original True condition of Cog --
"(header bitShift: -9) bitAnd: 16rFF".

But that's just "making it work" and not understanding the
implications of what I'm doing.  I know Spur can allow more literals
per CM, but assuming I'm willing to stay with a max of just 255
literals for now, is my override above the best way to handle this
need to be able to transfer objects back-and-forth within a
heterogeneous environment of Cog and Spur images?

Thanks for any advice and insight..


More information about the Squeak-dev mailing list