kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Andre Pearce (IG) (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (KAFKA-4424) Make serializer classes final
Date Thu, 24 Nov 2016 00:12:58 GMT

    [ 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 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.


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 do much.

> 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)

Mime
View raw message