You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Owen O'Malley (JIRA)" <ji...@apache.org> on 2010/07/26 23:09:16 UTC

[jira] Updated: (HADOOP-6881) The efficient comparators aren't always used except for BytesWritable and Text

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

Owen O'Malley updated HADOOP-6881:
----------------------------------

    Attachment: h-6881.patch

This patch does two things:
  1. If a comparator is not defined, forces the class to be initialized by the class loader.
  2. cache the comparator so that we reuse the comparator even if it is the generic one.

> The efficient comparators aren't always used except for BytesWritable and Text
> ------------------------------------------------------------------------------
>
>                 Key: HADOOP-6881
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6881
>             Project: Hadoop Common
>          Issue Type: Bug
>    Affects Versions: 0.20.0
>            Reporter: Owen O'Malley
>            Assignee: Owen O'Malley
>         Attachments: h-6881.patch
>
>
> When we moved from Java 4 to Java 5 (and then 6), there was a change in the JVM semantics such that references to a class such as IntWritable.class no longer forces initialization. Since all of the Writables depend on their class static blocks to register their fast comparators, that can happen *after* we look up the comparator. In that case, the framework will fall back to the generic comparator that deserializes both keys and does the object compare, which may cause a huge slow down in the sort.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.