Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

Hello,
Just a little update on my test.
I added a clear and gc before each Map instanciation and results are
different:

   - HashMapput:645
   - ConcurrentHashMapput:832
   - ConcurrentReaderHashMapput:620
   - HashMap get:17
   - ConcurrentHashMap get:32
   - ConcurrentReaderHashMap get:60


So it kind of closes the debate, sorry for disturbance.
Regards
Philippe



public class TestMap {

    public static void main(String[] args) {
        StopWatch timer = new StopWatch();

        Map map = new HashMap();
        testPut(timer, map, "HashMap");
        timer.reset();

        map.clear();
        System.gc();
        map = new ConcurrentHashMap();
        testPut(timer, map, "ConcurrentHashMap");
        timer.reset();

        map.clear();
        System.gc();
        map = new ConcurrentReaderHashMap();
        testPut(timer, map, "ConcurrentReaderHashMap");
        timer.reset();


        map.clear();
        System.gc();
        map = new HashMap();
        testGet(timer, map, "HashMap");
        timer.reset();

        map.clear();
        System.gc();
        map = new ConcurrentHashMap();
        testGet(timer, map, "ConcurrentHashMap");
        timer.reset();

        map.clear();
        System.gc();
        map = new ConcurrentReaderHashMap();
        testGet(timer, map, "ConcurrentReaderHashMap");
        timer.reset();
    }

    /**
     * @param timer
     */
    private static void testGet(StopWatch timer, Map map, String type) {
        timer.start();
        for (int i = 0; i < 1000000; i++) {
            map.get(i);
        }
        timer.stop();
        System.out.println(type+" get:"+timer.getTime());
    }

    /**
     * @param timer
     */
    private static void testPut(StopWatch timer, Map map, String type) {
        timer.start();
        for (int i = 0; i < 1000000; i++) {
            map.put(i,i);
        }
        timer.stop();
        System.out.println(type+"put:"+timer.getTime());
    }


Regards
Philippe

On Mon, Oct 3, 2011 at 1:37 PM, sebb <[email protected]> wrote:

> On 3 October 2011 12:15, Rainer Jung <[email protected]> wrote:
> > On 02.10.2011 23:17, Philippe Mouawad wrote:
> >> Ok, hope we can do the same.
> >
> > See https://issues.apache.org/jira/browse/XMLBEANS-447
> >
> > We are not the only people, who doubt it's correct to include that class
> ...
> >
> > There was also a discussion some time ago in another ASF project,
> > because the Sun license which is cited by Doug Lea has a "no use in
> > nuclear facilities clause", which make it non-usable as an Open Source
> > license.
> >
> > It looks like we are stuck here.
>
> Yes, apart from the binary option which brings in lots of unneeded code.
>
> > And the mentioning of the Harmony class in the above cited issue is a
> > red herring. Diffing it with the JDK 5 standard ConcurrentHashMap shows
> > little difference, so I doubt it will be much faster (though I didn't
> > inspect the delta in detail).
>
> I think the Harmony class was only mentioned as a means of supporting
> Java 1.4, not as an alternative faster implementation.
>
> >> I must say I don't understand why ConcurrentReaderHashMap is not in JDK.
> >
> > There's a discussion list for JSR166 (the concurrency stuff lead by Doug
> > Lea) mentioned on the JSR 166 page maintained by Doug Lea. So maybe you
> > can post a technical question there (what's the right class that solve
> > the following problem ... and doesn't have sun licensing restrictions).
> >
> > Regards,
> >
> > Rainer
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>


-- 
Cordialement.
Philippe Mouawad.