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 <mr...@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@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
