RFC: Remove DONT_USE_REGISTER_DEFINES on Sparc?

[Per Liden]

Ok, thanks! I'll file an RFE and send the patch out for formal review.

And yes, it passed hs-tier{1,2} in mach5.

/Per


On 2018-03-22 19:38, Vladimir Kozlov wrote:
> Yes, you can remove this code. Please, build fastdebug version of VM 
> too to verify that it works. And run tier1.
>
> Thanks,
> Vladimir
>
> On 3/22/18 6:39 AM, Erik Österlund wrote:
>> Hi Per,
>>
>> I welcome this change. Stealing the identifier G1 from the global 
>> name space seems like a problem. Inflating the libjvm.so size by 
>> ~0.3% on a SPARC machine does not seem like a problem.
>>
>> Thanks,
>> /Erik
>>
>> On 2018-03-22 12:14, Per Liden wrote:
>>> Hi,
>>>
>>> We recently ran into an unfortunate naming conflict, concerning "G1" 
>>> the garbage collector vs. "G1" the sparc register. We'd like to be 
>>> able to use "G1" as an enum value in various GC code, but 
>>> register_sparc.hpp defines "G1" as a macro, which obviously breaks 
>>> things.
>>>
>>> We're very reluctant to sprinkling #define DONT_USE_REGISTER_DEFINES 
>>> in GC code. An alternative would be to simply remove this 
>>> optimization in the sparc code. The comment in register_sparc.hpp 
>>> suggests that this was done to reduce the size of libjvm.so.
>>>
>>> I applied a patch[1] to remove the sparc macros and libjvm.so grew 
>>> by ~0.3% (66450K->66682K). Builds available here[2] and here[3].
>>>
>>> Given that the libjvm.so growth doesn't seem that bad, would people 
>>> be ok with removing the register defines on sparc? If so I'll file a 
>>> bug and send out the patch for formal review.
>>>
>>> The patch currently removes all register defines. There are of 
>>> course alternatives here in case someone things the libjvm growth is 
>>> unacceptable, like only remove general register, only G* registers, 
>>> etc.
>>>
>>> /Per
>>>
>>> [1] 
>>> http://cr.openjdk.java.net/~pliden/remove_G1_define_on_sparc/webrev.0
>>>
>>> [2] 
>>> https://java.se.oracle.com/artifactory/jdk-dev-local/jdk/personal/per.liden/2018-03-22-0935410.per.liden.hs/bundles/solaris-sparcv9/ 
>>>
>>>
>>> [3] 
>>> https://java.se.oracle.com/artifactory/jdk-dev-local/jdk/personal/per.liden/2018-03-22-0952297.per.liden.hs/bundles/solaris-sparcv9/ 
>>>
>>