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

[Coleen Phillimore]

Dan, 8028497 wasn't a clean backport.  instanceKlass.cpp/hpp needed 
manual edit so I had to patch it.  Then I already committed all three to 
three changesets and tested so I didn't know how to generate a jdk8u 
relative webrev for each.

Do you know how to do this without me rolling back anything?   I'm sure 
there's some magic hg command to do it, I just don't know how.

Thanks for the review,
Coleen

On 4/16/14, 4: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.
>
> > 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.
>
> > 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.
>
>
> 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
>>
>>
>>
>>
>