Hash synchronization patch

Boehm, Hans hans_boehm@hp.com
Fri Feb 9 16:36:00 GMT 2001


Thanks.

That's encouraging, so long as we can track down the problem(s).

I assume this was on Linux/X86?

> -----Original Message-----
> From: Jeff Sturm [ mailto:jeff.sturm@commerceone.com ]
> Sent: Friday, February 09, 2001 4:00 PM
> To: Boehm, Hans
> Cc: 'java@gcc.gnu.org'
> Subject: Re: Hash synchronization patch
> 
> 
> "Boehm, Hans" wrote:
> > Here's my current version of the hash synchronization 
> patch.  It passes my
> > (pretty basic) tests on Linux/X86.  It is against a recent 
> tree, so it
> > should hopefully apply to the current CVS tree.
> 
> I evaluated this patch on some of our application code.  I 
> was able to complete
> the tests, with a nearly 50% performance improvement overall 
> running on a
> uniprocessor (results are number of HTTP transactions per 
> second, concurrency is
> the number of simultaneous threads):
> 
>                  standard         hash sync
> 
> Concurrency | Requests / sec. | Requests / sec.
> ------------+-----------------+------------------
>      1      |      10.1       |      14.7  (+46%)
>      2      |      10.2       |      15.2  (+49%)
>      4      |       9.7       |      14.4  (+48%)
> 
> Heap usage was also slightly lower, and GC intervals around 
> %30 shorter than
> before.
> 
> However the application was not stable.  On roughly 50% of my 
> attempts the
> program deadlocked on startup with a 
> java.lang.IllegalMonitorStateException.  It
> was also prone to deadlock if any threads were running during 
> a System.gc(). 
That one may be nontrivial to track down.  That's the canonical symptom of
any bug in the locking algorithm.

It would be useful to know exactly where (in natObject.cc) the exception is
being raised.  It can be raised by monitor entry, monitor exit,
Object.wait(), and the notify variants.  For some of them it can be raised
under several different conditions.  It would also be nice to know the
values of locals, and particularly the fields in the structure *he where the
exception is raised.  (Of course, in an ideal world, I'd like a test case I
can run here.  If this is narrowed down a bit, I might be able to get
there.)

> Here's one interesting message I haven't seen before:
> 
> Finalization cycle involving 89b14d0
> Finalization cycle involving 81013c0
> Finalization cycle involving 8101440
> Finalization cycle involving 808af50
Oops.  I think if you change the GC_register_finalizer call in
natObject.cc:607 to call GC_REGISTER_FINALIZER_NO_ORDER, this will go away.
I fixed it in my tree.  It can also safely be ignored for now, since it just
introduces a memory leak, and probably a very minor one.  It's unrelated to
the other problem.
> 
> --
> Jeff Sturm
> jeff.sturm@commerceone.com
> 



More information about the Java mailing list