4109fe8594
libjava: 2004-08-13 Bryce McKinlay <mckinlay@redhat.com> * configure.in (GCINCS): Don't use "boehm-cflags". Instead, -I boehm-gc's include dirs. * configure: Rebuilt. * include/boehm-gc.h: Include gc_config.h. boehm-gc: 2004-08-13 Bryce McKinlay <mckinlay@redhat.com> * configure.ac (gc_cflags): Add -Iinclude. (AC_CONFIG_HEADERS): New. Configure gc_config.h header. Don't write DEFS to boehm-cflags file. * configure: Rebuilt. * gcj_mlc.c: Check #ifdef GC_GCJ_SUPPORT after including headers. * specific.c: Check #ifdef GC_LINUX_THREADS after including headers. * include/gc_config_macros.h: Remove backward-compatibility redefinitions of GC_ names. * include/gc.h: Include <gc_config.h>. 2004-08-13 Bryce McKinlay <mckinlay@redhat.com> Import Boehm GC version 6.3. From-SVN: r85972
22 lines
761 B
C
22 lines
761 B
C
# ifndef GC_H
|
|
# include "gc.h"
|
|
# endif
|
|
|
|
/*
|
|
* Invoke all remaining finalizers that haven't yet been run.
|
|
* This is needed for strict compliance with the Java standard,
|
|
* which can make the runtime guarantee that all finalizers are run.
|
|
* This is problematic for several reasons:
|
|
* 1) It means that finalizers, and all methods calle by them,
|
|
* must be prepared to deal with objects that have been finalized in
|
|
* spite of the fact that they are still referenced by statically
|
|
* allocated pointer variables.
|
|
* 1) It may mean that we get stuck in an infinite loop running
|
|
* finalizers which create new finalizable objects, though that's
|
|
* probably unlikely.
|
|
* Thus this is not recommended for general use.
|
|
*/
|
|
void GC_finalize_all();
|
|
|
|
|