Re: [gc-improv] Permanent vs function RTL obstack fix

[Mike Stump <mikestump@comcast.net>]

On Apr 12, 2011, at 1:45 AM, Steven Bosscher wrote:
> On Tue, Apr 12, 2011 at 9:01 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote:
>>> I think all these comments from you "old guys" ;-) are more
>>> discouraging than fair. What Laurynas and Bernd have done, is nothing
>> 
>> It is IMHO completely fair to point that the risks this brings in
>> a huge maintainance nightmare are very high.
> 
> And IM-equally-HO it is completely unfair to talk about risks in any
> situation where there is nothing yet to talk about! Give it a chance
> and wait for something that's more than just an idea, and then assess
> the risks based on an implementation.

The problem is that in the olden days, people thought it would work, then, they ran into, oh, but the lifetime is wrong.  Oh, but I don't know what the lifetime will be before I start allocating.  Oh, what do you mean I can't copy it...  All these things happened after real bug reports and great difficulty in tracking down real problems.  A review might not be able to spot the things that won't work.  We don't want to discourage, only to let everyone know what our experience is with these sorts of problems.  So, for example, if one is predicating copying objects to solve lifetime problems, we can expound what some of the problems were in the past.  They could be relevant, they might not be not relevant; also, they just might cause people to explore an area that might be a problem, find and address it sooner.

Also, actual patches have been posted since Jan 27th...  I don't see that all the problems are cleverly avoided.  So, let's take one:

>   - If objects stored in PCH have pointers pointing outside of PCH-able/GC-managed memory, these become wild pointers on PCH read even with GTY((skip)) applied properly. However, not all GTY((skip)) pointers point outside of PCH-able memory, so I have overloaded GTY((deletable)) option to reset such fields to NULL on PCH write. This is only a part of the fix as logic needs to be reviewed what to do with these NULLs after the PCH read. In case of DECL_RTL, the NULL in the field causes re-creation of rtx anew, which I think is the right thing.

Not an example of a warm fuzzy.  When you combine this with the entire idea of PCH, and that is to slosh to disk and back, the entire state of the compiler, essentially, unmodified, we run into a conceptual gap.  Now, why did PCH have that design, so that we could limit the number of pch bugs and come up with a robust design that just works.  This is a useful property.

Now, one can audit DECL_RTL, to see if it matters, but there are roughly 344 places to check.  I glanced at a few, to see if I can spot problems.  I find it hard to know if any particular one will be a problem.  At least some of them can't be found by testing.  Presently we do what I'd call smoke testing for pch.  Deeper issues aren't covered.  So, who then will spot the issues?