tree 33c85aada415308d8207d63bce903262ea7504fe
parent bb4366d2b0b56f2cc66041243bd93de4b8e4d15a
author Vladimir Marko <vmarko@google.com> 1478864440 +0000
committer Vladimir Marko <vmarko@google.com> 1479755491 +0000

Make sure that const-class linkage is preserved.

After calling loadClass() on the initiating loader, insert
the Class to the ClassTable. Check that the returned class
has the correct name and that the ClassTable does not yet
contain a different Class for the same name. If either check
fails, follow the RI behavior for parallel capable class
loaders, i.e. throw NoClassDefFoundError for name mismatch
(with more descriptive message than RI) or return the Class
already present in the ClassTable. This ensures that the
const-class instruction for a given name always gives the
same result as the first time it succeeded for the same
initiating loader, even for non-well-behaved loader.

Inserting the Class to the ClassTable is also a necessary
step for changing to hash-based dex cache type array when
the DexCache will not necessarily keep the Class and
therefore the defining loader alive while the initiating
loader stays alive, so the ClassTable entry is necessary
to keep the dependecy.

Add tests that a const-class instruction always returns the
same Class<?> as it returned the first time, i.e. when it
was "linked", even for class loaders that are not
well-behaved, even if the dex cache type array is cleared.
Also test the edge cases, i.e. NoClassDefFoundError and
returning old entry from ClassTable when already inserted
by another thread.

Bug: 30627598
Test: 626-const-class-linking
Test: m test-art-host
Change-Id: Ie9b721464b4e9a5dcce8df8095548e983bba1fe8