Do I also understand right, that your test for checking if the current
target is still valid is limited to only the receiver?
Well yes and no. In my case the test examines all of the arguments on the
stack and computes
an 'behavior' reference. This reference is the head of a linked list of
method dictionaries which
the fallback searches to locate the code for this callsite and that
behavior. The yes part is that
in my Smalltalk the behavior is stored in a field of the object on the top
of the stack. This happens
to be the receiver.
For the proposed api the test can examine the entire stack and callsite to
determine the dispatch.
I do plan to support multi methods which could be an expensive test. I
just wanted to do it once
regardless of the number of guards.
I also do special
things to not add guards if I can, since each guard costs...
information I use there is static so far
I would expect in a perfect world for the guards to be cheap if the jvm
knew the were part of
mlvm-dev mailing list