Two questions on Nashorn features

[Marcus Lagergren]

Nashorn should always split large scripts into smaller ones. The resulting split code might run slower than an unsplit one, however, as it has to be augmented with things like scope information, where previously was no need. Our performance update release, which is initially targeted for 8u20 (but I can’t promise anything) will bridge some/most of this performance gap.

/M

On 25 Mar 2014, at 06:30, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Nashorn spilts script into fragments and generates multiple classes (as needed). But, yes - you may still face issues with very large scripts - but we do test nashorn with large scripts.
> 
> No instruction count feature in nashorn - as nashorn generates bytecode always. Generated bytecode is not instrumented in anyway to report "instruction count" or any such.
> 
> -Sundar
> 
> On Tuesday 25 March 2014 10:53 AM, Greg Brail wrote:
>> I'm still looking at porting a lot of Rhino code to Nashorn since it seems
>> to be measurably faster and it is going to keep up with the Java specs
>> better than Rhino.
>> 
>> There are two Rhino features that seem to be to be hard to replicate in the
>> world of Nashorn and I wonder if the team has any idea if we could get to
>> them.
>> 
>> First, Rhino blows up when trying to compile scripts that produce more than
>> 64K of bytecode, but you can fall back to interpreted mode in that case so
>> that they still run, although much more slowly. I realize that Nashorn has
>> no interpreter. Is it still subject to the 64K class file limit? Is there
>> some other work around for large scripts (which are surprisingly common in
>> the Node.js world).
>> 
>> Second, Rhino has the following handy feature:
>> 
>> /**
>>      * Turn on or off generation of code with callbacks to
>>      * track the count of executed instructions.
>>      * Currently only affects JVM byte code generation: this slows down the
>>      * generated code, but code generated without the callbacks will not
>>      * be counted toward instruction thresholds. Rhino's interpretive
>>      * mode does instruction counting without inserting callbacks, so
>>      * there is no requirement to compile code differently.
>>      * @param generateObserverCount if true, generated code will contain
>>      * calls to accumulate an estimate of the instructions executed.
>>      */
>>     public void setGenerateObserverCount(boolean generateObserverCount) {
>>         this.generateObserverCount = generateObserverCount;
>>     }
>> 
>> with this feature turned on, any script will periodically call a callback,
>> and we can implement that callback to check a timer and throw an exception.
>> This can cause a long-running task to abort. This is really handy if you
>> want to run untrusted Javascript in a container, because it protects your
>> container from scripts that contain infinite loops.
>> 
>> Is there any chance that the Nashorn team might consider such a feature in
>> an upcoming release? Or can you think of another way to do this in the
>> world of Java 8?
>> 
>> 
>