Status page

[Loren James Rittle]

In article <3E4318FE000016CB@mail02.agrinet.ch> Andreas writes:
> Completed 3 tests
> Allocated 5212989 collectable objects
> Allocated 306 uncollectable objects
> Allocated 3699653 atomic objects
> Allocated 33000 stubborn objects
> Finalized 6608/6608 objects - finalization is probably ok
> Total number of bytes allocated is 188233964
> Final heap size is 6987776 bytes
> Collector appears to work
> Completed 136 collections
> PASS: gctest
> ==================
> All 1 tests passed
> ==================

Is this result with pending patches to (at least) boehm-gc/configure.in?

If so, then excellent, you are ahead of where I thought you were based
on Hans' statement of undiagnosed mismatch in configurations.  I'd
say/agree that you have the threaded-GC configuration working well
enough to support libjava.

If not (i.e. you are using boehm-gc exactly as in CVS), then I am
confused.  I don't see how Darwin gets GC_PTHREADS defined within
boehm-gc.  Thus, I don't see how it could ever attempt 3 concurrent
tests and report the above.

> With the hopefully coming soon thread support in [libjava?].

Assuming the above report is indeed to threaded-GC on Darwin, take a
close look at this configuration nugget buried in libjava/posix-threads.cc:

// The signal to use when interrupting a thread.
#if defined(LINUX_THREADS) || defined(FREEBSD_THREADS)
  // LinuxThreads (prior to glibc 2.1) usurps both SIGUSR1 and SIGUSR2.
  // GC on FreeBSD uses both SIGUSR1 and SIGUSR2.
#  define INTR SIGHUP
#else /* LINUX_THREADS */
#  define INTR SIGUSR2
#endif /* LINUX_THREADS */

It might be the root cause of test cases involving _Jv_ThreadInterrupt
failing...

Regards,
Loren