This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dl_iterate_phdr() deadlock patch


Mark Wielaard writes:
 > Hi,
 > 
 > On Tue, 2003-02-25 at 21:19, Boehm, Hans wrote:
 > > Request: could someone who has seen the dl_iterate_phdr() deadlocks
 > > test this berfore I check it in?
 > 
 > I was seeing this with the SyncTest running under gij and with Eclipse.
 > Sadly Eclipse doesn't seem to run anymore with recent gcj, I haven't
 > figured out yet what goes wrong, but it has nothing todo with this
 > patch. 
 > 
 > SyncTest doesn't deadlock anymore with this patch. But for reasons
 > outlined in http://gcc.gnu.org/ml/java/2003-01/msg00297.html this test
 > is now so slow that it will always timeout. For my tests I decreased the
 > counter from 1 milion to 100,000 (with 4 threads) and then it still
 > takes 20 minutes to complete. But at least it completes.
 > 
 > I am not sure what todo about the test. We can follow the suggestion of
 > Jeff Sturm and move the SyncTest.class contruct out of the for loop.
 > 
 > But the real problem is that a simple program like the following takes
 >    0.050s    with gij 3.2, but
 >   21.410s(!) with gij 3.3
 > 
 > public class CFN
 > {
 >   public static void main(String[] args) throws Exception
 >   {
 >     for (int i = 0; i < 5000; i++)
 >       Class.forName("CFN");
 >   }
 > }
 > 
 > Need to investigate what contributes to this slowdown.

Class.forName wasn't standard compliant before in that it didn't use
the caller's class loader.  It does now.

Compiled code takes 0.120s on my machine.  Interpreted code takes
about 40s.  I think my libgcj was build with -O0.

So, because the compiled code is 0.120s, the problem cannot be in the
call to Class.forName().  However, Class.forName calls
StackTrace.classAt(), which is more expensive for interpreted code.

I have just noticed that _Unwind_IteratePhdrCallback() is calling
linear_search_fdes.  This is very bad.  This should only ever happen
if there is insufficient memory to allocate and sort an array.  

It seems like _Unwind_Find_registered_FDE is failing.  I don't know
why this is.  However, even with all this weirdness, the fully
compiled version is not terribly slow.

I guess we need to profile the code.

Althernatively, we could easily disable the call to StackTrace in
Class.forName() and see what happens.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]