Message-ID: <1572794261.25775.1394290569738.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_25774_541724042.1394290569737" ------=_Part_25774_541724042.1394290569737 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
One of the services that MMTk expects a virtual machine to perfo= rm on its behalf is the scanning of objects, i.e. identifying and processin= g the pointer fields of the live objects it encounters during collection. I= n principle the implementation of this interface is simple, but there are t= wo moderately complex optimizations layered on top of this.
From MMTk's point of view, each time an object requires scanning it pass= es it to the VM, along with a TransitiveClosure object. The VM is expected = to identify the pointers and invoke the processEdge method on each of the p= ointer fields in the object. The rationale for the current object sca= nning scheme is presented in this paper.=
MMTk requires its host virtual machine to provide an implementation of t= he class org.mmtk.vm.Scanning as its interface to scanning objects. J= ikesRVM's implementation of this class is found under the source tree MMTk/= ext/vm/jikesrvm, in the class org.jikesrvm.mm.mmtk.Scanning. The meth= ods we are interested in are scanObject(TransitiveClosure, ObjectR= eference) and specializedScanObject(int, TransitiveClosure, O= bjectReference).
In MMTk, each plan defines one or more TransitiveClosure operations. &nb= sp;Simple full-heap collectors like MarkSweep only define one TransitiveClo= sure, but complex plans like GenImmix or the RefCount plans define several.= MMTk allows the plan to request specialized scanning on a closure-by= -closure basis, closures that are specialized call specializedScan= Object while unspecialized ones call scanObject. Specialization = is covered in more detail below.
In the absence of hand-inlined scanning, or if specialization is globall= y disabled, scanning reverts to the fallback method in org.jikesrvm.mm.mmin= terface.SpecializedScanMethod. This method can be regarded as the bas= ic underlying mechanism, and is worth understanding in detail.
This code fetches= the array of offsets that JikesRVM uses to identify the pointer fields in = the object. This array is constructed by the classloader when a class= is resolved.
One distinguished value (actually null) is used to identify arrays of re= ference objects, and this block of code scans scalar objects by tracing eac= h of the fields at the offsets given by the offset array.
The other case is reference arrays, for which we fetch the array length = and scan each of the elements.
The internals of trace.processEdge vary by collector and by collection t= ype (e.g. nursery/full-heap in a generational collector), and the details n= eed not concern us here.
Hand inlining was introduced in February 2011, and uses a cute technique= to encode 3 bits of metadata into the TIB pointer in an object's header. &= nbsp;The 7 most frequent object patterns are encoded into these bits, and t= hen special-case code is written for each of them.
Hand inlining produces an average-case speedup slightly better than spec= ialization, but performs poorly on some benchmarks. This is why we us= e it in combination with specialization.
Specialized Scanning was introduced in September 2007. It speeds u= p GC by removing the process of fetching and interpreting the offset array = that describes each object, by jumping directly to a hard-coded method for = scanning objects with a particular pattern.
The departure point from "standard" java into the specialized =
scanning method is
SpecializedScanMethod.invoke(...), which lo=
oks like this
@SpecializedMethodInvoke annotation signals to the=
compiler that it should dispatch to one of the specialized method slots in=
Creation of specialized methods is = handled by the class