A simple PIC api

Jochen Theodorou blackdrag at gmx.org
Wed Mar 11 13:46:08 UTC 2015


Am 09.03.2015 18:51, schrieb Mark Roos:
> 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.

Do I also understand right, that your test for checking if the current 
target is still valid is limited to only the receiver?

> 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.

I really should write a PIC implementation for Groovy :( Though it won't 
be as simple as this one. I need to check for arguments which can be 
primitives) and receiver as well as meta class (switchpoint for that 
one) So not only do I have to check more things, I also do special 
things to not add guards if I can, since each guard costs... though the 
information I use there is static so far.

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



More information about the mlvm-dev mailing list