Two questions on Nashorn features

[Greg Brail]

Glad to hear that it can support large scripts -- cool.

As for the instruction count feature, it does work in Rhino in compiled
mode -- Rhino simply inserts function calls to represent the "instruction
count" periodically. As far as I am concerned, the actual instruction count
isn't important, but the ability to be called back periodically when a
CPU-intensive script is running is very helpful when you need to safely run
code from a less-trusted source inside a container.



On Mon, Mar 24, 2014 at 10:30 PM, 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?
>>
>>
>>
>


-- 
*greg brail* | *apigee <https://apigee.com/>* | twitter
@gbrail<http://twitter.com/gbrail>