[M3devel] optimizer vs. gc?

[Tony Hosking]

I assume you are referring to:

@article{boeh92,
author = "Hans-Juergen Boehm and David R. Chase",
title = "A Proposal for Garbage-Collector-Safe {C} Compilation",
journal = "Journal of C Language Translation",
mon = dec,
year = 1992,
pages = "126--141",
URL = {http://reality.sgi.com/employees/boehm_mti/papers/boecha.ps.gz}
}

So long as the stacks have a pointer to anywhere on the heap page on which the object lies then it will not get reclaimed by our collector.  I'd be surprised if gcc performs optimizations that break our collector.


On Nov 23, 2010, at 5:44 AM, Jay K wrote:

> so.."the literate" (actually posts to usenet
> by people who worked on Modula-3 compilers!)
> warns about the following sort of thing:
> 
> void F1(char* a, char* b)
> {
>  int c;
>  for (c = 10; c < 20; ++c)
>  {
>    a[c] = b[c];
>  }
> }
> 
> getting transformed into something like:
> 
> void F1(char* a, char* b)
> {
>  int c;
>  a += 10;
>  b += 10;
>  for (c = 0; c < 10; ++c)
>  {
>    a[c] = a[c];
>  }
> }
> 
> 
> actually it warns about something trickier, but this
> is the best I can come up with that I understand,
> off the top of my head.
> 
> 
>  => "interior pointers"
>  => "no gc roots in registers or on stack"
>  
>  
> Should we be concerned?
> Does our GC handle this?
> 
> 
> Should we, like, mark all stores volatile but not all loads?
> And maybe all parameters???
>   And maybe copy them into non-volatile locals?
>   
> The trickier warning is something where
> the difference of the array bases is what is in registers, not merely an interior pointer.
> I searched a while but couldn't find it.
> It is probably by David Chase.
> 
>  - Jay
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101123/821b78a4/attachment-0002.html>