RFR (L/S) manual cleanup of white space issues (8057109)

[Frederic Parain]

Dan,

Thank you for this additional cleaning. It looks good to me,
only a few minor issues (feel free to ignore them):

src/os/bsd/vm/os_bsd.cpp:1937-1943

   Why typedef statements are not aligned with #define statements?

src/os/windows/vm/os_windows.cpp:

   1606     if (lib_arch == arch_array[i].arch_code)
   1607       lib_arch_str = arch_array[i].arch_name;
   1608     if (running_arch == arch_array[i].arch_code)
   1609       running_arch_str = arch_array[i].arch_name;

   Brackets around the conditioned statements could make the code
   easier to read.

     if (lib_arch == arch_array[i].arch_code) {
       lib_arch_str = arch_array[i].arch_name;
     }
     if (running_arch == arch_array[i].arch_code) {
       running_arch_str = arch_array[i].arch_name;
     }

   lines 4442-4443: do we really need two lines of empty comments?

Regards,

Fred

On 07/09/2014 21:13, Daniel D. Daugherty wrote:
> Greetings,
>
> I have the fix for the following bug ready for JDK9 RT_Baseline:
>
>      JDK-8057109 manual cleanup of white space issues prior to Contended
>                  Locking reorder and cache line bucket
>      https://bugs.openjdk.java.net/browse/JDK-8057109
>
> This is both a (L)arge and a (S)mall review! Here is the URL for the
> (L)arge webrev:
>
> http://cr.openjdk.java.net/~dcubed/8057109-webrev/0-jdk9-hs-rt/
>
> Since these are mostly white space fixes, I recommend the udiff links
> instead of the frames links. Of course, some folks prefer the patch file
> itself for white space fixes.
>
> Here is the URL for the (S)mall webrev which was generated with a version
> of webrev that ignores all whitespace changes:
>
> http://cr.openjdk.java.net/~dcubed/8057109-webrev/0-jdk9-hs-rt-no_ws/
>
> Again, I recommend the udiff links since that's the fastest way to see
> that webrev_no_ws found minimal non-white space changes. The patch file
> for this webrev shows all the changes.
>
> These manual changes were motivated by various review comments made for
> earlier fixes in the Contended Locking project. During those reviews, I
> deferred making some of the requested format changes to this round of
> manual changes. In most cases, the reviewers posted comments with one
> or two examples of things they did not like and I've swept all 17 files
> that we've targeted for cleanup in the Contended Locking project looking
> for those style problems and fixing them. I've made a total of 12 passes
> over the 17 files, but I cannot say that I've caught everything. Most
> stuff that annoys people is fixed, but it's very difficult to catch and
> fix them all without a real parser based solution.
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Dan
>
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com