Two questions on Nashorn features

[Wei Xiao]

I have the same concern as Greg, our case is that the scripts
developer can input scripts from web client and server runs the code,
to avoid time consuming scripts and infinite loop, the counter is
quite necessary to stop the script.

Looking forward to your suggestion.

-William

在 2014-3-26，3:23，Greg Brail <greg at apigee.com> 写道：

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