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

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Sep 2 16:19:33 UTC 2015


Thank you, Bertrand

Your suggestion is better, I will use it. I will add comment to explain why we need the field when CHECK_UNHANDLED_OOPS 
is undefined.

Thanks,
Vladimir

On 9/2/15 1:39 AM, Bertrand Delsart wrote:
> On 02/09/2015 06:19, Vladimir Kozlov wrote:
>>  > To resolve the incompatibility, you can simply remove
>>  > CHECK_UNHANDLED_OOPS around the field in Thread, and put it under
>>  > #ifndef PRODUCT.
>>
>> Wonderful! :) I thought it requires #ifdef CHECK_UNHANDLED_OOPS.
>>
>> Please, look on new changes:
>>
>> http://cr.openjdk.java.net/~kvn/8134898/webrev.01/
>
> Looks good.
>
> Small suggestion (feel free to ignore it). Might be even better to do:
>
>     // Support for Unhandled Oop detection
> -#ifdef CHECK_UNHANDLED_OOPS
> +#if defined(CHECK_UNHANDLED_OOPS) || defined(ASSERT)
>    private:
>     UnhandledOops* _unhandled_oops;
> +#endif
> +#ifdef CHECK_UNHANDLED_OOPS
>    public:
>     UnhandledOops* unhandled_oops() { return _unhandled_oops; }
>     // Mark oop safe for gc.  It may be stack allocated but won't move.
>
> This version:
> - does not prevent someone from building a PRODUCT VM with CHECK_HANDLED_OOPS if needed
> - ensures someone does not call unhandled_oops() in debug VMs when CHECK_UNHANDLED_OOPS is not defined
>
> Bertrand (not a Reviewer).
>
>>
>> Thanks,
>> Vladimir
>>
>> On 9/1/15 8:55 PM, Coleen Phillimore wrote:
>>>
>>>
>>> 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
>>>
>
>


More information about the hotspot-dev mailing list