A simple PIC api

[Jochen Theodorou]

Am 11.03.2015 15:37, schrieb Remi Forax:
[...]
> Sometime, yes, if you count the frequency of each branch by example,
> here is another code that implements a bimorphic inlining cache that
> expand to a dispatch table local to a callsite if necessary, I think you
> can adapt this code to implement what Mark want quite easily
>
> https://code.google.com/p/jsr292-cookbook/source/browse/trunk/bimorphic-cache/src/jsr292/cookbook/bicache/RT.java

but obviously the DispatchMap case is not something that will be nice to 
performance, or not? I am was wondering how performance would drop if I 
have an array for counting invocations for each part of the cache as 
well as total number of counts and how that would impact performance. 
Because obviously on each invocation I would have to call a little 
method that does the counting as well as an additional guard to cause 
the reorganization once a certain threshold is reached... And I know 
every guard will lower performance.

Anyway... based on Marks initial post as well as Remi's idea I would 
come up with the following... which is mostly an abstraction and 
refactoring of Remi's code.

class InlineCache<T extends MutableCallSite> {
     int MAX_DEPTH = 5
     int depth
     T callsite
     ...
     InlineCache(T callsite) {...}
     public void installCache()
     public final Object internalFallback(...)
     public abstract MH fallback(T callsite, Object[] args)
     public abstract MH megamorphicFallback(T callsite, Object[] args)
     public final MH insert(MH target, MH... tests)
}

in case of a cache miss and max depth not reached fallback is called and 
supposed to call insert for the new target, the method will do the 
integration into the cache, and return a handle you can return from 
fallback. megamorphicFallback would be called in case of maximum depth 
is reached and install for example a virtual dispatch or whatever else. 
installCache would the cache logic as target of the callsite. 
internalFallback would increase the count as well as calling either 
fallback or megamorphicFallback. I didn't want to let the cache extend 
the callsite, since others may need the callsite class for their own 
purposes. Separation could allow for for example using a different cache 
type.

Taking your code from 
https://code.google.com/p/jsr292-cookbook/source/browse/trunk/inlining-cache/src/jsr292/cookbook/icache/RT.java 
basically line 42 would be in internalFallback 43-45 in 
megamorphicFallback, 46-47 in internalFallback, 50-57 in fallback, 56-57 
would be the test given to insert, 59-63 in internalFallback, and of 
course we would not link to fallback, but to internalFallback

What do you guys think?

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org