RFR(M) 8011621: Keep the "live range id - node" mapping in a separate class

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Apr 8 11:34:18 PDT 2013


Niclas,

Thank you for doing this cleanup.

Please, test affection on RA performance. You can use CTW for this and 
fastdebug VM:

${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld 
-XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar

Or build optimized VM and run jvm08, for example, with -XX:+TimeCompiler.

Can you use full name LiveRangeMap instead of LRGMap?
Don't put big methods with loops into header file, we don't want to 
increase code size without need.

Explicitly declare private: and public: parts in class. Add comment what 
is class for.

I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a 
reference through _lrg_map pointer (in compiled code C++ needs only one 
PhaseChaitin* pointer).

Thanks,
Vladimir

On 4/8/13 3:05 AM, Niclas Adlertz wrote:
> Hi all.
>
> Problem:
> In order to clean up the Split code (in opto/reg_split.cpp) making it easier to maintain and (hopefully) making it easier to improve (https://jbs.oracle.com/bugs/browse/JDK-7022320), it would be good to have the Split code more isolated with as few dependencies to other parts of the code as possible.
> The Split code could reside in an own module (class), just having references to classes and data it really needs. Right now it would need to have a reference to PhaseChaitin, only to access the "live range id - node" mapping. However, it does not need to know about everything in the PhaseChaitin class. This may also introduce cross reference problems since PhaseChaitin would use the Split module and the Split module would need a reference to PhaseChaitin.
>
> Solution:
> Move the "live range id - node" mapping to a separate class, instantiated by PhaseChaitin, which can then be passed to the Split module as a reference.
>
> Regards,
> Niclas Adlertz
>
> (Note that the webrev title is named JDK-7022320. That's just the local folder name that the code resides in. The bug is indeed 8011621)
>
> -----------------------------------------------------------------
> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev00/
>     jbs: https://jbs.oracle.com/bugs/browse/JDK-8011621
>    bugs: http://bugs.sun.com/view_bug.do?bug_id=8011621
>
>


More information about the hotspot-compiler-dev mailing list