Hi:
What is the intention of the flag bit in the CompiledMethod header?
Just interested what it is good for, or was used for originally. 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.
Thanks Stefan
PS: the split encoding of the primitive code seems also to be a beautiful artifact of an old legacy ;)
On Tue, Mar 6, 2012 at 2:42 PM, Stefan Marr smalltalk@stefan-marr.dewrote:
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
Hi Eliot:
On 07 Mar 2012, at 01:47, Eliot Miranda wrote:
But the flag is really useful for VM/image communication.
Right, that's what I want to use it for. Flagged methods will allow me to mark exit points from a special interpretation mode. In that special mode, I enforce certain additional semantics, but need to be able to disable that to get back to the normal mode. The flag seems to be a convenient way to do that.
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.
Ehm, I am not completely with you. I think, I misunderstand something here, which header word exactly?
I looked through the diff of VMMaker.oscog-eem.146 and see this line: ^(objectMemory integerValueOf: (self headerOf: aMethodObj)) < 0
Isn't that the mark bit for the GC? Or am I confusing something?
#headerOf: should be the first word of every object, right?
And at least in the RoarVM (I doubt that this is different from the standard interpreter), MarkBit is defined as (1 << 31), isn't that exactly the sign bit?
Thanks Stefan
On Wed, Mar 7, 2012 at 1:57 AM, Stefan Marr smalltalk@stefan-marr.dewrote:
Hi Eliot:
On 07 Mar 2012, at 01:47, Eliot Miranda wrote:
But the flag is really useful for VM/image communication.
Right, that's what I want to use it for. Flagged methods will allow me to mark exit points from a special interpretation mode. In that special mode, I enforce certain additional semantics, but need to be able to disable that to get back to the normal mode. The flag seems to be a convenient way to do that.
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.
Ehm, I am not completely with you. I think, I misunderstand something here, which header word exactly?
I looked through the diff of VMMaker.oscog-eem.146 and see this line: ^(objectMemory integerValueOf: (self headerOf: aMethodObj)) < 0
Isn't that the mark bit for the GC? Or am I confusing something?
Yes, you're confusing the object header with the method header, which is unsurprising. herderOf: should really be called methodHeaderOf: but isn't (again history). So this is the sign bit in the method header (a SmallInteger) and is the bit next to the flag bit.
#headerOf: should be the first word of every object, right?
You'd think, but no :)
And at least in the RoarVM (I doubt that this is different from the standard interpreter), MarkBit is defined as (1 << 31), isn't that exactly the sign bit?
Purely coincidental ;)
Thanks Stefan
-- 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
Oops, let me try again, being a little less agricultural.
On Wed, Mar 7, 2012 at 1:57 AM, Stefan Marr smalltalk@stefan-marr.dewrote:
Hi Eliot:
On 07 Mar 2012, at 01:47, Eliot Miranda wrote:
But the flag is really useful for VM/image communication.
Right, that's what I want to use it for. Flagged methods will allow me to mark exit points from a special interpretation mode. In that special mode, I enforce certain additional semantics, but need to be able to disable that to get back to the normal mode. The flag seems to be a convenient way to do that.
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.
Ehm, I am not completely with you. I think, I misunderstand something here, which header word exactly?
I looked through the diff of VMMaker.oscog-eem.146 and see this line: ^(objectMemory integerValueOf: (self headerOf: aMethodObj)) < 0
Isn't that the mark bit for the GC? Or am I confusing something?
Yes, you're confusing the object header with the method header, which is unsurprising. headerOf: should really be called methodHeaderOf: but isn't (again history). So this is the sign bit in the method header (a SmallInteger) and is the bit next to the flag bit.
#headerOf: should be the first word of every object, right?
You'd think, but no :)
And at least in the RoarVM (I doubt that this is different from the standard interpreter), MarkBit is defined as (1 << 31), isn't that exactly the sign bit?
Purely coincidental ;)
Thanks Stefan
vm-dev@lists.squeakfoundation.org