[JBoss JIRA] (ISPN-6062) Remove megamorphic calls when calling next method in interceptor stack
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-6062?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-6062:
------------------------------
Status: Open (was: New)
> Remove megamorphic calls when calling next method in interceptor stack
> ----------------------------------------------------------------------
>
> Key: ISPN-6062
> URL: https://issues.jboss.org/browse/ISPN-6062
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 8.1.0.Final
> Reporter: Radim Vansa
>
> With current acceptor-visitor architecture of interceptor stack, calls to next interceptor use megamorphic interface calls. This is suboptimal as it prohibits the JIT compiler from inlining the calls.
> Since the interceptor stack is not changed very often, we may adapt the code programmatically to call next interceptor directly.
> The solution should verify that interceptor stack is inlined as much as possible with 'common' JVM options - increasing -XX:MaxInlineLevel is viable, while we should not request users to mess with -XX:DesiredMethodLimit. Preferably, -XX:FreqInlineSize and -XX:MaxInlineSize should stay at defaults.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6062) Remove megamorphic calls when calling next method in interceptor stack
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-6062?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-6062:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3931
> Remove megamorphic calls when calling next method in interceptor stack
> ----------------------------------------------------------------------
>
> Key: ISPN-6062
> URL: https://issues.jboss.org/browse/ISPN-6062
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 8.1.0.Final
> Reporter: Radim Vansa
>
> With current acceptor-visitor architecture of interceptor stack, calls to next interceptor use megamorphic interface calls. This is suboptimal as it prohibits the JIT compiler from inlining the calls.
> Since the interceptor stack is not changed very often, we may adapt the code programmatically to call next interceptor directly.
> The solution should verify that interceptor stack is inlined as much as possible with 'common' JVM options - increasing -XX:MaxInlineLevel is viable, while we should not request users to mess with -XX:DesiredMethodLimit. Preferably, -XX:FreqInlineSize and -XX:MaxInlineSize should stay at defaults.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-5857) HotRod client should use the consistent hash in replicated mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5857?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5857:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from ON_QA to VERIFIED
> HotRod client should use the consistent hash in replicated mode
> ---------------------------------------------------------------
>
> Key: ISPN-5857
> URL: https://issues.jboss.org/browse/ISPN-5857
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.1.Final, 8.1.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: hotrod
> Fix For: 8.1.0.Alpha2, 8.1.0.Final
>
>
> The HotRod server assumes that in replicated mode the server accessed by the client doesn't matter, so it doesn't send a consistent hash in the topology updates.
> However, since replicated mode is now implemented on top of distributed mode, hitting the primary owner or another node makes a big difference. We should change the server to send the consistent hash for replicated caches as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6003) Reduce number of allocations
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-6003?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-6003:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from ON_QA to VERIFIED
> Reduce number of allocations
> ----------------------------
>
> Key: ISPN-6003
> URL: https://issues.jboss.org/browse/ISPN-6003
> Project: Infinispan
> Issue Type: Task
> Components: Core, Server
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: performance
> Fix For: 8.1.0.Final
>
>
> Profiling revealed some allocations that are easy to remove:
> * The HotRod operations factory stores a list of flags in a thread-local. The thread-local can be removed, and the flags can be stored in an {{int}}.
> * JGroupsTransport copies the list of members to check if a broadcast should be sent as a unicast, and the copy is then discarded.
> * ExtendedByteBuf could use {{Array.empty}} instead of {{Array[Byte]()}}.
> * DecoratedCache could avoid calling {{Arrays.asList()}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6062) Remove megamorphic calls when calling next method in interceptor stack
by Radim Vansa (JIRA)
Radim Vansa created ISPN-6062:
---------------------------------
Summary: Remove megamorphic calls when calling next method in interceptor stack
Key: ISPN-6062
URL: https://issues.jboss.org/browse/ISPN-6062
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 8.1.0.Final
Reporter: Radim Vansa
With current acceptor-visitor architecture of interceptor stack, calls to next interceptor use megamorphic interface calls. This is suboptimal as it prohibits the JIT compiler from inlining the calls.
Since the interceptor stack is not changed very often, we may adapt the code programmatically to call next interceptor directly.
The solution should verify that interceptor stack is inlined as much as possible with 'common' JVM options - increasing -XX:MaxInlineLevel is viable, while we should not request users to mess with -XX:DesiredMethodLimit. Preferably, -XX:FreqInlineSize and -XX:MaxInlineSize should stay at defaults.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months