From timvolpe at gmail.com Sat Mar 1 01:27:44 2014 From: timvolpe at gmail.com (Tim Fox) Date: Sat, 01 Mar 2014 09:27:44 +0000 Subject: Implementing JavaScript index operator in a Java object Message-ID: <5311A810.8090602@gmail.com> Hello Nashorn folks, I have a JavaScript object, and I'd like to 'override' what the index operator [] does on it. I.e. when I do var x = myobj[3]; I actually want it to call some other function on the object, e.g. myobj.get(3); I'm pretty sure this isn't possible in pure JS, so I was thinking of wrapping a Java Object as a JavaScript object, e.g. if I have public class MyJavaClass { public Object get(int index) { ... return something; } } I would like to have a JS wrapper for it, such that when I call: var x = myJavaWrapper[3]; It actually calls: myJavaObject.get(3); Is this possible in Nashorn? From rieberandreas at gmail.com Sat Mar 1 03:00:03 2014 From: rieberandreas at gmail.com (Andreas Rieber) Date: Sat, 01 Mar 2014 12:00:03 +0100 Subject: Implementing JavaScript index operator in a Java object In-Reply-To: <5311A810.8090602@gmail.com> References: <5311A810.8090602@gmail.com> Message-ID: <5311BDB3.20500@gmail.com> Hi Tim, this is possible with JSAdapter described in [1]. Short sketch could look like this: --- var myobj = (function () { return new JSAdapter() { __get__: function(name) { print("getter called for '" + name + "'"); return name; }, __put__: function(name, value) { print("setter called for '" + name + "' with " + value); } } })(); myobj.x; myobj.x = 12; myobj[3]; --- output: getter called for 'x' setter called for 'x' with 12 getter called for '3' --- happy scripting Andreas [1] https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions On 01.03.2014 10:27, Tim Fox wrote: > Hello Nashorn folks, > > I have a JavaScript object, and I'd like to 'override' what the index > operator [] does on it. > > I.e. when I do > > var x = myobj[3]; > > I actually want it to call some other function on the object, e.g. > > myobj.get(3); > > I'm pretty sure this isn't possible in pure JS, so I was thinking of > wrapping a Java Object as a JavaScript object, e.g. if I have > > public class MyJavaClass { > public Object get(int index) { > ... > return something; > } > } > > I would like to have a JS wrapper for it, such that when I call: > > var x = myJavaWrapper[3]; > > It actually calls: > > myJavaObject.get(3); > > Is this possible in Nashorn? From marcus.lagergren at oracle.com Sun Mar 2 01:39:23 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Sun, 2 Mar 2014 10:39:23 +0100 Subject: Review request for JDK-8035948 - Redesign property listeners for shared classes In-Reply-To: <530F7446.6060508@oracle.com> References: <530F7446.6060508@oracle.com> Message-ID: <40A6A610-C644-4575-A860-F8FACBE64AA7@oracle.com> Have you done any benchmarking whether the synchronization in PropertyListeners gives us overhead? Any other numbers we should know about? On 27 Feb 2014, at 18:22, Hannes Wallnoefer wrote: > Please review JDK-8035948 - Redesign property listeners for shared classes: > > http://cr.openjdk.java.net/~hannesw/8035948/ > > This prepares property maps and property listeners to work better with classes that are reused between JS environments. The central ideas are: > > - Reuse property maps between globals in order to minimize polymorphism. > - Use SoftReferences for property map history to avoid memory leaks > - Redesign property listeners to be attatched to property maps only since ScriptObjects are specific to one JS environment. > - Reduce number of property listeners by only creating them when needed (when a callsite accesses an inherited property). > - Reduce number of prototype history lookups in property maps by using a unique combination of prototype/property maps from the start. > > Actual class sharing functionality is coming in a later webrev. Let me know if you have any questions about this. > > Hannes From sundararajan.athijegannathan at oracle.com Sun Mar 2 20:37:48 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 03 Mar 2014 10:07:48 +0530 Subject: Implementing JavaScript index operator in a Java object In-Reply-To: <5311BDB3.20500@gmail.com> References: <5311A810.8090602@gmail.com> <5311BDB3.20500@gmail.com> Message-ID: <5314071C.8050909@oracle.com> Thanks Andreas. Hi Tim, In addition to JSAdapter, there is also jdk.nashorn.api.scripting.JSObject. Any Java class can implement this interface to trap get/set indexed/named properties, call/new. See also https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes And this interface can also be implemented in script - as usual. See $nashorn_repo/test/script/basic/JDK-8024847.js as well. -Sundar On Saturday 01 March 2014 04:30 PM, Andreas Rieber wrote: > Hi Tim, > > this is possible with JSAdapter described in [1]. > > Short sketch could look like this: > > --- > var myobj = (function () { > > return new JSAdapter() { > __get__: function(name) { > print("getter called for '" + name + "'"); return name; > }, > > __put__: function(name, value) { > print("setter called for '" + name + "' with " + value); > } > } > })(); > > myobj.x; > myobj.x = 12; > myobj[3]; > --- > output: > > getter called for 'x' > setter called for 'x' with 12 > getter called for '3' > --- > > happy scripting > Andreas > > [1] https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > > > On 01.03.2014 10:27, Tim Fox wrote: >> Hello Nashorn folks, >> >> I have a JavaScript object, and I'd like to 'override' what the index >> operator [] does on it. >> >> I.e. when I do >> >> var x = myobj[3]; >> >> I actually want it to call some other function on the object, e.g. >> >> myobj.get(3); >> >> I'm pretty sure this isn't possible in pure JS, so I was thinking of >> wrapping a Java Object as a JavaScript object, e.g. if I have >> >> public class MyJavaClass { >> public Object get(int index) { >> ... >> return something; >> } >> } >> >> I would like to have a JS wrapper for it, such that when I call: >> >> var x = myJavaWrapper[3]; >> >> It actually calls: >> >> myJavaObject.get(3); >> >> Is this possible in Nashorn? > From hannes.wallnoefer at oracle.com Mon Mar 3 01:36:48 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 03 Mar 2014 10:36:48 +0100 Subject: Review request for JDK-8035948 - Redesign property listeners for shared classes In-Reply-To: <40A6A610-C644-4575-A860-F8FACBE64AA7@oracle.com> References: <530F7446.6060508@oracle.com> <40A6A610-C644-4575-A860-F8FACBE64AA7@oracle.com> Message-ID: <53144D30.3060407@oracle.com> I didn't notice any overhead from synchronization. I did notice a small reduction in performance from using soft references instead of hard references in PropertyMap history in some benchmarks (mostly deltablue I think). However, other solutions but they either had worse effects on performance or could possibly cause memory leaks. Still I think the net effect on performance is a positive one (even if only slightly) caused by reduced listener creation and history lookup overhead. Hannes Am 2014-03-02 10:39, schrieb Marcus Lagergren: > Have you done any benchmarking whether the synchronization in PropertyListeners gives us overhead? Any other numbers we should know about? > > On 27 Feb 2014, at 18:22, Hannes Wallnoefer wrote: > >> Please review JDK-8035948 - Redesign property listeners for shared classes: >> >> http://cr.openjdk.java.net/~hannesw/8035948/ >> >> This prepares property maps and property listeners to work better with classes that are reused between JS environments. The central ideas are: >> >> - Reuse property maps between globals in order to minimize polymorphism. >> - Use SoftReferences for property map history to avoid memory leaks >> - Redesign property listeners to be attatched to property maps only since ScriptObjects are specific to one JS environment. >> - Reduce number of property listeners by only creating them when needed (when a callsite accesses an inherited property). >> - Reduce number of prototype history lookups in property maps by using a unique combination of prototype/property maps from the start. >> >> Actual class sharing functionality is coming in a later webrev. Let me know if you have any questions about this. >> >> Hannes From marcus.lagergren at oracle.com Mon Mar 3 02:29:09 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Mon, 03 Mar 2014 10:29:09 +0000 Subject: hg: nashorn/jdk9/nashorn: 8035836: Array performance improvements Message-ID: <20140303102920.5382162455@hg.openjdk.java.net> Changeset: e008b751c93f Author: lagergren Date: 2014-03-03 11:24 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/e008b751c93f 8035836: Array performance improvements Summary: Implement typed arrays with native byte buffers and do fast linking for all continuous arrays Reviewed-by: attila, jlaskey, sundar, hannesw - bin/runnormal.sh - bin/runnormaldual.sh - bin/runopt.sh - bin/runoptdual.sh ! bin/runoptdualcatch.sh - bin/verbose_octane.bat - bin/verbose_octane.sh ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! make/build-benchmark.xml ! src/jdk/internal/dynalink/ChainedCallSite.java ! src/jdk/internal/dynalink/DynamicLinker.java ! src/jdk/internal/dynalink/linker/GuardedInvocation.java ! src/jdk/internal/dynalink/linker/GuardedTypeConversion.java ! src/jdk/internal/dynalink/linker/LinkRequest.java ! src/jdk/internal/dynalink/support/LinkRequestImpl.java ! src/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationEnvironment.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/Label.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/Namespace.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/lookup/Lookup.java ! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java ! src/jdk/nashorn/internal/lookup/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java - src/jdk/nashorn/internal/runtime/arrays/ContinuousArray.java + src/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java + src/jdk/nashorn/internal/runtime/arrays/TypedArrayData.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/examples/string-micro.js ! test/script/basic/JDK-8020357.js ! test/script/basic/NASHORN-377.js ! test/script/basic/typedarrays.js From marcus.lagergren at oracle.com Mon Mar 3 05:01:13 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 3 Mar 2014 14:01:13 +0100 Subject: Review request for JDK-8035948 - Redesign property listeners for shared classes In-Reply-To: <53144D30.3060407@oracle.com> References: <530F7446.6060508@oracle.com> <40A6A610-C644-4575-A860-F8FACBE64AA7@oracle.com> <53144D30.3060407@oracle.com> Message-ID: <64493030-23FB-4D0A-B504-8A43F75D43E2@oracle.com> Yes looks good otherwise and fairly simple to merge with optimistic types. /M On 03 Mar 2014, at 10:36, Hannes Wallnoefer wrote: > I didn't notice any overhead from synchronization. > > I did notice a small reduction in performance from using soft references instead of hard references in PropertyMap history in some benchmarks (mostly deltablue I think). However, other solutions but they either had worse effects on performance or could possibly cause memory leaks. > > Still I think the net effect on performance is a positive one (even if only slightly) caused by reduced listener creation and history lookup overhead. > > Hannes > > > Am 2014-03-02 10:39, schrieb Marcus Lagergren: >> Have you done any benchmarking whether the synchronization in PropertyListeners gives us overhead? Any other numbers we should know about? >> >> On 27 Feb 2014, at 18:22, Hannes Wallnoefer wrote: >> >>> Please review JDK-8035948 - Redesign property listeners for shared classes: >>> >>> http://cr.openjdk.java.net/~hannesw/8035948/ >>> >>> This prepares property maps and property listeners to work better with classes that are reused between JS environments. The central ideas are: >>> >>> - Reuse property maps between globals in order to minimize polymorphism. >>> - Use SoftReferences for property map history to avoid memory leaks >>> - Redesign property listeners to be attatched to property maps only since ScriptObjects are specific to one JS environment. >>> - Reduce number of property listeners by only creating them when needed (when a callsite accesses an inherited property). >>> - Reduce number of prototype history lookups in property maps by using a unique combination of prototype/property maps from the start. >>> >>> Actual class sharing functionality is coming in a later webrev. Let me know if you have any questions about this. >>> >>> Hannes > From marcus.lagergren at oracle.com Wed Mar 5 00:56:57 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Wed, 05 Mar 2014 08:56:57 +0000 Subject: hg: nashorn/jdk9/nashorn: 8036127: Prototype filter needs to be applied to getter guard as well, not just getter Message-ID: <20140305085705.D6788624F0@hg.openjdk.java.net> Changeset: c4c229109575 Author: lagergren Date: 2014-03-05 09:51 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/c4c229109575 8036127: Prototype filter needs to be applied to getter guard as well, not just getter Summary: This manifests itself as a bug in optimistic types, as inner functions may access properties of the wrong type, but it is also a bug in tip. Without optimistic types, we have been unable to find a reproducer due to more similar PropertyMaps Reviewed-by: attila, jlaskey, sundar + bin/fastCatchCombinator.jar ! bin/runoptdualcatch.sh ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java From tal.liron at threecrickets.com Wed Mar 5 22:28:28 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Thu, 06 Mar 2014 14:28:28 +0800 Subject: Fwd: GC overhead limit exceeded In-Reply-To: <530B8B8F.80909@threecrickets.com> References: <52C7B0FC.4040407@threecrickets.com> <52C811F1.4090202@threecrickets.com> <52C8171D.1000402@threecrickets.com> <52DA2462.1040800@threecrickets.com> <530B8B8F.80909@threecrickets.com> Message-ID: <5318158C.2070805@threecrickets.com> Well, I've reached the limits of my personal knowledge to work on this problem. I'm happy to assist in any way I can, including providing access to servers. As it stands, however, it seems that this problem will follow through into the official release of OpenJDK 8, which means that I won't be able to recommend Nashorn for production deployments of Prudence. Perhaps there will be a fix later on? (By the way, there is no bug with Log4j 2.0 -- the high number of instances is by design, an effect of using the innovative Disruptor library for inter-thread communication.) On 02/25/2014 02:12 AM, Tal Liron wrote: > I've been away for a month. Has anyone with knowhow followed up on this? > > The issue is still present. > > On 01/18/2014 02:51 PM, Tal Liron wrote: >> I have a new dump that will hopefully be more useful: >> >> https://dl.dropboxusercontent.com/u/122806/jvm8_gc2.zip >> >> From what I can tell, indeed lambda forms are way out of control >> here. Generally, too, there is a huge amount of Nashorn-related >> instances, which may be related. >> >> (Note that Log4j 2.0 also seems to be having a serious memory leak! I >> have opened a bug about it over there.) From hannes.wallnoefer at oracle.com Thu Mar 6 05:17:01 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 06 Mar 2014 14:17:01 +0100 Subject: Fwd: GC overhead limit exceeded In-Reply-To: <5318158C.2070805@threecrickets.com> References: <52C7B0FC.4040407@threecrickets.com> <52C811F1.4090202@threecrickets.com> <52C8171D.1000402@threecrickets.com> <52DA2462.1040800@threecrickets.com> <530B8B8F.80909@threecrickets.com> <5318158C.2070805@threecrickets.com> Message-ID: <5318754D.3040803@oracle.com> Hi Tal, I'm sorry this problem still persists. Back when I tried your app I threw a lot of apache bench requests at it but didn't see a leak. Looking at your dump again I notice that while there are a lot of LambdaForm related instances they don't occupy a large part of the heap. The biggest part of the heap (over 40 %) is used for character arrays, mostly from Strings. A lot of them are GC-rooted in TimerThread or ThreadLocal instances. I don't understand the application well enough to know whether that is the root of the problem. Could it be that you're retaining some reference in some recurring/scheduler tasks you're running? Hannes Am 2014-03-06 07:28, schrieb Tal Liron: > Well, I've reached the limits of my personal knowledge to work on this > problem. I'm happy to assist in any way I can, including providing > access to servers. > > As it stands, however, it seems that this problem will follow through > into the official release of OpenJDK 8, which means that I won't be > able to recommend Nashorn for production deployments of Prudence. > Perhaps there will be a fix later on? > > (By the way, there is no bug with Log4j 2.0 -- the high number of > instances is by design, an effect of using the innovative Disruptor > library for inter-thread communication.) > > On 02/25/2014 02:12 AM, Tal Liron wrote: >> I've been away for a month. Has anyone with knowhow followed up on this? >> >> The issue is still present. >> >> On 01/18/2014 02:51 PM, Tal Liron wrote: >>> I have a new dump that will hopefully be more useful: >>> >>> https://dl.dropboxusercontent.com/u/122806/jvm8_gc2.zip >>> >>> From what I can tell, indeed lambda forms are way out of control >>> here. Generally, too, there is a huge amount of Nashorn-related >>> instances, which may be related. >>> >>> (Note that Log4j 2.0 also seems to be having a serious memory leak! >>> I have opened a bug about it over there.) > From tal.liron at threecrickets.com Thu Mar 6 05:23:19 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Thu, 06 Mar 2014 21:23:19 +0800 Subject: Fwd: GC overhead limit exceeded In-Reply-To: <5318754D.3040803@oracle.com> References: <52C7B0FC.4040407@threecrickets.com> <52C811F1.4090202@threecrickets.com> <52C8171D.1000402@threecrickets.com> <52DA2462.1040800@threecrickets.com> <530B8B8F.80909@threecrickets.com> <5318158C.2070805@threecrickets.com> <5318754D.3040803@oracle.com> Message-ID: <531876C7.8050306@threecrickets.com> Have you looked at the dump I linked to before? https://dl.dropboxusercontent.com/u/122806/jvm8_gc2.zip Of course it could be a memory leak in my code, but by far the largest amount of instances are held by lambda forms. It could be that they take very little memory, so it might not be important. However, I understood that this is actually a known issue in JVM 7, too. But I don't know enough about how Nashorn uses it to comment. On 03/06/2014 09:17 PM, Hannes Wallnoefer wrote: > Hi Tal, > > I'm sorry this problem still persists. > > Back when I tried your app I threw a lot of apache bench requests at > it but didn't see a leak. Looking at your dump again I notice that > while there are a lot of LambdaForm related instances they don't > occupy a large part of the heap. > > The biggest part of the heap (over 40 %) is used for character arrays, > mostly from Strings. A lot of them are GC-rooted in TimerThread or > ThreadLocal instances. I don't understand the application well enough > to know whether that is the root of the problem. Could it be that > you're retaining some reference in some recurring/scheduler tasks > you're running? > > Hannes > > Am 2014-03-06 07:28, schrieb Tal Liron: >> Well, I've reached the limits of my personal knowledge to work on >> this problem. I'm happy to assist in any way I can, including >> providing access to servers. >> >> As it stands, however, it seems that this problem will follow through >> into the official release of OpenJDK 8, which means that I won't be >> able to recommend Nashorn for production deployments of Prudence. >> Perhaps there will be a fix later on? >> >> (By the way, there is no bug with Log4j 2.0 -- the high number of >> instances is by design, an effect of using the innovative Disruptor >> library for inter-thread communication.) >> >> On 02/25/2014 02:12 AM, Tal Liron wrote: >>> I've been away for a month. Has anyone with knowhow followed up on >>> this? >>> >>> The issue is still present. >>> >>> On 01/18/2014 02:51 PM, Tal Liron wrote: >>>> I have a new dump that will hopefully be more useful: >>>> >>>> https://dl.dropboxusercontent.com/u/122806/jvm8_gc2.zip >>>> >>>> From what I can tell, indeed lambda forms are way out of control >>>> here. Generally, too, there is a huge amount of Nashorn-related >>>> instances, which may be related. >>>> >>>> (Note that Log4j 2.0 also seems to be having a serious memory leak! >>>> I have opened a bug about it over there.) >> > From hannes.wallnoefer at oracle.com Thu Mar 6 05:50:02 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 06 Mar 2014 14:50:02 +0100 Subject: Fwd: GC overhead limit exceeded In-Reply-To: <531876C7.8050306@threecrickets.com> References: <52C7B0FC.4040407@threecrickets.com> <52C811F1.4090202@threecrickets.com> <52C8171D.1000402@threecrickets.com> <52DA2462.1040800@threecrickets.com> <530B8B8F.80909@threecrickets.com> <5318158C.2070805@threecrickets.com> <5318754D.3040803@oracle.com> <531876C7.8050306@threecrickets.com> Message-ID: <53187D0A.4010703@oracle.com> Am 2014-03-06 14:23, schrieb Tal Liron: > Have you looked at the dump I linked to before? > > https://dl.dropboxusercontent.com/u/122806/jvm8_gc2.zip Yes, this is the dump I looked at. > Of course it could be a memory leak in my code, but by far the largest > amount of instances are held by lambda forms. It could be that they > take very little memory, so it might not be important. However, I > understood that this is actually a known issue in JVM 7, too. But I > don't know enough about how Nashorn uses it to comment. Lambda forms are used by Nashorn internally to link callsites at runtime. However, even if it is lambda forms that are leaked that does not mean the problem must be within Nashorn (I'm not saying the opposite either - just trying to find out what's going on). The ThreadLocal thing could be a Nashorn issue as we keep the current global object in a ThreadLocal. Are you keeping a lot of threads alive after they interact with Nashorn (e.g. run some script)? The other trace I'd follow is the TimerThread -> PrudenceApplication path. There seems to be a lot of stuff (Nashorn related and else) stored in ConcurrentHashMaps stored in the context of PrudenceApplication. As I said I don't understand enough to say whether that's the way it's meant to be; you're probably in a better position to tell. Hannes > On 03/06/2014 09:17 PM, Hannes Wallnoefer wrote: >> Hi Tal, >> >> I'm sorry this problem still persists. >> >> Back when I tried your app I threw a lot of apache bench requests at >> it but didn't see a leak. Looking at your dump again I notice that >> while there are a lot of LambdaForm related instances they don't >> occupy a large part of the heap. >> >> The biggest part of the heap (over 40 %) is used for character >> arrays, mostly from Strings. A lot of them are GC-rooted in >> TimerThread or ThreadLocal instances. I don't understand the >> application well enough to know whether that is the root of the >> problem. Could it be that you're retaining some reference in some >> recurring/scheduler tasks you're running? >> >> Hannes >> >> Am 2014-03-06 07:28, schrieb Tal Liron: >>> Well, I've reached the limits of my personal knowledge to work on >>> this problem. I'm happy to assist in any way I can, including >>> providing access to servers. >>> >>> As it stands, however, it seems that this problem will follow >>> through into the official release of OpenJDK 8, which means that I >>> won't be able to recommend Nashorn for production deployments of >>> Prudence. Perhaps there will be a fix later on? >>> >>> (By the way, there is no bug with Log4j 2.0 -- the high number of >>> instances is by design, an effect of using the innovative Disruptor >>> library for inter-thread communication.) >>> >>> On 02/25/2014 02:12 AM, Tal Liron wrote: >>>> I've been away for a month. Has anyone with knowhow followed up on >>>> this? >>>> >>>> The issue is still present. >>>> >>>> On 01/18/2014 02:51 PM, Tal Liron wrote: >>>>> I have a new dump that will hopefully be more useful: >>>>> >>>>> https://dl.dropboxusercontent.com/u/122806/jvm8_gc2.zip >>>>> >>>>> From what I can tell, indeed lambda forms are way out of control >>>>> here. Generally, too, there is a huge amount of Nashorn-related >>>>> instances, which may be related. >>>>> >>>>> (Note that Log4j 2.0 also seems to be having a serious memory >>>>> leak! I have opened a bug about it over there.) >>> >> > From sergey.lugovoy at oracle.com Fri Mar 7 00:23:30 2014 From: sergey.lugovoy at oracle.com (Serge) Date: Fri, 07 Mar 2014 12:23:30 +0400 Subject: RFR 8028615: jdk.nashorn.x3::some.serious.failure needs more memory to run In-Reply-To: <53108AF1.4030901@oracle.com> References: <530DEE05.8080709@oracle.com> <53108AF1.4030901@oracle.com> Message-ID: <53198202.8060603@oracle.com> Hi, it's my fault, I thought that these arguments are used separately, but it's not true. new webrev : http://cr.openjdk.java.net/~yan/8028615/webrev.01/ On 02/28/2014 05:11 PM, A. Sundararajan wrote: > Looks confusing to have > > run.test.xmx=1G > run.test.xms=2G > > (misleading) that -Xmx < -Xms ?? If one of the values is not used in > octane, perhaps a different property has to be introduced for octane. > Or change xmx and xms both. > > -Sundar > > > > On Wednesday 26 February 2014 07:07 PM, Serge wrote: >> Hi all, >> Please review http://cr.openjdk.java.net/~yan/8028615/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8028615 >> > -- Regards, Serge Lugovoy From sundararajan.athijegannathan at oracle.com Fri Mar 7 03:04:50 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 07 Mar 2014 16:34:50 +0530 Subject: RFR 8028615: jdk.nashorn.x3::some.serious.failure needs more memory to run In-Reply-To: <53198202.8060603@oracle.com> References: <530DEE05.8080709@oracle.com> <53108AF1.4030901@oracle.com> <53198202.8060603@oracle.com> Message-ID: <5319A7D2.6030705@oracle.com> +1 -Sundar On Friday 07 March 2014 01:53 PM, Serge wrote: > Hi, > it's my fault, I thought that these arguments are used separately, but > it's not true. > new webrev : http://cr.openjdk.java.net/~yan/8028615/webrev.01/ > > On 02/28/2014 05:11 PM, A. Sundararajan wrote: >> Looks confusing to have >> >> run.test.xmx=1G >> run.test.xms=2G >> >> (misleading) that -Xmx < -Xms ?? If one of the values is not used in >> octane, perhaps a different property has to be introduced for octane. >> Or change xmx and xms both. >> >> -Sundar >> >> >> >> On Wednesday 26 February 2014 07:07 PM, Serge wrote: >>> Hi all, >>> Please review http://cr.openjdk.java.net/~yan/8028615/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8028615 >>> >> > From matherey.nunez at oracle.com Fri Mar 7 07:54:52 2014 From: matherey.nunez at oracle.com (Matherey Nunez) Date: Fri, 07 Mar 2014 16:54:52 +0100 Subject: RFR 8028615: jdk.nashorn.x3::some.serious.failure needs more memory to run In-Reply-To: <5319A7D2.6030705@oracle.com> References: <530DEE05.8080709@oracle.com> <53108AF1.4030901@oracle.com> <53198202.8060603@oracle.com> <5319A7D2.6030705@oracle.com> Message-ID: <5319EBCC.5060806@oracle.com> +1 /Matherey On 03/07/2014 12:04 PM, A. Sundararajan wrote: > +1 > > -Sundar > > On Friday 07 March 2014 01:53 PM, Serge wrote: >> Hi, >> it's my fault, I thought that these arguments are used separately, >> but it's not true. >> new webrev : http://cr.openjdk.java.net/~yan/8028615/webrev.01/ >> >> On 02/28/2014 05:11 PM, A. Sundararajan wrote: >>> Looks confusing to have >>> >>> run.test.xmx=1G >>> run.test.xms=2G >>> >>> (misleading) that -Xmx < -Xms ?? If one of the values is not used in >>> octane, perhaps a different property has to be introduced for >>> octane. Or change xmx and xms both. >>> >>> -Sundar >>> >>> >>> >>> On Wednesday 26 February 2014 07:07 PM, Serge wrote: >>>> Hi all, >>>> Please review http://cr.openjdk.java.net/~yan/8028615/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8028615 >>>> >>> >> > From youssef.elhouti at gmail.com Fri Mar 7 03:09:16 2014 From: youssef.elhouti at gmail.com (Youssef EL HOUTI) Date: Fri, 7 Mar 2014 12:09:16 +0100 Subject: Nashorn ScriptObject suggestion Message-ID: Hi, I'm working on a project when I use Nashorn with java 8 in many ways, and I thought that of an improvement in the class ScriptObject that doesn't cost much: What? Make ScriptObject implement Map Why? - we could call java function from javascript by passing a javascript Objact as argument. - we could get a js function result (JSON) in java without casting... - ScriptObject already define almost all the methods needed (if not all) thank you for your time and please let me know if it's a bad suggestion why? I would be glad to help coding that. Best Regards. From sundararajan.athijegannathan at oracle.com Fri Mar 7 08:57:02 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 07 Mar 2014 22:27:02 +0530 Subject: Nashorn ScriptObject suggestion In-Reply-To: References: Message-ID: <5319FA5E.40008@oracle.com> Hi, When you use javax.script API to evaluate scripts using nashorn engine, script objects are wrapped as instances of a class named jdk.nashorn.api.scripting.ScriptObjectMirror. This class implements javax.script.Bindings (and so java.util.Map) as well. ScriptObject cannot safely implement java.util.Map. Nashorn engine requires global instance to be set as thread local (implementation detail). When access is made from java code, we've to set/reset thread local. Doing that in ScriptObject will have perf. implications. ScriptObjectMirror takes care of set/reset thread local. -Sundar On Friday 07 March 2014 04:39 PM, Youssef EL HOUTI wrote: > Hi, > I'm working on a project when I use Nashorn with java 8 in many ways, and I > thought that of an improvement in the class ScriptObject that doesn't cost > much: > What? Make ScriptObject implement Map > Why? > > - we could call java function from javascript by passing a javascript > Objact as argument. > - we could get a js function result (JSON) in java without casting... > - ScriptObject already define almost all the methods needed (if not all) > > thank you for your time and please let me know if it's a bad suggestion why? > I would be glad to help coding that. > Best Regards. From walter.higgins at gmail.com Sat Mar 8 21:25:12 2014 From: walter.higgins at gmail.com (Walter Higgins) Date: Sat, 8 Mar 2014 21:25:12 +0000 Subject: Unable to iterate over Java object properties using for (var p in object) construct Message-ID: In Java 7 I can iterate over the properties/methods of a Java object using this notation... for (var p in javaObject) { print(p); } In java 8 this no longer works. for (var p in javaObject) { print(p); } ...doesn't result in the for loop block being executed (there are no properties). How can I iterate over the Java object properties in a consisted way between Java 6, 7 and 8? -- Walter Higgins Mobile: (+353) 086 8511600 Website: http://walterhiggins.net/ From sundararajan.athijegannathan at oracle.com Mon Mar 10 03:12:55 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 10 Mar 2014 08:42:55 +0530 Subject: Unable to iterate over Java object properties using for (var p in object) construct In-Reply-To: References: Message-ID: <531D2DB7.9030707@oracle.com> Iterating properties of java objects - both fields, methods - is a rhino specific feature. This is not supported by nashorn. If you've a java array or Iterable, JS for and for..each will do the expected - namely iterate over the array/collection. Thanks -Sundar On Sunday 09 March 2014 02:55 AM, Walter Higgins wrote: > In Java 7 I can iterate over the properties/methods of a Java object using > this notation... > > for (var p in javaObject) { > print(p); > } > > In java 8 this no longer works. > > for (var p in javaObject) { > print(p); > } > > ...doesn't result in the for loop block being executed (there are no > properties). > > How can I iterate over the Java object properties in a consisted way > between Java 6, 7 and 8? > From walter.higgins at gmail.com Mon Mar 10 12:53:44 2014 From: walter.higgins at gmail.com (Walter Higgins) Date: Mon, 10 Mar 2014 12:53:44 +0000 Subject: Is there a non-strict setting for the eval() function? Message-ID: Hi, In JRE6/7 I can run code like this... scriptEngine.eval(' age = 5 '); ... but in Nashorn the following fails ( ReferenceError) ... eval( ' age = 5' ); Is there a way to make the native eval() function provided by Nashorn not be so strict? -- Walter Higgins Mobile: (+353) 086 8511600 Website: http://walterhiggins.net/ From sundararajan.athijegannathan at oracle.com Mon Mar 10 13:23:51 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 10 Mar 2014 18:53:51 +0530 Subject: Is there a non-strict setting for the eval() function? In-Reply-To: References: Message-ID: <531DBCE7.4040700@oracle.com> Hi, Since you didn't give full sample code, I wrote this: import javax.script.*; public class Main { public static void main(String[] args) throws Exception { ScriptEngineManager m = new ScriptEngineManager(); ScriptEngine engine = m.getEngineByName("nashorn"); engine.eval("age = 5"); System.out.println(engine.get("age")); } } It compiled and ran as expected. -Sundar On Monday 10 March 2014 06:23 PM, Walter Higgins wrote: > Hi, > > In JRE6/7 I can run code like this... > > scriptEngine.eval(' age = 5 '); > > ... but in Nashorn the following fails ( ReferenceError) ... > > eval( ' age = 5' ); > > Is there a way to make the native eval() function provided by Nashorn not > be so strict? > From attila.szegedi at oracle.com Tue Mar 11 10:00:08 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 11 Mar 2014 11:00:08 +0100 Subject: Unable to iterate over Java object properties using for (var p in object) construct In-Reply-To: References: Message-ID: <311EE13B-7AD2-403D-94AA-8324246C2030@oracle.com> Hi Walter, thanks for trying out Nashorn and for your feedback. Nashorn's Java interop is different from Rhino's. The object models of Java and JavaScript are sufficiently different that a lot of functionality isn't straightforward to implement. We have chosen to err on the side of caution, and if we weren't convinced that something is the right way to do, we'd rather not implementing it than implement it in what we felt was the wrong way. We're open to community discussion - few months ago we have changed the way JS arrays are exposed to Java API after a discussion on this list. That said, for?in over Java objects is not straightforward, as it'd require us to decide which of the properties are enumerable, and which are not. E.g. would we want every object to expose a property "class" since it has a getClass() method? While we're at it, for a property getter method (let's stay with getClass), should it expose both a "class" property and a "getClass" property which returns a callable representation of the method? (Right now, this is moot, as you can't call .apply and .call on Java methods, but we might change that in the future). If applied to an Java List or Map, should it only return indices/keys, or object methods and properties too? When we feel that the gap in the object model are too large, we'd rather provide an explicit API that people can use than implement implicit non-specification behavior that's papers over this too large gap, and that's not apparent from reading the source code. Speaking of such explicit APIs, there's a solution. Nashorn exposes a (non-ECMAScript standard) method Object.bindProperties() that allows you to get properties from one object, bind them to that object, and expose them in another object. E.g. if you want to iterate over methods and properties of an ArrayList: var x = {} var y = new java.util.ArrayList(); Object.bindProperties(x, y) for(var i in x) { print(i); } will output: getClass wait notifyAll replaceAll notify remove iterator removeAll stream ... You can also selectively remove properties or otherwise edit the "x" object for further use (something you couldn't do with ArrayList proper - you couldn't remove its "stream" method etc.). Hope this helps. (Unfortunately, I can't think of a code construct that would works equally in both Rhino and Nashorn.) Attila. On Mar 8, 2014, at 10:25 PM, Walter Higgins wrote: > In Java 7 I can iterate over the properties/methods of a Java object using > this notation... > > for (var p in javaObject) { > print(p); > } > > In java 8 this no longer works. > > for (var p in javaObject) { > print(p); > } > > ...doesn't result in the for loop block being executed (there are no > properties). > > How can I iterate over the Java object properties in a consisted way > between Java 6, 7 and 8? > > -- > Walter Higgins > Mobile: (+353) 086 8511600 > Website: http://walterhiggins.net/ From hannes.wallnoefer at oracle.com Tue Mar 11 10:55:41 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 11 Mar 2014 11:55:41 +0100 Subject: Review request for JDK-8021350: Share script classes between threads/globals within context Message-ID: <531EEBAD.9070903@oracle.com> Please review JDK-8021350: Share script classes between threads/globals within context: http://cr.openjdk.java.net/~hannesw/8021350/webrev.01/ This makes script classes reusable by using appropriate guards and/or using dynamic parameter lookups instead of static bindings. Overall performance should roughly be the same. Applications that load the same script repeatedly will significantly benefit from this change, for example ant test262parallel runs more than twice as fast. Thanks, Hannes From marcus.lagergren at oracle.com Tue Mar 11 19:50:39 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 11 Mar 2014 20:50:39 +0100 Subject: Review request for JDK-8021350: Share script classes between threads/globals within context In-Reply-To: <531EEBAD.9070903@oracle.com> References: <531EEBAD.9070903@oracle.com> Message-ID: +1. Comments addressed from my earlier review. Thanks for this. On 11 Mar 2014, at 11:55, Hannes Wallnoefer wrote: > Please review JDK-8021350: Share script classes between threads/globals within context: > > http://cr.openjdk.java.net/~hannesw/8021350/webrev.01/ > > This makes script classes reusable by using appropriate guards and/or using dynamic parameter lookups instead of static bindings. Overall performance should roughly be the same. Applications that load the same script repeatedly will significantly benefit from this change, for example ant test262parallel runs more than twice as fast. > > Thanks, > Hannes From mark.reinhold at oracle.com Tue Mar 11 21:08:12 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 11 Mar 2014 14:08:12 -0700 (PDT) Subject: JEP 194: Nashorn Code Persistence Message-ID: <20140311210812.877921610D@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/194 - Mark From sundararajan.athijegannathan at oracle.com Wed Mar 12 08:29:22 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 12 Mar 2014 13:59:22 +0530 Subject: Review request for JDK-8021350: Share script classes between threads/globals within context In-Reply-To: <531EEBAD.9070903@oracle.com> References: <531EEBAD.9070903@oracle.com> Message-ID: <53201AE2.6030703@oracle.com> +1 Looks good -Sundar On Tuesday 11 March 2014 04:25 PM, Hannes Wallnoefer wrote: > Please review JDK-8021350: Share script classes between > threads/globals within context: > > http://cr.openjdk.java.net/~hannesw/8021350/webrev.01/ > > This makes script classes reusable by using appropriate guards and/or > using dynamic parameter lookups instead of static bindings. Overall > performance should roughly be the same. Applications that load the > same script repeatedly will significantly benefit from this change, > for example ant test262parallel runs more than twice as fast. > > Thanks, > Hannes From tal.liron at threecrickets.com Wed Mar 12 09:27:29 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 12 Mar 2014 17:27:29 +0800 Subject: The class cache Message-ID: <53202881.5030603@threecrickets.com> In Nashorn, the ClassCache is set per Global instance. This is fine if your application has only one global instance. However, my application design involves creating many Global instances. (Actually, I create and destroy them on the fly per user request in an HTTP server scenario.) The problem is that all code has to constantly be recompiled, and the cache is essentially never used. Since recompilation is so very expensive in Nashorn, this results in awful performance. How can I implement a shared ClassCache? I can't extend and modify Global behavior, because it's a final class. I've tried to cache ScriptFunction instances myself, but I get exceptions when I try to run them with a different Global instance than the one that created them. From marcus.lagergren at oracle.com Wed Mar 12 09:35:05 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Wed, 12 Mar 2014 09:35:05 +0000 Subject: hg: nashorn/jdk9/nashorn: 8037177: -Dnashorn.optimistic should be enabled by default, meaning that it has to be explicitly set to false to run with the jdk 8 style conservative types Message-ID: <201403120935.s2C9Z6g5000320@aojmv0008> Changeset: 3c1163f9c095 Author: lagergren Date: 2014-03-12 10:31 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/3c1163f9c095 8037177: -Dnashorn.optimistic should be enabled by default, meaning that it has to be explicitly set to false to run with the jdk 8 style conservative types Summary: This will be the new default setting, so the explicit flag should be removed, and instead reverse checked for explicitly DISABLED optimistic types. In the future, we might remove the flag altogether. Reviewed-by: attila, hannesw ! bin/runoptdualcatch.sh ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/options/Options.java From hannes.wallnoefer at oracle.com Wed Mar 12 09:50:46 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 12 Mar 2014 10:50:46 +0100 Subject: The class cache In-Reply-To: <53202881.5030603@threecrickets.com> References: <53202881.5030603@threecrickets.com> Message-ID: <53202DF6.50602@oracle.com> Hi Tal, I'm right now pushing a change for JDK-8021350 that allows sharing script classes between global scopes. Currently, script classes are bound to the global object in various ways, so the change is not trivial, and it's not possible to share compiled scripts between global scopes with the nashorn.jar in current JDK8 builds. The script sharing feature is planned for the 8u20 release. The class sharing will be per script engine, meaning that if you use multiple scopes with one script engine classes will be reused, when you use multiple script engines scripts will be recompiled for each engine. I'd be interested to know whether this would work for you. If you'd like to test the class sharing feature I can help you getting started. Hannes Am 2014-03-12 10:27, schrieb Tal Liron: > In Nashorn, the ClassCache is set per Global instance. > > This is fine if your application has only one global instance. > However, my application design involves creating many Global > instances. (Actually, I create and destroy them on the fly per user > request in an HTTP server scenario.) The problem is that all code has > to constantly be recompiled, and the cache is essentially never used. > Since recompilation is so very expensive in Nashorn, this results in > awful performance. > > How can I implement a shared ClassCache? I can't extend and modify > Global behavior, because it's a final class. > > I've tried to cache ScriptFunction instances myself, but I get > exceptions when I try to run them with a different Global instance > than the one that created them. From tal.liron at threecrickets.com Wed Mar 12 09:58:36 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 12 Mar 2014 17:58:36 +0800 Subject: The class cache In-Reply-To: <53202DF6.50602@oracle.com> References: <53202881.5030603@threecrickets.com> <53202DF6.50602@oracle.com> Message-ID: <53202FCC.30504@threecrickets.com> I did see that change come through, but I thought it was a JDK9 feature... great to know it is for JDK8! I'll note that I'm not using ScriptEngine, but instead working on the Scripturian implementation. How will ScriptEngine make sure to reuse the cache? Would it be possible to also allow a shared ClassCache instance for all globals? How about a ScriptEnvironment._class_cache_size boolean option to enable this? On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote: > Hi Tal, > > I'm right now pushing a change for JDK-8021350 that allows sharing > script classes between global scopes. Currently, script classes are > bound to the global object in various ways, so the change is not > trivial, and it's not possible to share compiled scripts between > global scopes with the nashorn.jar in current JDK8 builds. The script > sharing feature is planned for the 8u20 release. > > The class sharing will be per script engine, meaning that if you use > multiple scopes with one script engine classes will be reused, when > you use multiple script engines scripts will be recompiled for each > engine. > > I'd be interested to know whether this would work for you. If you'd > like to test the class sharing feature I can help you getting started. > > Hannes > > Am 2014-03-12 10:27, schrieb Tal Liron: >> In Nashorn, the ClassCache is set per Global instance. >> >> This is fine if your application has only one global instance. >> However, my application design involves creating many Global >> instances. (Actually, I create and destroy them on the fly per user >> request in an HTTP server scenario.) The problem is that all code has >> to constantly be recompiled, and the cache is essentially never used. >> Since recompilation is so very expensive in Nashorn, this results in >> awful performance. >> >> How can I implement a shared ClassCache? I can't extend and modify >> Global behavior, because it's a final class. >> >> I've tried to cache ScriptFunction instances myself, but I get >> exceptions when I try to run them with a different Global instance >> than the one that created them. > From sundararajan.athijegannathan at oracle.com Wed Mar 12 10:30:14 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 12 Mar 2014 16:00:14 +0530 Subject: The class cache In-Reply-To: <53202FCC.30504@threecrickets.com> References: <53202881.5030603@threecrickets.com> <53202DF6.50602@oracle.com> <53202FCC.30504@threecrickets.com> Message-ID: <53203736.7010904@oracle.com> Actually, the plan is to get to 8u20 - which is an update release after jdk8 GA. Script engine is associated with a single nashorn Context instance. One nashorn Context instance may be associated with multiple nashorn Global instances. The class sharing as of today is per global instance - after Hannes' change, it'll be per Context instance (and so sharing across all globals associated with a nashorn Context instance). ScriptEnvironment._class_cache_size is set from --class-cache-size option. Currently it is interpreted as per-global cache size. After Hannes' change, it is per-Context class cache size. -Sundar On Wednesday 12 March 2014 03:28 PM, Tal Liron wrote: > I did see that change come through, but I thought it was a JDK9 > feature... great to know it is for JDK8! > > I'll note that I'm not using ScriptEngine, but instead working on the > Scripturian implementation. How will ScriptEngine make sure to reuse > the cache? > > Would it be possible to also allow a shared ClassCache instance for > all globals? How about a ScriptEnvironment._class_cache_size boolean > option to enable this? > > On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote: >> Hi Tal, >> >> I'm right now pushing a change for JDK-8021350 that allows sharing >> script classes between global scopes. Currently, script classes are >> bound to the global object in various ways, so the change is not >> trivial, and it's not possible to share compiled scripts between >> global scopes with the nashorn.jar in current JDK8 builds. The script >> sharing feature is planned for the 8u20 release. >> >> The class sharing will be per script engine, meaning that if you use >> multiple scopes with one script engine classes will be reused, when >> you use multiple script engines scripts will be recompiled for each >> engine. >> >> I'd be interested to know whether this would work for you. If you'd >> like to test the class sharing feature I can help you getting started. >> >> Hannes >> >> Am 2014-03-12 10:27, schrieb Tal Liron: >>> In Nashorn, the ClassCache is set per Global instance. >>> >>> This is fine if your application has only one global instance. >>> However, my application design involves creating many Global >>> instances. (Actually, I create and destroy them on the fly per user >>> request in an HTTP server scenario.) The problem is that all code >>> has to constantly be recompiled, and the cache is essentially never >>> used. Since recompilation is so very expensive in Nashorn, this >>> results in awful performance. >>> >>> How can I implement a shared ClassCache? I can't extend and modify >>> Global behavior, because it's a final class. >>> >>> I've tried to cache ScriptFunction instances myself, but I get >>> exceptions when I try to run them with a different Global instance >>> than the one that created them. >> > From tal.liron at threecrickets.com Wed Mar 12 10:45:39 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 12 Mar 2014 18:45:39 +0800 Subject: The class cache In-Reply-To: <53203736.7010904@oracle.com> References: <53202881.5030603@threecrickets.com> <53202DF6.50602@oracle.com> <53202FCC.30504@threecrickets.com> <53203736.7010904@oracle.com> Message-ID: <53203AD3.9090508@threecrickets.com> To be clear: if I use a single Context for all my uses, then with 8u20 things should automatically work for me? Is there a timeline for 8u20's release? On 03/12/2014 06:30 PM, A. Sundararajan wrote: > Actually, the plan is to get to 8u20 - which is an update release > after jdk8 GA. > > Script engine is associated with a single nashorn Context instance. > One nashorn Context instance may be associated with multiple nashorn > Global instances. The class sharing as of today is per global instance > - after Hannes' change, it'll be per Context instance (and so sharing > across all globals associated with a nashorn Context instance). > > ScriptEnvironment._class_cache_size is set from --class-cache-size > option. Currently it is interpreted as per-global cache size. After > Hannes' change, it is per-Context class cache size. > > -Sundar > > On Wednesday 12 March 2014 03:28 PM, Tal Liron wrote: >> I did see that change come through, but I thought it was a JDK9 >> feature... great to know it is for JDK8! >> >> I'll note that I'm not using ScriptEngine, but instead working on the >> Scripturian implementation. How will ScriptEngine make sure to reuse >> the cache? >> >> Would it be possible to also allow a shared ClassCache instance for >> all globals? How about a ScriptEnvironment._class_cache_size boolean >> option to enable this? >> >> On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote: >>> Hi Tal, >>> >>> I'm right now pushing a change for JDK-8021350 that allows sharing >>> script classes between global scopes. Currently, script classes are >>> bound to the global object in various ways, so the change is not >>> trivial, and it's not possible to share compiled scripts between >>> global scopes with the nashorn.jar in current JDK8 builds. The >>> script sharing feature is planned for the 8u20 release. >>> >>> The class sharing will be per script engine, meaning that if you use >>> multiple scopes with one script engine classes will be reused, when >>> you use multiple script engines scripts will be recompiled for each >>> engine. >>> >>> I'd be interested to know whether this would work for you. If you'd >>> like to test the class sharing feature I can help you getting started. >>> >>> Hannes >>> >>> Am 2014-03-12 10:27, schrieb Tal Liron: >>>> In Nashorn, the ClassCache is set per Global instance. >>>> >>>> This is fine if your application has only one global instance. >>>> However, my application design involves creating many Global >>>> instances. (Actually, I create and destroy them on the fly per user >>>> request in an HTTP server scenario.) The problem is that all code >>>> has to constantly be recompiled, and the cache is essentially never >>>> used. Since recompilation is so very expensive in Nashorn, this >>>> results in awful performance. >>>> >>>> How can I implement a shared ClassCache? I can't extend and modify >>>> Global behavior, because it's a final class. >>>> >>>> I've tried to cache ScriptFunction instances myself, but I get >>>> exceptions when I try to run them with a different Global instance >>>> than the one that created them. >>> >> > From tal.liron at threecrickets.com Wed Mar 12 10:57:31 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 12 Mar 2014 18:57:31 +0800 Subject: The class cache In-Reply-To: <53203736.7010904@oracle.com> References: <53202881.5030603@threecrickets.com> <53202DF6.50602@oracle.com> <53202FCC.30504@threecrickets.com> <53203736.7010904@oracle.com> Message-ID: <53203D9B.10601@threecrickets.com> This architecture is actually still problematic for me. My specific problem is that I define a different stdout and stderr per request. Because these are stored in the ScriptEnvironment in the Context, it means I also need a unique Context per request. Why not make it possible to use Context with multiple ScriptEnvironment instances? It seems that all that would be necessary is to add a setEnv method to the class. On 03/12/2014 06:30 PM, A. Sundararajan wrote: > Actually, the plan is to get to 8u20 - which is an update release > after jdk8 GA. > > Script engine is associated with a single nashorn Context instance. > One nashorn Context instance may be associated with multiple nashorn > Global instances. The class sharing as of today is per global instance > - after Hannes' change, it'll be per Context instance (and so sharing > across all globals associated with a nashorn Context instance). > > ScriptEnvironment._class_cache_size is set from --class-cache-size > option. Currently it is interpreted as per-global cache size. After > Hannes' change, it is per-Context class cache size. > > -Sundar > > On Wednesday 12 March 2014 03:28 PM, Tal Liron wrote: >> I did see that change come through, but I thought it was a JDK9 >> feature... great to know it is for JDK8! >> >> I'll note that I'm not using ScriptEngine, but instead working on the >> Scripturian implementation. How will ScriptEngine make sure to reuse >> the cache? >> >> Would it be possible to also allow a shared ClassCache instance for >> all globals? How about a ScriptEnvironment._class_cache_size boolean >> option to enable this? >> >> On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote: >>> Hi Tal, >>> >>> I'm right now pushing a change for JDK-8021350 that allows sharing >>> script classes between global scopes. Currently, script classes are >>> bound to the global object in various ways, so the change is not >>> trivial, and it's not possible to share compiled scripts between >>> global scopes with the nashorn.jar in current JDK8 builds. The >>> script sharing feature is planned for the 8u20 release. >>> >>> The class sharing will be per script engine, meaning that if you use >>> multiple scopes with one script engine classes will be reused, when >>> you use multiple script engines scripts will be recompiled for each >>> engine. >>> >>> I'd be interested to know whether this would work for you. If you'd >>> like to test the class sharing feature I can help you getting started. >>> >>> Hannes >>> >>> Am 2014-03-12 10:27, schrieb Tal Liron: >>>> In Nashorn, the ClassCache is set per Global instance. >>>> >>>> This is fine if your application has only one global instance. >>>> However, my application design involves creating many Global >>>> instances. (Actually, I create and destroy them on the fly per user >>>> request in an HTTP server scenario.) The problem is that all code >>>> has to constantly be recompiled, and the cache is essentially never >>>> used. Since recompilation is so very expensive in Nashorn, this >>>> results in awful performance. >>>> >>>> How can I implement a shared ClassCache? I can't extend and modify >>>> Global behavior, because it's a final class. >>>> >>>> I've tried to cache ScriptFunction instances myself, but I get >>>> exceptions when I try to run them with a different Global instance >>>> than the one that created them. >>> >> > From rick.bullotta at thingworx.com Wed Mar 12 11:00:57 2014 From: rick.bullotta at thingworx.com (Rick Bullotta) Date: Wed, 12 Mar 2014 11:00:57 +0000 Subject: The class cache In-Reply-To: <53203D9B.10601@threecrickets.com> References: <53202881.5030603@threecrickets.com> <53202DF6.50602@oracle.com> <53202FCC.30504@threecrickets.com> <53203736.7010904@oracle.com>,<53203D9B.10601@threecrickets.com> Message-ID: Tal, I don't think that would work in a multi-threaded environment, would it? Calling setEnv on the single instance of the class would be problematic if it was executing on multiple threads in multiple contexts, I'd think... ________________________________________ From: nashorn-dev on behalf of Tal Liron Sent: Wednesday, March 12, 2014 6:57 AM To: nashorn-dev at openjdk.java.net Subject: Re: The class cache This architecture is actually still problematic for me. My specific problem is that I define a different stdout and stderr per request. Because these are stored in the ScriptEnvironment in the Context, it means I also need a unique Context per request. Why not make it possible to use Context with multiple ScriptEnvironment instances? It seems that all that would be necessary is to add a setEnv method to the class. On 03/12/2014 06:30 PM, A. Sundararajan wrote: > Actually, the plan is to get to 8u20 - which is an update release > after jdk8 GA. > > Script engine is associated with a single nashorn Context instance. > One nashorn Context instance may be associated with multiple nashorn > Global instances. The class sharing as of today is per global instance > - after Hannes' change, it'll be per Context instance (and so sharing > across all globals associated with a nashorn Context instance). > > ScriptEnvironment._class_cache_size is set from --class-cache-size > option. Currently it is interpreted as per-global cache size. After > Hannes' change, it is per-Context class cache size. > > -Sundar > > On Wednesday 12 March 2014 03:28 PM, Tal Liron wrote: >> I did see that change come through, but I thought it was a JDK9 >> feature... great to know it is for JDK8! >> >> I'll note that I'm not using ScriptEngine, but instead working on the >> Scripturian implementation. How will ScriptEngine make sure to reuse >> the cache? >> >> Would it be possible to also allow a shared ClassCache instance for >> all globals? How about a ScriptEnvironment._class_cache_size boolean >> option to enable this? >> >> On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote: >>> Hi Tal, >>> >>> I'm right now pushing a change for JDK-8021350 that allows sharing >>> script classes between global scopes. Currently, script classes are >>> bound to the global object in various ways, so the change is not >>> trivial, and it's not possible to share compiled scripts between >>> global scopes with the nashorn.jar in current JDK8 builds. The >>> script sharing feature is planned for the 8u20 release. >>> >>> The class sharing will be per script engine, meaning that if you use >>> multiple scopes with one script engine classes will be reused, when >>> you use multiple script engines scripts will be recompiled for each >>> engine. >>> >>> I'd be interested to know whether this would work for you. If you'd >>> like to test the class sharing feature I can help you getting started. >>> >>> Hannes >>> >>> Am 2014-03-12 10:27, schrieb Tal Liron: >>>> In Nashorn, the ClassCache is set per Global instance. >>>> >>>> This is fine if your application has only one global instance. >>>> However, my application design involves creating many Global >>>> instances. (Actually, I create and destroy them on the fly per user >>>> request in an HTTP server scenario.) The problem is that all code >>>> has to constantly be recompiled, and the cache is essentially never >>>> used. Since recompilation is so very expensive in Nashorn, this >>>> results in awful performance. >>>> >>>> How can I implement a shared ClassCache? I can't extend and modify >>>> Global behavior, because it's a final class. >>>> >>>> I've tried to cache ScriptFunction instances myself, but I get >>>> exceptions when I try to run them with a different Global instance >>>> than the one that created them. >>> >> > From tal.liron at threecrickets.com Wed Mar 12 11:03:50 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 12 Mar 2014 19:03:50 +0800 Subject: The class cache In-Reply-To: References: <53202881.5030603@threecrickets.com> <53202DF6.50602@oracle.com> <53202FCC.30504@threecrickets.com> <53203736.7010904@oracle.com>, <53203D9B.10601@threecrickets.com> Message-ID: <53203F16.2050003@threecrickets.com> Ugh, you're right ... Well, I do kinda have a hacky solution I could put in: implement my own PrintWriter wrapper that uses a thread-local. I think it would be better if stdout and stderr were in Global. On 03/12/2014 07:00 PM, Rick Bullotta wrote: > Tal, I don't think that would work in a multi-threaded environment, would it? Calling setEnv on the single instance of the class would be problematic if it was executing on multiple threads in multiple contexts, I'd think... > ________________________________________ > From: nashorn-dev on behalf of Tal Liron > Sent: Wednesday, March 12, 2014 6:57 AM > To: nashorn-dev at openjdk.java.net > Subject: Re: The class cache > > This architecture is actually still problematic for me. > > My specific problem is that I define a different stdout and stderr per > request. Because these are stored in the ScriptEnvironment in the > Context, it means I also need a unique Context per request. > > Why not make it possible to use Context with multiple ScriptEnvironment > instances? It seems that all that would be necessary is to add a setEnv > method to the class. > > On 03/12/2014 06:30 PM, A. Sundararajan wrote: >> Actually, the plan is to get to 8u20 - which is an update release >> after jdk8 GA. >> >> Script engine is associated with a single nashorn Context instance. >> One nashorn Context instance may be associated with multiple nashorn >> Global instances. The class sharing as of today is per global instance >> - after Hannes' change, it'll be per Context instance (and so sharing >> across all globals associated with a nashorn Context instance). >> >> ScriptEnvironment._class_cache_size is set from --class-cache-size >> option. Currently it is interpreted as per-global cache size. After >> Hannes' change, it is per-Context class cache size. >> >> -Sundar >> >> On Wednesday 12 March 2014 03:28 PM, Tal Liron wrote: >>> I did see that change come through, but I thought it was a JDK9 >>> feature... great to know it is for JDK8! >>> >>> I'll note that I'm not using ScriptEngine, but instead working on the >>> Scripturian implementation. How will ScriptEngine make sure to reuse >>> the cache? >>> >>> Would it be possible to also allow a shared ClassCache instance for >>> all globals? How about a ScriptEnvironment._class_cache_size boolean >>> option to enable this? >>> >>> On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote: >>>> Hi Tal, >>>> >>>> I'm right now pushing a change for JDK-8021350 that allows sharing >>>> script classes between global scopes. Currently, script classes are >>>> bound to the global object in various ways, so the change is not >>>> trivial, and it's not possible to share compiled scripts between >>>> global scopes with the nashorn.jar in current JDK8 builds. The >>>> script sharing feature is planned for the 8u20 release. >>>> >>>> The class sharing will be per script engine, meaning that if you use >>>> multiple scopes with one script engine classes will be reused, when >>>> you use multiple script engines scripts will be recompiled for each >>>> engine. >>>> >>>> I'd be interested to know whether this would work for you. If you'd >>>> like to test the class sharing feature I can help you getting started. >>>> >>>> Hannes >>>> >>>> Am 2014-03-12 10:27, schrieb Tal Liron: >>>>> In Nashorn, the ClassCache is set per Global instance. >>>>> >>>>> This is fine if your application has only one global instance. >>>>> However, my application design involves creating many Global >>>>> instances. (Actually, I create and destroy them on the fly per user >>>>> request in an HTTP server scenario.) The problem is that all code >>>>> has to constantly be recompiled, and the cache is essentially never >>>>> used. Since recompilation is so very expensive in Nashorn, this >>>>> results in awful performance. >>>>> >>>>> How can I implement a shared ClassCache? I can't extend and modify >>>>> Global behavior, because it's a final class. >>>>> >>>>> I've tried to cache ScriptFunction instances myself, but I get >>>>> exceptions when I try to run them with a different Global instance >>>>> than the one that created them. From rick.bullotta at thingworx.com Wed Mar 12 11:15:29 2014 From: rick.bullotta at thingworx.com (Rick Bullotta) Date: Wed, 12 Mar 2014 11:15:29 +0000 Subject: The class cache In-Reply-To: <53203F16.2050003@threecrickets.com> References: <53202881.5030603@threecrickets.com> <53202DF6.50602@oracle.com> <53202FCC.30504@threecrickets.com> <53203736.7010904@oracle.com>, <53203D9B.10601@threecrickets.com> , <53203F16.2050003@threecrickets.com> Message-ID: <2c9185a9632a46ad8d98c3c5cbad7ce2@BY2PR06MB517.namprd06.prod.outlook.com> In Rhino, you would just inject the classes into a reusable ScriptableObject that provided a context that could be re-used across many executions. We would create a ScriptableObject, call initStandardObjects() on it, call putProperty to add class references and defineFunctionProperties to add new base functions, and then keep that resulting ScriptableObject and re-use it over and over again as the execution context. Is there nothing analogous to this with Nashorn? ________________________________________ From: nashorn-dev on behalf of Tal Liron Sent: Wednesday, March 12, 2014 7:03 AM To: nashorn-dev at openjdk.java.net Subject: Re: The class cache Ugh, you're right ... Well, I do kinda have a hacky solution I could put in: implement my own PrintWriter wrapper that uses a thread-local. I think it would be better if stdout and stderr were in Global. On 03/12/2014 07:00 PM, Rick Bullotta wrote: > Tal, I don't think that would work in a multi-threaded environment, would it? Calling setEnv on the single instance of the class would be problematic if it was executing on multiple threads in multiple contexts, I'd think... > ________________________________________ > From: nashorn-dev on behalf of Tal Liron > Sent: Wednesday, March 12, 2014 6:57 AM > To: nashorn-dev at openjdk.java.net > Subject: Re: The class cache > > This architecture is actually still problematic for me. > > My specific problem is that I define a different stdout and stderr per > request. Because these are stored in the ScriptEnvironment in the > Context, it means I also need a unique Context per request. > > Why not make it possible to use Context with multiple ScriptEnvironment > instances? It seems that all that would be necessary is to add a setEnv > method to the class. > > On 03/12/2014 06:30 PM, A. Sundararajan wrote: >> Actually, the plan is to get to 8u20 - which is an update release >> after jdk8 GA. >> >> Script engine is associated with a single nashorn Context instance. >> One nashorn Context instance may be associated with multiple nashorn >> Global instances. The class sharing as of today is per global instance >> - after Hannes' change, it'll be per Context instance (and so sharing >> across all globals associated with a nashorn Context instance). >> >> ScriptEnvironment._class_cache_size is set from --class-cache-size >> option. Currently it is interpreted as per-global cache size. After >> Hannes' change, it is per-Context class cache size. >> >> -Sundar >> >> On Wednesday 12 March 2014 03:28 PM, Tal Liron wrote: >>> I did see that change come through, but I thought it was a JDK9 >>> feature... great to know it is for JDK8! >>> >>> I'll note that I'm not using ScriptEngine, but instead working on the >>> Scripturian implementation. How will ScriptEngine make sure to reuse >>> the cache? >>> >>> Would it be possible to also allow a shared ClassCache instance for >>> all globals? How about a ScriptEnvironment._class_cache_size boolean >>> option to enable this? >>> >>> On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote: >>>> Hi Tal, >>>> >>>> I'm right now pushing a change for JDK-8021350 that allows sharing >>>> script classes between global scopes. Currently, script classes are >>>> bound to the global object in various ways, so the change is not >>>> trivial, and it's not possible to share compiled scripts between >>>> global scopes with the nashorn.jar in current JDK8 builds. The >>>> script sharing feature is planned for the 8u20 release. >>>> >>>> The class sharing will be per script engine, meaning that if you use >>>> multiple scopes with one script engine classes will be reused, when >>>> you use multiple script engines scripts will be recompiled for each >>>> engine. >>>> >>>> I'd be interested to know whether this would work for you. If you'd >>>> like to test the class sharing feature I can help you getting started. >>>> >>>> Hannes >>>> >>>> Am 2014-03-12 10:27, schrieb Tal Liron: >>>>> In Nashorn, the ClassCache is set per Global instance. >>>>> >>>>> This is fine if your application has only one global instance. >>>>> However, my application design involves creating many Global >>>>> instances. (Actually, I create and destroy them on the fly per user >>>>> request in an HTTP server scenario.) The problem is that all code >>>>> has to constantly be recompiled, and the cache is essentially never >>>>> used. Since recompilation is so very expensive in Nashorn, this >>>>> results in awful performance. >>>>> >>>>> How can I implement a shared ClassCache? I can't extend and modify >>>>> Global behavior, because it's a final class. >>>>> >>>>> I've tried to cache ScriptFunction instances myself, but I get >>>>> exceptions when I try to run them with a different Global instance >>>>> than the one that created them. From tal.liron at threecrickets.com Wed Mar 12 11:44:30 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 12 Mar 2014 19:44:30 +0800 Subject: The class cache In-Reply-To: <53202DF6.50602@oracle.com> References: <53202881.5030603@threecrickets.com> <53202DF6.50602@oracle.com> Message-ID: <5320489E.9000209@threecrickets.com> Hannes, I would like to test this. It doesn't seem to be on the main Nashorn repository: http://hg.openjdk.java.net/nashorn/jdk8/nashorn Is there a separate repository I should be using? On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote: > Hi Tal, > > I'm right now pushing a change for JDK-8021350 that allows sharing > script classes between global scopes. Currently, script classes are > bound to the global object in various ways, so the change is not > trivial, and it's not possible to share compiled scripts between > global scopes with the nashorn.jar in current JDK8 builds. The script > sharing feature is planned for the 8u20 release. > > The class sharing will be per script engine, meaning that if you use > multiple scopes with one script engine classes will be reused, when > you use multiple script engines scripts will be recompiled for each > engine. > > I'd be interested to know whether this would work for you. If you'd > like to test the class sharing feature I can help you getting started. > > Hannes > > Am 2014-03-12 10:27, schrieb Tal Liron: >> In Nashorn, the ClassCache is set per Global instance. >> >> This is fine if your application has only one global instance. >> However, my application design involves creating many Global >> instances. (Actually, I create and destroy them on the fly per user >> request in an HTTP server scenario.) The problem is that all code has >> to constantly be recompiled, and the cache is essentially never used. >> Since recompilation is so very expensive in Nashorn, this results in >> awful performance. >> >> How can I implement a shared ClassCache? I can't extend and modify >> Global behavior, because it's a final class. >> >> I've tried to cache ScriptFunction instances myself, but I get >> exceptions when I try to run them with a different Global instance >> than the one that created them. > From hannes.wallnoefer at oracle.com Wed Mar 12 12:06:56 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 12 Mar 2014 13:06:56 +0100 Subject: The class cache In-Reply-To: <5320489E.9000209@threecrickets.com> References: <53202881.5030603@threecrickets.com> <53202DF6.50602@oracle.com> <5320489E.9000209@threecrickets.com> Message-ID: <53204DE0.9010608@oracle.com> Am 2014-03-12 12:44, schrieb Tal Liron: > Hannes, I would like to test this. > > It doesn't seem to be on the main Nashorn repository: > http://hg.openjdk.java.net/nashorn/jdk8/nashorn > > Is there a separate repository I should be using? You can get it here: http://hg.openjdk.java.net/jdk9/dev/nashorn In case you have problems with building I can send you a nashorn.jar via private mail. Just let me know. Hannes > On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote: >> Hi Tal, >> >> I'm right now pushing a change for JDK-8021350 that allows sharing >> script classes between global scopes. Currently, script classes are >> bound to the global object in various ways, so the change is not >> trivial, and it's not possible to share compiled scripts between >> global scopes with the nashorn.jar in current JDK8 builds. The script >> sharing feature is planned for the 8u20 release. >> >> The class sharing will be per script engine, meaning that if you use >> multiple scopes with one script engine classes will be reused, when >> you use multiple script engines scripts will be recompiled for each >> engine. >> >> I'd be interested to know whether this would work for you. If you'd >> like to test the class sharing feature I can help you getting started. >> >> Hannes >> >> Am 2014-03-12 10:27, schrieb Tal Liron: >>> In Nashorn, the ClassCache is set per Global instance. >>> >>> This is fine if your application has only one global instance. >>> However, my application design involves creating many Global >>> instances. (Actually, I create and destroy them on the fly per user >>> request in an HTTP server scenario.) The problem is that all code >>> has to constantly be recompiled, and the cache is essentially never >>> used. Since recompilation is so very expensive in Nashorn, this >>> results in awful performance. >>> >>> How can I implement a shared ClassCache? I can't extend and modify >>> Global behavior, because it's a final class. >>> >>> I've tried to cache ScriptFunction instances myself, but I get >>> exceptions when I try to run them with a different Global instance >>> than the one that created them. >> > From tal.liron at threecrickets.com Wed Mar 12 12:41:30 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 12 Mar 2014 20:41:30 +0800 Subject: The class cache In-Reply-To: <53204DE0.9010608@oracle.com> References: <53202881.5030603@threecrickets.com> <53202DF6.50602@oracle.com> <5320489E.9000209@threecrickets.com> <53204DE0.9010608@oracle.com> Message-ID: <532055FA.2050906@threecrickets.com> Great work, Hannes! With the jdk9 version, it seems caching improves performance by two orders of magnitude. :) And a simple benchmark shows the same code working twice as fast in Nashorn as compared to Rhino. This leaves me in a strange position in terms of what to tell my users. Should I recommend waiting until 8u20 is out? (And when is that going to be?) Or would it make sense for me to provide my own custom-built nashorn.jar? I'm worried, of course, about a custom-built jar, because it would be a snapshot of a development version. I really, really wish this feature could make it to the official OpenJDK 8 release. Any strings you guys can pull to make it happen? On 03/12/2014 08:06 PM, Hannes Wallnoefer wrote: > Am 2014-03-12 12:44, schrieb Tal Liron: >> Hannes, I would like to test this. >> >> It doesn't seem to be on the main Nashorn repository: >> http://hg.openjdk.java.net/nashorn/jdk8/nashorn >> >> Is there a separate repository I should be using? > > You can get it here: > > http://hg.openjdk.java.net/jdk9/dev/nashorn > > In case you have problems with building I can send you a nashorn.jar > via private mail. Just let me know. > > Hannes > >> On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote: >>> Hi Tal, >>> >>> I'm right now pushing a change for JDK-8021350 that allows sharing >>> script classes between global scopes. Currently, script classes are >>> bound to the global object in various ways, so the change is not >>> trivial, and it's not possible to share compiled scripts between >>> global scopes with the nashorn.jar in current JDK8 builds. The >>> script sharing feature is planned for the 8u20 release. >>> >>> The class sharing will be per script engine, meaning that if you use >>> multiple scopes with one script engine classes will be reused, when >>> you use multiple script engines scripts will be recompiled for each >>> engine. >>> >>> I'd be interested to know whether this would work for you. If you'd >>> like to test the class sharing feature I can help you getting started. >>> >>> Hannes >>> >>> Am 2014-03-12 10:27, schrieb Tal Liron: >>>> In Nashorn, the ClassCache is set per Global instance. >>>> >>>> This is fine if your application has only one global instance. >>>> However, my application design involves creating many Global >>>> instances. (Actually, I create and destroy them on the fly per user >>>> request in an HTTP server scenario.) The problem is that all code >>>> has to constantly be recompiled, and the cache is essentially never >>>> used. Since recompilation is so very expensive in Nashorn, this >>>> results in awful performance. >>>> >>>> How can I implement a shared ClassCache? I can't extend and modify >>>> Global behavior, because it's a final class. >>>> >>>> I've tried to cache ScriptFunction instances myself, but I get >>>> exceptions when I try to run them with a different Global instance >>>> than the one that created them. >>> >> > From hannes.wallnoefer at oracle.com Wed Mar 12 13:53:44 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 12 Mar 2014 14:53:44 +0100 Subject: The class cache In-Reply-To: <532055FA.2050906@threecrickets.com> References: <53202881.5030603@threecrickets.com> <53202DF6.50602@oracle.com> <5320489E.9000209@threecrickets.com> <53204DE0.9010608@oracle.com> <532055FA.2050906@threecrickets.com> Message-ID: <532066E8.2000908@oracle.com> That's great to hear, Tal. The gates for JDK8 are definitely closed, but u20 is scheduled for q3 2014, so you won't have to wait too long. I also think there will be preview releases available on jdk8.java.net for quite some time before release. Thanks for testing and feedback! Hannes Am 2014-03-12 13:41, schrieb Tal Liron: > Great work, Hannes! > > With the jdk9 version, it seems caching improves performance by two > orders of magnitude. :) And a simple benchmark shows the same code > working twice as fast in Nashorn as compared to Rhino. > > This leaves me in a strange position in terms of what to tell my > users. Should I recommend waiting until 8u20 is out? (And when is that > going to be?) Or would it make sense for me to provide my own > custom-built nashorn.jar? > > I'm worried, of course, about a custom-built jar, because it would be > a snapshot of a development version. > > I really, really wish this feature could make it to the official > OpenJDK 8 release. Any strings you guys can pull to make it happen? > > On 03/12/2014 08:06 PM, Hannes Wallnoefer wrote: >> Am 2014-03-12 12:44, schrieb Tal Liron: >>> Hannes, I would like to test this. >>> >>> It doesn't seem to be on the main Nashorn repository: >>> http://hg.openjdk.java.net/nashorn/jdk8/nashorn >>> >>> Is there a separate repository I should be using? >> >> You can get it here: >> >> http://hg.openjdk.java.net/jdk9/dev/nashorn >> >> In case you have problems with building I can send you a nashorn.jar >> via private mail. Just let me know. >> >> Hannes >> >>> On 03/12/2014 05:50 PM, Hannes Wallnoefer wrote: >>>> Hi Tal, >>>> >>>> I'm right now pushing a change for JDK-8021350 that allows sharing >>>> script classes between global scopes. Currently, script classes are >>>> bound to the global object in various ways, so the change is not >>>> trivial, and it's not possible to share compiled scripts between >>>> global scopes with the nashorn.jar in current JDK8 builds. The >>>> script sharing feature is planned for the 8u20 release. >>>> >>>> The class sharing will be per script engine, meaning that if you >>>> use multiple scopes with one script engine classes will be reused, >>>> when you use multiple script engines scripts will be recompiled for >>>> each engine. >>>> >>>> I'd be interested to know whether this would work for you. If you'd >>>> like to test the class sharing feature I can help you getting started. >>>> >>>> Hannes >>>> >>>> Am 2014-03-12 10:27, schrieb Tal Liron: >>>>> In Nashorn, the ClassCache is set per Global instance. >>>>> >>>>> This is fine if your application has only one global instance. >>>>> However, my application design involves creating many Global >>>>> instances. (Actually, I create and destroy them on the fly per >>>>> user request in an HTTP server scenario.) The problem is that all >>>>> code has to constantly be recompiled, and the cache is essentially >>>>> never used. Since recompilation is so very expensive in Nashorn, >>>>> this results in awful performance. >>>>> >>>>> How can I implement a shared ClassCache? I can't extend and modify >>>>> Global behavior, because it's a final class. >>>>> >>>>> I've tried to cache ScriptFunction instances myself, but I get >>>>> exceptions when I try to run them with a different Global instance >>>>> than the one that created them. >>>> >>> >> > From hannes.wallnoefer at oracle.com Wed Mar 12 14:14:48 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 12 Mar 2014 15:14:48 +0100 Subject: Review request for JDK-8034055: delete on global object not properly guarded Message-ID: <53206BD8.9020103@oracle.com> Please review JDK-8034055: delete on global object not properly guarded: http://cr.openjdk.java.net/~hannesw/8034055/ This only adds a test case as the bug was fixed in my previous commit (JDK-8021350: Share script classes between threads/globals within context). Thanks, Hannes From sundararajan.athijegannathan at oracle.com Wed Mar 12 14:16:31 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 12 Mar 2014 19:46:31 +0530 Subject: Review request for JDK-8034055: delete on global object not properly guarded In-Reply-To: <53206BD8.9020103@oracle.com> References: <53206BD8.9020103@oracle.com> Message-ID: <53206C3F.8000205@oracle.com> +1 -Sundar On Wednesday 12 March 2014 07:44 PM, Hannes Wallnoefer wrote: > Please review JDK-8034055: delete on global object not properly guarded: > > http://cr.openjdk.java.net/~hannesw/8034055/ > > This only adds a test case as the bug was fixed in my previous commit > (JDK-8021350: Share script classes between threads/globals within > context). > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Thu Mar 13 06:58:49 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 13 Mar 2014 12:28:49 +0530 Subject: RFR JDK-8015958: DataView constructor is not defined Message-ID: <53215729.7070705@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8015958/ Bug: https://bugs.openjdk.java.net/browse/JDK-8015958 Thanks -Sundar From marcus.lagergren at oracle.com Thu Mar 13 09:34:59 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 13 Mar 2014 10:34:59 +0100 Subject: Review request for JDK-8034055: delete on global object not properly guarded In-Reply-To: <53206BD8.9020103@oracle.com> References: <53206BD8.9020103@oracle.com> Message-ID: +1 On 12 Mar 2014, at 15:14, Hannes Wallnoefer wrote: > Please review JDK-8034055: delete on global object not properly guarded: > > http://cr.openjdk.java.net/~hannesw/8034055/ > > This only adds a test case as the bug was fixed in my previous commit (JDK-8021350: Share script classes between threads/globals within context). > > Thanks, > Hannes From attila.szegedi at oracle.com Thu Mar 13 09:50:24 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 13 Mar 2014 10:50:24 +0100 Subject: RFR JDK-8015958: DataView constructor is not defined In-Reply-To: <53215729.7070705@oracle.com> References: <53215729.7070705@oracle.com> Message-ID: <1D0E84C7-78EC-4F37-8C86-9DFDB78155AB@oracle.com> Looks good, +1 On Mar 13, 2014, at 7:58 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8015958/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8015958 > > Thanks > -Sundar From attila.szegedi at oracle.com Thu Mar 13 09:51:51 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 13 Mar 2014 10:51:51 +0100 Subject: Review request for JDK-8034055: delete on global object not properly guarded In-Reply-To: <53206BD8.9020103@oracle.com> References: <53206BD8.9020103@oracle.com> Message-ID: <79E1BC19-7F05-4506-BBB3-1726F8E620E5@oracle.com> +1 On Mar 12, 2014, at 3:14 PM, Hannes Wallnoefer wrote: > Please review JDK-8034055: delete on global object not properly guarded: > > http://cr.openjdk.java.net/~hannesw/8034055/ > > This only adds a test case as the bug was fixed in my previous commit (JDK-8021350: Share script classes between threads/globals within context). > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Thu Mar 13 10:47:18 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 13 Mar 2014 11:47:18 +0100 Subject: RFR JDK-8015958: DataView constructor is not defined In-Reply-To: <53215729.7070705@oracle.com> References: <53215729.7070705@oracle.com> Message-ID: <53218CB6.90004@oracle.com> +1 Am 2014-03-13 07:58, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8015958/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8015958 > > Thanks > -Sundar From marcus.lagergren at oracle.com Thu Mar 13 14:38:09 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 13 Mar 2014 15:38:09 +0100 Subject: RFR JDK-8015958: DataView constructor is not defined In-Reply-To: <53215729.7070705@oracle.com> References: <53215729.7070705@oracle.com> Message-ID: <8E57B365-44BC-438F-ADCE-9012AC245E81@oracle.com> Looks good. +1 We should fast link the setters and getters in the performance release, but that?s a separate enhancement (see findFastGetIndexMethod and findFastSetIndexMethod in the perf repo) /M On 13 Mar 2014, at 07:58, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8015958/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8015958 > > Thanks > -Sundar From james.laskey at oracle.com Fri Mar 14 13:16:09 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 14 Mar 2014 10:16:09 -0300 Subject: JEP 194: Nashorn Code Persistence In-Reply-To: <20140311210812.877921610D@eggemoggin.niobe.net> References: <20140311210812.877921610D@eggemoggin.niobe.net> Message-ID: <2B182A7C-6AA0-4A58-8E76-6DC3DC063BA2@oracle.com> Thank you sir. On Mar 11, 2014, at 6:08 PM, mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/194 > > - Mark From marcus.lagergren at oracle.com Fri Mar 14 13:27:39 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Fri, 14 Mar 2014 13:27:39 +0000 Subject: hg: nashorn/jdk9/nashorn: 8036986: Test should check that correctly type is returned running with optimistic. If optimistic assumption was wrong we should get the right one. Message-ID: <201403141327.s2EDReOA016255@aojmv0008> Changeset: 005ac813256a Author: lagergren Date: 2014-03-14 14:27 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/005ac813256a 8036986: Test should check that correctly type is returned running with optimistic. If optimistic assumption was wrong we should get the right one. Summary: This uses the inspection framework for generated code to ensure optimisim. Reviewed-by: attila, lagergren Contributed-by: matherey.nunez at oracle.com + test/script/basic/optimistic_check_type.js + test/script/basic/optimistic_check_type.js.EXPECTED + test/src/jdk/nashorn/test/tools/StaticTypeInspector.java From sundararajan.athijegannathan at oracle.com Fri Mar 14 15:40:26 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 14 Mar 2014 21:10:26 +0530 Subject: RFR 8037400: Remove getInitialMap getters and GlobalObject interface Message-ID: <532322EA.3070200@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8037400/ Bug: https://bugs.openjdk.java.net/browse/JDK-8037400 -Sundar From attila.szegedi at oracle.com Mon Mar 17 15:26:29 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Mon, 17 Mar 2014 15:26:29 +0000 Subject: hg: nashorn/jdk9/nashorn: 8037086: Check that deoptimizing recompilations are correct Message-ID: <201403171526.s2HFQUSG001274@aojmv0008> Changeset: 949577ac683d Author: mnunez Date: 2014-03-17 15:05 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/949577ac683d 8037086: Check that deoptimizing recompilations are correct Reviewed-by: attila, lagergren + test/src/jdk/nashorn/internal/runtime/OptimisticRecompilationTest.java From tal.liron at threecrickets.com Wed Mar 19 06:41:24 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 19 Mar 2014 14:41:24 +0800 Subject: Congrats! Message-ID: <53293C14.40700@threecrickets.com> ...On the official release of JDK 8! Nashorn is an important component of this release, and I believe it will become more and more important for Java technology's continued usage in many platforms and industries. There's quite a bit of work ahead to make Nashorn as mature as other JVM language engines, but it's already showing excellent performance, proper adherence to standards, and has security baked in. It's a great foundation. I've put quite a bit of effort to make Nashorn work for me, so allow me to join your celebration with this nice cup of gourmet tea. :) -Tal From james.laskey at oracle.com Wed Mar 19 13:24:40 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 19 Mar 2014 10:24:40 -0300 Subject: Congrats! In-Reply-To: <53293C14.40700@threecrickets.com> References: <53293C14.40700@threecrickets.com> Message-ID: <27B2C00D-541F-4A3C-8813-3E6F9D782FA2@oracle.com> Thank you and thank you for your support. Cheers, - Jim On Mar 19, 2014, at 3:41 AM, Tal Liron wrote: > ...On the official release of JDK 8! Nashorn is an important component of this release, and I believe it will become more and more important for Java technology's continued usage in many platforms and industries. > > There's quite a bit of work ahead to make Nashorn as mature as other JVM language engines, but it's already showing excellent performance, proper adherence to standards, and has security baked in. It's a great foundation. > > I've put quite a bit of effort to make Nashorn work for me, so allow me to join your celebration with this nice cup of gourmet tea. :) > > -Tal From attila.szegedi at oracle.com Wed Mar 19 15:17:36 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 19 Mar 2014 16:17:36 +0100 Subject: RFR 8037400: Remove getInitialMap getters and GlobalObject interface In-Reply-To: <532322EA.3070200@oracle.com> References: <532322EA.3070200@oracle.com> Message-ID: +1 On Mar 14, 2014, at 4:40 PM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8037400/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8037400 > > -Sundar From attila.szegedi at oracle.com Wed Mar 19 16:33:44 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 19 Mar 2014 17:33:44 +0100 Subject: Review request for JDK-8037534 Message-ID: Please review JDK-8037534 at http://cr.openjdk.java.net/~attila/8037534/webrev.00 From the JIRA issue: "When doing on-demand compilation, we can use the current runtime scope to look up types of variables in scope; if they're already wider than the current optimistic assumption, we can use that type and cut down on number of recompilation." This cuts down warmup time with optimistic compilation. In Octane tests, box2d now does 1300 deoptimizations instead of 1552 while it warms up, and earley-boyer is down to 1577 from whopping 3028. Thanks, Attila. From attila.szegedi at oracle.com Wed Mar 19 16:34:23 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 19 Mar 2014 17:34:23 +0100 Subject: Review request for JDK-8037534 In-Reply-To: References: Message-ID: <2E61BF03-C83A-49D1-8E0C-002B00B888A4@oracle.com> Actually, the link is http://cr.openjdk.java.net/~attila/8037534/webrev.01/index.html On Mar 19, 2014, at 5:33 PM, Attila Szegedi wrote: > Please review JDK-8037534 at http://cr.openjdk.java.net/~attila/8037534/webrev.00 > > From the JIRA issue: > > "When doing on-demand compilation, we can use the current runtime scope to look up types of variables in scope; if they're already wider than the current optimistic assumption, we can use that type and cut down on number of recompilation." > > This cuts down warmup time with optimistic compilation. In Octane tests, box2d now does 1300 deoptimizations instead of 1552 while it warms up, and earley-boyer is down to 1577 from whopping 3028. > > Thanks, > Attila. From harshad.rj at gmail.com Wed Mar 19 20:38:03 2014 From: harshad.rj at gmail.com (Harshad RJ) Date: Thu, 20 Mar 2014 02:08:03 +0530 Subject: Disabling extensions Message-ID: Hi, How do I disable some or all of the nashorn extensions? I am especially interested in disabling the creation of attributes such as: exit, quit, load, etc. I can confirm that this works: jsContext = jsEngine.getContext() jsContext.removeAttribute("exit", jsContext.getAttributesScope("exit")) However, it would be nicer to disable their creation itself. thanks, -- Harshad RJ From hrjet9 at gmail.com Wed Mar 19 20:43:37 2014 From: hrjet9 at gmail.com (HRJet) Date: Thu, 20 Mar 2014 02:13:37 +0530 Subject: Disabling extensions Message-ID: Hi, How do I disable some or all of the nashorn extensions? I am especially interested in disabling the creation of attributes such as: exit, quit, load, etc. I can confirm that this works: jsContext = jsEngine.getContext() scope = jsContext.getAttributesScope("exit") jsContext.removeAttribute("exit", scope) However, it would be nicer to disable their creation itself. thanks, HRJ From sundararajan.athijegannathan at oracle.com Thu Mar 20 04:04:22 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 20 Mar 2014 09:34:22 +0530 Subject: [8u20] request for approval to backport of nashorn changesets from jdk9/dev to jdk8u20 Message-ID: <532A68C6.8010303@oracle.com> Hi, Please approve backport of the following 25 nashorn (javascript engine) changesets from jdk9/dev/nashorn to jdk8u20/nashorn. Webrev against jdk8u-dev is here: http://cr.openjdk.java.net/~sundar/jdk9dev_to_8u20/ http://cr.openjdk.java.net/~sundar/jdk9dev_to_8u20/webrev.00/ List of bug fixes backported: http://cr.openjdk.java.net/~sundar/jdk9dev_to_8u20/jdk8u20_changesets.txt Links to the individual bugs and the corresponding jdk9/dev changesets below: Bug: https://bugs.openjdk.java.net/browse/JDK-8029031 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/fce0ef0c9858 Bug: https://bugs.openjdk.java.net/browse/JDK-8029364 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/dcca148a8219 Bug: https://bugs.openjdk.java.net/browse/JDK-8030182 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/cade47c36c6c Bug: https://bugs.openjdk.java.net/browse/JDK-8030809 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/8c0524412634 Bug: https://bugs.openjdk.java.net/browse/JDK-8031106 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/78cdf566535d Bug: https://bugs.openjdk.java.net/browse/JDK-8029003 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d6e66fef38eb Bug: https://bugs.openjdk.java.net/browse/JDK-8029667 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/18eccb9656e0 Bug: https://bugs.openjdk.java.net/browse/JDK-8031317 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3bbf629a2db9 Bug: https://bugs.openjdk.java.net/browse/JDK-8031359 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d1d4d669373c Bug: https://bugs.openjdk.java.net/browse/JDK-8029332 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/64ab63d26500 Bug: https://bugs.openjdk.java.net/browse/JDK-8031715 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/c041d151d7e6 Bug: https://bugs.openjdk.java.net/browse/JDK-8031983 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b2ca350d8415 Bug: https://bugs.openjdk.java.net/browse/JDK-8032004 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/341f81ebefe0 Bug: https://bugs.openjdk.java.net/browse/JDK-8032060 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/76f606690a45 Bug: https://bugs.openjdk.java.net/browse/JDK-8032068 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/071eb6953a4a Bug: https://bugs.openjdk.java.net/browse/JDK-8033763 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/22420177ec9d Bug: https://bugs.openjdk.java.net/browse/JDK-8011964 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0afcc0851aab Bug: https://bugs.openjdk.java.net/browse/JDK-8033924 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/79c69831674f Bug: https://bugs.openjdk.java.net/browse/JDK-8030197 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/feceb45debac Bug: https://bugs.openjdk.java.net/browse/JDK-8035948 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4d54c3d19e88 Bug: https://bugs.openjdk.java.net/browse/JDK-8033951 Changeset: http://hg.openjdk.java.net/jdk9/client/nashorn/rev/17c5f77518b1 Bug: https://bugs.openjdk.java.net/browse/JDK-8034055 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/ec0d76397a7d Bug: https://bugs.openjdk.java.net/browse/JDK-8021350 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b457a6ab0738 Bug: https://bugs.openjdk.java.net/browse/JDK-8015958 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/91ef0e039d91 Bug: https://bugs.openjdk.java.net/browse/JDK-8037400 Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3febf16a3039 Thanks -Sundar From sundararajan.athijegannathan at oracle.com Thu Mar 20 04:21:00 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 20 Mar 2014 09:51:00 +0530 Subject: Disabling extensions In-Reply-To: References: Message-ID: <532A6CAC.9040005@oracle.com> Hi, There is no simple way to disable *all* nashorn extensions. But the ECMAScript type arrays (which is not yet ECMAScript standard) and Java access can be disabled using command line options: jjs -nta -nj The above disables "ECMAScript typearrays" and "java access" (Java, Packages, javax, java etc.). As for 'load', 'exit' etc. these are security checked and therefore untrusted script will get security exception. If you still want to delete these, you can manually delete as you wrote. Command line options of 'jjs' also work for nashorn script engine via System property "nashorn.args". For example: java -Dnashorn.args="-nta -nj" Main where Main.java is as follows: import javax.script.*; public class Main { public static void main(String[] args) throws Exception { ScriptEngineManager m = new ScriptEngineManager(); ScriptEngine engine = m.getEngineByName("nashorn"); System.out.println(engine.eval("Int8Array")); System.out.println(engine.eval("Java")); } } -Sundar On Thursday 20 March 2014 02:08 AM, Harshad RJ wrote: > Hi, > > How do I disable some or all of the nashorn extensions? I am > especially interested in disabling the creation of attributes such as: > exit, quit, load, etc. > > I can confirm that this works: > > jsContext = jsEngine.getContext() > jsContext.removeAttribute("exit", jsContext.getAttributesScope("exit")) > > However, it would be nicer to disable their creation itself. > > thanks, From sundararajan.athijegannathan at oracle.com Thu Mar 20 10:51:26 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 20 Mar 2014 16:21:26 +0530 Subject: [8u20] request for approval to backport of nashorn changesets from jdk9/dev to jdk8u20 In-Reply-To: <532AB976.9000200@oracle.com> References: <532A68C6.8010303@oracle.com> <532AB976.9000200@oracle.com> Message-ID: <532AC82E.7070803@oracle.com> No significant changes. Only one minor in a single changeset. All other changesets appled "as is" (with no manual changes). Regards, -Sundar On Thursday 20 March 2014 03:18 PM, Se?n Coffey wrote: > Thanks for looking after the bulk backport effort here Sundar. Can > you confirm that the changesets applied without any significant > updates being required for jdk8u-dev ? > > I've pasted in some code review links from jdk9 Project for reference > also. > > regards, > Sean. > > On 20/03/2014 04:04, A. Sundararajan wrote: >> Hi, >> >> Please approve backport of the following 25 nashorn (javascript >> engine) changesets from jdk9/dev/nashorn to jdk8u20/nashorn. >> >> Webrev against jdk8u-dev is here: >> >> http://cr.openjdk.java.net/~sundar/jdk9dev_to_8u20/ >> http://cr.openjdk.java.net/~sundar/jdk9dev_to_8u20/webrev.00/ >> >> List of bug fixes backported: >> >> http://cr.openjdk.java.net/~sundar/jdk9dev_to_8u20/jdk8u20_changesets.txt >> >> >> Links to the individual bugs and the corresponding jdk9/dev >> changesets below: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029031 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/fce0ef0c9858 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029364 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/dcca148a8219 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8030182 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/cade47c36c6c >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8030809 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/8c0524412634 > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2013-December/002612.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8031106 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/78cdf566535d > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002628.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029003 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d6e66fef38eb >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029667 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/18eccb9656e0 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8031317 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3bbf629a2db9 > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002640.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8031359 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d1d4d669373c > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002645.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029332 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/64ab63d26500 > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002664.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8031715 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/c041d151d7e6 > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002677.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8031983 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b2ca350d8415 > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002678.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8032004 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/341f81ebefe0 > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002680.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8032060 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/76f606690a45 > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002682.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8032068 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/071eb6953a4a > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002686.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8033763 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/22420177ec9d > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002733.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8011964 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0afcc0851aab > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002752.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8033924 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/79c69831674f > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002740.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8030197 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/feceb45debac > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002767.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8035948 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4d54c3d19e88 > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002770.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8033951 >> Changeset: >> http://hg.openjdk.java.net/jdk9/client/nashorn/rev/17c5f77518b1 > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002742.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8034055 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/ec0d76397a7d >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8021350 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b457a6ab0738 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8015958 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/91ef0e039d91 > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-March/002815.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8037400 >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3febf16a3039 > review : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-March/002823.html >> >> Thanks >> -Sundar > From sean.coffey at oracle.com Thu Mar 20 09:48:38 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 20 Mar 2014 09:48:38 +0000 Subject: [8u20] request for approval to backport of nashorn changesets from jdk9/dev to jdk8u20 In-Reply-To: <532A68C6.8010303@oracle.com> References: <532A68C6.8010303@oracle.com> Message-ID: <532AB976.9000200@oracle.com> Thanks for looking after the bulk backport effort here Sundar. Can you confirm that the changesets applied without any significant updates being required for jdk8u-dev ? I've pasted in some code review links from jdk9 Project for reference also. regards, Sean. On 20/03/2014 04:04, A. Sundararajan wrote: > Hi, > > Please approve backport of the following 25 nashorn (javascript > engine) changesets from jdk9/dev/nashorn to jdk8u20/nashorn. > > Webrev against jdk8u-dev is here: > > http://cr.openjdk.java.net/~sundar/jdk9dev_to_8u20/ > http://cr.openjdk.java.net/~sundar/jdk9dev_to_8u20/webrev.00/ > > List of bug fixes backported: > > http://cr.openjdk.java.net/~sundar/jdk9dev_to_8u20/jdk8u20_changesets.txt > > Links to the individual bugs and the corresponding jdk9/dev changesets > below: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029031 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/fce0ef0c9858 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029364 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/dcca148a8219 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8030182 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/cade47c36c6c > > Bug: https://bugs.openjdk.java.net/browse/JDK-8030809 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/8c0524412634 review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2013-December/002612.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8031106 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/78cdf566535d review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002628.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029003 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d6e66fef38eb > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029667 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/18eccb9656e0 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8031317 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3bbf629a2db9 review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002640.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8031359 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d1d4d669373c review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002645.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029332 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/64ab63d26500 review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002664.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8031715 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/c041d151d7e6 review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002677.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8031983 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b2ca350d8415 review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002678.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8032004 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/341f81ebefe0 review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002680.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8032060 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/76f606690a45 review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002682.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8032068 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/071eb6953a4a review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002686.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8033763 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/22420177ec9d review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002733.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8011964 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0afcc0851aab review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002752.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8033924 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/79c69831674f review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002740.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8030197 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/feceb45debac review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002767.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8035948 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4d54c3d19e88 review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002770.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8033951 > Changeset: > http://hg.openjdk.java.net/jdk9/client/nashorn/rev/17c5f77518b1 review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002742.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8034055 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/ec0d76397a7d > > Bug: https://bugs.openjdk.java.net/browse/JDK-8021350 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b457a6ab0738 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8015958 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/91ef0e039d91 review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-March/002815.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037400 > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3febf16a3039 review : http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-March/002823.html > > Thanks > -Sundar From sean.coffey at oracle.com Thu Mar 20 15:14:03 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 20 Mar 2014 15:14:03 +0000 Subject: [8u20] request for approval to backport of nashorn changesets from jdk9/dev to jdk8u20 In-Reply-To: <532AC82E.7070803@oracle.com> References: <532A68C6.8010303@oracle.com> <532AB976.9000200@oracle.com> <532AC82E.7070803@oracle.com> Message-ID: <532B05BB.1020701@oracle.com> Thanks for confirming Sundar! Approved. regards, Sean. On 20/03/2014 10:51, A. Sundararajan wrote: > No significant changes. Only one minor in a single changeset. All > other changesets appled "as is" (with no manual changes). > > Regards, > -Sundar > > On Thursday 20 March 2014 03:18 PM, Se?n Coffey wrote: >> Thanks for looking after the bulk backport effort here Sundar. Can >> you confirm that the changesets applied without any significant >> updates being required for jdk8u-dev ? >> >> I've pasted in some code review links from jdk9 Project for reference >> also. >> >> regards, >> Sean. >> >> On 20/03/2014 04:04, A. Sundararajan wrote: >>> Hi, >>> >>> Please approve backport of the following 25 nashorn (javascript >>> engine) changesets from jdk9/dev/nashorn to jdk8u20/nashorn. >>> >>> Webrev against jdk8u-dev is here: >>> >>> http://cr.openjdk.java.net/~sundar/jdk9dev_to_8u20/ >>> http://cr.openjdk.java.net/~sundar/jdk9dev_to_8u20/webrev.00/ >>> >>> List of bug fixes backported: >>> >>> http://cr.openjdk.java.net/~sundar/jdk9dev_to_8u20/jdk8u20_changesets.txt >>> >>> >>> Links to the individual bugs and the corresponding jdk9/dev >>> changesets below: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029031 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/fce0ef0c9858 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029364 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/dcca148a8219 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030182 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/cade47c36c6c >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030809 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/8c0524412634 >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2013-December/002612.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8031106 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/78cdf566535d >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002628.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029003 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d6e66fef38eb >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029667 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/18eccb9656e0 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8031317 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3bbf629a2db9 >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002640.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8031359 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d1d4d669373c >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002645.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029332 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/64ab63d26500 >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002664.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8031715 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/c041d151d7e6 >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002677.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8031983 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b2ca350d8415 >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002678.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8032004 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/341f81ebefe0 >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002680.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8032060 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/76f606690a45 >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002682.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8032068 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/071eb6953a4a >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002686.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8033763 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/22420177ec9d >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002733.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8011964 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0afcc0851aab >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002752.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8033924 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/79c69831674f >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002740.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030197 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/feceb45debac >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002767.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8035948 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/4d54c3d19e88 >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002770.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8033951 >>> Changeset: >>> http://hg.openjdk.java.net/jdk9/client/nashorn/rev/17c5f77518b1 >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-February/002742.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034055 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/ec0d76397a7d >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8021350 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/b457a6ab0738 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8015958 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/91ef0e039d91 >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-March/002815.html >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8037400 >>> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3febf16a3039 >> review : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-March/002823.html >>> >>> Thanks >>> -Sundar >> > From marcus.lagergren at oracle.com Thu Mar 20 15:21:44 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Thu, 20 Mar 2014 15:21:44 +0000 Subject: hg: nashorn/jdk9/nashorn: 8033334: Make sure that scope depth information is maintained in the RecompilableScriptFunctionDatas, to avoid unnecessary slow proto linkage when doing on demand compilation Message-ID: <201403201521.s2KFLiwc003956@aojmv0008> Changeset: ba08b3188eb2 Author: lagergren Date: 2014-03-20 16:16 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/ba08b3188eb2 8033334: Make sure that scope depth information is maintained in the RecompilableScriptFunctionDatas, to avoid unnecessary slow proto linkage when doing on demand compilation Summary: Compute RecompiledScriptFunctionDatas eagerly, annotate them with scope depth information and use them in recompilations. Reviewed-by: attila, hannesw, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationEnvironment.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java + src/jdk/nashorn/internal/codegen/FindScopeDepths.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/debug/NashornTextifier.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Debug.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyDescriptor.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/arrays/ByteBufferArrayData.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java From marcus.lagergren at oracle.com Thu Mar 20 15:27:03 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Thu, 20 Mar 2014 15:27:03 +0000 Subject: hg: nashorn/jdk9/nashorn: 8037967: Broke the build, by commiting without saving the last review comment Message-ID: <201403201527.s2KFR4GL004929@aojmv0008> Changeset: d7807721d24a Author: lagergren Date: 2014-03-20 16:26 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/d7807721d24a 8037967: Broke the build, by commiting without saving the last review comment Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/PropertyMap.java From sundararajan.athijegannathan at oracle.com Fri Mar 21 12:20:40 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 21 Mar 2014 17:50:40 +0530 Subject: RFR JDK-8037562: Nashorn: JSON.parse comes up with nonexistent entries if there are gaps between the keys Message-ID: <532C2E98.4030401@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8037562/ Bug: https://bugs.openjdk.java.net/browse/JDK-8037562 Thanks -Sundar From hannes.wallnoefer at oracle.com Fri Mar 21 15:29:13 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 21 Mar 2014 16:29:13 +0100 Subject: RFR JDK-8037562: Nashorn: JSON.parse comes up with nonexistent entries if there are gaps between the keys In-Reply-To: <532C2E98.4030401@oracle.com> References: <532C2E98.4030401@oracle.com> Message-ID: <532C5AC9.8060208@oracle.com> +1 for webrev.01. Hannes Am 2014-03-21 13:20, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8037562/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8037562 > > Thanks > -Sundar From james.laskey at oracle.com Fri Mar 21 15:42:26 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 21 Mar 2014 12:42:26 -0300 Subject: RFR JDK-8037562: Nashorn: JSON.parse comes up with nonexistent entries if there are gaps between the keys In-Reply-To: <532C2E98.4030401@oracle.com> References: <532C2E98.4030401@oracle.com> Message-ID: +1 On Mar 21, 2014, at 9:20 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8037562/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8037562 > > Thanks > -Sundar From attila.szegedi at oracle.com Fri Mar 21 16:52:27 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Fri, 21 Mar 2014 16:52:27 +0000 Subject: hg: nashorn/jdk9/nashorn: 16 new changesets Message-ID: <201403211652.s2LGqZqv006226@aojmv0008> Changeset: 4d54c3d19e88 Author: hannesw Date: 2014-03-03 15:23 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/4d54c3d19e88 8035948: Redesign property listeners for shared classes Reviewed-by: sundar, lagergren ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java - src/jdk/nashorn/internal/runtime/PropertyListener.java - src/jdk/nashorn/internal/runtime/PropertyListenerManager.java + src/jdk/nashorn/internal/runtime/PropertyListeners.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/scripts/JO.java Changeset: 2acb7b9c15ca Author: katleman Date: 2014-02-21 11:40 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/2acb7b9c15ca Added tag jdk9-b03 for changeset 832f89ff25d9 ! .hgtags Changeset: 40b754e2b281 Author: lana Date: 2014-02-24 13:06 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/40b754e2b281 Merge Changeset: 3f6ef92cd782 Author: lana Date: 2014-03-06 10:42 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/3f6ef92cd782 Merge Changeset: 17c5f77518b1 Author: simonis Date: 2014-02-10 10:52 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/17c5f77518b1 8033951: nasgen needs the newly build nasgen and nashorn classes in the bootclasspath Reviewed-by: erikj ! make/BuildNashorn.gmk Changeset: dca0e982d9bf Author: prr Date: 2014-02-11 14:43 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/dca0e982d9bf Merge Changeset: 01a904b2c065 Author: prr Date: 2014-02-20 16:26 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/01a904b2c065 Merge Changeset: 57d32365a092 Author: prr Date: 2014-02-27 10:38 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/57d32365a092 Merge Changeset: fc192f46dd89 Author: prr Date: 2014-03-07 10:59 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/fc192f46dd89 Merge - src/jdk/nashorn/internal/runtime/PropertyListener.java - src/jdk/nashorn/internal/runtime/PropertyListenerManager.java Changeset: b457a6ab0738 Author: hannesw Date: 2014-03-12 11:26 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/b457a6ab0738 8021350: Share script classes between threads/globals within context Reviewed-by: lagergren, sundar ! make/build.xml ! make/project.properties ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! test/src/jdk/nashorn/api/scripting/ScopeTest.java + test/src/jdk/nashorn/api/scripting/resources/func.js + test/src/jdk/nashorn/api/scripting/resources/gettersetter.js + test/src/jdk/nashorn/api/scripting/resources/witheval.js Changeset: ec0d76397a7d Author: hannesw Date: 2014-03-12 16:33 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/ec0d76397a7d 8034055: delete on global object not properly guarded Reviewed-by: sundar, lagergren + test/script/basic/JDK-8034055.js + test/script/basic/JDK-8034055.js.EXPECTED Changeset: 91ef0e039d91 Author: sundar Date: 2014-03-13 15:58 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/91ef0e039d91 8015958: DataView constructor is not defined Reviewed-by: attila, hannesw, lagergren ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java + src/jdk/nashorn/internal/objects/NativeDataView.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/dataview_endian.js + test/script/basic/dataview_getset.js + test/script/basic/dataview_new.js Changeset: 3febf16a3039 Author: sundar Date: 2014-03-17 18:02 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/3febf16a3039 8037400: Remove getInitialMap getters and GlobalObject interface Reviewed-by: lagergren, jlaskey, attila ! make/build.xml ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebuggerSupport.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java - src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ByteBufferArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/performance/PerformanceWrapper.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: e2df2f9b4d70 Author: mnunez Date: 2014-03-17 18:27 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/e2df2f9b4d70 8037378: Write sanity tests for bytecode persistence feature Reviewed-by: sundar, hannesw + test/src/jdk/nashorn/internal/runtime/NoPersistenceCachingTest.java Changeset: 62ee612afc3e Author: mnunez Date: 2014-03-19 16:01 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/62ee612afc3e 8037779: NoPersistenceCachingTest fails with ant test Reviewed-by: sundar, hannesw ! test/src/jdk/nashorn/internal/runtime/NoPersistenceCachingTest.java Changeset: 21fe19543736 Author: attila Date: 2014-03-21 17:52 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/21fe19543736 Merge ! make/build.xml ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/codegen/FindScopeDepths.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java + src/jdk/nashorn/internal/objects/NativeDataView.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebuggerSupport.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java - src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/Property.java - src/jdk/nashorn/internal/runtime/PropertyListener.java - src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ByteBufferArrayData.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! src/jdk/nashorn/internal/scripts/JO.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/dataview_new.js + test/script/currently-failing/OptimisticRecompilationTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java - test/src/jdk/nashorn/internal/runtime/OptimisticRecompilationTest.java From marcus.lagergren at oracle.com Sun Mar 23 18:42:53 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Sun, 23 Mar 2014 19:42:53 +0100 Subject: Congrats! In-Reply-To: <53293C14.40700@threecrickets.com> References: <53293C14.40700@threecrickets.com> Message-ID: Thank you, Tal! We really appreciate your beta testing efforts. /M On 19 Mar 2014, at 07:41, Tal Liron wrote: > ...On the official release of JDK 8! Nashorn is an important component of this release, and I believe it will become more and more important for Java technology's continued usage in many platforms and industries. > > There's quite a bit of work ahead to make Nashorn as mature as other JVM language engines, but it's already showing excellent performance, proper adherence to standards, and has security baked in. It's a great foundation. > > I've put quite a bit of effort to make Nashorn work for me, so allow me to join your celebration with this nice cup of gourmet tea. :) > > -Tal From marcus.lagergren at oracle.com Mon Mar 24 00:44:09 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 24 Mar 2014 01:44:09 +0100 Subject: RFR 8037400: Remove getInitialMap getters and GlobalObject interface In-Reply-To: <532322EA.3070200@oracle.com> References: <532322EA.3070200@oracle.com> Message-ID: <67BF737E-F008-409E-BD37-856F895ED225@oracle.com> +1 On 14 Mar 2014, at 16:40, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8037400/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8037400 > > -Sundar From attila.szegedi at oracle.com Mon Mar 24 14:04:18 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 24 Mar 2014 15:04:18 +0100 Subject: Review request for JDK-8038223 Message-ID: <732E3AFB-E369-40BC-965A-B8EA18765DE6@oracle.com> Please review JDK-8038223 at http://cr.openjdk.java.net/~attila/8038223/webrev.01/index.html It's just a small trivial change that speeds up compilation nonetheless by eliminating a bunch of unnecessary string conversions for unused diagnostic output. Thanks, Attila. From attila.szegedi at oracle.com Mon Mar 24 14:12:26 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 24 Mar 2014 15:12:26 +0100 Subject: Review request for JDK-8037534 In-Reply-To: <2E61BF03-C83A-49D1-8E0C-002B00B888A4@oracle.com> References: <2E61BF03-C83A-49D1-8E0C-002B00B888A4@oracle.com> Message-ID: Repeated request to please review this. Since I got no reviews first time around, I updated it in-place with further development -- see the JIRA issue. box2d is down to 377 recompilations by having the compiler do safe evaluation of certain expressions. http://cr.openjdk.java.net/~attila/8037534/webrev.01/index.html On Mar 19, 2014, at 5:34 PM, Attila Szegedi wrote: > Actually, the link is http://cr.openjdk.java.net/~attila/8037534/webrev.01/index.html > > On Mar 19, 2014, at 5:33 PM, Attila Szegedi wrote: > >> Please review JDK-8037534 at http://cr.openjdk.java.net/~attila/8037534/webrev.00 >> >> From the JIRA issue: >> >> "When doing on-demand compilation, we can use the current runtime scope to look up types of variables in scope; if they're already wider than the current optimistic assumption, we can use that type and cut down on number of recompilation." >> >> This cuts down warmup time with optimistic compilation. In Octane tests, box2d now does 1300 deoptimizations instead of 1552 while it warms up, and earley-boyer is down to 1577 from whopping 3028. >> >> Thanks, >> Attila. > From hannes.wallnoefer at oracle.com Mon Mar 24 15:03:09 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 24 Mar 2014 16:03:09 +0100 Subject: Review request for JDK-8038223 In-Reply-To: <732E3AFB-E369-40BC-965A-B8EA18765DE6@oracle.com> References: <732E3AFB-E369-40BC-965A-B8EA18765DE6@oracle.com> Message-ID: <5330492D.9090000@oracle.com> Looks good. Hannes Am 2014-03-24 15:04, schrieb Attila Szegedi: > Please review JDK-8038223 at http://cr.openjdk.java.net/~attila/8038223/webrev.01/index.html > > It's just a small trivial change that speeds up compilation nonetheless by eliminating a bunch of unnecessary string conversions for unused diagnostic output. > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Mon Mar 24 16:33:24 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 24 Mar 2014 17:33:24 +0100 Subject: Review request for JDK-8037534 In-Reply-To: References: <2E61BF03-C83A-49D1-8E0C-002B00B888A4@oracle.com> Message-ID: <53305E54.1010403@oracle.com> Won't CompilationEnvironment.getOptimisticType() widen vars that have not been assigned yet to object type (since their value is undefined)? If not, why not? Other than that the patch looks good. Hannes Am 2014-03-24 15:12, schrieb Attila Szegedi: > Repeated request to please review this. Since I got no reviews first time around, I updated it in-place with further development -- see the JIRA issue. box2d is down to 377 recompilations by having the compiler do safe evaluation of certain expressions. > > http://cr.openjdk.java.net/~attila/8037534/webrev.01/index.html > > On Mar 19, 2014, at 5:34 PM, Attila Szegedi wrote: > >> Actually, the link is http://cr.openjdk.java.net/~attila/8037534/webrev.01/index.html >> >> On Mar 19, 2014, at 5:33 PM, Attila Szegedi wrote: >> >>> Please review JDK-8037534 at http://cr.openjdk.java.net/~attila/8037534/webrev.00 >>> >>> From the JIRA issue: >>> >>> "When doing on-demand compilation, we can use the current runtime scope to look up types of variables in scope; if they're already wider than the current optimistic assumption, we can use that type and cut down on number of recompilation." >>> >>> This cuts down warmup time with optimistic compilation. In Octane tests, box2d now does 1300 deoptimizations instead of 1552 while it warms up, and earley-boyer is down to 1577 from whopping 3028. >>> >>> Thanks, >>> Attila. From attila.szegedi at oracle.com Mon Mar 24 17:40:17 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Mon, 24 Mar 2014 17:40:17 +0000 Subject: hg: nashorn/jdk9/nashorn: 8038223: Symbol trace debug output takes time Message-ID: <201403241740.s2OHeIf2028967@aojmv0008> Changeset: a6b199203eb8 Author: attila Date: 2014-03-24 18:40 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/a6b199203eb8 8038223: Symbol trace debug output takes time Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/ir/Symbol.java From attila.szegedi at oracle.com Mon Mar 24 17:41:14 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Mon, 24 Mar 2014 17:41:14 +0000 Subject: hg: nashorn/jdk9/nashorn: 8037534: Use scope types to determine optimistic types Message-ID: <201403241741.s2OHfEWh029462@aojmv0008> Changeset: 051ac0fec966 Author: attila Date: 2014-03-24 18:41 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/051ac0fec966 8037534: Use scope types to determine optimistic types Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationEnvironment.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/RewriteException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! test/script/currently-failing/OptimisticRecompilationTest.java From greg at apigee.com Tue Mar 25 05:23:00 2014 From: greg at apigee.com (Greg Brail) Date: Mon, 24 Mar 2014 22:23:00 -0700 Subject: Two questions on Nashorn features Message-ID: 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 * | twitter @gbrail From sundararajan.athijegannathan at oracle.com Tue Mar 25 05:30:44 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 25 Mar 2014 11:00:44 +0530 Subject: Two questions on Nashorn features In-Reply-To: References: Message-ID: <53311484.1080503@oracle.com> 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? > > From marcus.lagergren at oracle.com Tue Mar 25 11:17:56 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 25 Mar 2014 12:17:56 +0100 Subject: Two questions on Nashorn features In-Reply-To: <53311484.1080503@oracle.com> References: <53311484.1080503@oracle.com> Message-ID: <638E49AA-A9C9-4C6E-A49E-97FFC9871C5C@oracle.com> 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 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? >> >> > From nate at slideseed.com Tue Mar 25 18:38:45 2014 From: nate at slideseed.com (Nate Kidwell) Date: Tue, 25 Mar 2014 14:38:45 -0400 Subject: nashorn security Message-ID: Greets- 1) Since people probably are going to be running a variety of dynamically-generated code within nashorn, what is done to allow the javascript code to be sandboxed? 2) Is something like engine.put("java", null); engine.put("Java", null); engine.put("Packages", null); etc. sufficiently secure sandboxing if it is run before a engine.eval(...). Or at least if all the bindings are wiped out, would THAT then be sufficient security. 3) Is there any other way to reach outside of the nashorn environment, even if sandboxed? For example are there properties available on any javascript objects (or java objects that are passed in) that would allow the dynamic execution of code on the java side of things. Thanks, Nate From greg at apigee.com Tue Mar 25 19:22:35 2014 From: greg at apigee.com (Greg Brail) Date: Tue, 25 Mar 2014 12:22:35 -0700 Subject: Two questions on Nashorn features In-Reply-To: <53311484.1080503@oracle.com> References: <53311484.1080503@oracle.com> Message-ID: 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 * | twitter @gbrail From greg at apigee.com Tue Mar 25 19:23:14 2014 From: greg at apigee.com (Greg Brail) Date: Tue, 25 Mar 2014 12:23:14 -0700 Subject: nashorn security In-Reply-To: References: Message-ID: Great question -- Rhino had the "class shutter" which was (IMHO) a lot easier to understand than a proper Java security manager. On Tue, Mar 25, 2014 at 11:38 AM, Nate Kidwell wrote: > Greets- > > > 1) Since people probably are going to be running a variety of > dynamically-generated code within nashorn, what is done to allow the > javascript code to be sandboxed? > > > 2) Is something like > > > engine.put("java", null); > > engine.put("Java", null); > > engine.put("Packages", null); > > etc. > > > sufficiently secure sandboxing if it is run before a engine.eval(...). Or > at least if all the bindings are wiped out, would THAT then be sufficient > security. > > > 3) Is there any other way to reach outside of the nashorn environment, even > if sandboxed? For example are there properties available on any javascript > objects (or java objects that are passed in) that would allow the dynamic > execution of code on the java side of things. > > > Thanks, > > Nate > -- *greg brail* | *apigee * | twitter @gbrail From rick.bullotta at thingworx.com Tue Mar 25 19:32:40 2014 From: rick.bullotta at thingworx.com (Rick Bullotta) Date: Tue, 25 Mar 2014 19:32:40 +0000 Subject: nashorn security In-Reply-To: References: , Message-ID: <9274d4aa2fd74683991cb0977e6cb5bb@BY2PR06MB517.namprd06.prod.outlook.com> We use that capability extensively, Greg. Totally agree that it is easy to comprehend and apply. ________________________________________ From: nashorn-dev on behalf of Greg Brail Sent: Tuesday, March 25, 2014 3:23 PM To: Nate Kidwell Cc: nashorn-dev at openjdk.java.net Subject: Re: nashorn security Great question -- Rhino had the "class shutter" which was (IMHO) a lot easier to understand than a proper Java security manager. On Tue, Mar 25, 2014 at 11:38 AM, Nate Kidwell wrote: > Greets- > > > 1) Since people probably are going to be running a variety of > dynamically-generated code within nashorn, what is done to allow the > javascript code to be sandboxed? > > > 2) Is something like > > > engine.put("java", null); > > engine.put("Java", null); > > engine.put("Packages", null); > > etc. > > > sufficiently secure sandboxing if it is run before a engine.eval(...). Or > at least if all the bindings are wiped out, would THAT then be sufficient > security. > > > 3) Is there any other way to reach outside of the nashorn environment, even > if sandboxed? For example are there properties available on any javascript > objects (or java objects that are passed in) that would allow the dynamic > execution of code on the java side of things. > > > Thanks, > > Nate > -- *greg brail* | *apigee * | twitter @gbrail From sundararajan.athijegannathan at oracle.com Wed Mar 26 09:17:57 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 26 Mar 2014 14:47:57 +0530 Subject: nashorn security In-Reply-To: <9274d4aa2fd74683991cb0977e6cb5bb@BY2PR06MB517.namprd06.prod.outlook.com> References: , <9274d4aa2fd74683991cb0977e6cb5bb@BY2PR06MB517.namprd06.prod.outlook.com> Message-ID: <53329B45.2000204@oracle.com> Hi, If you run nashorn under a security manager, the following are not allowed (among other things) * No reflective Java access (java.lang.reflect, java.lang.invoke.*) from scripts. * Script class is loaded only with the default permissions (which are given to all untrusted code) and so script can not write to file, delete a file, spawn a process or do similar bad stuff. * No access to package.access prevented packages, classes. By default security policy, this includes sun.*, jdk.internal.* etc. * All sensitive operations will go through checkPermission of SecurityManager. Unless you configure specific script URLs to have enhanced permissions in your policy file (and load those scripts by load(URL), all script compiled classes are loaded with least permissions. * With --no-java nashorn option passed (for programs you can set nashorn.args System property), top level Packages object, java, javax etc. and Java object are all not initialized by nashorn. This is like extreme class shutter that shuts everything. We use this option when running test262 tests - to make sure we don't initialize unnecessary stuff not expected by ECMAScript compliant code. Rhino has interpreter (at least by default) and java access is by reflection. Nashorn uses bytecode compilation - usual Class based protection domain etc. are always applicable. The comparison here is not exact one. Also, AFAIK ClassShutter alone is not enough in Rhino world, you need to play with wrap factory as well. ClassShutter is only about access to a class via Packages object. If script has got a java object somehow (say exposed from Java embedding code), any public member can still be accessed (please correct me if I am wrong on that). So, you need to play with Rhino's WrapFactory as well (or don't expose any Java object at all)! Summary: run nashorn with security manager enabled. -Sundar On Wednesday 26 March 2014 01:02 AM, Rick Bullotta wrote: > We use that capability extensively, Greg. Totally agree that it is easy to comprehend and apply. > ________________________________________ > From: nashorn-dev on behalf of Greg Brail > Sent: Tuesday, March 25, 2014 3:23 PM > To: Nate Kidwell > Cc: nashorn-dev at openjdk.java.net > Subject: Re: nashorn security > > Great question -- Rhino had the "class shutter" which was (IMHO) a lot > easier to understand than a proper Java security manager. > > > On Tue, Mar 25, 2014 at 11:38 AM, Nate Kidwell wrote: > >> Greets- >> >> >> 1) Since people probably are going to be running a variety of >> dynamically-generated code within nashorn, what is done to allow the >> javascript code to be sandboxed? >> >> >> 2) Is something like >> >> >> engine.put("java", null); >> >> engine.put("Java", null); >> >> engine.put("Packages", null); >> >> etc. >> >> >> sufficiently secure sandboxing if it is run before a engine.eval(...). Or >> at least if all the bindings are wiped out, would THAT then be sufficient >> security. >> >> >> 3) Is there any other way to reach outside of the nashorn environment, even >> if sandboxed? For example are there properties available on any javascript >> objects (or java objects that are passed in) that would allow the dynamic >> execution of code on the java side of things. >> >> >> Thanks, >> >> Nate >> > > > -- > *greg brail* | *apigee * | twitter > @gbrail From attila.szegedi at oracle.com Wed Mar 26 13:25:07 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 26 Mar 2014 14:25:07 +0100 Subject: Review request for JDK-8038396 Message-ID: <13F22AA3-BBE7-4578-99AA-D45B7542EBD0@oracle.com> Please review JDK-8038396 at http://cr.openjdk.java.net/~attila/8038396/webrev.01 There was apparently a case in interaction with dual fields that broke richards Octane benchmark. Thanks, Attila. From hannes.wallnoefer at oracle.com Wed Mar 26 13:42:30 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 26 Mar 2014 14:42:30 +0100 Subject: Review request for JDK-8038396 In-Reply-To: <13F22AA3-BBE7-4578-99AA-D45B7542EBD0@oracle.com> References: <13F22AA3-BBE7-4578-99AA-D45B7542EBD0@oracle.com> Message-ID: <5332D946.9070104@oracle.com> Looks good. Hannes Am 2014-03-26 14:25, schrieb Attila Szegedi: > Please review JDK-8038396 at http://cr.openjdk.java.net/~attila/8038396/webrev.01 > > There was apparently a case in interaction with dual fields that broke richards Octane benchmark. > > Thanks, > Attila. From wei.xiao.com at gmail.com Wed Mar 26 13:52:21 2014 From: wei.xiao.com at gmail.com (Wei Xiao) Date: Wed, 26 Mar 2014 21:52:21 +0800 Subject: Two questions on Nashorn features In-Reply-To: References: <53311484.1080503@oracle.com> Message-ID: <-4217091154863852666@unknownmsgid> 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 ??? > 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 * | twitter > @gbrail From attila.szegedi at oracle.com Wed Mar 26 13:55:46 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 26 Mar 2014 14:55:46 +0100 Subject: Review request for JDK-8038396 In-Reply-To: <13F22AA3-BBE7-4578-99AA-D45B7542EBD0@oracle.com> References: <13F22AA3-BBE7-4578-99AA-D45B7542EBD0@oracle.com> Message-ID: <60BF8608-7300-4C47-A005-50B1157D3136@oracle.com> Added changes in response to Marcus' feedback: http://cr.openjdk.java.net/~attila/8038396/webrev.02 On Mar 26, 2014, at 2:25 PM, Attila Szegedi wrote: > Please review JDK-8038396 at http://cr.openjdk.java.net/~attila/8038396/webrev.01 > > There was apparently a case in interaction with dual fields that broke richards Octane benchmark. > > Thanks, > Attila. From attila.szegedi at oracle.com Wed Mar 26 14:00:38 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Wed, 26 Mar 2014 14:00:38 +0000 Subject: hg: nashorn/jdk9/nashorn: 8038396: fix for the compiler expression evaluator to be more inquisitive about types Message-ID: <201403261400.s2QE0cf0001532@aojmv0008> Changeset: 95fed751dc0e Author: attila Date: 2014-03-26 15:00 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/95fed751dc0e 8038396: fix for the compiler expression evaluator to be more inquisitive about types Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CompilationEnvironment.java From attila.szegedi at oracle.com Wed Mar 26 16:27:26 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 26 Mar 2014 17:27:26 +0100 Subject: Review request for JDK-8038416 Message-ID: <6D49F306-1299-46A6-88E0-D70EED8EA92C@oracle.com> Please review JDK-8038416 at http://cr.openjdk.java.net/~attila/8038416/webrev.00 It's a one-liner building on 8038396. Thanks, Attila. From marcus.lagergren at oracle.com Thu Mar 27 08:47:11 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 27 Mar 2014 09:47:11 +0100 Subject: Review request for JDK-8038416 In-Reply-To: <6D49F306-1299-46A6-88E0-D70EED8EA92C@oracle.com> References: <6D49F306-1299-46A6-88E0-D70EED8EA92C@oracle.com> Message-ID: +1 On 26 Mar 2014, at 17:27, Attila Szegedi wrote: > Please review JDK-8038416 at http://cr.openjdk.java.net/~attila/8038416/webrev.00 > > It's a one-liner building on 8038396. > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Thu Mar 27 10:39:52 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 27 Mar 2014 16:09:52 +0530 Subject: RFR 8038456 : improve nasgen type checks and use specific return type for @Function, @SpecializedFunctio methods Message-ID: <5333FFF8.5020607@oracle.com> Pleas review http://cr.openjdk.java.net/~sundar/8038456/ Bug: https://bugs.openjdk.java.net/browse/JDK-8038456 Thanks -Sundar From marcus.lagergren at oracle.com Thu Mar 27 10:46:22 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Thu, 27 Mar 2014 10:46:22 +0000 Subject: hg: nashorn/jdk9/nashorn: 8038406: Testability: as a first step of moving loggers away from the process global space, the Debug object now supports logging POJOs from log entries as an event queue, which can be introspected from test scripts. This is way better than screen scraping brittle and subject-to-change log output. Message-ID: <201403271046.s2RAkNCY007565@aojmv0008> Changeset: 03b2757e2eba Author: lagergren Date: 2014-03-27 11:45 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/03b2757e2eba 8038406: Testability: as a first step of moving loggers away from the process global space, the Debug object now supports logging POJOs from log entries as an event queue, which can be introspected from test scripts. This is way better than screen scraping brittle and subject-to-change log output. Reviewed-by: attila, hannesw, sundar ! bin/runoptdualcatch.sh ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/DumpBytecode.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/PropertyListeners.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/RewriteException.java + src/jdk/nashorn/internal/runtime/RuntimeEvent.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js + test/script/trusted/event_queue.js + test/script/trusted/event_queue.js.EXPECTED ! test/src/jdk/nashorn/internal/runtime/NoPersistenceCachingTest.java From attila.szegedi at oracle.com Thu Mar 27 13:09:45 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Thu, 27 Mar 2014 13:09:45 +0000 Subject: hg: nashorn/jdk9/nashorn: 8038416: Access to undefined scoped variables deoptimized too much Message-ID: <201403271309.s2RD9kU6029475@aojmv0008> Changeset: fa068c865e46 Author: attila Date: 2014-03-27 14:09 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/fa068c865e46 8038416: Access to undefined scoped variables deoptimized too much Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CompilationEnvironment.java From james.laskey at oracle.com Thu Mar 27 15:10:20 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 27 Mar 2014 12:10:20 -0300 Subject: RFR 8038456 : improve nasgen type checks and use specific return type for @Function, @SpecializedFunctio methods In-Reply-To: <5333FFF8.5020607@oracle.com> References: <5333FFF8.5020607@oracle.com> Message-ID: <26264E08-4DE9-4899-B396-6DAA1C7D09E0@oracle.com> +1 On Mar 27, 2014, at 7:39 AM, A. Sundararajan wrote: > Pleas review http://cr.openjdk.java.net/~sundar/8038456/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8038456 > > Thanks > -Sundar From sundararajan.athijegannathan at oracle.com Fri Mar 28 06:13:43 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 28 Mar 2014 11:43:43 +0530 Subject: RFR 8038615: test262 repo is now a git repo in github Message-ID: <53351317.7070709@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8038615/ Bug: https://bugs.openjdk.java.net/browse/JDK-8038615 Thanks, -Sundar From hannes.wallnoefer at oracle.com Fri Mar 28 08:17:14 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 28 Mar 2014 09:17:14 +0100 Subject: RFR 8038615: test262 repo is now a git repo in github In-Reply-To: <53351317.7070709@oracle.com> References: <53351317.7070709@oracle.com> Message-ID: <5335300A.9040603@oracle.com> +1 Hannes Am 2014-03-28 07:13, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8038615/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8038615 > > Thanks, > -Sundar From marcus.lagergren at oracle.com Mon Mar 31 12:22:21 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Mon, 31 Mar 2014 12:22:21 +0000 Subject: hg: nashorn/jdk9/nashorn: 8027043: Turn global accesses into MethodHandle.constant, with one chance of reassignment, e.g. x = value occuring once in the global scope is ok, twice is not. Message-ID: <201403311222.s2VCMLU5014595@aojmv0008> Changeset: 7bb20a02bad0 Author: lagergren Date: 2014-03-31 14:13 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/7bb20a02bad0 8027043: Turn global accesses into MethodHandle.constant, with one chance of reassignment, e.g. x = value occuring once in the global scope is ok, twice is not. Reviewed-by: attila, sundar, jlaskey + bin/runoptdualcatch9.sh ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CompilationEnvironment.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDataView.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java + src/jdk/nashorn/internal/runtime/GlobalConstants.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/RewriteException.java ! src/jdk/nashorn/internal/runtime/RuntimeEvent.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java - test/script/basic/JDK-8010697.js - test/script/basic/JDK-8010697.js.EXPECTED ! test/script/basic/JDK-8022903.js ! test/script/basic/JDK-8022903.js.EXPECTED ! test/script/basic/JDK-8027042.js ! test/script/basic/JDK-8027042.js.EXPECTED + test/script/currently-failing/JDK-8010697.js + test/script/currently-failing/JDK-8010697.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScopeTest.java From ekemokai at gmail.com Mon Mar 31 18:24:52 2014 From: ekemokai at gmail.com (Edmond Kemokai) Date: Mon, 31 Mar 2014 14:24:52 -0400 Subject: Using Nashorn on a web app platform Message-ID: Hi Folks, I am the developer of HiveMind (crudzilla.com), it is a web app platform for the JVM. It is a combination of a container (jetty), middle-ware and a dev environment. The platform uses JSR-223 so that a users can use many of the scripting engines available for various languages on the JVM. Currently it uses Rhino for Javascript, I attempted to integrate Nashorn but it seems Nashorn doesn't include ASM and including ASM separately creates other conflicts. The Groovy jar for instance includes ASM by changing the package names thus eliminating conflict...perhaps Nashorn should be packaged this way as well? Here is a quick screencast showing usage: http://crudzilla.com/assets/img/info-graphics/lang-demo.gif -Edmond From james.laskey at oracle.com Mon Mar 31 18:36:41 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 31 Mar 2014 15:36:41 -0300 Subject: Using Nashorn on a web app platform In-Reply-To: References: Message-ID: <46AF0D67-8C83-4944-AA9A-3681FAF38051@oracle.com> Edmond, With JDK8, ASM has been included in the JDK. This allows, Lambda, JSR-292 and Nashorn to share the same version of ASM. Would you describe what issue you are running into? Cheers, -- Jim On Mar 31, 2014, at 3:24 PM, Edmond Kemokai wrote: > Hi Folks, > > I am the developer of HiveMind (crudzilla.com), it is a web app platform > for the JVM. It is a combination of a container (jetty), middle-ware and a > dev environment. > > The platform uses JSR-223 so that a users can use many of the scripting > engines available for various languages on the JVM. > > Currently it uses Rhino for Javascript, I attempted to integrate Nashorn > but it seems Nashorn doesn't include ASM and including ASM separately > creates other conflicts. > > The Groovy jar for instance includes ASM by changing the package names thus > eliminating conflict...perhaps Nashorn should be packaged this way as well? > > > Here is a quick screencast showing usage: > http://crudzilla.com/assets/img/info-graphics/lang-demo.gif > > -Edmond From ekemokai at gmail.com Mon Mar 31 20:37:43 2014 From: ekemokai at gmail.com (Edmond Kemokai) Date: Mon, 31 Mar 2014 16:37:43 -0400 Subject: Using Nashorn on a web app platform In-Reply-To: <46AF0D67-8C83-4944-AA9A-3681FAF38051@oracle.com> References: <46AF0D67-8C83-4944-AA9A-3681FAF38051@oracle.com> Message-ID: Hi Jim, Thanks for the follow-up. I went ahead and installed and tested with JDK 8, so far it seems to work as expected...it seems my problem was using jdk-7. By the way if you want to try it, you'll need to *create a new App, *for new app, change the scripting engine for Javascript as demonstrated here: https://s3.amazonaws.com/crudzilla/nashorn.gif *restart HiveMind *create a new script with type Javascript *write any suitable Javascript snippet *right-click and select test *click run -Edmond On Mon, Mar 31, 2014 at 2:36 PM, Jim Laskey (Oracle) < james.laskey at oracle.com> wrote: > Edmond, > > With JDK8, ASM has been included in the JDK. This allows, Lambda, JSR-292 > and Nashorn to share the same version of ASM. Would you describe what > issue you are running into? > > Cheers, > > -- Jim > > > > > On Mar 31, 2014, at 3:24 PM, Edmond Kemokai wrote: > > > Hi Folks, > > > > I am the developer of HiveMind (crudzilla.com), it is a web app platform > > for the JVM. It is a combination of a container (jetty), middle-ware and > a > > dev environment. > > > > The platform uses JSR-223 so that a users can use many of the scripting > > engines available for various languages on the JVM. > > > > Currently it uses Rhino for Javascript, I attempted to integrate Nashorn > > but it seems Nashorn doesn't include ASM and including ASM separately > > creates other conflicts. > > > > The Groovy jar for instance includes ASM by changing the package names > thus > > eliminating conflict...perhaps Nashorn should be packaged this way as > well? > > > > > > Here is a quick screencast showing usage: > > http://crudzilla.com/assets/img/info-graphics/lang-demo.gif > > > > -Edmond > > -- "talk trash and carry a small stick." PAUL KRUGMAN (NYT) "I believe god invented man, because he was disappointed in the monkey" Mark Twain "Beware of geeks bearing formulas" Warren Buffett