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

Tue May 10 17:59:56 UTC 2016

HI Christian

We have not heard from runtime team regarding this change.
Shall we go ahead with the current solution ?
I can send out the latest webrev.
Let me know your thoughts.

Regards,
Vivek

From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Monday, May 02, 2016 3:44 PM
To: Deshpande, Vivek R
Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime
Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics

On May 2, 2016, at 11:53 AM, Deshpande, Vivek R <vivek.r.deshpande at intel.com<mailto: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<mailto: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/
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]
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/

+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/
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]
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/

Regards,
Vivek

From: hotspot-compiler-dev [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
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