[Gc] Changes requested to reduce GC heap growth on Windows

Boehm, Hans hans_boehm at hp.com
Tue Jan 27 13:13:56 PST 2004


Derek's patch also includes at least one other changes, always setting IGNORE_OFF_PAGE, which
sometimes helps to reduce heap size, but causes the collector to be less conservative in
recognizing pointers, and is not always correct.

I agree that any compiler that systematically evaluated the second operand of && with a zero
first operand would be completely unusable.  If a compiler does that under any circumstances
under which it has an observable effect, that's a serious compiler bug.

For gctest, I see final heap sizes with my current version (very similar to 6.3alpha4):

Linux (RH8):	5.67 MB
Cygwin:		6.8 MB
VC++ 6:		5.73 MB

This is the single-threaded version.  Is somebody seeing something significantly different?
(Some variation between runs is normal here.  But a systematic variation of more than a
MB or two on X86 is probably worth looking at.)

There is a known issue with the collector sometimes scanning graphics memory on Windows.
I would love to have some help in tracking down a solution, since I can't reproduce it.  My impression
is that it happens only for processes that use the graphics libraries.

Hans


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Derek McUmber
> Sent: Tuesday, January 27, 2004 10:16 AM
> To: Andrew Begel
> Cc: 'gc at linux.hpl.hp.com'
> Subject: Re: [Gc] Changes requested to reduce GC heap growth 
> on Windows
> 
> 
> Thanks for your feedback.
> 
> 
>  From your excerpt below:
> 
>  > (pch) && (*pch = 'a');
>  >
>  >
>  > If pch is null (0), the right side of the expression is never
>  > evaluated. Therefore, the assignment through a null pointer is 
> impossible.
>  >
> 
> is different from what I was referencing:
> 
>  >>     while ( 0 == h && GET_MEM()) {
>  >>         h = GC_allochblk(...);
>  >>     }
> 
> The left side of the expression is simply True or False, never NULL.
> 
> Perhaps the fix is to change to:
> 
>  >>     while ( (h) && GET_MEM()) {
>  >>         h = GC_allochblk(...);
>  >>     }
> 
> so that the expression may match and the code will execute as 
> intended.
> 
> 
> If you have GCTEST.exe and can compile and run my change, you will 
> notice a significant reduction in the use of memory during execution.
> 
> Derek
> 
> 
> Andrew Begel wrote:
> > If this is true, then the docs pages for MSDN Visual Studio.NET  
> > description of C and C++ are incorrect, and it's a bug in the MSFT  
> > compiler. If your empirical observation is correct, maybe 
> there's a  
> > compiler flag being passed on Windows (or not being passed) 
> that is  
> > controlling this behavior that could be fixed.
> > 
> > Andrew
> > 
> >  From the C++ manual online (the same deal about 
> short-circuit eval is  
> > true about the C language reference as well. It's defined in the C  
> > standard as well as the MS docs).
> > 
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ 
> > vccelng/htm/express_42.asp
> > 
> > Logical AND Operator
> > 
> > The logical AND operator (&&) returns the integral value 1 if both  
> > operands are nonzero; otherwise, it returns 0. Logical AND has  
> > left-to-right associativity.
> > 
> > Syntax
> > logical-and-expression :
> > inclusive-or-expression
> > logical-and-expression && inclusive-or-expression
> > 
> > The operands to the logical AND operator need not be of the 
> same type,  
> > but they must be of integral or pointer type. The operands 
> are commonly  
> > relational or equality expressions.
> > 
> > The first operand is completely evaluated and all side effects are  
> > completed before continuing evaluation of the logical AND 
> expression.
> > 
> > The second operand is evaluated only if the first operand 
> evaluates to  
> > true (nonzero). This evaluation eliminates needless 
> evaluation of the  
> > second operand when the logical AND expression is false. 
> You can use  
> > this short-circuit evaluation to prevent null-pointer 
> dereferencing, as  
> > shown in the following example:
> > char *pch = 0;
> > ...
> > (pch) && (*pch = 'a');
> > 
> > 
> > If pch is null (0), the right side of the expression is never  
> > evaluated. Therefore, the assignment through a null pointer 
> is  impossible.
> > 
> > and from the C reference:
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ 
> > vccelng/htm/expre_9.asp
> > 
> > C Sequence Points
> > 
> > Between consecutive sequence points an objects value can be 
> modified  
> > only once by an expression. The C language defines the following  
> > sequence points:
> >     •     Left operand of the logical-AND operator (&&). The left 
> > operand of  the logical-AND operator is completely 
> evaluated and all 
> > side effects  complete before continuing. If the left 
> operand evaluates 
> > to false (0),  the other operand is not evaluated.
> >     •     Left operand of the logical-OR operator (||). The 
> left operand 
> > of  the logical-OR operator is completely evaluated and all side 
> > effects  complete before continuing. If the left operand 
> evaluates to 
> > true  (nonzero), the other operand is not evaluated.
> > 
> > 
> > On Jan 26, 2004, at 8:18 PM, Derek McUmber wrote:
> > 
> >> Attached is a small diff of required changes for gc 
> compiled with the  
> >> MSFT family of C compilers.  Please review this request 
> and check for
> >> correctness.  I have tested this on 
> WinXP/2K/2KAdvanced/win98 and it
> >> appears to be satisfactory.
> >>
> >> The issue is with statements like:
> >>
> >>     while ( 0 == h && GET_MEM()) {
> >>         h = GC_allochblk(...);
> >>     }
> >>
> >> The microsoft compilers do not optimize the execution by 
> not calling
> >> the right side of the && expression if the left side is 
> true (vc98 and
> >> vc7).  This leads to double heap growth which is not desirable.
> >>
> >> thanks
> > 
> > 
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 


More information about the Gc mailing list