1c80becf5406cd6d95dc24bf47a0c5a3809ea281 |
|
03-Feb-2015 |
Sebastien Hertz <shertz@google.com> |
Fix transaction aborting During compilation, a java.lang.InternalError is used to indicate that class initialization failed and the enclosing transaction should be aborted and the changes rolled back. However there is nothing preventing the code executed from a class initializer from catching that exception (like catching Throwable and ignore it). Therefore we may return from the class initializer with no pending exception, even if the transaction was aborted, and not rollback the changes properly. To fix this, we now rely on the new Transaction::aborted_ field to know whether a transaction aborted. When returning from the class initializer without pending exception, we now check wether we aborted the enclosing transaction. If that's the case, we set the status of the class to kStatusError and throw a new java.lang.InternalError with the original abort message. This CL also contains some cleanup: - Renames Transaction::Abort to Transaction::Rollback which is less ambiguous and more reflect what is done. - Moves the code throwing the java.lang.InternalError exception into the Transaction::ThrowInternalError method so we do not duplicate code. Now we may abort transaction more than once (because we may have caught the java.lang.InternalError then execute code causing new transaction abort), we only keep the first abort message to throw the exception. - Updates transaction_test with more cases and more checks. - Bumps oat version to force recompilation with this fix. Bug: 19202032 Change-Id: Iedc6969528a68bbdf3123146e990df4dbc57834b
|
d2fe10a3a34af171bf1631219cd2d6ff6b7778b5 |
|
15-Jan-2014 |
Sebastien Hertz <shertz@google.com> |
Remove blacklist Removes the class initialization blacklist and use transaction to detect and revert class initialization attempting to invoke native method. This only concerns class initialization happening at compilation time when generating an image (like boot.art for the system). In transactional mode, we log every object's field assignment and array update. Therefore we're able to abort a transaction to restore values of fields and array as they were before the transaction starts. We also log changes to the intern string table so we can restore its state prior to transaction start. Since transactional mode only happens at compilation time, we don't need to log all these changes at runtime. In order to reduce the overhead of testing if transactional mode is on/off, we templatize interfaces of mirror::Object and mirror::Array, respectively responsible for setting a field and setting an array element. For various reasons, we skip some specific fields from transaction: - Object's class and array's length must remain unchanged so garbage collector can compute object's size. - Immutable fields only set during class loading: list of fields, method, dex caches, vtables, ... as all classes have been loaded and verified before a transaction occurs. - Object's monitor for performance reason. Before generating the image, we browse the heap to collect objects that need to be written into it. Since the heap may still holds references to unreachable objects due to aborted transactions, we trigger one collection at the end of the class preinitialization phase. Since the transaction is held by the runtime and all compilation threads share the same runtime, we need to ensure only one compilation thread has exclusive access to the runtime. To workaround this issue, we force class initialization phase to run with only one thread. Note this is only done when generating image so application compilation is not impacted. This issue will be addressed in a separate CL. Bug: 9676614 Change-Id: I221910a9183a5ba6c2b99a277f5a5a68bc69b5f9
|