Hi Rémi,
I assume you want me to be more specific about my concerns on:
taking into account invalidation, multi core memory model and
volatile state.
My model is that I have a GWT chain, a cache, and a fallback which is
updating the chain, and more
than one core using the same callsit
Hi Jochen
I have to think about yours some more but I thought I would share mine. I
condensed it to
make it easier to explain.
regards
mark
I extended callsite to hold a bunch of values one of which is the depth.
And my model for the cache is up to 10 chained GWTs after that I drop the
chain
On 03/11/2015 11:12 PM, Mark Roos wrote:
Remi commented
I think you can adapt this code to implement what Mark want quite easily
I don't disagree that pics are easy to code, my premise is that with a
construct such I
I proposed the jvm would do a better job of optimizing. Especially
taking
On 03/11/2015 11:12 PM, Mark Roos wrote:
From Jochen
Do I also understand right, that your test for checking if the current
target is still valid is limited to only the receiver?
Well yes and no. In my case the test examines all of the arguments on
the stack and computes
an 'behavior' refere
Remi commented
I think you can adapt this code to implement what Mark want quite easily
I don't disagree that pics are easy to code, my premise is that with a
construct such I
I proposed the jvm would do a better job of optimizing. Especially taking
into account
invalidation, multi core memory
>From Jochen
Do I also understand right, that your test for checking if the current
target is still valid is limited to only the receiver?
Well yes and no. In my case the test examines all of the arguments on the
stack and computes
an 'behavior' reference. This reference is the head of a link
Hi Jochen
uses basically guardWithTest, so the order of the handles is never
changed to for example trying the last one first or the one with the
most hits recently. Is it not worth the trouble?
In my case I always add the new gwt to the head of the chain. This fits
my use case where
the most
> so the order of the handles is never changed to for example trying the last
> one first or the one with the most hits recently. Is it not worth the trouble?
We found a useful gain at one point from reordering GWT chains so that the new
MH was put on the end of the chain and the chain as a whol
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 M
On 03/11/2015 03:00 PM, Jochen Theodorou wrote:
Am 11.03.2015 14:46, schrieb Jochen Theodorou:
[...]
I really should write a PIC implementation for Groovy :(
actually picking up on that maybe you guys could give some advice
about how to structure a PIC internally.
https://code.google.c
Am 11.03.2015 14:46, schrieb Jochen Theodorou:
[...]
I really should write a PIC implementation for Groovy :(
actually picking up on that maybe you guys could give some advice
about how to structure a PIC internally.
https://code.google.com/p/jsr292-cookbook/source/browse/trunk/inlining-
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 s
The overhead is negligible in my micro-benchmarks for monomorphic and
trimorphic call sites compared to regular Java virtual calls.
- Julien
On Tue, Mar 10, 2015, at 18:25, Mark Roos wrote:
> From Julian
>
> That being said performance of the PIC construct is very good in our
> case.
>
>
13 matches
Mail list logo
