PATCH: Various GC fixes

[Boehm, Hans]

I'm not sure whether the following is appropriate for the trunk at this
stage.  This patch was originally motivated by Andreas Tobler's work
on porting gcj to HP/UX.  But in that process I also compared the gcc
"boehm-gc" tree to the current upstream tree, looking for any important
patches that hadn't made it.  I'm open to checking in only parts of
this, if that's the wish.

I'm doing more testing, but it passed initial tests on IA64.  Much, though
not all, of this is in GC6.4.  (I did not include GC6.4 changes which I
did not think would affect basic correctness on already supported platforms.)
All of it is in my current upstream tree.

OK for trunk?

2005-02-07  Hans Boehm  <Hans.Boehm@hp.com>

	* allchblk.c (GC_allochblk_nth): Dont overlook available space if
	  GC disabled, correctly convert GC_finalizer_mem_freed to byte,
	  total_size to words.
	* dyn_load.c (win32 GC_register_dynamic_libraries): Consider only
	  MEM_IMAGE regions.
	* mach_dep.c (GC_with_callee_saves_pushed): separate into new function,
	  and indent appropriately.
	* mark_rts.c (GC_approx_sp): Access stack.
	* pthread_stop_world.c: (GC_suspend_handler): Explicitly push
	  callee-saves registers when appropriate.
	  (GC_stop_world): Handle EINTR from sem_wait (sync with Mono GC).


More detailed explanation:
	allchblk.c: Blatant bug fixes already in GC6.4.  Should have been
	merged earlier.

	dyn_load.c: This is a major change to win32 root finding, in spite of
	the small code change.  It's in 6.4, and hasn't generated complaints.
	Potentially a huge performance improvement on win32, at some risk for
	win32 correctness.  In many cases it drastically reduces win32
	root sizes.  Will probably eliminate many of the complaints about
	win32 performance.  Otherwise I wouldn't propose it here.

	mark_rts.c: Very low risk.  The old code looks dubious to me, though
	I know of no bug reports.  (Without this, the collector might first
	access a stack page well beyond the current sp.  I expect that some
	kernels might complain about this.  And it would be hard to debug.)
	Not in GC6.4.

	mach_dep.c, pthread_stop_world.c:  This really motivated the patch.
	Not in GC6.4.  Empirically, we now know that GC6.4 does not work with
	gcc on HP/UX.  (Gctest does work with the HP compiler.)  The problem
	appears to be that not all relevant registers end up in the signal context
	structure on the stack, and hence the multithreaded collector occasionally
	misses a register.  This patch pushes the register context onto the stack
	in the signal handler.  Empirically this fixes the HP/UX problem.  We also
	know that we should really be doing this on IA64/Linux, since the kernel
	there explicitly leaves it to the handler to deal with callee-save
	registers.  Thus this patch really does two things:

		1) It empirically fixes an observed HP/UX problem, which I
		still don't understand 100%.  (I'm still investigating, but
		I'm not in the best position to do so.)
		2) It fixes a clear IA64/Linux bug, which was never observed
		in practice.

	(This piece looks bigger than it is because a big chunk of code was
	unindented as it was moved into a separate function.)

Hans

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc020705diffs
Type: application/octet-stream
Size: 10173 bytes
Desc: gc020705diffs
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20050207/77424522/attachment.obj>