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

Deshpande, Vivek R vivek.r.deshpande at intel.com
Wed May 18 17:36:36 UTC 2016


Hi Vladimir

Could you please review and sponsor this patch with the current solution.
This patch calls correct fallback version for LIBM methods when LIBM is disabled.

Regards,
Vivek



From: Deshpande, Vivek R
Sent: Tuesday, May 10, 2016 11:00 AM
To: 'Christian Thalinger'
Cc: Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime
Subject: RE: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics

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<mailto: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



More information about the hotspot-runtime-dev mailing list