This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the GCJ project. See the GCJ home page for more information.
> > 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