Request for Comment: MethodAnnotations for 3.9alpha
Marcus Denker
denker at iam.unibe.ch
Sun Aug 28 12:41:00 UTC 2005
Hello squeakers,
Of the long and exiting list of things that are in consideration for
3.9a, one is MethodAnnotations.
This is a changeset that was done by Andreas long time ago (2002, I
think) and it's used extensively
in Tweak. At SCG, we have used it for ByteSurgeon and are using it
for another ongoing project.
What are MethodAnnotations?
---------------------------------------
MethodAnnotations can be seen from two perspectives:
1) storing state in CompiledMethod objects.
In Squeak, CompiledMethod is a strange class. One thing you can't
do is adding an instance variable. This makes experimentation awfully
complicated, e.g. people made hacks to store state in the literalFrame
or in class vars... see MethodWrappers for an example.
MethodAnnotations just provides a general, nice and easy way to store
stuff in compiledMethods, no need for hacks anymore.
e.g. store:
(Object>>#halt) setProperty: #hello toValue: 5.
and read:
(Object>>#halt) valueOfProperty: #value;
2) Syntax for Method Annotations.
We can set annoations to methods using the syntax we already
know for primitives
(which are, in a sense, just an annotation):
Object>>mumble
<hello: 4>
Tweak uses these annotations to describe when a method should be
activated.
How are they implemented?
--------------------------------------
Andreas' orginal implemention used a big WeakIdentityKeyDictionary in
a class var
of CompiledMethods to store the IdentityDictionary for each method.
This turns
out to have some nice properties (no space is used for non-annotated
methods) and
a bad one: Performance. For ByteSurgeon, after annotation all methods
(40.000), it
was unusably slow.
So we hacked a version that used the literealFrame instead, after
discussing this with
Andreas, we now use the second-last literal Frame entry. The
reasoning is the following:
The first one is already used for some primitives, the last one
encodes the class in the
case that there is a supersend in the method.
So if we use the last entry to store the class for each method
(supered or not), we can
put the annoations in the one before and don't need to test for
anything. Putting the class
(or Trait) in the last litereal has the nice side-effect of making a
fast #who possible.
The changesets attached are a first step: We are right now adding the
class binding
to all methods but quickmethods (need to fix that), the second last
literal is initialized
with nil and will lazy initalize the property dictionary if it's
accessed.
Please note that the attached changesets need to be files in in-order
and the first
one will recompile the whole image.
Filling the last literal with the class (or trait) for all methods
will be done in an addional step
after the annotation cs is in 3.9. Then we will change the
implementation of compiledMethod>>who
to use this information.
Any comments? Does anyone see a problem with the annotations itself
or the implementation?
Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Annot.zip
Type: application/zip
Size: 6954 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050828/9282a27d/Annot.zip
-------------- next part --------------
More information about the Squeak-dev
mailing list
|