converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|'gcpoints' LIR transformation is an early stage of [:Jitrino_OPT/gcmap: gcmap] pass.
|'gcpoints' LIR transformation is an early stage of [[Jitrino_OPT/gcmap| gcmap]] pass.
|Line 4:||Line 4:|
|Line 6:||Line 6:|
|Line 8:||Line 8:|
|Line 10:||Line 10:|
|Line 13:||Line 13:|
|implementation file: [http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/jitrino/src/codegenerator/ia32/Ia32GCSafePoints.cpp?view=markup http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/jitrino/src/codegenerator/ia32/Ia32GCSafePoints.cpp]||implementation file: [[http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/jitrino/src/codegenerator/ia32/Ia32GCSafePoints.cpp?view=markup|http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/jitrino/src/codegenerator/ia32/Ia32GCSafePoints.cpp]]|
'gcpoints' LIR transformation is an early stage of gcmap pass.
The sole purpose of this transformation is insertion of CopyPseudoInsts instructions to extends live-ranges for object(base) operands.
The CopyPseudoInsts are inserted only in the case if the base operand have live managed pointer operand derived from the base and the offset of managed pointer from the base is not a compilation time constant.
The example of unknown offset is an iteration of array in loop: the base pointer can be dead in loop while managed pointer is alive and changes every new iteration.
The reason to extend the live range of object operands is due to the fact that JIT-GC interface requires from JIT to report base for every managed pointer.
Making base object alive we can derive offset of managed pointer during enumeration in runtime: the offset is a distance to the nearest base included to the enumeration set.