[infinispan-dev] Interceptor stack for local caches

[Radim Vansa]

@ 'very very specific cases':  yes, given the plethora of options 
Infinispan gives you, it is specific. However that does not say that 
these use cases are not the most common.

I don't think this has really too much common with the interceptor stack 
rework discussion - there the move is from vars on thread stack to vars 
in programmatic structure. Still, commands will be allocated and the 
interceptor stack with megamorphic calls as well.

Not sure if I understand the second response, but naturally the 
lightweight implementation would reuse some of the building blocks from 
the reactive Infinispan initiative, if that suits the purpose.

Radim

On 06/22/2015 02:09 PM, Emmanuel Bernard wrote:
> Pushing the idea further, you can actually make the CacheImpl specifically tailored to the configuration of a given cache by using ASM or anything that lets you build a class at runtime.
> That way, in this specialized implementation, all the interceptorImpl.before() and interceptorImpl.after() are specific non megamorphic calls that are optimizable and inline-able by the VM.
>
> And you don’t suffer for the maintenance overhead that Radim was pointing at.
>
> All of these ideas rely on a split of the interceptor logic into before() and after() methods.
>
> Emmanuel
>
>> On 22 Jun 2015, at 07:47, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>
>> BTW, a generic interface based call to interceptors is hard to optimize by the VM AFAIU.
>> So having a few specialized implementations of CacheImpl that do hard code the calls to specific interceptor implementations (the 2 methods split ones) would make a lot of sense to me for a handful of selected cases like you are describing Radim.
>>
>>> On 22 juin 2015, at 07:42, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>>
>>> I am no expect at all of the code base.
>>> Wouldn't returning LocalCacheImpl happening in very very specific cases and thus not be of quite limited use?
>>>
>>> And that resonates with the discussion of splitting the interceptor logic into before and after methods. And keeping the state not in the interceptor but in a type less stack passed to these methods. That would  probably reduce the unnecessary allocation you are seeing. This also opened the doors for moving locks outside the execution thread AFAIR.
>>>
>>> Was this approach ever put on paper even as a few paragraphs somewhere ?
>>>
>>>> On 22 juin 2015, at 07:18, Radim Vansa <rvansa at redhat.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> few weeks ago I was looking into performance of local cache when
>>>> compared to basic concurrent hash map, or data container. I can't find
>>>> the exact results now, but the difference was in order of magnitude -
>>>> IIRC concurrent hash map was about 20x faster than local cache. There
>>>> was no 'bottleneck', but the versatile Infinispan design of commands
>>>> traversing through interceptor stack brings some overhead (e.g.
>>>> allocation costs with each invocation, not only for writes) while in
>>>> some use cases it is not necessary to keep this complexity. The use case
>>>> I am looking for is caching in Hibernate ORM, which basically requires
>>>> only map with eviction, expiration and transactions in some cases. No
>>>> need for cache stores, statistics etc. So far I've found ways to remove
>>>> few interceptors [1], but it's few percent, not hundreds of percent
>>>> where I would ideally aim.
>>>>
>>>> Therefore, I was considering about an option to inspect cache
>>>> configuration and in suitable cases return LocalCacheImpl that would get
>>>> rid of the burden: no interceptor stack, no commands instantiation. This
>>>> would be transparent to the user. I understand that it will increase
>>>> maintenance costs, but it still seems better to me to have it under
>>>> wings of Infinispan as caching solution rather than separate project, as
>>>> it can share a lot of the codebase.
>>>>
>>>> Do you think that this idea makes sense, or is it just too wild? Do you
>>>> think I will crash when trying to implement this?
>>>>
>>>> Radim
>>>>
>>>> [1] https://issues.jboss.org/browse/ISPN-5542
>>>>
>>>> -- 
>>>> Radim Vansa <rvansa at redhat.com>
>>>> JBoss Performance Team
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team