RFR(M): 8206977: Minor improvements of runtime code.

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Wed Jul 11 16:44:34 UTC 2018



On 7/10/18 3:10 PM, Lois Foltan wrote:
> Hi Goetz,
>
> Just a couple of comments based on Coleen's review, see below.
>
> On 7/10/2018 9:03 AM, coleen.phillimore at oracle.com wrote:
>
>> http://cr.openjdk.java.net/~goetz/wr18/8206977-covRuntime/01/src/hotspot/share/classfile/moduleEntry.cpp.udiff.html 
>>
>>
>> + name ? name->as_C_string() : "<unnamed>");
>
> Instead of "<unnamed>" please use the UNNAMED_MODULE macro from 
> moduleEntry.hpp.
>
>>
>>
>> Can you change to:
>>
>> + name != NULL ? name->as_C_string() : "<unnamed>");
>>
>>
>> http://cr.openjdk.java.net/~goetz/wr18/8206977-covRuntime/01/src/hotspot/share/oops/klassVtable.cpp.udiff.html 
>>
>>
>> This looks a lot nicer!   Similar code is in linkResolver.cpp, can 
>> you look at changing it too?
>
> I have an RFR out currently for JDK-8205611, (see 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/033325.html), 
> which needs one more reviewer's okay.  It contains changes to reword 
> the error messages for loader constraint violations in order to follow 
> the new proposed format for module and class loader information.  So 
> our two changes will conflict in this area.

Goetz, if you want to check in this to 11, I think Lois can change it 
similarly in the linkResolver code with her change for 12, once it 
migrates down.

Thanks,
Coleen

>
> Thanks,
> Lois
>
>>
>> http://cr.openjdk.java.net/~goetz/wr18/8206977-covRuntime/01/src/hotspot/share/services/writeableFlags.cpp.udiff.html 
>>
>>
>> If name is null here, what would this do?  Should there be an 'else' 
>> to print something?
>>
>> I think this looks fine.  It doesn't look major to me.  The asserts 
>> turned to guarantees don't appear to be anywhere performance sensitive.
>>
>> Thanks,
>> Coleen
>>
>>
>>
>> On 7/10/18 6:53 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I ran coverity on the jdk11 hotspot sources and want to propose the
>>> following fixes to the runtime code. I scanned the linux x86_64 build.
>>> Some issues are similar to previous parfait fixes (check for NULL, add
>>> guarantees etc.) I also identified some issues I consider real 
>>> problems.
>>> http://cr.openjdk.java.net/~goetz/wr18/8206977-covRuntime/01/
>>>
>>> In detail:
>>>
>>> Real issues:
>>> ------------
>>>
>>> jvmtiEnvBase.cpp
>>>    || should be &&.
>>>    Attention, this is the only change that really will change 
>>> behaviour.
>>>    But if thr == NULL we will see a crash below.
>>>
>>> perfMemory_linux.cpp:
>>>    Wrong buffer length used.
>>>
>>> systemDictionary.cpp:
>>>    Move code dereferencing ik under if (ik != NULL).
>>>
>>> virtualspace.cpp
>>>    Initialization is missing. Moved constructor up to the other
>>>    constructors.
>>>
>>>
>>> Useful code improvements:
>>> -------------------------
>>>
>>> vm_version_ext_x86.cpp
>>>    Assure buffer is not accessed at offset -1.
>>>
>>> os_linux.cpp
>>>    Numa_max_node returns int, and a -1 in some cases.
>>>
>>> moduleEntry.cpp
>>>    name might be NULL. Just a fix for tracing.
>>>
>>> systemDictionaryShared.cpp
>>>    clearify code.
>>>    It would be wrong if only entry == NULL would hold, one
>>>    would hit the assertion below.
>>>
>>> verifier.cpp
>>>    Fix tracing.
>>>    Illegal opcode is -1 and should not be passed to name array.
>>>
>>> logOutput.cpp
>>>    If n_selections == 0, best_selection would be NULL.
>>>    Move up the assertion and turn into a guarantee.
>>>
>>> filemap.cpp
>>>    Either base can be NULL, or parts of the code before are dead.
>>>
>>> metaspace.cpp
>>>    We now an exception is pending.
>>>
>>> klassVtable.cpp
>>>    Coverity does not like the format in a variable.
>>>    Anyways this is quite rough coding, transformed to use stringStream
>>>    as with other similar exceptions.
>>>
>>> jvmFlag.cpp
>>>    match might be NULL.
>>>
>>> writableFlags.cpp
>>>    name might be NULL.
>>>
>>> ostream.cpp
>>>    If ftell returns error code -1, we need not continue.
>>>    Especially we should not fseek(-1).
>>>
>>> logTestUtils.inline.hpp
>>>    ftell returns -1.
>>>
>>> test_metachunk.cpp
>>>    wrong datatype.
>>
>



More information about the hotspot-runtime-dev mailing list