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

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed May 18 18:03:58 UTC 2016


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