From szegedia at gmail.com Tue Dec 1 10:54:21 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 1 Dec 2015 11:54:21 +0100 Subject: RFR 8144230: Add a sample for pluggable dynalink linker In-Reply-To: <565C3EAF.6040903@oracle.com> References: <565C3EAF.6040903@oracle.com> Message-ID: +1. This is amazing. It pretty much embodies what I hoped to see one day becomes possible with Dynalink. Thanks for doing this. Attila. > On Nov 30, 2015, at 1:18 PM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8144230/ for https://bugs.openjdk.java.net/browse/JDK-8144230 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Tue Dec 1 10:56:12 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 1 Dec 2015 16:26:12 +0530 Subject: RFR 8144230: Add a sample for pluggable dynalink linker In-Reply-To: References: <565C3EAF.6040903@oracle.com> Message-ID: <565D7CCC.9040608@oracle.com> Thanks, Attila! -Sundar On 12/1/2015 4:24 PM, Attila Szegedi wrote: > +1. This is amazing. It pretty much embodies what I hoped to see one day becomes possible with Dynalink. > > Thanks for doing this. > > Attila. > >> On Nov 30, 2015, at 1:18 PM, Sundararajan Athijegannathan wrote: >> >> Please review http://cr.openjdk.java.net/~sundar/8144230/ for https://bugs.openjdk.java.net/browse/JDK-8144230 >> >> Thanks, >> -Sundar From sundararajan.athijegannathan at oracle.com Wed Dec 2 09:39:42 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 2 Dec 2015 15:09:42 +0530 Subject: RFR 8144473: Nashorn code assumes NashornCallSiteDescriptor always Message-ID: <565EBC5E.6080509@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8144473/ for https://bugs.openjdk.java.net/browse/JDK-8144473 Piggybacking a dynalink pluggable linker sample to translate underscore_separated names to CamelCase names. The bug in nashorn was found when attempting to use that linker. Nashorn call site descriptors failed (before the current fix) Thanks, -Sundar From hannes.wallnoefer at oracle.com Wed Dec 2 10:31:42 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 2 Dec 2015 11:31:42 +0100 Subject: RFR 8144473: Nashorn code assumes NashornCallSiteDescriptor always In-Reply-To: <565EBC5E.6080509@oracle.com> References: <565EBC5E.6080509@oracle.com> Message-ID: <565EC88E.80805@oracle.com> +1 Nice! Am 2015-12-02 um 10:39 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8144473/ for > https://bugs.openjdk.java.net/browse/JDK-8144473 > > Piggybacking a dynalink pluggable linker sample to translate > underscore_separated names to CamelCase names. > The bug in nashorn was found when attempting to use that linker. > Nashorn call site descriptors failed (before the current fix) > > Thanks, > -Sundar From michael.haupt at oracle.com Wed Dec 2 10:32:02 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 2 Dec 2015 11:32:02 +0100 Subject: RFR 8144473: Nashorn code assumes NashornCallSiteDescriptor always In-Reply-To: <565EBC5E.6080509@oracle.com> References: <565EBC5E.6080509@oracle.com> Message-ID: Hi Sundar, lower-case thumbs up! Next, please write a Dynalink book. :-) Best, Michael > Am 02.12.2015 um 10:39 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8144473/ for https://bugs.openjdk.java.net/browse/JDK-8144473 > > Piggybacking a dynalink pluggable linker sample to translate underscore_separated names to CamelCase names. > The bug in nashorn was found when attempting to use that linker. Nashorn call site descriptors failed (before the current fix) > > Thanks, > -Sundar -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From szegedia at gmail.com Wed Dec 2 13:15:30 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 2 Dec 2015 14:15:30 +0100 Subject: RFR 8144473: Nashorn code assumes NashornCallSiteDescriptor always In-Reply-To: References: <565EBC5E.6080509@oracle.com> Message-ID: +1 Yeah, the assumption used to be that non-exported linkers will only ever observe NashornCallSiteDescriptor as they only link code emitted by Nashorn. This invariant can now obviously (well, "obviously" now that Sundar discovered it?) get violated because an auto-loaded linker can produce a different call site descriptor and delegate linking to linkerServices. Good fix. There's few other cases where we presume a NashornCallSiteDescriptor, e.g. WithObject's linkage, but as far as I can tell, the presumption there is still true (scope of the WithObject can not be referenced nor created externally). FWIW, in my rework for no-such-property (which I hope to be able to submit soon; I'm waiting for my JIRA account reactivation to be able to open the relevant issues) I also had to remove the assumption of NashornCallSiteDescriptor from NashornBottomLinker. Also, and somewhat unrelated, we should also think of providing a GuardingDynamicLinkerExporter for Nashorn itself. I was thinking of what it would export, and weirdly enough, it should actually only export (in my opinion) BoundCallableLinker, JavaSuperAdapterLinker, and JSObjectLinker. NashornLinker is not on the list, as we try to wrap all native Nashorn objects into a ScriptObjectMirror before they leave the engine. (Although adding it just in case we still leak natives somewhere probably wouldn't hurt much.) Attila. On Wed, Dec 2, 2015 at 11:32 AM, Michael Haupt wrote: > Hi Sundar, > > lower-case thumbs up! Next, please write a Dynalink book. :-) > > Best, > > Michael > > > Am 02.12.2015 um 10:39 schrieb Sundararajan Athijegannathan < > sundararajan.athijegannathan at oracle.com>: > > > > Please review http://cr.openjdk.java.net/~sundar/8144473/ for > https://bugs.openjdk.java.net/browse/JDK-8144473 > > > > Piggybacking a dynalink pluggable linker sample to translate > underscore_separated names to CamelCase names. > > The bug in nashorn was found when attempting to use that linker. Nashorn > call site descriptors failed (before the current fix) > > > > Thanks, > > -Sundar > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, > Germany > Oracle is committed to developing > practices and products that help protect the environment > > From sundararajan.athijegannathan at oracle.com Wed Dec 2 17:31:58 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 2 Dec 2015 23:01:58 +0530 Subject: RFR 8144519: Add a sample for pluggable dynalink linker that demonstrats beans linker delegation Message-ID: <565F2B0E.2060103@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8144519/ for https://bugs.openjdk.java.net/browse/JDK-8144519 Thanks, -Sundar From michael.haupt at oracle.com Thu Dec 3 08:15:04 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 3 Dec 2015 09:15:04 +0100 Subject: RFR 8144519: Add a sample for pluggable dynalink linker that demonstrats beans linker delegation In-Reply-To: <565F2B0E.2060103@oracle.com> References: <565F2B0E.2060103@oracle.com> Message-ID: <2CF4DD0D-B76E-4873-AD70-995A48301A53@oracle.com> Hi Sundar, lower-case thumbs up. Smalltalk goodness. :-) Best, Michael > Am 02.12.2015 um 18:31 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8144519/ for https://bugs.openjdk.java.net/browse/JDK-8144519 > > Thanks, > -Sundar -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Fri Dec 4 15:27:22 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 4 Dec 2015 16:27:22 +0100 Subject: Use of long in Nashorn In-Reply-To: <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> References: <5645ADD8.9060906@oracle.com> <8373DB71-DC4C-40E0-BD0C-3910108A6BD5@oracle.com> <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> Message-ID: <5661B0DA.706@oracle.com> After receiving another long/precision related bug last week I decided to go ahead with the removal of longs in Nashorn. It's been quite an effort, but I think it looks good now. Below are the links to the webrev and Jira issue. http://cr.openjdk.java.net/~hannesw/8144020/ https://bugs.openjdk.java.net/browse/JDK-8144020 This is a rather big patch, but it mostly removes code. There are over 2000 deletions vs. 400 insertions. I removed all uses of long in our code where it represented JS numbers, including ScriptObject property accessors with longs as key or value, and the LongArrayData class. With this, all JS numbers are represented as int or double in Nashorn. Longs will not "naturally" occur anymore and only be present as java.lang.Long instances. As expected, the areas that demanded special care were those where ES prescribes use of uint32. These are mostly unsigned right shift, Uint32Array elements, and the length property of arrays. For right shift and Uint32Array elements, I added optimistic implementations that return int if possible and deoptimize to double. Pdfjs and mandreel are benchmarks that make use of these features, and I didn't notice any observable impact on performance. Even when I simulated fallback to double performance was still ok (previously reported performance regressions for this case were in fact caused by an error of mine). For the Array length property, I changed the getter in NativeArray to return int or double depending on actual value. Previously, the length getter always returned long. Since the property is actually evaluated by OptimisticTypesCalculator, for-loops with an array length as limit now use ints instead of longs to iterate through array indices, which is probably a good thing. As for longs returned by Java code, their value is always preserved. Only when they are used for JS math they will be converted to double as prescribed by ECMA. When running with optimistic types we check if a long fits into an int or double to avoid deoptimization to object. Previously we did this only when converting long to optimistic int, but optimistic double did not use any return filter for longs, so a long returned for an optimistic double could easily lose precision. You can find the related changes in OptimisticReturnFilters.java. I also added tests to make sure long values are preserved in various optimistic and non-optimstic contexts, some of which would have previously fail. In a previous version of this patch it included functionality to only treat ints and doubles or their wrapper objects as native JS numbers (e.g. you could invoke Number.prototype methods only on ints and doubles). However, this is a quite a hairy issue and I reckoned the patch is large enough without it, so I pulled it out and will fix this separately as JDK-8143896. I've testing and refining this patch for the last few days and think it looks pretty good. I thought it was a good idea to discuss this to this existing thread before posting a review request. Please let me know what you think. Thanks, Hannes Am 2015-11-13 um 15:06 schrieb Attila Szegedi: > Well, we could just box them in that case. If we only used int and double as primitive number types internally, then a natural representation for a long becomes Long. Java methods returning long could have an optimistic filter that first checks if the value fits in an int (32-bit signed), then in a double (53-bit signed) without loss of precision, and finally deoptimizes to Object and uses Long. int->long->double->Object becomes int->double->Object, with longs of too large magnitude becoming boxed. > > Attila. > >> On Nov 13, 2015, at 2:46 PM, Jim Laskey (Oracle) wrote: >> >> The main thing to watch for here is that longs/Longs need to survive unobstructed between Java calls. Remember we ran into trouble in this area (loss of precision when using longs for encoding.) >> >> >> >> >>> On Nov 13, 2015, at 8:26 AM, Attila Szegedi wrote: >>> >>>> On Nov 13, 2015, at 10:31 AM, Hannes Wallnoefer wrote: >>>> >>>> Hi all, >>>> >>>> I'm currently questioning our use of longs to represent numbers in combination with optimistic typing. >>> I often feel that the presence of longs is more hassle than they?re worth. I?d be all for eliminating them. >>> >>>> After all, there's a pretty large range where long arithmetic will be more precise than the doubles required by ECMA. >>> There?s currently several different places in Nashorn where we try to confine the precision of longs to 53 bits (so they aren?t more precise than doubles). It?s a bit of a whack-a-mole where you can?t always be sure whether you found all instances. >>> >>>> For context see this bug, especially the last two comments (the original bug was about number to string conversion which has been solved in the meantime): >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8065910 >>>> >>>> So the question is: can we use longs at all and be confident that results won't be too precise (and thus, strictly speaking, incorrect)? >>> Internally, the longs are also used for representing UInt32 even in non-optimistic setting, which is only really significant for the >>> operator and array indices and lengths; maybe we should limit longs to that usage only, or even just use doubles internally for UInt32 values that can?t be represented as Int32. FWIW, even for the >>> operator we only need it when shifting by zero, as in every other case the result will have the topmost bit set to 0 and thus fit in Int32 too. >>> >>> I guess once Valhalla rolls around, we could easily have an unsigned 32 bit int type. >>> >>>> Hannes >>> Attila. >>> From james.laskey at oracle.com Fri Dec 4 15:39:00 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 4 Dec 2015 11:39:00 -0400 Subject: Use of long in Nashorn In-Reply-To: <5661B0DA.706@oracle.com> References: <5645ADD8.9060906@oracle.com> <8373DB71-DC4C-40E0-BD0C-3910108A6BD5@oracle.com> <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> <5661B0DA.706@oracle.com> Message-ID: <0692F87F-DCD6-4C55-BEA6-29A79A18E2F0@oracle.com> Cool. Note Attila?s mailing address is no more. > On Dec 4, 2015, at 11:27 AM, Hannes Wallnoefer wrote: > > After receiving another long/precision related bug last week I decided to go ahead with the removal of longs in Nashorn. It's been quite an effort, but I think it looks good now. Below are the links to the webrev and Jira issue. > > http://cr.openjdk.java.net/~hannesw/8144020/ > https://bugs.openjdk.java.net/browse/JDK-8144020 > > This is a rather big patch, but it mostly removes code. There are over 2000 deletions vs. 400 insertions. I removed all uses of long in our code where it represented JS numbers, including ScriptObject property accessors with longs as key or value, and the LongArrayData class. With this, all JS numbers are represented as int or double in Nashorn. Longs will not "naturally" occur anymore and only be present as java.lang.Long instances. > > As expected, the areas that demanded special care were those where ES prescribes use of uint32. These are mostly unsigned right shift, Uint32Array elements, and the length property of arrays. For right shift and Uint32Array elements, I added optimistic implementations that return int if possible and deoptimize to double. Pdfjs and mandreel are benchmarks that make use of these features, and I didn't notice any observable impact on performance. Even when I simulated fallback to double performance was still ok (previously reported performance regressions for this case were in fact caused by an error of mine). > > For the Array length property, I changed the getter in NativeArray to return int or double depending on actual value. Previously, the length getter always returned long. Since the property is actually evaluated by OptimisticTypesCalculator, for-loops with an array length as limit now use ints instead of longs to iterate through array indices, which is probably a good thing. > > As for longs returned by Java code, their value is always preserved. Only when they are used for JS math they will be converted to double as prescribed by ECMA. When running with optimistic types we check if a long fits into an int or double to avoid deoptimization to object. Previously we did this only when converting long to optimistic int, but optimistic double did not use any return filter for longs, so a long returned for an optimistic double could easily lose precision. > > You can find the related changes in OptimisticReturnFilters.java. I also added tests to make sure long values are preserved in various optimistic and non-optimstic contexts, some of which would have previously fail. > > In a previous version of this patch it included functionality to only treat ints and doubles or their wrapper objects as native JS numbers (e.g. you could invoke Number.prototype methods only on ints and doubles). However, this is a quite a hairy issue and I reckoned the patch is large enough without it, so I pulled it out and will fix this separately as JDK-8143896. > > I've testing and refining this patch for the last few days and think it looks pretty good. I thought it was a good idea to discuss this to this existing thread before posting a review request. Please let me know what you think. > > Thanks, > Hannes > > > Am 2015-11-13 um 15:06 schrieb Attila Szegedi: >> Well, we could just box them in that case. If we only used int and double as primitive number types internally, then a natural representation for a long becomes Long. Java methods returning long could have an optimistic filter that first checks if the value fits in an int (32-bit signed), then in a double (53-bit signed) without loss of precision, and finally deoptimizes to Object and uses Long. int->long->double->Object becomes int->double->Object, with longs of too large magnitude becoming boxed. >> >> Attila. >> >>> On Nov 13, 2015, at 2:46 PM, Jim Laskey (Oracle) wrote: >>> >>> The main thing to watch for here is that longs/Longs need to survive unobstructed between Java calls. Remember we ran into trouble in this area (loss of precision when using longs for encoding.) >>> >>> >>> >>> >>>> On Nov 13, 2015, at 8:26 AM, Attila Szegedi wrote: >>>> >>>>> On Nov 13, 2015, at 10:31 AM, Hannes Wallnoefer wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I'm currently questioning our use of longs to represent numbers in combination with optimistic typing. >>>> I often feel that the presence of longs is more hassle than they?re worth. I?d be all for eliminating them. >>>> >>>>> After all, there's a pretty large range where long arithmetic will be more precise than the doubles required by ECMA. >>>> There?s currently several different places in Nashorn where we try to confine the precision of longs to 53 bits (so they aren?t more precise than doubles). It?s a bit of a whack-a-mole where you can?t always be sure whether you found all instances. >>>> >>>>> For context see this bug, especially the last two comments (the original bug was about number to string conversion which has been solved in the meantime): >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8065910 >>>>> >>>>> So the question is: can we use longs at all and be confident that results won't be too precise (and thus, strictly speaking, incorrect)? >>>> Internally, the longs are also used for representing UInt32 even in non-optimistic setting, which is only really significant for the >>> operator and array indices and lengths; maybe we should limit longs to that usage only, or even just use doubles internally for UInt32 values that can?t be represented as Int32. FWIW, even for the >>> operator we only need it when shifting by zero, as in every other case the result will have the topmost bit set to 0 and thus fit in Int32 too. >>>> >>>> I guess once Valhalla rolls around, we could easily have an unsigned 32 bit int type. >>>> >>>>> Hannes >>>> Attila. >>>> > From szegedia at gmail.com Fri Dec 4 15:40:11 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 4 Dec 2015 16:40:11 +0100 Subject: Use of long in Nashorn In-Reply-To: <0692F87F-DCD6-4C55-BEA6-29A79A18E2F0@oracle.com> References: <5645ADD8.9060906@oracle.com> <8373DB71-DC4C-40E0-BD0C-3910108A6BD5@oracle.com> <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> <5661B0DA.706@oracle.com> <0692F87F-DCD6-4C55-BEA6-29A79A18E2F0@oracle.com> Message-ID: No worries, I?m subscribed to nashorn-dev :-) I?m reviewing the code right now. > On Dec 4, 2015, at 4:39 PM, Jim Laskey (Oracle) wrote: > > Cool. Note Attila?s mailing address is no more. > > >> On Dec 4, 2015, at 11:27 AM, Hannes Wallnoefer wrote: >> >> After receiving another long/precision related bug last week I decided to go ahead with the removal of longs in Nashorn. It's been quite an effort, but I think it looks good now. Below are the links to the webrev and Jira issue. >> >> http://cr.openjdk.java.net/~hannesw/8144020/ >> https://bugs.openjdk.java.net/browse/JDK-8144020 >> >> This is a rather big patch, but it mostly removes code. There are over 2000 deletions vs. 400 insertions. I removed all uses of long in our code where it represented JS numbers, including ScriptObject property accessors with longs as key or value, and the LongArrayData class. With this, all JS numbers are represented as int or double in Nashorn. Longs will not "naturally" occur anymore and only be present as java.lang.Long instances. >> >> As expected, the areas that demanded special care were those where ES prescribes use of uint32. These are mostly unsigned right shift, Uint32Array elements, and the length property of arrays. For right shift and Uint32Array elements, I added optimistic implementations that return int if possible and deoptimize to double. Pdfjs and mandreel are benchmarks that make use of these features, and I didn't notice any observable impact on performance. Even when I simulated fallback to double performance was still ok (previously reported performance regressions for this case were in fact caused by an error of mine). >> >> For the Array length property, I changed the getter in NativeArray to return int or double depending on actual value. Previously, the length getter always returned long. Since the property is actually evaluated by OptimisticTypesCalculator, for-loops with an array length as limit now use ints instead of longs to iterate through array indices, which is probably a good thing. >> >> As for longs returned by Java code, their value is always preserved. Only when they are used for JS math they will be converted to double as prescribed by ECMA. When running with optimistic types we check if a long fits into an int or double to avoid deoptimization to object. Previously we did this only when converting long to optimistic int, but optimistic double did not use any return filter for longs, so a long returned for an optimistic double could easily lose precision. >> >> You can find the related changes in OptimisticReturnFilters.java. I also added tests to make sure long values are preserved in various optimistic and non-optimstic contexts, some of which would have previously fail. >> >> In a previous version of this patch it included functionality to only treat ints and doubles or their wrapper objects as native JS numbers (e.g. you could invoke Number.prototype methods only on ints and doubles). However, this is a quite a hairy issue and I reckoned the patch is large enough without it, so I pulled it out and will fix this separately as JDK-8143896. >> >> I've testing and refining this patch for the last few days and think it looks pretty good. I thought it was a good idea to discuss this to this existing thread before posting a review request. Please let me know what you think. >> >> Thanks, >> Hannes >> >> >> Am 2015-11-13 um 15:06 schrieb Attila Szegedi: >>> Well, we could just box them in that case. If we only used int and double as primitive number types internally, then a natural representation for a long becomes Long. Java methods returning long could have an optimistic filter that first checks if the value fits in an int (32-bit signed), then in a double (53-bit signed) without loss of precision, and finally deoptimizes to Object and uses Long. int->long->double->Object becomes int->double->Object, with longs of too large magnitude becoming boxed. >>> >>> Attila. >>> >>>> On Nov 13, 2015, at 2:46 PM, Jim Laskey (Oracle) wrote: >>>> >>>> The main thing to watch for here is that longs/Longs need to survive unobstructed between Java calls. Remember we ran into trouble in this area (loss of precision when using longs for encoding.) >>>> >>>> >>>> >>>> >>>>> On Nov 13, 2015, at 8:26 AM, Attila Szegedi wrote: >>>>> >>>>>> On Nov 13, 2015, at 10:31 AM, Hannes Wallnoefer wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm currently questioning our use of longs to represent numbers in combination with optimistic typing. >>>>> I often feel that the presence of longs is more hassle than they?re worth. I?d be all for eliminating them. >>>>> >>>>>> After all, there's a pretty large range where long arithmetic will be more precise than the doubles required by ECMA. >>>>> There?s currently several different places in Nashorn where we try to confine the precision of longs to 53 bits (so they aren?t more precise than doubles). It?s a bit of a whack-a-mole where you can?t always be sure whether you found all instances. >>>>> >>>>>> For context see this bug, especially the last two comments (the original bug was about number to string conversion which has been solved in the meantime): >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8065910 >>>>>> >>>>>> So the question is: can we use longs at all and be confident that results won't be too precise (and thus, strictly speaking, incorrect)? >>>>> Internally, the longs are also used for representing UInt32 even in non-optimistic setting, which is only really significant for the >>> operator and array indices and lengths; maybe we should limit longs to that usage only, or even just use doubles internally for UInt32 values that can?t be represented as Int32. FWIW, even for the >>> operator we only need it when shifting by zero, as in every other case the result will have the topmost bit set to 0 and thus fit in Int32 too. >>>>> >>>>> I guess once Valhalla rolls around, we could easily have an unsigned 32 bit int type. >>>>> >>>>>> Hannes >>>>> Attila. >>>>> >> > From szegedia at gmail.com Fri Dec 4 17:39:14 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 4 Dec 2015 18:39:14 +0100 Subject: Use of long in Nashorn In-Reply-To: <5661B0DA.706@oracle.com> References: <5645ADD8.9060906@oracle.com> <8373DB71-DC4C-40E0-BD0C-3910108A6BD5@oracle.com> <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> <5661B0DA.706@oracle.com> Message-ID: <0B1CADAA-F45E-48FB-8974-13C72D120B13@gmail.com> * In CodeGenerator SHR implementations (both self-assign and ordinary) you have method.shr() in loadStack instead of consumeStack. I was actually staring at this for a while as it seemed wrong to perform an operation in loadStack, but in the end I decided it?s okay like this. After all, it?s the toUint32 that?s the optimistic part here, so this should be fine indeed. I think we had a JIRA issue saying ?make SHR optimistic? but I can?t find it now. If it pops up, we can mark it as a duplicate of this one. * I see "assert storeType != Type.LONG;? do we even need Type.LONG and LongType class anymore? * Symbol.java: you could reclaim the HAS_LONG_VALUE bit by shifting the rest down by one * optimization idea: have versions of callback invokers in NativeArray.java for both int and double indices. Since we know the length of the array when we enter forEach etc. we could select the double version when length > maxint and the int version otherwise. Actually, we could even have IteratorAction.forEach be overloaded for int and double, and write the body of IteratorAction.apply() to start out with the int version, and when the index crosses maxint start calling the double version (so even for large arrays we?ll iterate calling int specialization of functions for the cases where it?s short circuited). * array length: could we still have Nashorn APIs that return long? Optimistic filters will deal with these appropriately, won?t they? I guess they should since they also need to be able to handle return values from POJO methods that return long (e.g. System.currentTimeMillis()). Hence, you could have NativeArray.length return ?long? and let the optimistic machinery decide whether to cast it as int or double. That would allow you to not have to box the return value of NativeArray.length. * NativeNumber: unused import? *Unit32ArrayData: getBoxedElementType went from INTEGER to DOUBLE. I?m not sure I understand that. I mean, was INTEGER incorrect before? * You didn?t remove LongArrayData.java? * It looks like long[] arrays can now lose precision if passed through Java.from(), E.g. if you have Java methods ?long[] getLongArray()? and ?void setLongArray(long[] arr)? then pojo.setLongArray(Java.from(pojo.getLongArray()) will lose precision because NativeJava.copyArray(long[]) produces double[]. Of course, we could argue that this is expected behavior if you explicitly use Java.from. Just passing around and manipulating a raw long[] won?t have that effect (although it?d be good to confirm that in test), it requires an explicit Java.from(). Still, I wonder if it?d make sense to have copyArray(long[]) either return Object[] or choose dynamically between double[] and Object[] based on the maximum magnitude of an element (you can start with double[] and reallocate as Object[] when you bump into a large long). Other than that: great work! Nice to see large swaths of code removed. Attila. > On Dec 4, 2015, at 4:27 PM, Hannes Wallnoefer wrote: > > After receiving another long/precision related bug last week I decided to go ahead with the removal of longs in Nashorn. It's been quite an effort, but I think it looks good now. Below are the links to the webrev and Jira issue. > > http://cr.openjdk.java.net/~hannesw/8144020/ > https://bugs.openjdk.java.net/browse/JDK-8144020 > > This is a rather big patch, but it mostly removes code. There are over 2000 deletions vs. 400 insertions. I removed all uses of long in our code where it represented JS numbers, including ScriptObject property accessors with longs as key or value, and the LongArrayData class. With this, all JS numbers are represented as int or double in Nashorn. Longs will not "naturally" occur anymore and only be present as java.lang.Long instances. > > As expected, the areas that demanded special care were those where ES prescribes use of uint32. These are mostly unsigned right shift, Uint32Array elements, and the length property of arrays. For right shift and Uint32Array elements, I added optimistic implementations that return int if possible and deoptimize to double. Pdfjs and mandreel are benchmarks that make use of these features, and I didn't notice any observable impact on performance. Even when I simulated fallback to double performance was still ok (previously reported performance regressions for this case were in fact caused by an error of mine). > > For the Array length property, I changed the getter in NativeArray to return int or double depending on actual value. Previously, the length getter always returned long. Since the property is actually evaluated by OptimisticTypesCalculator, for-loops with an array length as limit now use ints instead of longs to iterate through array indices, which is probably a good thing. > > As for longs returned by Java code, their value is always preserved. Only when they are used for JS math they will be converted to double as prescribed by ECMA. When running with optimistic types we check if a long fits into an int or double to avoid deoptimization to object. Previously we did this only when converting long to optimistic int, but optimistic double did not use any return filter for longs, so a long returned for an optimistic double could easily lose precision. > > You can find the related changes in OptimisticReturnFilters.java. I also added tests to make sure long values are preserved in various optimistic and non-optimstic contexts, some of which would have previously fail. > > In a previous version of this patch it included functionality to only treat ints and doubles or their wrapper objects as native JS numbers (e.g. you could invoke Number.prototype methods only on ints and doubles). However, this is a quite a hairy issue and I reckoned the patch is large enough without it, so I pulled it out and will fix this separately as JDK-8143896. > > I've testing and refining this patch for the last few days and think it looks pretty good. I thought it was a good idea to discuss this to this existing thread before posting a review request. Please let me know what you think. > > Thanks, > Hannes > > > Am 2015-11-13 um 15:06 schrieb Attila Szegedi: >> Well, we could just box them in that case. If we only used int and double as primitive number types internally, then a natural representation for a long becomes Long. Java methods returning long could have an optimistic filter that first checks if the value fits in an int (32-bit signed), then in a double (53-bit signed) without loss of precision, and finally deoptimizes to Object and uses Long. int->long->double->Object becomes int->double->Object, with longs of too large magnitude becoming boxed. >> >> Attila. >> >>> On Nov 13, 2015, at 2:46 PM, Jim Laskey (Oracle) wrote: >>> >>> The main thing to watch for here is that longs/Longs need to survive unobstructed between Java calls. Remember we ran into trouble in this area (loss of precision when using longs for encoding.) >>> >>> >>> >>> >>>> On Nov 13, 2015, at 8:26 AM, Attila Szegedi wrote: >>>> >>>>> On Nov 13, 2015, at 10:31 AM, Hannes Wallnoefer wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I'm currently questioning our use of longs to represent numbers in combination with optimistic typing. >>>> I often feel that the presence of longs is more hassle than they?re worth. I?d be all for eliminating them. >>>> >>>>> After all, there's a pretty large range where long arithmetic will be more precise than the doubles required by ECMA. >>>> There?s currently several different places in Nashorn where we try to confine the precision of longs to 53 bits (so they aren?t more precise than doubles). It?s a bit of a whack-a-mole where you can?t always be sure whether you found all instances. >>>> >>>>> For context see this bug, especially the last two comments (the original bug was about number to string conversion which has been solved in the meantime): >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8065910 >>>>> >>>>> So the question is: can we use longs at all and be confident that results won't be too precise (and thus, strictly speaking, incorrect)? >>>> Internally, the longs are also used for representing UInt32 even in non-optimistic setting, which is only really significant for the >>> operator and array indices and lengths; maybe we should limit longs to that usage only, or even just use doubles internally for UInt32 values that can?t be represented as Int32. FWIW, even for the >>> operator we only need it when shifting by zero, as in every other case the result will have the topmost bit set to 0 and thus fit in Int32 too. >>>> >>>> I guess once Valhalla rolls around, we could easily have an unsigned 32 bit int type. >>>> >>>>> Hannes >>>> Attila. >>>> > From hannes.wallnoefer at oracle.com Sun Dec 6 10:12:13 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Sun, 6 Dec 2015 11:12:13 +0100 Subject: Use of long in Nashorn In-Reply-To: <0B1CADAA-F45E-48FB-8974-13C72D120B13@gmail.com> References: <5645ADD8.9060906@oracle.com> <8373DB71-DC4C-40E0-BD0C-3910108A6BD5@oracle.com> <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> <5661B0DA.706@oracle.com> <0B1CADAA-F45E-48FB-8974-13C72D120B13@gmail.com> Message-ID: <566409FD.7030804@oracle.com> Thanks for the quick review, Attila. Answers inline. Am 2015-12-04 um 18:39 schrieb Attila Szegedi: > * In CodeGenerator SHR implementations (both self-assign and ordinary) you have method.shr() in loadStack instead of consumeStack. I was actually staring at this for a while as it seemed wrong to perform an operation in loadStack, but in the end I decided it?s okay like this. After all, it?s the toUint32 that?s the optimistic part here, so this should be fine indeed. I think we had a JIRA issue saying ?make SHR optimistic? but I can?t find it now. If it pops up, we can mark it as a duplicate of this one. I've looked for that Jira issue but didn't find it either. > * I see "assert storeType != Type.LONG;? do we even need Type.LONG and LongType class anymore? That assert is a leftover from the conversion process, it shouldn't be needed anymore. We do still use Type.LONG for creating and handling the primitive fields and spill slots with dual fields. That's why I had to keep it. > * Symbol.java: you could reclaim the HAS_LONG_VALUE bit by shifting the rest down by one Will do. > > * optimization idea: have versions of callback invokers in NativeArray.java for both int and double indices. Since we know the length of the array when we enter forEach etc. we could select the double version when length > maxint and the int version otherwise. Actually, we could even have IteratorAction.forEach be overloaded for int and double, and write the body of IteratorAction.apply() to start out with the int version, and when the index crosses maxint start calling the double version (so even for large arrays we?ll iterate calling int specialization of functions for the cases where it?s short circuited). Nice idea, and should be easy to implement. I'll try it out. > > * array length: could we still have Nashorn APIs that return long? Optimistic filters will deal with these appropriately, won?t they? I guess they should since they also need to be able to handle return values from POJO methods that return long (e.g. System.currentTimeMillis()). Hence, you could have NativeArray.length return ?long? and let the optimistic machinery decide whether to cast it as int or double. That would allow you to not have to box the return value of NativeArray.length. Yes, we could have things returning long, but it will deoptimize to Object. OptimisticReturnFilters (which do the runtime checks) are not used for ScriptObject properties. > * NativeNumber: unused import? Fixed. > *Unit32ArrayData: getBoxedElementType went from INTEGER to DOUBLE. I?m not sure I understand that. I mean, was INTEGER incorrect before? That obviously has been incorrect before. Actually, that method is only used in NativeArray#concat and will never be invoked on typed arrays. Looking at that NativeArray#concat method it looks a bit fishy to me, assuming all NativeArrays use ContinuousArrayData. I have to investigate further on this. Back to the issue at hand, int.class/Integer.class is definitely wrong for element type for Uint32. When returning int.class in getElementType, optimistic code that uses optimstic int getter gets incredibly slow when actually deoptimizing to double, because we keep trying to handle elements as ints. (I had this in my code at one time and found pdfjs slowed down to a crawl when changing the optimistic int getter to always deoptimize to double.) Probably getBoxedElementType should just be a final method instead of abstract in ContinuousArrayData and convert getElementType to boxed counterpart on the fly. > > * You didn?t remove LongArrayData.java? I think I did: http://cr.openjdk.java.net/~hannesw/8144020/webrev.00/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/LongArrayData.java.patch > > * It looks like long[] arrays can now lose precision if passed through Java.from(), E.g. if you have Java methods ?long[] getLongArray()? and ?void setLongArray(long[] arr)? then pojo.setLongArray(Java.from(pojo.getLongArray()) will lose precision because NativeJava.copyArray(long[]) produces double[]. Of course, we could argue that this is expected behavior if you explicitly use Java.from. Just passing around and manipulating a raw long[] won?t have that effect (although it?d be good to confirm that in test), it requires an explicit Java.from(). Still, I wonder if it?d make sense to have copyArray(long[]) either return Object[] or choose dynamically between double[] and Object[] based on the maximum magnitude of an element (you can start with double[] and reallocate as Object[] when you bump into a large long). Good catch. I'll see if I can use existing code in ArrayData to convert to the narrowest array type. Thanks! Hannes > Other than that: great work! Nice to see large swaths of code removed. > > Attila. > >> On Dec 4, 2015, at 4:27 PM, Hannes Wallnoefer wrote: >> >> After receiving another long/precision related bug last week I decided to go ahead with the removal of longs in Nashorn. It's been quite an effort, but I think it looks good now. Below are the links to the webrev and Jira issue. >> >> http://cr.openjdk.java.net/~hannesw/8144020/ >> https://bugs.openjdk.java.net/browse/JDK-8144020 >> >> This is a rather big patch, but it mostly removes code. There are over 2000 deletions vs. 400 insertions. I removed all uses of long in our code where it represented JS numbers, including ScriptObject property accessors with longs as key or value, and the LongArrayData class. With this, all JS numbers are represented as int or double in Nashorn. Longs will not "naturally" occur anymore and only be present as java.lang.Long instances. >> >> As expected, the areas that demanded special care were those where ES prescribes use of uint32. These are mostly unsigned right shift, Uint32Array elements, and the length property of arrays. For right shift and Uint32Array elements, I added optimistic implementations that return int if possible and deoptimize to double. Pdfjs and mandreel are benchmarks that make use of these features, and I didn't notice any observable impact on performance. Even when I simulated fallback to double performance was still ok (previously reported performance regressions for this case were in fact caused by an error of mine). >> >> For the Array length property, I changed the getter in NativeArray to return int or double depending on actual value. Previously, the length getter always returned long. Since the property is actually evaluated by OptimisticTypesCalculator, for-loops with an array length as limit now use ints instead of longs to iterate through array indices, which is probably a good thing. >> >> As for longs returned by Java code, their value is always preserved. Only when they are used for JS math they will be converted to double as prescribed by ECMA. When running with optimistic types we check if a long fits into an int or double to avoid deoptimization to object. Previously we did this only when converting long to optimistic int, but optimistic double did not use any return filter for longs, so a long returned for an optimistic double could easily lose precision. >> >> You can find the related changes in OptimisticReturnFilters.java. I also added tests to make sure long values are preserved in various optimistic and non-optimstic contexts, some of which would have previously fail. >> >> In a previous version of this patch it included functionality to only treat ints and doubles or their wrapper objects as native JS numbers (e.g. you could invoke Number.prototype methods only on ints and doubles). However, this is a quite a hairy issue and I reckoned the patch is large enough without it, so I pulled it out and will fix this separately as JDK-8143896. >> >> I've testing and refining this patch for the last few days and think it looks pretty good. I thought it was a good idea to discuss this to this existing thread before posting a review request. Please let me know what you think. >> >> Thanks, >> Hannes >> >> >> Am 2015-11-13 um 15:06 schrieb Attila Szegedi: >>> Well, we could just box them in that case. If we only used int and double as primitive number types internally, then a natural representation for a long becomes Long. Java methods returning long could have an optimistic filter that first checks if the value fits in an int (32-bit signed), then in a double (53-bit signed) without loss of precision, and finally deoptimizes to Object and uses Long. int->long->double->Object becomes int->double->Object, with longs of too large magnitude becoming boxed. >>> >>> Attila. >>> >>>> On Nov 13, 2015, at 2:46 PM, Jim Laskey (Oracle) wrote: >>>> >>>> The main thing to watch for here is that longs/Longs need to survive unobstructed between Java calls. Remember we ran into trouble in this area (loss of precision when using longs for encoding.) >>>> >>>> >>>> >>>> >>>>> On Nov 13, 2015, at 8:26 AM, Attila Szegedi wrote: >>>>> >>>>>> On Nov 13, 2015, at 10:31 AM, Hannes Wallnoefer wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm currently questioning our use of longs to represent numbers in combination with optimistic typing. >>>>> I often feel that the presence of longs is more hassle than they?re worth. I?d be all for eliminating them. >>>>> >>>>>> After all, there's a pretty large range where long arithmetic will be more precise than the doubles required by ECMA. >>>>> There?s currently several different places in Nashorn where we try to confine the precision of longs to 53 bits (so they aren?t more precise than doubles). It?s a bit of a whack-a-mole where you can?t always be sure whether you found all instances. >>>>> >>>>>> For context see this bug, especially the last two comments (the original bug was about number to string conversion which has been solved in the meantime): >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8065910 >>>>>> >>>>>> So the question is: can we use longs at all and be confident that results won't be too precise (and thus, strictly speaking, incorrect)? >>>>> Internally, the longs are also used for representing UInt32 even in non-optimistic setting, which is only really significant for the >>> operator and array indices and lengths; maybe we should limit longs to that usage only, or even just use doubles internally for UInt32 values that can?t be represented as Int32. FWIW, even for the >>> operator we only need it when shifting by zero, as in every other case the result will have the topmost bit set to 0 and thus fit in Int32 too. >>>>> >>>>> I guess once Valhalla rolls around, we could easily have an unsigned 32 bit int type. >>>>> >>>>>> Hannes >>>>> Attila. >>>>> From hannes.wallnoefer at oracle.com Sun Dec 6 10:27:53 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Sun, 6 Dec 2015 11:27:53 +0100 Subject: Use of long in Nashorn In-Reply-To: <566409FD.7030804@oracle.com> References: <5645ADD8.9060906@oracle.com> <8373DB71-DC4C-40E0-BD0C-3910108A6BD5@oracle.com> <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> <5661B0DA.706@oracle.com> <0B1CADAA-F45E-48FB-8974-13C72D120B13@gmail.com> <566409FD.7030804@oracle.com> Message-ID: <56640DA9.4090408@oracle.com> Am 2015-12-06 um 11:12 schrieb Hannes Wallnoefer: >> >> * array length: could we still have Nashorn APIs that return long? >> Optimistic filters will deal with these appropriately, won?t they? I >> guess they should since they also need to be able to handle return >> values from POJO methods that return long (e.g. >> System.currentTimeMillis()). Hence, you could have NativeArray.length >> return ?long? and let the optimistic machinery decide whether to cast >> it as int or double. That would allow you to not have to box the >> return value of NativeArray.length. > > Yes, we could have things returning long, but it will deoptimize to > Object. OptimisticReturnFilters (which do the runtime checks) are not > used for ScriptObject properties. Actually it would still be nice not to box, which probably means we have to make it optimistic. Looking at this, I found that we have an @Optimistic annotation but it looks like it isn't actually used nor implemented. Hannes From marcus at lagergren.net Mon Dec 7 09:05:46 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 7 Dec 2015 10:05:46 +0100 Subject: RFR 8144230: Add a sample for pluggable dynalink linker In-Reply-To: <565C3EAF.6040903@oracle.com> References: <565C3EAF.6040903@oracle.com> Message-ID: <702FE4C7-C4D6-4BB9-B5F3-BA7AE5D618B7@lagergren.net> Amazing, Sundar! +1 > On 30 Nov 2015, at 13:18, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8144230/ for https://bugs.openjdk.java.net/browse/JDK-8144230 > > Thanks, > -Sundar From marcus at lagergren.net Mon Dec 7 09:08:32 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 7 Dec 2015 10:08:32 +0100 Subject: RFR 8144519: Add a sample for pluggable dynalink linker that demonstrats beans linker delegation In-Reply-To: <565F2B0E.2060103@oracle.com> References: <565F2B0E.2060103@oracle.com> Message-ID: Nice! How about a README that explains a little bit more about how the different dynamic linker example you have implemented work and demo usage? /M > On 02 Dec 2015, at 18:31, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8144519/ for https://bugs.openjdk.java.net/browse/JDK-8144519 > > Thanks, > -Sundar From marcus at lagergren.net Mon Dec 7 09:08:41 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 7 Dec 2015 10:08:41 +0100 Subject: RFR 8144519: Add a sample for pluggable dynalink linker that demonstrats beans linker delegation In-Reply-To: References: <565F2B0E.2060103@oracle.com> Message-ID: <6CC88948-3326-4294-8FEE-02CE9049EE8A@lagergren.net> +1 > On 07 Dec 2015, at 10:08, Marcus Lagergren wrote: > > Nice! > > How about a README that explains a little bit more about how the different dynamic linker example you have implemented work and demo usage? > > /M > >> On 02 Dec 2015, at 18:31, Sundararajan Athijegannathan wrote: >> >> Please review http://cr.openjdk.java.net/~sundar/8144519/ for https://bugs.openjdk.java.net/browse/JDK-8144519 >> >> Thanks, >> -Sundar > From sundararajan.athijegannathan at oracle.com Mon Dec 7 09:23:29 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 7 Dec 2015 14:53:29 +0530 Subject: RFR 8144519: Add a sample for pluggable dynalink linker that demonstrats beans linker delegation In-Reply-To: <6CC88948-3326-4294-8FEE-02CE9049EE8A@lagergren.net> References: <565F2B0E.2060103@oracle.com> <6CC88948-3326-4294-8FEE-02CE9049EE8A@lagergren.net> Message-ID: <56655011.3020304@oracle.com> Hi Marcus, Thanks. I'll write a README and piggyback in my next push. -Sundar On 12/7/2015 2:38 PM, Marcus Lagergren wrote: > +1 > >> On 07 Dec 2015, at 10:08, Marcus Lagergren wrote: >> >> Nice! >> >> How about a README that explains a little bit more about how the different dynamic linker example you have implemented work and demo usage? >> >> /M >> >>> On 02 Dec 2015, at 18:31, Sundararajan Athijegannathan wrote: >>> >>> Please review http://cr.openjdk.java.net/~sundar/8144519/ for https://bugs.openjdk.java.net/browse/JDK-8144519 >>> >>> Thanks, >>> -Sundar From axeld at pinc-software.de Mon Dec 7 10:05:00 2015 From: axeld at pinc-software.de (=?UTF-8?Q?Axel_D=c3=b6rfler?=) Date: Mon, 7 Dec 2015 11:05:00 +0100 Subject: Override load pseudo URL schemes Message-ID: <566559CC.5000500@pinc-software.de> Hi there, I've got a scriptable application that would benefit from having globally available scripts that user scripts can import. Would it be possible to add other pseudo URL schemes (in addition to the already available nashorn: or fx:), and let me handle those requests? Is there a stable API to achieve this by any chance? Thanks in advance! Bye, Axel. From sundararajan.athijegannathan at oracle.com Mon Dec 7 12:08:46 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 7 Dec 2015 17:38:46 +0530 Subject: Override load pseudo URL schemes In-Reply-To: <566559CC.5000500@pinc-software.de> References: <566559CC.5000500@pinc-software.de> Message-ID: <566576CE.1060206@oracle.com> Hi Axel, "load" is just another normal global function. You can replace it with your own version of "load" that extends for other schemes (or forwards calls to original load as needed!) Thanks, -Sundar On 12/7/2015 3:35 PM, Axel D?rfler wrote: > Hi there, > > I've got a scriptable application that would benefit from having > globally available scripts that user scripts can import. > > Would it be possible to add other pseudo URL schemes (in addition to > the already available nashorn: or fx:), and let me handle those > requests? Is there a stable API to achieve this by any chance? > > Thanks in advance! > > Bye, > Axel. From sundararajan.athijegannathan at oracle.com Mon Dec 7 15:46:41 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 7 Dec 2015 21:16:41 +0530 Subject: RFR 8144841: Add a sample for pluggable dynalink linker for stream property on arrays and a REAMDE for linker samples Message-ID: <5665A9E1.2080809@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8144841/ for https://bugs.openjdk.java.net/browse/JDK-8144841 Adding a README for dynalink samples as Marcus suggested earlier. Thanks, -Sundar From michael.haupt at oracle.com Tue Dec 8 08:01:13 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 8 Dec 2015 09:01:13 +0100 Subject: RFR 8144841: Add a sample for pluggable dynalink linker for stream property on arrays and a REAMDE for linker samples In-Reply-To: <5665A9E1.2080809@oracle.com> References: <5665A9E1.2080809@oracle.com> Message-ID: Hi Sundar, lower-case thumbs up! Best, Michael > Am 07.12.2015 um 16:46 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8144841/ for https://bugs.openjdk.java.net/browse/JDK-8144841 > > Adding a README for dynalink samples as Marcus suggested earlier. > > Thanks, > -Sundar -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Tue Dec 8 08:05:44 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 8 Dec 2015 13:35:44 +0530 Subject: RFR 8144841: Add a sample for pluggable dynalink linker for stream property on arrays and a REAMDE for linker samples In-Reply-To: References: <5665A9E1.2080809@oracle.com> Message-ID: <56668F58.2060706@oracle.com> Hi, I've updated webrev to include another sample (treating nio Buffer objects like arrays). Updated webrev is @ http://cr.openjdk.java.net/~sundar/8144841/webrev.01/ Thanks, -Sundar On 12/8/2015 1:31 PM, Michael Haupt wrote: > Hi Sundar, > > lower-case thumbs up! > > Best, > > Michael > >> Am 07.12.2015 um 16:46 schrieb Sundararajan Athijegannathan : >> >> Please review http://cr.openjdk.java.net/~sundar/8144841/ for https://bugs.openjdk.java.net/browse/JDK-8144841 >> >> Adding a README for dynalink samples as Marcus suggested earlier. >> >> Thanks, >> -Sundar From michael.haupt at oracle.com Tue Dec 8 08:21:28 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 8 Dec 2015 09:21:28 +0100 Subject: RFR 8144841: Add a sample for pluggable dynalink linker for stream property on arrays and a REAMDE for linker samples In-Reply-To: <56668F58.2060706@oracle.com> References: <5665A9E1.2080809@oracle.com> <56668F58.2060706@oracle.com> Message-ID: <42D66342-3A61-4298-9059-F590E665DF39@oracle.com> Hi Sundar, thumbs are still up. At some point, I think it would make sense to place the dynalink samples in a dedicated place and provide one dedicated JS file for the compilation and JAR generation that the various samples can just load() at the beginning. The proliferation of ever-similar sample_linker.js files might eventually be overwhelming. Best, Michael > Am 08.12.2015 um 09:05 schrieb Sundararajan Athijegannathan : > > Hi, > > I've updated webrev to include another sample (treating nio Buffer objects like arrays). Updated webrev is @ http://cr.openjdk.java.net/~sundar/8144841/webrev.01/ > > Thanks, > -Sundar > > On 12/8/2015 1:31 PM, Michael Haupt wrote: >> Hi Sundar, >> >> lower-case thumbs up! >> >> Best, >> >> Michael >> >>> Am 07.12.2015 um 16:46 schrieb Sundararajan Athijegannathan : >>> >>> Please review http://cr.openjdk.java.net/~sundar/8144841/ for https://bugs.openjdk.java.net/browse/JDK-8144841 >>> >>> Adding a README for dynalink samples as Marcus suggested earlier. >>> >>> Thanks, >>> -Sundar > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From szegedia at gmail.com Tue Dec 8 10:30:52 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 8 Dec 2015 11:30:52 +0100 Subject: RFR 8144841: Add a sample for pluggable dynalink linker for stream property on arrays and a REAMDE for linker samples In-Reply-To: <56668F58.2060706@oracle.com> References: <5665A9E1.2080809@oracle.com> <56668F58.2060706@oracle.com> Message-ID: A bit of a nitpick: if (getProp && name instanceof String) { String nameStr = (String)name; if (nameStr.equals("stream")) { can be replaced with if (getProp && ?stream?.equals(name)) { Other than that, +1. Still very happy that you?re producing these examples :-) I?m wondering if maybe ?getFirstStandardOperation? would make sense to add as a static method to StandardOperation? Attila. > On Dec 8, 2015, at 9:05 AM, Sundararajan Athijegannathan > wrote: > > Hi, > > I've updated webrev to include another sample (treating nio Buffer objects like arrays). Updated webrev is @ http://cr.openjdk.java.net/~sundar/8144841/webrev.01/ > > Thanks, > -Sundar > > On 12/8/2015 1:31 PM, Michael Haupt wrote: >> Hi Sundar, >> >> lower-case thumbs up! >> >> Best, >> >> Michael >> >>> Am 07.12.2015 um 16:46 schrieb Sundararajan Athijegannathan >: >>> >>> Please review http://cr.openjdk.java.net/~sundar/8144841/ for https://bugs.openjdk.java.net/browse/JDK-8144841 >>> >>> Adding a README for dynalink samples as Marcus suggested earlier. >>> >>> Thanks, >>> -Sundar > From szegedia at gmail.com Tue Dec 8 10:38:56 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 8 Dec 2015 11:38:56 +0100 Subject: Override load pseudo URL schemes In-Reply-To: <566576CE.1060206@oracle.com> References: <566559CC.5000500@pinc-software.de> <566576CE.1060206@oracle.com> Message-ID: We do actually track this as an issue, see https://bugs.openjdk.java.net/browse/JDK-8142335. It turns out that there's all kinds of security implications involved, so we're unlikely to provide customized URL loading as a feature in Nashorn. Fortunately, it's very easy to roll your own load(), and the issue actually has an attached example that shows you how: https://bugs.openjdk.java.net/secure/attachment/54881/LoaderTest.java Hope that helps, Attila. On Mon, Dec 7, 2015 at 1:08 PM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Hi Axel, > > "load" is just another normal global function. You can replace it with > your own version of "load" that extends for other schemes (or forwards > calls to original load as needed!) > > Thanks, > -Sundar > > > On 12/7/2015 3:35 PM, Axel D?rfler wrote: > >> Hi there, >> >> I've got a scriptable application that would benefit from having globally >> available scripts that user scripts can import. >> >> Would it be possible to add other pseudo URL schemes (in addition to the >> already available nashorn: or fx:), and let me handle those requests? Is >> there a stable API to achieve this by any chance? >> >> Thanks in advance! >> >> Bye, >> Axel. >> > > From sundararajan.athijegannathan at oracle.com Tue Dec 8 11:47:16 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 8 Dec 2015 17:17:16 +0530 Subject: RFR 8144841: Add a sample for pluggable dynalink linker for stream property on arrays and a REAMDE for linker samples In-Reply-To: References: <5665A9E1.2080809@oracle.com> <56668F58.2060706@oracle.com> Message-ID: <5666C344.5070706@oracle.com> Thanks Attila. I changed that and pushed it. Yes, it seems that few operation extraction static methods would be useful. -Sundar On 12/8/2015 4:00 PM, Attila Szegedi wrote: > A bit of a nitpick: > > if (getProp && name instanceof String) { > String nameStr = (String)name; > if (nameStr.equals("stream")) { > > can be replaced with > > if (getProp && ?stream?.equals(name)) { > Other than that, +1. Still very happy that you?re producing these > examples :-) > > I?m wondering if maybe ?getFirstStandardOperation? would make sense to > add as a static method to StandardOperation? > > Attila. > > >> On Dec 8, 2015, at 9:05 AM, Sundararajan Athijegannathan >> > > wrote: >> >> Hi, >> >> I've updated webrev to include another sample (treating nio Buffer >> objects like arrays). Updated webrev is @ >> http://cr.openjdk.java.net/~sundar/8144841/webrev.01/ >> >> >> Thanks, >> -Sundar >> >> On 12/8/2015 1:31 PM, Michael Haupt wrote: >>> Hi Sundar, >>> >>> lower-case thumbs up! >>> >>> Best, >>> >>> Michael >>> >>>> Am 07.12.2015 um 16:46 schrieb Sundararajan Athijegannathan >>>> >>> >: >>>> >>>> Please review http://cr.openjdk.java.net/~sundar/8144841/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8144841 >>>> >>>> Adding a README for dynalink samples as Marcus suggested earlier. >>>> >>>> Thanks, >>>> -Sundar >> > From szegedia at gmail.com Tue Dec 8 11:53:08 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 8 Dec 2015 12:53:08 +0100 Subject: Review request for JDK-8144914: Eagerly lookup browser JS object class in BrowserJSObjectLinker Message-ID: <482EFEAD-D413-4F4D-BCC8-98D2581642FA@gmail.com> Please review JDK-8144914 "Eagerly lookup browser JS object class in BrowserJSObjectLinker" at for (Note that line 96 replaces ?return null? for ?return inv? ? the distinction only makes sense in presence of non-standard operations, which we currently don?t have, but even so that?s pedantically more correct.) Thanks, Attila. From szegedia at gmail.com Tue Dec 8 11:55:09 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 8 Dec 2015 12:55:09 +0100 Subject: RFR 8144841: Add a sample for pluggable dynalink linker for stream property on arrays and a REAMDE for linker samples In-Reply-To: <5666C344.5070706@oracle.com> References: <5665A9E1.2080809@oracle.com> <56668F58.2060706@oracle.com> <5666C344.5070706@oracle.com> Message-ID: By the way: https://en.wikipedia.org/wiki/Reamde :-) > On Dec 8, 2015, at 12:47 PM, Sundararajan Athijegannathan > wrote: > > Thanks Attila. I changed that and pushed it. > > Yes, it seems that few operation extraction static methods would be useful. > > -Sundar > > On 12/8/2015 4:00 PM, Attila Szegedi wrote: >> A bit of a nitpick: >> >> if (getProp && name instanceof String) { >> String nameStr = (String)name; >> if (nameStr.equals("stream")) { >> >> can be replaced with >> >> if (getProp && ?stream?.equals(name)) { >> Other than that, +1. Still very happy that you?re producing these examples :-) >> >> I?m wondering if maybe ?getFirstStandardOperation? would make sense to add as a static method to StandardOperation? >> >> Attila. >> >> >>> On Dec 8, 2015, at 9:05 AM, Sundararajan Athijegannathan > wrote: >>> >>> Hi, >>> >>> I've updated webrev to include another sample (treating nio Buffer objects like arrays). Updated webrev is @ http://cr.openjdk.java.net/~sundar/8144841/webrev.01/ >>> >>> Thanks, >>> -Sundar >>> >>> On 12/8/2015 1:31 PM, Michael Haupt wrote: >>>> Hi Sundar, >>>> >>>> lower-case thumbs up! >>>> >>>> Best, >>>> >>>> Michael >>>> >>>>> Am 07.12.2015 um 16:46 schrieb Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com >: >>>>> >>>>> Please review http://cr.openjdk.java.net/~sundar/8144841/ for https://bugs.openjdk.java.net/browse/JDK-8144841 >>>>> >>>>> Adding a README for dynalink samples as Marcus suggested earlier. >>>>> >>>>> Thanks, >>>>> -Sundar >>> >> > From sundararajan.athijegannathan at oracle.com Tue Dec 8 11:56:42 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 8 Dec 2015 17:26:42 +0530 Subject: RFR 8144841: Add a sample for pluggable dynalink linker for stream property on arrays and a REAMDE for linker samples In-Reply-To: References: <5665A9E1.2080809@oracle.com> <56668F58.2060706@oracle.com> <5666C344.5070706@oracle.com> Message-ID: <5666C57A.2060904@oracle.com> :-) On 12/8/2015 5:25 PM, Attila Szegedi wrote: > By the way: https://en.wikipedia.org/wiki/Reamde :-) > >> On Dec 8, 2015, at 12:47 PM, Sundararajan Athijegannathan >> > > wrote: >> >> Thanks Attila. I changed that and pushed it. >> >> Yes, it seems that few operation extraction static methods would be >> useful. >> >> -Sundar >> >> On 12/8/2015 4:00 PM, Attila Szegedi wrote: >>> A bit of a nitpick: >>> >>> if (getProp && name instanceof String) { >>> String nameStr = (String)name; >>> if (nameStr.equals("stream")) { >>> >>> can be replaced with >>> >>> if (getProp && ?stream?.equals(name)) { >>> Other than that, +1. Still very happy that you?re producing these >>> examples :-) >>> >>> I?m wondering if maybe ?getFirstStandardOperation? would make sense >>> to add as a static method to StandardOperation? >>> >>> Attila. >>> >>> >>>> On Dec 8, 2015, at 9:05 AM, Sundararajan Athijegannathan >>>> >>> > wrote: >>>> >>>> Hi, >>>> >>>> I've updated webrev to include another sample (treating nio Buffer >>>> objects like arrays). Updated webrev is @ >>>> http://cr.openjdk.java.net/~sundar/8144841/webrev.01/ >>>> >>>> Thanks, >>>> -Sundar >>>> >>>> On 12/8/2015 1:31 PM, Michael Haupt wrote: >>>>> Hi Sundar, >>>>> >>>>> lower-case thumbs up! >>>>> >>>>> Best, >>>>> >>>>> Michael >>>>> >>>>>> Am 07.12.2015 um 16:46 schrieb Sundararajan Athijegannathan >>>>>> : >>>>>> >>>>>> Please review http://cr.openjdk.java.net/~sundar/8144841/ >>>>>> for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8144841 >>>>>> >>>>>> Adding a README for dynalink samples as Marcus suggested earlier. >>>>>> >>>>>> Thanks, >>>>>> -Sundar >>>> >>> >> > From sundararajan.athijegannathan at oracle.com Tue Dec 8 11:58:03 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 8 Dec 2015 17:28:03 +0530 Subject: Review request for JDK-8144914: Eagerly lookup browser JS object class in BrowserJSObjectLinker In-Reply-To: <482EFEAD-D413-4F4D-BCC8-98D2581642FA@gmail.com> References: <482EFEAD-D413-4F4D-BCC8-98D2581642FA@gmail.com> Message-ID: <5666C5CB.9090108@oracle.com> +1 -Sundar On 12/8/2015 5:23 PM, Attila Szegedi wrote: > Please review JDK-8144914 "Eagerly lookup browser JS object class in BrowserJSObjectLinker" at for > > (Note that line 96 replaces ?return null? for ?return inv? ? the distinction only makes sense in presence of non-standard operations, which we currently don?t have, but even so that?s pedantically more correct.) > > Thanks, > Attila. From hammer65 at gmail.com Tue Dec 1 05:11:28 2015 From: hammer65 at gmail.com (Chris Root) Date: Mon, 30 Nov 2015 23:11:28 -0600 Subject: Nashorn webview issue Message-ID: I'm trying to get two way communication working for a browser project in Nashorn and I'm having trouble implementing an HTML to host callback. I tried this in Java using setMember and it works perfectly, but I can't seem to duplicate it with Nashorn. Since using setMember didn't work I decided to use the approach below but still no luck. I don't want to pick up objects from the window object, I want to plant a function in window that will call Nashorn code. Again getting this to work in Java was no problem. I followed the instructions on this page https://blogs.oracle.com/nashorn/entry/porting_from_the_browser_to I have the jsObject wrapper shown in the article and it works fine. but the code below doesn't work. This is the relevant snip from the load handler. This.engine.loadWorker.stateProperty().addListener(new ChangeListener() { changed: function(value, oldState, newState) { switch(newState){ case Worker.State.SUCCEEDED: This.document = wrap(This.engine.executeScript("document")); This.window = wrap(This.engine.executeScript("window")); This.window.hello = function(){ This.hello(); } As you can see I planted a function on the window called hello, which calls a method of the webview wrapper (same wrapper as in the article) called hello() This.hello = function(){ print("****** hello it worked *******"); } I then set up the alert handler This.engine.onAlert = new javafx.event.EventHandler() { handle: function(evt) { print(evt.data) } }; and then finally loaded the HTML file below into the webview. Nashorn Browser Say Hello What I get back in the console is. JavaRuntimeObject is not a function (evaluating 'window.hello()') Is there any way to establish a callback into my Nashorn code the way it can be done in Java? From vivin.paliath at gmail.com Tue Dec 8 16:04:10 2015 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Tue, 8 Dec 2015 09:04:10 -0700 Subject: Sharing native JavaScript objects across contexts Message-ID: I have a Nashorn engine in which I evaluate some scripts that expose some common utility functions and objects. I want custom scripts to run in their own contexts and not step over each other, so I create new contexts for them using engine.createBindings(): ScriptContext newContext = new SimpleScriptContext(); newContext.setBindings(engine.createBindings(), ScriptContext.ENGINE_SCOPE); newContext.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); Now I have access to everything that was created in the original scope, but this also creates an entirely-new global-object for the new context, which means that instances of native JS objects like Object, Number, etc. are different from corresponding instances in the original context. This leads to some strange behavior. For example, assume you have the following code that was evaluated in the engine (i.e., the "parent" context"): function foo(obj) { print(JSON.stringify(obj, null, 4)); print(Object.getPrototypeOf(obj) === Object.prototype);} Now let's say your custom script is as follows: function bar() { foo({a: 10, b: 20});} I evaluate this against newContext and then invoke the function: engine.eval(source, newContext);ScriptObjectMirror foo = newContext.getAttribute("foo", ScriptContext.ENGINE_SCOPE); foo.call(null); This returns: undefinedfalse This is expected behavior because objects created in other contexts are treated as foreign objects. What I'm trying to do is to expose a common library of functions and maintain that within a single script-engine instance. I don't want to keep recreating script-engine instances because I end up losing JIT optimizations (I read this somewhere, but I can't find the link right now). I do like the fact that objects "remember" their originating global-context, but I'd like that not to happen in the case of native JS objects. Is there a way to create an entirely-new global context, while still sharing JS global-object instances? I've tried manually copying over these instances (enumerating the properties of this), but when I copy them over to the new context, they are ScriptObjectMirror instances and not the unwrapped versions. I assume this is because they were originally created in a different context and therefore are considered to be "foreign". I'm also open to doing this in a completely different manner. I looked at using --global-per-engine, but I noticed that anything exposed by the custom script seemed to end up in the main context instead of the new context that I have created. In general I'm just looking for a way to have isolated execution contexts while still sharing native JS object instances across these contexts. Thanks! -- Ruin untold; And thine own sadness, Sing in the grass, When eve has forgot, that no more hear common things that gleam and pass; But seek alone to lip, sad Rose of love and ruin untold; And thine own mother Can know it as I know More than another What makes your own sadness, Set in her eyes. map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". ":13:02:11:01:02:11:01:12:02";map{print chr unpack" i",pack"B32",$_}$j=~m/.{8}/g From sundararajan.athijegannathan at oracle.com Wed Dec 9 07:56:24 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 9 Dec 2015 13:26:24 +0530 Subject: 8144979: Context.fromClass should catch exception from Class.getClassLoader call Message-ID: <5667DEA8.8000303@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8144979/ for https://bugs.openjdk.java.net/browse/JDK-8144979 This fix is already in jake/nashorn. See also: https://bugs.openjdk.java.net/browse/JDK-8144568 In addition, I've moved all dynalink samples to $nashorn/samples/dynalink directory and renamed the README. Thanks, -Sundar From michael.haupt at oracle.com Wed Dec 9 08:20:46 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 9 Dec 2015 09:20:46 +0100 Subject: 8144979: Context.fromClass should catch exception from Class.getClassLoader call In-Reply-To: <5667DEA8.8000303@oracle.com> References: <5667DEA8.8000303@oracle.com> Message-ID: Hi Sundar, lower-case thumbs up. One remark: I'm a bit concerned about the plethora of files involved with the dynalink samples. For each particular sample, there's a Java file, a sample JS file, and a linker JS file, where the linker compiles the Java file and assembles a JAR. The linkers all look pretty much the same. In my opinion, providing one script that takes care of compilation and JARring and is loaded from all actual samples would keep the samples more lean. Best, Michael > Am 09.12.2015 um 08:56 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8144979/ for https://bugs.openjdk.java.net/browse/JDK-8144979 > This fix is already in jake/nashorn. See also: https://bugs.openjdk.java.net/browse/JDK-8144568 > > In addition, I've moved all dynalink samples to $nashorn/samples/dynalink directory and renamed the README. > > Thanks, > -Sundar -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From szegedia at gmail.com Wed Dec 9 08:38:31 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 9 Dec 2015 09:38:31 +0100 Subject: 8144979: Context.fromClass should catch exception from Class.getClassLoader call In-Reply-To: References: <5667DEA8.8000303@oracle.com> Message-ID: So? I presume the security exception only thrown when a SecurityManager is present? This is actually somewhat weird, especially since VM anonymous classes should return their host class' loader as their loader. getClassLoader() doc says If a security manager is present, and the caller's class loader is not null > and the caller's class loader is not the same as or an ancestor of the > class loader for the class whose class loader is requested, then this > method calls the security manager's checkPermission method with a > RuntimePermission("getClassLoader") permission I'd think that for Context.class.classLoader it is true that it is either null or the ancestor of the script's class loader, is that not so? I'm just trying to understand *why* can this SecurityException arise at all. Attila. On Wed, Dec 9, 2015 at 9:20 AM, Michael Haupt wrote: > Hi Sundar, > > lower-case thumbs up. > > One remark: I'm a bit concerned about the plethora of files involved with > the dynalink samples. For each particular sample, there's a Java file, a > sample JS file, and a linker JS file, where the linker compiles the Java > file and assembles a JAR. The linkers all look pretty much the same. In my > opinion, providing one script that takes care of compilation and JARring > and is loaded from all actual samples would keep the samples more lean. > > Best, > > Michael > > > Am 09.12.2015 um 08:56 schrieb Sundararajan Athijegannathan < > sundararajan.athijegannathan at oracle.com>: > > > > Please review http://cr.openjdk.java.net/~sundar/8144979/ for > https://bugs.openjdk.java.net/browse/JDK-8144979 > > This fix is already in jake/nashorn. See also: > https://bugs.openjdk.java.net/browse/JDK-8144568 > > > > In addition, I've moved all dynalink samples to > $nashorn/samples/dynalink directory and renamed the README. > > > > Thanks, > > -Sundar > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, > Germany > Oracle is committed to developing > practices and products that help protect the environment > > From Joerg.Frantzius at aperto.com Wed Dec 9 09:28:13 2015 From: Joerg.Frantzius at aperto.com (=?utf-8?B?RnJhbnR6aXVzLCBKw7ZyZw==?=) Date: Wed, 9 Dec 2015 09:28:13 +0000 Subject: Keeping ScriptEngine per Thread? Message-ID: <5CCE216C-D34A-4FD2-BC99-3B70B41FCF60@aperto.com> Hi, we?re using Oracle JDK?s Nashorn in a web application, where it is used to render HTML markup in HTTP worker threads. I remember having read somewhere that the creation of a ScriptEngine (i.e. invocation of ScriptEngineFactory.getScriptEngine()) may have considerable performance overhead, so probably it should be avoided to do this with every incoming HTTP request. This is why we?ll go for keeping a ScriptEngine per thread in a ThreadLocal. On the other hand this may result in a large memory footprint, as there can be 200 HTTP worker threads, but we don?t have any experience with it yet. The ScriptEngineFactory.getParameter() Javadocs does list some interesting parameters for the key ?THREADING?, that seem to make it possible to have a singleton ScriptEngine instead, which could be used concurrently from multiple threads. However, I have no clue whether this is either supported by Nashorn, nor how to set this parameter on engine creation. Is there per chance some recommended usage pattern for ScriptEngine in a web server? Thanks for any insights, J?rg --- Dipl. Inf. J?rg von Frantzius, Technical Director E-Mail joerg.frantzius at aperto.com Phone +49 30 283921-0 Fax +49 30 283921-29 Aperto AG - In der Pianofabrik Chausseestra?e 5, D-10115 Berlin http://www.aperto.com http://www.facebook.com/aperto https://www.xing.com/companies/apertoag HRB 77049 B, AG Berlin Charlottenburg Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen, Daniel Simon Aufsichtsrat: Bernd Hardes (Vorsitzender) From sundararajan.athijegannathan at oracle.com Wed Dec 9 09:50:52 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 9 Dec 2015 15:20:52 +0530 Subject: 8144979: Context.fromClass should catch exception from Class.getClassLoader call In-Reply-To: References: <5667DEA8.8000303@oracle.com> Message-ID: <5667F97C.1070204@oracle.com> Hi, Inline comments below... On 12/9/2015 2:08 PM, Attila Szegedi wrote: > So? I presume the security exception only thrown when a SecurityManager is > present? Yes. But note that we run all the tests under a security manager (except for tests under "test/script/nosecurity" directory) > This is actually somewhat weird, especially since VM anonymous > classes should return their host class' loader as their loader. > getClassLoader() doc says > > If a security manager is present, and the caller's class loader is not null Well, for unknown reason, this fails in jake/nashorn - but not on jdk9-dev/nashorn. I'm trying to come up with a standalone test to reproduce it - but not successful so far. >> and the caller's class loader is not the same as or an ancestor of the >> class loader for the class whose class loader is requested, then this >> method calls the security manager's checkPermission method with a >> RuntimePermission("getClassLoader") permission > > I'd think that for Context.class.classLoader it is true that it is either > null or the ancestor of the script's class loader, is that not so? Nashorn's loader is extension loader. And it is ancestor of script loader. because script loader uses thread context loader as parent - and thread context loader's parent is extension loader in this case. > I'm just > trying to understand *why* can this SecurityException arise at all. As I said, tests are run under security manager and tests do fail in jake/nashorn without this change. As for the root cause, I/we need to understand by coming up with an independent test case (yet). This workaround fix is for two reasons: 1) Will make future jdk9-> jake merge would be clean (for this file/method) 2) When jake merges to jdk9 in future, we don't want failure in this part of code to disrupt nashorn test run. Because this is just an optimization (to get Context from loader instance). We should be able to get current Context from thread-local in any case. i.e., should not fail/disrupt test run for this reason. Thanks, -Sundar > Attila. > > > On Wed, Dec 9, 2015 at 9:20 AM, Michael Haupt > wrote: > >> Hi Sundar, >> >> lower-case thumbs up. >> >> One remark: I'm a bit concerned about the plethora of files involved with >> the dynalink samples. For each particular sample, there's a Java file, a >> sample JS file, and a linker JS file, where the linker compiles the Java >> file and assembles a JAR. The linkers all look pretty much the same. In my >> opinion, providing one script that takes care of compilation and JARring >> and is loaded from all actual samples would keep the samples more lean. >> >> Best, >> >> Michael >> >>> Am 09.12.2015 um 08:56 schrieb Sundararajan Athijegannathan < >> sundararajan.athijegannathan at oracle.com>: >>> Please review http://cr.openjdk.java.net/~sundar/8144979/ for >> https://bugs.openjdk.java.net/browse/JDK-8144979 >>> This fix is already in jake/nashorn. See also: >> https://bugs.openjdk.java.net/browse/JDK-8144568 >>> In addition, I've moved all dynalink samples to >> $nashorn/samples/dynalink directory and renamed the README. >>> Thanks, >>> -Sundar >> -- >> >> >> Dr. Michael Haupt | Principal Member of Technical Staff >> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >> Oracle Java Platform Group | LangTools Team | Nashorn >> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, >> Germany >> Oracle is committed to developing >> practices and products that help protect the environment >> >> From sundararajan.athijegannathan at oracle.com Wed Dec 9 09:55:37 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 9 Dec 2015 15:25:37 +0530 Subject: Keeping ScriptEngine per Thread? In-Reply-To: <5CCE216C-D34A-4FD2-BC99-3B70B41FCF60@aperto.com> References: <5CCE216C-D34A-4FD2-BC99-3B70B41FCF60@aperto.com> Message-ID: <5667FA99.6010108@oracle.com> One engine per worker thread would definitely work - this is maximum isolation. This mode even avoids sharing script classers / loaders. If that is not workable in your use-case, you can use a separate ENGINE_SCOPE bindings (or separate ScriptContext) per thread. This will separate ECMAScript globals to be thread specific. This mode allows for script Class (compiled/loaded script Class objects) to be shared -- but global state is not. This is partial sharing - but safe. If you do share the default ScriptContext of the script engine across threads, then it is up to you to take care of MT access/modification of globals -- you could still carefully structure code to run script functions in a such a way to avoid concurrent global modifications - but it'd be practically difficult. Hope this helps, -Sundar On 12/9/2015 2:58 PM, Frantzius, J?rg wrote: > Hi, > > we?re using Oracle JDK?s Nashorn in a web application, where it is used to render HTML markup in HTTP worker threads. > > I remember having read somewhere that the creation of a ScriptEngine (i.e. invocation of ScriptEngineFactory.getScriptEngine()) may have considerable performance overhead, so probably it should be avoided to do this with every incoming HTTP request. This is why we?ll go for keeping a ScriptEngine per thread in a ThreadLocal. > > On the other hand this may result in a large memory footprint, as there can be 200 HTTP worker threads, but we don?t have any experience with it yet. > > The ScriptEngineFactory.getParameter() Javadocs does list some interesting parameters for the key ?THREADING?, that seem to make it possible to have a singleton ScriptEngine instead, which could be used concurrently from multiple threads. However, I have no clue whether this is either supported by Nashorn, nor how to set this parameter on engine creation. > > Is there per chance some recommended usage pattern for ScriptEngine in a web server? > > Thanks for any insights, > J?rg > > > --- > > Dipl. Inf. J?rg von Frantzius, Technical Director > > E-Mail joerg.frantzius at aperto.com > > Phone +49 30 283921-0 > Fax +49 30 283921-29 > > Aperto AG - In der Pianofabrik > Chausseestra?e 5, D-10115 Berlin > http://www.aperto.com > http://www.facebook.com/aperto > https://www.xing.com/companies/apertoag > > HRB 77049 B, AG Berlin Charlottenburg > Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen, Daniel Simon > Aufsichtsrat: Bernd Hardes (Vorsitzender) > From Joerg.Frantzius at aperto.com Wed Dec 9 11:14:35 2015 From: Joerg.Frantzius at aperto.com (=?utf-8?B?RnJhbnR6aXVzLCBKw7ZyZw==?=) Date: Wed, 9 Dec 2015 11:14:35 +0000 Subject: Keeping ScriptEngine per Thread? In-Reply-To: <5667FA99.6010108@oracle.com> References: <5CCE216C-D34A-4FD2-BC99-3B70B41FCF60@aperto.com> <5667FA99.6010108@oracle.com> Message-ID: <80A0E9D9-3ABE-4979-A632-945D17BE0F43@aperto.com> Hi Sundar, thanks for your answer. So that seems to mean that ScriptEngine per se is thread-safe, and we can isolate threads by providing separate ScriptContexts. It?s good to know we can use a singleton ScriptEngine in case memory footprint turns out to be too big. Thx + regards, J?rg --- Dipl. Inf. J?rg von Frantzius, Technical Director E-Mail joerg.frantzius at aperto.com Phone +49 30 283921-0 Fax +49 30 283921-29 Aperto AG - In der Pianofabrik Chausseestra?e 5, D-10115 Berlin http://www.aperto.com http://www.facebook.com/aperto https://www.xing.com/companies/apertoag HRB 77049 B, AG Berlin Charlottenburg Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen, Daniel Simon Aufsichtsrat: Bernd Hardes (Vorsitzender) Am 09.12.2015 um 10:55 schrieb Sundararajan Athijegannathan >: One engine per worker thread would definitely work - this is maximum isolation. This mode even avoids sharing script classers / loaders. If that is not workable in your use-case, you can use a separate ENGINE_SCOPE bindings (or separate ScriptContext) per thread. This will separate ECMAScript globals to be thread specific. This mode allows for script Class (compiled/loaded script Class objects) to be shared -- but global state is not. This is partial sharing - but safe. If you do share the default ScriptContext of the script engine across threads, then it is up to you to take care of MT access/modification of globals -- you could still carefully structure code to run script functions in a such a way to avoid concurrent global modifications - but it'd be practically difficult. Hope this helps, -Sundar On 12/9/2015 2:58 PM, Frantzius, J?rg wrote: Hi, we?re using Oracle JDK?s Nashorn in a web application, where it is used to render HTML markup in HTTP worker threads. I remember having read somewhere that the creation of a ScriptEngine (i.e. invocation of ScriptEngineFactory.getScriptEngine()) may have considerable performance overhead, so probably it should be avoided to do this with every incoming HTTP request. This is why we?ll go for keeping a ScriptEngine per thread in a ThreadLocal. On the other hand this may result in a large memory footprint, as there can be 200 HTTP worker threads, but we don?t have any experience with it yet. The ScriptEngineFactory.getParameter() Javadocs does list some interesting parameters for the key ?THREADING?, that seem to make it possible to have a singleton ScriptEngine instead, which could be used concurrently from multiple threads. However, I have no clue whether this is either supported by Nashorn, nor how to set this parameter on engine creation. Is there per chance some recommended usage pattern for ScriptEngine in a web server? Thanks for any insights, J?rg --- Dipl. Inf. J?rg von Frantzius, Technical Director E-Mail joerg.frantzius at aperto.com Phone +49 30 283921-0 Fax +49 30 283921-29 Aperto AG - In der Pianofabrik Chausseestra?e 5, D-10115 Berlin http://www.aperto.com http://www.facebook.com/aperto https://www.xing.com/companies/apertoag HRB 77049 B, AG Berlin Charlottenburg Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen, Daniel Simon Aufsichtsrat: Bernd Hardes (Vorsitzender) From sundararajan.athijegannathan at oracle.com Wed Dec 9 11:33:24 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 9 Dec 2015 17:03:24 +0530 Subject: Sharing native JavaScript objects across contexts Message-ID: <56681184.6060501@oracle.com> This is in response to http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005690.html [ I accidentally deleted the original email ] Yes, objects from other ScriptContexts are indeed foreign - but nashorn allows you to call functions, access properties and so on.And even when you're using multiple ScriptContexts in the same engine -- compiled Classes (java.lang.Class instances) are shared. i.e., so long as you use same script, Nashorn will re-use Class objects. i.e., compiled code sharing is on per-engine basis. So, you can eval "common code" again and again -- you'll be re-using same Class object. You don't share ECMAScript global objects (which are in ENGINE_SCOPE of the ScriptContexts you use) -- but that is only about objects including function objects. But you still share nashorn compiled code -- so long as you use the same script engine instance. Hope that answers your concerns, -Sundar From szegedia at gmail.com Wed Dec 9 12:11:26 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 9 Dec 2015 13:11:26 +0100 Subject: 8144979: Context.fromClass should catch exception from Class.getClassLoader call In-Reply-To: <5667F97C.1070204@oracle.com> References: <5667DEA8.8000303@oracle.com> <5667F97C.1070204@oracle.com> Message-ID: <0F29E45A-3EB7-46F0-AE6D-868E0BEACD76@gmail.com> Thanks for the response; basically we don't have an understanding about the cause of the exception in the modular world then. I wonder if we could bother Jigsaw folks with this. They do seem to be quite busy on the mailing lists these days :-) +1 on the change - it's not harmful by any means and makes the code more robust. As you said, dereferencing the class loader is just an optimization. Attila. > On Dec 9, 2015, at 10:50 AM, Sundararajan Athijegannathan wrote: > > Hi, > > Inline comments below... > > > On 12/9/2015 2:08 PM, Attila Szegedi wrote: >> So? I presume the security exception only thrown when a SecurityManager is >> present? > > Yes. But note that we run all the tests under a security manager (except for tests under "test/script/nosecurity" directory) > >> This is actually somewhat weird, especially since VM anonymous >> classes should return their host class' loader as their loader. >> getClassLoader() doc says >> >> If a security manager is present, and the caller's class loader is not null > > Well, for unknown reason, this fails in jake/nashorn - but not on jdk9-dev/nashorn. I'm trying to come up with a standalone test to reproduce it - but not > successful so far. >>> and the caller's class loader is not the same as or an ancestor of the >>> class loader for the class whose class loader is requested, then this >>> method calls the security manager's checkPermission method with a >>> RuntimePermission("getClassLoader") permission >> >> I'd think that for Context.class.classLoader it is true that it is either >> null or the ancestor of the script's class loader, is that not so? > > Nashorn's loader is extension loader. And it is ancestor of script loader. because script loader uses thread context loader as parent - and thread context loader's parent is extension loader in this case. > > >> I'm just >> trying to understand *why* can this SecurityException arise at all. > > As I said, tests are run under security manager and tests do fail in jake/nashorn without this change. As for the root cause, I/we need to understand by coming up with an independent test case (yet). > This workaround fix is for two reasons: > > 1) Will make future jdk9-> jake merge would be clean (for this file/method) > 2) When jake merges to jdk9 in future, we don't want failure in this part of code to disrupt nashorn test run. Because this is just an optimization (to get Context from loader instance). We should be able > to get current Context from thread-local in any case. i.e., should not fail/disrupt test run for this reason. > > Thanks, > -Sundar > >> Attila. >> >> >> On Wed, Dec 9, 2015 at 9:20 AM, Michael Haupt >> wrote: >> >>> Hi Sundar, >>> >>> lower-case thumbs up. >>> >>> One remark: I'm a bit concerned about the plethora of files involved with >>> the dynalink samples. For each particular sample, there's a Java file, a >>> sample JS file, and a linker JS file, where the linker compiles the Java >>> file and assembles a JAR. The linkers all look pretty much the same. In my >>> opinion, providing one script that takes care of compilation and JARring >>> and is loaded from all actual samples would keep the samples more lean. >>> >>> Best, >>> >>> Michael >>> >>>> Am 09.12.2015 um 08:56 schrieb Sundararajan Athijegannathan < >>> sundararajan.athijegannathan at oracle.com>: >>>> Please review http://cr.openjdk.java.net/~sundar/8144979/ for >>> https://bugs.openjdk.java.net/browse/JDK-8144979 >>>> This fix is already in jake/nashorn. See also: >>> https://bugs.openjdk.java.net/browse/JDK-8144568 >>>> In addition, I've moved all dynalink samples to >>> $nashorn/samples/dynalink directory and renamed the README. >>>> Thanks, >>>> -Sundar >>> -- >>> >>> >>> Dr. Michael Haupt | Principal Member of Technical Staff >>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561 >>> Oracle Java Platform Group | LangTools Team | Nashorn >>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, >>> Germany >>> Oracle is committed to developing >>> practices and products that help protect the environment >>> >>> > From james.laskey at oracle.com Wed Dec 9 12:40:10 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 9 Dec 2015 08:40:10 -0400 Subject: Nashorn webview issue In-Reply-To: References: Message-ID: <8DED599F-72E1-487A-BF4B-2DA1FF93985E@oracle.com> Which version of jjs are you using? (jjs -version) ? Jim > On Dec 1, 2015, at 1:11 AM, Chris Root wrote: > > I'm trying to get two way communication working for a browser project in > Nashorn and I'm having trouble implementing an HTML to host callback. I > tried this in Java using setMember and it works perfectly, but I can't seem > to duplicate it with Nashorn. Since using setMember didn't work I decided > to use the approach below but still no luck. > > I don't want to pick up objects from the window object, I want to plant a > function in window that will call Nashorn code. Again getting this to work > in Java was no problem. I followed the instructions on this page > > https://blogs.oracle.com/nashorn/entry/porting_from_the_browser_to > > I have the jsObject wrapper shown in the article and it works fine. but the > code below doesn't work. This is the relevant snip from the load handler. > > This.engine.loadWorker.stateProperty().addListener(new ChangeListener() { > changed: function(value, oldState, newState) { > switch(newState){ > case Worker.State.SUCCEEDED: > This.document = wrap(This.engine.executeScript("document")); > This.window = wrap(This.engine.executeScript("window")); > This.window.hello = function(){ > This.hello(); > } > > As you can see I planted a function on the window called hello, which calls > a method of the webview wrapper (same wrapper as in the article) called > hello() > > This.hello = function(){ > print("****** hello it worked *******"); > } > > I then set up the alert handler > > This.engine.onAlert = new javafx.event.EventHandler() { > handle: function(evt) { > print(evt.data) > } > }; > > and then finally loaded the HTML file below into the webview. > > > > Nashorn Browser > > > > > > Say Hello > > > > What I get back in the console is. > > JavaRuntimeObject is not a function (evaluating 'window.hello()') > > Is there any way to establish a callback into my Nashorn code the way it > can be done in Java? From sundararajan.athijegannathan at oracle.com Wed Dec 9 12:52:32 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 9 Dec 2015 18:22:32 +0530 Subject: Nashorn webview issue In-Reply-To: <8DED599F-72E1-487A-BF4B-2DA1FF93985E@oracle.com> References: <8DED599F-72E1-487A-BF4B-2DA1FF93985E@oracle.com> Message-ID: <56682410.1060701@oracle.com> Are you using any JSAdapter over netscape.javascript.JSObject instances? If so, that is no longer needed! Nashorn natively supports Browser JSObjects - you can access properties/functions from JSObjects directly. Also you can pass nashorn functions (or assign callbacks). See for example: http://hg.openjdk.java.net/jdk9/dev/nashorn/file/c779bd47d648/samples/browser_dom.js -Sundar On 12/9/2015 6:10 PM, Jim Laskey (Oracle) wrote: > Which version of jjs are you using? (jjs -version) > > ? Jim > > >> On Dec 1, 2015, at 1:11 AM, Chris Root wrote: >> >> I'm trying to get two way communication working for a browser project in >> Nashorn and I'm having trouble implementing an HTML to host callback. I >> tried this in Java using setMember and it works perfectly, but I can't seem >> to duplicate it with Nashorn. Since using setMember didn't work I decided >> to use the approach below but still no luck. >> >> I don't want to pick up objects from the window object, I want to plant a >> function in window that will call Nashorn code. Again getting this to work >> in Java was no problem. I followed the instructions on this page >> >> https://blogs.oracle.com/nashorn/entry/porting_from_the_browser_to >> >> I have the jsObject wrapper shown in the article and it works fine. but the >> code below doesn't work. This is the relevant snip from the load handler. >> >> This.engine.loadWorker.stateProperty().addListener(new ChangeListener() { >> changed: function(value, oldState, newState) { >> switch(newState){ >> case Worker.State.SUCCEEDED: >> This.document = wrap(This.engine.executeScript("document")); >> This.window = wrap(This.engine.executeScript("window")); >> This.window.hello = function(){ >> This.hello(); >> } >> >> As you can see I planted a function on the window called hello, which calls >> a method of the webview wrapper (same wrapper as in the article) called >> hello() >> >> This.hello = function(){ >> print("****** hello it worked *******"); >> } >> >> I then set up the alert handler >> >> This.engine.onAlert = new javafx.event.EventHandler() { >> handle: function(evt) { >> print(evt.data) >> } >> }; >> >> and then finally loaded the HTML file below into the webview. >> >> >> >> Nashorn Browser >> >> >> >> >> >> Say Hello >> >> >> >> What I get back in the console is. >> >> JavaRuntimeObject is not a function (evaluating 'window.hello()') >> >> Is there any way to establish a callback into my Nashorn code the way it >> can be done in Java? From sundararajan.athijegannathan at oracle.com Thu Dec 10 07:49:40 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 10 Dec 2015 13:19:40 +0530 Subject: 8144979: Context.fromClass should catch exception from Class.getClassLoader call Message-ID: <56692E94.1020301@oracle.com> This is in response to http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005699.html Found the root cause of difference in behavior between "jake/jigsaw" and "jdk9-dev". Filed: https://bugs.openjdk.java.net/browse/JDK-8145070 Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Fri Dec 11 13:31:54 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 11 Dec 2015 19:01:54 +0530 Subject: RFR 8145186: jjs package completion should have a fallback when javac is not available Message-ID: <566AD04A.3090105@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8145186/ for https://bugs.openjdk.java.net/browse/JDK-8145186 Thanks, -Sundar From hannes.wallnoefer at oracle.com Fri Dec 11 14:11:26 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 11 Dec 2015 15:11:26 +0100 Subject: RFR 8145186: jjs package completion should have a fallback when javac is not available In-Reply-To: <566AD04A.3090105@oracle.com> References: <566AD04A.3090105@oracle.com> Message-ID: <566AD98E.2000003@oracle.com> +1 "atleast" should be two words (in a comment) Hannes Am 2015-12-11 um 14:31 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8145186/ for > https://bugs.openjdk.java.net/browse/JDK-8145186 > > Thanks, > -Sundar From michael.haupt at oracle.com Fri Dec 11 14:12:42 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 11 Dec 2015 15:12:42 +0100 Subject: RFR 8145186: jjs package completion should have a fallback when javac is not available In-Reply-To: <566AD04A.3090105@oracle.com> References: <566AD04A.3090105@oracle.com> Message-ID: <6C44F24B-C827-49A3-8B2B-E21EF01914FA@oracle.com> Hi Sundar, lower-case thumbs up. Best, Michael > Am 11.12.2015 um 14:31 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8145186/ for https://bugs.openjdk.java.net/browse/JDK-8145186 > > Thanks, > -Sundar -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Fri Dec 11 14:36:06 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 11 Dec 2015 20:06:06 +0530 Subject: RFR 8145186: jjs package completion should have a fallback when javac is not available In-Reply-To: <566AD98E.2000003@oracle.com> References: <566AD04A.3090105@oracle.com> <566AD98E.2000003@oracle.com> Message-ID: <566ADF56.1050205@oracle.com> Will fix comment and push it. Thanks, -Sundar On 12/11/2015 7:41 PM, Hannes Wallnoefer wrote: > +1 > > "atleast" should be two words (in a comment) > > Hannes > > Am 2015-12-11 um 14:31 schrieb Sundararajan Athijegannathan: >> Please review http://cr.openjdk.java.net/~sundar/8145186/ for >> https://bugs.openjdk.java.net/browse/JDK-8145186 >> >> Thanks, >> -Sundar > From hannes.wallnoefer at oracle.com Fri Dec 11 15:08:02 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 11 Dec 2015 16:08:02 +0100 Subject: Use of long in Nashorn In-Reply-To: <566409FD.7030804@oracle.com> References: <5645ADD8.9060906@oracle.com> <8373DB71-DC4C-40E0-BD0C-3910108A6BD5@oracle.com> <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> <5661B0DA.706@oracle.com> <0B1CADAA-F45E-48FB-8974-13C72D120B13@gmail.com> <566409FD.7030804@oracle.com> Message-ID: <566AE6D2.6060107@oracle.com> I uploaded a new webrev that includes most of the changes you suggested. Conversion of long[] from Java now works without losing precision, using int, double, or Object arrays. I also added a test for this. http://cr.openjdk.java.net/~hannesw/8144020/webrev.01/ I didn't implement the int/double overloading of array iterator actions. Unless I missed something, I would have to implement two forEach methods in each subclass, which seem ugly and error prone. Additionally, I removed the ArrayData.set method that takes a long value, something I had overlooked in my previous patch. Hannes Am 2015-12-06 um 11:12 schrieb Hannes Wallnoefer: > Thanks for the quick review, Attila. Answers inline. > > Am 2015-12-04 um 18:39 schrieb Attila Szegedi: >> * In CodeGenerator SHR implementations (both self-assign and >> ordinary) you have method.shr() in loadStack instead of consumeStack. >> I was actually staring at this for a while as it seemed wrong to >> perform an operation in loadStack, but in the end I decided it?s okay >> like this. After all, it?s the toUint32 that?s the optimistic part >> here, so this should be fine indeed. I think we had a JIRA issue >> saying ?make SHR optimistic? but I can?t find it now. If it pops up, >> we can mark it as a duplicate of this one. > > I've looked for that Jira issue but didn't find it either. > >> * I see "assert storeType != Type.LONG;? do we even need Type.LONG >> and LongType class anymore? > > That assert is a leftover from the conversion process, it shouldn't be > needed anymore. We do still use Type.LONG for creating and handling > the primitive fields and spill slots with dual fields. That's why I > had to keep it. > >> * Symbol.java: you could reclaim the HAS_LONG_VALUE bit by shifting >> the rest down by one > > Will do. >> >> * optimization idea: have versions of callback invokers in >> NativeArray.java for both int and double indices. Since we know the >> length of the array when we enter forEach etc. we could select the >> double version when length > maxint and the int version otherwise. >> Actually, we could even have IteratorAction.forEach be overloaded for >> int and double, and write the body of IteratorAction.apply() to start >> out with the int version, and when the index crosses maxint start >> calling the double version (so even for large arrays we?ll iterate >> calling int specialization of functions for the cases where it?s >> short circuited). > > Nice idea, and should be easy to implement. I'll try it out. >> >> * array length: could we still have Nashorn APIs that return long? >> Optimistic filters will deal with these appropriately, won?t they? I >> guess they should since they also need to be able to handle return >> values from POJO methods that return long (e.g. >> System.currentTimeMillis()). Hence, you could have NativeArray.length >> return ?long? and let the optimistic machinery decide whether to cast >> it as int or double. That would allow you to not have to box the >> return value of NativeArray.length. > > Yes, we could have things returning long, but it will deoptimize to > Object. OptimisticReturnFilters (which do the runtime checks) are not > used for ScriptObject properties. > >> * NativeNumber: unused import? > Fixed. > >> *Unit32ArrayData: getBoxedElementType went from INTEGER to DOUBLE. >> I?m not sure I understand that. I mean, was INTEGER incorrect before? > > That obviously has been incorrect before. Actually, that method is > only used in NativeArray#concat and will never be invoked on typed > arrays. Looking at that NativeArray#concat method it looks a bit fishy > to me, assuming all NativeArrays use ContinuousArrayData. I have to > investigate further on this. > > Back to the issue at hand, int.class/Integer.class is definitely wrong > for element type for Uint32. When returning int.class in > getElementType, optimistic code that uses optimstic int getter gets > incredibly slow when actually deoptimizing to double, because we keep > trying to handle elements as ints. (I had this in my code at one time > and found pdfjs slowed down to a crawl when changing the optimistic > int getter to always deoptimize to double.) > > Probably getBoxedElementType should just be a final method instead of > abstract in ContinuousArrayData and convert getElementType to boxed > counterpart on the fly. > > >> >> * You didn?t remove LongArrayData.java? > > I think I did: > http://cr.openjdk.java.net/~hannesw/8144020/webrev.00/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/LongArrayData.java.patch >> >> * It looks like long[] arrays can now lose precision if passed >> through Java.from(), E.g. if you have Java methods ?long[] >> getLongArray()? and ?void setLongArray(long[] arr)? then >> pojo.setLongArray(Java.from(pojo.getLongArray()) will lose precision >> because NativeJava.copyArray(long[]) produces double[]. Of course, we >> could argue that this is expected behavior if you explicitly use >> Java.from. Just passing around and manipulating a raw long[] won?t >> have that effect (although it?d be good to confirm that in test), it >> requires an explicit Java.from(). Still, I wonder if it?d make sense >> to have copyArray(long[]) either return Object[] or choose >> dynamically between double[] and Object[] based on the maximum >> magnitude of an element (you can start with double[] and reallocate >> as Object[] when you bump into a large long). > Good catch. I'll see if I can use existing code in ArrayData to > convert to the narrowest array type. > > Thanks! > > Hannes > >> Other than that: great work! Nice to see large swaths of code removed. >> >> Attila. >> >>> On Dec 4, 2015, at 4:27 PM, Hannes Wallnoefer >>> wrote: >>> >>> After receiving another long/precision related bug last week I >>> decided to go ahead with the removal of longs in Nashorn. It's been >>> quite an effort, but I think it looks good now. Below are the links >>> to the webrev and Jira issue. >>> >>> http://cr.openjdk.java.net/~hannesw/8144020/ >>> https://bugs.openjdk.java.net/browse/JDK-8144020 >>> >>> This is a rather big patch, but it mostly removes code. There are >>> over 2000 deletions vs. 400 insertions. I removed all uses of long >>> in our code where it represented JS numbers, including ScriptObject >>> property accessors with longs as key or value, and the LongArrayData >>> class. With this, all JS numbers are represented as int or double in >>> Nashorn. Longs will not "naturally" occur anymore and only be >>> present as java.lang.Long instances. >>> >>> As expected, the areas that demanded special care were those where >>> ES prescribes use of uint32. These are mostly unsigned right shift, >>> Uint32Array elements, and the length property of arrays. For right >>> shift and Uint32Array elements, I added optimistic implementations >>> that return int if possible and deoptimize to double. Pdfjs and >>> mandreel are benchmarks that make use of these features, and I >>> didn't notice any observable impact on performance. Even when I >>> simulated fallback to double performance was still ok (previously >>> reported performance regressions for this case were in fact caused >>> by an error of mine). >>> >>> For the Array length property, I changed the getter in NativeArray >>> to return int or double depending on actual value. Previously, the >>> length getter always returned long. Since the property is actually >>> evaluated by OptimisticTypesCalculator, for-loops with an array >>> length as limit now use ints instead of longs to iterate through >>> array indices, which is probably a good thing. >>> >>> As for longs returned by Java code, their value is always preserved. >>> Only when they are used for JS math they will be converted to double >>> as prescribed by ECMA. When running with optimistic types we check >>> if a long fits into an int or double to avoid deoptimization to >>> object. Previously we did this only when converting long to >>> optimistic int, but optimistic double did not use any return filter >>> for longs, so a long returned for an optimistic double could easily >>> lose precision. >>> >>> You can find the related changes in OptimisticReturnFilters.java. I >>> also added tests to make sure long values are preserved in various >>> optimistic and non-optimstic contexts, some of which would have >>> previously fail. >>> >>> In a previous version of this patch it included functionality to >>> only treat ints and doubles or their wrapper objects as native JS >>> numbers (e.g. you could invoke Number.prototype methods only on ints >>> and doubles). However, this is a quite a hairy issue and I reckoned >>> the patch is large enough without it, so I pulled it out and will >>> fix this separately as JDK-8143896. >>> >>> I've testing and refining this patch for the last few days and think >>> it looks pretty good. I thought it was a good idea to discuss this >>> to this existing thread before posting a review request. Please let >>> me know what you think. >>> >>> Thanks, >>> Hannes >>> >>> >>> Am 2015-11-13 um 15:06 schrieb Attila Szegedi: >>>> Well, we could just box them in that case. If we only used int and >>>> double as primitive number types internally, then a natural >>>> representation for a long becomes Long. Java methods returning long >>>> could have an optimistic filter that first checks if the value fits >>>> in an int (32-bit signed), then in a double (53-bit signed) without >>>> loss of precision, and finally deoptimizes to Object and uses Long. >>>> int->long->double->Object becomes int->double->Object, with longs >>>> of too large magnitude becoming boxed. >>>> >>>> Attila. >>>> >>>>> On Nov 13, 2015, at 2:46 PM, Jim Laskey >>>>> (Oracle) wrote: >>>>> >>>>> The main thing to watch for here is that longs/Longs need to >>>>> survive unobstructed between Java calls. Remember we ran into >>>>> trouble in this area (loss of precision when using longs for >>>>> encoding.) >>>>> >>>>> >>>>> >>>>> >>>>>> On Nov 13, 2015, at 8:26 AM, Attila >>>>>> Szegedi wrote: >>>>>> >>>>>>> On Nov 13, 2015, at 10:31 AM, Hannes >>>>>>> Wallnoefer wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I'm currently questioning our use of longs to represent numbers >>>>>>> in combination with optimistic typing. >>>>>> I often feel that the presence of longs is more hassle than >>>>>> they?re worth. I?d be all for eliminating them. >>>>>> >>>>>>> After all, there's a pretty large range where long arithmetic >>>>>>> will be more precise than the doubles required by ECMA. >>>>>> There?s currently several different places in Nashorn where we >>>>>> try to confine the precision of longs to 53 bits (so they aren?t >>>>>> more precise than doubles). It?s a bit of a whack-a-mole where >>>>>> you can?t always be sure whether you found all instances. >>>>>> >>>>>>> For context see this bug, especially the last two comments (the >>>>>>> original bug was about number to string conversion which has >>>>>>> been solved in the meantime): >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065910 >>>>>>> >>>>>>> So the question is: can we use longs at all and be confident >>>>>>> that results won't be too precise (and thus, strictly speaking, >>>>>>> incorrect)? >>>>>> Internally, the longs are also used for representing UInt32 even >>>>>> in non-optimistic setting, which is only really significant for >>>>>> the >>> operator and array indices and lengths; maybe we should >>>>>> limit longs to that usage only, or even just use doubles >>>>>> internally for UInt32 values that can?t be represented as Int32. >>>>>> FWIW, even for the >>> operator we only need it when shifting by >>>>>> zero, as in every other case the result will have the topmost bit >>>>>> set to 0 and thus fit in Int32 too. >>>>>> >>>>>> I guess once Valhalla rolls around, we could easily have an >>>>>> unsigned 32 bit int type. >>>>>> >>>>>>> Hannes >>>>>> Attila. >>>>>> > From hannes.wallnoefer at oracle.com Fri Dec 11 15:15:46 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 11 Dec 2015 16:15:46 +0100 Subject: Review request for JDK-8144020: Remove long as an internal numeric type Message-ID: <566AE8A2.5010708@oracle.com> Please review JDK-8144020: Remove long as an internal numeric type: http://cr.openjdk.java.net/~hannesw/8144020/webrev.01/ Attila already reviewed a previous version of this patch: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005669.html This version contains most of the changes he suggested. Thanks, Hannes From szegedia at gmail.com Fri Dec 11 15:21:13 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 11 Dec 2015 16:21:13 +0100 Subject: Use of long in Nashorn In-Reply-To: <566AE6D2.6060107@oracle.com> References: <5645ADD8.9060906@oracle.com> <8373DB71-DC4C-40E0-BD0C-3910108A6BD5@oracle.com> <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> <5661B0DA.706@oracle.com> <0B1CADAA-F45E-48FB-8974-13C72D120B13@gmail.com> <566409FD.7030804@oracle.com> <566AE6D2.6060107@oracle.com> Message-ID: On Dec 11, 2015, at 4:08 PM, Hannes Wallnoefer wrote: > > I uploaded a new webrev that includes most of the changes you suggested. Conversion of long[] from Java now works without losing precision, using int, double, or Object arrays. I also added a test for this. > > http://cr.openjdk.java.net/~hannesw/8144020/webrev.01/ +1 on all changes. > I didn't implement the int/double overloading of array iterator actions. Unless I missed something, I would have to implement two forEach methods in each subclass, which seem ugly and error prone. You haven?t missed anything; that?s exactly how that would work. Ultimately, if we had macros in Java, this wouldn?t need to look ugly, but we don?t have them, so? Performance optimizations are sometimes ugly :-) Anyway, this needn?t happen now, although ultimately I don?t think it?d be much of a big deal to implement, even with the unfortunate code duplication, and we still wouldn?t always force-promote the parameter type for the callback functions to double. > Additionally, I removed the ArrayData.set method that takes a long value, something I had overlooked in my previous patch. > > Hannes Attila. > > Am 2015-12-06 um 11:12 schrieb Hannes Wallnoefer: >> Thanks for the quick review, Attila. Answers inline. >> >> Am 2015-12-04 um 18:39 schrieb Attila Szegedi: >>> * In CodeGenerator SHR implementations (both self-assign and ordinary) you have method.shr() in loadStack instead of consumeStack. I was actually staring at this for a while as it seemed wrong to perform an operation in loadStack, but in the end I decided it?s okay like this. After all, it?s the toUint32 that?s the optimistic part here, so this should be fine indeed. I think we had a JIRA issue saying ?make SHR optimistic? but I can?t find it now. If it pops up, we can mark it as a duplicate of this one. >> >> I've looked for that Jira issue but didn't find it either. >> >>> * I see "assert storeType != Type.LONG;? do we even need Type.LONG and LongType class anymore? >> >> That assert is a leftover from the conversion process, it shouldn't be needed anymore. We do still use Type.LONG for creating and handling the primitive fields and spill slots with dual fields. That's why I had to keep it. >> >>> * Symbol.java: you could reclaim the HAS_LONG_VALUE bit by shifting the rest down by one >> >> Will do. >>> >>> * optimization idea: have versions of callback invokers in NativeArray.java for both int and double indices. Since we know the length of the array when we enter forEach etc. we could select the double version when length > maxint and the int version otherwise. Actually, we could even have IteratorAction.forEach be overloaded for int and double, and write the body of IteratorAction.apply() to start out with the int version, and when the index crosses maxint start calling the double version (so even for large arrays we?ll iterate calling int specialization of functions for the cases where it?s short circuited). >> >> Nice idea, and should be easy to implement. I'll try it out. >>> >>> * array length: could we still have Nashorn APIs that return long? Optimistic filters will deal with these appropriately, won?t they? I guess they should since they also need to be able to handle return values from POJO methods that return long (e.g. System.currentTimeMillis()). Hence, you could have NativeArray.length return ?long? and let the optimistic machinery decide whether to cast it as int or double. That would allow you to not have to box the return value of NativeArray.length. >> >> Yes, we could have things returning long, but it will deoptimize to Object. OptimisticReturnFilters (which do the runtime checks) are not used for ScriptObject properties. >> >>> * NativeNumber: unused import? >> Fixed. >> >>> *Unit32ArrayData: getBoxedElementType went from INTEGER to DOUBLE. I?m not sure I understand that. I mean, was INTEGER incorrect before? >> >> That obviously has been incorrect before. Actually, that method is only used in NativeArray#concat and will never be invoked on typed arrays. Looking at that NativeArray#concat method it looks a bit fishy to me, assuming all NativeArrays use ContinuousArrayData. I have to investigate further on this. >> >> Back to the issue at hand, int.class/Integer.class is definitely wrong for element type for Uint32. When returning int.class in getElementType, optimistic code that uses optimstic int getter gets incredibly slow when actually deoptimizing to double, because we keep trying to handle elements as ints. (I had this in my code at one time and found pdfjs slowed down to a crawl when changing the optimistic int getter to always deoptimize to double.) >> >> Probably getBoxedElementType should just be a final method instead of abstract in ContinuousArrayData and convert getElementType to boxed counterpart on the fly. >> >> >>> >>> * You didn?t remove LongArrayData.java? >> >> I think I did: http://cr.openjdk.java.net/~hannesw/8144020/webrev.00/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/LongArrayData.java.patch >>> >>> * It looks like long[] arrays can now lose precision if passed through Java.from(), E.g. if you have Java methods ?long[] getLongArray()? and ?void setLongArray(long[] arr)? then pojo.setLongArray(Java.from(pojo.getLongArray()) will lose precision because NativeJava.copyArray(long[]) produces double[]. Of course, we could argue that this is expected behavior if you explicitly use Java.from. Just passing around and manipulating a raw long[] won?t have that effect (although it?d be good to confirm that in test), it requires an explicit Java.from(). Still, I wonder if it?d make sense to have copyArray(long[]) either return Object[] or choose dynamically between double[] and Object[] based on the maximum magnitude of an element (you can start with double[] and reallocate as Object[] when you bump into a large long). >> Good catch. I'll see if I can use existing code in ArrayData to convert to the narrowest array type. >> >> Thanks! >> >> Hannes >> >>> Other than that: great work! Nice to see large swaths of code removed. >>> >>> Attila. >>> >>>> On Dec 4, 2015, at 4:27 PM, Hannes Wallnoefer wrote: >>>> >>>> After receiving another long/precision related bug last week I decided to go ahead with the removal of longs in Nashorn. It's been quite an effort, but I think it looks good now. Below are the links to the webrev and Jira issue. >>>> >>>> http://cr.openjdk.java.net/~hannesw/8144020/ >>>> https://bugs.openjdk.java.net/browse/JDK-8144020 >>>> >>>> This is a rather big patch, but it mostly removes code. There are over 2000 deletions vs. 400 insertions. I removed all uses of long in our code where it represented JS numbers, including ScriptObject property accessors with longs as key or value, and the LongArrayData class. With this, all JS numbers are represented as int or double in Nashorn. Longs will not "naturally" occur anymore and only be present as java.lang.Long instances. >>>> >>>> As expected, the areas that demanded special care were those where ES prescribes use of uint32. These are mostly unsigned right shift, Uint32Array elements, and the length property of arrays. For right shift and Uint32Array elements, I added optimistic implementations that return int if possible and deoptimize to double. Pdfjs and mandreel are benchmarks that make use of these features, and I didn't notice any observable impact on performance. Even when I simulated fallback to double performance was still ok (previously reported performance regressions for this case were in fact caused by an error of mine). >>>> >>>> For the Array length property, I changed the getter in NativeArray to return int or double depending on actual value. Previously, the length getter always returned long. Since the property is actually evaluated by OptimisticTypesCalculator, for-loops with an array length as limit now use ints instead of longs to iterate through array indices, which is probably a good thing. >>>> >>>> As for longs returned by Java code, their value is always preserved. Only when they are used for JS math they will be converted to double as prescribed by ECMA. When running with optimistic types we check if a long fits into an int or double to avoid deoptimization to object. Previously we did this only when converting long to optimistic int, but optimistic double did not use any return filter for longs, so a long returned for an optimistic double could easily lose precision. >>>> >>>> You can find the related changes in OptimisticReturnFilters.java. I also added tests to make sure long values are preserved in various optimistic and non-optimstic contexts, some of which would have previously fail. >>>> >>>> In a previous version of this patch it included functionality to only treat ints and doubles or their wrapper objects as native JS numbers (e.g. you could invoke Number.prototype methods only on ints and doubles). However, this is a quite a hairy issue and I reckoned the patch is large enough without it, so I pulled it out and will fix this separately as JDK-8143896. >>>> >>>> I've testing and refining this patch for the last few days and think it looks pretty good. I thought it was a good idea to discuss this to this existing thread before posting a review request. Please let me know what you think. >>>> >>>> Thanks, >>>> Hannes >>>> >>>> >>>> Am 2015-11-13 um 15:06 schrieb Attila Szegedi: >>>>> Well, we could just box them in that case. If we only used int and double as primitive number types internally, then a natural representation for a long becomes Long. Java methods returning long could have an optimistic filter that first checks if the value fits in an int (32-bit signed), then in a double (53-bit signed) without loss of precision, and finally deoptimizes to Object and uses Long. int->long->double->Object becomes int->double->Object, with longs of too large magnitude becoming boxed. >>>>> >>>>> Attila. >>>>> >>>>>> On Nov 13, 2015, at 2:46 PM, Jim Laskey (Oracle) wrote: >>>>>> >>>>>> The main thing to watch for here is that longs/Longs need to survive unobstructed between Java calls. Remember we ran into trouble in this area (loss of precision when using longs for encoding.) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Nov 13, 2015, at 8:26 AM, Attila Szegedi wrote: >>>>>>> >>>>>>>> On Nov 13, 2015, at 10:31 AM, Hannes Wallnoefer wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I'm currently questioning our use of longs to represent numbers in combination with optimistic typing. >>>>>>> I often feel that the presence of longs is more hassle than they?re worth. I?d be all for eliminating them. >>>>>>> >>>>>>>> After all, there's a pretty large range where long arithmetic will be more precise than the doubles required by ECMA. >>>>>>> There?s currently several different places in Nashorn where we try to confine the precision of longs to 53 bits (so they aren?t more precise than doubles). It?s a bit of a whack-a-mole where you can?t always be sure whether you found all instances. >>>>>>> >>>>>>>> For context see this bug, especially the last two comments (the original bug was about number to string conversion which has been solved in the meantime): >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065910 >>>>>>>> >>>>>>>> So the question is: can we use longs at all and be confident that results won't be too precise (and thus, strictly speaking, incorrect)? >>>>>>> Internally, the longs are also used for representing UInt32 even in non-optimistic setting, which is only really significant for the >>> operator and array indices and lengths; maybe we should limit longs to that usage only, or even just use doubles internally for UInt32 values that can?t be represented as Int32. FWIW, even for the >>> operator we only need it when shifting by zero, as in every other case the result will have the topmost bit set to 0 and thus fit in Int32 too. >>>>>>> >>>>>>> I guess once Valhalla rolls around, we could easily have an unsigned 32 bit int type. >>>>>>> >>>>>>>> Hannes >>>>>>> Attila. >>>>>>> >> > From hannes.wallnoefer at oracle.com Fri Dec 11 15:30:20 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 11 Dec 2015 16:30:20 +0100 Subject: Use of long in Nashorn In-Reply-To: References: <5645ADD8.9060906@oracle.com> <8373DB71-DC4C-40E0-BD0C-3910108A6BD5@oracle.com> <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> <5661B0DA.706@oracle.com> <0B1CADAA-F45E-48FB-8974-13C72D120B13@gmail.com> <566409FD.7030804@oracle.com> <566AE6D2.6060107@oracle.com> Message-ID: <566AEC0C.60307@oracle.com> Am 2015-12-11 um 16:21 schrieb Attila Szegedi: > On Dec 11, 2015, at 4:08 PM, Hannes Wallnoefer wrote: > >> I didn't implement the int/double overloading of array iterator actions. Unless I missed something, I would have to implement two forEach methods in each subclass, which seem ugly and error prone. > You haven?t missed anything; that?s exactly how that would work. Ultimately, if we had macros in Java, this wouldn?t need to look ugly, but we don?t have them, so? Performance optimizations are sometimes ugly :-) Anyway, this needn?t happen now, although ultimately I don?t think it?d be much of a big deal to implement, even with the unfortunate code duplication, and we still wouldn?t always force-promote the parameter type for the callback functions to double. > Ok, you convinced me. I'll add that optimization an upcoming webrev. Still waiting for other reviews though. Hannes From sundararajan.athijegannathan at oracle.com Mon Dec 14 07:36:05 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 14 Dec 2015 13:06:05 +0530 Subject: Review request for JDK-8144020: Remove long as an internal numeric type In-Reply-To: <566AE8A2.5010708@oracle.com> References: <566AE8A2.5010708@oracle.com> Message-ID: <566E7165.5080203@oracle.com> +1 Nice code deletion ! Minor: * copyright year in the new test LongProvider.java is 2014 -Sundar On 12/11/2015 8:45 PM, Hannes Wallnoefer wrote: > Please review JDK-8144020: Remove long as an internal numeric type: > > http://cr.openjdk.java.net/~hannesw/8144020/webrev.01/ > > Attila already reviewed a previous version of this patch: > > http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005669.html > > > This version contains most of the changes he suggested. > > Thanks, > Hannes From michael.haupt at oracle.com Mon Dec 14 10:09:49 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 14 Dec 2015 11:09:49 +0100 Subject: RFR(S): 8144221: fix Nashorn shebang argument handling on Mac/Linux Message-ID: Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8144221 Webrev: http://cr.openjdk.java.net/~mhaupt/8144221/webrev.00 The fix for Cygwin is pending and tracked by JDK-8145305. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From marcus at lagergren.net Mon Dec 14 11:29:21 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 14 Dec 2015 12:29:21 +0100 Subject: RFR(S): 8144221: fix Nashorn shebang argument handling on Mac/Linux In-Reply-To: References: Message-ID: +1 > On 14 Dec 2015, at 11:09, Michael Haupt wrote: > > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8144221 > Webrev: http://cr.openjdk.java.net/~mhaupt/8144221/webrev.00 > > The fix for Cygwin is pending and tracked by JDK-8145305. > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From marcus at lagergren.net Mon Dec 14 11:29:35 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 14 Dec 2015 12:29:35 +0100 Subject: Review request for JDK-8144020: Remove long as an internal numeric type In-Reply-To: <566AE8A2.5010708@oracle.com> References: <566AE8A2.5010708@oracle.com> Message-ID: <7C439AC9-66BE-4C3D-B7FB-ACA387F8B919@lagergren.net> +1. This is awesome work, Hannes! /M > On 11 Dec 2015, at 16:15, Hannes Wallnoefer wrote: > > Please review JDK-8144020: Remove long as an internal numeric type: > > http://cr.openjdk.java.net/~hannesw/8144020/webrev.01/ > > Attila already reviewed a previous version of this patch: > > http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005669.html > > This version contains most of the changes he suggested. > > Thanks, > Hannes From james.laskey at oracle.com Mon Dec 14 13:01:54 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 14 Dec 2015 09:01:54 -0400 Subject: RFR(S): 8144221: fix Nashorn shebang argument handling on Mac/Linux In-Reply-To: References: Message-ID: <225678AA-6C62-48AE-9888-A434B251EAD0@oracle.com> +1 > On Dec 14, 2015, at 6:09 AM, Michael Haupt wrote: > > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8144221 > Webrev: http://cr.openjdk.java.net/~mhaupt/8144221/webrev.00 > > The fix for Cygwin is pending and tracked by JDK-8145305. > > Thanks, > > Michael > > -- > > > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | LangTools Team | Nashorn > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > Oracle is committed to developing practices and products that help protect the environment > From marcus at lagergren.net Mon Dec 14 14:51:35 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 14 Dec 2015 15:51:35 +0100 Subject: JFokus VM Tech Day 2016 In-Reply-To: References: <809E0327-271A-4985-B7E1-F02004500F34@lagergren.net> Message-ID: Guys. Sadly Paul couldn?t make it, but we have replaced him with Simon Ritter, who will be wearing his new Azul hat. You are all welcome to attend! https://www.jfokus.se/jfokus/jvmtech.jsp /M /M > On 19 Nov 2015, at 17:17, Marcus Lagergren wrote: > > And all talks have now been finalized: https://www.jfokus.se/jfokus/jvmtech.jsp > > A VM tech day without Martin Thompson is no VM tech day! > > Regards > Marcus > >> On 11 Nov 2015, at 09:35, Marcus Lagergren wrote: >> >> Greetings community members! >> >> I am coordinator for the JFokus VM Tech Day at the JFokus conference in February 2016. This is the second year running we have this event, and it was a great success last year. This year we have received significantly more contributions, and the hardest part was sifting through all quality material that we were given. >> >> We are in the process of finalizing the speaker list, but 5 out of 6 slots are now filled and the current agenda looks like this: https://www.jfokus.se/jfokus/jvmtech.jsp >> >> This year, Brian Goetz, Java Language Architect from Oracle opens the tech day, and talks about project Valhalla and how the OpenJDK is getting there. >> >> Brian is followed by Charlie Gracie, IBM, who will cover what is some of the most exciting news in the runtime world for a very long time: The open sourcing of the J9 JVM and its APIs, and example applications in the dynamic language space. >> >> We are also proud (as always) to host the formidable Mr. Aleksey Shipilev, performance czar extraordinare, always balancing on the fine line between brilliant and crazy. Aleksey's presentation is about String compaction, and String optimisations with invokedynamic in Java 9. Hopefully we have room for him at the ordinary JFokus conference as well, as the man spouts excellent tech presentations like a fountain. >> >> Charlie Nutter also joins us to discuss JRuby 9000, which was released this summer, and about using the JVM as a platform for multi language development. >> >> Paul Sandoz, a man who can do anything from REST services down to bare silicone magic in his job, will tell us about how VarHandles are implemented in the JVM, performance aspects and why no one should miss sun.misc.Unsafe. >> >> Our sixth and final speaker slot is being allocated real soon now. Watch this space. >> >> As usual there is time allocated for breakout sessions, improvised unscheduled lightning talks and discussions / Q&A. >> >> Join the best VM internals conference initiative since JVMLS, and the first of its kind in the old world. >> >> Regards >> Marcus Lagergren >> > From sundararajan.athijegannathan at oracle.com Mon Dec 14 15:05:56 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 14 Dec 2015 20:35:56 +0530 Subject: RFR 8145314: jjs tab-completion should support camel case completion Message-ID: <566EDAD4.3020903@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8145314/ for https://bugs.openjdk.java.net/browse/JDK-8145314 Thanks, -Sundar From szegedia at gmail.com Mon Dec 14 15:44:02 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 14 Dec 2015 16:44:02 +0100 Subject: Review request for JDK-8144914: Eagerly lookup browser JS object class in BrowserJSObjectLinker In-Reply-To: <5666C5CB.9090108@oracle.com> References: <482EFEAD-D413-4F4D-BCC8-98D2581642FA@gmail.com> <5666C5CB.9090108@oracle.com> Message-ID: 2nd review, please? On Tue, Dec 8, 2015 at 12:58 PM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > +1 > > -Sundar > > > On 12/8/2015 5:23 PM, Attila Szegedi wrote: > >> Please review JDK-8144914 "Eagerly lookup browser JS object class in >> BrowserJSObjectLinker" at < >> http://cr.openjdk.java.net/~attila/8144914/webrev.jdk9.jdk> for < >> https://bugs.openjdk.java.net/browse/JDK-8144914> >> >> (Note that line 96 replaces ?return null? for ?return inv? ? the >> distinction only makes sense in presence of non-standard operations, which >> we currently don?t have, but even so that?s pedantically more correct.) >> >> Thanks, >> Attila. >> > > From michael.haupt at oracle.com Mon Dec 14 16:19:30 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 14 Dec 2015 17:19:30 +0100 Subject: RFR 8145314: jjs tab-completion should support camel case completion In-Reply-To: <566EDAD4.3020903@oracle.com> References: <566EDAD4.3020903@oracle.com> Message-ID: <21275B60-DC17-4A83-BDEF-95581793DE43@oracle.com> Hi Sundar, lower-case thumbs up. Best, Michael > Am 14.12.2015 um 16:05 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8145314/ for https://bugs.openjdk.java.net/browse/JDK-8145314 > > Thanks, > -Sundar -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Mon Dec 14 16:20:51 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 14 Dec 2015 17:20:51 +0100 Subject: Review request for JDK-8144914: Eagerly lookup browser JS object class in BrowserJSObjectLinker In-Reply-To: References: <482EFEAD-D413-4F4D-BCC8-98D2581642FA@gmail.com> <5666C5CB.9090108@oracle.com> Message-ID: <566EEC63.2090806@oracle.com> Sorry, I missed the intial request. +1 Hannes Am 2015-12-14 um 16:44 schrieb Attila Szegedi: > 2nd review, please? > > On Tue, Dec 8, 2015 at 12:58 PM, Sundararajan Athijegannathan < > sundararajan.athijegannathan at oracle.com> wrote: > >> +1 >> >> -Sundar >> >> >> On 12/8/2015 5:23 PM, Attila Szegedi wrote: >> >>> Please review JDK-8144914 "Eagerly lookup browser JS object class in >>> BrowserJSObjectLinker" at < >>> http://cr.openjdk.java.net/~attila/8144914/webrev.jdk9.jdk> for < >>> https://bugs.openjdk.java.net/browse/JDK-8144914> >>> >>> (Note that line 96 replaces ?return null? for ?return inv? ? the >>> distinction only makes sense in presence of non-standard operations, which >>> we currently don?t have, but even so that?s pedantically more correct.) >>> >>> Thanks, >>> Attila. >>> >> From hannes.wallnoefer at oracle.com Mon Dec 14 16:21:21 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 14 Dec 2015 17:21:21 +0100 Subject: RFR 8145314: jjs tab-completion should support camel case completion In-Reply-To: <566EDAD4.3020903@oracle.com> References: <566EDAD4.3020903@oracle.com> Message-ID: <566EEC81.3000108@oracle.com> +1 Am 2015-12-14 um 16:05 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8145314/ for > https://bugs.openjdk.java.net/browse/JDK-8145314 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Mon Dec 14 16:30:01 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 14 Dec 2015 17:30:01 +0100 Subject: Use of long in Nashorn In-Reply-To: <566AEC0C.60307@oracle.com> References: <5645ADD8.9060906@oracle.com> <8373DB71-DC4C-40E0-BD0C-3910108A6BD5@oracle.com> <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> <5661B0DA.706@oracle.com> <0B1CADAA-F45E-48FB-8974-13C72D120B13@gmail.com> <566409FD.7030804@oracle.com> <566AE6D2.6060107@oracle.com> <566AEC0C.60307@oracle.com> Message-ID: <566EEE89.8080500@oracle.com> For the record, I tried the integer index optimization for array iterators, but didn't really see a difference running a microbenchmark using Array.prototype.forEach, so I left it out after all. Hannes Am 2015-12-11 um 16:30 schrieb Hannes Wallnoefer: > Am 2015-12-11 um 16:21 schrieb Attila Szegedi: >> On Dec 11, 2015, at 4:08 PM, Hannes Wallnoefer >> wrote: >> >>> I didn't implement the int/double overloading of array iterator >>> actions. Unless I missed something, I would have to implement two >>> forEach methods in each subclass, which seem ugly and error prone. >> You haven?t missed anything; that?s exactly how that would work. >> Ultimately, if we had macros in Java, this wouldn?t need to look >> ugly, but we don?t have them, so? Performance optimizations are >> sometimes ugly :-) Anyway, this needn?t happen now, although >> ultimately I don?t think it?d be much of a big deal to implement, >> even with the unfortunate code duplication, and we still wouldn?t >> always force-promote the parameter type for the callback functions to >> double. >> > > Ok, you convinced me. I'll add that optimization an upcoming webrev. > Still waiting for other reviews though. > > Hannes From Steven.Wyatt at fisglobal.com Mon Dec 14 19:09:25 2015 From: Steven.Wyatt at fisglobal.com (Wyatt, Steven) Date: Mon, 14 Dec 2015 19:09:25 +0000 Subject: nashorn migration Message-ID: <03ABFF6A1EF0DA4087B85BAE50C37BC48A44F837@us-voo-mb01.internal.sungard.corp> Hi, You have listed "nashorn:mozilla_script.js" as the compatibility script instead of "nashorn:mozilla_compat.js" in the section "loading compatibility script so that script runs on rhino and nashorn". https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide Steve _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From marcus at lagergren.net Tue Dec 15 08:55:15 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Tue, 15 Dec 2015 09:55:15 +0100 Subject: Use of long in Nashorn In-Reply-To: <566EEE89.8080500@oracle.com> References: <5645ADD8.9060906@oracle.com> <8373DB71-DC4C-40E0-BD0C-3910108A6BD5@oracle.com> <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> <5661B0DA.706@oracle.com> <0B1CADAA-F45E-48FB-8974-13C72D120B13@gmail.com> <566409FD.7030804@oracle.com> <566AE6D2.6060107@oracle.com> <566AEC0C.60307@oracle.com> <566EEE89.8080500@oracle.com> Message-ID: <1D8C177E-7532-4106-94AE-1A7586378967@lagergren.net> All octane benchmarks and stuff like that run with no serious regressions, I hope? > On 14 Dec 2015, at 17:30, Hannes Wallnoefer wrote: > > For the record, I tried the integer index optimization for array iterators, but didn't really see a difference running a microbenchmark using Array.prototype.forEach, so I left it out after all. > > Hannes > > Am 2015-12-11 um 16:30 schrieb Hannes Wallnoefer: >> Am 2015-12-11 um 16:21 schrieb Attila Szegedi: >>> On Dec 11, 2015, at 4:08 PM, Hannes Wallnoefer wrote: >>> >>>> I didn't implement the int/double overloading of array iterator actions. Unless I missed something, I would have to implement two forEach methods in each subclass, which seem ugly and error prone. >>> You haven?t missed anything; that?s exactly how that would work. Ultimately, if we had macros in Java, this wouldn?t need to look ugly, but we don?t have them, so? Performance optimizations are sometimes ugly :-) Anyway, this needn?t happen now, although ultimately I don?t think it?d be much of a big deal to implement, even with the unfortunate code duplication, and we still wouldn?t always force-promote the parameter type for the callback functions to double. >>> >> >> Ok, you convinced me. I'll add that optimization an upcoming webrev. Still waiting for other reviews though. >> >> Hannes > From hannes.wallnoefer at oracle.com Tue Dec 15 09:15:15 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 15 Dec 2015 10:15:15 +0100 Subject: Use of long in Nashorn In-Reply-To: <1D8C177E-7532-4106-94AE-1A7586378967@lagergren.net> References: <5645ADD8.9060906@oracle.com> <8373DB71-DC4C-40E0-BD0C-3910108A6BD5@oracle.com> <4DCB809B-95CA-4F2E-8036-444848AA2C82@oracle.com> <5661B0DA.706@oracle.com> <0B1CADAA-F45E-48FB-8974-13C72D120B13@gmail.com> <566409FD.7030804@oracle.com> <566AE6D2.6060107@oracle.com> <566AEC0C.60307@oracle.com> <566EEE89.8080500@oracle.com> <1D8C177E-7532-4106-94AE-1A7586378967@lagergren.net> Message-ID: <566FDA23.6090303@oracle.com> I spent significant time testing this with octane and sunspider, and didn't find any regressions. Hannes Am 2015-12-15 um 09:55 schrieb Marcus Lagergren: > All octane benchmarks and stuff like that run with no serious regressions, I hope? > > >> On 14 Dec 2015, at 17:30, Hannes Wallnoefer wrote: >> >> For the record, I tried the integer index optimization for array iterators, but didn't really see a difference running a microbenchmark using Array.prototype.forEach, so I left it out after all. >> >> Hannes >> >> Am 2015-12-11 um 16:30 schrieb Hannes Wallnoefer: >>> Am 2015-12-11 um 16:21 schrieb Attila Szegedi: >>>> On Dec 11, 2015, at 4:08 PM, Hannes Wallnoefer wrote: >>>> >>>>> I didn't implement the int/double overloading of array iterator actions. Unless I missed something, I would have to implement two forEach methods in each subclass, which seem ugly and error prone. >>>> You haven?t missed anything; that?s exactly how that would work. Ultimately, if we had macros in Java, this wouldn?t need to look ugly, but we don?t have them, so? Performance optimizations are sometimes ugly :-) Anyway, this needn?t happen now, although ultimately I don?t think it?d be much of a big deal to implement, even with the unfortunate code duplication, and we still wouldn?t always force-promote the parameter type for the callback functions to double. >>>> >>> Ok, you convinced me. I'll add that optimization an upcoming webrev. Still waiting for other reviews though. >>> >>> Hannes From sundararajan.athijegannathan at oracle.com Tue Dec 15 11:41:36 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 15 Dec 2015 17:11:36 +0530 Subject: nashorn migration In-Reply-To: <03ABFF6A1EF0DA4087B85BAE50C37BC48A44F837@us-voo-mb01.internal.sungard.corp> References: <03ABFF6A1EF0DA4087B85BAE50C37BC48A44F837@us-voo-mb01.internal.sungard.corp> Message-ID: <566FFC70.3080101@oracle.com> Thanks for the notification! Fixed the wiki page: https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide -Sundar On 12/15/2015 12:39 AM, Wyatt, Steven wrote: > Hi, > > You have listed "nashorn:mozilla_script.js" as the compatibility script instead of "nashorn:mozilla_compat.js" in the section "loading compatibility script so that script runs on rhino and nashorn". > > https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide > > Steve > > _____________ > The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From marcus at lagergren.net Tue Dec 15 11:43:10 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Tue, 15 Dec 2015 12:43:10 +0100 Subject: VM Tech Summit 2016 update Message-ID: <996AC2DB-DB8F-4484-9A16-8583F0AEB3AC@lagergren.net> Hi guys! I just wanted to inform you that Paul Sandoz sadly couldn?t make it to JFokus and the VM Tech Summit in February. Luckily we have found Simon Ritter to replace him. Simon will be wearing his Azul hat, and will talk about the Object Layout project (objectlayout.org). The speaker list has been updated. https://www.jfokus.se/jfokus/jvmtech.jsp Hope to see you there! /Marcus (VM Tech summit chair and coordinator) From stijndewitt at hotmail.com Tue Dec 15 15:53:37 2015 From: stijndewitt at hotmail.com (Stijn de Witt) Date: Tue, 15 Dec 2015 15:53:37 +0000 Subject: ClassCastException NativeRegExpExecResult cannot be cast to NativeArray Message-ID: Dear fellow developers, First of all thank you for your work on Nashorn. I am pretty excited at the possibilities of being able to integrate my two favorite languages, Java and Javascript. I have two concrete questions and a problem (which caused the questions): 1. Can a Nashorn engine be used across threads (using ScriptContext or Bindings for isolation)?2. Is there a good example of using Nashorn from a Servlet Filter? My problem: I am struggling with server-side rendering of React components using Nashorn. I am deploying to OpenShift and whenever I try to make my app listen to the rout route, I run into a weird ClassCastException somewhere inside the Nashorn code. I now think this is due to a heartbeat request OpenShift's haproxy is doing on my app that is causing (relatively) high load and triggering a concurrency problem... This leads me to believe I am doing something wrong in the way I create the script engine and using script contexts in a ThreadLocal to isolate the different threads. I have formulated my question, including logs and relevant code, on StackOverflow.com.http://stackoverflow.com/questions/34276136/classcastexception-nativeregexpexecresult-cannot-be-cast-to-nativearray Could one of you maybe have a look at my situation, specifically my servlet filter code and tell me if I am doing it wrong and if so, what I should change?(I tried instantiating a different engine per thread and saving them in a ThreadLocal, but this leads to OutOfMemory errors quickly) Thank you for any tips, pointers to docs etc that you could spare. With kind regards, -Stijn Stijn de Witthttp://stijndewitt.wordpress.com From james.laskey at oracle.com Tue Dec 15 16:24:58 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 15 Dec 2015 12:24:58 -0400 Subject: ClassCastException NativeRegExpExecResult cannot be cast to NativeArray In-Reply-To: References: Message-ID: <05B43658-2417-42FF-9B2E-2065B6B33282@oracle.com> At first glance it doesn?t seem to be thread related. We?ll poke at it but it would be helpful if you reduced the problem. ? Jim > On Dec 15, 2015, at 11:53 AM, Stijn de Witt wrote: > > Dear fellow developers, > First of all thank you for your work on Nashorn. I am pretty excited at the possibilities of being able to integrate my two favorite languages, Java and Javascript. > I have two concrete questions and a problem (which caused the questions): > 1. Can a Nashorn engine be used across threads (using ScriptContext or Bindings for isolation)?2. Is there a good example of using Nashorn from a Servlet Filter? > My problem: > I am struggling with server-side rendering of React components using Nashorn. I am deploying to OpenShift and whenever I try to make my app listen to the rout route, I run into a weird ClassCastException somewhere inside the Nashorn code. I now think this is due to a heartbeat request OpenShift's haproxy is doing on my app that is causing (relatively) high load and triggering a concurrency problem... This leads me to believe I am doing something wrong in the way I create the script engine and using script contexts in a ThreadLocal to isolate the different threads. > I have formulated my question, including logs and relevant code, on StackOverflow.com.http://stackoverflow.com/questions/34276136/classcastexception-nativeregexpexecresult-cannot-be-cast-to-nativearray > > Could one of you maybe have a look at my situation, specifically my servlet filter code and tell me if I am doing it wrong and if so, what I should change?(I tried instantiating a different engine per thread and saving them in a ThreadLocal, but this leads to OutOfMemory errors quickly) > Thank you for any tips, pointers to docs etc that you could spare. > With kind regards, > -Stijn > Stijn de Witthttp://stijndewitt.wordpress.com > > From sundararajan.athijegannathan at oracle.com Wed Dec 16 04:38:23 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 16 Dec 2015 10:08:23 +0530 Subject: RFR 8145486: jjs should support documentation key shortcut in interactive mode Message-ID: <5670EABF.5080405@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8145486/ for https://bugs.openjdk.java.net/browse/JDK-8145486 Note that this enhancement only adds jjs changes to show documentation when available and infrastructure to attach documentation string for JS built-in functions, constructors. Actual documentation strings are added only for NativeObject. Adding documentation string for all other built-in functions, constructors will be done in future. Thanks, -Sundar From michael.haupt at oracle.com Wed Dec 16 08:49:05 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 16 Dec 2015 09:49:05 +0100 Subject: RFR 8145486: jjs should support documentation key shortcut in interactive mode In-Reply-To: <5670EABF.5080405@oracle.com> References: <5670EABF.5080405@oracle.com> Message-ID: <997720C0-E827-461A-84A6-59EC16F570BD@oracle.com> Hi Sundar, very cool. Lower-case thumbs up. I tested this on the Mac platform, and all the features work, save one little thing. Main.openBrowserForJavaDoc does not seem to handle inner classes correctly. Entering java.util.HashMap.SimpleEntry in the jjs shell and then hitting Shift-Tab will pass the URL http://download.java.net/jdk9/docs/api/java/util/AbstractMap$SimpleEntry.html to the browser, when http://download.java.net/jdk9/docs/api/java/util/AbstractMap.SimpleEntry.html is needed. The $->. conversion needs to be added. Best, Michael > Am 16.12.2015 um 05:38 schrieb Sundararajan Athijegannathan : > > Please review http://cr.openjdk.java.net/~sundar/8145486/ for https://bugs.openjdk.java.net/browse/JDK-8145486 > > Note that this enhancement only adds jjs changes to show documentation when available and infrastructure to attach documentation string for JS built-in functions, constructors. > Actual documentation strings are added only for NativeObject. Adding documentation string for all other built-in functions, constructors will be done in future. > > Thanks, > -Sundar -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Wed Dec 16 09:18:09 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 16 Dec 2015 10:18:09 +0100 Subject: RFR 8145486: jjs should support documentation key shortcut in interactive mode In-Reply-To: <5670EABF.5080405@oracle.com> References: <5670EABF.5080405@oracle.com> Message-ID: <56712C51.7090902@oracle.com> Very nice, and works like a charm on Linux. One nitpick: documentation for NativeObject.setIndexedPropertiesToExternalArrayData should start with "sets" rather than "set" to be consistent with the rest. Hannes Am 2015-12-16 um 05:38 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8145486/ for > https://bugs.openjdk.java.net/browse/JDK-8145486 > > Note that this enhancement only adds jjs changes to show documentation > when available and infrastructure to attach documentation string for > JS built-in functions, constructors. > Actual documentation strings are added only for NativeObject. Adding > documentation string for all other built-in functions, constructors > will be done in future. > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Wed Dec 16 10:33:45 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 16 Dec 2015 16:03:45 +0530 Subject: RFR 8145486: jjs should support documentation key shortcut in interactive mode In-Reply-To: <56712C51.7090902@oracle.com> References: <5670EABF.5080405@oracle.com> <56712C51.7090902@oracle.com> Message-ID: <56713E09.4070709@oracle.com> Thanks for the reviews. Updated webrev: http://cr.openjdk.java.net/~sundar/8145486/webrev.01/ * Fixed documentation for setIndexedPropertiesToExternalArrayData * Fixed inner/nested class case ($ - > ".") * Added doc for NativeJavaPackage objects * Added missing "final" in Console.bind method. Incremental changes are only in Main.java and Console.java Please review.. -Sundar On 12/16/2015 2:48 PM, Hannes Wallnoefer wrote: > Very nice, and works like a charm on Linux. > > One nitpick: documentation for > NativeObject.setIndexedPropertiesToExternalArrayData should start with > "sets" rather than "set" to be consistent with the rest. > > Hannes > > Am 2015-12-16 um 05:38 schrieb Sundararajan Athijegannathan: >> Please review http://cr.openjdk.java.net/~sundar/8145486/ for >> https://bugs.openjdk.java.net/browse/JDK-8145486 >> >> Note that this enhancement only adds jjs changes to show >> documentation when available and infrastructure to attach >> documentation string for JS built-in functions, constructors. >> Actual documentation strings are added only for NativeObject. Adding >> documentation string for all other built-in functions, constructors >> will be done in future. >> >> Thanks, >> -Sundar > From michael.haupt at oracle.com Wed Dec 16 10:37:00 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 16 Dec 2015 11:37:00 +0100 Subject: RFR 8145486: jjs should support documentation key shortcut in interactive mode In-Reply-To: <56713E09.4070709@oracle.com> References: <5670EABF.5080405@oracle.com> <56712C51.7090902@oracle.com> <56713E09.4070709@oracle.com> Message-ID: <7B199821-7A21-412D-8E95-8BC90B18F17E@oracle.com> Hi Sundar, thumbs are still up! Best, Michael > Am 16.12.2015 um 11:33 schrieb Sundararajan Athijegannathan : > > Thanks for the reviews. > > Updated webrev: http://cr.openjdk.java.net/~sundar/8145486/webrev.01/ > > * Fixed documentation for setIndexedPropertiesToExternalArrayData > * Fixed inner/nested class case ($ - > ".") > * Added doc for NativeJavaPackage objects > * Added missing "final" in Console.bind method. > > Incremental changes are only in Main.java and Console.java > > Please review.. > > -Sundar > > On 12/16/2015 2:48 PM, Hannes Wallnoefer wrote: >> Very nice, and works like a charm on Linux. >> >> One nitpick: documentation for NativeObject.setIndexedPropertiesToExternalArrayData should start with "sets" rather than "set" to be consistent with the rest. >> >> Hannes >> >> Am 2015-12-16 um 05:38 schrieb Sundararajan Athijegannathan: >>> Please review http://cr.openjdk.java.net/~sundar/8145486/ for https://bugs.openjdk.java.net/browse/JDK-8145486 >>> >>> Note that this enhancement only adds jjs changes to show documentation when available and infrastructure to attach documentation string for JS built-in functions, constructors. >>> Actual documentation strings are added only for NativeObject. Adding documentation string for all other built-in functions, constructors will be done in future. >>> >>> Thanks, >>> -Sundar >> > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From hannes.wallnoefer at oracle.com Wed Dec 16 11:16:08 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 16 Dec 2015 12:16:08 +0100 Subject: RFR 8145486: jjs should support documentation key shortcut in interactive mode In-Reply-To: <56713E09.4070709@oracle.com> References: <5670EABF.5080405@oracle.com> <56712C51.7090902@oracle.com> <56713E09.4070709@oracle.com> Message-ID: <567147F8.7000403@oracle.com> +1 Am 2015-12-16 um 11:33 schrieb Sundararajan Athijegannathan: > Thanks for the reviews. > > Updated webrev: http://cr.openjdk.java.net/~sundar/8145486/webrev.01/ > > * Fixed documentation for setIndexedPropertiesToExternalArrayData > * Fixed inner/nested class case ($ - > ".") > * Added doc for NativeJavaPackage objects > * Added missing "final" in Console.bind method. > > Incremental changes are only in Main.java and Console.java > > Please review.. > > -Sundar > > On 12/16/2015 2:48 PM, Hannes Wallnoefer wrote: >> Very nice, and works like a charm on Linux. >> >> One nitpick: documentation for >> NativeObject.setIndexedPropertiesToExternalArrayData should start >> with "sets" rather than "set" to be consistent with the rest. >> >> Hannes >> >> Am 2015-12-16 um 05:38 schrieb Sundararajan Athijegannathan: >>> Please review http://cr.openjdk.java.net/~sundar/8145486/ for >>> https://bugs.openjdk.java.net/browse/JDK-8145486 >>> >>> Note that this enhancement only adds jjs changes to show >>> documentation when available and infrastructure to attach >>> documentation string for JS built-in functions, constructors. >>> Actual documentation strings are added only for NativeObject. Adding >>> documentation string for all other built-in functions, constructors >>> will be done in future. >>> >>> Thanks, >>> -Sundar >> > From sundararajan.athijegannathan at oracle.com Wed Dec 16 13:30:34 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 16 Dec 2015 19:00:34 +0530 Subject: RFR 8145550: Megamorphic invoke should use CompiledFunction variants without any LinkLogic Message-ID: <5671677A.9090007@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8145550/ for https://bugs.openjdk.java.net/browse/JDK-8145550 Thanks, -Sundar From james.laskey at oracle.com Wed Dec 16 13:47:41 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 16 Dec 2015 09:47:41 -0400 Subject: RFR 8145550: Megamorphic invoke should use CompiledFunction variants without any LinkLogic In-Reply-To: <5671677A.9090007@oracle.com> References: <5671677A.9090007@oracle.com> Message-ID: <132CCF99-2DC7-406C-A66D-4135991AB48E@oracle.com> +1 > On Dec 16, 2015, at 9:30 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8145550/ for https://bugs.openjdk.java.net/browse/JDK-8145550 > > Thanks, > -Sundar From daniel.kasmeroglu at aperto.com Wed Dec 16 14:01:27 2015 From: daniel.kasmeroglu at aperto.com (Kasmeroglu, Daniel) Date: Wed, 16 Dec 2015 14:01:27 +0000 Subject: TypeError: I could use some explanation Message-ID: <0DEAA59F0C96E948858BBBF8DA3840321742A4AE@EX2010.aperto.de> Hi there, First of all: thanks for the great work with Nashorn. Unfortunately I'm currently a little bit stuck as I don't get what I'm doing wrong here. Here's a simple code snippet that explains what I'm doing: --<8-- ScriptEngine engine = ... Map context = ... engine.put("t4_context", context); engine.eval("t4(t4_context);"); --8>-- The variable 't4' is a compiled template generated through Handlebars (so it's a function taking a hash). Unfortunately I don't get it running as there's the following complain: --<8-- Caused by: :30 TypeError: {assets=dodo} is not an Object --8>-- It's clear to me that the issue is caused since the java object 'context' isn't an instance of 'ScriptObject'. However it isn't clear to me why this happens. It would be nice to give me a hint of what I'm doing wrong or to point me to some helpful documentation. Thanks in advance. -- Dipl.-Inform. Daniel Kasmeroglu, Java Developer Advanced Email daniel.kasmeroglu at aperto.de Phone +49 30 283921-381 Fax +49 30 283921-29 Aperto AG - In der Pianofabrik Chausseestra?e 5, D-10115 Berlin-Mitte http://www.aperto.de http://www.facebook.com/aperto https://www.xing.com/companies/apertoag HRB 77049, AG Berlin Charlottenburg Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen, Daniel Simon Aufsichtsrat: Bernd Hardes (Vorsitzender) From james.laskey at oracle.com Wed Dec 16 14:07:41 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 16 Dec 2015 10:07:41 -0400 Subject: TypeError: I could use some explanation In-Reply-To: <0DEAA59F0C96E948858BBBF8DA3840321742A4AE@EX2010.aperto.de> References: <0DEAA59F0C96E948858BBBF8DA3840321742A4AE@EX2010.aperto.de> Message-ID: How is t4_context used in the function? IE., what does line 30 look like? ? Jim > On Dec 16, 2015, at 10:01 AM, Kasmeroglu, Daniel wrote: > > Hi there, > > First of all: thanks for the great work with Nashorn. > Unfortunately I'm currently a little bit stuck as I don't get what I'm > doing wrong here. > Here's a simple code snippet that explains what I'm doing: > > --<8-- > ScriptEngine engine = ... > Map context = ... > engine.put("t4_context", context); > engine.eval("t4(t4_context);"); > --8>-- > > The variable 't4' is a compiled template generated through Handlebars > (so it's a function taking a hash). > Unfortunately I don't get it running as there's the following complain: > > --<8-- > Caused by: :30 TypeError: {assets=dodo} is not an Object > --8>-- > > It's clear to me that the issue is caused since the java object > 'context' isn't an instance of 'ScriptObject'. However it isn't clear to > me why this happens. > > It would be nice to give me a hint of what I'm doing wrong or to point > me to some helpful documentation. > > Thanks in advance. > > > -- > Dipl.-Inform. Daniel Kasmeroglu, Java Developer Advanced > > Email daniel.kasmeroglu at aperto.de > Phone +49 30 283921-381 > Fax +49 30 283921-29 > > Aperto AG - In der Pianofabrik > Chausseestra?e 5, D-10115 Berlin-Mitte > http://www.aperto.de > http://www.facebook.com/aperto > https://www.xing.com/companies/apertoag > > HRB 77049, AG Berlin Charlottenburg > Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen, > Daniel Simon > Aufsichtsrat: Bernd Hardes (Vorsitzender) > > From hannes.wallnoefer at oracle.com Wed Dec 16 14:39:36 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 16 Dec 2015 15:39:36 +0100 Subject: RFR 8145550: Megamorphic invoke should use CompiledFunction variants without any LinkLogic In-Reply-To: <5671677A.9090007@oracle.com> References: <5671677A.9090007@oracle.com> Message-ID: <567177A8.70304@oracle.com> Looks good. Am 2015-12-16 um 14:30 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8145550/ for > https://bugs.openjdk.java.net/browse/JDK-8145550 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Wed Dec 16 14:41:51 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 16 Dec 2015 20:11:51 +0530 Subject: TypeError: I could use some explanation In-Reply-To: <0DEAA59F0C96E948858BBBF8DA3840321742A4AE@EX2010.aperto.de> References: <0DEAA59F0C96E948858BBBF8DA3840321742A4AE@EX2010.aperto.de> Message-ID: <5671782F.8040703@oracle.com> If the script function t4 expects that "t4_context" is a script object and so calls Object.prototype function or any JS function that expects "this" to be a script object, you'll get a TypeError (per spec.). We need bit more information on the code of "t4" to help further. -Sundar On 12/16/2015 7:31 PM, Kasmeroglu, Daniel wrote: > Hi there, > > First of all: thanks for the great work with Nashorn. > Unfortunately I'm currently a little bit stuck as I don't get what I'm > doing wrong here. > Here's a simple code snippet that explains what I'm doing: > > --<8-- > ScriptEngine engine = ... > Map context = ... > engine.put("t4_context", context); > engine.eval("t4(t4_context);"); > --8>-- > > The variable 't4' is a compiled template generated through Handlebars > (so it's a function taking a hash). > Unfortunately I don't get it running as there's the following complain: > > --<8-- > Caused by: :30 TypeError: {assets=dodo} is not an Object > --8>-- > > It's clear to me that the issue is caused since the java object > 'context' isn't an instance of 'ScriptObject'. However it isn't clear to > me why this happens. > > It would be nice to give me a hint of what I'm doing wrong or to point > me to some helpful documentation. > > Thanks in advance. > > From daniel.kasmeroglu at aperto.com Wed Dec 16 15:22:55 2015 From: daniel.kasmeroglu at aperto.com (Kasmeroglu, Daniel) Date: Wed, 16 Dec 2015 15:22:55 +0000 Subject: TypeError: I could use some explanation In-Reply-To: <5671782F.8040703@oracle.com> References: <0DEAA59F0C96E948858BBBF8DA3840321742A4AE@EX2010.aperto.de> <5671782F.8040703@oracle.com> Message-ID: <0DEAA59F0C96E948858BBBF8DA3840321742ADD8@EX2010.aperto.de> On Mi, 2015-12-16 at 20:11 +0530, Sundararajan Athijegannathan wrote: > If the script function t4 expects that "t4_context" is a script object > and so calls Object.prototype function or any JS function that expects > "this" to be a script object, you'll get a TypeError (per spec.). We > need bit more information on the code of "t4" to help further. > The code of 't4' is a problem here as it's generated by Handlebars. It's ScriptObjectMirror presentation results in: --8>-- [_setup -> function (setupOptions) { if (!compiled) { compiled = compileInput(); } return compiled._setup(setupOptions); }] [_child -> function (i, data, blockParams, depths) { if (!compiled) { compiled = compileInput(); } return compiled._child(i, data, blockParams, depths); }] --<8-- However I don't expect anyone to investigate this code further as I think this might require quite a bit of work (https://github.com/wycats/handlebars.js/tree/master). It's essentially a template which will render it's content with the supplied hash in question. Last but not least I figured out a workaround which seem to work fine. I'm simply adding the entries of the map 't4_context' and I'm generating the template function call accordingly. F.e. > t4(t4_context) turns into > t4({'assets': assets, 'def': def}) Nevertheless if someone knows an answer to the problem it would be nice to know. > -Sundar > > On 12/16/2015 7:31 PM, Kasmeroglu, Daniel wrote: > > Hi there, > > > > First of all: thanks for the great work with Nashorn. > > Unfortunately I'm currently a little bit stuck as I don't get what I'm > > doing wrong here. > > Here's a simple code snippet that explains what I'm doing: > > > > --<8-- > > ScriptEngine engine = ... > > Map context = ... > > engine.put("t4_context", context); > > engine.eval("t4(t4_context);"); > > --8>-- > > > > The variable 't4' is a compiled template generated through Handlebars > > (so it's a function taking a hash). > > Unfortunately I don't get it running as there's the following complain: > > > > --<8-- > > Caused by: :30 TypeError: {assets=dodo} is not an Object > > --8>-- > > > > It's clear to me that the issue is caused since the java object > > 'context' isn't an instance of 'ScriptObject'. However it isn't clear to > > me why this happens. > > > > It would be nice to give me a hint of what I'm doing wrong or to point > > me to some helpful documentation. > > > > Thanks in advance. > > > > > -- Dipl.-Inform. Daniel Kasmeroglu, Java Developer Advanced Email daniel.kasmeroglu at aperto.de Phone +49 30 283921-381 Fax +49 30 283921-29 Aperto AG - In der Pianofabrik Chausseestra?e 5, D-10115 Berlin-Mitte http://www.aperto.de http://www.facebook.com/aperto https://www.xing.com/companies/apertoag HRB 77049, AG Berlin Charlottenburg Vorstand: Dirk Buddensiek (Vorsitzender), Kai Gro?mann, Stephan Haagen, Daniel Simon Aufsichtsrat: Bernd Hardes (Vorsitzender) From sundararajan.athijegannathan at oracle.com Wed Dec 16 15:50:54 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 16 Dec 2015 21:20:54 +0530 Subject: TypeError: I could use some explanation In-Reply-To: <0DEAA59F0C96E948858BBBF8DA3840321742ADD8@EX2010.aperto.de> References: <0DEAA59F0C96E948858BBBF8DA3840321742A4AE@EX2010.aperto.de> <5671782F.8040703@oracle.com> <0DEAA59F0C96E948858BBBF8DA3840321742ADD8@EX2010.aperto.de> Message-ID: <5671885E.2060308@oracle.com> Actually, it'd be difficult for us to debug as well. As I said, most likely your Java Map passed is being treated as a (JS) script object - and it is not. Please note that Nashorn uses wrapperless Java objects with scripts - so scripts see the exposed Java objects as plain Java objects. So, the solution would be to use an actual script object in such cases. -Sundar On 12/16/2015 8:52 PM, Kasmeroglu, Daniel wrote: > On Mi, 2015-12-16 at 20:11 +0530, Sundararajan Athijegannathan wrote: >> If the script function t4 expects that "t4_context" is a script object >> and so calls Object.prototype function or any JS function that expects >> "this" to be a script object, you'll get a TypeError (per spec.). We >> need bit more information on the code of "t4" to help further. >> > The code of 't4' is a problem here as it's generated by Handlebars. It's > ScriptObjectMirror presentation results in: > > --8>-- > [_setup -> function (setupOptions) { > if (!compiled) { > compiled = compileInput(); > } > return compiled._setup(setupOptions); > }] > [_child -> function (i, data, blockParams, depths) { > if (!compiled) { > compiled = compileInput(); > } > return compiled._child(i, data, blockParams, depths); > }] > --<8-- > > However I don't expect anyone to investigate this code further as I > think this might require quite a bit of work > (https://github.com/wycats/handlebars.js/tree/master). It's essentially > a template which will render it's content with the supplied hash in > question. > > Last but not least I figured out a workaround which seem to work fine. > I'm simply adding the entries of the map 't4_context' and I'm generating > the template function call accordingly. F.e. > >> t4(t4_context) > turns into > >> t4({'assets': assets, 'def': def}) > Nevertheless if someone knows an answer to the problem it would be nice > to know. > > > >> -Sundar >> >> On 12/16/2015 7:31 PM, Kasmeroglu, Daniel wrote: >>> Hi there, >>> >>> First of all: thanks for the great work with Nashorn. >>> Unfortunately I'm currently a little bit stuck as I don't get what I'm >>> doing wrong here. >>> Here's a simple code snippet that explains what I'm doing: >>> >>> --<8-- >>> ScriptEngine engine = ... >>> Map context = ... >>> engine.put("t4_context", context); >>> engine.eval("t4(t4_context);"); >>> --8>-- >>> >>> The variable 't4' is a compiled template generated through Handlebars >>> (so it's a function taking a hash). >>> Unfortunately I don't get it running as there's the following complain: >>> >>> --<8-- >>> Caused by: :30 TypeError: {assets=dodo} is not an Object >>> --8>-- >>> >>> It's clear to me that the issue is caused since the java object >>> 'context' isn't an instance of 'ScriptObject'. However it isn't clear to >>> me why this happens. >>> >>> It would be nice to give me a hint of what I'm doing wrong or to point >>> me to some helpful documentation. >>> >>> Thanks in advance. >>> >>> From szegedia at gmail.com Wed Dec 16 16:16:27 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 16 Dec 2015 17:16:27 +0100 Subject: RFR 8145550: Megamorphic invoke should use CompiledFunction variants without any LinkLogic In-Reply-To: <5671677A.9090007@oracle.com> References: <5671677A.9090007@oracle.com> Message-ID: <382D8064-8ABD-41DB-A3EE-42CC059D8444@gmail.com> +1 > On Dec 16, 2015, at 2:30 PM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8145550/ for https://bugs.openjdk.java.net/browse/JDK-8145550 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Thu Dec 17 05:43:39 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 17 Dec 2015 11:13:39 +0530 Subject: RFR 8145630: accidental debug printlns in NativeFunction.java Message-ID: <56724B8B.4050805@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8145630/ for https://bugs.openjdk.java.net/browse/JDK-8145630 Thanks, -Sundar From hannes.wallnoefer at oracle.com Thu Dec 17 07:12:38 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 17 Dec 2015 08:12:38 +0100 Subject: RFR 8145630: accidental debug printlns in NativeFunction.java In-Reply-To: <56724B8B.4050805@oracle.com> References: <56724B8B.4050805@oracle.com> Message-ID: <56726066.6060504@oracle.com> +1 Am 2015-12-17 um 06:43 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8145630/ for > https://bugs.openjdk.java.net/browse/JDK-8145630 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Thu Dec 17 12:28:44 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 17 Dec 2015 17:58:44 +0530 Subject: RFR 8145669: apply2call optimized callsite fails after becoming megamorphic Message-ID: <5672AA7C.4030003@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8145669/ for https://bugs.openjdk.java.net/browse/JDK-8145669 Thanks, -Sundar From james.laskey at oracle.com Thu Dec 17 12:33:13 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 17 Dec 2015 08:33:13 -0400 Subject: RFR 8145669: apply2call optimized callsite fails after becoming megamorphic In-Reply-To: <5672AA7C.4030003@oracle.com> References: <5672AA7C.4030003@oracle.com> Message-ID: <5E26BFF5-0818-4D4B-84D3-69C3FBB331AD@oracle.com> +1 > On Dec 17, 2015, at 8:28 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8145669/ for https://bugs.openjdk.java.net/browse/JDK-8145669 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Thu Dec 17 12:37:06 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 17 Dec 2015 13:37:06 +0100 Subject: RFR 8145669: apply2call optimized callsite fails after becoming megamorphic In-Reply-To: <5672AA7C.4030003@oracle.com> References: <5672AA7C.4030003@oracle.com> Message-ID: <5672AC72.6010301@oracle.com> +1 Am 2015-12-17 um 13:28 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8145669/ for > https://bugs.openjdk.java.net/browse/JDK-8145669 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Thu Dec 17 12:47:57 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 17 Dec 2015 18:17:57 +0530 Subject: ClassCastException NativeRegExpExecResult cannot be cast to NativeArray In-Reply-To: <05B43658-2417-42FF-9B2E-2065B6B33282@oracle.com> References: <05B43658-2417-42FF-9B2E-2065B6B33282@oracle.com> Message-ID: <5672AEFD.2090302@oracle.com> Hi Stijn, We *suspect* a bug fix ( https://bugs.openjdk.java.net/browse/JDK-8145550) that is in jdk9 may fix the one you describe as well. We'd want to backport to a jdk8u after due backport process. FYI. Thanks, -Sundar On 12/15/2015 9:54 PM, Jim Laskey (Oracle) wrote: > At first glance it doesn?t seem to be thread related. We?ll poke at it but it would be helpful if you reduced the problem. > > ? Jim > > > >> On Dec 15, 2015, at 11:53 AM, Stijn de Witt wrote: >> >> Dear fellow developers, >> First of all thank you for your work on Nashorn. I am pretty excited at the possibilities of being able to integrate my two favorite languages, Java and Javascript. >> I have two concrete questions and a problem (which caused the questions): >> 1. Can a Nashorn engine be used across threads (using ScriptContext or Bindings for isolation)?2. Is there a good example of using Nashorn from a Servlet Filter? >> My problem: >> I am struggling with server-side rendering of React components using Nashorn. I am deploying to OpenShift and whenever I try to make my app listen to the rout route, I run into a weird ClassCastException somewhere inside the Nashorn code. I now think this is due to a heartbeat request OpenShift's haproxy is doing on my app that is causing (relatively) high load and triggering a concurrency problem... This leads me to believe I am doing something wrong in the way I create the script engine and using script contexts in a ThreadLocal to isolate the different threads. >> I have formulated my question, including logs and relevant code, on StackOverflow.com.http://stackoverflow.com/questions/34276136/classcastexception-nativeregexpexecresult-cannot-be-cast-to-nativearray >> >> Could one of you maybe have a look at my situation, specifically my servlet filter code and tell me if I am doing it wrong and if so, what I should change?(I tried instantiating a different engine per thread and saving them in a ThreadLocal, but this leads to OutOfMemory errors quickly) >> Thank you for any tips, pointers to docs etc that you could spare. >> With kind regards, >> -Stijn >> Stijn de Witthttp://stijndewitt.wordpress.com >> >> From sundararajan.athijegannathan at oracle.com Thu Dec 17 14:58:34 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 17 Dec 2015 20:28:34 +0530 Subject: [8u] approval request for 8145550: Megamorphic invoke should use CompiledFunction variants without any LinkLogic, 8145669: apply2call optimized callsite fails after becoming megamorphic Message-ID: <5672CD9A.6070809@oracle.com> Please approve the backport of the following fixes: 8145550: Megamorphic invoke should use CompiledFunction variants without any LinkLogic https://bugs.openjdk.java.net/browse/JDK-8145550 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005736.html 8145669: apply2call optimized callsite fails after becoming megamorphic https://bugs.openjdk.java.net/browse/JDK-8145669 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005747.html jdk8u-dev combined webrev: http://cr.openjdk.java.net/~sundar/8145550_8145669/8u/webrev.00/ Apart from the modular source layout changes, the tests have to be adjusted slightly for jdk8u -- as tests in jdk9 use a new Nashorn engine option that does not exist in jdk8u. For jdk8u, the tests use System property to configure megamorphic threshold and @fork option. I'm CC'ing nashorn-dev for review. Thanks, -Sundar From james.laskey at oracle.com Thu Dec 17 15:05:40 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 17 Dec 2015 11:05:40 -0400 Subject: [8u] approval request for 8145550: Megamorphic invoke should use CompiledFunction variants without any LinkLogic, 8145669: apply2call optimized callsite fails after becoming megamorphic In-Reply-To: <5672CD9A.6070809@oracle.com> References: <5672CD9A.6070809@oracle.com> Message-ID: +1 > On Dec 17, 2015, at 10:58 AM, Sundararajan Athijegannathan wrote: > > Please approve the backport of the following fixes: > > 8145550: Megamorphic invoke should use CompiledFunction variants without any LinkLogic > https://bugs.openjdk.java.net/browse/JDK-8145550 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005736.html > > 8145669: apply2call optimized callsite fails after becoming megamorphic > https://bugs.openjdk.java.net/browse/JDK-8145669 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005747.html > > jdk8u-dev combined webrev: > http://cr.openjdk.java.net/~sundar/8145550_8145669/8u/webrev.00/ > > Apart from the modular source layout changes, the tests have to be adjusted slightly for jdk8u -- as tests in jdk9 use a new Nashorn engine option that does not exist in jdk8u. For jdk8u, the tests use System property to configure megamorphic threshold and @fork option. I'm CC'ing nashorn-dev for review. > > Thanks, > -Sundar From sean.coffey at oracle.com Thu Dec 17 16:03:09 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 17 Dec 2015 16:03:09 +0000 Subject: [8u] approval request for 8145550: Megamorphic invoke should use CompiledFunction variants without any LinkLogic, 8145669: apply2call optimized callsite fails after becoming megamorphic In-Reply-To: References: <5672CD9A.6070809@oracle.com> Message-ID: <5672DCBD.6070801@oracle.com> Approved for jdk8u-dev. Regards, Sean. On 17/12/2015 15:05, Jim Laskey (Oracle) wrote: > +1 > >> On Dec 17, 2015, at 10:58 AM, Sundararajan Athijegannathan wrote: >> >> Please approve the backport of the following fixes: >> >> 8145550: Megamorphic invoke should use CompiledFunction variants without any LinkLogic >> https://bugs.openjdk.java.net/browse/JDK-8145550 >> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005736.html >> >> 8145669: apply2call optimized callsite fails after becoming megamorphic >> https://bugs.openjdk.java.net/browse/JDK-8145669 >> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005747.html >> >> jdk8u-dev combined webrev: >> http://cr.openjdk.java.net/~sundar/8145550_8145669/8u/webrev.00/ >> >> Apart from the modular source layout changes, the tests have to be adjusted slightly for jdk8u -- as tests in jdk9 use a new Nashorn engine option that does not exist in jdk8u. For jdk8u, the tests use System property to configure megamorphic threshold and @fork option. I'm CC'ing nashorn-dev for review. >> >> Thanks, >> -Sundar From sundararajan.athijegannathan at oracle.com Fri Dec 18 12:23:59 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 18 Dec 2015 17:53:59 +0530 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on Message-ID: <5673FADF.1040504@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8145750 Adding missing permissions for jdk.dynalink module. Note that it used to be part of jdk.scripting.nashorn module in the past and therefore got AllPermission. Thanks, -Sundar From Alan.Bateman at oracle.com Fri Dec 18 12:52:26 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Dec 2015 12:52:26 +0000 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on In-Reply-To: <5673FADF.1040504@oracle.com> References: <5673FADF.1040504@oracle.com> Message-ID: <5674018A.1040001@oracle.com> On 18/12/2015 12:23, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8145750 > > Adding missing permissions for jdk.dynalink module. Note that it used > to be part of jdk.scripting.nashorn module in the past and therefore > got AllPermission. Is it really necessary to grant it AllPermission? Just wondering how hard it would be to figure out the permissions that it really needs. If test/tools/jjs is new then it would be good to this test directory into one of the test groups so that the tests are run, maybe jdk_other. -Alan From sundararajan.athijegannathan at oracle.com Fri Dec 18 12:55:55 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 18 Dec 2015 18:25:55 +0530 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on In-Reply-To: <5674018A.1040001@oracle.com> References: <5673FADF.1040504@oracle.com> <5674018A.1040001@oracle.com> Message-ID: <5674025B.9090508@oracle.com> inline comments below.. On 12/18/2015 6:22 PM, Alan Bateman wrote: > > > On 18/12/2015 12:23, Sundararajan Athijegannathan wrote: >> Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8145750 >> >> Adding missing permissions for jdk.dynalink module. Note that it used >> to be part of jdk.scripting.nashorn module in the past and therefore >> got AllPermission. > Is it really necessary to grant it AllPermission? Just wondering how > hard it would be to figure out the permissions that it really needs. May be, not. But I tried giving only sun.reflect package access -- didn't work. There are a few doPrivileged blocks in dynalink code as well. This needs further analysis. But dynalink code was part of nashorn and so was getting AllPermission so far - so there is no permission enhancement by adding this missing permission block. That said, we can revisit reduced permission set for dynalink module. I'd prefer to track that as separate bug. > If test/tools/jjs is new then it would be good to this test directory > into one of the test groups so that the tests are run, maybe jdk_other. okay, I'll find out that. -Sundar > -Alan From hannes.wallnoefer at oracle.com Fri Dec 18 14:18:57 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 18 Dec 2015 15:18:57 +0100 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on In-Reply-To: <5673FADF.1040504@oracle.com> References: <5673FADF.1040504@oracle.com> Message-ID: <567415D1.2060607@oracle.com> Looks good. Some of the new test scripts have an incomplete @summary line, e.g. jjs-strictTest.sh: # @summary Test that output of 'jjs -strict' Hannes Am 2015-12-18 um 13:23 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8145750 > > Adding missing permissions for jdk.dynalink module. Note that it used > to be part of jdk.scripting.nashorn module in the past and therefore > got AllPermission. > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Fri Dec 18 14:54:53 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 18 Dec 2015 15:54:53 +0100 Subject: Review request for JDK-8143896: java.lang.Long is implicitly converted to double Message-ID: <56741E3D.4080504@oracle.com> Please review JDK-8143896: java.lang.Long is implicitly converted to double http://cr.openjdk.java.net/~hannesw/8143896/webrev/ Thanks, Hannes From sean.mullan at oracle.com Fri Dec 18 19:40:40 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 18 Dec 2015 14:40:40 -0500 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on In-Reply-To: <5674025B.9090508@oracle.com> References: <5673FADF.1040504@oracle.com> <5674018A.1040001@oracle.com> <5674025B.9090508@oracle.com> Message-ID: <56746138.5090806@oracle.com> On 12/18/2015 07:55 AM, Sundararajan Athijegannathan wrote: > inline comments below.. > > On 12/18/2015 6:22 PM, Alan Bateman wrote: >> >> >> On 18/12/2015 12:23, Sundararajan Athijegannathan wrote: >>> Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ >>> for https://bugs.openjdk.java.net/browse/JDK-8145750 >>> >>> Adding missing permissions for jdk.dynalink module. Note that it used >>> to be part of jdk.scripting.nashorn module in the past and therefore >>> got AllPermission. >> Is it really necessary to grant it AllPermission? Just wondering how >> hard it would be to figure out the permissions that it really needs. > > May be, not. But I tried giving only sun.reflect package access -- > didn't work. There are a few doPrivileged blocks in dynalink code as > well. This needs further analysis. > But dynalink code was part of nashorn and so was getting AllPermission > so far - so there is no permission enhancement by adding this missing > permission block. > > That said, we can revisit reduced permission set for dynalink module. > I'd prefer to track that as separate bug. Yes, please file a separate bug to track this as de-privileging is one of the main advantages of loading the module with the extension class loader. Thanks, Sean From Alan.Bateman at oracle.com Sun Dec 20 16:23:59 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 20 Dec 2015 16:23:59 +0000 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on In-Reply-To: <5674025B.9090508@oracle.com> References: <5673FADF.1040504@oracle.com> <5674018A.1040001@oracle.com> <5674025B.9090508@oracle.com> Message-ID: <5676D61F.9070408@oracle.com> On 18/12/2015 12:55, Sundararajan Athijegannathan wrote: > > May be, not. But I tried giving only sun.reflect package access -- > didn't work. There are a few doPrivileged blocks in dynalink code as > well. This needs further analysis. > But dynalink code was part of nashorn and so was getting AllPermission > so far - so there is no permission enhancement by adding this missing > permission block. > > That said, we can revisit reduced permission set for dynalink module. > I'd prefer to track that as separate bug. Sure, a separate bug is fine. > >> If test/tools/jjs is new then it would be good to this test directory >> into one of the test groups so that the tests are run, maybe jdk_other. > > okay, I'll find out that. Looks looks core_tools will execute tools/** so I think what you have here is okay. -Alan. From sundararajan.athijegannathan at oracle.com Mon Dec 21 04:11:34 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 21 Dec 2015 09:41:34 +0530 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on In-Reply-To: <5676D61F.9070408@oracle.com> References: <5673FADF.1040504@oracle.com> <5674018A.1040001@oracle.com> <5674025B.9090508@oracle.com> <5676D61F.9070408@oracle.com> Message-ID: <56777BF6.6010708@oracle.com> File a separate to track jdk.dynalink permissions: https://bugs.openjdk.java.net/browse/JDK-8145868 Adjusted test comments that Hannes mentioned and pushing changes in webrev @ http://cr.openjdk.java.net/~sundar/8145750/webrev.01/ Thanks -Sundar On 12/20/2015 9:53 PM, Alan Bateman wrote: > On 18/12/2015 12:55, Sundararajan Athijegannathan wrote: >> >> May be, not. But I tried giving only sun.reflect package access -- >> didn't work. There are a few doPrivileged blocks in dynalink code as >> well. This needs further analysis. >> But dynalink code was part of nashorn and so was getting >> AllPermission so far - so there is no permission enhancement by >> adding this missing permission block. >> >> That said, we can revisit reduced permission set for dynalink module. >> I'd prefer to track that as separate bug. > Sure, a separate bug is fine. > > >> >>> If test/tools/jjs is new then it would be good to this test >>> directory into one of the test groups so that the tests are run, >>> maybe jdk_other. >> >> okay, I'll find out that. > Looks looks core_tools will execute tools/** so I think what you have > here is okay. > > -Alan. From sundararajan.athijegannathan at oracle.com Mon Dec 21 04:35:05 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 21 Dec 2015 10:05:05 +0530 Subject: Review request for JDK-8143896: java.lang.Long is implicitly converted to double In-Reply-To: <56741E3D.4080504@oracle.com> References: <56741E3D.4080504@oracle.com> Message-ID: <56778179.2030007@oracle.com> Tests may be expanded to cover other Number subtypes like BigDecimal, BigInteger. -Sundar On 12/18/2015 8:24 PM, Hannes Wallnoefer wrote: > Please review JDK-8143896: java.lang.Long is implicitly converted to > double > > http://cr.openjdk.java.net/~hannesw/8143896/webrev/ > > Thanks, > Hannes From marcus at lagergren.net Mon Dec 21 14:15:45 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 21 Dec 2015 15:15:45 +0100 Subject: RFR 8145630: accidental debug printlns in NativeFunction.java In-Reply-To: <56724B8B.4050805@oracle.com> References: <56724B8B.4050805@oracle.com> Message-ID: +1 > On 17 Dec 2015, at 06:43, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8145630/ for https://bugs.openjdk.java.net/browse/JDK-8145630 > > Thanks, > -Sundar From vivin.paliath at gmail.com Mon Dec 21 22:49:02 2015 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Mon, 21 Dec 2015 15:49:02 -0700 Subject: Using === across different contexts Message-ID: I ran into an issue where === returns false even when both should be pointing to the same object. I'm assuming this is because one of the objects is wrapped by a ScriptObjectMirror, because it was defined in a different context. Here's some code that demonstrates this: ScriptEngine engine = new NashornScriptEngineFactory().getScriptEngine( new String[] { "-strict" } ); try { engine.eval("function Foo(src) { this.src = src }; var e = { x: new Foo(\"what\") };"); ScriptContext c = new SimpleScriptContext(); c.setBindings(engine.createBindings(), ScriptContext.ENGINE_SCOPE); c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); System.out.println(engine.eval("var z = e.x; z === e.x;", c)); } catch(Exception e) { throw new RuntimeException(e); } This prints out "false". Is there a way around this? I am also explicitly copying over all the bindings from the parent scope into the new scope so that I have access to "e". Could this be the source of the problem, and if so, is there a better way to achieve what I'm trying to do? -- Ruin untold; And thine own sadness, Sing in the grass, When eve has forgot, that no more hear common things that gleam and pass; But seek alone to lip, sad Rose of love and ruin untold; And thine own mother Can know it as I know More than another What makes your own sadness, Set in her eyes. map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". ":13:02:11:01:02:11:01:12:02";map{print chr unpack" i",pack"B32",$_}$j=~m/.{8}/g From vivin.paliath at gmail.com Mon Dec 21 22:56:49 2015 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Mon, 21 Dec 2015 15:56:49 -0700 Subject: Using === across different contexts In-Reply-To: References: Message-ID: One more thing I noticed is that apparently a new ScriptObjectMirror instance is probably being created each time x is dereferenced, so "e.x === e.x" also returns "false". On Mon, Dec 21, 2015 at 3:49 PM, Vivin Suresh Paliath < vivin.paliath at gmail.com> wrote: > I ran into an issue where === returns false even when both should be > pointing to the same object. I'm assuming this is because one of the > objects is wrapped by a ScriptObjectMirror, because it was defined in a > different context. > > Here's some code that demonstrates this: > > ScriptEngine engine = new > NashornScriptEngineFactory().getScriptEngine( > new String[] { "-strict" } > ); > > try { > engine.eval("function Foo(src) { this.src = src }; var e = { > x: new Foo(\"what\") };"); > > ScriptContext c = new SimpleScriptContext(); > c.setBindings(engine.createBindings(), > ScriptContext.ENGINE_SCOPE); > > c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); > > System.out.println(engine.eval("var z = e.x; z === e.x;", c)); > } catch(Exception e) { > throw new RuntimeException(e); > } > > This prints out "false". Is there a way around this? I am also explicitly > copying over all the bindings from the parent scope into the new scope so > that I have access to "e". Could this be the source of the problem, and if > so, is there a better way to achieve what I'm trying to do? > > -- > Ruin untold; > And thine own sadness, > Sing in the grass, > When eve has forgot, that no more hear common things that gleam and pass; > But seek alone to lip, sad Rose of love and ruin untold; > And thine own mother > Can know it as I know > More than another > What makes your own sadness, > Set in her eyes. > > map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". > ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". > ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". > ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". > ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". > ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". > ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". > ":13:02:11:01:02:11:01:12:02";map{print chr unpack" > i",pack"B32",$_}$j=~m/.{8}/g > -- Ruin untold; And thine own sadness, Sing in the grass, When eve has forgot, that no more hear common things that gleam and pass; But seek alone to lip, sad Rose of love and ruin untold; And thine own mother Can know it as I know More than another What makes your own sadness, Set in her eyes. map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". ":13:02:11:01:02:11:01:12:02";map{print chr unpack" i",pack"B32",$_}$j=~m/.{8}/g From sundararajan.athijegannathan at oracle.com Tue Dec 22 03:48:13 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 22 Dec 2015 09:18:13 +0530 Subject: Using === across different contexts In-Reply-To: References: Message-ID: <5678C7FD.4050700@oracle.com> Unless we create mirrors as weak refs internally (i.e., maintain 1:1 with underlying foreign object reference), there is no easy solution. And maintaining such weak refs is unnecessarily complex. "Foreign object" call/access is mean to be just a "lightweight wrapper" based access. That said, you can do the === on the foreign context itself. You can call ScriptObjectMirror's eval to evaluate === test in that foreign context. That would get right object identity. -Sundar On 12/22/2015 4:26 AM, Vivin Suresh Paliath wrote: > One more thing I noticed is that apparently a new ScriptObjectMirror > instance is probably being created each time x is dereferenced, so "e.x === > e.x" also returns "false". > > On Mon, Dec 21, 2015 at 3:49 PM, Vivin Suresh Paliath < > vivin.paliath at gmail.com> wrote: > >> I ran into an issue where === returns false even when both should be >> pointing to the same object. I'm assuming this is because one of the >> objects is wrapped by a ScriptObjectMirror, because it was defined in a >> different context. >> >> Here's some code that demonstrates this: >> >> ScriptEngine engine = new >> NashornScriptEngineFactory().getScriptEngine( >> new String[] { "-strict" } >> ); >> >> try { >> engine.eval("function Foo(src) { this.src = src }; var e = { >> x: new Foo(\"what\") };"); >> >> ScriptContext c = new SimpleScriptContext(); >> c.setBindings(engine.createBindings(), >> ScriptContext.ENGINE_SCOPE); >> >> c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); >> >> System.out.println(engine.eval("var z = e.x; z === e.x;", c)); >> } catch(Exception e) { >> throw new RuntimeException(e); >> } >> >> This prints out "false". Is there a way around this? I am also explicitly >> copying over all the bindings from the parent scope into the new scope so >> that I have access to "e". Could this be the source of the problem, and if >> so, is there a better way to achieve what I'm trying to do? >> >> -- >> Ruin untold; >> And thine own sadness, >> Sing in the grass, >> When eve has forgot, that no more hear common things that gleam and pass; >> But seek alone to lip, sad Rose of love and ruin untold; >> And thine own mother >> Can know it as I know >> More than another >> What makes your own sadness, >> Set in her eyes. >> >> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >> i",pack"B32",$_}$j=~m/.{8}/g >> > > From vivin.paliath at gmail.com Tue Dec 22 04:04:20 2015 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Mon, 21 Dec 2015 21:04:20 -0700 Subject: Using === across different contexts In-Reply-To: <5678C7FD.4050700@oracle.com> References: <5678C7FD.4050700@oracle.com> Message-ID: Thanks for the response! I understand that in general it would be difficult for foreign objects. But this seems like surprising behavior given that these are both JavaScript objects. That they are unequal seems to be an artifact of the implementation (the fact that JS objects from different contexts are treated as foreign). Could JS objects be treated differently? After going through the Nashorn source, I decided to try this very naive approach adding the following test to ScriptRuntime#equalSameTypeValues: if(x instanceof ScriptObjectMirror && y instanceof ScriptObjectMirror) { return x.equals(y); } After this change, the code now returns true, because ScriptObjectMirror#equals compares the actual objects. I am not sure if this breaks anything though (been trying to run the test suite, but end up getting some errors from make). Is there a reason this particular fix is a bad idea? I can't think of a particular reason why. From the perspective of the runtime, I can't see a reason why those two objects should be considered different. I will investigate the eval approach, but ideally I would like something that doesn't impose any changes on the JS code. I am developing a simple runtime that exposes some objects and utilities, and where custom scripts can run in their own contexts. The fact that === returns false in these cases leads to some very strange behavior. On Mon, Dec 21, 2015 at 8:48 PM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Unless we create mirrors as weak refs internally (i.e., maintain 1:1 with > underlying foreign object reference), there is no easy solution. And > maintaining such weak refs is unnecessarily complex. "Foreign object" > call/access is mean to be just a "lightweight wrapper" based access. That > said, you can do the === on the foreign context itself. You can call > ScriptObjectMirror's eval to evaluate === test in that foreign context. > That would get right object identity. > > -Sundar > > > On 12/22/2015 4:26 AM, Vivin Suresh Paliath wrote: > >> One more thing I noticed is that apparently a new ScriptObjectMirror >> instance is probably being created each time x is dereferenced, so "e.x >> === >> e.x" also returns "false". >> >> On Mon, Dec 21, 2015 at 3:49 PM, Vivin Suresh Paliath < >> vivin.paliath at gmail.com> wrote: >> >> I ran into an issue where === returns false even when both should be >>> pointing to the same object. I'm assuming this is because one of the >>> objects is wrapped by a ScriptObjectMirror, because it was defined in a >>> different context. >>> >>> Here's some code that demonstrates this: >>> >>> ScriptEngine engine = new >>> NashornScriptEngineFactory().getScriptEngine( >>> new String[] { "-strict" } >>> ); >>> >>> try { >>> engine.eval("function Foo(src) { this.src = src }; var e = { >>> x: new Foo(\"what\") };"); >>> >>> ScriptContext c = new SimpleScriptContext(); >>> c.setBindings(engine.createBindings(), >>> ScriptContext.ENGINE_SCOPE); >>> >>> >>> c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); >>> >>> System.out.println(engine.eval("var z = e.x; z === e.x;", >>> c)); >>> } catch(Exception e) { >>> throw new RuntimeException(e); >>> } >>> >>> This prints out "false". Is there a way around this? I am also explicitly >>> copying over all the bindings from the parent scope into the new scope so >>> that I have access to "e". Could this be the source of the problem, and >>> if >>> so, is there a better way to achieve what I'm trying to do? >>> >>> -- >>> Ruin untold; >>> And thine own sadness, >>> Sing in the grass, >>> When eve has forgot, that no more hear common things that gleam and pass; >>> But seek alone to lip, sad Rose of love and ruin untold; >>> And thine own mother >>> Can know it as I know >>> More than another >>> What makes your own sadness, >>> Set in her eyes. >>> >>> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >>> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >>> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >>> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >>> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >>> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >>> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >>> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >>> i",pack"B32",$_}$j=~m/.{8}/g >>> >>> >> >> > -- Ruin untold; And thine own sadness, Sing in the grass, When eve has forgot, that no more hear common things that gleam and pass; But seek alone to lip, sad Rose of love and ruin untold; And thine own mother Can know it as I know More than another What makes your own sadness, Set in her eyes. map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". ":13:02:11:01:02:11:01:12:02";map{print chr unpack" i",pack"B32",$_}$j=~m/.{8}/g From sundararajan.athijegannathan at oracle.com Tue Dec 22 04:10:27 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 22 Dec 2015 09:40:27 +0530 Subject: Using === across different contexts In-Reply-To: References: <5678C7FD.4050700@oracle.com> Message-ID: <5678CD33.80704@oracle.com> Actually, I'm not sure if depending on === in the code is a good approach -- particularly, for objects that are not script objects of the current world. These are to be treated like "host objects" in ECMAScript-speak. i.e., regular rules of script objects don't always apply to 'host objects'. The === operator for Java objects is interpreted as object identity -- and the same rule for ScriptObjectMirrors -- in that both are "host objects" from the standpoint of the 'current world'. -Sundar On 12/22/2015 9:34 AM, Vivin Suresh Paliath wrote: > Thanks for the response! I understand that in general it would be > difficult for foreign objects. But this seems like surprising behavior > given that these are both JavaScript objects. That they are unequal > seems to be an artifact of the implementation (the fact that JS > objects from different contexts are treated as foreign). Could JS > objects be treated differently? > > After going through the Nashorn source, I decided to try this very > naive approach adding the following test to > ScriptRuntime#equalSameTypeValues: > > if(x instanceof ScriptObjectMirror && y instanceof ScriptObjectMirror) { > return x.equals(y); > } > > After this change, the code now returns true, because > ScriptObjectMirror#equals compares the actual objects. I am not sure > if this breaks anything though (been trying to run the test suite, but > end up getting some errors from make). Is there a reason this > particular fix is a bad idea? I can't think of a particular reason > why. From the perspective of the runtime, I can't see a reason why > those two objects should be considered different. > > I will investigate the eval approach, but ideally I would like > something that doesn't impose any changes on the JS code. I am > developing a simple runtime that exposes some objects and utilities, > and where custom scripts can run in their own contexts. The fact that > === returns false in these cases leads to some very strange behavior. > > On Mon, Dec 21, 2015 at 8:48 PM, Sundararajan Athijegannathan > > wrote: > > Unless we create mirrors as weak refs internally (i.e., maintain > 1:1 with underlying foreign object reference), there is no easy > solution. And maintaining such weak refs is unnecessarily complex. > "Foreign object" call/access is mean to be just a "lightweight > wrapper" based access. That said, you can do the === on the > foreign context itself. You can call ScriptObjectMirror's eval to > evaluate === test in that foreign context. That would get right > object identity. > > -Sundar > > > On 12/22/2015 4:26 AM, Vivin Suresh Paliath wrote: > > One more thing I noticed is that apparently a new > ScriptObjectMirror > instance is probably being created each time x is > dereferenced, so "e.x === > e.x" also returns "false". > > On Mon, Dec 21, 2015 at 3:49 PM, Vivin Suresh Paliath < > vivin.paliath at gmail.com > wrote: > > I ran into an issue where === returns false even when both > should be > pointing to the same object. I'm assuming this is because > one of the > objects is wrapped by a ScriptObjectMirror, because it was > defined in a > different context. > > Here's some code that demonstrates this: > > ScriptEngine engine = new > NashornScriptEngineFactory().getScriptEngine( > new String[] { "-strict" } > ); > > try { > engine.eval("function Foo(src) { this.src = > src }; var e = { > x: new Foo(\"what\") };"); > > ScriptContext c = new SimpleScriptContext(); > c.setBindings(engine.createBindings(), > ScriptContext.ENGINE_SCOPE); > > c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); > > System.out.println(engine.eval("var z = e.x; > z === e.x;", c)); > } catch(Exception e) { > throw new RuntimeException(e); > } > > This prints out "false". Is there a way around this? I am > also explicitly > copying over all the bindings from the parent scope into > the new scope so > that I have access to "e". Could this be the source of the > problem, and if > so, is there a better way to achieve what I'm trying to do? > > -- > Ruin untold; > And thine own sadness, > Sing in the grass, > When eve has forgot, that no more hear common things that > gleam and pass; > But seek alone to lip, sad Rose of love and ruin untold; > And thine own mother > Can know it as I know > More than another > What makes your own sadness, > Set in her eyes. > > map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". > ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". > ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". > ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". > ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". > ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". > ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". > ":13:02:11:01:02:11:01:12:02";map{print chr unpack" > i",pack"B32",$_}$j=~m/.{8}/g > > > > > > > > -- > Ruin untold; > And thine own sadness, > Sing in the grass, > When eve has forgot, that no more hear common things that gleam and pass; > But seek alone to lip, sad Rose of love and ruin untold; > And thine own mother > Can know it as I know > More than another > What makes your own sadness, > Set in her eyes.| > > map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". > ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". > ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". > ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". > ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". > ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". > ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". > ":13:02:11:01:02:11:01:12:02";map{print chr unpack" > i",pack"B32",$_}$j=~m/.{8}/g > | From vivin.paliath at gmail.com Tue Dec 22 06:55:06 2015 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Mon, 21 Dec 2015 23:55:06 -0700 Subject: Using === across different contexts In-Reply-To: <5678CD33.80704@oracle.com> References: <5678C7FD.4050700@oracle.com> <5678CD33.80704@oracle.com> Message-ID: I am looking at it from the perspective of someone writing code that is expect to run in JavaScript environment. I will describe the runtime environment I have set up. Perhaps what I am running into is an artifact of my approach. I have a single script engine instance. In this context I evaluate some JS source that populates the JS global scope with some objects. When a custom script needs to be evaluated, I create a new script context with a new global. Then I copy over all bindings from the parent script context into the new one. I also have a module system. When a custom script requests a core module, the module source is evaluated in the main script context and a single instance of the object exposed by the module source is cached. This way the source only needs to be evaluated once and benefits from optimizations. The problem I am running into has to do with some singleton objects I expose; kind of like enums, and can be compared using ===. I am using a JS library for this and this behavior holds in the browser and on NodeJS. On Nashorn, because the instances were created in a different context, === returns false. Is there a better way to accomplish what I am doing? Regarding host objects, even if they are different from native objects, it seems strange to me that the semantics of things like === would be different especially when doing something like obj.prop === obj.prop. The fact that such a statement could ever return false is non-obvious unless implementation details of the runtime are known. I am trying to expose my runtime environment as a JS environment where a developer can write custom scripts using some runtime libraries and utilities. So behavior like this would be very surprising, and requiring them to know that objects might be from different contexts seems like abstraction leakage from the way I have implemented the runtime. They shouldn't have to know whether an object is a wrapped ScriptObjectMirror instance, since from their point of view they are just working with JS objects, and they don't know that they are from different "worlds" since they don't even know that there are different worlds. I guess I am also having a hard time seeing a scenario where === would need to return false in the scenario I described, unless as a developer you knew there were different worlds. Even then, it would essentially make some forms of equality comparisons impossible (e.g., o.prop === o.prop if o is foreign). Does the snippet I posted earlier make sense? On Dec 21, 2015 9:10 PM, "Sundararajan Athijegannathan" < sundararajan.athijegannathan at oracle.com> wrote: > Actually, I'm not sure if depending on === in the code is a good approach > -- particularly, for objects that are not script objects of the current > world. These are to be treated like "host objects" in ECMAScript-speak. > i.e., regular rules of script objects don't always apply to 'host > objects'. The === operator for Java objects is interpreted as object > identity -- and the same rule for ScriptObjectMirrors -- in that both are > "host objects" from the standpoint of the 'current world'. > > -Sundar > > On 12/22/2015 9:34 AM, Vivin Suresh Paliath wrote: > > Thanks for the response! I understand that in general it would be > difficult for foreign objects. But this seems like surprising behavior > given that these are both JavaScript objects. That they are unequal seems > to be an artifact of the implementation (the fact that JS objects from > different contexts are treated as foreign). Could JS objects be treated > differently? > > After going through the Nashorn source, I decided to try this very naive > approach adding the following test to ScriptRuntime#equalSameTypeValues: > > if(x instanceof ScriptObjectMirror && y instanceof ScriptObjectMirror) { > return x.equals(y); > } > > After this change, the code now returns true, because > ScriptObjectMirror#equals compares the actual objects. I am not sure if > this breaks anything though (been trying to run the test suite, but end up > getting some errors from make). Is there a reason this particular fix is a > bad idea? I can't think of a particular reason why. From the perspective of > the runtime, I can't see a reason why those two objects should be > considered different. > > I will investigate the eval approach, but ideally I would like something > that doesn't impose any changes on the JS code. I am developing a simple > runtime that exposes some objects and utilities, and where custom scripts > can run in their own contexts. The fact that === returns false in these > cases leads to some very strange behavior. > > On Mon, Dec 21, 2015 at 8:48 PM, Sundararajan Athijegannathan < > sundararajan.athijegannathan at oracle.com> wrote: > >> Unless we create mirrors as weak refs internally (i.e., maintain 1:1 with >> underlying foreign object reference), there is no easy solution. And >> maintaining such weak refs is unnecessarily complex. "Foreign object" >> call/access is mean to be just a "lightweight wrapper" based access. That >> said, you can do the === on the foreign context itself. You can call >> ScriptObjectMirror's eval to evaluate === test in that foreign context. >> That would get right object identity. >> >> -Sundar >> >> >> On 12/22/2015 4:26 AM, Vivin Suresh Paliath wrote: >> >>> One more thing I noticed is that apparently a new ScriptObjectMirror >>> instance is probably being created each time x is dereferenced, so "e.x >>> === >>> e.x" also returns "false". >>> >>> On Mon, Dec 21, 2015 at 3:49 PM, Vivin Suresh Paliath < >>> vivin.paliath at gmail.com> wrote: >>> >>> I ran into an issue where === returns false even when both should be >>>> pointing to the same object. I'm assuming this is because one of the >>>> objects is wrapped by a ScriptObjectMirror, because it was defined in a >>>> different context. >>>> >>>> Here's some code that demonstrates this: >>>> >>>> ScriptEngine engine = new >>>> NashornScriptEngineFactory().getScriptEngine( >>>> new String[] { "-strict" } >>>> ); >>>> >>>> try { >>>> engine.eval("function Foo(src) { this.src = src }; var e = >>>> { >>>> x: new Foo(\"what\") };"); >>>> >>>> ScriptContext c = new SimpleScriptContext(); >>>> c.setBindings(engine.createBindings(), >>>> ScriptContext.ENGINE_SCOPE); >>>> >>>> >>>> c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); >>>> >>>> System.out.println(engine.eval("var z = e.x; z === e.x;", >>>> c)); >>>> } catch(Exception e) { >>>> throw new RuntimeException(e); >>>> } >>>> >>>> This prints out "false". Is there a way around this? I am also >>>> explicitly >>>> copying over all the bindings from the parent scope into the new scope >>>> so >>>> that I have access to "e". Could this be the source of the problem, and >>>> if >>>> so, is there a better way to achieve what I'm trying to do? >>>> >>>> -- >>>> Ruin untold; >>>> And thine own sadness, >>>> Sing in the grass, >>>> When eve has forgot, that no more hear common things that gleam and >>>> pass; >>>> But seek alone to lip, sad Rose of love and ruin untold; >>>> And thine own mother >>>> Can know it as I know >>>> More than another >>>> What makes your own sadness, >>>> Set in her eyes. >>>> >>>> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >>>> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >>>> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >>>> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >>>> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >>>> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >>>> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >>>> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >>>> i",pack"B32",$_}$j=~m/.{8}/g >>>> >>>> >>> >>> >> > > > -- > Ruin untold; > And thine own sadness, > Sing in the grass, > When eve has forgot, that no more hear common things that gleam and pass; > But seek alone to lip, sad Rose of love and ruin untold; > And thine own mother > Can know it as I know > More than another > What makes your own sadness, > Set in her eyes. > > map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". > ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". > ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". > ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". > ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". > ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". > ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". > ":13:02:11:01:02:11:01:12:02";map{print chr unpack" > i",pack"B32",$_}$j=~m/.{8}/g > > > From sundararajan.athijegannathan at oracle.com Tue Dec 22 08:35:31 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 22 Dec 2015 14:05:31 +0530 Subject: Using === across different contexts In-Reply-To: References: <5678C7FD.4050700@oracle.com> <5678CD33.80704@oracle.com> Message-ID: <56790B53.8030503@oracle.com> Hi, May be I should explain the background on how nashorn treates "foreign/host" objects. Nashorn implements object access primitives like "get_property, set_property, get_method, call, new" via a series of dynalink linkers (http://openjdk.java.net/jeps/276). There is a linker for it's own objects (ScriptObject instances), there is one for Java objects ("beans linkers"), "foreign 'script' objects" (ScriptObjectMirrors). It allows even user specified linkers picked up via java.util.ServiceLoader mechanism. (See http://hg.openjdk.java.net/jdk9/dev/nashorn/file/74ddd1339c57/samples/dynalink). But, looping (via for, for..each), identity and other operators are natively implemented in Nashorn. Object identity is implemented strictly per ECMAScript spec - which says === evals to be evaluated true only if "same object". Why should we treat ScriptObjectMirrors as special for identity comparison (and who knows what problems it could cause than the ones it solves!). For eg. think of using that in j.u.IdentityHashMap and expect it work! [=== returns true and so IdentityHashMap should work as expected -- but it won't because IdentityHashMap goes by JVM level object identity! As I said, it at all we want mirrors to preserve identity, we need weak refs. / Regarding host objects, even if they are different from native objects, it seems strange to me that the semantics of things like === would be different especially when doing something like obj.prop === obj.prop. The fact that such a statement could ever return false is non-obvious unless implementation details of the runtime are known. / The fact that you're assuming your host objects return "same object" for doing two "obj.prop" evals -- is an assumption about mirror objects! Why do you think such as assumption to be true for mirrors -- whose sole purpose is to provide easy access to objects. You're creating multiple ScriptContexts and associate ENGINE_SCOPE Bindings to isolate. And yet you want objects from "isolated" worlds to be treated exactly like "current isolate world". If you do not want that kind of multiple ECMAScript global scope isolation at all, why not load your library/framework scripts before loading the user scripts? If you want to avoid clash b/w different user scripts (i.e., globals in user's scripts for eg.), you could implement "require" like primitive such as the one here -> https://github.com/walterhiggins/commonjs-modules-javax-script If you do want isolation and still want singleton enum-like objects, why not implement those in Java and expose to scripts? These would then be real JVM singleton objects and therefore usual identity would work. Hope this helps, -Sundar On 12/22/2015 12:25 PM, Vivin Suresh Paliath wrote: > > I am looking at it from the perspective of someone writing code that > is expect to run in JavaScript environment. I will describe the > runtime environment I have set up. Perhaps what I am running into is > an artifact of my approach. > > I have a single script engine instance. In this context I evaluate > some JS source that populates the JS global scope with some objects. > When a custom script needs to be evaluated, I create a new script > context with a new global. Then I copy over all bindings from the > parent script context into the new one. I also have a module system. > When a custom script requests a core module, the module source is > evaluated in the main script context and a single instance of the > object exposed by the module source is cached. This way the source > only needs to be evaluated once and benefits from optimizations. > > The problem I am running into has to do with some singleton objects I > expose; kind of like enums, and can be compared using ===. I am using > a JS library for this and this behavior holds in the browser and on > NodeJS. On Nashorn, because the instances were created in a different > context, === returns false. > > Is there a better way to accomplish what I am doing? > > Regarding host objects, even if they are different from native > objects, it seems strange to me that the semantics of things like === > would be different especially when doing something like obj.prop === > obj.prop. The fact that such a statement could ever return false is > non-obvious unless implementation details of the runtime are known. > > I am trying to expose my runtime environment as a JS environment where > a developer can write custom scripts using some runtime libraries and > utilities. So behavior like this would be very surprising, and > requiring them to know that objects might be from different contexts > seems like abstraction leakage from the way I have implemented the > runtime. They shouldn't have to know whether an object is a wrapped > ScriptObjectMirror instance, since from their point of view they are > just working with JS objects, and they don't know that they are from > different "worlds" since they don't even know that there are different > worlds. > > I guess I am also having a hard time seeing a scenario where === would > need to return false in the scenario I described, unless as a > developer you knew there were different worlds. Even then, it would > essentially make some forms of equality comparisons impossible (e.g., > o.prop === o.prop if o is foreign). > > Does the snippet I posted earlier make sense? > > On Dec 21, 2015 9:10 PM, "Sundararajan Athijegannathan" > > wrote: > > Actually, I'm not sure if depending on === in the code is a good > approach -- particularly, for objects that are not script objects > of the current world. These are to be treated like "host objects" > in ECMAScript-speak. i.e., regular rules of script objects don't > always apply to 'host objects'. The === operator for Java objects > is interpreted as object identity -- and the same rule for > ScriptObjectMirrors -- in that both are "host objects" from the > standpoint of the 'current world'. > > -Sundar > > On 12/22/2015 9:34 AM, Vivin Suresh Paliath wrote: >> Thanks for the response! I understand that in general it would be >> difficult for foreign objects. But this seems like surprising >> behavior given that these are both JavaScript objects. That they >> are unequal seems to be an artifact of the implementation (the >> fact that JS objects from different contexts are treated as >> foreign). Could JS objects be treated differently? >> >> After going through the Nashorn source, I decided to try this >> very naive approach adding the following test to >> ScriptRuntime#equalSameTypeValues: >> >> if(x instanceof ScriptObjectMirror && y instanceof >> ScriptObjectMirror) { >> return x.equals(y); >> } >> >> After this change, the code now returns true, because >> ScriptObjectMirror#equals compares the actual objects. I am not >> sure if this breaks anything though (been trying to run the test >> suite, but end up getting some errors from make). Is there a >> reason this particular fix is a bad idea? I can't think of a >> particular reason why. From the perspective of the runtime, I >> can't see a reason why those two objects should be considered >> different. >> >> I will investigate the eval approach, but ideally I would like >> something that doesn't impose any changes on the JS code. I am >> developing a simple runtime that exposes some objects and >> utilities, and where custom scripts can run in their own >> contexts. The fact that === returns false in these cases leads to >> some very strange behavior. >> >> On Mon, Dec 21, 2015 at 8:48 PM, Sundararajan Athijegannathan >> > > wrote: >> >> Unless we create mirrors as weak refs internally (i.e., >> maintain 1:1 with underlying foreign object reference), there >> is no easy solution. And maintaining such weak refs is >> unnecessarily complex. "Foreign object" call/access is mean >> to be just a "lightweight wrapper" based access. That said, >> you can do the === on the foreign context itself. You can >> call ScriptObjectMirror's eval to evaluate === test in that >> foreign context. That would get right object identity. >> >> -Sundar >> >> >> On 12/22/2015 4:26 AM, Vivin Suresh Paliath wrote: >> >> One more thing I noticed is that apparently a new >> ScriptObjectMirror >> instance is probably being created each time x is >> dereferenced, so "e.x === >> e.x" also returns "false". >> >> On Mon, Dec 21, 2015 at 3:49 PM, Vivin Suresh Paliath < >> vivin.paliath at gmail.com > >> wrote: >> >> I ran into an issue where === returns false even when >> both should be >> pointing to the same object. I'm assuming this is >> because one of the >> objects is wrapped by a ScriptObjectMirror, because >> it was defined in a >> different context. >> >> Here's some code that demonstrates this: >> >> ScriptEngine engine = new >> NashornScriptEngineFactory().getScriptEngine( >> new String[] { "-strict" } >> ); >> >> try { >> engine.eval("function Foo(src) { >> this.src = src }; var e = { >> x: new Foo(\"what\") };"); >> >> ScriptContext c = new SimpleScriptContext(); >> c.setBindings(engine.createBindings(), >> ScriptContext.ENGINE_SCOPE); >> >> c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); >> >> System.out.println(engine.eval("var z = e.x; z === >> e.x;", c)); >> } catch(Exception e) { >> throw new RuntimeException(e); >> } >> >> This prints out "false". Is there a way around this? >> I am also explicitly >> copying over all the bindings from the parent scope >> into the new scope so >> that I have access to "e". Could this be the source >> of the problem, and if >> so, is there a better way to achieve what I'm trying >> to do? >> >> -- >> Ruin untold; >> And thine own sadness, >> Sing in the grass, >> When eve has forgot, that no more hear common things >> that gleam and pass; >> But seek alone to lip, sad Rose of love and ruin untold; >> And thine own mother >> Can know it as I know >> More than another >> What makes your own sadness, >> Set in her eyes. >> >> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >> i",pack"B32",$_}$j=~m/.{8}/g >> >> >> >> >> >> >> >> -- >> Ruin untold; >> And thine own sadness, >> Sing in the grass, >> When eve has forgot, that no more hear common things that gleam >> and pass; >> But seek alone to lip, sad Rose of love and ruin untold; >> And thine own mother >> Can know it as I know >> More than another >> What makes your own sadness, >> Set in her eyes.| >> >> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >> i",pack"B32",$_}$j=~m/.{8}/g >> | > From vivin.paliath at gmail.com Tue Dec 22 20:11:18 2015 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Tue, 22 Dec 2015 13:11:18 -0700 Subject: Using === across different contexts In-Reply-To: <56790B53.8030503@oracle.com> References: <5678C7FD.4050700@oracle.com> <5678CD33.80704@oracle.com> <56790B53.8030503@oracle.com> Message-ID: Hi Sundar, Thank you for the explanation! I hope I am not being too obtuse - I'm just trying to get a handle on how things work! Object identity is implemented strictly per ECMAScript spec - which says > === evals to be evaluated true only if "same object". Why should we treat > ScriptObjectMirrors as special for identity comparison In my view, ScriptObjectMirrors should be treated the same only if it is made abundantly clear that the JavaScript object you're working with in Nashorn, may sometimes be a wrapped object and not the actual object itself. The problem is that right now there is no easy way to discern that, and anticipate the side effects that come with that distinction. With respect to the ES spec, I agree that === should evaluate to true if the objects are the same object, and that holds true for the most part even if the objects are wrapped. But the problem arises when you try to compare a property of an object (which is itself a JS object) with itself, where the parent object happens to be foreign. That's when you end up in a situation where obj === obj returns true, but obj.prop === obj.prop returns false. The assumption I am making is invalid only if I *know* that they are mirror objects, but as I mentioned before, there is no easy way to determine that. I can see a case where obj.prop is actually a getter that returns a new instance of an object each time, and here obj.prop === obj.prop would return false, but that fact would be evident from the source of the JS object itself, and wouldn't be due to how foreign script-objects are implemented in Nashorn. For eg. think of using that in j.u.IdentityHashMap and expect it work! [=== > returns true and so IdentityHashMap should work as expected -- but it won't > because IdentityHashMap goes by JVM level object identity! Perhaps I am not understanding this example correctly. Are you saying that inserts into the IdentityHashMap wouldn't work as expected? But wouldn't the only comparison that is being performed be == in Java, which would be comparing the ScriptObjectMirror instances anyway (i.e., the same behavior as now). I tried out the following with and without my changes and I got the same output (size of the map is 3): engine.eval("function Foo(src) { this.src = src }; var e = { x: new Foo(\"what\") };"); ScriptContext c = new SimpleScriptContext(); c.setBindings(engine.createBindings(), ScriptContext.ENGINE_SCOPE); c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); c.getBindings(ScriptContext.ENGINE_SCOPE).put("ihm", new IdentityHashMap()); engine.eval("ihm.put(e.x, 1); ihm.put(e.x, 2); ihm.put(e.x, 3); print(ihm.size());", c); The one discrepancy that would exist is if you perform an === comparison in JavaScript against something from the map. You're creating multiple ScriptContexts and associate ENGINE_SCOPE Bindings > to isolate. And yet you want objects from "isolated" worlds to be treated > exactly like "current isolate world". The new contexts I create know nothing about each other; they only "know" (in the sense that the "global" runtime-library objects are available) the objects from the main context (and only because I copy them over). Also, I am not treating the object from the main isolated-world the same way as the one in the current one; I am really only trying to compare references (and that too against themselves). > If you do not want that kind of multiple ECMAScript global scope isolation > at all, why not load your library/framework scripts before loading the user > scripts? If you want to avoid clash b/w different user scripts (i.e., > globals in user's scripts for eg.), you could implement "require" like > primitive such as the one here This is actually exactly what I am doing, and I am using require-like functionality as well. The problem arises when I try to dereference a property of an object that is a foreign script-object. For example, let's assume the default context of the script engine has an "enum" SomeEnum, with the enum CONST. When I get a custom script, I create a new context (using createBindings) and copy everything over. So now the new context has a foreign object called SomeEnum. Now if I do SomeEnum === SomeEnum, I get back true, but SomeEnum.CONST === SomeEnum.CONST returns false. Is this what you were saying weak-refs would solve? If you do want isolation and still want singleton enum-like objects, why > not implement those in Java and expose to scripts? These would then be real > JVM singleton objects and therefore usual identity would work. That would be a workaround, but some code that I insert are autogenerated JS equivalents of POJOs. Enums are implemented using this library, which gives you type-safe enums in JavaScript as well. So I cannot assume upfront what kind of Java enums are going to be used since they come from a different project entirely. Based on what you said, I agree with you that === is probably the wrong place to do this and it seems that the thing that really needs to be fixed is ensuring that properties of foreign objects return the same mirror instance whenever dereferenced. As I said before, I can't think of a case where obj.prop === obj.prop would return false *unless* prop is a calculated property that returns a new instance of some object each time. Even if that were the case, I don't see how that behavior would be broken if the Nashorn runtime ensured that we got back the same mirror instance. Regardless, wouldn't it notice that prop actually delegates to a getter function, and then run that? But in the case where prop is a reference to an actual object, you would still have the expected behavior. I understand that these foreign objects are wrapped, but I am questioning whether someone really needs to *know* that they are, if they are writing JS code on Nashorn. My original aim when I was doing this was to provide a single script-engine instance so that I could take advantage of optimizations on common code, while providing isolated execution contexts. Objects in the engine's default context are "read-only" and the isolated contexts cannot really mess with them. Really what I'm after is ensuring that library-code gets optimized over time and that contexts can't step over each other. So if such an approach gives me that, then it would definitely make things a lot easier. Also, is there somewhere I can read about the optimizations Nashorn makes in different cases? I'm specifically wondering about the following: 1. Does Nashorn optimize pre-compiled JS code each time it is evaluated? Are the optimizations persisted to the compiled representation? 2. If I repeatedly evaluate the same JS code in the same script-engine, but in different contexts, is that code optimized? Or are the optimizations discarded once the context is gone? If I can still get these optimizations, then I can simply just precompile and/or re-evaluate the library code in each new context and that would do away with this issue and make things much easier. Thank you once again, and I apologize for so many questions! Vivin On Tue, Dec 22, 2015 at 1:35 AM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Hi, > > May be I should explain the background on how nashorn treates > "foreign/host" objects. Nashorn implements object access primitives like > "get_property, set_property, get_method, call, new" via a series of > dynalink linkers (http://openjdk.java.net/jeps/276). There is a linker > for it's own objects (ScriptObject instances), there is one for Java > objects ("beans linkers"), "foreign 'script' objects" > (ScriptObjectMirrors). It allows even user specified linkers picked up via > java.util.ServiceLoader mechanism. (See > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/74ddd1339c57/samples/dynalink > ). > > But, looping (via for, for..each), identity and other operators are > natively implemented in Nashorn. Object identity is implemented strictly > per ECMAScript spec - which says === evals to be evaluated true only if > "same object". Why should we treat ScriptObjectMirrors as special for > identity comparison (and who knows what problems it could cause than the > ones it solves!). For eg. think of using that in j.u.IdentityHashMap and > expect it work! [=== returns true and so IdentityHashMap should work as > expected -- but it won't because IdentityHashMap goes by JVM level object > identity! As I said, it at all we want mirrors to preserve identity, we > need weak refs. > > / > > Regarding host objects, even if they are different from native objects, it > seems strange to me that the semantics of things like === would be > different especially when doing something like obj.prop === obj.prop. The > fact that such a statement could ever return false is non-obvious unless > implementation details of the runtime are known. > / > > The fact that you're assuming your host objects return "same object" for > doing two "obj.prop" evals -- is an assumption about mirror objects! Why do > you think such as assumption to be true for mirrors -- whose sole purpose > is to provide easy access to objects. You're creating multiple > ScriptContexts and associate ENGINE_SCOPE Bindings to isolate. And yet you > want objects from "isolated" worlds to be treated exactly like "current > isolate world". > > If you do not want that kind of multiple ECMAScript global scope isolation > at all, why not load your library/framework scripts before loading the user > scripts? If you want to avoid clash b/w different user scripts (i.e., > globals in user's scripts for eg.), you could implement "require" like > primitive such as the one here -> > https://github.com/walterhiggins/commonjs-modules-javax-script > > If you do want isolation and still want singleton enum-like objects, why > not implement those in Java and expose to scripts? These would then be real > JVM singleton objects and therefore usual identity would work. > > Hope this helps, > -Sundar > > > On 12/22/2015 12:25 PM, Vivin Suresh Paliath wrote: > > I am looking at it from the perspective of someone writing code that is > expect to run in JavaScript environment. I will describe the runtime > environment I have set up. Perhaps what I am running into is an artifact of > my approach. > > I have a single script engine instance. In this context I evaluate some JS > source that populates the JS global scope with some objects. When a custom > script needs to be evaluated, I create a new script context with a new > global. Then I copy over all bindings from the parent script context into > the new one. I also have a module system. When a custom script requests a > core module, the module source is evaluated in the main script context and > a single instance of the object exposed by the module source is cached. > This way the source only needs to be evaluated once and benefits from > optimizations. > > The problem I am running into has to do with some singleton objects I > expose; kind of like enums, and can be compared using ===. I am using a JS > library for this and this behavior holds in the browser and on NodeJS. On > Nashorn, because the instances were created in a different context, === > returns false. > > Is there a better way to accomplish what I am doing? > > Regarding host objects, even if they are different from native objects, it > seems strange to me that the semantics of things like === would be > different especially when doing something like obj.prop === obj.prop. The > fact that such a statement could ever return false is non-obvious unless > implementation details of the runtime are known. > > I am trying to expose my runtime environment as a JS environment where a > developer can write custom scripts using some runtime libraries and > utilities. So behavior like this would be very surprising, and requiring > them to know that objects might be from different contexts seems like > abstraction leakage from the way I have implemented the runtime. They > shouldn't have to know whether an object is a wrapped ScriptObjectMirror > instance, since from their point of view they are just working with JS > objects, and they don't know that they are from different "worlds" since > they don't even know that there are different worlds. > > I guess I am also having a hard time seeing a scenario where === would > need to return false in the scenario I described, unless as a developer you > knew there were different worlds. Even then, it would essentially make some > forms of equality comparisons impossible (e.g., o.prop === o.prop if o is > foreign). > > Does the snippet I posted earlier make sense? > On Dec 21, 2015 9:10 PM, "Sundararajan Athijegannathan" < > sundararajan.athijegannathan at oracle.com> wrote: > >> Actually, I'm not sure if depending on === in the code is a good approach >> -- particularly, for objects that are not script objects of the current >> world. These are to be treated like "host objects" in ECMAScript-speak. >> i.e., regular rules of script objects don't always apply to 'host >> objects'. The === operator for Java objects is interpreted as object >> identity -- and the same rule for ScriptObjectMirrors -- in that both are >> "host objects" from the standpoint of the 'current world'. >> >> -Sundar >> >> On 12/22/2015 9:34 AM, Vivin Suresh Paliath wrote: >> >> Thanks for the response! I understand that in general it would be >> difficult for foreign objects. But this seems like surprising behavior >> given that these are both JavaScript objects. That they are unequal seems >> to be an artifact of the implementation (the fact that JS objects from >> different contexts are treated as foreign). Could JS objects be treated >> differently? >> >> After going through the Nashorn source, I decided to try this very naive >> approach adding the following test to ScriptRuntime#equalSameTypeValues: >> >> if(x instanceof ScriptObjectMirror && y instanceof ScriptObjectMirror) { >> return x.equals(y); >> } >> >> After this change, the code now returns true, because >> ScriptObjectMirror#equals compares the actual objects. I am not sure if >> this breaks anything though (been trying to run the test suite, but end up >> getting some errors from make). Is there a reason this particular fix is a >> bad idea? I can't think of a particular reason why. From the perspective of >> the runtime, I can't see a reason why those two objects should be >> considered different. >> >> I will investigate the eval approach, but ideally I would like something >> that doesn't impose any changes on the JS code. I am developing a simple >> runtime that exposes some objects and utilities, and where custom scripts >> can run in their own contexts. The fact that === returns false in these >> cases leads to some very strange behavior. >> >> On Mon, Dec 21, 2015 at 8:48 PM, Sundararajan Athijegannathan < >> >> sundararajan.athijegannathan at oracle.com> wrote: >> >>> Unless we create mirrors as weak refs internally (i.e., maintain 1:1 >>> with underlying foreign object reference), there is no easy solution. And >>> maintaining such weak refs is unnecessarily complex. "Foreign object" >>> call/access is mean to be just a "lightweight wrapper" based access. That >>> said, you can do the === on the foreign context itself. You can call >>> ScriptObjectMirror's eval to evaluate === test in that foreign context. >>> That would get right object identity. >>> >>> -Sundar >>> >>> >>> On 12/22/2015 4:26 AM, Vivin Suresh Paliath wrote: >>> >>>> One more thing I noticed is that apparently a new ScriptObjectMirror >>>> instance is probably being created each time x is dereferenced, so "e.x >>>> === >>>> e.x" also returns "false". >>>> >>>> On Mon, Dec 21, 2015 at 3:49 PM, Vivin Suresh Paliath < >>>> vivin.paliath at gmail.com> wrote: >>>> >>>> I ran into an issue where === returns false even when both should be >>>>> pointing to the same object. I'm assuming this is because one of the >>>>> objects is wrapped by a ScriptObjectMirror, because it was defined in a >>>>> different context. >>>>> >>>>> Here's some code that demonstrates this: >>>>> >>>>> ScriptEngine engine = new >>>>> NashornScriptEngineFactory().getScriptEngine( >>>>> new String[] { "-strict" } >>>>> ); >>>>> >>>>> try { >>>>> engine.eval("function Foo(src) { this.src = src }; var e >>>>> = { >>>>> x: new Foo(\"what\") };"); >>>>> >>>>> ScriptContext c = new SimpleScriptContext(); >>>>> c.setBindings(engine.createBindings(), >>>>> ScriptContext.ENGINE_SCOPE); >>>>> >>>>> >>>>> c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); >>>>> >>>>> System.out.println(engine.eval("var z = e.x; z === e.x;", >>>>> c)); >>>>> } catch(Exception e) { >>>>> throw new RuntimeException(e); >>>>> } >>>>> >>>>> This prints out "false". Is there a way around this? I am also >>>>> explicitly >>>>> copying over all the bindings from the parent scope into the new scope >>>>> so >>>>> that I have access to "e". Could this be the source of the problem, >>>>> and if >>>>> so, is there a better way to achieve what I'm trying to do? >>>>> >>>>> -- >>>>> Ruin untold; >>>>> And thine own sadness, >>>>> Sing in the grass, >>>>> When eve has forgot, that no more hear common things that gleam and >>>>> pass; >>>>> But seek alone to lip, sad Rose of love and ruin untold; >>>>> And thine own mother >>>>> Can know it as I know >>>>> More than another >>>>> What makes your own sadness, >>>>> Set in her eyes. >>>>> >>>>> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >>>>> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >>>>> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >>>>> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >>>>> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >>>>> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >>>>> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >>>>> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >>>>> i",pack"B32",$_}$j=~m/.{8}/g >>>>> >>>>> >>>> >>>> >>> >> >> >> -- >> Ruin untold; >> And thine own sadness, >> Sing in the grass, >> When eve has forgot, that no more hear common things that gleam and pass; >> But seek alone to lip, sad Rose of love and ruin untold; >> And thine own mother >> Can know it as I know >> More than another >> What makes your own sadness, >> Set in her eyes. >> >> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >> i",pack"B32",$_}$j=~m/.{8}/g >> >> >> > -- Ruin untold; And thine own sadness, Sing in the grass, When eve has forgot, that no more hear common things that gleam and pass; But seek alone to lip, sad Rose of love and ruin untold; And thine own mother Can know it as I know More than another What makes your own sadness, Set in her eyes. map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". ":13:02:11:01:02:11:01:12:02";map{print chr unpack" i",pack"B32",$_}$j=~m/.{8}/g From szegedia at gmail.com Tue Dec 22 20:33:04 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 22 Dec 2015 21:33:04 +0100 Subject: Using === across different contexts In-Reply-To: References: <5678C7FD.4050700@oracle.com> <5678CD33.80704@oracle.com> <56790B53.8030503@oracle.com> Message-ID: Hi Vivin, let me chime in with some answers for you. We recommend using a single Nashorn ScriptEngine instance with your application. I have some StackOverflow posts that try to explain it: http://stackoverflow.com/questions/33690353/efficient-way-to-prepare-an-apache-commons-pool-of-nashorn-engines/34122641#34122641 http://stackoverflow.com/questions/30140103/should-i-use-a-separate-scriptengine-and-compiledscript-instances-per-each-threa/30159424#30159424 and maybe slightly less related but still helpful: http://stackoverflow.com/questions/27494130/nashorn-inefficiency/27562223#27562223 Also, I spoke about this issue at several conferences this year, e.g. here's the video of my GeekOut EE presentation: https://vimeo.com/131393786 If you don't want to watch it all, the relevant section starts around the 28th minute mark and lasts until minute 53. To answer your questions: 1. Does Nashorn optimize pre-compiled JS code each time it is evaluated? > Are the optimizations persisted to the compiled representation? > Yes. Especially if you cast your ScriptEngine to javax.script.Compilable and obtain CompiledScript instances. If you evaluate a CompiledScript in a new Bindings object, and your script mostly defines functions, it's very cheap. It'll just instantiate function objects -- they're cheap, just a tuple of (lexical scope, code) and the code was already precompiled and put them into bindings. > 2. If I repeatedly evaluate the same JS code in the same script-engine, > but in different contexts, is that code optimized? Or are the > optimizations > discarded once the context is gone? Code is maintained on a per-engine basis. If you create multiple Bindings (or ScriptContexts) within a single engine, the code is shared. Hope these help. Attila. On Tue, Dec 22, 2015 at 9:11 PM, Vivin Suresh Paliath < vivin.paliath at gmail.com> wrote: > Hi Sundar, > > Thank you for the explanation! I hope I am not being too obtuse - I'm just > trying to get a handle on how things work! > > Object identity is implemented strictly per ECMAScript spec - which says > > === evals to be evaluated true only if "same object". Why should we > treat > > ScriptObjectMirrors as special for identity comparison > > > In my view, ScriptObjectMirrors should be treated the same only if it is > made abundantly clear that the JavaScript object you're working with in > Nashorn, may sometimes be a wrapped object and not the actual object > itself. The problem is that right now there is no easy way to discern that, > and anticipate the side effects that come with that distinction. With > respect to the ES spec, I agree that === should evaluate to true if the > objects are the same object, and that holds true for the most part even if > the objects are wrapped. But the problem arises when you try to compare a > property of an object (which is itself a JS object) with itself, where the > parent object happens to be foreign. That's when you end up in a situation > where obj === obj returns true, but obj.prop === obj.prop returns false. > The assumption I am making is invalid only if I *know* that they are mirror > objects, but as I mentioned before, there is no easy way to determine that. > I can see a case where obj.prop is actually a getter that returns a new > instance of an object each time, and here obj.prop === obj.prop would > return false, but that fact would be evident from the source of the JS > object itself, and wouldn't be due to how foreign script-objects are > implemented in Nashorn. > > For eg. think of using that in j.u.IdentityHashMap and expect it work! [=== > > returns true and so IdentityHashMap should work as expected -- but it > won't > > because IdentityHashMap goes by JVM level object identity! > > > Perhaps I am not understanding this example correctly. Are you saying that > inserts into the IdentityHashMap wouldn't work as expected? But wouldn't > the only comparison that is being performed be == in Java, which would be > comparing the ScriptObjectMirror instances anyway (i.e., the same behavior > as now). I tried out the following with and without my changes and I got > the same output (size of the map is 3): > > engine.eval("function Foo(src) { this.src = src }; var e = { x: new > Foo(\"what\") };"); > > > ScriptContext c = new SimpleScriptContext(); > c.setBindings(engine.createBindings(), ScriptContext.ENGINE_SCOPE); > > c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); > > c.getBindings(ScriptContext.ENGINE_SCOPE).put("ihm", new > IdentityHashMap()); > engine.eval("ihm.put(e.x, 1); ihm.put(e.x, 2); ihm.put(e.x, 3); > print(ihm.size());", c); > > > The one discrepancy that would exist is if you perform an === comparison in > JavaScript against something from the map. > > You're creating multiple ScriptContexts and associate ENGINE_SCOPE Bindings > > to isolate. And yet you want objects from "isolated" worlds to be > treated > > exactly like "current isolate world". > > > The new contexts I create know nothing about each other; they only "know" > (in the sense that the "global" runtime-library objects are available) the > objects from the main context (and only because I copy them over). Also, I > am not treating the object from the main isolated-world the same way as the > one in the current one; I am really only trying to compare references (and > that too against themselves). > > > > If you do not want that kind of multiple ECMAScript global scope > isolation > > at all, why not load your library/framework scripts before loading the > user > > scripts? If you want to avoid clash b/w different user scripts (i.e., > > globals in user's scripts for eg.), you could implement "require" like > > primitive such as the one here > > > This is actually exactly what I am doing, and I am using require-like > functionality as well. The problem arises when I try to dereference a > property of an object that is a foreign script-object. For example, let's > assume the default context of the script engine has an "enum" SomeEnum, > with the enum CONST. When I get a custom script, I create a new context > (using createBindings) and copy everything over. So now the new context has > a foreign object called SomeEnum. Now if I do SomeEnum === SomeEnum, I get > back true, but SomeEnum.CONST === SomeEnum.CONST returns false. Is this > what you were saying weak-refs would solve? > > If you do want isolation and still want singleton enum-like objects, why > > not implement those in Java and expose to scripts? These would then be > real > > JVM singleton objects and therefore usual identity would work. > > > That would be a workaround, but some code that I insert are autogenerated > JS equivalents of POJOs. Enums are implemented using this > library, which gives you type-safe enums > in JavaScript as well. So I cannot assume upfront what kind of Java enums > are going to be used since they come from a different project entirely. > > Based on what you said, I agree with you that === is probably the wrong > place to do this and it seems that the thing that really needs to be fixed > is ensuring that properties of foreign objects return the same mirror > instance whenever dereferenced. As I said before, I can't think of a case > where obj.prop === obj.prop would return false *unless* prop is a > calculated property that returns a new instance of some object each time. > Even if that were the case, I don't see how that behavior would be broken > if the Nashorn runtime ensured that we got back the same mirror instance. > Regardless, wouldn't it notice that prop actually delegates to a getter > function, and then run that? But in the case where prop is a reference to > an actual object, you would still have the expected behavior. I understand > that these foreign objects are wrapped, but I am questioning whether > someone really needs to *know* that they are, if they are writing JS code > on Nashorn. > > My original aim when I was doing this was to provide a single script-engine > instance so that I could take advantage of optimizations on common code, > while providing isolated execution contexts. Objects in the engine's > default context are "read-only" and the isolated contexts cannot really > mess with them. Really what I'm after is ensuring that library-code gets > optimized over time and that contexts can't step over each other. So if > such an approach gives me that, then it would definitely make things a lot > easier. Also, is there somewhere I can read about the optimizations Nashorn > makes in different cases? I'm specifically wondering about the following: > > 1. Does Nashorn optimize pre-compiled JS code each time it is evaluated? > Are the optimizations persisted to the compiled representation? > 2. If I repeatedly evaluate the same JS code in the same script-engine, > but in different contexts, is that code optimized? Or are the > optimizations > discarded once the context is gone? > > If I can still get these optimizations, then I can simply just precompile > and/or re-evaluate the library code in each new context and that would do > away with this issue and make things much easier. > > Thank you once again, and I apologize for so many questions! > > Vivin > > On Tue, Dec 22, 2015 at 1:35 AM, Sundararajan Athijegannathan < > sundararajan.athijegannathan at oracle.com> wrote: > > > Hi, > > > > May be I should explain the background on how nashorn treates > > "foreign/host" objects. Nashorn implements object access primitives like > > "get_property, set_property, get_method, call, new" via a series of > > dynalink linkers (http://openjdk.java.net/jeps/276). There is a linker > > for it's own objects (ScriptObject instances), there is one for Java > > objects ("beans linkers"), "foreign 'script' objects" > > (ScriptObjectMirrors). It allows even user specified linkers picked up > via > > java.util.ServiceLoader mechanism. (See > > > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/74ddd1339c57/samples/dynalink > > ). > > > > But, looping (via for, for..each), identity and other operators are > > natively implemented in Nashorn. Object identity is implemented strictly > > per ECMAScript spec - which says === evals to be evaluated true only if > > "same object". Why should we treat ScriptObjectMirrors as special for > > identity comparison (and who knows what problems it could cause than the > > ones it solves!). For eg. think of using that in j.u.IdentityHashMap and > > expect it work! [=== returns true and so IdentityHashMap should work as > > expected -- but it won't because IdentityHashMap goes by JVM level object > > identity! As I said, it at all we want mirrors to preserve identity, we > > need weak refs. > > > > / > > > > Regarding host objects, even if they are different from native objects, > it > > seems strange to me that the semantics of things like === would be > > different especially when doing something like obj.prop === obj.prop. The > > fact that such a statement could ever return false is non-obvious unless > > implementation details of the runtime are known. > > / > > > > The fact that you're assuming your host objects return "same object" for > > doing two "obj.prop" evals -- is an assumption about mirror objects! Why > do > > you think such as assumption to be true for mirrors -- whose sole purpose > > is to provide easy access to objects. You're creating multiple > > ScriptContexts and associate ENGINE_SCOPE Bindings to isolate. And yet > you > > want objects from "isolated" worlds to be treated exactly like "current > > isolate world". > > > > If you do not want that kind of multiple ECMAScript global scope > isolation > > at all, why not load your library/framework scripts before loading the > user > > scripts? If you want to avoid clash b/w different user scripts (i.e., > > globals in user's scripts for eg.), you could implement "require" like > > primitive such as the one here -> > > https://github.com/walterhiggins/commonjs-modules-javax-script > > > > If you do want isolation and still want singleton enum-like objects, why > > not implement those in Java and expose to scripts? These would then be > real > > JVM singleton objects and therefore usual identity would work. > > > > Hope this helps, > > -Sundar > > > > > > On 12/22/2015 12:25 PM, Vivin Suresh Paliath wrote: > > > > I am looking at it from the perspective of someone writing code that is > > expect to run in JavaScript environment. I will describe the runtime > > environment I have set up. Perhaps what I am running into is an artifact > of > > my approach. > > > > I have a single script engine instance. In this context I evaluate some > JS > > source that populates the JS global scope with some objects. When a > custom > > script needs to be evaluated, I create a new script context with a new > > global. Then I copy over all bindings from the parent script context into > > the new one. I also have a module system. When a custom script requests a > > core module, the module source is evaluated in the main script context > and > > a single instance of the object exposed by the module source is cached. > > This way the source only needs to be evaluated once and benefits from > > optimizations. > > > > The problem I am running into has to do with some singleton objects I > > expose; kind of like enums, and can be compared using ===. I am using a > JS > > library for this and this behavior holds in the browser and on NodeJS. On > > Nashorn, because the instances were created in a different context, === > > returns false. > > > > Is there a better way to accomplish what I am doing? > > > > Regarding host objects, even if they are different from native objects, > it > > seems strange to me that the semantics of things like === would be > > different especially when doing something like obj.prop === obj.prop. The > > fact that such a statement could ever return false is non-obvious unless > > implementation details of the runtime are known. > > > > I am trying to expose my runtime environment as a JS environment where a > > developer can write custom scripts using some runtime libraries and > > utilities. So behavior like this would be very surprising, and requiring > > them to know that objects might be from different contexts seems like > > abstraction leakage from the way I have implemented the runtime. They > > shouldn't have to know whether an object is a wrapped ScriptObjectMirror > > instance, since from their point of view they are just working with JS > > objects, and they don't know that they are from different "worlds" since > > they don't even know that there are different worlds. > > > > I guess I am also having a hard time seeing a scenario where === would > > need to return false in the scenario I described, unless as a developer > you > > knew there were different worlds. Even then, it would essentially make > some > > forms of equality comparisons impossible (e.g., o.prop === o.prop if o is > > foreign). > > > > Does the snippet I posted earlier make sense? > > On Dec 21, 2015 9:10 PM, "Sundararajan Athijegannathan" < > > sundararajan.athijegannathan at oracle.com> wrote: > > > >> Actually, I'm not sure if depending on === in the code is a good > approach > >> -- particularly, for objects that are not script objects of the current > >> world. These are to be treated like "host objects" in ECMAScript-speak. > >> i.e., regular rules of script objects don't always apply to 'host > >> objects'. The === operator for Java objects is interpreted as object > >> identity -- and the same rule for ScriptObjectMirrors -- in that both > are > >> "host objects" from the standpoint of the 'current world'. > >> > >> -Sundar > >> > >> On 12/22/2015 9:34 AM, Vivin Suresh Paliath wrote: > >> > >> Thanks for the response! I understand that in general it would be > >> difficult for foreign objects. But this seems like surprising behavior > >> given that these are both JavaScript objects. That they are unequal > seems > >> to be an artifact of the implementation (the fact that JS objects from > >> different contexts are treated as foreign). Could JS objects be treated > >> differently? > >> > >> After going through the Nashorn source, I decided to try this very naive > >> approach adding the following test to ScriptRuntime#equalSameTypeValues: > >> > >> if(x instanceof ScriptObjectMirror && y instanceof ScriptObjectMirror) { > >> return x.equals(y); > >> } > >> > >> After this change, the code now returns true, because > >> ScriptObjectMirror#equals compares the actual objects. I am not sure if > >> this breaks anything though (been trying to run the test suite, but end > up > >> getting some errors from make). Is there a reason this particular fix > is a > >> bad idea? I can't think of a particular reason why. From the > perspective of > >> the runtime, I can't see a reason why those two objects should be > >> considered different. > >> > >> I will investigate the eval approach, but ideally I would like something > >> that doesn't impose any changes on the JS code. I am developing a simple > >> runtime that exposes some objects and utilities, and where custom > scripts > >> can run in their own contexts. The fact that === returns false in these > >> cases leads to some very strange behavior. > >> > >> On Mon, Dec 21, 2015 at 8:48 PM, Sundararajan Athijegannathan < > >> > >> sundararajan.athijegannathan at oracle.com> wrote: > >> > >>> Unless we create mirrors as weak refs internally (i.e., maintain 1:1 > >>> with underlying foreign object reference), there is no easy solution. > And > >>> maintaining such weak refs is unnecessarily complex. "Foreign object" > >>> call/access is mean to be just a "lightweight wrapper" based access. > That > >>> said, you can do the === on the foreign context itself. You can call > >>> ScriptObjectMirror's eval to evaluate === test in that foreign context. > >>> That would get right object identity. > >>> > >>> -Sundar > >>> > >>> > >>> On 12/22/2015 4:26 AM, Vivin Suresh Paliath wrote: > >>> > >>>> One more thing I noticed is that apparently a new ScriptObjectMirror > >>>> instance is probably being created each time x is dereferenced, so > "e.x > >>>> === > >>>> e.x" also returns "false". > >>>> > >>>> On Mon, Dec 21, 2015 at 3:49 PM, Vivin Suresh Paliath < > >>>> vivin.paliath at gmail.com> wrote: > >>>> > >>>> I ran into an issue where === returns false even when both should be > >>>>> pointing to the same object. I'm assuming this is because one of the > >>>>> objects is wrapped by a ScriptObjectMirror, because it was defined > in a > >>>>> different context. > >>>>> > >>>>> Here's some code that demonstrates this: > >>>>> > >>>>> ScriptEngine engine = new > >>>>> NashornScriptEngineFactory().getScriptEngine( > >>>>> new String[] { "-strict" } > >>>>> ); > >>>>> > >>>>> try { > >>>>> engine.eval("function Foo(src) { this.src = src }; var e > >>>>> = { > >>>>> x: new Foo(\"what\") };"); > >>>>> > >>>>> ScriptContext c = new SimpleScriptContext(); > >>>>> c.setBindings(engine.createBindings(), > >>>>> ScriptContext.ENGINE_SCOPE); > >>>>> > >>>>> > >>>>> > c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); > >>>>> > >>>>> System.out.println(engine.eval("var z = e.x; z === > e.x;", > >>>>> c)); > >>>>> } catch(Exception e) { > >>>>> throw new RuntimeException(e); > >>>>> } > >>>>> > >>>>> This prints out "false". Is there a way around this? I am also > >>>>> explicitly > >>>>> copying over all the bindings from the parent scope into the new > scope > >>>>> so > >>>>> that I have access to "e". Could this be the source of the problem, > >>>>> and if > >>>>> so, is there a better way to achieve what I'm trying to do? > >>>>> > >>>>> -- > >>>>> Ruin untold; > >>>>> And thine own sadness, > >>>>> Sing in the grass, > >>>>> When eve has forgot, that no more hear common things that gleam and > >>>>> pass; > >>>>> But seek alone to lip, sad Rose of love and ruin untold; > >>>>> And thine own mother > >>>>> Can know it as I know > >>>>> More than another > >>>>> What makes your own sadness, > >>>>> Set in her eyes. > >>>>> > >>>>> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". > >>>>> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". > >>>>> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". > >>>>> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". > >>>>> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". > >>>>> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". > >>>>> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". > >>>>> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" > >>>>> i",pack"B32",$_}$j=~m/.{8}/g > >>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > >> -- > >> Ruin untold; > >> And thine own sadness, > >> Sing in the grass, > >> When eve has forgot, that no more hear common things that gleam and > pass; > >> But seek alone to lip, sad Rose of love and ruin untold; > >> And thine own mother > >> Can know it as I know > >> More than another > >> What makes your own sadness, > >> Set in her eyes. > >> > >> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". > >> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". > >> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". > >> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". > >> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". > >> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". > >> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". > >> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" > >> i",pack"B32",$_}$j=~m/.{8}/g > >> > >> > >> > > > > > -- > Ruin untold; > And thine own sadness, > Sing in the grass, > When eve has forgot, that no more hear common things that gleam and pass; > But seek alone to lip, sad Rose of love and ruin untold; > And thine own mother > Can know it as I know > More than another > What makes your own sadness, > Set in her eyes. > > map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". > ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". > ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". > ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". > ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". > ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". > ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". > ":13:02:11:01:02:11:01:12:02";map{print chr unpack" > i",pack"B32",$_}$j=~m/.{8}/g > From vivin.paliath at gmail.com Tue Dec 22 21:24:51 2015 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Tue, 22 Dec 2015 14:24:51 -0700 Subject: Using === across different contexts In-Reply-To: References: <5678C7FD.4050700@oracle.com> <5678CD33.80704@oracle.com> <56790B53.8030503@oracle.com> Message-ID: Thank you Attila and Sundar! It looks like the way I was going about it was needlessly complex. I think I will use the compiled-script approach and precompile when it is first requested. Then on subsequent requests I can just evaluate the compiled script. I ran some rough benchmarks, and the performance of repeated eval in separate contexts vs repeated eval of precompiled code in separate contexts (all in the same engine) seems to be about the same; it is not as performant as evaluating once and then repeatedly running, but the difference is extremely small (around 10ms on my machine). Attila, thank you also for the SO links and the link to the video. I will go over those (the second SO link addresses my question really well). On Tue, Dec 22, 2015 at 1:33 PM, Attila Szegedi wrote: > Hi Vivin, > > let me chime in with some answers for you. > > We recommend using a single Nashorn ScriptEngine instance with your > application. I have some StackOverflow posts that try to explain it: > > > http://stackoverflow.com/questions/33690353/efficient-way-to-prepare-an-apache-commons-pool-of-nashorn-engines/34122641#34122641 > > > http://stackoverflow.com/questions/30140103/should-i-use-a-separate-scriptengine-and-compiledscript-instances-per-each-threa/30159424#30159424 > > and maybe slightly less related but still helpful: > > > http://stackoverflow.com/questions/27494130/nashorn-inefficiency/27562223#27562223 > > Also, I spoke about this issue at several conferences this year, e.g. > here's the video of my GeekOut EE presentation: > https://vimeo.com/131393786 If you don't want to watch it all, the > relevant section starts around the 28th minute mark and lasts until minute > 53. > > To answer your questions: > > 1. Does Nashorn optimize pre-compiled JS code each time it is evaluated? >> Are the optimizations persisted to the compiled representation? >> > > Yes. Especially if you cast your ScriptEngine to javax.script.Compilable > and obtain CompiledScript instances. If you evaluate a CompiledScript in a > new Bindings object, and your script mostly defines functions, it's very > cheap. It'll just instantiate function objects -- they're cheap, just a > tuple of (lexical scope, code) and the code was already precompiled and put > them into bindings. > > >> 2. If I repeatedly evaluate the same JS code in the same script-engine, >> but in different contexts, is that code optimized? Or are the >> optimizations >> discarded once the context is gone? > > > Code is maintained on a per-engine basis. If you create multiple Bindings > (or ScriptContexts) within a single engine, the code is shared. > > Hope these help. > > Attila. > > > On Tue, Dec 22, 2015 at 9:11 PM, Vivin Suresh Paliath < > vivin.paliath at gmail.com> wrote: > >> Hi Sundar, >> >> Thank you for the explanation! I hope I am not being too obtuse - I'm just >> trying to get a handle on how things work! >> >> Object identity is implemented strictly per ECMAScript spec - which says >> > === evals to be evaluated true only if "same object". Why should we >> treat >> > ScriptObjectMirrors as special for identity comparison >> >> >> In my view, ScriptObjectMirrors should be treated the same only if it is >> made abundantly clear that the JavaScript object you're working with in >> Nashorn, may sometimes be a wrapped object and not the actual object >> itself. The problem is that right now there is no easy way to discern >> that, >> and anticipate the side effects that come with that distinction. With >> respect to the ES spec, I agree that === should evaluate to true if the >> objects are the same object, and that holds true for the most part even if >> the objects are wrapped. But the problem arises when you try to compare a >> property of an object (which is itself a JS object) with itself, where the >> parent object happens to be foreign. That's when you end up in a situation >> where obj === obj returns true, but obj.prop === obj.prop returns false. >> The assumption I am making is invalid only if I *know* that they are >> mirror >> >> objects, but as I mentioned before, there is no easy way to determine >> that. >> I can see a case where obj.prop is actually a getter that returns a new >> instance of an object each time, and here obj.prop === obj.prop would >> return false, but that fact would be evident from the source of the JS >> object itself, and wouldn't be due to how foreign script-objects are >> implemented in Nashorn. >> >> For eg. think of using that in j.u.IdentityHashMap and expect it work! >> [=== >> > returns true and so IdentityHashMap should work as expected -- but it >> won't >> > because IdentityHashMap goes by JVM level object identity! >> >> >> Perhaps I am not understanding this example correctly. Are you saying that >> inserts into the IdentityHashMap wouldn't work as expected? But wouldn't >> the only comparison that is being performed be == in Java, which would be >> comparing the ScriptObjectMirror instances anyway (i.e., the same behavior >> as now). I tried out the following with and without my changes and I got >> the same output (size of the map is 3): >> >> engine.eval("function Foo(src) { this.src = src }; var e = { x: new >> Foo(\"what\") };"); >> >> >> ScriptContext c = new SimpleScriptContext(); >> c.setBindings(engine.createBindings(), ScriptContext.ENGINE_SCOPE); >> >> c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); >> >> c.getBindings(ScriptContext.ENGINE_SCOPE).put("ihm", new >> IdentityHashMap()); >> engine.eval("ihm.put(e.x, 1); ihm.put(e.x, 2); ihm.put(e.x, 3); >> print(ihm.size());", c); >> >> >> The one discrepancy that would exist is if you perform an === comparison >> in >> JavaScript against something from the map. >> >> You're creating multiple ScriptContexts and associate ENGINE_SCOPE >> Bindings >> > to isolate. And yet you want objects from "isolated" worlds to be >> treated >> > exactly like "current isolate world". >> >> >> The new contexts I create know nothing about each other; they only "know" >> (in the sense that the "global" runtime-library objects are available) the >> objects from the main context (and only because I copy them over). Also, I >> am not treating the object from the main isolated-world the same way as >> the >> one in the current one; I am really only trying to compare references (and >> that too against themselves). >> >> >> > If you do not want that kind of multiple ECMAScript global scope >> isolation >> > at all, why not load your library/framework scripts before loading the >> user >> > scripts? If you want to avoid clash b/w different user scripts (i.e., >> > globals in user's scripts for eg.), you could implement "require" like >> > primitive such as the one here >> >> >> This is actually exactly what I am doing, and I am using require-like >> functionality as well. The problem arises when I try to dereference a >> property of an object that is a foreign script-object. For example, let's >> assume the default context of the script engine has an "enum" SomeEnum, >> with the enum CONST. When I get a custom script, I create a new context >> (using createBindings) and copy everything over. So now the new context >> has >> a foreign object called SomeEnum. Now if I do SomeEnum === SomeEnum, I get >> back true, but SomeEnum.CONST === SomeEnum.CONST returns false. Is this >> what you were saying weak-refs would solve? >> >> If you do want isolation and still want singleton enum-like objects, why >> > not implement those in Java and expose to scripts? These would then be >> real >> > JVM singleton objects and therefore usual identity would work. >> >> >> That would be a workaround, but some code that I insert are autogenerated >> JS equivalents of POJOs. Enums are implemented using this >> library, which gives you type-safe >> enums >> in JavaScript as well. So I cannot assume upfront what kind of Java enums >> are going to be used since they come from a different project entirely. >> >> Based on what you said, I agree with you that === is probably the wrong >> place to do this and it seems that the thing that really needs to be fixed >> is ensuring that properties of foreign objects return the same mirror >> instance whenever dereferenced. As I said before, I can't think of a case >> where obj.prop === obj.prop would return false *unless* prop is a >> calculated property that returns a new instance of some object each time. >> Even if that were the case, I don't see how that behavior would be broken >> if the Nashorn runtime ensured that we got back the same mirror instance. >> Regardless, wouldn't it notice that prop actually delegates to a getter >> function, and then run that? But in the case where prop is a reference to >> an actual object, you would still have the expected behavior. I understand >> that these foreign objects are wrapped, but I am questioning whether >> someone really needs to *know* that they are, if they are writing JS code >> on Nashorn. >> >> My original aim when I was doing this was to provide a single >> script-engine >> instance so that I could take advantage of optimizations on common code, >> while providing isolated execution contexts. Objects in the engine's >> default context are "read-only" and the isolated contexts cannot really >> mess with them. Really what I'm after is ensuring that library-code gets >> optimized over time and that contexts can't step over each other. So if >> such an approach gives me that, then it would definitely make things a lot >> easier. Also, is there somewhere I can read about the optimizations >> Nashorn >> makes in different cases? I'm specifically wondering about the following: >> >> 1. Does Nashorn optimize pre-compiled JS code each time it is >> evaluated? >> Are the optimizations persisted to the compiled representation? >> 2. If I repeatedly evaluate the same JS code in the same script-engine, >> >> but in different contexts, is that code optimized? Or are the >> optimizations >> discarded once the context is gone? >> >> If I can still get these optimizations, then I can simply just precompile >> and/or re-evaluate the library code in each new context and that would do >> away with this issue and make things much easier. >> >> Thank you once again, and I apologize for so many questions! >> >> Vivin >> >> On Tue, Dec 22, 2015 at 1:35 AM, Sundararajan Athijegannathan < >> sundararajan.athijegannathan at oracle.com> wrote: >> >> > Hi, >> > >> > May be I should explain the background on how nashorn treates >> > "foreign/host" objects. Nashorn implements object access primitives >> like >> > "get_property, set_property, get_method, call, new" via a series of >> > dynalink linkers (http://openjdk.java.net/jeps/276). There is a linker >> > for it's own objects (ScriptObject instances), there is one for Java >> > objects ("beans linkers"), "foreign 'script' objects" >> > (ScriptObjectMirrors). It allows even user specified linkers picked up >> via >> > java.util.ServiceLoader mechanism. (See >> > >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/74ddd1339c57/samples/dynalink >> > ). >> > >> > But, looping (via for, for..each), identity and other operators are >> > natively implemented in Nashorn. Object identity is implemented strictly >> > per ECMAScript spec - which says === evals to be evaluated true only if >> > "same object". Why should we treat ScriptObjectMirrors as special for >> > identity comparison (and who knows what problems it could cause than the >> > ones it solves!). For eg. think of using that in j.u.IdentityHashMap and >> > expect it work! [=== returns true and so IdentityHashMap should work as >> > expected -- but it won't because IdentityHashMap goes by JVM level >> object >> > identity! As I said, it at all we want mirrors to preserve identity, we >> > need weak refs. >> > >> > / >> > >> > Regarding host objects, even if they are different from native objects, >> it >> > seems strange to me that the semantics of things like === would be >> > different especially when doing something like obj.prop === obj.prop. >> The >> > fact that such a statement could ever return false is non-obvious unless >> > implementation details of the runtime are known. >> > / >> > >> > The fact that you're assuming your host objects return "same object" for >> > doing two "obj.prop" evals -- is an assumption about mirror objects! >> Why do >> > you think such as assumption to be true for mirrors -- whose sole >> purpose >> > is to provide easy access to objects. You're creating multiple >> > ScriptContexts and associate ENGINE_SCOPE Bindings to isolate. And yet >> you >> > want objects from "isolated" worlds to be treated exactly like "current >> > isolate world". >> > >> > If you do not want that kind of multiple ECMAScript global scope >> isolation >> > at all, why not load your library/framework scripts before loading the >> user >> > scripts? If you want to avoid clash b/w different user scripts (i.e., >> > globals in user's scripts for eg.), you could implement "require" like >> > primitive such as the one here -> >> > https://github.com/walterhiggins/commonjs-modules-javax-script >> > >> > If you do want isolation and still want singleton enum-like objects, why >> > not implement those in Java and expose to scripts? These would then be >> real >> > JVM singleton objects and therefore usual identity would work. >> > >> > Hope this helps, >> > -Sundar >> > >> > >> > On 12/22/2015 12:25 PM, Vivin Suresh Paliath wrote: >> > >> > I am looking at it from the perspective of someone writing code that is >> > expect to run in JavaScript environment. I will describe the runtime >> > environment I have set up. Perhaps what I am running into is an >> artifact of >> > my approach. >> > >> > I have a single script engine instance. In this context I evaluate some >> JS >> > source that populates the JS global scope with some objects. When a >> custom >> > script needs to be evaluated, I create a new script context with a new >> > global. Then I copy over all bindings from the parent script context >> into >> > the new one. I also have a module system. When a custom script requests >> a >> > core module, the module source is evaluated in the main script context >> and >> > a single instance of the object exposed by the module source is cached. >> > This way the source only needs to be evaluated once and benefits from >> > optimizations. >> > >> > The problem I am running into has to do with some singleton objects I >> > expose; kind of like enums, and can be compared using ===. I am using a >> JS >> > library for this and this behavior holds in the browser and on NodeJS. >> On >> > Nashorn, because the instances were created in a different context, === >> > returns false. >> > >> > Is there a better way to accomplish what I am doing? >> > >> > Regarding host objects, even if they are different from native objects, >> it >> > seems strange to me that the semantics of things like === would be >> > different especially when doing something like obj.prop === obj.prop. >> The >> > fact that such a statement could ever return false is non-obvious unless >> > implementation details of the runtime are known. >> > >> > I am trying to expose my runtime environment as a JS environment where a >> > developer can write custom scripts using some runtime libraries and >> > utilities. So behavior like this would be very surprising, and requiring >> > them to know that objects might be from different contexts seems like >> > abstraction leakage from the way I have implemented the runtime. They >> > shouldn't have to know whether an object is a wrapped ScriptObjectMirror >> > instance, since from their point of view they are just working with JS >> > objects, and they don't know that they are from different "worlds" since >> > they don't even know that there are different worlds. >> > >> > I guess I am also having a hard time seeing a scenario where === would >> > need to return false in the scenario I described, unless as a developer >> you >> > knew there were different worlds. Even then, it would essentially make >> some >> > forms of equality comparisons impossible (e.g., o.prop === o.prop if o >> is >> > foreign). >> > >> > Does the snippet I posted earlier make sense? >> > On Dec 21, 2015 9:10 PM, "Sundararajan Athijegannathan" < >> > sundararajan.athijegannathan at oracle.com> wrote: >> > >> >> Actually, I'm not sure if depending on === in the code is a good >> approach >> >> -- particularly, for objects that are not script objects of the >> current >> >> world. These are to be treated like "host objects" in ECMAScript-speak. >> >> i.e., regular rules of script objects don't always apply to 'host >> >> objects'. The === operator for Java objects is interpreted as object >> >> identity -- and the same rule for ScriptObjectMirrors -- in that both >> are >> >> "host objects" from the standpoint of the 'current world'. >> >> >> >> -Sundar >> >> >> >> On 12/22/2015 9:34 AM, Vivin Suresh Paliath wrote: >> >> >> >> Thanks for the response! I understand that in general it would be >> >> difficult for foreign objects. But this seems like surprising behavior >> >> given that these are both JavaScript objects. That they are unequal >> seems >> >> to be an artifact of the implementation (the fact that JS objects from >> >> different contexts are treated as foreign). Could JS objects be treated >> >> differently? >> >> >> >> After going through the Nashorn source, I decided to try this very >> naive >> >> approach adding the following test to >> ScriptRuntime#equalSameTypeValues: >> >> >> >> if(x instanceof ScriptObjectMirror && y instanceof ScriptObjectMirror) >> { >> >> return x.equals(y); >> >> } >> >> >> >> After this change, the code now returns true, because >> >> ScriptObjectMirror#equals compares the actual objects. I am not sure if >> >> this breaks anything though (been trying to run the test suite, but >> end up >> >> getting some errors from make). Is there a reason this particular fix >> is a >> >> bad idea? I can't think of a particular reason why. From the >> perspective of >> >> the runtime, I can't see a reason why those two objects should be >> >> considered different. >> >> >> >> I will investigate the eval approach, but ideally I would like >> something >> >> that doesn't impose any changes on the JS code. I am developing a >> simple >> >> runtime that exposes some objects and utilities, and where custom >> scripts >> >> can run in their own contexts. The fact that === returns false in these >> >> cases leads to some very strange behavior. >> >> >> >> On Mon, Dec 21, 2015 at 8:48 PM, Sundararajan Athijegannathan < >> >> >> >> sundararajan.athijegannathan at oracle.com> wrote: >> >> >> >>> Unless we create mirrors as weak refs internally (i.e., maintain 1:1 >> >>> with underlying foreign object reference), there is no easy solution. >> And >> >>> maintaining such weak refs is unnecessarily complex. "Foreign object" >> >>> call/access is mean to be just a "lightweight wrapper" based access. >> That >> >>> said, you can do the === on the foreign context itself. You can call >> >>> ScriptObjectMirror's eval to evaluate === test in that foreign >> context. >> >>> That would get right object identity. >> >>> >> >>> -Sundar >> >>> >> >>> >> >>> On 12/22/2015 4:26 AM, Vivin Suresh Paliath wrote: >> >>> >> >>>> One more thing I noticed is that apparently a new ScriptObjectMirror >> >>>> instance is probably being created each time x is dereferenced, so >> "e.x >> >>>> === >> >>>> e.x" also returns "false". >> >>>> >> >>>> On Mon, Dec 21, 2015 at 3:49 PM, Vivin Suresh Paliath < >> >>>> vivin.paliath at gmail.com> wrote: >> >>>> >> >>>> I ran into an issue where === returns false even when both should be >> >>>>> pointing to the same object. I'm assuming this is because one of the >> >>>>> objects is wrapped by a ScriptObjectMirror, because it was defined >> in a >> >>>>> different context. >> >>>>> >> >>>>> Here's some code that demonstrates this: >> >>>>> >> >>>>> ScriptEngine engine = new >> >>>>> NashornScriptEngineFactory().getScriptEngine( >> >>>>> new String[] { "-strict" } >> >>>>> ); >> >>>>> >> >>>>> try { >> >>>>> engine.eval("function Foo(src) { this.src = src }; var >> e >> >>>>> = { >> >>>>> x: new Foo(\"what\") };"); >> >>>>> >> >>>>> ScriptContext c = new SimpleScriptContext(); >> >>>>> c.setBindings(engine.createBindings(), >> >>>>> ScriptContext.ENGINE_SCOPE); >> >>>>> >> >>>>> >> >>>>> >> c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); >> >>>>> >> >>>>> System.out.println(engine.eval("var z = e.x; z === >> e.x;", >> >>>>> c)); >> >>>>> } catch(Exception e) { >> >>>>> throw new RuntimeException(e); >> >>>>> } >> >>>>> >> >>>>> This prints out "false". Is there a way around this? I am also >> >>>>> explicitly >> >>>>> copying over all the bindings from the parent scope into the new >> scope >> >>>>> so >> >>>>> that I have access to "e". Could this be the source of the problem, >> >>>>> and if >> >>>>> so, is there a better way to achieve what I'm trying to do? >> >>>>> >> >>>>> -- >> >>>>> Ruin untold; >> >>>>> And thine own sadness, >> >>>>> Sing in the grass, >> >>>>> When eve has forgot, that no more hear common things that gleam and >> >>>>> pass; >> >>>>> But seek alone to lip, sad Rose of love and ruin untold; >> >>>>> And thine own mother >> >>>>> Can know it as I know >> >>>>> More than another >> >>>>> What makes your own sadness, >> >>>>> Set in her eyes. >> >>>>> >> >>>>> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >> >>>>> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >> >>>>> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >> >>>>> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >> >>>>> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >> >>>>> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >> >>>>> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >> >>>>> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >> >>>>> i",pack"B32",$_}$j=~m/.{8}/g >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>> >> >> >> >> >> >> -- >> >> Ruin untold; >> >> And thine own sadness, >> >> Sing in the grass, >> >> When eve has forgot, that no more hear common things that gleam and >> pass; >> >> But seek alone to lip, sad Rose of love and ruin untold; >> >> And thine own mother >> >> Can know it as I know >> >> More than another >> >> What makes your own sadness, >> >> Set in her eyes. >> >> >> >> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >> >> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >> >> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >> >> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >> >> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >> >> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >> >> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >> >> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >> >> i",pack"B32",$_}$j=~m/.{8}/g >> >> >> >> >> >> >> > >> >> >> -- >> Ruin untold; >> And thine own sadness, >> Sing in the grass, >> When eve has forgot, that no more hear common things that gleam and pass; >> But seek alone to lip, sad Rose of love and ruin untold; >> And thine own mother >> Can know it as I know >> More than another >> What makes your own sadness, >> Set in her eyes. >> >> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >> i",pack"B32",$_}$j=~m/.{8}/g >> > > -- Ruin untold; And thine own sadness, Sing in the grass, When eve has forgot, that no more hear common things that gleam and pass; But seek alone to lip, sad Rose of love and ruin untold; And thine own mother Can know it as I know More than another What makes your own sadness, Set in her eyes. map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". ":13:02:11:01:02:11:01:12:02";map{print chr unpack" i",pack"B32",$_}$j=~m/.{8}/g From sundararajan.athijegannathan at oracle.com Wed Dec 23 02:58:07 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 23 Dec 2015 08:28:07 +0530 Subject: Using === across different contexts In-Reply-To: References: <5678C7FD.4050700@oracle.com> <5678CD33.80704@oracle.com> <56790B53.8030503@oracle.com> Message-ID: <567A0DBF.4000009@oracle.com> Hi, Addressing your question on j.u.IdentityHashMap. I assume the rest of the questions were addressed by Attila. * Assume that we implement === for ScriptObjectMirror to be (JVM) object identity comparison of the *wrapped* underlying objects (as in your attempted patch) rather than identity of ScriptObjectMirror objects, what would happen? Script writer would see === being true for potentially two *different* ScriptObjectMirror instances. Based on the mental model that === means strict object identity, s/he then may try to use ScriptObjectMirror objects in a java.util.IdentityHashMap! IdentityHashMap itself would use JVM object identity -- so two different ScriptObjectMirror instances m1, m2 wrapping *same* underlying script object "sobj" are different for IdentityHashMap implementation. But, this breaks the assumption by the script writer! s/he thinks m1 === m2 true => IdentityHashMap should treat m1 and m2 are identical! That is not the case and so model breaks for script authors. That is why I said, if at all we want to preserve script object identity with ScriptObjectMirror instances, we'd need to implement weakref based mirroring. -Sundar On 12/23/2015 1:41 AM, Vivin Suresh Paliath wrote: > Hi Sundar, > > Thank you for the explanation! I hope I am not being too obtuse - I'm > just trying to get a handle on how things work! > > Object identity is implemented strictly per ECMAScript spec - > which says === evals to be evaluated true only if "same object". > Why should we treat ScriptObjectMirrors as special for identity > comparison > > > In my view, ScriptObjectMirrors should be treated the same only if it > is made abundantly clear that the JavaScript object you're working > with in Nashorn, may sometimes be a wrapped object and not the actual > object itself. The problem is that right now there is no easy way to > discern that, and anticipate the side effects that come with that > distinction. With respect to the ES spec, I agree that === should > evaluate to true if the objects are the same object, and that holds > true for the most part even if the objects are wrapped. But the > problem arises when you try to compare a property of an object (which > is itself a JS object) with itself, where the parent object happens to > be foreign. That's when you end up in a situation where obj === obj > returns true, but obj.prop === obj.prop returns false. The assumption > I am making is invalid only if I /know/ that they are mirror objects, > but as I mentioned before, there is no easy way to determine that. I > can see a case where obj.prop is actually a getter that returns a new > instance of an object each time, and here obj.prop === obj.prop would > return false, but that fact would be evident from the source of the JS > object itself, and wouldn't be due to how foreign script-objects are > implemented in Nashorn. > > For eg. think of using that in j.u.IdentityHashMap and expect it > work! [=== returns true and so IdentityHashMap should work as > expected -- but it won't because IdentityHashMap goes by JVM level > object identity! > > > Perhaps I am not understanding this example correctly. Are you saying > that inserts into the IdentityHashMap wouldn't work as expected? But > wouldn't the only comparison that is being performed be == in Java, > which would be comparing the ScriptObjectMirror instances anyway > (i.e., the same behavior as now). I tried out the following with and > without my changes and I got the same output (size of the map is 3): > > engine.eval("function Foo(src) { this.src = src }; var e = { x: > new Foo(\"what\") };"); > > > ScriptContext c = new SimpleScriptContext(); > c.setBindings(engine.createBindings(), ScriptContext.ENGINE_SCOPE); > c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); > > c.getBindings(ScriptContext.ENGINE_SCOPE).put("ihm", new > IdentityHashMap()); > engine.eval("ihm.put(e.x, 1); ihm.put(e.x, 2); ihm.put(e.x, 3); > print(ihm.size());", c); > > > The one discrepancy that would exist is if you perform an === > comparison in JavaScript against something from the map. > > You're creating multiple ScriptContexts and associate ENGINE_SCOPE > Bindings to isolate. And yet you want objects from "isolated" > worlds to be treated exactly like "current isolate world". > > > The new contexts I create know nothing about each other; they only > "know" (in the sense that the "global" runtime-library objects are > available) the objects from the main context (and only because I copy > them over). Also, I am not treating the object from the main > isolated-world the same way as the one in the current one; I am really > only trying to compare references (and that too against themselves). > > If you do not want that kind of multiple ECMAScript global scope > isolation at all, why not load your library/framework scripts > before loading the user scripts? If you want to avoid clash b/w > different user scripts (i.e., globals in user's scripts for eg.), > you could implement "require" like primitive such as the one here > > > This is actually exactly what I am doing, and I am using require-like > functionality as well. The problem arises when I try to dereference a > property of an object that is a foreign script-object. For example, > let's assume the default context of the script engine has an "enum" > SomeEnum, with the enum CONST. When I get a custom script, I create a > new context (using createBindings) and copy everything over. So now > the new context has a foreign object called SomeEnum. Now if I do > SomeEnum === SomeEnum, I get back true, but SomeEnum.CONST === > SomeEnum.CONST returns false. Is this what you were saying weak-refs > would solve? > > If you do want isolation and still want singleton enum-like > objects, why not implement those in Java and expose to scripts? > These would then be real JVM singleton objects and therefore usual > identity would work. > > > That would be a workaround, but some code that I insert are > autogenerated JS equivalents of POJOs. Enums are implemented using > this library, which gives you > type-safe enums in JavaScript as well. So I cannot assume upfront what > kind of Java enums are going to be used since they come from a > different project entirely. > > Based on what you said, I agree with you that === is probably the > wrong place to do this and it seems that the thing that really needs > to be fixed is ensuring that properties of foreign objects return the > same mirror instance whenever dereferenced. As I said before, I can't > think of a case where obj.prop === obj.prop would return false > /unless/ prop is a calculated property that returns a new instance of > some object each time. Even if that were the case, I don't see how > that behavior would be broken if the Nashorn runtime ensured that we > got back the same mirror instance. Regardless, wouldn't it notice that > prop actually delegates to a getter function, and then run that? But > in the case where prop is a reference to an actual object, you would > still have the expected behavior. I understand that these foreign > objects are wrapped, but I am questioning whether someone really needs > to /know/ that they are, if they are writing JS code on Nashorn. > > My original aim when I was doing this was to provide a single > script-engine instance so that I could take advantage of optimizations > on common code, while providing isolated execution contexts. Objects > in the engine's default context are "read-only" and the isolated > contexts cannot really mess with them. Really what I'm after is > ensuring that library-code gets optimized over time and that contexts > can't step over each other. So if such an approach gives me that, then > it would definitely make things a lot easier. Also, is there somewhere > I can read about the optimizations Nashorn makes in different cases? > I'm specifically wondering about the following: > > 1. Does Nashorn optimize pre-compiled JS code each time it is > evaluated? Are the optimizations persisted to the compiled > representation? > 2. If I repeatedly evaluate the same JS code in the same > script-engine, but in different contexts, is that code optimized? > Or are the optimizations discarded once the context is gone? > > If I can still get these optimizations, then I can simply just > precompile and/or re-evaluate the library code in each new context and > that would do away with this issue and make things much easier. > > Thank you once again, and I apologize for so many questions! > > Vivin > > On Tue, Dec 22, 2015 at 1:35 AM, Sundararajan Athijegannathan > > wrote: > > Hi, > > May be I should explain the background on how nashorn treates > "foreign/host" objects. Nashorn implements object access > primitives like "get_property, set_property, get_method, call, > new" via a series of dynalink linkers > (http://openjdk.java.net/jeps/276). There is a linker for it's own > objects (ScriptObject instances), there is one for Java objects > ("beans linkers"), "foreign 'script' objects" > (ScriptObjectMirrors). It allows even user specified linkers > picked up via java.util.ServiceLoader mechanism. (See > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/74ddd1339c57/samples/dynalink). > > But, looping (via for, for..each), identity and other operators > are natively implemented in Nashorn. Object identity is > implemented strictly per ECMAScript spec - which says === evals to > be evaluated true only if "same object". Why should we treat > ScriptObjectMirrors as special for identity comparison (and who > knows what problems it could cause than the ones it solves!). For > eg. think of using that in j.u.IdentityHashMap and expect it work! > [=== returns true and so IdentityHashMap should work as expected > -- but it won't because IdentityHashMap goes by JVM level object > identity! As I said, it at all we want mirrors to preserve > identity, we need weak refs. > > / > > Regarding host objects, even if they are different from native > objects, it seems strange to me that the semantics of things like > === would be different especially when doing something like > obj.prop === obj.prop. The fact that such a statement could ever > return false is non-obvious unless implementation details of the > runtime are known. > > / > > The fact that you're assuming your host objects return "same > object" for doing two "obj.prop" evals -- is an assumption about > mirror objects! Why do you think such as assumption to be true for > mirrors -- whose sole purpose is to provide easy access to > objects. You're creating multiple ScriptContexts and associate > ENGINE_SCOPE Bindings to isolate. And yet you want objects from > "isolated" worlds to be treated exactly like "current isolate world". > > If you do not want that kind of multiple ECMAScript global scope > isolation at all, why not load your library/framework scripts > before loading the user scripts? If you want to avoid clash b/w > different user scripts (i.e., globals in user's scripts for eg.), > you could implement "require" like primitive such as the one here > -> https://github.com/walterhiggins/commonjs-modules-javax-script > > If you do want isolation and still want singleton enum-like > objects, why not implement those in Java and expose to scripts? > These would then be real JVM singleton objects and therefore usual > identity would work. > > Hope this helps, > -Sundar > > > On 12/22/2015 12:25 PM, Vivin Suresh Paliath wrote: >> >> I am looking at it from the perspective of someone writing code >> that is expect to run in JavaScript environment. I will describe >> the runtime environment I have set up. Perhaps what I am running >> into is an artifact of my approach. >> >> I have a single script engine instance. In this context I >> evaluate some JS source that populates the JS global scope with >> some objects. When a custom script needs to be evaluated, I >> create a new script context with a new global. Then I copy over >> all bindings from the parent script context into the new one. I >> also have a module system. When a custom script requests a core >> module, the module source is evaluated in the main script context >> and a single instance of the object exposed by the module source >> is cached. This way the source only needs to be evaluated once >> and benefits from optimizations. >> >> The problem I am running into has to do with some singleton >> objects I expose; kind of like enums, and can be compared using >> ===. I am using a JS library for this and this behavior holds in >> the browser and on NodeJS. On Nashorn, because the instances were >> created in a different context, === returns false. >> >> Is there a better way to accomplish what I am doing? >> >> Regarding host objects, even if they are different from native >> objects, it seems strange to me that the semantics of things like >> === would be different especially when doing something like >> obj.prop === obj.prop. The fact that such a statement could ever >> return false is non-obvious unless implementation details of the >> runtime are known. >> >> I am trying to expose my runtime environment as a JS environment >> where a developer can write custom scripts using some runtime >> libraries and utilities. So behavior like this would be very >> surprising, and requiring them to know that objects might be from >> different contexts seems like abstraction leakage from the way I >> have implemented the runtime. They shouldn't have to know whether >> an object is a wrapped ScriptObjectMirror instance, since from >> their point of view they are just working with JS objects, and >> they don't know that they are from different "worlds" since they >> don't even know that there are different worlds. >> >> I guess I am also having a hard time seeing a scenario where === >> would need to return false in the scenario I described, unless as >> a developer you knew there were different worlds. Even then, it >> would essentially make some forms of equality comparisons >> impossible (e.g., o.prop === o.prop if o is foreign). >> >> Does the snippet I posted earlier make sense? >> >> On Dec 21, 2015 9:10 PM, "Sundararajan Athijegannathan" >> > > wrote: >> >> Actually, I'm not sure if depending on === in the code is a >> good approach -- particularly, for objects that are not >> script objects of the current world. These are to be treated >> like "host objects" in ECMAScript-speak. i.e., regular rules >> of script objects don't always apply to 'host objects'. The >> === operator for Java objects is interpreted as object >> identity -- and the same rule for ScriptObjectMirrors -- in >> that both are "host objects" from the standpoint of the >> 'current world'. >> >> -Sundar >> >> On 12/22/2015 9:34 AM, Vivin Suresh Paliath wrote: >>> Thanks for the response! I understand that in general it >>> would be difficult for foreign objects. But this seems like >>> surprising behavior given that these are both JavaScript >>> objects. That they are unequal seems to be an artifact of >>> the implementation (the fact that JS objects from different >>> contexts are treated as foreign). Could JS objects be >>> treated differently? >>> >>> After going through the Nashorn source, I decided to try >>> this very naive approach adding the following test to >>> ScriptRuntime#equalSameTypeValues: >>> >>> if(x instanceof ScriptObjectMirror && y instanceof >>> ScriptObjectMirror) { >>> return x.equals(y); >>> } >>> >>> After this change, the code now returns true, because >>> ScriptObjectMirror#equals compares the actual objects. I am >>> not sure if this breaks anything though (been trying to run >>> the test suite, but end up getting some errors from make). >>> Is there a reason this particular fix is a bad idea? I can't >>> think of a particular reason why. From the perspective of >>> the runtime, I can't see a reason why those two objects >>> should be considered different. >>> >>> I will investigate the eval approach, but ideally I would >>> like something that doesn't impose any changes on the JS >>> code. I am developing a simple runtime that exposes some >>> objects and utilities, and where custom scripts can run in >>> their own contexts. The fact that === returns false in these >>> cases leads to some very strange behavior. >>> >>> On Mon, Dec 21, 2015 at 8:48 PM, Sundararajan >>> Athijegannathan >> > wrote: >>> >>> Unless we create mirrors as weak refs internally (i.e., >>> maintain 1:1 with underlying foreign object reference), >>> there is no easy solution. And maintaining such weak >>> refs is unnecessarily complex. "Foreign object" >>> call/access is mean to be just a "lightweight wrapper" >>> based access. That said, you can do the === on the >>> foreign context itself. You can call >>> ScriptObjectMirror's eval to evaluate === test in that >>> foreign context. That would get right object identity. >>> >>> -Sundar >>> >>> >>> On 12/22/2015 4:26 AM, Vivin Suresh Paliath wrote: >>> >>> One more thing I noticed is that apparently a new >>> ScriptObjectMirror >>> instance is probably being created each time x is >>> dereferenced, so "e.x === >>> e.x" also returns "false". >>> >>> On Mon, Dec 21, 2015 at 3:49 PM, Vivin Suresh Paliath < >>> vivin.paliath at gmail.com >>> > wrote: >>> >>> I ran into an issue where === returns false even >>> when both should be >>> pointing to the same object. I'm assuming this >>> is because one of the >>> objects is wrapped by a ScriptObjectMirror, >>> because it was defined in a >>> different context. >>> >>> Here's some code that demonstrates this: >>> >>> ScriptEngine engine = new >>> NashornScriptEngineFactory().getScriptEngine( >>> new String[] { "-strict" } >>> ); >>> >>> try { >>> engine.eval("function Foo(src) { this.src = src >>> }; var e = { >>> x: new Foo(\"what\") };"); >>> >>> ScriptContext c = new >>> SimpleScriptContext(); >>> c.setBindings(engine.createBindings(), >>> ScriptContext.ENGINE_SCOPE); >>> >>> c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); >>> >>> System.out.println(engine.eval("var z = e.x; z >>> === e.x;", c)); >>> } catch(Exception e) { >>> throw new RuntimeException(e); >>> } >>> >>> This prints out "false". Is there a way around >>> this? I am also explicitly >>> copying over all the bindings from the parent >>> scope into the new scope so >>> that I have access to "e". Could this be the >>> source of the problem, and if >>> so, is there a better way to achieve what I'm >>> trying to do? >>> >>> -- >>> Ruin untold; >>> And thine own sadness, >>> Sing in the grass, >>> When eve has forgot, that no more hear common >>> things that gleam and pass; >>> But seek alone to lip, sad Rose of love and ruin >>> untold; >>> And thine own mother >>> Can know it as I know >>> More than another >>> What makes your own sadness, >>> Set in her eyes. >>> >>> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >>> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >>> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >>> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >>> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >>> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >>> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >>> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >>> i",pack"B32",$_}$j=~m/.{8}/g >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Ruin untold; >>> And thine own sadness, >>> Sing in the grass, >>> When eve has forgot, that no more hear common things that >>> gleam and pass; >>> But seek alone to lip, sad Rose of love and ruin untold; >>> And thine own mother >>> Can know it as I know >>> More than another >>> What makes your own sadness, >>> Set in her eyes.| >>> >>> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >>> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >>> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >>> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >>> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >>> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >>> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >>> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >>> i",pack"B32",$_}$j=~m/.{8}/g >>> | >> > > > > > -- > Ruin untold; > And thine own sadness, > Sing in the grass, > When eve has forgot, that no more hear common things that gleam and pass; > But seek alone to lip, sad Rose of love and ruin untold; > And thine own mother > Can know it as I know > More than another > What makes your own sadness, > Set in her eyes.| > > map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". > ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". > ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". > ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". > ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". > ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". > ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". > ":13:02:11:01:02:11:01:12:02";map{print chr unpack" > i",pack"B32",$_}$j=~m/.{8}/g > | From szegedia at gmail.com Wed Dec 23 20:29:16 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 23 Dec 2015 21:29:16 +0100 Subject: Review request for JDK-8144917: Prepare AbstractJavaLinker/BeanLinker codebase for missing member implementation Message-ID: Please review JDK-8144917 "Prepare AbstractJavaLinker/BeanLinker codebase for missing member implementation" at for This change has no functional effects, it's a refactoring for easier introduction of the no-such-member implementation (JDK-8144919), a review for which will immediately follow. I only plan to commit the two together after they have been both reviewed. Thanks, Attila. From szegedia at gmail.com Wed Dec 23 20:30:34 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 23 Dec 2015 21:30:34 +0100 Subject: Review request for JDK-8144917: Prepare AbstractJavaLinker/BeanLinker codebase for missing member implementation Message-ID: <1502B2E0-059C-46D5-8E4F-BBB562567A6A@gmail.com> Please review JDK-8144917 "Prepare AbstractJavaLinker/BeanLinker codebase for missing member implementation" at for This change has no functional effects, it's a refactoring for easier introduction of the no-such-member implementation (JDK-8144919), a review for which will immediately follow. I only plan to commit the two together after they have been both reviewed. Thanks, Attila. From szegedia at gmail.com Wed Dec 23 20:31:04 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 23 Dec 2015 21:31:04 +0100 Subject: Review request for JDK-8144919: Implement missing member handler for BeansLinker Message-ID: <9A790E75-DA5D-40CA-8004-02C2A4624CE3@gmail.com> Please review JDK-8144919 "Implement missing member handler for BeansLinker" at for This change dependes on JDK-8144917, a review request for which immediately preceded this one. I only plan to commit the two together after they have been both reviewed. Note that I need a CCC review for this, as it touches the Dynalink public API (details in the JIRA issue). As such, even if I get 2 reviews on this, I will not be committing either this or 8144917 until CCC approval is obtained. Thanks, Attila. From sundararajan.athijegannathan at oracle.com Thu Dec 24 05:05:42 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 24 Dec 2015 10:35:42 +0530 Subject: RFR 8146147: Java linker indexed property getter does not work for computed nashorn string Message-ID: <567B7D26.5010904@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8146147/ for https://bugs.openjdk.java.net/browse/JDK-8146147 Thanks, -Sundar From james.laskey at oracle.com Thu Dec 24 11:21:57 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 24 Dec 2015 07:21:57 -0400 Subject: RFR 8146147: Java linker indexed property getter does not work for computed nashorn string In-Reply-To: <567B7D26.5010904@oracle.com> References: <567B7D26.5010904@oracle.com> Message-ID: <7983243A-5EF2-4151-BDB6-32BC30A02F39@oracle.com> +1 > On Dec 24, 2015, at 1:05 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8146147/ for https://bugs.openjdk.java.net/browse/JDK-8146147 > > Thanks, > -Sundar From szegedia at gmail.com Thu Dec 24 13:14:15 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 24 Dec 2015 14:14:15 +0100 Subject: RFR 8146147: Java linker indexed property getter does not work for computed nashorn string In-Reply-To: <7983243A-5EF2-4151-BDB6-32BC30A02F39@oracle.com> References: <567B7D26.5010904@oracle.com> <7983243A-5EF2-4151-BDB6-32BC30A02F39@oracle.com> Message-ID: <50DFBC58-1A86-453B-8767-B54CEBE5D993@gmail.com> +1 > On Dec 24, 2015, at 12:21 PM, Jim Laskey (Oracle) wrote: > > +1 > >> On Dec 24, 2015, at 1:05 AM, Sundararajan Athijegannathan wrote: >> >> Please review http://cr.openjdk.java.net/~sundar/8146147/ for https://bugs.openjdk.java.net/browse/JDK-8146147 >> >> Thanks, >> -Sundar > From vivin.paliath at gmail.com Thu Dec 24 23:36:06 2015 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Thu, 24 Dec 2015 16:36:06 -0700 Subject: Using === across different contexts In-Reply-To: <567A0DBF.4000009@oracle.com> References: <5678C7FD.4050700@oracle.com> <5678CD33.80704@oracle.com> <56790B53.8030503@oracle.com> <567A0DBF.4000009@oracle.com> Message-ID: That makes sense Sundar; thank you for the great explanation! You mentioned that a weak-ref based mapping would be required to fix this. I am assuming that this would involve ScriptObject maintaining a weakref to a ScriptObjectMirror instance? You also said that this would bring added complexity that you would have to deal with. Can you elaborate on that a little bit? I played around with the source in ScriptObject and ScriptObjectMirror a little bit, and added a weakref to a mirror instance inside ScriptObject. The weakref in the ScriptObject is initialized via the ScriptObjectMirror constructor. In ScriptObjectMirror#wrap, it looks for the mirror first, and returns it if it is not null. Otherwise it creates a new instance and sets the weakref to that instance. This seemed to fix the original issue I was facing. I ran the nashorn test suite and there weren't any failures after my changes. However, I am sure there are subtleties and nuances I am not taking into account, and so I'm curious what kind of issues could arise from my change. I know this is a complex issue, but I would like to learn more about it and see if I can take a stab at solving it. Thanks! Vivin On Tue, Dec 22, 2015 at 7:58 PM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Hi, > > Addressing your question on j.u.IdentityHashMap. I assume the rest of the > questions were addressed by Attila. > > * Assume that we implement === for ScriptObjectMirror to be (JVM) object > identity comparison of the *wrapped* underlying objects (as in your > attempted patch) rather than identity of ScriptObjectMirror objects, what > would happen? > > Script writer would see === being true for potentially two *different* > ScriptObjectMirror instances. Based on the mental model that === means > strict object identity, s/he then may try to use ScriptObjectMirror objects > in a java.util.IdentityHashMap! IdentityHashMap itself would use JVM > object identity -- so two different ScriptObjectMirror instances m1, m2 > wrapping *same* underlying script object "sobj" are different > for IdentityHashMap implementation. But, this breaks the assumption by > the script writer! s/he thinks m1 === m2 true => IdentityHashMap should > treat m1 and m2 are identical! That is not the case and so model breaks for > script authors. That is why I said, if at all we want to preserve script > object identity with ScriptObjectMirror instances, we'd need to implement > weakref based mirroring. > > -Sundar > > > On 12/23/2015 1:41 AM, Vivin Suresh Paliath wrote: > > Hi Sundar, > > Thank you for the explanation! I hope I am not being too obtuse - I'm just > trying to get a handle on how things work! > > Object identity is implemented strictly per ECMAScript spec - which says >> === evals to be evaluated true only if "same object". Why should we treat >> ScriptObjectMirrors as special for identity comparison > > > In my view, ScriptObjectMirrors should be treated the same only if it is > made abundantly clear that the JavaScript object you're working with in > Nashorn, may sometimes be a wrapped object and not the actual object > itself. The problem is that right now there is no easy way to discern that, > and anticipate the side effects that come with that distinction. With > respect to the ES spec, I agree that === should evaluate to true if the > objects are the same object, and that holds true for the most part even if > the objects are wrapped. But the problem arises when you try to compare a > property of an object (which is itself a JS object) with itself, where the > parent object happens to be foreign. That's when you end up in a situation > where obj === obj returns true, but obj.prop === obj.prop returns false. > The assumption I am making is invalid only if I *know* that they are > mirror objects, but as I mentioned before, there is no easy way to > determine that. I can see a case where obj.prop is actually a getter that > returns a new instance of an object each time, and here obj.prop === > obj.prop would return false, but that fact would be evident from the source > of the JS object itself, and wouldn't be due to how foreign script-objects > are implemented in Nashorn. > > For eg. think of using that in j.u.IdentityHashMap and expect it work! >> [=== returns true and so IdentityHashMap should work as expected -- but it >> won't because IdentityHashMap goes by JVM level object identity! > > > Perhaps I am not understanding this example correctly. Are you saying that > inserts into the IdentityHashMap wouldn't work as expected? But wouldn't > the only comparison that is being performed be == in Java, which would be > comparing the ScriptObjectMirror instances anyway (i.e., the same behavior > as now). I tried out the following with and without my changes and I got > the same output (size of the map is 3): > > engine.eval("function Foo(src) { this.src = src }; var e = { x: new > Foo(\"what\") };"); > > > ScriptContext c = new SimpleScriptContext(); > c.setBindings(engine.createBindings(), ScriptContext.ENGINE_SCOPE); > > c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); > > c.getBindings(ScriptContext.ENGINE_SCOPE).put("ihm", new > IdentityHashMap()); > engine.eval("ihm.put(e.x, 1); ihm.put(e.x, 2); ihm.put(e.x, 3); > print(ihm.size());", c); > > > The one discrepancy that would exist is if you perform an === comparison > in JavaScript against something from the map. > > You're creating multiple ScriptContexts and associate ENGINE_SCOPE >> Bindings to isolate. And yet you want objects from "isolated" worlds to be >> treated exactly like "current isolate world". > > > The new contexts I create know nothing about each other; they only "know" > (in the sense that the "global" runtime-library objects are available) the > objects from the main context (and only because I copy them over). Also, I > am not treating the object from the main isolated-world the same way as the > one in the current one; I am really only trying to compare references (and > that too against themselves). > > >> If you do not want that kind of multiple ECMAScript global scope >> isolation at all, why not load your library/framework scripts before >> loading the user scripts? If you want to avoid clash b/w different user >> scripts (i.e., globals in user's scripts for eg.), you could implement >> "require" like primitive such as the one here > > > This is actually exactly what I am doing, and I am using require-like > functionality as well. The problem arises when I try to dereference a > property of an object that is a foreign script-object. For example, let's > assume the default context of the script engine has an "enum" SomeEnum, > with the enum CONST. When I get a custom script, I create a new context > (using createBindings) and copy everything over. So now the new context has > a foreign object called SomeEnum. Now if I do SomeEnum === SomeEnum, I get > back true, but SomeEnum.CONST === SomeEnum.CONST returns false. Is this > what you were saying weak-refs would solve? > > If you do want isolation and still want singleton enum-like objects, why >> not implement those in Java and expose to scripts? These would then be real >> JVM singleton objects and therefore usual identity would work. > > > That would be a workaround, but some code that I insert are autogenerated > JS equivalents of POJOs. Enums are implemented using this > library, which gives you type-safe > enums in JavaScript as well. So I cannot assume upfront what kind of Java > enums are going to be used since they come from a different project > entirely. > > Based on what you said, I agree with you that === is probably the wrong > place to do this and it seems that the thing that really needs to be fixed > is ensuring that properties of foreign objects return the same mirror > instance whenever dereferenced. As I said before, I can't think of a case > where obj.prop === obj.prop would return false *unless* prop is a > calculated property that returns a new instance of some object each time. > Even if that were the case, I don't see how that behavior would be broken > if the Nashorn runtime ensured that we got back the same mirror instance. > Regardless, wouldn't it notice that prop actually delegates to a getter > function, and then run that? But in the case where prop is a reference to > an actual object, you would still have the expected behavior. I > understand that these foreign objects are wrapped, but I am questioning > whether someone really needs to *know* that they are, if they are writing > JS code on Nashorn. > > My original aim when I was doing this was to provide a single > script-engine instance so that I could take advantage of optimizations on > common code, while providing isolated execution contexts. Objects in the > engine's default context are "read-only" and the isolated contexts cannot > really mess with them. Really what I'm after is ensuring that library-code > gets optimized over time and that contexts can't step over each other. So > if such an approach gives me that, then it would definitely make things a > lot easier. Also, is there somewhere I can read about the optimizations > Nashorn makes in different cases? I'm specifically wondering about the > following: > > 1. Does Nashorn optimize pre-compiled JS code each time it is > evaluated? Are the optimizations persisted to the compiled representation? > 2. If I repeatedly evaluate the same JS code in the same > script-engine, but in different contexts, is that code optimized? Or are > the optimizations discarded once the context is gone? > > If I can still get these optimizations, then I can simply just precompile > and/or re-evaluate the library code in each new context and that would do > away with this issue and make things much easier. > > Thank you once again, and I apologize for so many questions! > > Vivin > > On Tue, Dec 22, 2015 at 1:35 AM, Sundararajan Athijegannathan < > > sundararajan.athijegannathan at oracle.com> wrote: > >> Hi, >> >> May be I should explain the background on how nashorn treates >> "foreign/host" objects. Nashorn implements object access primitives like >> "get_property, set_property, get_method, call, new" via a series of >> dynalink linkers ( >> http://openjdk.java.net/jeps/276). There is a linker for it's own >> objects (ScriptObject instances), there is one for Java objects ("beans >> linkers"), "foreign 'script' objects" (ScriptObjectMirrors). It allows even >> user specified linkers picked up via java.util.ServiceLoader mechanism. >> (See >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/74ddd1339c57/samples/dynalink >> ). >> >> But, looping (via for, for..each), identity and other operators are >> natively implemented in Nashorn. Object identity is implemented strictly >> per ECMAScript spec - which says === evals to be evaluated true only if >> "same object". Why should we treat ScriptObjectMirrors as special for >> identity comparison (and who knows what problems it could cause than the >> ones it solves!). For eg. think of using that in j.u.IdentityHashMap and >> expect it work! [=== returns true and so IdentityHashMap should work as >> expected -- but it won't because IdentityHashMap goes by JVM level object >> identity! As I said, it at all we want mirrors to preserve identity, we >> need weak refs. >> >> / >> >> Regarding host objects, even if they are different from native objects, >> it seems strange to me that the semantics of things like === would be >> different especially when doing something like obj.prop === obj.prop. The >> fact that such a statement could ever return false is non-obvious unless >> implementation details of the runtime are known. >> / >> >> The fact that you're assuming your host objects return "same object" for >> doing two "obj.prop" evals -- is an assumption about mirror objects! Why do >> you think such as assumption to be true for mirrors -- whose sole purpose >> is to provide easy access to objects. You're creating multiple >> ScriptContexts and associate ENGINE_SCOPE Bindings to isolate. And yet you >> want objects from "isolated" worlds to be treated exactly like "current >> isolate world". >> >> If you do not want that kind of multiple ECMAScript global scope >> isolation at all, why not load your library/framework scripts before >> loading the user scripts? If you want to avoid clash b/w different user >> scripts (i.e., globals in user's scripts for eg.), you could implement >> "require" like primitive such as the one here -> >> https://github.com/walterhiggins/commonjs-modules-javax-script >> >> If you do want isolation and still want singleton enum-like objects, why >> not implement those in Java and expose to scripts? These would then be real >> JVM singleton objects and therefore usual identity would work. >> >> Hope this helps, >> -Sundar >> >> >> On 12/22/2015 12:25 PM, Vivin Suresh Paliath wrote: >> >> I am looking at it from the perspective of someone writing code that is >> expect to run in JavaScript environment. I will describe the runtime >> environment I have set up. Perhaps what I am running into is an artifact of >> my approach. >> >> I have a single script engine instance. In this context I evaluate some >> JS source that populates the JS global scope with some objects. When a >> custom script needs to be evaluated, I create a new script context with a >> new global. Then I copy over all bindings from the parent script context >> into the new one. I also have a module system. When a custom script >> requests a core module, the module source is evaluated in the main script >> context and a single instance of the object exposed by the module source is >> cached. This way the source only needs to be evaluated once and benefits >> from optimizations. >> >> The problem I am running into has to do with some singleton objects I >> expose; kind of like enums, and can be compared using ===. I am using a JS >> library for this and this behavior holds in the browser and on NodeJS. On >> Nashorn, because the instances were created in a different context, === >> returns false. >> >> Is there a better way to accomplish what I am doing? >> >> Regarding host objects, even if they are different from native objects, >> it seems strange to me that the semantics of things like === would be >> different especially when doing something like obj.prop === obj.prop. The >> fact that such a statement could ever return false is non-obvious unless >> implementation details of the runtime are known. >> >> I am trying to expose my runtime environment as a JS environment where a >> developer can write custom scripts using some runtime libraries and >> utilities. So behavior like this would be very surprising, and requiring >> them to know that objects might be from different contexts seems like >> abstraction leakage from the way I have implemented the runtime. They >> shouldn't have to know whether an object is a wrapped ScriptObjectMirror >> instance, since from their point of view they are just working with JS >> objects, and they don't know that they are from different "worlds" since >> they don't even know that there are different worlds. >> >> I guess I am also having a hard time seeing a scenario where === would >> need to return false in the scenario I described, unless as a developer you >> knew there were different worlds. Even then, it would essentially make some >> forms of equality comparisons impossible (e.g., o.prop === o.prop if o is >> foreign). >> >> Does the snippet I posted earlier make sense? >> On Dec 21, 2015 9:10 PM, "Sundararajan Athijegannathan" < >> >> sundararajan.athijegannathan at oracle.com> wrote: >> >>> Actually, I'm not sure if depending on === in the code is a good >>> approach -- particularly, for objects that are not script objects of the >>> current world. These are to be treated like "host objects" in >>> ECMAScript-speak. i.e., regular rules of script objects don't always apply >>> to 'host objects'. The === operator for Java objects is interpreted as >>> object identity -- and the same rule for ScriptObjectMirrors -- in that >>> both are "host objects" from the standpoint of the 'current world'. >>> >>> -Sundar >>> >>> On 12/22/2015 9:34 AM, Vivin Suresh Paliath wrote: >>> >>> Thanks for the response! I understand that in general it would be >>> difficult for foreign objects. But this seems like surprising behavior >>> given that these are both JavaScript objects. That they are unequal seems >>> to be an artifact of the implementation (the fact that JS objects from >>> different contexts are treated as foreign). Could JS objects be treated >>> differently? >>> >>> After going through the Nashorn source, I decided to try this very naive >>> approach adding the following test to ScriptRuntime#equalSameTypeValues: >>> >>> if(x instanceof ScriptObjectMirror && y instanceof ScriptObjectMirror) { >>> return x.equals(y); >>> } >>> >>> After this change, the code now returns true, because >>> ScriptObjectMirror#equals compares the actual objects. I am not sure if >>> this breaks anything though (been trying to run the test suite, but end up >>> getting some errors from make). Is there a reason this particular fix is a >>> bad idea? I can't think of a particular reason why. From the perspective of >>> the runtime, I can't see a reason why those two objects should be >>> considered different. >>> >>> I will investigate the eval approach, but ideally I would like something >>> that doesn't impose any changes on the JS code. I am developing a simple >>> runtime that exposes some objects and utilities, and where custom scripts >>> can run in their own contexts. The fact that === returns false in these >>> cases leads to some very strange behavior. >>> >>> On Mon, Dec 21, 2015 at 8:48 PM, Sundararajan Athijegannathan < >>> >>> sundararajan.athijegannathan at oracle.com> wrote: >>> >>>> Unless we create mirrors as weak refs internally (i.e., maintain 1:1 >>>> with underlying foreign object reference), there is no easy solution. And >>>> maintaining such weak refs is unnecessarily complex. "Foreign object" >>>> call/access is mean to be just a "lightweight wrapper" based access. That >>>> said, you can do the === on the foreign context itself. You can call >>>> ScriptObjectMirror's eval to evaluate === test in that foreign context. >>>> That would get right object identity. >>>> >>>> -Sundar >>>> >>>> >>>> On 12/22/2015 4:26 AM, Vivin Suresh Paliath wrote: >>>> >>>>> One more thing I noticed is that apparently a new ScriptObjectMirror >>>>> instance is probably being created each time x is dereferenced, so >>>>> "e.x === >>>>> e.x" also returns "false". >>>>> >>>>> On Mon, Dec 21, 2015 at 3:49 PM, Vivin Suresh Paliath < >>>>> vivin.paliath at gmail.com> wrote: >>>>> >>>>> I ran into an issue where === returns false even when both should be >>>>>> pointing to the same object. I'm assuming this is because one of the >>>>>> objects is wrapped by a ScriptObjectMirror, because it was defined in >>>>>> a >>>>>> different context. >>>>>> >>>>>> Here's some code that demonstrates this: >>>>>> >>>>>> ScriptEngine engine = new >>>>>> NashornScriptEngineFactory().getScriptEngine( >>>>>> new String[] { "-strict" } >>>>>> ); >>>>>> >>>>>> try { >>>>>> engine.eval("function Foo(src) { this.src = src }; var e >>>>>> = { >>>>>> x: new Foo(\"what\") };"); >>>>>> >>>>>> ScriptContext c = new SimpleScriptContext(); >>>>>> c.setBindings(engine.createBindings(), >>>>>> ScriptContext.ENGINE_SCOPE); >>>>>> >>>>>> >>>>>> c.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE)); >>>>>> >>>>>> System.out.println(engine.eval("var z = e.x; z === >>>>>> e.x;", c)); >>>>>> } catch(Exception e) { >>>>>> throw new RuntimeException(e); >>>>>> } >>>>>> >>>>>> This prints out "false". Is there a way around this? I am also >>>>>> explicitly >>>>>> copying over all the bindings from the parent scope into the new >>>>>> scope so >>>>>> that I have access to "e". Could this be the source of the problem, >>>>>> and if >>>>>> so, is there a better way to achieve what I'm trying to do? >>>>>> >>>>>> -- >>>>>> Ruin untold; >>>>>> And thine own sadness, >>>>>> Sing in the grass, >>>>>> When eve has forgot, that no more hear common things that gleam and >>>>>> pass; >>>>>> But seek alone to lip, sad Rose of love and ruin untold; >>>>>> And thine own mother >>>>>> Can know it as I know >>>>>> More than another >>>>>> What makes your own sadness, >>>>>> Set in her eyes. >>>>>> >>>>>> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >>>>>> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >>>>>> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >>>>>> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >>>>>> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >>>>>> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >>>>>> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >>>>>> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >>>>>> i",pack"B32",$_}$j=~m/.{8}/g >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Ruin untold; >>> And thine own sadness, >>> Sing in the grass, >>> When eve has forgot, that no more hear common things that gleam and pass; >>> But seek alone to lip, sad Rose of love and ruin untold; >>> And thine own mother >>> Can know it as I know >>> More than another >>> What makes your own sadness, >>> Set in her eyes. >>> >>> map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". >>> ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". >>> ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". >>> ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". >>> ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". >>> ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". >>> ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". >>> ":13:02:11:01:02:11:01:12:02";map{print chr unpack" >>> i",pack"B32",$_}$j=~m/.{8}/g >>> >>> >>> >> > > > -- > Ruin untold; > And thine own sadness, > Sing in the grass, > When eve has forgot, that no more hear common things that gleam and pass; > But seek alone to lip, sad Rose of love and ruin untold; > And thine own mother > Can know it as I know > More than another > What makes your own sadness, > Set in her eyes. > > map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". > ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". > ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". > ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". > ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". > ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". > ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". > ":13:02:11:01:02:11:01:12:02";map{print chr unpack" > i",pack"B32",$_}$j=~m/.{8}/g > > > -- Ruin untold; And thine own sadness, Sing in the grass, When eve has forgot, that no more hear common things that gleam and pass; But seek alone to lip, sad Rose of love and ruin untold; And thine own mother Can know it as I know More than another What makes your own sadness, Set in her eyes. map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". ":13:02:11:01:02:11:01:12:02";map{print chr unpack" i",pack"B32",$_}$j=~m/.{8}/g From vivin.paliath at gmail.com Fri Dec 25 21:35:52 2015 From: vivin.paliath at gmail.com (Vivin Suresh Paliath) Date: Fri, 25 Dec 2015 14:35:52 -0700 Subject: Dereferencing properties on foreign script objects creates a new ScriptObjectMirror instance each time, making direct comparisons difficult Message-ID: I thought I would start a separate thread for this dedicated to discussing possible fixes. The issue is the following "surprising" behavior when dealing with foreign script-objects: foreignObj === foreignObj; //true foreignObj.prop === foreignObj.prop; //false I took a quick stab at fixing this. My first approach is quite naive; I just have a cyclic reference (see here ) from ScriptObject back to its mirror. It does seem to fix the issue and none of the tests seem to fail either. I initially used a weakref, but I'm not sure if that would have bought me anything extra. The weakref would be GC'd when no strong references are held on the mirror, but I think even without the weakref, that would be the case. I admit I don't like the cyclic reference, but are there any other drawbacks with the approach? Another approach I tried was to use a WeakHashMap in Context. I tried that approach (see here ) as well and it also seemed to fix the issue without causing any tests to fail. Thanks! Vivin -- Ruin untold; And thine own sadness, Sing in the grass, When eve has forgot, that no more hear common things that gleam and pass; But seek alone to lip, sad Rose of love and ruin untold; And thine own mother Can know it as I know More than another What makes your own sadness, Set in her eyes. map{@n=split//;$j.=$n[0]x$n[1]}split/:/,"01:11:02". ":11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01". ":11:04:11:06:12:04:11:01:12:01:13:02:12:01:14:01". ":13:01:11:03:12:01:11:04:12:02:11:01:11:01:13:02". ":11:03:11:06:11:01:11:05:12:02:11:01:11:01:13:02". ":11:02:12:01:12:04:11:06:12:01:11:04:12:04:11:01". ":12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01". ":13:02:11:01:02:11:01:12:02";map{print chr unpack" i",pack"B32",$_}$j=~m/.{8}/g From roland.bouman at gmail.com Tue Dec 29 01:53:41 2015 From: roland.bouman at gmail.com (Roland Bouman) Date: Tue, 29 Dec 2015 02:53:41 +0100 Subject: Using java.math.BigInteger in Nashorn / jjs? Message-ID: Hi all, I'm new to this list - apologies if this topic came up earlier, I'm trying to work use java,math,BigInteger in my javascript - obviously to overcome the limitations of the JavaScript built-in Number type. Please consider the concrete example of a Java function I would like to get working in Nashorn / jss javascript below: public static BigInteger fibonacci(int n) { BigInteger prev = new BigInteger("0"); if (n == 0) { return prev; } BigInteger next = new BigInteger("1"); if (n == 1) { return next; } BigInteger fib = null; int i; for (i = 1; i < n; i++) { fib = prev.add(next); prev = next; next = fib; } return fib; } We can test with these values: n=77: 5527939700884757 n=78: 8944394323791464 n=79: 14472334024676221 So far so good. Now I try the - what I think is - equivalent function in javascript: function fibonacci(n) { var BigInteger = Java.type("java.math.BigInteger"); prev = new BigInteger("0"); if (n == 0) return prev; next = new BigInteger("1"); if (n == 1) return next; var i, fib = null; for (i = 1; i < n; i++) { fib = prev.add(next); prev = next; next = fib; } return fib; } However, now we get different results: n=77: 5527939700884757 n=78: 8944394323791464 n=79: 14472334024676220 Note that the value for n=79 is off by one. What I suspect happens is that the next passed to .add gets first evaluated and then silently cast to a javascript Number type before it is actually passed into add (at which point it will probably need to be converted to a BigInteger again) but then it will have lost its precision already. A simpler example can be shown here: var str, BigInteger = Java.type("java.math.BigInteger"); str = "9999999999999998"; print(str + ": " + (new BigInteger(str)).toString()); str = "9999999999999999"; print(str + ": " + (new BigInteger(str)).toString()); outputs: 9999999999999998: 9999999999999998 9999999999999999: 10000000000000000 (whereas in java the ouput checks out as expected) Is there anything I can do to make BigInteger additions work in jss / Nashorn javascript code? Thanks in advance, -- Roland Bouman blog: http://rpbouman.blogspot.com/ twitter: @rolandbouman linkedin: http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro Author of "Pentaho Solutions" (Wiley, ISBN: 978-0-470-48432-6 http://tinyurl.com/lvxa88) and "Pentaho Kettle Solutions" (Wiley, ISBN: 978-0-470-63517-9 http://tinyurl.com/33r7a8m) From sundararajan.athijegannathan at oracle.com Tue Dec 29 04:24:27 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 29 Dec 2015 09:54:27 +0530 Subject: RFR 8146251: Avoid annotation to specify documentation for JS builtin functions Message-ID: <56820AFB.5030205@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8146251/ for https://bugs.openjdk.java.net/browse/JDK-8146251 Instead of annotation like: @Function(attributes = Attribute.NOT_ENUMERABLE, where = Where.CONSTRUCTOR, documentation = "returns the prototype of the specified object") to specify documentation, a properties file is used and the documentation property key is automatically derived (Object.prototype.hasOwnProperty, Object.keys etc.) This allow adding documentation (+ localizing it) by just editing a properties file. Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Tue Dec 29 05:39:31 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 29 Dec 2015 11:09:31 +0530 Subject: RFR 8146253: jjs should look for "doc string" property to print documentation on shift-tab Message-ID: <56821C93.6010709@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8146253/ for https://bugs.openjdk.java.net/browse/JDK-8146253 Note that this bug just adds printing __doc__ property where it is available (on shift-tab). There is no change to associate doc string to a function or an object. But, users can just define that property. If a user defined function is defined as follows, jjs prints __doc__ string when shift-tab is pressed after "func". function func() { print("hello") } func.__doc__ = "prints 'hello' in the standard output"; Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Tue Dec 29 11:22:48 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 29 Dec 2015 16:52:48 +0530 Subject: Using java.math.BigInteger in Nashorn / jjs? In-Reply-To: References: Message-ID: <56826D08.1070003@oracle.com> Hi, I initially that the recent fix by Hannes (see also: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-December/005762.html).would fix this issue as well. But, I applied patch by Hannes and verified that the issue is not fixed by that patch. I've filed a new bug: https://bugs.openjdk.java.net/browse/JDK-8146264 Thanks, -Sundar ** On 12/29/2015 7:23 AM, Roland Bouman wrote: > Please consider the concrete example of a Java function I would like to get > working in Nashorn / jss javascript below: > > public static BigInteger fibonacci(int n) { > BigInteger prev = new BigInteger("0"); > if (n == 0) { > return prev; > } > BigInteger next = new BigInteger("1"); > if (n == 1) { > return next; > } > BigInteger fib = null; > int i; > for (i = 1; i < n; i++) { > fib = prev.add(next); > prev = next; > next = fib; > } > return fib; > } > > We can test with these values: > > n=77: 5527939700884757 > n=78: 8944394323791464 > n=79: 14472334024676221 > > So far so good. Now I try the - what I think is - equivalent function in > javascript: > > function fibonacci(n) { > var BigInteger = Java.type("java.math.BigInteger"); > prev = new BigInteger("0"); > if (n == 0) return prev; > > next = new BigInteger("1"); > if (n == 1) return next; > > var i, fib = null; > for (i = 1; i < n; i++) { > fib = prev.add(next); > prev = next; > next = fib; > } > return fib; > } > > However, now we get different results: > > n=77: 5527939700884757 > n=78: 8944394323791464 > n=79: 14472334024676220 > > Note that the value for n=79 is off by one. From szegedia at gmail.com Tue Dec 29 16:03:41 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 29 Dec 2015 17:03:41 +0100 Subject: RFR 8146253: jjs should look for "doc string" property to print documentation on shift-tab In-Reply-To: <56821C93.6010709@oracle.com> References: <56821C93.6010709@oracle.com> Message-ID: +1 > On Dec 29, 2015, at 6:39 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8146253/ for https://bugs.openjdk.java.net/browse/JDK-8146253 > > Note that this bug just adds printing __doc__ property where it is available (on shift-tab). There is no change to associate doc string to a function or an object. But, users can just define that property. If a user defined function is defined as follows, jjs prints __doc__ string when shift-tab is pressed after "func". > > function func() { print("hello") } > func.__doc__ = "prints 'hello' in the standard output"; > > Thanks, > -Sundar From szegedia at gmail.com Tue Dec 29 16:22:00 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 29 Dec 2015 17:22:00 +0100 Subject: RFR 8146251: Avoid annotation to specify documentation for JS builtin functions In-Reply-To: <56820AFB.5030205@oracle.com> References: <56820AFB.5030205@oracle.com> Message-ID: <0C63128E-808E-4AB2-BEF0-439417A4C35F@gmail.com> +1 On Dec 29, 2015, at 5:24 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8146251/ for https://bugs.openjdk.java.net/browse/JDK-8146251 > > Instead of annotation like: > > @Function(attributes = Attribute.NOT_ENUMERABLE, where = Where.CONSTRUCTOR, documentation = "returns the prototype of the specified object") > > to specify documentation, a properties file is used and the documentation property key is automatically derived (Object.prototype.hasOwnProperty, Object.keys etc.) This allow adding documentation (+ localizing it) by just editing a properties file. > > Thanks, > -Sundar