I was thinking about a generic pic, easy to use but flexible and came up 
with the following concept api.
By passing the callsite and the testValue around with allowing an optional 
pic update I can envision
this as a nice building block for several caching strategies.  Of course 
this is all based on my use
model which does not use primitives.  In summary it reduces the calling of 
the test method to only
once and it supports the quick testing of a few targets.  Its also easy to 
understand how to use without
using Charlies or Remis builders.

to generate a PIC
        MethodHandle createPic(Callsite site, MethodHandle getTestValue, 
MethodHandle fallback)

The getTestValue methodHandle returns the object used in the comparison 
        Object getTestValue(Callsite site, Object... stackArgs)

The fallback returns a testValue and MH to use
        Object[] fallback(Callsite site, Object testValue, Object... 

        where the return value is [Object newTestValue][MethodHandle 
newMH]  // use case for Tuple
                if(newTestValue != null) lookup.insert(newTest, newMH)
        This path should also be considered fast as the first step of a 
fallback could be to check a cache of MH.

the lookup process could be a simple chain of compare/branch operations. 
And the mh replacement could be
a simple circular update.  This chain could be limited to less than 5.


mlvm-dev mailing list

Reply via email to