RE: I need help with gc

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

You clearly cannot protect regions that contain pointers, since the
collector needs to see those.

By default, the collector will scan all static data for pointers.  You can
tell it not to do so by calling GC_exclude_static_roots on the right address
range before you protect part of the data.  If you have large static
C/Fortran arrays that are known not to contain pointers to the garbage
collected heap, it may be a good idea to do so anyway.  (Due to the way the
heap expansion heuristics work, this may reduce the heap size instead of
reducing GC time.  But one way or another it should improve GC performance.
And it will reduce the probability of misidentified pointers.)

Clearly none of his applies if gcj is ever configured with a different
garbage collector.

Hans
 
> -----Original Message-----
> From: Martin Kahlert [mailto:martin.kahlert@infineon.com]
> Sent: Friday, April 26, 2002 1:55 AM
> To: java@gcc.gnu.org
> Subject: I need help with gc
> 
> 
> Hi!
> i get a SegFault on Linux in 
> #0  GC_mark_from (mark_stack_top=0x85c5000, mark_stack=0x85c5000,
> mark_stack_limit=0x85cd000) at 
> ../../../gcc-3.1-20020423/boehm-gc/mark.c:654
> 654               deferred = *limit;
> (gdb) p limit
> $1 = (word *) 0x8569048
> 
> This is an address inside a fortran common block which is 
> layed out like this:
> 
>       COMMON /BLANK/ NODPRE,NODPLC,NODPST
>       INTEGER NODPRE(4096), NODPLC(2048), NODPST(2048)
>       REAL*8 VALUE(1024)
>       COMPLEX*16 ZVALUE(512)
>       CHARACTER CHRARR(8192)
> 
>       EQUIVALENCE (VALUE(1),NODPLC(1),ZVALUE(1),CHRARR(1))
> C
> 
> and also addressed from C by
> extern struct
> {
>     int padding_pre[4096];
>     union
>     {
>         char    carray[8192];
>         int     iarray[2048];
>         double  darray[1024];
>         Complex zarray[512];
>     } userdata;
>     int padding_post[2048];
> } blank_;
> 
> In the application blank.padding_pre = 0x8566220.
> Thus limit is somewhere in the middle of NODPRE or blank_padding_pre.
> Is this an error?  
> 
> I found that because i mprotected a region around NODPLC / 
> blank_userdata
>  with PROT_NONE in order to catch errors in my code.
> 
> The full stack frame is this:
> #0  GC_mark_from (mark_stack_top=0x85c5000, 
> mark_stack=0x85c5000, mark_stack_limit=0x85cd000) at 
> ../../../gcc-3.1-20020423/boehm-gc/mark.c:654
> #1  0x40642ad2 in GC_mark_some (cold_gc_frame=0x8568e50 "") 
> at ../../../gcc-3.1-20020423/boehm-gc/mark.c:289
> #2  0x4063f025 in GC_stopped_mark (stop_func=0x8568e50 
> <blank_+11312>) at ../../../gcc-3.1-20020423/boehm-gc/alloc.c:489
> #3  0x4063ed9c in GC_try_to_collect_inner 
> (stop_func=0x4063e950 <GC_never_stop_func>) at 
> ../../../gcc-3.1-20020423/boehm-gc/alloc.c:350
> #4  0x40645105 in GC_init_inner () at 
> ../../../gcc-3.1-20020423/boehm-gc/misc.c:673
> #5  0x406410d4 in GC_init_gcj_malloc (mp_index=0, mp=0x1fc) 
> at ../../../gcc-3.1-20020423/boehm-gc/gcj_mlc.c:60
> #6  0x4063e452 in _Jv_InitGC() () at 
> ../../../gcc-3.1-20020423/libjava/boehm.cc:465
> #7  0x405ca741 in _Jv_CreateJavaVM(void*) () at 
> ../../../gcc-3.1-20020423/libjava/prims.cc:892
> #8  0x405cd665 in JNI_CreateJavaVM (vm=0x1fc, penv=0x1fc, 
> args=0xbfff9cf0) at ../../../gcc-3.1-20020423/libjava/jni.cc:2262
> #9  0x0805cbf6 in loadJVM () at c_code/vti.c:660
> ....
> 
> Is this behaviour correct and i just cannot mprotect static 
> data and use the gc or is it an error?
> 
> Thanks for any help,
> Martin.
> 
> -- 
> The early bird catches the worm. If you want something else for       
> breakfast, get up late
>