RFR: 8159613: [Findbugs] various warnings reported for JVMCI sources

[Christian Thalinger]

> On Jun 22, 2016, at 7:23 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> 
>> 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[1] 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.

Yes, that’s better.

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

Good.

> These changes are in HotSpotMethodData.java and HotSpotMethodDataAccessor.java in this updated webrev:
> 
> http://cr.openjdk.java.net/~dnsimon/8159613-v2/ <http://cr.openjdk.java.net/~dnsimon/8159613-v2/>
> 
> -Doug
> 
> [1] http://cr.openjdk.java.net/~dnsimon/8159613/FindBugsIssues.txt
> 
>> 
>>> 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[1] 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.
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8159613
>>> http://cr.openjdk.java.net/~dnsimon/8159613/
>>> 
>>> -Doug
>>> 
>>> [1] http://cr.openjdk.java.net/~dnsimon/8159613/FindBugsIssues.txt
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160622/a6810409/attachment-0001.html>