RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu May 19 01:29:37 UTC 2016
Good. I started testing.
Thanks,
Vladimir
On 5/18/16 5:36 PM, Deshpande, Vivek R wrote:
> Hi Vladimir
>
> Sorry I missed that part.
> Here is the webrev with that change:
> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.05/
>
> Regards,
> Vivek
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Wednesday, May 18, 2016 4:29 PM
> To: Deshpande, Vivek R
> Cc: Viswanathan, Sandhya; hotspot compiler
> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics
>
> That is why I suggested new method with '0' in name and no int parameter:
>
> // Use this method when MacroAssembler version of call_VM_leaf_base() should be called.
> void MacroAssembler::call_VM_leaf0(address entry_point) {
> MacroAssembler::call_VM_leaf_base(entry_point, 0); }
>
> Vladimir
>
> On 5/18/16 4:22 PM, Deshpande, Vivek R wrote:
>> HI Vladimir
>>
>> I need to call masm version of call_VM_leaf_base().
>>
>> Using following from templateInterpreter_x86_64/32.cpp
>>
>> 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) { ...
>>
>> So I had put mathfunc() to call the masm version of call_VM_leaf_base().
>>
>> Regards,
>> Vivek
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Wednesday, May 18, 2016 4:18 PM
>> To: Deshpande, Vivek R
>> Cc: Viswanathan, Sandhya; hotspot compiler
>> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to
>> control stub generation and intrinsics
>>
>> You are still using mathfunc().
>>
>> Vladimir
>>
>> On 5/18/16 3:26 PM, Deshpande, Vivek R wrote:
>>> Hi Vladimir
>>>
>>> I have the latest webrev with suggested changes here:
>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/web
>>> r
>>> ev.04/
>>> Could you please take a look at it.
>>>
>>> Regards,
>>> Vivek
>>> -----Original Message-----
>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>> Sent: Wednesday, May 18, 2016 12:41 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
>>>
>>> Okay, convert it to bug saying that -XX:DisableIntrinsic does not
>>> disable intrinsic in Interpreter. Which can lead to results
>>> inconsistencies since different code is used in compiled code and
>>> Interpreter.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/18/16 12:36 PM, Deshpande, Vivek R wrote:
>>>> HI Vladimir
>>>>
>>>> We can convert it to bug.
>>>> With the change, using -XX:DisableIntrinsic=_dexp, will not generate the LIBM stub and all the calls will point to SharedRuntime::dexp correctly with stack adjustment.
>>>> Currently with -XX:DisableIntrinsic=_dexp, stub gets generated and points to LIBM stub in interpreter.
>>>> and just using option UseLibmIntrinsic to disable LIBM usage fails without stack adjustment for 64 bit.
>>>> I can make changes for 32 bit in updated webrev.
>>>>
>>>> Regards,
>>>> Vivek
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>> Sent: Wednesday, May 18, 2016 12:24 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
>>>>
>>>> First, 8154473 is RFE and we are post FC (feature complete). We have to wait until the process of RFEs approval is finalized.
>>>>
>>>> Or we can convert it to bug. Can you say what happens with current code if -XX:DisableIntrinsic=_dexp is used, for example? And what will happen after these changes?
>>>>
>>>> I don't see changes for:
>>>> templateInterpreterGenerator_x86_32.cpp
>>>>
>>>> It would be better to have similar code there even if 32-bit code does not have stack problem.
>>>>
>>>>
>>>> You did not implemented what Chris was asked:
>>>>
>>>> > 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 would suggest an other method
>>>>
>>>> // Use this method when MacroAssembler version of
>>>> call_VM_leaf_base() should be called.
>>>> void MacroAssembler::call_VM_leaf0(address entry_point) {
>>>> MacroAssembler::call_VM_leaf_base(entry_point, 0); }
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 5/18/16 11:27 AM, Deshpande, Vivek R wrote:
>>>>> Hi Vladimir
>>>>>
>>>>> The latest webrev is here:
>>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w
>>>>> e
>>>>> brev.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/
>>>>>> w
>>>>>> ebr
>>>>>> 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/
>>>>>> w
>>>>>> ebr
>>>>>> 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/
>>>>>> w
>>>>>> ebrev.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/
>>>>>> w
>>>>>> ebr
>>>>>> 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/
>>>>>> w
>>>>>> ebr
>>>>>> 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/
>>>>>> w
>>>>>> ebrev.00/
>>>>>>
>>>>>> <http://cr.openjdk.java.net/%7Evdeshpande/CompilerDirectives/81544
>>>>>> 7
>>>>>> 3/w
>>>>>> ebrev.00/>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks and regards,
>>>>>>
>>>>>> Vivek
>>>>>>
>>>>>>
>>>>>>
More information about the hotspot-compiler-dev
mailing list