Method caches
Dan Sugalski
First important note: I've never done this before (I think my
antipathy towards objects might've given everyone just the tiniest
clue :) so pointers to good docs and papers on this would be much
appreciated.
My current thinking, based entirely on the "Hmmm, if I had no clue
there was any history here, what would I do?" school of design, is to
do this:
Method cache is an array of arrays of cache entries.
Top level index is the class number.
Second level index is bits 2-10 of the method name string (the actual
string, mind--we use the bufstart address) shifted right two bits to
give us a single byte offset.
Third is a set of structs that look like:
bufaddr
string (maybe)
pmc ptr
next
When we get to the list, we run through it looking for entries that
match. If we find one, yay, we're done. If not, we do a slow search,
find the entry, and put it in the cache.
This presupposes that the method names are all constant, shared
strings. I think this is reasonable, and I'm OK adding in some code
to the namespace store to make *sure* that it's the case.
This seems... too simple, so I'm sure I'm missing something besides
the potential massive memory usage. So, by all means, have at it.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Dan Sugalski
>Dan Sugalski wrote in perl.perl6.internals :
>>
>> This seems... too simple, so I'm sure I'm missing something besides
>> the potential massive memory usage. So, by all means, have at it.
>
>method cache : introduction of a new class, of a new method,
>modification of the inheritance hierarchy, destruction of a whole class.
>Not mentioning autoloaded methods.
Currently I'm figuring on just nuking the whole cache in any of these
cases. Later on we can consider doing Clever Things, if it seems
worthwhile.
Rafael Garcia-Suarez
>
> the potential massive memory usage. So, by all means, have at it.
You'll need to worry about actions that invalidate all or part of the
Larry Wall
: Currently I'm figuring on just nuking the whole cache in any of these
: worthwhile.
That's what Perl 5 does, FWIW. But you're caching scheme seems way
too complicated to me. In Perl 5, you cache the method simply by
making it look like it's a member of the current class. There's very
little extra mechanism. You just have to know which methods are the
"fake" ones you can blow away.
Admittedly MMD complicates things, but maybe that's a separate cache.
Larry
Mark A Biggar
--
Mark Biggar
mark.a...@comcast.net
> Okay, so it's method cache time.
>
> First important note: I've never done this before (I think my
> antipathy towards objects might've given everyone just the tiniest
> clue :) so pointers to good docs and papers on this would be much
> appreciated.
>
> My current thinking, based entirely on the "Hmmm, if I had no clue
> there was any history here, what would I do?" school of design, is to
> do this:
>
> Method cache is an array of arrays of cache entries.
> This seems... too simple, so I'm sure I'm missing something besides
> the potential massive memory usage. So, by all means, have at it.
teddy bears get drunk
Piers Cawley
> On Wed, Mar 17, 2004 at 12:41:20PM -0500, Dan Sugalski wrote:
> : Currently I'm figuring on just nuking the whole cache in any of these
> : cases. Later on we can consider doing Clever Things, if it seems
> : worthwhile.
>
> That's what Perl 5 does, FWIW. But you're caching scheme seems way
> too complicated to me. In Perl 5, you cache the method simply by
> making it look like it's a member of the current class. There's very
> little extra mechanism. You just have to know which methods are the
> "fake" ones you can blow away.
And this is why Perl 5 can't work out SUPER:: type stuff at
runtime. It's possible through cleverness to find out where you were
found the *first* time you're called, but the information isn't
retained in the cache. Which is a complete and utter PITA.
Larry Wall
Fair enough. I'm all in favor of sweeping PITAs from Perl into C. :-)
Larry