harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elena Semukhina" <elena.semukh...@gmail.com>
Subject Re: [classlib][net] java.net.URLClassLoader implementation is not thread-safe
Date Thu, 22 Feb 2007 06:04:46 GMT
Me and Mikhail reached a consensus in improvement of the patch for
https://issues.apache.org/jira/browse/HARMONY-2982. While working on the
patch I found another bug described in
https://issues.apache.org/jira/browse/HARMONY-3207 and Mikhail provided a
patch for it.

We need these patches to be committed now. Could anyone of committers take a
look at them?

Thanks,
Elena

On 2/14/07, Elena Semukhina <elena.semukhina@gmail.com> wrote:
>
>
>
> On 2/8/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> >
> > Elena Semukhina wrote:
> > > On 1/30/07, Geir Magnusson Jr. <geir@pobox.com > wrote:
> > >>
> > >> I have a comment, that I'll bring out to the dev list -
> > >>
> > >> Is there any problem with some other thread adding the entry for
> > >> currentURL while the  if (jf==null) block is doing it's work? That's
> > >> one difference I can see between sync-ing the block, vs just syncing
> > >> the map.
> > >>
> > >> I don't know if it matters, though.
> > >
> > >
> > > This remark is quite relevant. Each thread which gets jf == null for
> > some
> > > URL does the same job on openning connection, getting jar file and
> > putting
> > > it to a map. Block synchronization ensures that this job is done once
> > for
> > > each jar file.
> >
> > In general we would allow the concurrent update of a cache, but in this
> > case it sounds like the cost of a cache miss is very high, so that it
> > may be worth synchronizing.
> >
> > > Moreover, I ran the classloader.StressLoader test on an unpatched
> > build and
> > > see stable hang on a Windows 2CPUx4core machine. Threads are
> > deadlocked
> > > while doing the same job somewhere in
> > >
> > org/apache/harmony/luni/internal/net/www/protocol/jar/JarURLConnection.findJarFile().
> > >
> > > The patch resolves the issue.
> >
> > Does that imply that there is a synchronization problem 'lower down'?
>
>
> I'm not sure that we have a "lower" synchronization problem here. The
> deadlock happens somewhere in internal classes when many threads try to find
> the same file while it needs to be found once. Synchronization on an upper
> level helps avoiding this.
>
> Thanks,
> Elena
>
> Regards,
> > Tim
> >
> > > Mikhail, could you please add some more comments to
> > > https://issues.apache.org/jira/browse/HARMONY-2982?
> > >
> > > Elena
> > >
> > >
> > > geir
> > >>
> > >> On Jan 30, 2007, at 7:48 AM, Mikhail Markov wrote:
> > >>
> > >> > Elena, thanks for the patch!
> > >> > I've reviewed it and posted the comment to this JIRA.
> > >> >
> > >> > Regards,
> > >> > Mikhail
> > >> >
> > >> >
> > >> > On 1/30/07, Elena Semukhina < elena.semukhina@gmail.com> wrote:
> > >> >>
> > >> >> The DRLVM smoke test classloader.StressLoader fails
> > intermittently.
> > >> >> Investigation revealed that java.net.URLClassLoader implementation
> > >> >> does
> > >> >> not
> > >> >> take care of synchronizing on access to its IdentityHashMap field.
> > I
> > >> >> suggested a patch to fix the issue at
> > >> >> https://issues.apache.org/jira/browse/HARMONY-2982.
> > >> >>
> > >> >> Could anyone please take a look and review the patch?
> > >> >>
> > >> >> --
> > >> >> Thanks,
> > >> >> Elena
> > >> >>
> > >> >>
> > >>
> > >>
> > >
> > >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message