[
https://issues.apache.org/jira/browse/HADOOP-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703976#action_12703976
]
Chris Douglas commented on HADOOP-5727:
---------------------------------------
As pointed out, the patch returns exactly what Integer::hashCode did, so the
fix only removes the object alloc (which is probably also optimized out, but
returning {{id}} is clearer). The supplemental hashing in HashMap is
interesting; purely out of curiosity, do you happen to have any references for
broader, J2SE changes?
bq. HashMap is a list-hash, so consecutive hashes followed by a hash collision
does not cause a walk of a long linear hash chain.
Are you sure? The openjdk6
[source|http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/a42d6999734b/src/share/classes/java/util/HashMap.java]
appears to create/walk a list for collisions (addEntry/get)...
The current patch looks good, but the comments keep context for this particular
fix. Would you mind removing them?
> Faster, simpler id.hashCode() which does not allocate memory
> ------------------------------------------------------------
>
> Key: HADOOP-5727
> URL: https://issues.apache.org/jira/browse/HADOOP-5727
> Project: Hadoop Core
> Issue Type: Improvement
> Components: mapred
> Reporter: Shevek
> Assignee: Shevek
> Attachments: 00_id-noallocate.patch, 03_id-noallocate.patch
>
>
> Integer.valueOf allocates memory if the integer is not in the object-cache,
> which is the vast majority of cases for the task id. It is possible to
> compute the hash code of an integer without going via the integer cache, and
> hence avoiding allocating memory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
