[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Caspole resolved MAPREDUCE-2629. ------------------------------------- Resolution: Invalid Fix Version/s: 0.23.0 It seems MRv2 removed the classes where this problem was occurring. If I see this pattern arise again I'll file a new bug. > 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 > Fix For: 0.23.0 > > 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