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

[Daniel D. Daugherty]

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
>>
>>
>>
>>
>
>
>