Precise gc and PMT (was: Re: Test)

[Roy Ward <roy@earthlight.co.nz>]

>Suppose you have three threads: thread 1 and thread 2 do computation,
>thread 3 is the gc thread.  Now suppose thread 1 executes code.
>Further, suppose it executes a loop that is between pc value 20 and 30.
>Suppose the compiler has prepared stack maps for the pc value 20 and 31,
>but not for any pc value greater than 20 and less than 31.
>Now suppose thread 1 is preempted at pc 25.  Now suppose thread 2
>runs, thread 2 wants to allocate memory, but a gc is triggered.
>
>The gc threads needs to obtain root information from both thread 1
>and thread 2.  Thread 2 is not a problem, because the compiler will
>have created type information (read: set a gc point) for the pc value at
>which thread 2 tries to allocate memory.
>
>Thread 1, however, is stuck between two gc points: no precise information
>is available to map machine state to Java state.  What do you do?

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?

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.

Cheers,
Roy Ward.

--
"Moderation in all things?" "Over my dead body!"