[15] RFR(M) 8237497: vmStructs_jvmci.cpp does not check that the correct field type is specified

Vladimir Kozlov vladimir.kozlov at oracle.com
Sun Mar 22 16:55:09 UTC 2020


Thank you, Ioi

Thanks
Vladimir

> On Mar 21, 2020, at 11:21 AM, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> Looks good.
> 
> Thanks
> - Ioi
> 
>> On 3/20/20 5:47 PM, Vladimir Kozlov wrote:
>> Okay, as you suggested.
>> 
>> Methods JVMCIVMStructs::init() and jvmci_vmStructs_init() declaration in jvmci.cpp use NOT_DEBUG_RETURN.
>> The same for vmStructs_init() in init.cpp. I also added NOT_VM_STRUCTS_RETURN_(0) to methods in VMStructs because vmStructs.cpp file is excluded from compilation when vm-structs is excluded in configure.
>> 
>> http://cr.openjdk.java.net/~kvn/8237497/webrev.01/
>> 
>> Thanks,
>> Vladimir
>> 
>>> On 3/20/20 1:00 PM, Ioi Lam wrote:
>>> 
>>> 
>>> On 3/20/20 12:32 PM, Vladimir Kozlov wrote:
>>>> Thank you, Ioi, for looking on changes.
>>>> 
>>>> On 3/20/20 11:56 AM, Ioi Lam wrote:
>>>>> Hi Vladimir,
>>>>> 
>>>>> Why do you need jvmci_vmStructs_init()? Is it possible to call JVMCIVMStructs::init() directly?
>>>> 
>>>> For that I have to #include vmStructs_jvmci.hpp which will pull other headers as well. Which would increase parsing time of this C++ code even for product build. And I followed what we do for vmStruct - it calls vmStructs_init().
>>>> 
>>> 
>>> OK.
>>> 
>>>>> 
>>>>> Also, I think you can change the declaration as
>>>>> 
>>>>> class JVMCIVMStructs {
>>>>>     void init() NOT_DEBUG_RETURN;
>>>>> }
>>>>> 
>>>>> So the caller can avoid using DEBUG_ONLY().
>>>> 
>>>> I don't like hiding that a called code is executed only in debug more.
>>>> And why do we need to keep empty methods in product builds?
>>>> 
>>> The "XXX_RETURN;" pattern is widely used. E.g.,
>>> 
>>> class nmethod : public CompiledMethod {
>>>    void print_dependencies() PRODUCT_RETURN;
>>> }
>>> 
>>> These functions are all inlined and elided by the C++ compiler. They don't take up space in the product build.
>>> 
>>> $ nm -S debug/images/jdk/lib/server/libjvm.so | c++filt | grep nmethod::print_dependencies
>>> 000000000173fdb2 000000000000017f t nmethod::print_dependencies()
>>> 
>>> $ nm -S product/images/jdk/lib/server/libjvm.so | c++filt | grep nmethod::print_dependencies | wc
>>>        0       0       0
>>> 
>>> We only use this style of declaration for class member functions, though. I believe it's not strictly compliant to have a stray ";" in the global scope until some newer version of C++ that we have not adopted yet.
>>> 
>>> Thanks
>>> - Ioi
>>> 
>>>> It takes a lot of time to compile HotSpot VM.
>>>> 
>>>>> 
>>>>> The rest looks good to me.
>>>> 
>>>> Thank you,
>>>> Vladimir K
>>>> 
>>>>> 
>>>>> Thanks
>>>>> - Ioi
>>>>> 
>>>>> On 3/20/20 10:01 AM, Vladimir Kozlov wrote:
>>>>>> http://cr.openjdk.java.net/~kvn/8237497/webrev.00/
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8237497
>>>>>> 
>>>>>> JVMCI missed checks for declarations in vmStructs_jvmci.cpp. I copied check logic from vmStruct to fix that. It will be called during JVMCI initialization in debug build (as for vmStruct). I can't call it from vmStructs_init() because vmStruct code is guarded by INCLUDE_VM_STRUCTS variable which can be switched off with configure option --with-jvm-features=-vm-structs. On other hand JVMCIVMStruct have to be initialized always when JVMCI is used - it is how Graal accesses HotSpot's internal data.
>>>>>> 
>>>>>> The fix found several (4) cases of incorrect types in JVMCI declarations. 2 of them require update Graal code as well which I will upstream later.
>>>>>> 
>>>>>> I also did cleanup in both, vmStructs_jvmci and vmStructs.
>>>>>> In vmStructs_jvmci I removed macros which are not used (we can add them back if they needed).
>>>>>> In vmStructs I moved all check code under #ifdef ASSERT because it is called only in debug build.
>>>>>> I removed VMStructs::test() declaration which we forgot to remove when its body was removed in JDK-8171090.
>>>>>> I removed duplicated lines which existed from "day one" (before Mercurial).
>>>>>> 
>>>>>> I did local build and testing with and without --with-jvm-features=-vm-structs to make sure everything (inluding Graal) worked. I ran tier1 (which runs HotSpot gtests), hs-tier2, hs-tier3-graal.
>>>>>> 
>>>>>> Thanks,
>>>>>> Vladimir
>>>>> 
>>> 
> 



More information about the hotspot-runtime-dev mailing list