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

[Coleen Phillimore]

Thank you Lois!
Coleen

On 4/16/14, 6:50 PM, Lois Foltan wrote:
> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>