[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    RE: VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant?
From:       "Reingruber, Richard" <richard.reingruber () sap ! com>
Date:       2020-01-31 17:24:50
Message-ID: AM0PR0202MB333193D74B901D4B97BB94E39B070 () AM0PR0202MB3331 ! eurprd02 ! prod ! outlook ! com
[Download RAW message or body]

Hi Vladimir,

thanks for looking at this and providing feedback.

I though as well about using a handshake there. I'll try it.

Thanks, Richard.

-----Original Message-----
From: Vladimir Ivanov <vladimir.x.ivanov@oracle.com> 
Sent: Donnerstag, 30. Januar 2020 17:55
To: Reingruber, Richard <richard.reingruber@sap.com>; \
                serviceability-dev@openjdk.java.net; \
                hotspot-compiler-dev@openjdk.java.net
Subject: Re: VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant?

Hi Richard,

> I noticed that VM_EnterInterpOnlyMode makes all compiled methods on stack \
> not_entrant. To me this seems unnecessary. I think it would be sufficient to patch \
> the return pc of compiled frames and let them return to their deopt handler. Or \
> what would be the reason to make the compiled methods not_entrant?
> 
> VM_EnterInterpOnlyMode::doit(): all compiled methods on stack that are not native \
> methods get marked.
> 
> Deoptimization::deoptimize_all_marked(): all marked methods are made not_entrant.
> 
> Maybe this is for historical reasons? If I remember correctly, many years ago, \
> deoptimizing a compiled frame used to require making the corresponding nmethod \
> not_entrant. And making a nmethod not_entrant meant overriding its code with a \
> slide of nops that led to the deopt handler. 
> I'd like to change this and just apply Deoptimization::deoptimize() on every \
> compiled frame on stack. I've done this locally and tested the change without \
> issues.

I'm not a JVMTI expert, but considering VM_EnterInterpOnlyMode is 
performed on per-thread basis [1], it looks like per-frame 
deoptimization (instead of per-nmethod) should be enough to do the job.

So, from JIT-compiler perspective, your suggestion to use 
Deoptimization::deoptimize() instead of 
CompiledMethod::mark_for_deoptimization()/Deoptimization::deoptimize_all_marked() 
sounds good.

PS: also, it looks like handshakes become a perfect fit for 
VM_EnterInterpOnlyMode: once you don't need to deoptimize on per-nmethod 
basis, there's no need to trigger global safepoint.

Best regards,
Vladimir Ivanov

[1] 
http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/prims/jvmtiEventController.cpp#l227


     // If running in fullspeed mode, single stepping is implemented
     // as follows: first, the interpreter does not dispatch to
     // compiled code for threads that have single stepping enabled;
     // second, we deoptimize all methods on the thread's stack when
     // interpreted-only mode is enabled the first time for a given
     // thread (nothing to do if no Java frames yet).


[prev in list] [next in list] [prev in thread] [next in thread]