RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics

Mon May 2 22:43:57 UTC 2016

> On May 2, 2016, at 11:53 AM, Deshpande, Vivek R <vivek.r.deshpande at intel.com> wrote:
> 
> Hi Christian
>  
> I had tried using call_VM_leaf() which you mentioned.
>  
> But this function
>  
> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) {
>   call_VM_leaf_base(entry_point, number_of_arguments);
> }
>  
> ends up calling
>  
> void InterpreterMacroAssembler::call_VM_leaf_base(address entry_point,
>                                                   int number_of_arguments) { ...
> from interp_masm_x86.cpp instead of
>  
> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) { …

Frankly, I didn’t know that there is an overload for call_VM_leaf_base in InterpreterMacroAssembler.  So this means there are two options:

a)  Add a method in MacroAssembler to call MacroAssembler::call_VM_leaf_base (what you did) or

b)  Add InterpreterMacroAssembler::call_VM_leaf and change MacroAssembler::call_VM_leaf to do:

void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) {
  MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments);
}

I will let the runtime team decide.

>  
> So I had put mathfunc() to call the masm version of call_VM_leaf_base().
>  
> Let me know what you think.
>  
> Thanks and regards,
> Vivek
>  
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Monday, May 02, 2016 1:50 PM
> To: Deshpande, Vivek R
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics
>  
>  
> On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R <vivek.r.deshpande at intel.com <mailto:vivek.r.deshpande at intel.com>> wrote:
>  
> Hi Christian
>  
> I have updated the webrev and link for the same is here:
> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/ <http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/>
> I am using mathfunc() to call the masm version of call_VM_leaf_base() and not the InterpreterMacroAssembler version.
>  
> That’s better but, again, there is nothing math-y about this method:
> ! void MacroAssembler::mathfunc(address runtime_entry) {
>     MacroAssembler::call_VM_leaf_base(runtime_entry, 0);
>   }
> Also, there is this method:
>  
> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) {
>   call_VM_leaf_base(entry_point, number_of_arguments);
> }
>  
> which has:
>  
>   void call_VM_leaf(address entry_point,
>                     int number_of_arguments = 0);
>  
> Get rid of mathfunc completely and use call_VM_leaf directly.
>  
>  
> Regards,
> Vivek
>  
>   <>
>  <>From: Christian Thalinger [mailto:christian.thalinger at oracle.com <mailto:christian.thalinger at oracle.com>] 
> Sent: Thursday, April 21, 2016 2:35 PM
> To: Deshpande, Vivek R <vivek.r.deshpande at intel.com <mailto:vivek.r.deshpande at intel.com>>
> Cc: Nils Eliasson <nils.eliasson at oracle.com <mailto:nils.eliasson at oracle.com>>; hotspot-compiler-dev at openjdk.java.net <mailto:hotspot-compiler-dev at openjdk.java.net>; Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>
> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics
>  
>  
> On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R <vivek.r.deshpande at intel.com <mailto:vivek.r.deshpande at intel.com>> wrote:
>  
> Hi
>  
> The correct URL for the updated webrev is this.
> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ <http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/>
>  
> +void MacroAssembler::mathfunc(address runtime_entry) {
> I don’t like the name of this method.  Mainly because it’s only aligning the stack (shouldn’t that happen somewhere else?) and doing this 0x20 stack frame thing which I still don’t understand.
>  
> Right, this is the one I was thinking about:
>  
> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) {
> 
> 
> 
> Sorry for the spam.
>  
> Regards,
> Vivek
>  
> From: Deshpande, Vivek R 
> Sent: Wednesday, April 20, 2016 5:10 PM
> To: Deshpande, Vivek R; 'Nils Eliasson'; 'hotspot-compiler-dev at openjdk.java.net <mailto:hotspot-compiler-dev at openjdk.java.net>'
> Cc: 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian Thalinger'; Viswanathan, Sandhya
> Subject: RE: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics
>  
> Sent out the wrong link by mistake.
>  
> updated webrev: 
> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ <http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/>
>  
> Regards
> Vivek
>  
>  
> From: Deshpande, Vivek R 
> Sent: Wednesday, April 20, 2016 5:07 PM
> To: 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net <mailto:hotspot-compiler-dev at openjdk.java.net>
> Cc: Vladimir Kozlov; Volker Simonis; Christian Thalinger; Viswanathan, Sandhya
> Subject: RE: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics
>  
> Hi Nils
>  
> I have updated the webrev with all the suggestions.
> updated webrev: 
> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/ <http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/>
> Thanks for your comments and review.
>  
> @Vladimir,
> I have taken care of all the comments. Would you please review and sponsor the patch.
>  
> Thanks and regards,
> Vivek 
>  
> From: Nils Eliasson [mailto:nils.eliasson at oracle.com <mailto:nils.eliasson at oracle.com>] 
> Sent: Wednesday, April 20, 2016 12:27 PM
> To: Deshpande, Vivek R; hotspot-compiler-dev at openjdk.java.net <mailto:hotspot-compiler-dev at openjdk.java.net>
> Cc: Vladimir Kozlov; Volker Simonis; Christian Thalinger; Viswanathan, Sandhya
> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics
>  
> In vmSymbols.cpp together with the other flag checks.
> 
> Regards,
> Nils
> 
> On 2016-04-20 02:44, Deshpande, Vivek R wrote:
> HI Nils
>  
> Yes you are right the function accesses the command line flag DisableIntrinsic and changes are static.
> Could you point me the right location for the function ?
> Also I have updated the webrev with rest of the comments here:
> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/ <http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/>
>  
> Regards,
> Vivek
>  
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net <mailto:hotspot-compiler-dev-bounces at openjdk.java.net>]On Behalf Of Nils Eliasson
> Sent: Tuesday, April 19, 2016 5:55 AM
> To: hotspot-compiler-dev at openjdk.java.net <mailto:hotspot-compiler-dev at openjdk.java.net>
> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics
>  
> Hi Vivek,
> 
> The changes in is_intrinsic_disabled in compilerDirectives.* are static and only access the command line flag DisableIntrinsics. As long as stubs are only generated during startup and don't have a method context - that is ok - but it doesn't belong in the compilerDirectives-files if it doens't use directives.  
> 
> Regards,
> Nils
> 
> On 2016-04-18 19:38, Deshpande, Vivek R wrote:
> Hi all
>  
> I would like to contribute a patch which helps to control the intrinsics in interpreter, c1 and c2 by disabling the stub generation.
> This uses -XX:DisableIntrinsic option to achieve the same.
> Could you please review and sponsor this patch.
>  
> Bug-id: 
> https://bugs.openjdk.java.net/browse/JDK-8154473 <https://bugs.openjdk.java.net/browse/JDK-8154473>
> webrev:
> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ <http://cr.openjdk.java.net/%7Evdeshpande/CompilerDirectives/8154473/webrev.00/>
>  
> Thanks and regards,
> Vivek