[
https://issues.apache.org/jira/browse/KAFKA-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15691736#comment-15691736
]
Michael Andre Pearce (IG) edited comment on KAFKA-4424 at 11/24/16 12:12 AM:
-----------------------------------------------------------------------------
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.
was (Author: michael.andre.pearce):
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 get 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)
