Erik Österlund erik.osterlund at oracle.com
Thu Mar 22 13:39:14 UTC 2018

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.


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