[8u20] RFR Backports of 8035735, 8028497 and 8039904

[Lois Foltan]

Hi Coleen,

I had started to look at this earlier, thanks for the updated webrevs.  
I think all 3 webrevs look fine.

Lois

On 4/16/2014 6:40 PM, Coleen Phillimore wrote:
>
> Thanks Dan for the code review and for creating webrevs for the 
> patches.   They are here:
>
> open webrev at 
> http://cr.openjdk.java.net/~coleenp/8035735_8u20/0-for-jdk8u-hs
> open webrev at 
> http://cr.openjdk.java.net/~coleenp/8028497_8u20/0-for-jdk8u-hs
> open webrev at 
> http://cr.openjdk.java.net/~coleenp/8039904_8u20/0-for-jdk8u-hs
>
> Coleen
>
> On 4/16/14, 6:36 PM, Daniel D. Daugherty wrote:
>> At this point, I've compared Coleen's exported JDK8u changesets
>> with the patch files from the JDK9-hs-rt versions.
>>
>>
>> On 4/16/14 2:32 PM, Daniel D. Daugherty wrote:
>>> Usually when you request a backport review you supply webrevs
>>> relative to the backport target repo. All of the webrevs here
>>> appear to the JDK9 webrevs so there's not really any way that
>>> a reviewer can verify that your backport is correct.
>>>
>>> > http://cr.openjdk.java.net/~coleenp/8035735/
>>>
>>> src/share/vm/code/debugInfo.hpp
>>> src/share/vm/oops/metadata.hpp
>>>     No comments; I expect this to be a clean backport.
>>
>> The patch that Coleen imported for JDK8u includes changes made
>> after the JDK9 webrev was generated (during the code review cycle).
>> So the JDK8u version matches the JDK9 version. Thumbs up!
>>
>>
>>> > http://cr.openjdk.java.net/~coleenp/8028497_4/
>>>
>>> src/share/vm/classfile/classFileParser.cpp
>>> src/share/vm/classfile/javaClasses.cpp
>>> src/share/vm/classfile/javaClasses.hpp
>>> src/share/vm/classfile/systemDictionary.cpp
>>> src/share/vm/classfile/systemDictionary.hpp
>>> src/share/vm/gc_interface/collectedHeap.cpp
>>> src/share/vm/gc_interface/collectedHeap.hpp
>>> src/share/vm/oops/constantPool.cpp
>>> src/share/vm/oops/instanceKlass.cpp
>>> src/share/vm/oops/instanceKlass.hpp
>>> src/share/vm/oops/instanceMirrorKlass.cpp
>>> src/share/vm/oops/klass.cpp
>>> src/share/vm/oops/method.cpp
>>> src/share/vm/oops/method.hpp
>>>     This might be a candidate for a clean backport, but I
>>>     don't know this code well enough to make that call
>>>     without a JDK8u relative webrev.
>>
>> The patch that Coleen imported for JDK8u is different
>> than the JDK9 webrev version; as Coleen mentioned below
>> there are name changes from 'this_k' -> 'this_oop'.
>> Thumbs up!
>>
>>
>>>
>>> > http://cr.openjdk.java.net/~coleenp/8039904/
>>>
>>> src/share/vm/gc_interface/collectedHeap.hpp
>>> src/share/vm/gc_interface/collectedHeap.inline.hpp
>>> src/share/vm/runtime/sharedRuntime.cpp
>>> src/share/vm/runtime/sharedRuntime.hpp
>>>     No comments; I expect this to be a clean backport.
>>
>> The patch that Coleen imported for JDK8u matches the
>> JDK9 webrev version (modulo copyrights and line numbers).
>> Thumbs up!
>>
>> Dan
>>
>>
>>>
>>>
>>> Dan
>>>
>>>
>>> On 4/15/14 3:39 PM, Coleen Phillimore wrote:
>>>>
>>>> Please review backports of these bug fixes in JDK9.  Nightly 
>>>> testing has been running this code for a few nights now.
>>>>
>>>> 8035735: Metaspace::contains become extremely slow in some cases
>>>> Summary: Call is_metadata instead which does less work for the call 
>>>> in debugInfo.hpp which is called for all compiled code stack frames.
>>>> Reviewed-by: jmasa, dcubed
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8035735
>>>> http://cr.openjdk.java.net/~coleenp/8035735/
>>>>
>>>> (changeset applied cleanly)
>>>>
>>>> 8028497: SIGSEGV at ClassLoaderData::oops_do(OopClosure*, 
>>>> KlassClosure*, bool)
>>>> Summary: Keep class in CLD::_klasses list and mirror created for 
>>>> CDS classes if OOM during restore_shareable_info(). This keeps 
>>>> pointers consistent for CMS.
>>>> Reviewed-by: ehelin, stefank, jmasa, iklam
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/8028497_4/
>>>> https://bugs.openjdk.java.net/browse/JDK-8028497
>>>>
>>>> (changeset had one difference because of name change from this_oop 
>>>> to this_k).
>>>>
>>>> 8039904: dtrace/hotspot/Monitors/Monitors001 fails with "assert(s > 
>>>> 0) failed: Bad size calculated"
>>>> Summary: Dtrace monitoring uses size before mirror size is set.
>>>> Reviewed-by: kamg, hseigel
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/8039904/
>>>> https://bugs.openjdk.java.net/browse/JDK-8039904
>>>>
>>>> (changeset applied cleanly)
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>