On Oct 4, 5:09 pm, DanH <danhi...@ieee.org> wrote:
> The verifier must create what is commonly known a "use-def chains" for
> the bytecodes in a method, to determine which results from one
> bytecode can flow as inputs to another bytecode ("data flow"). The
> traditional way to do this (and the one used in most verifiers) is to
> literally construct chains -- lots of little objects chained together
> into lists. This is space consuming and time-consuming to do.
Ah. The current verifier just tracks the contents of each register
(Dalvik isn't Java, registers not stack), and uses a work-list
approach to figure out what to do next. Each register value is a
small enumeration (indicating a primitive type) or a Class reference.
The verification process is also used to generate the register maps
for type-precise GC, which means it needs to store the register state
for every instruction that could be a GC point. (If it were just
about verification, it would only need to retain it for the start of
each basic block.)
The current version doesn't really treat basic blocks in a fancy way;
it just has a bit flag on each instruction that indicates if it's a
branch target. This leads to some inefficiencies in the work-list
scan. A future version will identify the basic blocks, use a reverse
postorder traversal to reduce the number of times we have to process
the same stretch, and do backward flow analysis for live-precise
register maps.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
