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