Precise gc and PMT (was: Re: Test)

[Godmar Back]

> 
> I've been looking at for a similar problem in a different context.
> A current (tentative) solution that I am working on is to produce
> type maps for any possible destination of a backward branch, a
> backward branch being anything that reduces the value in the PC.
>  (actually I'm doing something for the destinations of ALL branches
> for reasons given below, but backward branches are the only ones
> necessary). That guarantees that a map point is nearly always not
> far away when you look at how seldom there are large amounts of
> one-way code (massive if-then-else constructs?).
> 
> >I really recommend reading Diwan's paper, he does a better job at explaining
> >the issue.
> 
> Is it possible to get an online copy of this paper?
> 

 I can't give you the original source right now, but you can pull the
copy I have from http://www.cs.utah.edu/~gback/diwan-pldi92.ps

> An aside:
> 
> This is slightly off topic as it involves access to levels of the
> machine that gcj won't(?) have, but I have taken over the interrupts
> on a PowerPC, and when there are any interrupts, do the following
> (quickly - in a few cycles):
> * Save somewhere what sort of interrupt it was.
> * Turn on Trace mode on the chip so that it stops after every branch
> (the PowerPC750 and 68030 offer this in hardware - not all chips do)
> * Turn off the interrupts.
> * return execution to thread.
> 
> The Trace exception in trapped to turn off trace mode and turn on
> interrupts in the thread and deal with what the interrupt was meant
> to do (whether that be a thread switch or whatever).
> 
> This doubles the number of exceptions with an (unmeasured) speed hit,
> but it means that all threads are always stopped at well defined
> points. A nice side-effect of this is that any basic block can be
> treated as atomic.
> 

 I see.  That's a neat trick which rolls every thread forward to the
next gc point.

	- Godmar