Changing lots of files - mainly GC code

[Jesper Wilhelmsson]

Coleen,

Thanks for the review!

When looking at the runtime code I also found a ResourceMark rm; on line 841 in 
safepoint.cpp that seems unused. I won't remove it in the typos fix and I don't 
edit the safepoint code on a regular basis. Maybe you (or someone else) have 
related changes where it makes sense to remove it?
/Jesper


Coleen Phillmore skrev 13/1/14 2:44 PM:
>
> Hi Jesper,
> The runtime changes look great, thanks!   I suggest pushing them all together in
> hs-gc so there's a single changeset.  I don't see any merge difficulty with
> these changes.
> Thanks!
> Coleen
>
> On 1/13/2014 8:13 AM, Jesper Wilhelmsson wrote:
>> Hi Coleen!
>>
>> I accidentally browsed the runtime directory this weekend and found about 70
>> typos. I have updated the webrev to include these.
>>
>> Do you want me to push them as part of the GC-fix? (If so, please review the
>> runtime-part of the change ;-) )
>> /Jesper
>>
>>
>> Coleen Phillmore skrev 10/1/14 4:54 PM:
>>> Seems fine with me also.  Could you find typos in the comments in the runtime
>>> code "by accident" too? :)
>>> thanks,
>>> Coleen
>>>
>>> On 1/10/2014 10:39 AM, Daniel D. Daugherty wrote:
>>>> On 1/10/14 5:49 AM, Jesper Wilhelmsson wrote:
>>>>> Hi,
>>>>>
>>>>> I have a change out for review that fixes a huge pile of typos in the
>>>>> comments in the GC code. The RFR was sent to the GC list, but I want to give
>>>>> a heads up in case anyone else is changing GC code and want to avoid merge
>>>>> conflicts.
>>>>>
>>>>> The patch: http://cr.openjdk.java.net/~jwilhelm/8025856/webrev.1/
>>>>>
>>>>>
>>>>> There are also a few files where I happened to find a few typos "by accident"
>>>>> in code that is not strictly GC code. These are:
>>>>>
>>>>> src/share/vm/memory/heap.cpp
>>>>> src/share/vm/memory/heap.hpp
>>>>> src/share/vm/memory/allocation.hpp
>>>>> src/share/vm/memory/resourceArea.hpp
>>>>> src/share/vm/runtime/thread.cpp
>>>>>
>>>>> There is a total of eight typos fixed in these files so I think the risk of
>>>>> merge conflicts here is minimal. Are there any objections to including these
>>>>> fixes in the change?
>>>>
>>>> Vote: go for it!
>>>>
>>>> Dan
>>>>
>>>>>
>>>>> Thanks,
>>>>> /Jesper
>>>>
>>>
>