[jira] [Updated] (MAPREDUCE-2629) Class loading quirk prevents inner class method compilation

["Eric Caspole (JIRA)" <ji...@apache.org>]

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

Eric Caspole updated MAPREDUCE-2629:
------------------------------------

    Attachment: MAPREDUCE-2629.patch

Hotspot has an -XX option relates to this situation -XX:-
UseFastAccessorMethods, which is likely to be the default in future JDK
versions. The attached patch allows the -UseFastAccessorMethods to
correctly analyze the method and inline the call. The JVM analyses the bytecodes of the getter method and takes the correct action, which it cannot currently do for the access$000 call.

> Class loading quirk prevents inner class method compilation
> -----------------------------------------------------------
>
>                 Key: MAPREDUCE-2629
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-2629
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>          Components: task
>    Affects Versions: 0.21.0, 0.22.0
>            Reporter: Eric Caspole
>            Priority: Minor
>         Attachments: MAPREDUCE-2629.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> While profiling jobs like terasort and gridmix, I noticed that a
> method "org.apache.hadoop.mapreduce.task.ReduceContextImpl.access
> $000" is near the top. It turns out that this is because the
> ReduceContextImpl class has a member backupStore which is accessed
> from an inner class ReduceContextImpl$ValueIterator. Due to the way
> synthetic accessor methods work, every access of backupStore results
> in a call to access$000 to the outer class. For some portion of the
> run, backupStore is null and the BackupStore class has never been
> loaded by the reducer.
> Due to the way the Hotspot JVM inliner works, by default it will not
> inline a short method where the class of of the return value object
> is unloaded - if you use a debug JVM with -XX:+PrintCompilation you
> will see a failure reason message like "unloaded signature classes."
> This causes every call to ReduceContextImpl.access$000 to be executed
> in the interpreter for the handful of bytecodes to return the null
> backupStore.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira