[Vm-dev] CompiledMethod header bits index 29 (flag bit)

[Eliot Miranda]

On Tue, Mar 6, 2012 at 2:42 PM, Stefan Marr <smalltalk at stefan-marr.de>wrote:

>
> Hi:
>
> What is the intention of the flag bit in the CompiledMethod header?
>

I'm not sure it is used for anything other than an arbitrary flag that can
be set for various purposes as the need arises.


>
> Just interested what it is good for, or was used for originally.
>

The Cog VM will flag interpreted methods if bit 1 of vmParameter 48 is set.
 This is useful in deciding how large to set maxLiteralCountForCompile.
 Early in Cog's usage I would run a Qwaq image and check which methods were
flagged on start-up and keep upping the limit until all
performance-intensive start-up methods were covered.  The default value is
now 60, and IIRC it started at 50.  [BTW, maxLiteralCountForCompile is only
variable via a command-line parameter, -cogmaxlits, which is poor, because
it really should be a per-image setting, overridable on the command-line,
instead of a VM default, overridable on the command-line).



> More specifically, I would like to verify that I can just reuse it without
> having to worry about to many incompatibilities.
>
> My understanding so far is that it is only used to highlight methods in a
> browser.
>

There's no conflict with Cog's usage.  But the flag is really useful for
VM/image communication.  If you're only interested in image-level flagging
you can always do something simple like create an IdentitySet containing
the methods you want to flag.  The flag is a single resource, one per
method, so if different open browsers want to flag for different reasons
they will conflict.

Thanks
> Stefan
>
> PS: the split encoding of the primitive code seems also to be a beautiful
> artifact of an old legacy ;)
>

Indeed ;)  And consuming all those bits for 10% of methods (the ones that
have primitives) doesn't make all that much sense either.  And in fact only
1.5% of methods have a real primitive; the bulk of methods with a primitive
are quick methods that return an inst var or nil, true, false and self.  It
streamlines a naive implementation of the interpreter.  But once the method
cache caches a primitive routine as well as the method, the decode time for
a primitive becomes less important.  And so VisualWorks' approach where the
primitive is encoded in a bytecode, and the VM can detect frameless
accessors by checking the first one or two bytecodes, claws back a lot of
header bits.

This is related to the above.  I've just added support to Squeak trunk for
accessing the sign bit in the method header and using this as an additional
flag.  But Cog reserves the use of that flag for choosing an alternative
bytecode set, an idea I've stolen from Claus Gittinger, whose Smalltalk/X
VM runs Java bytecode alongside Smalltalk.  Its as simple as setting a
constant based on the method's bytecode selector, e.g. 0 for Smalltalk, 256
for the alternative bytecode set, and adding this to the current bytecode
when dispatching.  So if there are two bytecode sets there aren't two
interpreters, but instead are 512 bytecodes.  So I'm set, when time allows,
to experiment with designing an alternative bytecode set.

--
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525
>
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120306/dd430148/attachment.htm