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

Coleen Phillimore coleen.phillimore at oracle.com
Wed Sep 2 03:55:53 UTC 2015

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

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

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

More information about the hotspot-dev mailing list