jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: Nashorm Javascript engine
Date Wed, 16 Sep 2015 20:04:21 GMT
Am 15.09.2015 um 21:40 schrieb Philippe Mouawad:
> Hello,
> @Other team members, what's your opinion on this ?
We shouldn't give up backward compatibility lightly.

In case of the javascript interpreter, that comes with the jvm, I think 
it is ok, to use the default interpreter of the jvm. The differences, 
that were shown in the migration guide were not the ones, I would expect 
in small scripts as they are probably found in the ifcontroller.

But I would expect to have the same javascript environment in all places.

Since the current stable version uses rhino, it could be a good strategy 
to enable the use of nashorn, but leave rhino the default. Make a big 
note, that we will switch to prefer nashorn in some near future, so that 
people have a chance to test it and report problems. When no problems 
are reported, we can switch to nashorn.

Regards,
  Felix

>
> Thanks
> Regards
>
> On Tue, Sep 15, 2015 at 7:38 AM, Philippe Mouawad <
> philippe.mouawad@gmail.com> wrote:
>
>>
>> On Tuesday, September 15, 2015, sebb <sebbaz@gmail.com> wrote:
>>
>>> On 14 September 2015 at 21:28, Philippe Mouawad
>>> <philippe.mouawad@gmail.com> wrote:
>>>> On Mon, Sep 14, 2015 at 4:51 PM, sebb <sebbaz@gmail.com> wrote:
>>>>
>>>>> On 14 September 2015 at 12:58, Vladimir Sitnikov
>>>>> <sitnikov.vladimir@gmail.com> wrote:
>>>>>>> Apart from compatibility issues [1]
>>>>>> I do know there are compatibility issues, however is is rather smooth
>>>>>> if you are creating a new script.
>>>>>> I do know what "backward compatibility" is.
>>>>> It means that existing Javascript scripts will run without needing to
>>>>> be amended.
>>>>>
>>>> What is the probability to break a Javascript code in IF Controller ?
>>> Depends on what the incompatible changes are.
>>>
>>>   so what do you propose ?
>>> Complexity of such script would be very low.
>>>
>>> Probably, but that does not mean the script cannot break.
>>>
>>>
>> so you want the statu quo ?
>>
>>
>>>> I doubt  Rhino and Nashorn would differ in the way of interpreting those
>>>> scripts.
>>> That may be true but is just guesswork without more evidence.
>>>
>>>
>> I don't know what to say. I tend to think we have very low risk to have
>> issues here, we mention the incompatible change so user check their script
>> once they upgrade.
>> And if any regression they have the option to debug or revert to old
>> behaviour.
>> Backward compatibility is rather well managed here. It should not be a
>> stopper for any change in JMeter.
>>
>> New scripts are built on nashorn and that 's it.
>>
>> You think something else, why would I have to prove that it will not break
>> , and not you prove that it will?
>>
>>
>>
>> In my opinion unless you have a big explicit case where it breaks I see no
>> reason not to move forward.
>>
>>
>>
>>
>>>> Based on this:
>>>> https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide
>>>>
>>>> Maybe the biggest risk is in replace, but I am not sure..
>>> This needs to be established.
>>>
>>>
>> what do you propose ?
>>
>>
>>>>>>> I got the speed info from the diagram in the link from the Bugzilla:
>>>>>>>
>>> http://ariya.ofilabs.com/2014/03/nashorn-the-new-rhino-on-the-block.html
>>>>>> This benchmark makes very little sense. Proper benchmarking should
>>>>>> involve jmh [1]
>>>>> I quoted the URL because it was used in justifying Nashorn over Rhino.
>>>>> However the page clearly shows that Nashorn is not always faster.
>>>>>
>>>>> Given that
>>>>> - Nashorn is not always faster
>>>>>
>>>> Can you point to a particular case where it is not and that users would
>>>> meet in the JMeter scope ?
>>>>
>>>>
>>>>> - it may have compatibility issues
>>>>>
>>>> as long as we propose a way to select rhino and given that chances of
>>>> having regressions is very low, is it really a big risk.
>>> We don't yet what the chance of regressions is.
>>
>> the migration guide does not show big regression risks.
>>
>>
>>>> In the benchmark I made using 2 IfControllers, there is a 50% increase
>>> in
>>>> throughput.
>>>>
>>>>
>>>> it is clearly NOT OK to change JMeter without prior discussion of the
>>>>> issues.
>>>>>
>>>>
>>>> I suppose we are discussing it here.
>>> Yes, we are now.
>>>
>>>> One side note.
>>>> Whenever a user migrates to Java8, the Javascript engine used by JSR223
>>>> Test Elements is switched without any other notice from RHINO to
>>> NASHORN.
>>>
>>> That's not quite true.
>>>
>>> If the user originally selected "rhino" then the test plan will fail
>>> because "rhino" has been dropped as a valid engine.
>>>
>>>   As a standard user, would you choose javascript (very well known) or
>> rhino(more specialized ) ?
>> I think most users choose javascript.
>> Seeing lot of questions on JMeter at stackoverflow , they frequently
>> mention js or javascript.
>>
>>
>> However if they selected "javascript" or "js" then they will get the
>>> default JS engine.
>> And in this case there are chances to break.
>>
>>
>>>> In my opinion there are much bigger chances to break things  here as the
>>>> script has chances to be bigger.
>>> It is likely that such scripts will be bigger, however the user will
>>> get a clear warning if they selected Rhino specifically.
>>>
>>>>> We may well decide that the advantages outweigh the disadvantages, but
>>>>> that discussion needs to occur and for agreement to be reached.
>>>>>
>>>>>>> Nashorn is NOT always faster than Rhino
>>>>>> Well, what if it is faster in 99.9% cases?
>>>>>> I mean that we never find a library that will be always faster than
>>>>>> Rhino. There always be at lease a case or two where Rhino wins.
>>>>>> Does that mean we have to live with Rhino forever?
>>>>> No, but the decision needs to take these facts into consideration.
>>>>>
>>>>>> [1] http://openjdk.java.net/projects/code-tools/jmh/
>>>>>>
>>>>>> Vladimir
>>>>
>>>>
>>>> --
>>>> Cordialement.
>>>> Philippe Mouawad.
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>>
>


Mime
View raw message