Message-ID: <1123766717.7134.1422578359023.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7133_1971862403.1422578359023" ------=_Part_7133_1971862403.1422578359023 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In early implementations of Jikes RVM's adaptive system, compila= tion required holding a global lock that serialized compilation and also pr= evented classloading from occurring concurrently with compilation. Th= is bottleneck was removed in version 2.1.0 by switching to a finer-grained = locking discipline to coordinate compilation, speculative optimization, and= class loading. Since no published description of this locking protocol exi= sts outside of the source code, we briefly summarize the life cycle of a co= mpiled method here.=20
When Jikes RVM compiles a method, it creates a compiled method object to= represent this particular compilation of the source method. A compil= ed method has a unique id, and stores the compiled code and associated comp= iler meta-data. After a brief initialization phase, the compiled method tra= nsitions from uncompiled to compiling when compilation be= gins. During compilation, the optimizing compiler may perform speculative o= ptimizations that can be invalidated by future class loading. Each ti= me the compiler so speculates, it records a relevant entry in an invalidati= on database. Upon finishing compilation, the system checks to ensure = that the current compilation has not already been invalidated by conc= urrent classloading. If it has not, then the system installs the comp= iled code, and subsequent invocations will branch to the newly create= d code.=20
Each time a class is loaded, the system checks the invalidation database=
to identify the set of compiled methods to mark as obsolete,
because= this classloading action invalidates speculative optimizations previously = applied to that method. A method may transition from either compi= ling or installed to obsolete due to a classloading-= induced invalidation. A method can also transition from installed= to obsolete when the adaptive system selects a method for op= timizing recompilation and a new compiled method is installed to replace it= .
Once a method is marked obsolete, it will never be invoked again. = However, before the generated code for the compiled method can be garbage c= ollected, all existing invocations of the compiled method must be complete.= A compiled method transitions from obsolete to de= ad when no invocations of it exist on any thread stack. Jikes RV= M detects this as part of the stack scanning phase of garbage collection; a= s stack frames are scanned, their compiled methods are marked as active.&nb= sp; Any obsolete method that is not marked as active when stack sc= anning completes is marked as dead and the reference to it is remo= ved from the compiled method table. It will then be freed during the = next garbage collection.