[ 
https://issues.apache.org/jira/browse/KAFKA-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Andre Pearce (IG) updated KAFKA-4424:
---------------------------------------------
    Comment: was deleted

(was: Just reading the link you reference.

Virtual calls and jump tables is monomorphic vs polymorphic calls.

If only one implementation(this implementation being final or not) of an 
interface is loaded then you will get a monomorphic implementation and it can 
be fully inlined. 

If you load another, your method is inlined but with a branch, once you load 
further hotspot will do on stack replacement and this is when jump tables are 
needed.

You can see this occurring with on stack replacement with 
-XX:+PrintCompilation, as classes are loaded.

A classical test case showing this:
http://mechanical-sympathy.blogspot.co.uk/2012/04/invoke-interface-optimisations.html

You'll note that making the class's final or not in the test, makes no 
difference to the outcome.

In case of serialisers/deserialisers this is our case as we have an interface 
that is implemented, as such making these implementations final doesn't help, 
as all reference by calling classes are invoking methods on the interface, as 
such its performance is about how many implementations are loaded.)

> Make serializer classes final
> -----------------------------
>
>                 Key: KAFKA-4424
>                 URL: https://issues.apache.org/jira/browse/KAFKA-4424
>             Project: Kafka
>          Issue Type: Improvement
>          Components: clients
>            Reporter: Matthias Bechtold
>            Priority: Minor
>
> Implementations of simple serializers / deserializers should be final to 
> prevent JVM method call overhead.
> See also:
> https://wiki.openjdk.java.net/display/HotSpot/VirtualCalls
> This breaks the API slightly, inheritors must change to generic interfaces 
> Serializer / Deserializer. But architecture-wise final serialization classes 
> make the most sense to me.
> So what do you think?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to