|[24 earlier articles]|
|Re: Pros and cons of high-level intermediate languages firstname.lastname@example.org (1992-08-04)|
|Re: Pros and cons of high-level intermediate languages email@example.com (1992-08-03)|
|Re: Pros and cons of high-level intermediate languages firstname.lastname@example.org (Ronald Bodkin) (1992-08-04)|
|Re: Pros and cons of high-level intermediate languages email@example.com (1992-08-04)|
|Re: Pros and cons of high-level intermediate languages chased@rbbb.Eng.Sun.COM (1992-08-04)|
|Re: Pros and cons of high-level intermediate languages nfsun!gchamber@uunet.UU.NET (1992-08-04)|
|Re: Pros and cons of high-level intermediate languages firstname.lastname@example.org (1992-08-05)|
|Re: Pros and cons of high-level intermediate languages chased@rbbb.Eng.Sun.COM (1992-08-07)|
|Re: Pros and cons of high-level intermediate languages email@example.com (1992-08-07)|
|Re: Pros and cons of high-level intermediate languages firstname.lastname@example.org (1992-08-10)|
|From:||email@example.com (Eliot Moss)|
|Organization:||Dept of Comp and Info Sci, Univ of Mass (Amherst)|
|Date:||Wed, 5 Aug 1992 14:30:14 GMT|
|Keywords:||C, storage, optimize|
firstname.lastname@example.org (Graham Matthews) said:
>[to handle cases where GC might move objects, generate C code like:]
> for( i = 0; i < 100; i++ )
> object_access(p)[i] = object_access(q)[i];
> where object_access() is a function returning a pointer to the storage
> space for the array. The C compiler will not optimise this code (you
> may have problems with global inter-procedural optimisations here but
> you can usually turn them off).
> You take a performance hit here but in the presence of GC surely you
> have to take that hit no matter what IL you use?
Looks like a *big* performance hit for every array access, since you're
talking about doing a real procedure call (otherwise, it may boil down to what
I wrote and you get back into the problems previously discussed)!
> Now if you are really sure that 'q' and 'p' above will not move (eg:
> you only preform GC on allocation or deletion and you are sure that
> there will be no collections inside the loop) you can code the loop as
> you suggest above and the performance will be better. If you cannot
> guarantee this condition then you cannot code the loop as above.
See our paper in the last SIGPLAN conference which describes a *working
system* that can handle the kind of code I originally presented. It works
by generating tabular information for the collector to use. This incurs a
space cost, but impacts run-time performance minimally. There are cases
where additional values have to be kept around, which might increase
register pressure a little, but it appears to be a minor effect.
As for changes/extensions to C to make it easier to gc, Hans Boehm has
worked up a proposal for making C safe for gc (for conservative gc at
least; I can't recall if it would allow other kinds of gc). I certainly
think it's *possible*; whether people would accept the necessary language
definition changes is another matter.
J. Eliot B. Moss, Associate Professor
Department of Computer Science
Lederle Graduate Research Center
University of Massachusetts
Amherst, MA 01003
(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
Return to the
Search the comp.compilers archives again.