RFR: 8205957: setfldw001/TestDescription.java fails with bad field value

[Dean Long]

On Mon, 19 Aug 2024 23:46:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The summary of the problem. Test is intermittently failing because can't get expected field watch event.
>> The test is failing to get event in the 'setfmodw001b' thread with Xcomp only.
>> I verified that frame with the method 'run' of setfmodw001b is compiled when line
>> 118: setfmodw001.setWatch(4);
>> is executed, however the thread is in interp_only mode. The watch events are supported by interpreter only and just ignored by compiled code.
>> 
>> The reason of failure is race beteween setting interp_only mode in line
>> 
>> https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001.java#L75
>> 
>>  and calling method call_helper while
>>  the method run()
>> https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001.java#L116
>> 
>>  in newly created thread 'setfmodw001b' is invoked.
>> 
>> The javaCalls:call are used to invoke methods from hotspot, so it might be rare issues. But still, synchronization might be improved.
>> The
>> void JavaCalls::call_helper(JavaValue* result, const methodHandle& method, JavaCallArguments* args, TRAPS)
>> 
>> checks if interp_only mode is set and use 'Method::from_interpreted_entry()' if not. However the interp_only might be set later before compiled method is called (or enter first safe point?). This might happens in safepoint during transition via handshake.
>> So the running thread is in interp_only mode however the run() method is compiled and executed already and never going to be deoptimized.
>> 
>> The additional setWatch calls don't try to deptimize method that are already in interp_only mode.
>> 
>> BTW, the when JVMCI is enabled and verified adapter exists it is also will be loaded even in interp_only mode set. There is not race here, just ignoring of interp_only mode.
>> 
>> I run failing test with Xcomp ~1000 times and tiers1-5.
>
> src/hotspot/share/runtime/javaCalls.cpp line 358:
> 
>> 356: #endif
>> 357: 
>> 358:   CompilationPolicy::compile_if_required(method, CHECK);
> 
> I'd like to understand what is going to happen at the line 358. Are we going to compile method with -Xcomp even though the `interp_only` mode is required? If so, do we waist cycles in doing this?
> This question is not to Leonid. Maybe @dean-long could answer this, please?

Yes, I believe we will compile the method even in interp-only mode.  As -Xcomp is a mode to stress the compiler, I don't think it matters if we compile eagerly here or wait until interp-only mode is turned off.  Other threads not in interp-only mode will compile the method anyway.  But if it makes sense to change this behavior, then let's do that in a separate bug/RFE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20587#discussion_r1722600762