RE: GC / GCJ / and binutils (ld)

[Andrew Haley <aph at redhat dot com>]

Peter Blemel writes:
 > 
 > >From: Andrew Haley <aph@redhat.com>
 > >To: "Peter Blemel" <pblemel@hotmail.com>
 > >CC: java-patches@gcc.gnu.org
 > >Subject: GC / GCJ / and binutils (ld)
 > >Date: Mon, 6 Sep 2004 13:34:00 +0100
 > >
 > >Peter Blemel writes:
 > >  > The macros in GCJ (specifically MS_TIME_DIFF) seem to ignore the fact 
 > >that a
 > >  > DWORD tick count even expressed in millis will wrap around every 49.7 
 > >days
 > >  > (E.g. MS Windows).   This is a problem if garbage collection is running
 > >  > right about that time, because attempts to limit the time used by GC 
 > >will
 > >  > not be successful if the clock 'rolls over' during GC.   It's not 
 > >terribly
 > >  > unusual for an embedded application to run for this long, and in the
 > >  > (unlikely) event that this occurs, the application will stop until gc
 > >  > completes.
 > >
 > >Why will there be a problem?  Even when the tick count wraps around,
 > >the time difference should still be correct.  Mind you, I don't know
 > >exactly what GetTickCount() does.
 > 
 > The short version of this is that the MS_TIME_DIFF(a,b) macro basically 
 > subtracts b from a to compute 'elapsed time'.   'b' is held constant, taken 
 > at the beginning of some activity.   'a' is the current time.   This works 
 > fine while a > b, but when the clock rolls over after 'marking b' then a 
 > becomes less than b, and the difference is negative.

Why would that happen?  Let's say we have a 32-bit timer that is
getting near to overflow.  b is 4294966796, say, and after the timer
wraps round a is 100.  100 - 4294966796 == 600 (mod 2^32).  The only
problem will occur if the operands are promoted to a greater type
before the subtraction is performed.  An then we have a bug.  :-)

 > At this point the issue is either picking nits or a theoretical
 > discussion :-) The quick answer is that I can just fix my macro to
 > ensure that the result is positive and be done with it.  The answer
 > to 'why is this a problem?' is longer and isn't likely to be
 > interesting to most people (probably anyone but me).

Well, if it's really wrong we'd like to get it fixed.

Andrew.