On Apr 12, 2011, at 1:45 AM, Steven Bosscher wrote:
> On Tue, Apr 12, 2011 at 9:01 AM, Jakub Jelinek <ja...@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?

Reply via email to