RFR: 8159613: [Findbugs] various warnings reported for JVMCI sources
doug.simon at oracle.com
Wed Jun 22 14:23:28 UTC 2016
> On 22 Jun 2016, at 00:10, Christian Thalinger <cthalinger at twitter.com> wrote:
> Why are we moving the static fields out of the inner classes in HotSpotMethodData? It makes it harder to understand.
This was done to resolve initialization circularity warnings such as:
M D IC: Initialization circularity between jdk.vm.ci.hotspot.HotSpotMethodData and jdk.vm.ci.hotspot.HotSpotMethodData$ArgInfoData At HotSpotMethodData.java:[lines 47-913]
However, I get your point about decreasing readability and so have moved the constants to just before the nested classes that they used to be declared in. At the same time, I got rid of the completely unnecessary jdk.vm.ci.hotspot.HotSpotMethodDataAccessor.Tag enum which added no value and further complicated understanding of the initialization sequence. These changes are in HotSpotMethodData.java and HotSpotMethodDataAccessor.java in this updated webrev:
>> On Jun 20, 2016, at 1:00 PM, Doug Simon <doug.simon at oracle.com> wrote:
>> Please review this webrev which addresses all the issues identified by FindBugs in the JVMCI Java code. A significant number of issues related to exposing array fields. For example:
>> M V EI: jdk.vm.ci.hotspot.sparc.SPARCHotSpotRegisterConfig.getCallerSaveRegisters() may expose internal representation by returning SPARCHotSpotRegisterConfig.callerSaveRegisters At SPARCHotSpotRegisterConfig.java:[line 187]
>> M V EI: jdk.vm.ci.amd64.AMD64.getAvailableValueRegisters() may expose internal representation by returning AMD64.valueRegistersSSE At AMD64.java:[line 252]
>> These have been addressed by either creating an immutable array wrapper classes (e.g. RegisterArray) or by documenting intentional mutability and applying @SuppressFBWarnings where necessary.
>>  http://cr.openjdk.java.net/~dnsimon/8159613/FindBugsIssues.txt
More information about the hotspot-compiler-dev