You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-issues@hadoop.apache.org by "Eric Caspole (JIRA)" <ji...@apache.org> on 2011/06/29 00:07:28 UTC
[jira] [Created] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
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
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
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13056831#comment-13056831 ]
Todd Lipcon commented on MAPREDUCE-2629:
----------------------------------------
Seems reasonable, and thanks for teaching me something new about JVM performance :) Do you have some benchmark that shows a difference here?
> 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
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Hudson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132354#comment-13132354 ]
Hudson commented on MAPREDUCE-2629:
-----------------------------------
Integrated in Hadoop-Mapreduce-0.23-Commit #34 (See [https://builds.apache.org/job/Hadoop-Mapreduce-0.23-Commit/34/])
MAPREDUCE-2629. Workaround a JVM class loading quirk which prevents JIT compilation of inner classes methods in ReduceContextImpl. Contributed by Eric Caspole.
todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1187182
Files :
* /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/CHANGES.txt
* /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/task/ReduceContextImpl.java
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Hadoop QA (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131982#comment-13131982 ]
Hadoop QA commented on MAPREDUCE-2629:
--------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12499918/mr-2629.txt
against trunk revision .
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified tests.
Please justify why no new tests are needed for this patch.
Also please list what manual steps were performed to verify this patch.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac compiler warnings.
-1 findbugs. The patch appears to introduce 160 new Findbugs (version 1.3.9) warnings.
+1 release audit. The applied patch does not increase the total number of release audit warnings.
+1 core tests. The patch passed unit tests in .
+1 contrib tests. The patch passed contrib unit tests.
Test results: https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/1087//testReport/
Findbugs warnings: https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/1087//artifact/trunk/hadoop-mapreduce-project/patchprocess/newPatchFindbugsWarningshadoop-mapreduce-client-common.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/1087//artifact/trunk/hadoop-mapreduce-project/patchprocess/newPatchFindbugsWarningshadoop-mapreduce-client-app.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/1087//artifact/trunk/hadoop-mapreduce-project/patchprocess/newPatchFindbugsWarningshadoop-mapreduce-client-core.html
Console output: https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/1087//console
This message is automatically generated.
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "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
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Hudson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132653#comment-13132653 ]
Hudson commented on MAPREDUCE-2629:
-----------------------------------
Integrated in Hadoop-Hdfs-trunk #837 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk/837/])
MAPREDUCE-2629. Workaround a JVM class loading quirk which prevents JIT compilation of inner classes methods in ReduceContextImpl. Contributed by Eric Caspole.
todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1187183
Files :
* /hadoop/common/trunk/hadoop-mapreduce-project/CHANGES.txt
* /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/task/ReduceContextImpl.java
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Hudson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132357#comment-13132357 ]
Hudson commented on MAPREDUCE-2629:
-----------------------------------
Integrated in Hadoop-Common-0.23-Commit #34 (See [https://builds.apache.org/job/Hadoop-Common-0.23-Commit/34/])
MAPREDUCE-2629. Workaround a JVM class loading quirk which prevents JIT compilation of inner classes methods in ReduceContextImpl. Contributed by Eric Caspole.
todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1187182
Files :
* /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/CHANGES.txt
* /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/task/ReduceContextImpl.java
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Todd Lipcon (Reopened) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon reopened MAPREDUCE-2629:
------------------------------------
I'm still seeing this in MRv2
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Todd Lipcon (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131985#comment-13131985 ]
Todd Lipcon commented on MAPREDUCE-2629:
----------------------------------------
findbugs are bogus. No tests since this is covered by existing tests. I successfully ran several terasorts with this patch.
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Hudson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132346#comment-13132346 ]
Hudson commented on MAPREDUCE-2629:
-----------------------------------
Integrated in Hadoop-Mapreduce-trunk-Commit #1144 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Commit/1144/])
MAPREDUCE-2629. Workaround a JVM class loading quirk which prevents JIT compilation of inner classes methods in ReduceContextImpl. Contributed by Eric Caspole.
todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1187183
Files :
* /hadoop/common/trunk/hadoop-mapreduce-project/CHANGES.txt
* /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/task/ReduceContextImpl.java
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Hudson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132359#comment-13132359 ]
Hudson commented on MAPREDUCE-2629:
-----------------------------------
Integrated in Hadoop-Common-trunk-Commit #1128 (See [https://builds.apache.org/job/Hadoop-Common-trunk-Commit/1128/])
MAPREDUCE-2629. Workaround a JVM class loading quirk which prevents JIT compilation of inner classes methods in ReduceContextImpl. Contributed by Eric Caspole.
todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1187183
Files :
* /hadoop/common/trunk/hadoop-mapreduce-project/CHANGES.txt
* /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/task/ReduceContextImpl.java
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Todd Lipcon (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon reassigned MAPREDUCE-2629:
--------------------------------------
Assignee: Eric Caspole
Eric: Would you mind updating this against the current trunk? Profiling a running MRv2 terasort I'm seeing this use a significant amount of CPU
> 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
> Assignee: 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Hudson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132365#comment-13132365 ]
Hudson commented on MAPREDUCE-2629:
-----------------------------------
Integrated in Hadoop-Hdfs-trunk-Commit #1206 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk-Commit/1206/])
MAPREDUCE-2629. Workaround a JVM class loading quirk which prevents JIT compilation of inner classes methods in ReduceContextImpl. Contributed by Eric Caspole.
todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1187183
Files :
* /hadoop/common/trunk/hadoop-mapreduce-project/CHANGES.txt
* /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/task/ReduceContextImpl.java
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Todd Lipcon (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon updated MAPREDUCE-2629:
-----------------------------------
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Committed to 23 and trunk. Thanks, Eric!
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Todd Lipcon (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon updated MAPREDUCE-2629:
-----------------------------------
Attachment: mr-2629.txt
the CPU usage was bugging me so I rebased Eric's patch last night.
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Eric Caspole (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057856#comment-13057856 ]
Eric Caspole commented on MAPREDUCE-2629:
-----------------------------------------
On my test system I see about 2% cpu time in that method, which is removed with various versions of the patch. But since I spend a lot of time in I/O wait I cannot see an improvement in the wall clock run time of, say, a 8gb terasort.
I think this patch can be improved, I'll update it after I get back from vacation.
> 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
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Hudson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132621#comment-13132621 ]
Hudson commented on MAPREDUCE-2629:
-----------------------------------
Integrated in Hadoop-Hdfs-0.23-Build #46 (See [https://builds.apache.org/job/Hadoop-Hdfs-0.23-Build/46/])
MAPREDUCE-2629. Workaround a JVM class loading quirk which prevents JIT compilation of inner classes methods in ReduceContextImpl. Contributed by Eric Caspole.
todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1187182
Files :
* /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/CHANGES.txt
* /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/task/ReduceContextImpl.java
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Hudson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132361#comment-13132361 ]
Hudson commented on MAPREDUCE-2629:
-----------------------------------
Integrated in Hadoop-Hdfs-0.23-Commit #34 (See [https://builds.apache.org/job/Hadoop-Hdfs-0.23-Commit/34/])
MAPREDUCE-2629. Workaround a JVM class loading quirk which prevents JIT compilation of inner classes methods in ReduceContextImpl. Contributed by Eric Caspole.
todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1187182
Files :
* /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/CHANGES.txt
* /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/task/ReduceContextImpl.java
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "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 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
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Hudson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132647#comment-13132647 ]
Hudson commented on MAPREDUCE-2629:
-----------------------------------
Integrated in Hadoop-Mapreduce-0.23-Build #58 (See [https://builds.apache.org/job/Hadoop-Mapreduce-0.23-Build/58/])
MAPREDUCE-2629. Workaround a JVM class loading quirk which prevents JIT compilation of inner classes methods in ReduceContextImpl. Contributed by Eric Caspole.
todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1187182
Files :
* /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/CHANGES.txt
* /hadoop/common/branches/branch-0.23/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/task/ReduceContextImpl.java
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Hudson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132641#comment-13132641 ]
Hudson commented on MAPREDUCE-2629:
-----------------------------------
Integrated in Hadoop-Mapreduce-trunk #867 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk/867/])
MAPREDUCE-2629. Workaround a JVM class loading quirk which prevents JIT compilation of inner classes methods in ReduceContextImpl. Contributed by Eric Caspole.
todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1187183
Files :
* /hadoop/common/trunk/hadoop-mapreduce-project/CHANGES.txt
* /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/task/ReduceContextImpl.java
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Todd Lipcon (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon updated MAPREDUCE-2629:
-----------------------------------
Target Version/s: 0.23.0
Status: Patch Available (was: Reopened)
> 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
> Assignee: Eric Caspole
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2629.patch, mr-2629.txt
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-2629) Class loading quirk prevents
inner class method compilation
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057956#comment-13057956 ]
Todd Lipcon commented on MAPREDUCE-2629:
----------------------------------------
OK. I'm happy to +1 as is, but if you think there's an improvement, I'll hold off. Enjoy your vacation.
> 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