[Soot-list] Question on the DEF/USE analysis

[John Jorgensen]

    cregut> To avoid this, I have added a version of the
    cregut> ExceptionalUnitGraph class where
    cregut> "allvaysAddSelfEdges" is false (mightHaveSideEffect
    cregut> is static and cannot be overridden).

It's been a few years since I was familiar with this code, but if
you are using soot from the command line, I think you can just
use the "-omit-excepting-unit-edges" command line option (or more
likely "-trim-cfgs", which implies "-omit-excepting-unit-edges")
to turn off alwaysAddSelfEdges, without having to replace
the ExceptionalUnitGraph implementation.

The command line option effectively changes
the default value of one of the ExceptionalUnitGraph's
constructor; the Soot.Options class probably provides
programmatic methods to change the default value without
specifying the command line option, but I haven't looked into
that.

    cregut> This is true as long as the definition effect 
    cregut> occurs after any potential exception has been raised for all the 
    cregut> statements of the intermediate language. I think this is true in Jimple.

    cregut> Am I wrong, or is this something that could be modified to make the 
    cregut> def/use analysis more precise ?

I think you're right (that's the reason "-trim-cfgs" and
"-omit-excepting-unit-edges" exist).  But there are at least two
caveats:

- I've never seen a definitive specification of when asynchronous
  exceptions may be delivered (ThreadDeath and InternalError are
  asynchronous, meaning them may be delivered to a thread at
  arbitrary points unrelated to the particular instructions the
  thread is executing).  So it's conceivable that if your
  assignment were the last instruction within a try block whose
  catch catches Throwable (i.e., it catches the asynchronous
  exceptions) and that an asynchronous exception happens to be
  raised just as the assignment completes, then some JVMs might
  deliver the asynchronous exception to the catch block even after
  completing the assignment to the LHS of the statement being
  executed when the exception occurred (I agree that this is an
  unlikely interpretation, but I'm not sure the JVM specification
  disallows it).

- When I checked seven years ago, the bytecode verifiers in JVMs
  performed their verifications on the assumption that all
  instructions within a try block had the potential to throw an
  exception to the catch.  As a consequence, basing optimizations
  on CFGs which eliminated edges corresponding to unrealizable
  exceptions could result in unverifiable code (see sections 2.6
  and 3.4 of
  http://www.sable.mcgill.ca/publications/techreports/#report2003-3
  for details).  

  Soot includes a hack (the "Trap Tightener" in the jb.tt pass)
  to reduce the likelihood of such unverifiable code, but the
  hack does not eliminate the possibility.

  So it's conceivable that making the Def/Use analysis more
  accurate might increase the possibility of generating
  unverifiable code. I haven't thought through the details of
  that, though.