RegMask uses arrays of 32-bit ints to store its' values, which means most operations happen in more steps than they have to.
I did a proof-of-concept by rewriting this using uint64_t, which shows a 5% reduction in instructions and branches from C2 compilations:
https://github.com/openjdk/jdk/compare/master...cl4es:c2_opts
To not penalize 32-bit builds/platforms that should probably be written using uintptr_t or similar. At least measure and verify that the uint64_t implementation doesn't measurably hurt 32-bit builds.
            
I did a proof-of-concept by rewriting this using uint64_t, which shows a 5% reduction in instructions and branches from C2 compilations:
https://github.com/openjdk/jdk/compare/master...cl4es:c2_opts
To not penalize 32-bit builds/platforms that should probably be written using uintptr_t or similar. At least measure and verify that the uint64_t implementation doesn't measurably hurt 32-bit builds.
- relates to
- 
                    JDK-8256166 [C2] Registers get confused on Big Endian after 8221404 -           
- Resolved
 
-         
- 
                    JDK-8257221 C2: RegMask::is_bound_set split set handling broken since JDK-8221404 -           
- Closed
 
-         
 P4
  P4                      
        