Mercurial > hg > Members > kono > jpf-core
comparison jpf.properties @ 24:6774e2e08d37
the fix I would have liked to avoid - apparently hotspot internally does nested locking during class init, which can lead to deadlocks such as described in http://ternarysearch.blogspot.ru/2013/07/static-initialization-deadlock.html. Actually, it's not a regular deadlock since core dumps still list the threads as runnable, althouth it doesn't seem to be a livelock either. In any case, it can be simulated by nested locking and clinit execution, and it is such a serious defect that we want to be able to catch it. The general mechanism is to replace the disparate (but properly ordered) direct clinit calls of the generic ClassInfo.initializeClass() with a single sythetic method that includes all required locking (bottom up), clinit calls / class status change (top down), and unlocking (top down). We also need to add a synthetic insn to defer changing the class status of classes that don't have clinits(), or otherwise the correct lock/unlock order will not amount to anything if the hierarchy is entered through one of the clinit-absent classes. Now we get proper deadlocks if there are concurrent cyclic dependencies during class resolution. However, this can be such a state exploder that we certainly don't want this as the default behavior, especially since it probably is hotspot specific. Nested class init locking is therefore controlled by jvm.nested_init and respective jvm.nested_init.include/exclude options. Added a NestedInitTest to demonstrate use. Thanks to Lilia Abdulina for bringing this long forgotten issue up
In the wake of nested locks, there were a number of cases to fix that implicitly relied on absent clinits because clients were not properly checking for re-execution (most notably java.util.Exchanger). This mostly came in through MJIEnv.newObject/ElementInfo. We might turn ClinitRequired into a handled exception at some point, to catch such cases during compilation.
Added a UnknownJPFClass exception (in analogy to ClinitRequired), to make clients aware of failed class load attempts/reasons.
fixed Exchanger peer, which was not giving up the lock when timing out. This is an example of a lockfree wait op that can time out. Basically, ThreadInfo.isWaiting() needs to be complemented by a isWaitingOrTimedOut(), and ElementInfo.notifies0() has to be aware of it
fixed NPE when setting report.probe_interval in tests, which was missing that it had to create a stat object
author | Peter Mehlitz <Peter.C.Mehlitz@nasa.gov> |
---|---|
date | Tue, 21 Apr 2015 00:34:15 -0700 |
parents | 61d41facf527 |
children |
comparison
equal
deleted
inserted
replaced
23:db918c531e6d | 24:6774e2e08d37 |
---|---|
299 vm.no_orphan_methods = false | 299 vm.no_orphan_methods = false |
300 | 300 |
301 # if this is set to true, overriden finalize() methods execute upon objects garbage collections | 301 # if this is set to true, overriden finalize() methods execute upon objects garbage collections |
302 vm.process_finalizers = false | 302 vm.process_finalizers = false |
303 | 303 |
304 | |
305 ### jvm specifics | |
306 | |
307 # di=o we model nested locks during class init (to detect possible hotspot dealocks during init) | |
308 # (off by default since it can cause state explosion) | |
309 jvm.nested_init=false | |
310 | |
311 # if so, for which classes (default is to exclude system classes) | |
312 jvm.nested_init.exclude=java.*,javax.*,sun.misc.* | |
313 | |
314 | |
304 ############################### 3. CG part ############################### | 315 ############################### 3. CG part ############################### |
305 | 316 |
306 # choice randomization policy in effect: | 317 # choice randomization policy in effect: |
307 # "NONE" - choice sets are not randomized | 318 # "NONE" - choice sets are not randomized |
308 # "FIXED_SEED" - choice sets are randomized using a fixed seed for each JPF run (reproducible) | 319 # "FIXED_SEED" - choice sets are randomized using a fixed seed for each JPF run (reproducible) |