A simple PIC api

[Julien Ponge]

How is it different from Rémi's construct?

https://code.google.com/p/jsr292-cookbook/source/browse/trunk/inlining-cache/src/jsr292/cookbook/icache/RT.java

(we use that pattern in Golo)

- Julien

> On 09 Mar 2015, at 18:51, Mark Roos <mroos at roos.com> wrote:
> 
> 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 process 
>         Object getTestValue(Callsite site, Object... stackArgs) 
> 
> The fallback returns a testValue and MH to use 
>         Object[] fallback(Callsite site, Object testValue, Object... stackArgs) 
> 
>         where the return value is [Object newTestValue][MethodHandle newMH]  // use case for Tuple 
>                 if(newTestValue != null) lookup.insert(newTest, newMH) 
>                 newMh.invoke() 
>         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. 
> 
> regards 
> mark 
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev