> Dalvik needs to keep more state than this around, because it needs to > keep track of what type of object is in each register that holds an > object. The verifier is responsible for determining if method A is > allowed to access fields and methods in class B, so it needs to know > what type of object the code is operating on. The register merge > procedure can actually involve searching for a common superclass.
The "anding" of the bitsets together implicitly does the search for the common superclass, since when a "reference" is placed in a slot (register/stack entry) then all of the bits of the class hierarchy are turned on. That's the meat-and-potatoes of verification. The iSeries scheme also did pre-verification (on first touch), and then did a load-time post-verification step (using tables created during the verification) to assure that everything "plugged together" legally. Unlike many implementations, there was no option to bypass verification on iSeries, since verification was necessary to insure machine integrity, so verification had to be reasonably fast and very secure. (This fit in with the RPG and COBOL implementations that also relied on a "safe backend" to produce code that could not violate system integrity.) On Oct 5, 3:49 pm, fadden <fad...@android.com> wrote: > On Oct 5, 11:28 am, DanH <danhi...@ieee.org> wrote: > > > In the bitmap scheme each stack entry/register has several bits > > assigned, one for each possible type that could conceivably reach it. > > If an object pointer is assigned then all the bits for that class > > hierarchy are set, and when flows combine the bitsets are "anded" > > together. Thus the value that reaches a use automatically represents > > the classes valid at that point, taking into account the different > > flows. > > Dalvik needs to keep more state than this around, because it needs to > keep track of what type of object is in each register that holds an > object. The verifier is responsible for determining if method A is > allowed to access fields and methods in class B, so it needs to know > what type of object the code is operating on. The register merge > procedure can actually involve searching for a common superclass. > > I'm sort of curious now to see if there's a way to detect invalid > conversions and perform legal widening conversions with bitwise > operations. I'm not sure it'd be a win over the table lookup, but it > creates the possibility of doing a whole bunch of registers in > parallel. I'm not sure the relations are simple enough. For example, > Dalvik is more picky than certain other VMs when it comes to the > contents of short integers (e.g. you could have a value of 1024 in a > "byte" in some VMs). > > Dalvik tries to do all this ahead of time (via "dexopt") when the app > is first installed, which results in various limitations and re-verify > triggers when other parts of the system change. This doesn't always > work, so it'll do the verification / register map generation on first > load if necessary. -- 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
