RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics
Deshpande, Vivek R
vivek.r.deshpande at intel.com
Wed May 18 18:27:37 UTC 2016
Hi Vladimir
The latest webrev is here:
http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/
The bug ID for the same is:
https://bugs.openjdk.java.net/browse/JDK-8154473
Thanks for looking into it.
Regards,
Vivek
-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
Sent: Wednesday, May 18, 2016 11:04 AM
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
Hi Vivek,
Can you send link to latest webrev? The thread is long and it is not clear which webrev is final.
Thanks,
Vladimir
On 5/18/16 10:36 AM, Deshpande, Vivek R wrote:
>
>
> 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:
>
>
>
> voidMacroAssembler::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/webr
> ev.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/webr
> ev.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/web
> rev.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/webr
> ev.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/webr
> ev.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/w
> ebrev.00/>
>
>
>
> Thanks and regards,
>
> Vivek
>
>
>
More information about the hotspot-compiler-dev
mailing list