Re: Method caches
On Thu, Mar 18, 2004 at 05:25:00PM +, Piers Cawley wrote: : Larry Wall <[EMAIL PROTECTED]> writes: : : > 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. Fair enough. I'm all in favor of sweeping PITAs from Perl into C. :-) Larry
Re: Method caches
Larry Wall <[EMAIL PROTECTED]> writes: > 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.
Re: Method caches
Don't forget about cache invalidation on dynamic method redefinition. -- Mark Biggar [EMAIL PROTECTED] > 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
Re: Method caches
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. Admittedly MMD complicates things, but maybe that's a separate cache. Larry
Re: Method caches
At 5:31 PM + 3/17/04, Rafael Garcia-Suarez wrote: 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. You'll need to worry about actions that invalidate all or part of the 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. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Method caches
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. You'll need to worry about actions that invalidate all or part of the 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.
Method caches
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. 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 [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
