Re: DEBUG_GCSAFETY issues

[Vladimir T. <vtz...@gm...>]

Hi,

On Aug 4, 2008, at 9:28 PM, Sam Steingold wrote:
> \you might want to start with CVS head instead of your branch to  
> check whether the problems you see are branch-specific.
>

I am trying to keep in sync my development copy with the cvs (almost  
daily).

>> 1. control.d - function:
>> local maygc void make_vframe_activate (void)  {....}
>> it may gc only because of make_variable_frame() which uses value1  
>> and  value2.
>> However because of the "maygc" - value1 and value2 become invalid   
>> from GCSAFETY
>> point of view and it is not possible to perform successful build.
>> so I changed it to:
>> local /*maygc*/ void make_vframe_activate (void)
>> {  GCTRIGGER1(mv_space);
>> ....}
>
> this is wrong.
> the arguments to GCTRIGGER1 should be objects, not arrays thereof.
> please pull my patch from HEAD and apply it to your branch.

It seems legal to pass mv_space (actually array of "object 
[mv_limit-1]") to any of
GCTRIGGERx() macros - since we have:
   inline void inc_allocstamp (object (&mvsp)[mv_limit-1])
specialized exactly for this case.

(I used GCTRIGGER2(value1,value2), but
GCTRIGGER1(mv_space) looks more general and legal).

>> 2. It seems that with HEAPCODES the macro:
>> pointable_address_unchecked(obj_o)
>> is not exported (%% export_def(...)) causing problems in building.
>> I added it.
>
> what is the problem?
>

The problem is with clisp-test.c make target. During normal build the  
executable
clisp-test-clisp cannot be build. I get following error:

clisp.h: In function 'aint pgci_pointable(object)':
clisp.h:644: error: 'pointable_address_unchecked' was not declared in  
this scope
clisp.h: In function 'aint pgci_pointable(gcv_object_t)':
clisp.h:645: error: 'pointable_address_unchecked' was not declared in  
this scope
.......

That's the reason I added the %%export_def for it.


>> 4. The GCSAFETY will not be usable at all in MT environment. When   
>> allocation can be
>> done in parallel the allocstamp will not carry much information.
>
> I thought we have already settled that allocations cannot be  
> performed in parallel.
>

Of course the allocations itself are not performed in parallel,  
however suppose following:
(which is quite normal)
thread #1 to allocates an object, after it thread #2  allocates  
another one (increasing
alloccount). Now  GCSAFETY checks will complain in thread #1 about  
the legal status
of the first allocated object. This object will have  allocstamp  
different than alloccount so
any attempt to put this object in GC visible location will cause  
GCSAFETY machinery
to abort.

Possible solution is to keep the alloccount in the TLS of the thread  
(clisp_thread_t) but I
am not sure whether this will not cause some other problems?

BR
   Vladimir