RFR: 8024927: Nashorn performance regression with CompressedOops

[Stefan Karlsson]

On 10/24/13 6:03 AM, Coleen Phillimore wrote:
> Summary: Allocate compressed class space at end of Java heap.  For 
> small heap sizes, without CDS, reserve some space under 32G so 
> compressed classes can have the same (more favorable) compression 
> algorithm as oops.
>
> This change may have to be reverted when we implement extending 
> compressed class spaces in the future, but it gets back the 
> performance of these nashorn benchmarks, and seems to make sense for 
> small heaps.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8024927/
> bug link https://bugs.openjdk.java.net/browse/JDK-8024927

Hi Coleen,

If I you run with a small heap, say -Xmx128m, you get shifted compressed 
klass pointers. Is that intentional?

$ java -Xmx128m -XX:+PrintCompressedOopsMode -version

heap address: 0x00000000f8000000, size: 128 MB, zero based Compressed 
Oops, 32-bits Oops

Narrow klass base: 0x0000000000000000, Narrow klass shift: 3
Compressed class space size: 1073741824 Address: 0x0000000100000000 Req 
Addr: 0x0000000100000000


Some comments:

http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/metaspace.cpp.frames.html

+  uint64_t klass_encoding_max = NarrowOopHeapMax << 
LogKlassAlignmentInBytes;

Shouldn't you be using this constant: ?
  const uint64_t KlassEncodingMetaspaceMax = (uint64_t(max_juint) + 1) 
<< LogKlassAlignmentInBytes;


2818   uint64_t klass_encoding_max = NarrowOopHeapMax << 
LogKlassAlignmentInBytes;
2819   // If compressed class space fits in lower 32G, we don't need a base.
2820   if (higher_address <= (address)klass_encoding_max) {
2821     Universe::set_narrow_klass_base(0);
2822     lower_base = 0; // effectively lower base is zero.
2823   } else {
2824     Universe::set_narrow_klass_base(lower_base);
2825   }
2826
2827   if ((uint64_t)(higher_address - lower_base) < (uint64_t)max_juint) {
2828     Universe::set_narrow_klass_shift(0);
2829   } else {
2830     assert(!UseSharedSpaces, "Cannot shift with UseSharedSpaces");
2831     Universe::set_narrow_klass_shift(LogKlassAlignmentInBytes);
2832   }

If you execute line 2822, will you hit the assert at line 2830 if you 
run with CDS and set SharedBaseAddress.

$ java -Xshare:dump -Xmx128m -XX:SharedBaseAddress=8g 
-XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version

heap address: 0x00000000f8000000, size: 128 MB, zero based Compressed 
Oops, 32-bits Oops

Loading classes to share ... done.
Rewriting and linking classes ... done.
Number of classes 2359
Calculating fingerprints ... done.
Removing unshareable information ... done.
ro space:   6895936 [ 34.7% of total] out of  16777216 bytes [41.1% 
used] at 0x0000000200000000
rw space:  10849560 [ 54.5% of total] out of  16777216 bytes [64.7% 
used] at 0x0000000201000000
md space:   2120272 [ 10.7% of total] out of   4194304 bytes [50.6% 
used] at 0x0000000202000000
mc space:     34053 [  0.2% of total] out of    122880 bytes [27.7% 
used] at 0x0000000202400000
total   :  19899821 [100.0% of total] out of  37871616 bytes [52.5% used]


$ java -Xshare:on -Xmx128m -XX:SharedBaseAddress=8g 
-XX:+PrintCompressedOopsMode -XX:+VerifyBeforeGC -version

heap address: 0x00000000f8000000, size: 128 MB, zero based Compressed 
Oops, 32-bits Oops

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/metaspace.cpp:2874
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error 
(/home/stefank/hg/hsx-gc/src/share/vm/memory/metaspace.cpp:2874), 
pid=32067, tid=140386534242048
#  assert(!UseSharedSpaces) failed: Cannot shift with UseSharedSpaces
#
# JRE version:  (8.0-b110) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b55-internal-debug 
mixed mode, sharing linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable 
core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /localhome/tests/SPECjbb2005/hs_err_pid32067.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#



2852   assert_is_ptr_aligned(requested_addr, _reserve_alignment);
2853   assert_is_ptr_aligned(cds_base, _reserve_alignment);
2854   assert_is_size_aligned(compressed_class_space_size(), 
_reserve_alignment);

Could you keep the alignment, or remove it?


-        allocate_metaspace_compressed_klass_ptrs((char 
*)CompressedKlassPointersBase, 0);
+        char* base = (char*)Universe::heap()->reserved_region().end();
+        allocate_metaspace_compressed_klass_ptrs(base, 0);

You need to make sure that 'base' address is aligned against 
Metaspace::reserve_alignment().


http://cr.openjdk.java.net/~coleenp/8024927/src/share/vm/memory/universe.cpp.udiff.html

+          if (UseCompressedClassPointers &&
+              LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes) {
+            // For small heaps, save some space for compressed class 
pointer
+            // space with no base, only when ObjAlignmentInBytes is 64 
bits.
+            uint64_t class_space = 
align_size_up(CompressedClassSpaceSize, alignment);
+ assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space,
+                   alignment), "difference must be aligned too");
+            uint64_t new_top = OopEncodingHeapMax-class_space;
+
+            if (total_size <= new_top) {
+              base = (new_top - heap_size);
+            } else {
+              base = (OopEncodingHeapMax - heap_size);
+            }

I don't understand why you have this restriction:
  LogMinObjAlignmentInBytes == LogKlassAlignmentInBytes

thanks,
StefanK

>
> Tested with ute vm.quick.testlist vm.mlvm.testlist on linux/x64 
> solaris/x64 and windows/x64 (in progress).  Also running refworkload.
>
> Thanks,
> Coleen