[fpc-devel] Const optimization is a serious bug

[Jonas Maebe]

On 08 Jul 2011, at 05:51, Chad Berchek wrote:

> The problem comes down to the specs though, or rather the lack  
> thereof. As I have searched the web and read some docs at  
> Embarcadero, things have only become more ambiguous. It seems that  
> everyone repeats the same basic explanations but never fleshes out  
> the subtleties. In my opinion, if you compared C, Java, and C++ (to  
> a slightly lesser extent) to a mathematical proof, then Object  
> Pascal in today's form would be more like a pile of notes and some  
> lunchtime conversations.

It's true that C, Java and C++ all have some kind of committee that  
designs and fleshes out the specs, which are then published so that  
others can conform to them. They go into excruciating detail about  
minor details to make sure they are as unambiguous as possible. For  
Pascal this also happened in the past (the ISO standards), but  
Borland's success was largely based on deviating from those standards  
and coming up with their own dialect.

And while they have extensive documentation for their language,  
several aspects that you run into when dealing with corner cases are  
at most only defined by "what does the Borland/Embarcadero compiler  
accept/do". As far as const string parameters, I found this post by  
Embarcadero's (main) compiler developer: http://stackoverflow.com/questions/5851584/are-const-string-parameters-thread-safe/5851898#5851898

There he explicitly says that const prevents increasing the reference  
count (and also gives an example program similar to others posted in  
this thread).

> I'm more interested now in a solution. The solutions I've seen so  
> far have potential, but in my opinion most of them seem like they  
> are more complex, would be more overhead, and produce worse  
> performance than just getting rid of the const "optimization".

The main proposals I've seen were
a) treat const string parameters the same as value parameters (i.e.,  
get rid of the current const behaviour)
b) the same as a), combined with a very conservative heuristic to  
apply the optimization in case there can be no side effects. I.e., in  
case there is not a single function call and not a single indirect  
write (var parameter, pointer, global variable, dynamic array, ...) to  
any string or anything that might be somehow aliased to a string  
passed as parameter to the current routine
c) keep the current behaviour, but add functionality to the compiler  
to help debug problems that can occur as a result of problems that can  
occur as a result of this behaviour

> However, looking at the generated assembly, I can't believe there  
> isn't a more efficient way to handle the implicit try-finally. It  
> feels to me like that is where the problem is. There is a lot of  
> code and several function calls that go into implementing that  
> implicit 'finally' block. There's got to be some way to decrement  
> the refcount even when there are exceptions but without so much  
> overhead. It would require changes to the exception handling  
> mechanism though. Here my knowledge runs out.

The main problem here is that FPC's exception handling is based on  
setjump/longjump. This technique has a relatively high overhead for  
"try", but low overhead when an exception actually occurs (of course,  
since exceptions are supposed to happen only exceptionally, that's not  
a really good selling point). The main reason we use it is because  
it's easy to implement.

A better approach would be to use SEH-based exception handling (which  
has no overhead at all for "try", and a high overhead in case an  
exception occurs), but that woud require
a) support for generating EH frames for all platforms (it's currently  
only supported for a number of i386 and x86-64 platforms)
b) support for parsing EH frames on all platforms and performing  
exception handling based on that

This is definitely something we want, but nobody has found the time  
yet to implement it.


Jonas