RFR(S) 8134898: Small fixes found during JVMCI work

[Coleen Phillimore]

On 9/1/15 7:59 PM, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8134898/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8134898
>
> During review of JVMCI changes we were asked to push not related small 
> changes separately.
>
> Removed jre/ from jdk paths in makefiles since jdk9 does not have it 
> anymore.
> Solaris vm.make and buildtree.make missed changes other unix platforms 
> have.
> Fix type in doc.
> Added -DCHECK_UNHANDLED_OOPS to debug build. I very strongly want to 
> do that.
Adding -DCHECK_UNHANDLED_OOPS to the debug build adds a level of 
indirection to the oops that are somewhat annoying during debugging:

eg.

692    void java_lang_Class::set_component_mirror(oop java_class, oop 
comp_mirror) {
693      assert(_component_mirror_offset != 0, "must be set");
694        java_class->obj_field_put(_component_mirror_offset, comp_mirror);
695      }

(gdb) print java_class
$7 = {_o = 0x8cb003b8}
(gdb) print java_mirror
No symbol "java_mirror" in current context.
(gdb) print comp_mirror
$8 = {_o = 0x8cb001b0}
(gdb) call hsfind(java_class._o)
warning: Using non-standard conversion to match function hsfind to 
supplied arguments

"Executing hsfind"
0x000000008cb003b8 is an oop
java.lang.Class
  - klass: 'java/lang/Class'
  - ---- fields (total size 13 words):
...


vs.

693      assert(_component_mirror_offset != 0, "must be set");
(gdb) print java_class
$1 = (oop) 0x8cb003b8
(gdb) print comp_mirror
$2 = (oop) 0x8cb001b0
(gdb) print hsfind(java_class)
warning: Using non-standard conversion to match function hsfind to 
supplied arguments

"Executing hsfind"
0x000000008cb003b8 is an oop
java.lang.Class
  - klass: 'java/lang/Class'
  - ---- fields (total size 13 words):
...


The GC people deal with far more 'oop' objects in their debugging, which 
is why they asked me originally not to enable CHECK_UNHANDLED_OOPS in 
the debug build.

To resolve the incompatibility, you can simply remove 
CHECK_UNHANDLED_OOPS around the field in Thread, and put it under 
#ifndef PRODUCT.

Coleen
> It is the only incompatibility in memory layout between fastdebug and 
> debug VM. We maintained such compatibility for long time and it was 
> broken with 7195622 changes.
> For AOT project it is very important to keep compatibility because we 
> use fastdebug VM for JAOTC tool to compile aot code and we want to be 
> able use debug VM to debug execution of aot code.
> Note, using debug VM with JAOTC will take 5-10 times longer to compile.
>
> Thanks,
> Vladimir