[jira] Commented: (HARMONY-5929) [classlib][pack200][performance] Segment.computeIcStored rewrite

["Aleksey Shipilev (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HARMONY-5929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622350#action_12622350 ] 

Aleksey Shipilev commented on HARMONY-5929:
-------------------------------------------

Aha! It seems my code is not semantically equivalent to original code. Given the ic_local and Ic_relevant sets (they're lists backed by sets):
 - original code computes: result = ic_local XOR ic_relevant [1]
 - my code computes: result = ic_local OR ic_relevant

Hence the excess lines in the log I guess. 
Sian, could you please confirm that XOR is really required?

[1] That's deduced from
        for(int i = 0; i < resultCopy.size(); i++) {
            IcTuple tuple = (IcTuple) resultCopy.get(i);
            if (localList.contains(tuple) && relevantList.contains(tuple)) {
                while (result.remove(tuple));
            }
        }

> [classlib][pack200][performance] Segment.computeIcStored rewrite
> ----------------------------------------------------------------
>
>                 Key: HARMONY-5929
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5929
>             Project: Harmony
>          Issue Type: Improvement
>          Components: Classlib
>         Environment: Latest pack200
>            Reporter: Aleksey Shipilev
>            Assignee: Sian January
>         Attachments: DriverManagerTest.BadDummyDriver.out, pack200-computeIcStored-v1.patch
>
>
> Current implementation of Segment.computeIcStored is heavily inefficient.
> This issue rewrites this method from scratch.

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