RFC: Remove DONT_USE_REGISTER_DEFINES on Sparc?

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Mar 22 18:38:36 UTC 2018


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/ 
>>
> 


More information about the hotspot-compiler-dev mailing list