RFR(S) 8032656: Tag the MachSpillCopies with purpose information (original) (raw)

Niclas Adlertz niclas.adlertz at oracle.com
Wed Jan 29 14:27:27 PST 2014

Hi Vladimir,

Thank you. Here is the new webrev:http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev02/ I also included machnode.hpp in chaitin.hpp since we need the definition of MachSpillCopyNode::SpillType. (Build failed on Solaris otherwise).

Kind Regards, Niclas Adlertz

On 2014-01-29 19:46, Vladimir Kozlov wrote:

Niclas,

Changes are fine but names should be adjusted. I think we should use original "SpillCopy" suffix instead of "SpillNode". "RegToMem" and "MemToReg" are missing the suffux. Thanks, Vladimir On 1/29/14 3:14 AM, Niclas Adlertz wrote: Hi Vladimir K,

Thank you for your response. Here is an updated webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev01/ Kind Regards, Niclas Adlertz

On 2014-01-28 18:21, Vladimir Kozlov wrote: On 1/28/14 3:18 AM, Niclas Adlertz wrote: Hi Vladimir,

Thank you for your response. That is a possibility as well. By using an enum I still have the problem of deciding what to return in Name(). I could have either * an array of const char* with the names and index into it by using the enum when returning a name * a switch-case on the enums in the Name() method. Switch by enum in Name().

However, I think sub-classing the MachSpillCopyNode looks cleaner. The sub-classing approach could also be of use in a product build when debugging a crash and we want to check what type of node we are at. You can determine type by enum value too. Thanks, Vladimir If it's ok with you, I'll wait and see what the others think. If more people think the enum approach is better I can use enums instead. Kind Regards, Niclas Adlertz On 2014-01-28 11:50, Vladimir Ivanov wrote: Niclas, Why didn't you introduce an enum instead and pass the reason to constructor? Introducing 13 subclasses just to overload Name() method in debug builds looks like an overkill to me. Best regards, Vladimir Ivanov On 1/28/14 2:07 PM, Niclas Adlertz wrote: Hi all,

When debugging or visualizing spills/splits/moves in C2 it's hard to know what caused an insertion of a certain MachSpillCopy. I've made this easier by creating subclasses of the MachSpillCopyNode. webrev: http://cr.openjdk.java.net/~adlertz/JDK-8032656/webrev00/ bug: https://bugs.openjdk.java.net/browse/JDK-8032656 Kind Regards, Niclas Adlertz

More information about the hotspot-compiler-dev mailing list