Precise gc and PMT (was: Re: Test)

Fri Sep 18 16:59:00 GMT 1998

>> 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