You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "deven you (JIRA)" <ji...@apache.org> on 2010/03/03 10:41:27 UTC

[jira] Created: (HARMONY-6461) [classlib][nio_char]Remove alias cache from Charset

[classlib][nio_char]Remove alias cache from Charset
---------------------------------------------------

                 Key: HARMONY-6461
                 URL: https://issues.apache.org/jira/browse/HARMONY-6461
             Project: Harmony
          Issue Type: Bug
    Affects Versions: 5.0M14
            Reporter: deven you
             Fix For: 5.0M14


At present, when a charset is loaded by a charset name, Charset class will cache all alias of that charset. However it is not a good design because harmony use built-in charset provider and third party providers. We can not ensure one alias only belongs to a unique charset which provided by built-in or 3rd providers. Actually now harmony use built-in and icu provider has already countered such problems with this design. Below charset alias belong to more than one charset:
    TIS-620,
    windows-1258,
    cp856,
    cp922
Now Charset only solve this issue with hard code. I think the correct way to deal with this situation is that when Charset load a charset with a charset name, it should only cache this charset name and the canonical name of the charset, rather than cache all alias of that charset. Follow this way the alias conflict will be solved and there is no need of any hard code anymore.
I have test this patch for many common benchmarks like specjvm2008, specjbb2005, volano and dacapo. It shows there is no performance regression for this design change. So please someone verify this patch. Thanks a lot!

  

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


[jira] Commented: (HARMONY-6461) [classlib][nio_char]Remove alias cache from Charset

Posted by "Hudson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HARMONY-6461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847180#action_12847180 ] 

Hudson commented on HARMONY-6461:
---------------------------------

Integrated in Harmony-1.5-head-linux-x86_64 #708 (See [http://hudson.zones.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/708/])
    

> [classlib][nio_char]Remove alias cache from Charset
> ---------------------------------------------------
>
>                 Key: HARMONY-6461
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6461
>             Project: Harmony
>          Issue Type: Bug
>    Affects Versions: 5.0M14
>            Reporter: deven you
>            Assignee: Regis Xu
>             Fix For: 5.0M14
>
>         Attachments: HY-6461.diff
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> At present, when a charset is loaded by a charset name, Charset class will cache all alias of that charset. However it is not a good design because harmony use built-in charset provider and third party providers. We can not ensure one alias only belongs to a unique charset which provided by built-in or 3rd providers. Actually now harmony use built-in and icu provider has already countered such problems with this design. Below charset alias belong to more than one charset:
>     TIS-620,
>     windows-1258,
>     cp856,
>     cp922
> Now Charset only solve this issue with hard code. I think the correct way to deal with this situation is that when Charset load a charset with a charset name, it should only cache this charset name and the canonical name of the charset, rather than cache all alias of that charset. Follow this way the alias conflict will be solved and there is no need of any hard code anymore.
> I have test this patch for many common benchmarks like specjvm2008, specjbb2005, volano and dacapo. It shows there is no performance regression for this design change. So please someone verify this patch. Thanks a lot!
>   

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


[jira] Updated: (HARMONY-6461) [classlib][nio_char]Remove alias cache from Charset

Posted by "deven you (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HARMONY-6461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

deven you updated HARMONY-6461:
-------------------------------

    Attachment: HY-6461.diff

> [classlib][nio_char]Remove alias cache from Charset
> ---------------------------------------------------
>
>                 Key: HARMONY-6461
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6461
>             Project: Harmony
>          Issue Type: Bug
>    Affects Versions: 5.0M14
>            Reporter: deven you
>             Fix For: 5.0M14
>
>         Attachments: HY-6461.diff
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> At present, when a charset is loaded by a charset name, Charset class will cache all alias of that charset. However it is not a good design because harmony use built-in charset provider and third party providers. We can not ensure one alias only belongs to a unique charset which provided by built-in or 3rd providers. Actually now harmony use built-in and icu provider has already countered such problems with this design. Below charset alias belong to more than one charset:
>     TIS-620,
>     windows-1258,
>     cp856,
>     cp922
> Now Charset only solve this issue with hard code. I think the correct way to deal with this situation is that when Charset load a charset with a charset name, it should only cache this charset name and the canonical name of the charset, rather than cache all alias of that charset. Follow this way the alias conflict will be solved and there is no need of any hard code anymore.
> I have test this patch for many common benchmarks like specjvm2008, specjbb2005, volano and dacapo. It shows there is no performance regression for this design change. So please someone verify this patch. Thanks a lot!
>   

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


[jira] Resolved: (HARMONY-6461) [classlib][nio_char]Remove alias cache from Charset

Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HARMONY-6461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Regis Xu resolved HARMONY-6461.
-------------------------------

    Resolution: Fixed

Thanks Deven!!

Patch was applied at r923557, please verify.

> [classlib][nio_char]Remove alias cache from Charset
> ---------------------------------------------------
>
>                 Key: HARMONY-6461
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6461
>             Project: Harmony
>          Issue Type: Bug
>    Affects Versions: 5.0M14
>            Reporter: deven you
>            Assignee: Regis Xu
>             Fix For: 5.0M14
>
>         Attachments: HY-6461.diff
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> At present, when a charset is loaded by a charset name, Charset class will cache all alias of that charset. However it is not a good design because harmony use built-in charset provider and third party providers. We can not ensure one alias only belongs to a unique charset which provided by built-in or 3rd providers. Actually now harmony use built-in and icu provider has already countered such problems with this design. Below charset alias belong to more than one charset:
>     TIS-620,
>     windows-1258,
>     cp856,
>     cp922
> Now Charset only solve this issue with hard code. I think the correct way to deal with this situation is that when Charset load a charset with a charset name, it should only cache this charset name and the canonical name of the charset, rather than cache all alias of that charset. Follow this way the alias conflict will be solved and there is no need of any hard code anymore.
> I have test this patch for many common benchmarks like specjvm2008, specjbb2005, volano and dacapo. It shows there is no performance regression for this design change. So please someone verify this patch. Thanks a lot!
>   

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


[jira] Closed: (HARMONY-6461) [classlib][nio_char]Remove alias cache from Charset

Posted by "deven you (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HARMONY-6461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

deven you closed HARMONY-6461.
------------------------------


> [classlib][nio_char]Remove alias cache from Charset
> ---------------------------------------------------
>
>                 Key: HARMONY-6461
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6461
>             Project: Harmony
>          Issue Type: Bug
>    Affects Versions: 5.0M14
>            Reporter: deven you
>            Assignee: Regis Xu
>             Fix For: 5.0M14
>
>         Attachments: HY-6461.diff
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> At present, when a charset is loaded by a charset name, Charset class will cache all alias of that charset. However it is not a good design because harmony use built-in charset provider and third party providers. We can not ensure one alias only belongs to a unique charset which provided by built-in or 3rd providers. Actually now harmony use built-in and icu provider has already countered such problems with this design. Below charset alias belong to more than one charset:
>     TIS-620,
>     windows-1258,
>     cp856,
>     cp922
> Now Charset only solve this issue with hard code. I think the correct way to deal with this situation is that when Charset load a charset with a charset name, it should only cache this charset name and the canonical name of the charset, rather than cache all alias of that charset. Follow this way the alias conflict will be solved and there is no need of any hard code anymore.
> I have test this patch for many common benchmarks like specjvm2008, specjbb2005, volano and dacapo. It shows there is no performance regression for this design change. So please someone verify this patch. Thanks a lot!
>   

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


[jira] Assigned: (HARMONY-6461) [classlib][nio_char]Remove alias cache from Charset

Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HARMONY-6461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Regis Xu reassigned HARMONY-6461:
---------------------------------

    Assignee: Regis Xu

> [classlib][nio_char]Remove alias cache from Charset
> ---------------------------------------------------
>
>                 Key: HARMONY-6461
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6461
>             Project: Harmony
>          Issue Type: Bug
>    Affects Versions: 5.0M14
>            Reporter: deven you
>            Assignee: Regis Xu
>             Fix For: 5.0M14
>
>         Attachments: HY-6461.diff
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> At present, when a charset is loaded by a charset name, Charset class will cache all alias of that charset. However it is not a good design because harmony use built-in charset provider and third party providers. We can not ensure one alias only belongs to a unique charset which provided by built-in or 3rd providers. Actually now harmony use built-in and icu provider has already countered such problems with this design. Below charset alias belong to more than one charset:
>     TIS-620,
>     windows-1258,
>     cp856,
>     cp922
> Now Charset only solve this issue with hard code. I think the correct way to deal with this situation is that when Charset load a charset with a charset name, it should only cache this charset name and the canonical name of the charset, rather than cache all alias of that charset. Follow this way the alias conflict will be solved and there is no need of any hard code anymore.
> I have test this patch for many common benchmarks like specjvm2008, specjbb2005, volano and dacapo. It shows there is no performance regression for this design change. So please someone verify this patch. Thanks a lot!
>   

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