On Thu, Aug 10, 2000 at 06:30:01PM -0400, Chaim Frenkel wrote:
> >>>>> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
> GB> On Thu, Aug 10, 2000 at 04:54:25PM -0400, Dan Sugalski wrote:
> >> At 08:31 PM 8/10/00 +0000, Nick Ing-Simmons wrote:
> >> >You just re-invented "look up the name in a hash table" ;-)
> >> >
> >> >You now have one big hash table rather than several small ones.
> >> >Which _may_ give side benefits - but I doubt it.
> >>
> >> If we prefigure a bunch of things (hash values of method names, store
> >> package stash pointers in objects, and pre-lookup CVs for objects that are
> >> typed) it'll save us maybe one level of pointer indirection and a type
> >> comparison. If the object isn't the same type we pay for a type comparison
> >> and hashtable lookup.
> >>
> >> Not free, but not expensive either. 'Specially if we get way too clever and
> >> cache the new CV and type in the opcode for the next time around, presuming
> >> we'll have the same type the next time through.
>
> GB> Or if someone has defined a new sub, you don't know it was not the
> GB> one you stashed.
>
> Leave a stub behind at the old address that would trigger the repointing.
> (I'm not clear what to do for refcounting the old address)
That will only work if the sub being defined is the one that is cached.
Consider....
A isa B
B isa C
we have an object of type A and the cached sub `foo' was originally found
in C. Then someone defines `foo' in B.
However that is not to say that something along those lines could not work.
> I don't think anything should be in the op tree. The optree (or whatever
> the engine is) should only be operations. Data should be either in the
> object, vtbl, or stack.
The optree needs to know what to perform. an op_call_method needs
to know which method.
Graham.
