RE: IGNORE LAST POST; gc not at fault; questions about mutexes vs critical sections

["Boehm, Hans" <hans_boehm at hp dot com>]

Re: GC:
The only obvious anomaly is that you are building the GC with HBLKSIZE=1024,
probably because you are cross-compiling, and hence SMALL_CONFIG is getting
defined.  This is almost certainly wrong for your environment.  SMALL_CONFIG
should not be defined.  This doesn't matter much yet, but will eventually
cost you performance and make it impossible to run the
incremental/generational collector.

Re: Locking:
My impression is that it's quite tricky to implement either pthread-style or
Java-style synchronization with win32 primitives.  See

http://www.cs.wustl.edu/~schmidt/win32-cv-1.html

Condition variables or Object.wait() are the hard part, and they interact
with locking.  The gcj implementation probably needs work.  It's at least
conceivable to me that the fastest implementation would largely bypass the
win32 facilities, and do something along the lines of what linuxthreads does
internally. (You still need to make win32 calls to actually block a thread,
but that should be relatively rare.)

Hans

-----Original Message-----
From: Adam Megacz

I'm going to reimplement win32 locking with Critical Sections (no
kernel-user context switch in the common case) instead of Mutexes -- I
can't see a good reason to stick with Mutexes, since GCJ threads never
need to synchronize across a process boundary, and Mutexes are usually
slower.

Does anybody know why Mutexes were chosen over Critical Sections in
the initial win32 implementation? True, Mutexes offer better
performance if many (4+) threads contend on the same lock, but I would
tend to think that good performance in the common case (unlocked
mutex) would be more important than performance in the highly-locked
case.

  - a