From sundararajan.athijegannathan at oracle.com Thu Oct 1 13:18:24 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 1 Oct 2015 18:48:24 +0530 Subject: RFR 8138616: invokeFunction fails if function calls a function defined in GLOBAL_SCOPE Message-ID: <560D32A0.1060504@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8138616/ for https://bugs.openjdk.java.net/browse/JDK-8138616 Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Thu Oct 1 13:45:06 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 1 Oct 2015 19:15:06 +0530 Subject: RFR 8138616: invokeFunction fails if function calls a function defined in GLOBAL_SCOPE In-Reply-To: <560D32A0.1060504@oracle.com> References: <560D32A0.1060504@oracle.com> Message-ID: <560D38E2.5040901@oracle.com> Forgot to add: piggybacked a test change. Moved a test from jdk.nashorn.api.scripting to jdk.nashorn.api.scripting.test package. -Sundar On 10/1/2015 6:48 PM, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8138616/ for > https://bugs.openjdk.java.net/browse/JDK-8138616 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Thu Oct 1 14:32:54 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 1 Oct 2015 16:32:54 +0200 Subject: RFR 8138616: invokeFunction fails if function calls a function defined in GLOBAL_SCOPE In-Reply-To: <560D38E2.5040901@oracle.com> References: <560D32A0.1060504@oracle.com> <560D38E2.5040901@oracle.com> Message-ID: <560D4416.4070907@oracle.com> +1 Am 2015-10-01 um 15:45 schrieb Sundararajan Athijegannathan: > Forgot to add: piggybacked a test change. Moved a test from > jdk.nashorn.api.scripting to jdk.nashorn.api.scripting.test package. > > -Sundar > > On 10/1/2015 6:48 PM, Sundararajan Athijegannathan wrote: >> Please review http://cr.openjdk.java.net/~sundar/8138616/ for >> https://bugs.openjdk.java.net/browse/JDK-8138616 >> >> Thanks, >> -Sundar > From michael.haupt at oracle.com Thu Oct 1 15:50:43 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 1 Oct 2015 17:50:43 +0200 Subject: RFR 8138616: invokeFunction fails if function calls a function defined in GLOBAL_SCOPE In-Reply-To: <560D4416.4070907@oracle.com> References: <560D32A0.1060504@oracle.com> <560D38E2.5040901@oracle.com> <560D4416.4070907@oracle.com> Message-ID: <3DBA0BCD-AA36-4229-A822-341C2EBF5B18@oracle.com> ... and a lower-case thumbs up from me. Best, Michael > Am 01.10.2015 um 16:32 schrieb Hannes Wallnoefer : > > +1 > > Am 2015-10-01 um 15:45 schrieb Sundararajan Athijegannathan: >> Forgot to add: piggybacked a test change. Moved a test from jdk.nashorn.api.scripting to jdk.nashorn.api.scripting.test package. >> >> -Sundar >> >> On 10/1/2015 6:48 PM, Sundararajan Athijegannathan wrote: >>> Please review http://cr.openjdk.java.net/~sundar/8138616/ for https://bugs.openjdk.java.net/browse/JDK-8138616 >>> >>> 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 attila.szegedi at oracle.com Thu Oct 1 21:49:44 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 1 Oct 2015 23:49:44 +0200 Subject: RFR 8138616: invokeFunction fails if function calls a function defined in GLOBAL_SCOPE In-Reply-To: <560D4416.4070907@oracle.com> References: <560D32A0.1060504@oracle.com> <560D38E2.5040901@oracle.com> <560D4416.4070907@oracle.com> Message-ID: +1 > On Oct 1, 2015, at 4:32 PM, Hannes Wallnoefer wrote: > > +1 > > Am 2015-10-01 um 15:45 schrieb Sundararajan Athijegannathan: >> Forgot to add: piggybacked a test change. Moved a test from jdk.nashorn.api.scripting to jdk.nashorn.api.scripting.test package. >> >> -Sundar >> >> On 10/1/2015 6:48 PM, Sundararajan Athijegannathan wrote: >>> Please review http://cr.openjdk.java.net/~sundar/8138616/ for https://bugs.openjdk.java.net/browse/JDK-8138616 >>> >>> Thanks, >>> -Sundar >> > From hannes.wallnoefer at oracle.com Fri Oct 2 11:08:29 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 2 Oct 2015 13:08:29 +0200 Subject: RFR: JDK-8137281: OutOfMemoryError with large numeric keys in JSON.parse Message-ID: <560E65AD.7080202@oracle.com> Please review JDK-8137281: OutOfMemoryError with large numeric keys in JSON.parse: http://cr.openjdk.java.net/~hannesw/8137281/webrev/ Thanks, Hannes From michael.haupt at oracle.com Fri Oct 2 12:36:47 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 2 Oct 2015 14:36:47 +0200 Subject: RFR: JDK-8137281: OutOfMemoryError with large numeric keys in JSON.parse In-Reply-To: <560E65AD.7080202@oracle.com> References: <560E65AD.7080202@oracle.com> Message-ID: Hi Hannes, lower-case thumbs up. Best, Michael > Am 02.10.2015 um 13:08 schrieb Hannes Wallnoefer : > > Please review JDK-8137281: OutOfMemoryError with large numeric keys in JSON.parse: > > http://cr.openjdk.java.net/~hannesw/8137281/webrev/ > > Thanks, > Hannes -- 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 attila.szegedi at oracle.com Fri Oct 2 12:57:10 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 2 Oct 2015 14:57:10 +0200 Subject: RFR: JDK-8137281: OutOfMemoryError with large numeric keys in JSON.parse In-Reply-To: <560E65AD.7080202@oracle.com> References: <560E65AD.7080202@oracle.com> Message-ID: +1 > On Oct 2, 2015, at 1:08 PM, Hannes Wallnoefer wrote: > > Please review JDK-8137281: OutOfMemoryError with large numeric keys in JSON.parse: > > http://cr.openjdk.java.net/~hannesw/8137281/webrev/ > > Thanks, > Hannes From marcus at lagergren.net Mon Oct 5 07:25:35 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 5 Oct 2015 09:25:35 +0200 Subject: RFR: JDK-8137281: OutOfMemoryError with large numeric keys in JSON.parse In-Reply-To: <560E65AD.7080202@oracle.com> References: <560E65AD.7080202@oracle.com> Message-ID: +1. No regressions everywhere on e.g. Octane? I have a feeling we bumped that buffer up to 8 megs for performance reasons. For the general case, this is of course way too much. /M > On 02 Oct 2015, at 13:08, Hannes Wallnoefer wrote: > > Please review JDK-8137281: OutOfMemoryError with large numeric keys in JSON.parse: > > http://cr.openjdk.java.net/~hannesw/8137281/webrev/ > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Mon Oct 5 07:43:35 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 5 Oct 2015 09:43:35 +0200 Subject: RFR: JDK-8137281: OutOfMemoryError with large numeric keys in JSON.parse In-Reply-To: References: <560E65AD.7080202@oracle.com> Message-ID: <56122A27.303@oracle.com> Thanks Marcus. Actually the lower threshold does not affect any script in Octane or Sunspider. When you set it so low that it starts being used more it really hurts performance, but 1 million is still pretty high while allowing us to keep a few of these in memory at a time. Hannes Am 2015-10-05 um 09:25 schrieb Marcus Lagergren: > +1. No regressions everywhere on e.g. Octane? I have a feeling we bumped that buffer up to 8 megs for performance reasons. For the general case, this is of course way too much. > > /M > >> On 02 Oct 2015, at 13:08, Hannes Wallnoefer wrote: >> >> Please review JDK-8137281: OutOfMemoryError with large numeric keys in JSON.parse: >> >> http://cr.openjdk.java.net/~hannesw/8137281/webrev/ >> >> Thanks, >> Hannes From marcus at lagergren.net Mon Oct 5 08:00:31 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 5 Oct 2015 10:00:31 +0200 Subject: RFR: JDK-8137281: OutOfMemoryError with large numeric keys in JSON.parse In-Reply-To: <56122A27.303@oracle.com> References: <560E65AD.7080202@oracle.com> <56122A27.303@oracle.com> Message-ID: Happy with that. +1 /M > On 05 Oct 2015, at 09:43, Hannes Wallnoefer wrote: > > Thanks Marcus. > > Actually the lower threshold does not affect any script in Octane or Sunspider. When you set it so low that it starts being used more it really hurts performance, but 1 million is still pretty high while allowing us to keep a few of these in memory at a time. > > Hannes > > > Am 2015-10-05 um 09:25 schrieb Marcus Lagergren: >> +1. No regressions everywhere on e.g. Octane? I have a feeling we bumped that buffer up to 8 megs for performance reasons. For the general case, this is of course way too much. >> >> /M >> >>> On 02 Oct 2015, at 13:08, Hannes Wallnoefer wrote: >>> >>> Please review JDK-8137281: OutOfMemoryError with large numeric keys in JSON.parse: >>> >>> http://cr.openjdk.java.net/~hannesw/8137281/webrev/ >>> >>> Thanks, >>> Hannes > From hannes.wallnoefer at oracle.com Mon Oct 5 15:33:55 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 5 Oct 2015 17:33:55 +0200 Subject: RFR: 8138882: Performance regression due to anonymous classloading Message-ID: <56129863.20706@oracle.com> Please review JDK-8138882: Performance regression due to anonymous classloading: http://cr.openjdk.java.net/~hannesw/8138882/ Thanks, Hannes From attila.szegedi at oracle.com Mon Oct 5 16:09:24 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 5 Oct 2015 18:09:24 +0200 Subject: RFR: 8138882: Performance regression due to anonymous classloading In-Reply-To: <56129863.20706@oracle.com> References: <56129863.20706@oracle.com> Message-ID: <0B71FDF9-BA55-458E-BAF0-FB6539DC70F6@oracle.com> +1. Thanks for doing this. > On Oct 5, 2015, at 5:33 PM, Hannes Wallnoefer wrote: > > Please review JDK-8138882: Performance regression due to anonymous classloading: > > http://cr.openjdk.java.net/~hannesw/8138882/ > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Mon Oct 5 16:22:05 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 5 Oct 2015 21:52:05 +0530 Subject: RFR: 8138882: Performance regression due to anonymous classloading In-Reply-To: <56129863.20706@oracle.com> References: <56129863.20706@oracle.com> Message-ID: <5612A3AD.7050700@oracle.com> +1 On 10/5/2015 9:03 PM, Hannes Wallnoefer wrote: > Please review JDK-8138882: Performance regression due to anonymous > classloading: > > http://cr.openjdk.java.net/~hannesw/8138882/ > > Thanks, > Hannes From michel at undercouch.de Mon Oct 5 18:02:51 2015 From: michel at undercouch.de (=?UTF-8?Q?Michel_Kr=c3=a4mer?=) Date: Mon, 5 Oct 2015 20:02:51 +0200 Subject: Excessive memory usage Message-ID: <5612BB4B.3020303@undercouch.de> Hi! I'm currently working on TypeScript support for Vert.x. I'm trying to run the TypeScript compiler on Nashorn. It works well, but the process uses a lot of memory. I'm wondering if there is a bug in Nashorn or if I'm doing something wrong. I uploaded a small example project demonstrating the issue: https://github.com/michel-kraemer/nashorn-memory-test I tested it under Ubuntu 14.04 with JDK 8u60. I run javac Main.java && java -Xmx256M -cp . Main and watch the process with top. The resident memory quickly goes up to 1 GB and after about 20 iterations grows even further to 1.2 GB. After about 500 iterations it sometimes even goes up to 1.5 GB where it stays until the end of the program. That's 1.3 GB more than I specified with -Xmx. I know this is metaspace, but I wonder why Nashorn needs so much of it. By the way, even if I do only 1 iteration the process still goes up to 400-500 MB. Any ideas? Cheers, Michel From hannes.wallnoefer at oracle.com Mon Oct 5 19:34:02 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 5 Oct 2015 21:34:02 +0200 Subject: Excessive memory usage In-Reply-To: <5612BB4B.3020303@undercouch.de> References: <5612BB4B.3020303@undercouch.de> Message-ID: <5612D0AA.3030804@oracle.com> Hi Michel, Thanks for the quick and easy github repository to reproduce this. Looking at the code running with jvisualvm I can't see any excessive memory usage. Both with JDK 8u60 and 9 heap usage is around 150 MB. The fact that Java reserves a lot of memory on Linux is a well-known fact. It's not related to Nashorn, but rather to how Java interacts with the Linux memory system. It is a bit annoying, but usually it's not a problem and does not reflect Java heap usage. Hannes Am 2015-10-05 um 20:02 schrieb Michel Kr?mer: > Hi! > > I'm currently working on TypeScript support for Vert.x. I'm trying to > run the TypeScript compiler on Nashorn. It works well, but the process > uses a lot of memory. I'm wondering if there is a bug in Nashorn or if > I'm doing something wrong. > > I uploaded a small example project demonstrating the issue: > https://github.com/michel-kraemer/nashorn-memory-test > > I tested it under Ubuntu 14.04 with JDK 8u60. I run > > javac Main.java && java -Xmx256M -cp . Main > > and watch the process with top. The resident memory quickly goes up to > 1 GB and after about 20 iterations grows even further to 1.2 GB. After > about 500 iterations it sometimes even goes up to 1.5 GB where it > stays until the end of the program. That's 1.3 GB more than I > specified with -Xmx. I know this is metaspace, but I wonder why > Nashorn needs so much of it. By the way, even if I do only 1 iteration > the process still goes up to 400-500 MB. > > Any ideas? > > Cheers, > Michel From michel at undercouch.de Mon Oct 5 20:38:40 2015 From: michel at undercouch.de (=?UTF-8?Q?Michel_Kr=c3=a4mer?=) Date: Mon, 5 Oct 2015 22:38:40 +0200 Subject: Excessive memory usage In-Reply-To: <5612DB6E.4010109@oracle.com> References: <5612BB4B.3020303@undercouch.de> <5612D0AA.3030804@oracle.com> <5612D3AF.3000604@undercouch.de> <5612DB6E.4010109@oracle.com> Message-ID: <5612DFD0.2010406@undercouch.de> (Ooops. I didn't press the reply-to-list button.) Thanks for the link to the bug report. I will keep observing the issue and let you know if I find something. If possible I'll also do a test with a snapshot build of JDK9 and see if things have changed. Thanks, Michel Am 05.10.2015 um 22:19 schrieb Hannes Wallnoefer: > Well maybe there is a problem if the process is killed because it uses > too much memory. I just think it's not heap space, at least not in that > particular code in your github repository. Is that the same code that is > running in the CI environments? > > I must say I did see increased GC activity and a slowdown after half the > iterations. > > We did fix some problems recently that may cause memory problems under > certain circumstances, such as > https://bugs.openjdk.java.net/browse/JDK-8137333 > > So I'm not saying there isn't a problem - there may well be one. I just > think that the observed memory numbers on Linux are not that > extraordinary. Please keep observing and let us know if you find > anything new and noteworthy. > > Hannes > > > Am 2015-10-05 um 21:46 schrieb Michel Kr?mer: >> Hannes, >> >> Thanks for the quick response. I see... >> >> The reason why I'm asking all this is because I tried to run the unit >> tests for vertx-lang-typescript on Travis CI and Circle CI and they >> both killed the process after it had reached 4GB (in fact very quickly >> after the process had started). I had to play with environment >> variables such as MALLOC_ARENA_MAX to get it down to 2.5 GB. >> >> At least it runs now, but I figured it might be something of interest >> for you as I've never experienced this behaviour with any other code >> that I ran on Travis CI or Circle CI (and I have a couple of open >> source projects running there). The memory usage increased quickly >> when I ran JavaScript code so I thought it might have something to do >> with Nashorn. >> >> I was able to reproduce the issue on my own Ubuntu machine so it's not >> related to Travis or Circle. >> >> As far as I can tell heap memory is not the problem. It seems >> metaspace is used a lot or maybe direct memory buffers or maybe even >> something else!? >> >> Anyway, if you say this much of memory is normal under Linux then I'm >> completely fine with it. I just thought if it wasn't the case you >> might want to know. >> >> Cheers, >> Michel >> >> >> Am 05.10.2015 um 21:34 schrieb Hannes Wallnoefer: >>> Hi Michel, >>> >>> Thanks for the quick and easy github repository to reproduce this. >>> >>> Looking at the code running with jvisualvm I can't see any excessive >>> memory usage. Both with JDK 8u60 and 9 heap usage is around 150 MB. >>> >>> The fact that Java reserves a lot of memory on Linux is a well-known >>> fact. It's not related to Nashorn, but rather to how Java interacts with >>> the Linux memory system. It is a bit annoying, but usually it's not a >>> problem and does not reflect Java heap usage. >>> >>> Hannes >>> >>> >>> Am 2015-10-05 um 20:02 schrieb Michel Kr?mer: >>>> Hi! >>>> >>>> I'm currently working on TypeScript support for Vert.x. I'm trying to >>>> run the TypeScript compiler on Nashorn. It works well, but the process >>>> uses a lot of memory. I'm wondering if there is a bug in Nashorn or if >>>> I'm doing something wrong. >>>> >>>> I uploaded a small example project demonstrating the issue: >>>> https://github.com/michel-kraemer/nashorn-memory-test >>>> >>>> I tested it under Ubuntu 14.04 with JDK 8u60. I run >>>> >>>> javac Main.java && java -Xmx256M -cp . Main >>>> >>>> and watch the process with top. The resident memory quickly goes up to >>>> 1 GB and after about 20 iterations grows even further to 1.2 GB. After >>>> about 500 iterations it sometimes even goes up to 1.5 GB where it >>>> stays until the end of the program. That's 1.3 GB more than I >>>> specified with -Xmx. I know this is metaspace, but I wonder why >>>> Nashorn needs so much of it. By the way, even if I do only 1 iteration >>>> the process still goes up to 400-500 MB. >>>> >>>> Any ideas? >>>> >>>> Cheers, >>>> Michel >>> >>> > > From sundararajan.athijegannathan at oracle.com Tue Oct 6 08:24:36 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 6 Oct 2015 13:54:36 +0530 Subject: RFR 8138910: Ctrl-D causes jjs to crash with NPE Message-ID: <56138544.1080305@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8138910/ for https://bugs.openjdk.java.net/browse/JDK-8138910 Thanks, -Sundar From attila.szegedi at oracle.com Tue Oct 6 08:41:21 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 6 Oct 2015 10:41:21 +0200 Subject: RFR 8138910: Ctrl-D causes jjs to crash with NPE In-Reply-To: <56138544.1080305@oracle.com> References: <56138544.1080305@oracle.com> Message-ID: +1 > On Oct 6, 2015, at 10:24 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8138910/ for https://bugs.openjdk.java.net/browse/JDK-8138910 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Tue Oct 6 08:42:47 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 6 Oct 2015 10:42:47 +0200 Subject: RFR 8138910: Ctrl-D causes jjs to crash with NPE In-Reply-To: <56138544.1080305@oracle.com> References: <56138544.1080305@oracle.com> Message-ID: <56138987.7000000@oracle.com> +1 Am 2015-10-06 um 10:24 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8138910/ for > https://bugs.openjdk.java.net/browse/JDK-8138910 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Tue Oct 6 13:05:12 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 6 Oct 2015 15:05:12 +0200 Subject: RFR: 8138758: U+180E not recognized as whitespace by Joni Message-ID: <5613C708.7050803@oracle.com> Please review 8138758: U+180E not recognized as whitespace by Joni http://cr.openjdk.java.net/~hannesw/8138758/ Thanks, Hannes From attila.szegedi at oracle.com Tue Oct 6 13:07:25 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 6 Oct 2015 15:07:25 +0200 Subject: RFR: 8138758: U+180E not recognized as whitespace by Joni In-Reply-To: <5613C708.7050803@oracle.com> References: <5613C708.7050803@oracle.com> Message-ID: +1 > On Oct 6, 2015, at 3:05 PM, Hannes Wallnoefer wrote: > > Please review 8138758: U+180E not recognized as whitespace by Joni > > http://cr.openjdk.java.net/~hannesw/8138758/ > > Thanks, > Hannes > > > From sundararajan.athijegannathan at oracle.com Tue Oct 6 13:08:34 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 6 Oct 2015 18:38:34 +0530 Subject: RFR: 8138758: U+180E not recognized as whitespace by Joni In-Reply-To: <5613C708.7050803@oracle.com> References: <5613C708.7050803@oracle.com> Message-ID: <5613C7D2.60708@oracle.com> +1 On 10/6/2015 6:35 PM, Hannes Wallnoefer wrote: > Please review 8138758: U+180E not recognized as whitespace by Joni > > http://cr.openjdk.java.net/~hannesw/8138758/ > > Thanks, > Hannes > > > From richard.d.evans at oracle.com Tue Oct 6 15:50:43 2015 From: richard.d.evans at oracle.com (Richard Evans) Date: Tue, 6 Oct 2015 08:50:43 -0700 (PDT) Subject: What is codebase for compiled Nashorn scripts? Message-ID: I'm running with a Java Security manager, trying to give permissions to compiled Nashorn JavaScript, but cannot find the right codebase. Some debug has shown an access control context entry like: ProtectionDomain (null ) HYPERLINK "mailto:jdk.nashorn.internal.runtime.ScriptLoader at 67e1a6ee"jdk.nashorn.internal.runtime.ScriptLoader at 67e1a6ee HYPERLINK "mailto:java.security.Permissions at 28443842"java.security.Permissions at 28443842 ( ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.runtime") ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.scripts") ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.objects") ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.runtime.linker") ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.runtime.arrays") ) Looks like the codebase is null - how can this be specified in a policy file? Or can the codebase be set somewhere? Thanks Richard -- http://www.oracle.com/ Richard Evans | Product Architect Phone: HYPERLINK "tel:+44%201223%20228408"+44 1223 228408 | Mobile: HYPERLINK "tel:+44%207973%20839664"+44 7973 839664 Oracle Product Development Newton House Cambrige Business Park | Cambridge | CB4 0WZ | United Kingdom ORACLE Corporation UK Ltd is a company incorporated in England & Wales | Company Reg. No. 1782505 | Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Tue Oct 6 16:27:37 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 6 Oct 2015 21:57:37 +0530 Subject: What is codebase for compiled Nashorn scripts? In-Reply-To: References: Message-ID: <5613F679.9040302@oracle.com> If your script loaded from a URL (via 'load' call), then you can use that URL in policy file and give permissions to that script. If it is "eval", you always get a 'sandbox' script. If you're using ScriptEngine.eval with a Reader, then you can pass a jdk.nashorn.api.scripting.URLReader (https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/URLReader.html). In that case, the underlying URL is the code origin and you can give permissions to that URL in your policy. hope this helps, -Sundar On 10/6/2015 9:20 PM, Richard Evans wrote: > I'm running with a Java Security manager, trying to give permissions to compiled Nashorn JavaScript, but cannot find the right codebase. > > > > Some debug has shown an access control context entry like: > > > > ProtectionDomain (null ) > > HYPERLINK "mailto:jdk.nashorn.internal.runtime.ScriptLoader at 67e1a6ee"jdk.nashorn.internal.runtime.ScriptLoader at 67e1a6ee > > > > HYPERLINK "mailto:java.security.Permissions at 28443842"java.security.Permissions at 28443842 ( > > ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.runtime") > > ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.scripts") > > ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.objects") > > ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.runtime.linker") > > ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.runtime.arrays") > > ) > > > > Looks like the codebase is null - how can this be specified in a policy file? Or can the codebase be set somewhere? > > > > Thanks > > > > Richard > > > From richard.d.evans at oracle.com Wed Oct 7 09:46:40 2015 From: richard.d.evans at oracle.com (Richard Evans) Date: Wed, 7 Oct 2015 02:46:40 -0700 (PDT) Subject: jdk.nashorn.api.scripting.ScriptUtils.wrap Message-ID: <7b5c2211-246e-4be2-8d5c-28499108e3a9@default> Sometime after jdk1.8u32 this method changed to take an internal jdk.nashorn.internal.runtime.ScriptObject argument. This means that code compiled with 1.8u20 will not work with later releases, and vice versa. Was this change intentional? Is this API now fixed for all future jdk1.8 and 1.9 releases? Thanks Richard -- http://www.oracle.com/ Richard Evans | Product Architect Phone: HYPERLINK "tel:+44%201223%20228408"+44 1223 228408 | Mobile: HYPERLINK "tel:+44%207973%20839664"+44 7973 839664 Oracle Product Development Newton House Cambrige Business Park | Cambridge | CB4 0WZ | United Kingdom ORACLE Corporation UK Ltd is a company incorporated in England & Wales | Company Reg. No. 1782505 | Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Wed Oct 7 11:43:28 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 7 Oct 2015 13:43:28 +0200 Subject: RFR(S): 8139038: cleanup and documentation around JSAdapter Message-ID: <7900F612-AE9E-43A4-8ECA-67A34D4AB042@oracle.com> Dear all, please review this (mostly cosmetic) change. RFE: https://bugs.openjdk.java.net/browse/JDK-8139038 Webrev: http://cr.openjdk.java.net/~mhaupt/8139038/webrev.00 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 attila.szegedi at oracle.com Wed Oct 7 11:47:03 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 7 Oct 2015 13:47:03 +0200 Subject: RFR(S): 8139038: cleanup and documentation around JSAdapter In-Reply-To: <7900F612-AE9E-43A4-8ECA-67A34D4AB042@oracle.com> References: <7900F612-AE9E-43A4-8ECA-67A34D4AB042@oracle.com> Message-ID: +1 > On Oct 7, 2015, at 1:43 PM, Michael Haupt wrote: > > Dear all, > > please review this (mostly cosmetic) change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8139038 > Webrev: http://cr.openjdk.java.net/~mhaupt/8139038/webrev.00 > > 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 hannes.wallnoefer at oracle.com Wed Oct 7 11:54:19 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 7 Oct 2015 13:54:19 +0200 Subject: RFR(S): 8139038: cleanup and documentation around JSAdapter In-Reply-To: <7900F612-AE9E-43A4-8ECA-67A34D4AB042@oracle.com> References: <7900F612-AE9E-43A4-8ECA-67A34D4AB042@oracle.com> Message-ID: <561507EB.4010000@oracle.com> +1 Am 2015-10-07 um 13:43 schrieb Michael Haupt: > Dear all, > > please review this (mostly cosmetic) change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8139038 > Webrev: http://cr.openjdk.java.net/~mhaupt/8139038/webrev.00 > > Thanks, > > Michael > From michael.haupt at oracle.com Wed Oct 7 12:54:22 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 7 Oct 2015 14:54:22 +0200 Subject: RFR(XS): 8139047: add test for JSAdapter __getIds__ Message-ID: Dear all, please review this very small change (it adds a single test). RFE: https://bugs.openjdk.java.net/browse/JDK-8139047 Webrev: http://cr.openjdk.java.net/~mhaupt/8139047/webrev.00 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 sundararajan.athijegannathan at oracle.com Wed Oct 7 12:54:58 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 7 Oct 2015 18:24:58 +0530 Subject: RFR(XS): 8139047: add test for JSAdapter __getIds__ In-Reply-To: References: Message-ID: <56151622.2010802@oracle.com> +1 On 10/7/2015 6:24 PM, Michael Haupt wrote: > Dear all, > > please review this very small change (it adds a single test). > RFE: https://bugs.openjdk.java.net/browse/JDK-8139047 > Webrev: http://cr.openjdk.java.net/~mhaupt/8139047/webrev.00 > > Thanks, > > Michael > From hannes.wallnoefer at oracle.com Wed Oct 7 12:56:14 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 7 Oct 2015 14:56:14 +0200 Subject: RFR(XS): 8139047: add test for JSAdapter __getIds__ In-Reply-To: References: Message-ID: <5615166E.3080707@oracle.com> +1 Am 2015-10-07 um 14:54 schrieb Michael Haupt: > Dear all, > > please review this very small change (it adds a single test). > RFE: https://bugs.openjdk.java.net/browse/JDK-8139047 > Webrev: http://cr.openjdk.java.net/~mhaupt/8139047/webrev.00 > > Thanks, > > Michael > From sundararajan.athijegannathan at oracle.com Thu Oct 8 06:24:36 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 8 Oct 2015 11:54:36 +0530 Subject: RFR 8139106: ant build/test fails with jigsaw/jake/nashorn Message-ID: <56160C24.2030206@oracle.com> Hi, Please review http://cr.openjdk.java.net/~sundar/8139106/ for https://bugs.openjdk.java.net/browse/JDK-8139106 Changes: * JSONCompatibleTest was in jdk.nashorn.api.scripting test - a package used in named module jdk.scripting.nashorn. Moved this to a different package - like other tests this class is in jdk.nashorn.api.scripting.test package. * module exports needed for nasgen and tests [nasgen and test classes are in unnamed modules] should use "ALL-UNNAMED" rather than blank. * build.xml: 1) compiling only jdk.scripting.nashorn module (leaving 'shell' module of nashorn) 2) removed unnecessary -XaddExports 3) Using -Xpatch... javac option rather than -J-Xpatch... in "compile-test" With these changes, I can do "ant clean test" and "ant clean test262parallel" with jake/nashorn. Couple of test262 issues fail - but that may be due to missing "whitespace handling fix" that went to jdk9-dev/nashorn recently. And there are few (internal) javadoc warnings for nashorn code. Thanks, -Sundar From michael.haupt at oracle.com Thu Oct 8 07:02:29 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 8 Oct 2015 09:02:29 +0200 Subject: RFR 8139106: ant build/test fails with jigsaw/jake/nashorn In-Reply-To: <56160C24.2030206@oracle.com> References: <56160C24.2030206@oracle.com> Message-ID: <21D3D806-6B7D-4F20-81CE-148662A02381@oracle.com> Hi Sundar, lower-case thumbs up. Best, Michael > Am 08.10.2015 um 08:24 schrieb Sundararajan Athijegannathan : > > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8139106/ for https://bugs.openjdk.java.net/browse/JDK-8139106 > > Changes: > > * JSONCompatibleTest was in jdk.nashorn.api.scripting test - a package used in named module jdk.scripting.nashorn. > Moved this to a different package - like other tests this class is in jdk.nashorn.api.scripting.test package. > > * module exports needed for nasgen and tests [nasgen and test classes are in unnamed modules] should use "ALL-UNNAMED" rather than blank. > > * build.xml: > 1) compiling only jdk.scripting.nashorn module (leaving 'shell' module of nashorn) > 2) removed unnecessary -XaddExports > 3) Using -Xpatch... javac option rather than -J-Xpatch... in "compile-test" > > With these changes, I can do "ant clean test" and "ant clean test262parallel" with jake/nashorn. Couple of test262 issues fail - but that may be due to missing "whitespace handling fix" that went to jdk9-dev/nashorn recently. And there are few (internal) javadoc warnings for nashorn code. > > 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 marcus at lagergren.net Thu Oct 8 07:19:26 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Thu, 8 Oct 2015 09:19:26 +0200 Subject: RFR 8139106: ant build/test fails with jigsaw/jake/nashorn In-Reply-To: <56160C24.2030206@oracle.com> References: <56160C24.2030206@oracle.com> Message-ID: <1E5877C6-99AD-43FA-AB56-D4250ABAE2B3@lagergren.net> Looks good and builds for me on 9. Are the 262 issues tracked separately? +1 /M > On 08 Oct 2015, at 08:24, Sundararajan Athijegannathan wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8139106/ for https://bugs.openjdk.java.net/browse/JDK-8139106 > > Changes: > > * JSONCompatibleTest was in jdk.nashorn.api.scripting test - a package used in named module jdk.scripting.nashorn. > Moved this to a different package - like other tests this class is in jdk.nashorn.api.scripting.test package. > > * module exports needed for nasgen and tests [nasgen and test classes are in unnamed modules] should use "ALL-UNNAMED" rather than blank. > > * build.xml: > 1) compiling only jdk.scripting.nashorn module (leaving 'shell' module of nashorn) > 2) removed unnecessary -XaddExports > 3) Using -Xpatch... javac option rather than -J-Xpatch... in "compile-test" > > With these changes, I can do "ant clean test" and "ant clean test262parallel" with jake/nashorn. Couple of test262 issues fail - but that may be due to missing "whitespace handling fix" that went to jdk9-dev/nashorn recently. And there are few (internal) javadoc warnings for nashorn code. > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Thu Oct 8 08:40:06 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 8 Oct 2015 14:10:06 +0530 Subject: RFR 8139106: ant build/test fails with jigsaw/jake/nashorn In-Reply-To: <1E5877C6-99AD-43FA-AB56-D4250ABAE2B3@lagergren.net> References: <56160C24.2030206@oracle.com> <1E5877C6-99AD-43FA-AB56-D4250ABAE2B3@lagergren.net> Message-ID: <56162BE6.9040406@oracle.com> Module/jigsaw related fixes go into http://hg.openjdk.java.net/jigsaw/jake/nashorn Thanks for the review. -Sundar On 10/8/2015 12:49 PM, Marcus Lagergren wrote: > Looks good and builds for me on 9. Are the 262 issues tracked separately? > > +1 > > /M > >> On 08 Oct 2015, at 08:24, Sundararajan Athijegannathan wrote: >> >> Hi, >> >> Please review http://cr.openjdk.java.net/~sundar/8139106/ for https://bugs.openjdk.java.net/browse/JDK-8139106 >> >> Changes: >> >> * JSONCompatibleTest was in jdk.nashorn.api.scripting test - a package used in named module jdk.scripting.nashorn. >> Moved this to a different package - like other tests this class is in jdk.nashorn.api.scripting.test package. >> >> * module exports needed for nasgen and tests [nasgen and test classes are in unnamed modules] should use "ALL-UNNAMED" rather than blank. >> >> * build.xml: >> 1) compiling only jdk.scripting.nashorn module (leaving 'shell' module of nashorn) >> 2) removed unnecessary -XaddExports >> 3) Using -Xpatch... javac option rather than -J-Xpatch... in "compile-test" >> >> With these changes, I can do "ant clean test" and "ant clean test262parallel" with jake/nashorn. Couple of test262 issues fail - but that may be due to missing "whitespace handling fix" that went to jdk9-dev/nashorn recently. And there are few (internal) javadoc warnings for nashorn code. >> >> Thanks, >> -Sundar From attila.szegedi at oracle.com Fri Oct 9 11:40:21 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 9 Oct 2015 13:40:21 +0200 Subject: Review request for JDK-8139269: Do not expose prune method handles from ChainedCallSite Message-ID: <86926A03-2DF6-4E57-85FE-D849D6B45F72@oracle.com> Please review JDK-8139269 "Do not expose prune method handles from ChainedCallSite" at for Thanks, Attila. From attila.szegedi at oracle.com Fri Oct 9 11:50:50 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 9 Oct 2015 13:50:50 +0200 Subject: Review request for JDK-8139270: Drastically reduce memory footprint of ChainedCallSite Message-ID: <9357E32F-8C41-4BEC-BF3F-31305105CBD0@oracle.com> Please review JDK-8139270 "Drastically reduce memory footprint of ChainedCallSite" at for Thanks, Attila. From attila.szegedi at oracle.com Fri Oct 9 12:00:56 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 9 Oct 2015 14:00:56 +0200 Subject: Review request for JDK-8139273: Small improvements to DynamicLinker and DynamicLinkerFactory Message-ID: <24056050-3096-4535-B112-33A1D646A955@oracle.com> Please review JDK-8139273 "Small improvements to DynamicLinker and DynamicLinkerFactory" at for Thanks, Attila. From attila.szegedi at oracle.com Fri Oct 9 12:07:41 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 9 Oct 2015 14:07:41 +0200 Subject: Review request for JDK-8139274: Use JDK 8 default method for LinkerServices.asTypeLosslessReturn Message-ID: Please review JDK-8139274 "Use JDK 8 default method for LinkerServices.asTypeLosslessReturn" at for Thanks, Attila. From hannes.wallnoefer at oracle.com Fri Oct 9 13:01:31 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 9 Oct 2015 15:01:31 +0200 Subject: RFR: JDK-8131929: Add option for debuggable scopes Message-ID: <5617BAAB.8010602@oracle.com> Please review JDK-8131929: Add option for debuggable scopes http://cr.openjdk.java.net/~hannesw/8131929/ This contains a fair bit of cleanup (like putting most of Options.properties into lexicographical order). The actual change is pretty simple and consists of adding the --debug-scopes option and setting a flag in Parser. Thanks, Hannes From hannes.wallnoefer at oracle.com Fri Oct 9 13:06:54 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 9 Oct 2015 15:06:54 +0200 Subject: Review request for JDK-8139270: Drastically reduce memory footprint of ChainedCallSite In-Reply-To: <9357E32F-8C41-4BEC-BF3F-31305105CBD0@oracle.com> References: <9357E32F-8C41-4BEC-BF3F-31305105CBD0@oracle.com> Message-ID: <5617BBEE.8010302@oracle.com> +1 Am 2015-10-09 um 13:50 schrieb Attila Szegedi: > Please review JDK-8139270 "Drastically reduce memory footprint of ChainedCallSite" at for > > Thanks, > Attila. From attila.szegedi at oracle.com Fri Oct 9 13:14:20 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 9 Oct 2015 15:14:20 +0200 Subject: Review request for JDK-8139282: Remove @author and @id tags from Dynalink JavaDoc; some minor edits Message-ID: Please review JDK-8139282 "Remove @author and @id tags from Dynalink JavaDoc; some minor edits" at for This is a very trivial and boring change, it?s mostly what it says: removing the @author and @id tags; I also made some minor rewording edits (that will likely be further changed by later more major JavaDoc edits anyway). Thanks, Attila. From attila.szegedi at oracle.com Fri Oct 9 13:36:14 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 9 Oct 2015 15:36:14 +0200 Subject: RFR: JDK-8131929: Add option for debuggable scopes In-Reply-To: <5617BAAB.8010602@oracle.com> References: <5617BAAB.8010602@oracle.com> Message-ID: <0EDFDCC9-9734-46C8-91D4-DF5F76E97D7A@oracle.com> +1; very elegant solution! Just marking in the parser every function as ?containing eval?, since debugging can be considered from the point of view of the debugged program as ?anything can be eval()'d anytime, anywhere?). Attila. > On Oct 9, 2015, at 3:01 PM, Hannes Wallnoefer wrote: > > Please review JDK-8131929: Add option for debuggable scopes > > http://cr.openjdk.java.net/~hannesw/8131929/ > > This contains a fair bit of cleanup (like putting most of Options.properties into lexicographical order). The actual change is pretty simple and consists of adding the --debug-scopes option and setting a flag in Parser. > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Fri Oct 9 13:54:43 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 9 Oct 2015 15:54:43 +0200 Subject: Review request for JDK-8139269: Do not expose prune method handles from ChainedCallSite In-Reply-To: <86926A03-2DF6-4E57-85FE-D849D6B45F72@oracle.com> References: <86926A03-2DF6-4E57-85FE-D849D6B45F72@oracle.com> Message-ID: <5617C723.8040604@oracle.com> +1 Am 2015-10-09 um 13:40 schrieb Attila Szegedi: > Please review JDK-8139269 "Do not expose prune method handles from ChainedCallSite" at for > > Thanks, > Attila. From marcus at lagergren.net Fri Oct 9 14:19:41 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Fri, 9 Oct 2015 16:19:41 +0200 Subject: Review request for JDK-8139269: Do not expose prune method handles from ChainedCallSite In-Reply-To: <86926A03-2DF6-4E57-85FE-D849D6B45F72@oracle.com> References: <86926A03-2DF6-4E57-85FE-D849D6B45F72@oracle.com> Message-ID: <49C1F61B-6F9D-4C82-A31B-19AE359AC35C@lagergren.net> +1 > On 09 Oct 2015, at 13:40, Attila Szegedi wrote: > > Please review JDK-8139269 "Do not expose prune method handles from ChainedCallSite" at for > > Thanks, > Attila. From marcus at lagergren.net Fri Oct 9 14:19:56 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Fri, 9 Oct 2015 16:19:56 +0200 Subject: Review request for JDK-8139274: Use JDK 8 default method for LinkerServices.asTypeLosslessReturn In-Reply-To: References: Message-ID: +1 On 09 Oct 2015, at 14:07, Attila Szegedi wrote: > > Please review JDK-8139274 "Use JDK 8 default method for LinkerServices.asTypeLosslessReturn" at for > > Thanks, > Attila. From marcus at lagergren.net Fri Oct 9 14:20:04 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Fri, 9 Oct 2015 16:20:04 +0200 Subject: Review request for JDK-8139273: Small improvements to DynamicLinker and DynamicLinkerFactory In-Reply-To: <24056050-3096-4535-B112-33A1D646A955@oracle.com> References: <24056050-3096-4535-B112-33A1D646A955@oracle.com> Message-ID: <0FABDDCA-02DD-4E45-9805-E097473F7325@lagergren.net> +1 > On 09 Oct 2015, at 14:00, Attila Szegedi wrote: > > Please review JDK-8139273 "Small improvements to DynamicLinker and DynamicLinkerFactory" at for > > Thanks, > Attila. From marcus at lagergren.net Fri Oct 9 14:20:11 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Fri, 9 Oct 2015 16:20:11 +0200 Subject: Review request for JDK-8139270: Drastically reduce memory footprint of ChainedCallSite In-Reply-To: <9357E32F-8C41-4BEC-BF3F-31305105CBD0@oracle.com> References: <9357E32F-8C41-4BEC-BF3F-31305105CBD0@oracle.com> Message-ID: +1 > On 09 Oct 2015, at 13:50, Attila Szegedi wrote: > > Please review JDK-8139270 "Drastically reduce memory footprint of ChainedCallSite" at for > > Thanks, > Attila. From attila.szegedi at oracle.com Fri Oct 9 16:47:33 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 9 Oct 2015 18:47:33 +0200 Subject: Review request for JDK-8139270: Drastically reduce memory footprint of ChainedCallSite In-Reply-To: References: <9357E32F-8C41-4BEC-BF3F-31305105CBD0@oracle.com> Message-ID: Thanks, folks. However, Sundar asked if I could maybe remove the dependency on Unsafe. This got me further thinking about this and I realized that thread safety is actually not a requirement here, as race conditions are nonfatal (they can lead to some repeated linking), and the strategies we could adopt for resolving them would have their own problems (e.g. same method linked twice in the chain if linked councurrently on two threads). I explained my reasoning in more detail in > I uploaded a new webrev to: >, please review this one as well. It removes the ?volatile? keyword from ?invocations? and no longer uses any CAS, just overwrites the field value. test262parallel runs just fine; it is one of those tests that do concurrent relinking in the test harness code. Thanks, Attila. > On Oct 9, 2015, at 4:20 PM, Marcus Lagergren wrote: > > +1 > >> On 09 Oct 2015, at 13:50, Attila Szegedi wrote: >> >> Please review JDK-8139270 "Drastically reduce memory footprint of ChainedCallSite" at for >> >> Thanks, >> Attila. > From attila.szegedi at oracle.com Fri Oct 9 17:09:04 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 9 Oct 2015 19:09:04 +0200 Subject: Review request for JDK-8139304: Remove some obsolete Dynalink classes Message-ID: <745349D0-C7E9-415E-965A-B2F0146A6748@oracle.com> Please review JDK-8139304 "Remove some obsolete Dynalink classes" at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 12 03:34:48 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 12 Oct 2015 09:04:48 +0530 Subject: Review request for JDK-8139269: Do not expose prune method handles from ChainedCallSite In-Reply-To: <86926A03-2DF6-4E57-85FE-D849D6B45F72@oracle.com> References: <86926A03-2DF6-4E57-85FE-D849D6B45F72@oracle.com> Message-ID: <561B2A58.6070007@oracle.com> +1 On 10/9/2015 5:10 PM, Attila Szegedi wrote: > Please review JDK-8139269 "Do not expose prune method handles from ChainedCallSite" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 12 03:36:28 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 12 Oct 2015 09:06:28 +0530 Subject: Review request for JDK-8139273: Small improvements to DynamicLinker and DynamicLinkerFactory In-Reply-To: <24056050-3096-4535-B112-33A1D646A955@oracle.com> References: <24056050-3096-4535-B112-33A1D646A955@oracle.com> Message-ID: <561B2ABC.6040906@oracle.com> +1 On 10/9/2015 5:30 PM, Attila Szegedi wrote: > Please review JDK-8139273 "Small improvements to DynamicLinker and DynamicLinkerFactory" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 12 03:37:02 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 12 Oct 2015 09:07:02 +0530 Subject: Review request for JDK-8139274: Use JDK 8 default method for LinkerServices.asTypeLosslessReturn In-Reply-To: References: Message-ID: <561B2ADE.8060105@oracle.com> +1 On 10/9/2015 5:37 PM, Attila Szegedi wrote: > Please review JDK-8139274 "Use JDK 8 default method for LinkerServices.asTypeLosslessReturn" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 12 03:40:59 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 12 Oct 2015 09:10:59 +0530 Subject: Review request for JDK-8139304: Remove some obsolete Dynalink classes In-Reply-To: <745349D0-C7E9-415E-965A-B2F0146A6748@oracle.com> References: <745349D0-C7E9-415E-965A-B2F0146A6748@oracle.com> Message-ID: <561B2BCB.2050806@oracle.com> Wherever SecurityException is thrown, javadoc could have @throws and one line explanation. Even though it is a RuntimeException, JDK javadoc elsewhere documents SecurityException explicitly. Other than that +1 PS. This webrev shows differences due to other patches/fixes as well ... -Sundar On 10/9/2015 10:39 PM, Attila Szegedi wrote: > Please review JDK-8139304 "Remove some obsolete Dynalink classes" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 12 03:42:10 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 12 Oct 2015 09:12:10 +0530 Subject: Review request for JDK-8139304: Remove some obsolete Dynalink classes In-Reply-To: <561B2BCB.2050806@oracle.com> References: <745349D0-C7E9-415E-965A-B2F0146A6748@oracle.com> <561B2BCB.2050806@oracle.com> Message-ID: <561B2C12.7080405@oracle.com> Oops. reply to wrong webrev.. Please ignore -Sundar On 10/12/2015 9:10 AM, Sundararajan Athijegannathan wrote: > Wherever SecurityException is thrown, javadoc could have @throws and > one line explanation. Even though it is a RuntimeException, JDK > javadoc elsewhere documents SecurityException explicitly. > > Other than that +1 > > PS. This webrev shows differences due to other patches/fixes as well ... > > -Sundar > > On 10/9/2015 10:39 PM, Attila Szegedi wrote: >> Please review JDK-8139304 "Remove some obsolete Dynalink classes" at >> for >> >> >> Thanks, >> Attila. > From sundararajan.athijegannathan at oracle.com Mon Oct 12 03:42:24 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 12 Oct 2015 09:12:24 +0530 Subject: Review request for JDK-8139282: Remove @author and @id tags from Dynalink JavaDoc; some minor edits In-Reply-To: References: Message-ID: <561B2C20.4080704@oracle.com> Wherever SecurityException is thrown, javadoc could have @throws and one line explanation. Even though it is a RuntimeException, JDK javadoc elsewhere documents SecurityException explicitly. Other than that +1 PS. This webrev shows differences due to other patches/fixes as well ... -Sundar On 10/9/2015 6:44 PM, Attila Szegedi wrote: > Please review JDK-8139282 "Remove @author and @id tags from Dynalink JavaDoc; some minor edits" at for > > This is a very trivial and boring change, it?s mostly what it says: removing the @author and @id tags; I also made some minor rewording edits (that will likely be further changed by later more major JavaDoc edits anyway). > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 12 03:44:27 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 12 Oct 2015 09:14:27 +0530 Subject: Review request for JDK-8139304: Remove some obsolete Dynalink classes In-Reply-To: <745349D0-C7E9-415E-965A-B2F0146A6748@oracle.com> References: <745349D0-C7E9-415E-965A-B2F0146A6748@oracle.com> Message-ID: <561B2C9B.7060901@oracle.com> +1 New file http://cr.openjdk.java.net/~attila/8139304/webrev.jdk9-01/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleCallSiteDescriptor.java.html has @author - which you've removed in other files. Hope you're aware... -Sundar On 10/9/2015 10:39 PM, Attila Szegedi wrote: > Please review JDK-8139304 "Remove some obsolete Dynalink classes" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 12 03:50:42 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 12 Oct 2015 09:20:42 +0530 Subject: Review request for JDK-8139270: Drastically reduce memory footprint of ChainedCallSite In-Reply-To: References: <9357E32F-8C41-4BEC-BF3F-31305105CBD0@oracle.com> Message-ID: <561B2E12.4060905@oracle.com> +1 -Sundar On 10/9/2015 10:17 PM, Attila Szegedi wrote: > Thanks, folks. > > However, Sundar asked if I could maybe remove the dependency on Unsafe. This got me further thinking about this and I realized that thread safety is actually not a requirement here, as race conditions are nonfatal (they can lead to some repeated linking), and the strategies we could adopt for resolving them would have their own problems (e.g. same method linked twice in the chain if linked councurrently on two threads). I explained my reasoning in more detail in > > > I uploaded a new webrev to: >, please review this one as well. > > It removes the ?volatile? keyword from ?invocations? and no longer uses any CAS, just overwrites the field value. test262parallel runs just fine; it is one of those tests that do concurrent relinking in the test harness code. > > Thanks, > Attila. > > > >> On Oct 9, 2015, at 4:20 PM, Marcus Lagergren wrote: >> >> +1 >> >>> On 09 Oct 2015, at 13:50, Attila Szegedi wrote: >>> >>> Please review JDK-8139270 "Drastically reduce memory footprint of ChainedCallSite" at for >>> >>> Thanks, >>> Attila. From attila.szegedi at oracle.com Mon Oct 12 08:36:13 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 12 Oct 2015 10:36:13 +0200 Subject: Review request for JDK-8139282: Remove @author and @id tags from Dynalink JavaDoc; some minor edits In-Reply-To: <561B2C20.4080704@oracle.com> References: <561B2C20.4080704@oracle.com> Message-ID: <591590C4-9157-4B17-8FE5-F05E3D03C575@oracle.com> Thanks. I will go through the documentation and add SecurityException where necessary in a later separate JavaDoc patch. You are right about webrev showing other changes too. I fixed that, updating it in-place. Thanks, Attila. > On Oct 12, 2015, at 5:42 AM, Sundararajan Athijegannathan wrote: > > Wherever SecurityException is thrown, javadoc could have @throws and one line explanation. Even though it is a RuntimeException, JDK javadoc elsewhere documents SecurityException explicitly. > > Other than that +1 > > PS. This webrev shows differences due to other patches/fixes as well ... > > -Sundar > > > On 10/9/2015 6:44 PM, Attila Szegedi wrote: >> Please review JDK-8139282 "Remove @author and @id tags from Dynalink JavaDoc; some minor edits" at for >> >> This is a very trivial and boring change, it?s mostly what it says: removing the @author and @id tags; I also made some minor rewording edits (that will likely be further changed by later more major JavaDoc edits anyway). >> >> Thanks, >> Attila. > From michael.haupt at oracle.com Mon Oct 12 11:13:39 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 12 Oct 2015 13:13:39 +0200 Subject: RFR(XS): 8139266: add JSAdapter example with fallthrough Message-ID: <8F240638-2500-46C4-8AA1-979B152A09AA@oracle.com> Dear all, please review this change - it adds a sample for JSAdapter usage. RFE: https://bugs.openjdk.java.net/browse/JDK-8139266 Webrev: http://cr.openjdk.java.net/~mhaupt/8139266/webrev.00 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 hannes.wallnoefer at oracle.com Mon Oct 12 11:18:55 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 12 Oct 2015 13:18:55 +0200 Subject: Review request for JDK-8139270: Drastically reduce memory footprint of ChainedCallSite In-Reply-To: References: <9357E32F-8C41-4BEC-BF3F-31305105CBD0@oracle.com> Message-ID: <561B971F.8000302@oracle.com> +1 Am 2015-10-09 um 18:47 schrieb Attila Szegedi: > Thanks, folks. > > However, Sundar asked if I could maybe remove the dependency on Unsafe. This got me further thinking about this and I realized that thread safety is actually not a requirement here, as race conditions are nonfatal (they can lead to some repeated linking), and the strategies we could adopt for resolving them would have their own problems (e.g. same method linked twice in the chain if linked councurrently on two threads). I explained my reasoning in more detail in > > > I uploaded a new webrev to: >, please review this one as well. > > It removes the ?volatile? keyword from ?invocations? and no longer uses any CAS, just overwrites the field value. test262parallel runs just fine; it is one of those tests that do concurrent relinking in the test harness code. > > Thanks, > Attila. > > > >> On Oct 9, 2015, at 4:20 PM, Marcus Lagergren wrote: >> >> +1 >> >>> On 09 Oct 2015, at 13:50, Attila Szegedi wrote: >>> >>> Please review JDK-8139270 "Drastically reduce memory footprint of ChainedCallSite" at for >>> >>> Thanks, >>> Attila. From hannes.wallnoefer at oracle.com Mon Oct 12 11:29:15 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 12 Oct 2015 13:29:15 +0200 Subject: RFR(XS): 8139266: add JSAdapter example with fallthrough In-Reply-To: <8F240638-2500-46C4-8AA1-979B152A09AA@oracle.com> References: <8F240638-2500-46C4-8AA1-979B152A09AA@oracle.com> Message-ID: <561B998B.9040704@oracle.com> +1 Am 2015-10-12 um 13:13 schrieb Michael Haupt: > Dear all, > > please review this change - it adds a sample for JSAdapter usage. > RFE: https://bugs.openjdk.java.net/browse/JDK-8139266 > Webrev: http://cr.openjdk.java.net/~mhaupt/8139266/webrev.00 > > Thanks, > > Michael > From michael.haupt at oracle.com Mon Oct 12 11:53:33 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 12 Oct 2015 13:53:33 +0200 Subject: Review request for JDK-8139282: Remove @author and @id tags from Dynalink JavaDoc; some minor edits In-Reply-To: <591590C4-9157-4B17-8FE5-F05E3D03C575@oracle.com> References: <561B2C20.4080704@oracle.com> <591590C4-9157-4B17-8FE5-F05E3D03C575@oracle.com> Message-ID: <051AF39D-E8DF-457F-ADE5-41FAC3B5FC29@oracle.com> Hi Attila, lower-case thumbs up. Best, Michael > Am 12.10.2015 um 10:36 schrieb Attila Szegedi : > > Thanks. I will go through the documentation and add SecurityException where necessary in a later separate JavaDoc patch. You are right about webrev showing other changes too. I fixed that, updating it in-place. > > Thanks, > Attila. > >> On Oct 12, 2015, at 5:42 AM, Sundararajan Athijegannathan wrote: >> >> Wherever SecurityException is thrown, javadoc could have @throws and one line explanation. Even though it is a RuntimeException, JDK javadoc elsewhere documents SecurityException explicitly. >> >> Other than that +1 >> >> PS. This webrev shows differences due to other patches/fixes as well ... >> >> -Sundar >> >> >> On 10/9/2015 6:44 PM, Attila Szegedi wrote: >>> Please review JDK-8139282 "Remove @author and @id tags from Dynalink JavaDoc; some minor edits" at for >>> >>> This is a very trivial and boring change, it?s mostly what it says: removing the @author and @id tags; I also made some minor rewording edits (that will likely be further changed by later more major JavaDoc edits anyway). >>> >>> Thanks, >>> Attila. >> > -- 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 attila.szegedi at oracle.com Mon Oct 12 12:56:37 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 12 Oct 2015 14:56:37 +0200 Subject: Review request for JDK-8139304: Remove some obsolete Dynalink classes In-Reply-To: <561B2C9B.7060901@oracle.com> References: <745349D0-C7E9-415E-965A-B2F0146A6748@oracle.com> <561B2C9B.7060901@oracle.com> Message-ID: I honestly can?t find an ?@author? tag anywhere in the source. > On Oct 12, 2015, at 5:44 AM, Sundararajan Athijegannathan wrote: > > +1 > > New file http://cr.openjdk.java.net/~attila/8139304/webrev.jdk9-01/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleCallSiteDescriptor.java.html has @author - which you've removed in other files. Hope you're aware... > > -Sundar > > On 10/9/2015 10:39 PM, Attila Szegedi wrote: >> Please review JDK-8139304 "Remove some obsolete Dynalink classes" at for >> >> Thanks, >> Attila. > From marcus at lagergren.net Mon Oct 12 13:28:49 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 12 Oct 2015 15:28:49 +0200 Subject: RFR: JDK-8131929: Add option for debuggable scopes In-Reply-To: <5617BAAB.8010602@oracle.com> References: <5617BAAB.8010602@oracle.com> Message-ID: +1 > On 09 Oct 2015, at 15:01, Hannes Wallnoefer wrote: > > Please review JDK-8131929: Add option for debuggable scopes > > http://cr.openjdk.java.net/~hannesw/8131929/ > > This contains a fair bit of cleanup (like putting most of Options.properties into lexicographical order). The actual change is pretty simple and consists of adding the --debug-scopes option and setting a flag in Parser. > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Mon Oct 12 22:05:02 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 13 Oct 2015 03:35:02 +0530 Subject: RFR(XS): 8139266: add JSAdapter example with fallthrough In-Reply-To: <8F240638-2500-46C4-8AA1-979B152A09AA@oracle.com> References: <8F240638-2500-46C4-8AA1-979B152A09AA@oracle.com> Message-ID: <561C2E8E.1040405@oracle.com> +1 On 10/12/2015 4:43 PM, Michael Haupt wrote: > Dear all, > > please review this change - it adds a sample for JSAdapter usage. > RFE: https://bugs.openjdk.java.net/browse/JDK-8139266 > Webrev: http://cr.openjdk.java.net/~mhaupt/8139266/webrev.00 > > Thanks, > > Michael > From attila.szegedi at oracle.com Wed Oct 14 13:30:52 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 14 Oct 2015 15:30:52 +0200 Subject: Review request for JDK-8139435: Make sure CallSiteDescriptor.getLookup is subject to a security check Message-ID: <9666A523-BE02-4F01-A4C5-40745D9ADD4E@oracle.com> Please review JDK-8139435 "Make sure CallSiteDescriptor.getLookup is subject to a security check" at for Notes: - webrev also shows a previous issue in the history of some of the files, but the changes for that issue are not in the diffs. - the mechanism for security checks in this changeset is sound, but it is even further improved by making CallSiteDescriptor into a proper class and internalizing the checks later on (I will be sending that changeset for review separately later). Thanks, Attila. From attila.szegedi at oracle.com Wed Oct 14 13:35:52 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 14 Oct 2015 15:35:52 +0200 Subject: Review request for JDK-8139588: Remove concept of runtime context arguments, call site tokens, and link counts Message-ID: <771E0063-D175-4BB6-9058-2723525CDB62@oracle.com> Please review JDK-8139588 "Remove concept of runtime context arguments, call site tokens, and link counts" at for Note: webrev also shows some previous issues in the history of some of the files, but the changes for those issue are not in the diffs. Thanks, Attila. From attila.szegedi at oracle.com Wed Oct 14 13:48:18 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 14 Oct 2015 15:48:18 +0200 Subject: Review request for JDK-8139590: Improve Dynalink JavaDoc Message-ID: <8D3E39DC-7859-4049-864A-925E470CA1A1@oracle.com> Please review JDK-8139590 "Improve Dynalink JavaDoc" at for Notes: - webrev also shows some previous issues in the history of some of the files, but the changes for those issue are not in the diffs. - In addition to JavaDoc, there are some minor additional fixes: - GuardedInvocation.assertType was removed; it has shown up in JavaDoc, but it was not used except for one place in TypeConverterFactory, and even there it wasn?t needed - GuardedInvocation had an accidental dependency on jdk.nashorn.internal.* class; that was eliminated. - AbstractCallSiteDescriptor.lookupsEqual and lookupHashCode now handle nulls - CompositeGuardingDynamicLinker and TypeBasedCompositeGuardingDynamicLinker detect if any of its composites are null and throw a NPE Thanks, Attila. From sundararajan.athijegannathan at oracle.com Thu Oct 15 16:21:50 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 15 Oct 2015 21:51:50 +0530 Subject: Review request for JDK-8139435: Make sure CallSiteDescriptor.getLookup is subject to a security check In-Reply-To: <9666A523-BE02-4F01-A4C5-40745D9ADD4E@oracle.com> References: <9666A523-BE02-4F01-A4C5-40745D9ADD4E@oracle.com> Message-ID: <561FD29E.7080304@oracle.com> +1 On 10/14/2015 7:00 PM, Attila Szegedi wrote: > Please review JDK-8139435 "Make sure CallSiteDescriptor.getLookup is subject to a security check" at for > > Notes: > - webrev also shows a previous issue in the history of some of the files, but the changes for that issue are not in the diffs. > - the mechanism for security checks in this changeset is sound, but it is even further improved by making CallSiteDescriptor into a proper class and internalizing the checks later on (I will be sending that changeset for review separately later). > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Thu Oct 15 16:47:14 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 15 Oct 2015 22:17:14 +0530 Subject: Review request for JDK-8139588: Remove concept of runtime context arguments, call site tokens, and link counts In-Reply-To: <771E0063-D175-4BB6-9058-2723525CDB62@oracle.com> References: <771E0063-D175-4BB6-9058-2723525CDB62@oracle.com> Message-ID: <561FD892.1090702@oracle.com> +1 Nice cleanup! Like the removal of those unused stuff... -Sundar On 10/14/2015 7:05 PM, Attila Szegedi wrote: > Please review JDK-8139588 "Remove concept of runtime context arguments, call site tokens, and link counts" at for > > Note: webrev also shows some previous issues in the history of some of the files, but the changes for those issue are not in the diffs. > > Thanks, > Attila. From tal.liron at threecrickets.com Thu Oct 15 16:51:27 2015 From: tal.liron at threecrickets.com (Tal Liron) Date: Thu, 15 Oct 2015 11:51:27 -0500 Subject: Developer API docs In-Reply-To: <559B3526.2010802@threecrickets.com> References: <559844B1.60409@threecrickets.com> <559A0214.8040502@oracle.com> <559A19A3.4090008@threecrickets.com> <9AC00CD0-2210-4934-88A7-6120BDAF5841@oracle.com> <559B3526.2010802@threecrickets.com> Message-ID: <561FD98F.1060803@threecrickets.com> Hey guys, nobody ever responded to my message... Do you really think that my usage of these internal Nashorn APIs is so unwarranted? I tried to prove that some useful libraries need to use Nashorn APIs that some of you insist should not be made public. On 07/06/2015 09:10 PM, Tal Liron wrote: > Hi Atilla (and Sundar and everyone else, really), > > You asked which Nashorn APIs I'm using that are not documented. I will > reply in full detail. > > For the BSON/JSON codecs, the most important thing is to access the > NativeBoolean, NativeNumber, NativeArray, ConsString, Undefined, etc., > classes. This allows the codecs to check for these classes incoming, > and also to easily create instances of them using their constructor() > static method. > > ScriptObject has no constructor(), so I use Global.newEmptyInstance(). > (By the way: NativeDate and NativeArray name the method construct() > instead of constructor(). I assume this is a consistency mistake.) > > But I also need to access their data. This means get()/set() for > NativeScriptObject and NativeArray, getOwnKeys(), getArray() (which > means I need access to the ArrayData class), and also getTime() for > NativeData. NativeRegExp is a bit harder, but I use get("source"), > get("multiline"), etc. > > (In Rhino, some of these classes are actually private! This required > an awkward workaround: I do a string equality check on the classname. > That's neither efficient nor portable, though more "dynamic", I guess. > Also, for these classes I can use Context.newObject() to create > instances by JS name, for example "RegExp". Then I can do > ScriptableObject.callMethod() to access their internals. So, there are > workarounds to not being to able to access them.) > > ScriptObjectMirror is awkward. Though it's stable and documented, the > issue with unwrap() is that it needs a global. Documented, but of > course unclear what to do! For me, this actually means calling > Context.getGlobal(), which is not publicly documented. (Another issue > is that, of course, unwrap won't work for other globals. This has > created difficulties in some threaded environments in which multiple > globals are used intentionally. More on that below.) > > So much for BSON/JSON. The Scripturian implementation of Nashorn is > much more complex. As you may know, Scripturian is a rethinking of and > alternative to JSR-223, so it has to do much of the same work. > > Scripturian works by purposely creating different global instances for > each "execution context" (which *can* be a thread, but doesn't have to > be: it's an abstraction over, well, execution contexts). I use > Context.createGlobal(), and set it via Context.setGlobal(). > > We then need to compile scripts in the Context, so I use > Source.sourceFor() and Context.compileScript(), which returns a > ScriptFunction, so I also need access to that. Compilations errors are > via Context.getErrorManager(), so I need access to ErrorManager. To > run the scripts, I use ScriptRuntime.apply(). A small fix I need to > add is that Nashorn's NativeArray does not support java.util.List, so > if an array is returned from apply(), I call NativeJava.to() to get > list access. Thats's just a bit friendlier for users of Scripturian, > who are otherwise agnostic about implementation specifics. > > There's an important issue here: remember, there might be many > different globals, but of course I want them all to use the same code > cache, which is stored in the Context. So, I use one singleton Context > and switch globals via Context.setGlobal(). To create a Context, I > also need access to Options. A limitation in Nashorn is that I can't > change stdout and stderr after I create the Context (Scripturian > allows different onces per ExecutionContext), so my workaround is to > use a custom Writer wrapper class that underneath delegates to the > correct "real" Writers (I use the same mechanism for a few other > Scripturian language engines, too). > > I grumbled here before that I have no programmatic access to the code > cache. Behind the scenes, ScriptFunction might retrieve from the cache > instead of being compiled. I can control the cache base location via > the "nashorn.persistent.code.cache" system property, but it's > unfortunate that I can't control the structure and naming the way I > can with other languages supported by Scripturian. In particular, the > problem is that it's a global property for the whole JVM, whereas > compilation and caching location is ideally controlled per > ExecutionContext in Scripturian. This makes Nashorn support in > Scripturian a bit more limited. > > Finally, for errors during execution, I use NashornException > (documented!) to extract specific information into Scripturian's more > generic ExecutionException. > > Small extras: I use Version.version() and > NashornScriptEngineFactory.getLanguageVersion() to get version data. > > I think that's everything! Of course, I also had to "reverse engineer" > much of this (=read a lot of code) and work around many quirks (and > big differences to Rhino's implementation) before streamlining it down > to just these few classes. (I tried to work around the caching > limitations, but gave up due to its complexity. Also, I think some of > the key classes I would need are private.) I did my best not to delve > to much into internals, but I hope I made it clear to you that it > would have been impossible to achieve all the above goals without it. > > -Tal > > On 07/06/2015 04:18 AM, Attila Szegedi wrote: >> What APIs are you using, BTW? Just curious if I can suggest an >> alternative approach, or even consider if something you use should be >> publicly supported. > From sundararajan.athijegannathan at oracle.com Fri Oct 16 02:56:49 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 16 Oct 2015 08:26:49 +0530 Subject: Developer API docs In-Reply-To: <561FD98F.1060803@threecrickets.com> References: <559844B1.60409@threecrickets.com> <559A0214.8040502@oracle.com> <559A19A3.4090008@threecrickets.com> <9AC00CD0-2210-4934-88A7-6120BDAF5841@oracle.com> <559B3526.2010802@threecrickets.com> <561FD98F.1060803@threecrickets.com> Message-ID: <56206771.1040308@oracle.com> Hi Tal Liron, Sorry about missing reply for this email. I somehow remember replying similar nashorn internal usage email. It is difficult maintain all of jdk.nashorn.internal.* between versions. Also, with security manager around, jdk.nashorn.internal.* are not accessible without explicit 'package access' RuntimePermission. In addition, with jdk9, nashorn module exports only jdk.nashorn.api.* packages. i.e., even without any security manager, user code won't be able to access nashorn internal implementation classes. It is possible to use jdk.nashorn.api.scripting.JSObject to get constructors and create objecs. JSObject numberConstructor = (JSObject) engine.eval("Number"); JSObject numberObj = numberConstructor.newObject(); Is it not possible to work with these? Please check out latest 8u-dev code. Mostly explicit wrap/unwrap won't be required from user's code. Thanks, -Sundar On 10/15/2015 10:21 PM, Tal Liron wrote: > Hey guys, nobody ever responded to my message... > > Do you really think that my usage of these internal Nashorn APIs is so > unwarranted? > > I tried to prove that some useful libraries need to use Nashorn APIs > that some of you insist should not be made public. > > On 07/06/2015 09:10 PM, Tal Liron wrote: >> Hi Atilla (and Sundar and everyone else, really), >> >> You asked which Nashorn APIs I'm using that are not documented. I >> will reply in full detail. >> >> For the BSON/JSON codecs, the most important thing is to access the >> NativeBoolean, NativeNumber, NativeArray, ConsString, Undefined, >> etc., classes. This allows the codecs to check for these classes >> incoming, and also to easily create instances of them using their >> constructor() static method. >> >> ScriptObject has no constructor(), so I use >> Global.newEmptyInstance(). (By the way: NativeDate and NativeArray >> name the method construct() instead of constructor(). I assume this >> is a consistency mistake.) >> >> But I also need to access their data. This means get()/set() for >> NativeScriptObject and NativeArray, getOwnKeys(), getArray() (which >> means I need access to the ArrayData class), and also getTime() for >> NativeData. NativeRegExp is a bit harder, but I use get("source"), >> get("multiline"), etc. >> >> (In Rhino, some of these classes are actually private! This required >> an awkward workaround: I do a string equality check on the classname. >> That's neither efficient nor portable, though more "dynamic", I >> guess. Also, for these classes I can use Context.newObject() to >> create instances by JS name, for example "RegExp". Then I can do >> ScriptableObject.callMethod() to access their internals. So, there >> are workarounds to not being to able to access them.) >> >> ScriptObjectMirror is awkward. Though it's stable and documented, the >> issue with unwrap() is that it needs a global. Documented, but of >> course unclear what to do! For me, this actually means calling >> Context.getGlobal(), which is not publicly documented. (Another issue >> is that, of course, unwrap won't work for other globals. This has >> created difficulties in some threaded environments in which multiple >> globals are used intentionally. More on that below.) >> >> So much for BSON/JSON. The Scripturian implementation of Nashorn is >> much more complex. As you may know, Scripturian is a rethinking of >> and alternative to JSR-223, so it has to do much of the same work. >> >> Scripturian works by purposely creating different global instances >> for each "execution context" (which *can* be a thread, but doesn't >> have to be: it's an abstraction over, well, execution contexts). I >> use Context.createGlobal(), and set it via Context.setGlobal(). >> >> We then need to compile scripts in the Context, so I use >> Source.sourceFor() and Context.compileScript(), which returns a >> ScriptFunction, so I also need access to that. Compilations errors >> are via Context.getErrorManager(), so I need access to ErrorManager. >> To run the scripts, I use ScriptRuntime.apply(). A small fix I need >> to add is that Nashorn's NativeArray does not support java.util.List, >> so if an array is returned from apply(), I call NativeJava.to() to >> get list access. Thats's just a bit friendlier for users of >> Scripturian, who are otherwise agnostic about implementation specifics. >> >> There's an important issue here: remember, there might be many >> different globals, but of course I want them all to use the same code >> cache, which is stored in the Context. So, I use one singleton >> Context and switch globals via Context.setGlobal(). To create a >> Context, I also need access to Options. A limitation in Nashorn is >> that I can't change stdout and stderr after I create the Context >> (Scripturian allows different onces per ExecutionContext), so my >> workaround is to use a custom Writer wrapper class that underneath >> delegates to the correct "real" Writers (I use the same mechanism for >> a few other Scripturian language engines, too). >> >> I grumbled here before that I have no programmatic access to the code >> cache. Behind the scenes, ScriptFunction might retrieve from the >> cache instead of being compiled. I can control the cache base >> location via the "nashorn.persistent.code.cache" system property, but >> it's unfortunate that I can't control the structure and naming the >> way I can with other languages supported by Scripturian. In >> particular, the problem is that it's a global property for the whole >> JVM, whereas compilation and caching location is ideally controlled >> per ExecutionContext in Scripturian. This makes Nashorn support in >> Scripturian a bit more limited. >> >> Finally, for errors during execution, I use NashornException >> (documented!) to extract specific information into Scripturian's more >> generic ExecutionException. >> >> Small extras: I use Version.version() and >> NashornScriptEngineFactory.getLanguageVersion() to get version data. >> >> I think that's everything! Of course, I also had to "reverse >> engineer" much of this (=read a lot of code) and work around many >> quirks (and big differences to Rhino's implementation) before >> streamlining it down to just these few classes. (I tried to work >> around the caching limitations, but gave up due to its complexity. >> Also, I think some of the key classes I would need are private.) I >> did my best not to delve to much into internals, but I hope I made it >> clear to you that it would have been impossible to achieve all the >> above goals without it. >> >> -Tal >> >> On 07/06/2015 04:18 AM, Attila Szegedi wrote: >>> What APIs are you using, BTW? Just curious if I can suggest an >>> alternative approach, or even consider if something you use should >>> be publicly supported. >> > From attila.szegedi at oracle.com Fri Oct 16 13:39:48 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 16 Oct 2015 15:39:48 +0200 Subject: Review request for JDK-8139756: Eliminate GuardedTypeConversion, DynamicLinker.getCurrentLinkRequest and its associated permission Message-ID: <4401A42D-DAF2-4965-82C2-919578BC6A09@oracle.com> Please review JDK-8139756 "Eliminate GuardedTypeConversion, DynamicLinker.getCurrentLinkRequest and its associated permission" at for Note: webrev also shows some previous issues in the history of some of the files, but the changes for those issue are not in the diffs. Thanks, Attila. From attila.szegedi at oracle.com Fri Oct 16 14:04:12 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 16 Oct 2015 16:04:12 +0200 Subject: Review request for JDK-8139761: Improve Dynalink class nomenclature and package organization Message-ID: Please review JDK-8139761 "Improve Dynalink class nomenclature and package organization" at for Thanks, Attila. From marcus at lagergren.net Fri Oct 16 14:04:12 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Fri, 16 Oct 2015 16:04:12 +0200 Subject: Review request for JDK-8139590: Improve Dynalink JavaDoc In-Reply-To: <8D3E39DC-7859-4049-864A-925E470CA1A1@oracle.com> References: <8D3E39DC-7859-4049-864A-925E470CA1A1@oracle.com> Message-ID: <9FEB9A8B-4A7A-4BF5-97EC-A4BF96AEF8F4@lagergren.net> +1 > On 14 Oct 2015, at 15:48, Attila Szegedi wrote: > > Please review JDK-8139590 "Improve Dynalink JavaDoc" at for > > Notes: > - webrev also shows some previous issues in the history of some of the files, but the changes for those issue are not in the diffs. > - In addition to JavaDoc, there are some minor additional fixes: > - GuardedInvocation.assertType was removed; it has shown up in JavaDoc, but it was not used except for one place in TypeConverterFactory, and even there it wasn?t needed > - GuardedInvocation had an accidental dependency on jdk.nashorn.internal.* class; that was eliminated. > - AbstractCallSiteDescriptor.lookupsEqual and lookupHashCode now handle nulls > - CompositeGuardingDynamicLinker and TypeBasedCompositeGuardingDynamicLinker detect if any of its composites are null and throw a NPE > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Fri Oct 16 14:30:06 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 16 Oct 2015 16:30:06 +0200 Subject: Review request for JDK-8139304: Remove some obsolete Dynalink classes In-Reply-To: <745349D0-C7E9-415E-965A-B2F0146A6748@oracle.com> References: <745349D0-C7E9-415E-965A-B2F0146A6748@oracle.com> Message-ID: <562109EE.1050807@oracle.com> One minor issue: DynamicLinker.java still has a reference to {@link DefaultBootstrapper} in its Javadoc. Other than that +1. Hannes Am 2015-10-09 um 19:09 schrieb Attila Szegedi: > Please review JDK-8139304 "Remove some obsolete Dynalink classes" at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Fri Oct 16 15:11:12 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 16 Oct 2015 17:11:12 +0200 Subject: Review request for JDK-8139435: Make sure CallSiteDescriptor.getLookup is subject to a security check In-Reply-To: <9666A523-BE02-4F01-A4C5-40745D9ADD4E@oracle.com> References: <9666A523-BE02-4F01-A4C5-40745D9ADD4E@oracle.com> Message-ID: <56211390.2040309@oracle.com> What's the rationale for providing the static lookupEquals and lookupHashCode methods in AbstractCallSiteDescriptor instead of just putting the code in non-abstract instance methods? This way it's a bit more flexible, but I'm not sure it warrants the additional API surface. There are references to the old getTarget(Lookup) method in the javadoc comments of CallerSensitiveDynamicMethod.java and SimpleDynamicMethod.java that should be changed to getTarget( CallSiteDescriptor). +1 Hannes Am 2015-10-14 um 15:30 schrieb Attila Szegedi: > Please review JDK-8139435 "Make sure CallSiteDescriptor.getLookup is subject to a security check" at for > > Notes: > - webrev also shows a previous issue in the history of some of the files, but the changes for that issue are not in the diffs. > - the mechanism for security checks in this changeset is sound, but it is even further improved by making CallSiteDescriptor into a proper class and internalizing the checks later on (I will be sending that changeset for review separately later). > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Fri Oct 16 15:17:46 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 16 Oct 2015 17:17:46 +0200 Subject: Review request for JDK-8139588: Remove concept of runtime context arguments, call site tokens, and link counts In-Reply-To: <771E0063-D175-4BB6-9058-2723525CDB62@oracle.com> References: <771E0063-D175-4BB6-9058-2723525CDB62@oracle.com> Message-ID: <5621151A.6080103@oracle.com> +1 The DynamicLinker constructor still has the @param runtimeContextArgCount in its javadoc! Hannes Am 2015-10-14 um 15:35 schrieb Attila Szegedi: > Please review JDK-8139588 "Remove concept of runtime context arguments, call site tokens, and link counts" at for > > Note: webrev also shows some previous issues in the history of some of the files, but the changes for those issue are not in the diffs. > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Fri Oct 16 15:49:49 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 16 Oct 2015 17:49:49 +0200 Subject: Review request for JDK-8139590: Improve Dynalink JavaDoc In-Reply-To: <8D3E39DC-7859-4049-864A-925E470CA1A1@oracle.com> References: <8D3E39DC-7859-4049-864A-925E470CA1A1@oracle.com> Message-ID: <56211C9D.7010004@oracle.com> Looks good. A few minor issues I found: - GuardedInvocation.java class javadoc: "as long as the switch point is not invalidated" should be plural. - LinkRequest.java #getReceiver: I think "first argument" would be more intuitive than "0th argument". - BeansLinker.java class javadoc last sentence: "The class also allows exposes...": remove "allows" Hannes Am 2015-10-14 um 15:48 schrieb Attila Szegedi: > Please review JDK-8139590 "Improve Dynalink JavaDoc" at for > > Notes: > - webrev also shows some previous issues in the history of some of the files, but the changes for those issue are not in the diffs. > - In addition to JavaDoc, there are some minor additional fixes: > - GuardedInvocation.assertType was removed; it has shown up in JavaDoc, but it was not used except for one place in TypeConverterFactory, and even there it wasn?t needed > - GuardedInvocation had an accidental dependency on jdk.nashorn.internal.* class; that was eliminated. > - AbstractCallSiteDescriptor.lookupsEqual and lookupHashCode now handle nulls > - CompositeGuardingDynamicLinker and TypeBasedCompositeGuardingDynamicLinker detect if any of its composites are null and throw a NPE > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 19 03:29:11 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 19 Oct 2015 08:59:11 +0530 Subject: Review request for JDK-8139756: Eliminate GuardedTypeConversion, DynamicLinker.getCurrentLinkRequest and its associated permission In-Reply-To: <4401A42D-DAF2-4965-82C2-919578BC6A09@oracle.com> References: <4401A42D-DAF2-4965-82C2-919578BC6A09@oracle.com> Message-ID: <56246386.7050609@oracle.com> +1 On 10/16/2015 7:09 PM, Attila Szegedi wrote: > Please review JDK-8139756 "Eliminate GuardedTypeConversion, DynamicLinker.getCurrentLinkRequest and its associated permission" at for > > Note: webrev also shows some previous issues in the history of some of the files, but the changes for those issue are not in the diffs. > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 19 05:50:18 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 19 Oct 2015 11:20:18 +0530 Subject: RFR 8139852: jjs interactive mode fails to work with security manager Message-ID: <5624849A.50107@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8139852/ for https://bugs.openjdk.java.net/browse/JDK-8139852 Thanks, -Sundar From attila.szegedi at oracle.com Mon Oct 19 06:16:47 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 Oct 2015 08:16:47 +0200 Subject: RFR 8139852: jjs interactive mode fails to work with security manager In-Reply-To: <5624849A.50107@oracle.com> References: <5624849A.50107@oracle.com> Message-ID: +1 > On Oct 19, 2015, at 7:50 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8139852/ for https://bugs.openjdk.java.net/browse/JDK-8139852 > > Thanks, > -Sundar From attila.szegedi at oracle.com Mon Oct 19 06:29:30 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 Oct 2015 08:29:30 +0200 Subject: Review request for JDK-8139435: Make sure CallSiteDescriptor.getLookup is subject to a security check In-Reply-To: <56211390.2040309@oracle.com> References: <9666A523-BE02-4F01-A4C5-40745D9ADD4E@oracle.com> <56211390.2040309@oracle.com> Message-ID: > On Oct 16, 2015, at 5:11 PM, Hannes Wallnoefer wrote: > > What's the rationale for providing the static lookupEquals and lookupHashCode methods in AbstractCallSiteDescriptor instead of just putting the code in non-abstract instance methods? This way it's a bit more flexible, but I'm not sure it warrants the additional API surface. I agree that the API surface increase is not great. The idea was to externalize into subclasses anything that needs access to the lookup object instead of providing access to the lookup object in a superclass. But in the end, that?s actually a better idea (as Sundar pointed out). Fortunately, another changeset coming soon will fix this by making CallSiteDescriptor into a class instead of an interface, and then reduce the API surface back (and eventually eliminate all subclasses and just leave CallSiteDescriptor). > There are references to the old getTarget(Lookup) method in the javadoc comments of CallerSensitiveDynamicMethod.java and SimpleDynamicMethod.java that should be changed to getTarget( CallSiteDescriptor). Fixed the JavaDoc comments, thanks. Attila. > > +1 > > Hannes > > > Am 2015-10-14 um 15:30 schrieb Attila Szegedi: >> Please review JDK-8139435 "Make sure CallSiteDescriptor.getLookup is subject to a security check" at for >> >> Notes: >> - webrev also shows a previous issue in the history of some of the files, but the changes for that issue are not in the diffs. >> - the mechanism for security checks in this changeset is sound, but it is even further improved by making CallSiteDescriptor into a proper class and internalizing the checks later on (I will be sending that changeset for review separately later). >> >> Thanks, >> Attila. > From attila.szegedi at oracle.com Mon Oct 19 06:38:55 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 Oct 2015 08:38:55 +0200 Subject: Review request for JDK-8139588: Remove concept of runtime context arguments, call site tokens, and link counts In-Reply-To: <5621151A.6080103@oracle.com> References: <771E0063-D175-4BB6-9058-2723525CDB62@oracle.com> <5621151A.6080103@oracle.com> Message-ID: > On Oct 16, 2015, at 5:17 PM, Hannes Wallnoefer wrote: > > +1 > > The DynamicLinker constructor still has the @param runtimeContextArgCount in its javadoc! Thanks, fixed. (Also, there was a reference to the no longer existing LinkRequest#withoutRuntimeContext in GuardingDynamicLinker.java - fixed that too). > > Hannes > > Am 2015-10-14 um 15:35 schrieb Attila Szegedi: >> Please review JDK-8139588 "Remove concept of runtime context arguments, call site tokens, and link counts" at for >> >> Note: webrev also shows some previous issues in the history of some of the files, but the changes for those issue are not in the diffs. >> >> Thanks, >> Attila. > From sundararajan.athijegannathan at oracle.com Mon Oct 19 07:01:40 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 19 Oct 2015 12:31:40 +0530 Subject: Review request for JDK-8139761: Improve Dynalink class nomenclature and package organization Message-ID: <56249554.7080707@oracle.com> +1 on http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-October/005431.html -Sundar From hannes.wallnoefer at oracle.com Mon Oct 19 10:14:44 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 19 Oct 2015 12:14:44 +0200 Subject: RFR 8139852: jjs interactive mode fails to work with security manager In-Reply-To: <5624849A.50107@oracle.com> References: <5624849A.50107@oracle.com> Message-ID: <5624C294.40801@oracle.com> +1 Am 2015-10-19 um 07:50 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8139852/ for > https://bugs.openjdk.java.net/browse/JDK-8139852 > > Thanks, > -Sundar From attila.szegedi at oracle.com Mon Oct 19 13:53:45 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 Oct 2015 15:53:45 +0200 Subject: Review request for JDK-8139884: Use privileged blocks when working with class loaders Message-ID: Please review JDK-8139884 "Use privileged blocks when working with class loaders" at for Thanks, Attila. From attila.szegedi at oracle.com Mon Oct 19 14:02:52 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 Oct 2015 16:02:52 +0200 Subject: Review request for JDK-8139887: Reduce visibility of few methods in TypeUtilities and Guards API Message-ID: Please review JDK-8139887 "Reduce visibility of few methods in TypeUtilities and Guards API" at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 19 14:29:46 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 19 Oct 2015 19:59:46 +0530 Subject: Review request for JDK-8139884: Use privileged blocks when working with class loaders In-Reply-To: References: Message-ID: <5624FE5A.5010702@oracle.com> +1 On 10/19/2015 7:23 PM, Attila Szegedi wrote: > Please review JDK-8139884 "Use privileged blocks when working with class loaders" at for > > Thanks, > Attila. From michael.haupt at oracle.com Mon Oct 19 14:33:24 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 19 Oct 2015 16:33:24 +0200 Subject: Review request for JDK-8139884: Use privileged blocks when working with class loaders In-Reply-To: References: Message-ID: Hi Attila, lower-case thumbs up, with just the remark that lambdas could make the code more concise. Best, Michael > Am 19.10.2015 um 15:53 schrieb Attila Szegedi : > > Please review JDK-8139884 "Use privileged blocks when working with class loaders" at for > > Thanks, > Attila. From attila.szegedi at oracle.com Mon Oct 19 14:34:40 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 Oct 2015 16:34:40 +0200 Subject: Review request for JDK-8139888: Improve Dynalink JavaDoc some more Message-ID: <2B610D78-50A5-4D8D-A784-3D0B46BF2245@oracle.com> Please review JDK-8139888 "Improve Dynalink JavaDoc some more" at for This is the last anticipated JavaDoc focused changeset. In addition to JavaDoc improvements, there are few minor changes: - DynamicLinkerFactory rejects nulls in lists of linkers being passed - LinkRequest.replaceArguments was made variable arity (taking Object? as its last arg instead of Object[]), making it consistent with SipleLinkRequest constructor - SimpleLinkRequest rejects nulls in constructor parameters now, and clones incoming arguments lists - Lookup and NameCodec classes were made final Thanks, Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 19 14:35:41 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 19 Oct 2015 20:05:41 +0530 Subject: Review request for JDK-8139887: Reduce visibility of few methods in TypeUtilities and Guards API In-Reply-To: References: Message-ID: <5624FFBD.4050003@oracle.com> +1 -Sundar On 10/19/2015 7:32 PM, Attila Szegedi wrote: > Please review JDK-8139887 "Reduce visibility of few methods in TypeUtilities and Guards API" at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Mon Oct 19 15:16:24 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 19 Oct 2015 17:16:24 +0200 Subject: Review request for JDK-8139756: Eliminate GuardedTypeConversion, DynamicLinker.getCurrentLinkRequest and its associated permission In-Reply-To: <4401A42D-DAF2-4965-82C2-919578BC6A09@oracle.com> References: <4401A42D-DAF2-4965-82C2-919578BC6A09@oracle.com> Message-ID: <56250948.5020706@oracle.com> +1 Am 2015-10-16 um 15:39 schrieb Attila Szegedi: > Please review JDK-8139756 "Eliminate GuardedTypeConversion, DynamicLinker.getCurrentLinkRequest and its associated permission" at for > > Note: webrev also shows some previous issues in the history of some of the files, but the changes for those issue are not in the diffs. > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Mon Oct 19 15:18:30 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 19 Oct 2015 17:18:30 +0200 Subject: Review request for JDK-8139435: Make sure CallSiteDescriptor.getLookup is subject to a security check In-Reply-To: References: <9666A523-BE02-4F01-A4C5-40745D9ADD4E@oracle.com> <56211390.2040309@oracle.com> Message-ID: <562509C5.5070800@oracle.com> Am 2015-10-19 um 08:29 schrieb Attila Szegedi: >> On Oct 16, 2015, at 5:11 PM, Hannes Wallnoefer wrote: >> >> What's the rationale for providing the static lookupEquals and lookupHashCode methods in AbstractCallSiteDescriptor instead of just putting the code in non-abstract instance methods? This way it's a bit more flexible, but I'm not sure it warrants the additional API surface. > I agree that the API surface increase is not great. The idea was to externalize into subclasses anything that needs access to the lookup object instead of providing access to the lookup object in a superclass. But in the end, that?s actually a better idea (as Sundar pointed out). Fortunately, another changeset coming soon will fix this by making CallSiteDescriptor into a class instead of an interface, and then reduce the API surface back (and eventually eliminate all subclasses and just leave CallSiteDescriptor). Thanks for the explanation, sounds good. Hannes From hannes.wallnoefer at oracle.com Mon Oct 19 16:03:05 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 19 Oct 2015 18:03:05 +0200 Subject: Review request for JDK-8139884: Use privileged blocks when working with class loaders In-Reply-To: References: Message-ID: <56251439.5020202@oracle.com> +1 Am 2015-10-19 um 15:53 schrieb Attila Szegedi: > Please review JDK-8139884 "Use privileged blocks when working with class loaders" at for > > Thanks, > Attila. From attila.szegedi at oracle.com Mon Oct 19 16:21:46 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 Oct 2015 18:21:46 +0200 Subject: Review request for JDK-8139895: Introduce GuardingDynamicLinkerExporter Message-ID: <325EA0C3-A81C-45C6-8D2A-48068944AC61@oracle.com> Please review JDK-8139895 "Introduce GuardingDynamicLinkerExporter" at for Remarks: - DynamicLinkerFactory now loads the linkers in a doPrivileged block so that the lack of ?dynalink.exportLinkersAutomatically? permission in the caller doesn?t preclude it from loading trusted linkers. This is consistent with how e.g. ScriptEngineManager uses ServiceLoader. - DynamicLinkerFactory now has a new method "List getAutoLoadingErrors()? so that the user can inspect if some automatically loaded linkers failed to load. This is especially significant as the GuardingDynamicLinkerExporter can have some failure modes: it can lack the dynalink.exportLinkersAutomatically permission, it can return null from get() or any element of the returned element might be null Thanks, Attila. From attila.szegedi at oracle.com Mon Oct 19 18:07:35 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 Oct 2015 11:07:35 -0700 (PDT) Subject: Review request for JDK-8139905: Add a convenience AccessControlContext factory Message-ID: <751C3D8B-EFF8-42FC-BCFA-042B63BDEAFD@oracle.com> Please review JDK-8139905 "Add a convenience AccessControlContext factory" at for Thanks, Attila. From attila.szegedi at oracle.com Mon Oct 19 18:33:10 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 Oct 2015 20:33:10 +0200 Subject: Review request for JDK-8139905: Add a convenience AccessControlContext factory In-Reply-To: <751C3D8B-EFF8-42FC-BCFA-042B63BDEAFD@oracle.com> References: <751C3D8B-EFF8-42FC-BCFA-042B63BDEAFD@oracle.com> Message-ID: Please note that there?s two AccessControlContextFactory classes; it?s unfortunate, but we?ll be separating Dynalink from Nashorn, and while Nashorn can rely on Dynalink, we don?t want to expose the ACC factory from Dynalink, so lacking a better place, we?ll duplicate this small utility for now. Attila. > On Oct 19, 2015, at 8:07 PM, Attila Szegedi wrote: > > Please review JDK-8139905 "Add a convenience AccessControlContext factory" at for > > Thanks, > Attila. From attila.szegedi at oracle.com Mon Oct 19 18:47:10 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 Oct 2015 20:47:10 +0200 Subject: Review request for JDK-8139919: Make CallSiteDescriptor a concrete class Message-ID: <18A20FF5-0E2C-4195-90BA-2E6FB52C0039@oracle.com> Please review JDK-8139919 "Make CallSiteDescriptor a concrete class" at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Tue Oct 20 03:19:14 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 20 Oct 2015 08:49:14 +0530 Subject: Review request for JDK-8139895: Introduce GuardingDynamicLinkerExporter In-Reply-To: <325EA0C3-A81C-45C6-8D2A-48068944AC61@oracle.com> References: <325EA0C3-A81C-45C6-8D2A-48068944AC61@oracle.com> Message-ID: <5625B2B2.4080606@oracle.com> * File: DynamicLinkerFactory: + String autoLoaderClassName = "unknown"; + final GuardingDynamicLinkerExporter autoLoader = it.next(); + try { + autoLoaderClassName = autoLoader.getClass().getName(); + final String knownAutoLoaderClassName = autoLoaderClassName; Do we need 2 variables to store auto loaded class name? autoLoaderClassName seems to be used only to initialize second (final) variable. Am I missing something? * If a particular linker exporter jar does not have necessary permission to export, it appears that it can still do "deniel of service". i.e., SecurityException will force for loop in "discoverAutoLoadLinkers"method to exit early and prevent other legitimate 'linker exporters" from working. -Sundar On 10/19/2015 9:51 PM, Attila Szegedi wrote: > Please review JDK-8139895 "Introduce GuardingDynamicLinkerExporter" at for > > Remarks: > - DynamicLinkerFactory now loads the linkers in a doPrivileged block so that the lack of ?dynalink.exportLinkersAutomatically? permission in the caller doesn?t preclude it from loading trusted linkers. This is consistent with how e.g. ScriptEngineManager uses ServiceLoader. > - DynamicLinkerFactory now has a new method "List getAutoLoadingErrors()? so that the user can inspect if some automatically loaded linkers failed to load. This is especially significant as the GuardingDynamicLinkerExporter can have some failure modes: it can lack the dynalink.exportLinkersAutomatically permission, it can return null from get() or any element of the returned element might be null > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Tue Oct 20 03:30:08 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 20 Oct 2015 09:00:08 +0530 Subject: Review request for JDK-8139919: Make CallSiteDescriptor a concrete class In-Reply-To: <18A20FF5-0E2C-4195-90BA-2E6FB52C0039@oracle.com> References: <18A20FF5-0E2C-4195-90BA-2E6FB52C0039@oracle.com> Message-ID: <5625B540.5060608@oracle.com> +1 -Sundar On 10/20/2015 12:17 AM, Attila Szegedi wrote: > Please review JDK-8139919 "Make CallSiteDescriptor a concrete class" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Tue Oct 20 03:34:45 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 20 Oct 2015 09:04:45 +0530 Subject: Review request for JDK-8139905: Add a convenience AccessControlContext factory In-Reply-To: References: <751C3D8B-EFF8-42FC-BCFA-042B63BDEAFD@oracle.com> Message-ID: <5625B655.8010001@oracle.com> +1 PS. Should the nashorn's AccessControlContextFactory be under jdk.nashorn.internal.runtime? I think this is the first class under jdk.nashorn.internal... -Sundar On 10/20/2015 12:03 AM, Attila Szegedi wrote: > Please note that there?s two AccessControlContextFactory classes; it?s unfortunate, but we?ll be separating Dynalink from Nashorn, and while Nashorn can rely on Dynalink, we don?t want to expose the ACC factory from Dynalink, so lacking a better place, we?ll duplicate this small utility for now. > > Attila. > >> On Oct 19, 2015, at 8:07 PM, Attila Szegedi wrote: >> >> Please review JDK-8139905 "Add a convenience AccessControlContext factory" at for >> >> Thanks, >> Attila. From sundararajan.athijegannathan at oracle.com Tue Oct 20 03:49:37 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 20 Oct 2015 09:19:37 +0530 Subject: Review request for JDK-8139888: Improve Dynalink JavaDoc some more In-Reply-To: <2B610D78-50A5-4D8D-A784-3D0B46BF2245@oracle.com> References: <2B610D78-50A5-4D8D-A784-3D0B46BF2245@oracle.com> Message-ID: <5625B9D1.3060000@oracle.com> * File: http://cr.openjdk.java.net/~attila/8139888/webrev.jdk9/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java.udiff.html "they are themselves" -> "these are" ? +1 -Sundar On 10/19/2015 8:04 PM, Attila Szegedi wrote: > Please review JDK-8139888 "Improve Dynalink JavaDoc some more" at for > > This is the last anticipated JavaDoc focused changeset. > > In addition to JavaDoc improvements, there are few minor changes: > - DynamicLinkerFactory rejects nulls in lists of linkers being passed > - LinkRequest.replaceArguments was made variable arity (taking Object? as its last arg instead of Object[]), making it consistent with SipleLinkRequest constructor > - SimpleLinkRequest rejects nulls in constructor parameters now, and clones incoming arguments lists > - Lookup and NameCodec classes were made final > > Thanks, > Attila. From michel at undercouch.de Tue Oct 20 05:37:01 2015 From: michel at undercouch.de (=?UTF-8?Q?Michel_Kr=c3=a4mer?=) Date: Tue, 20 Oct 2015 07:37:01 +0200 Subject: Excessive memory usage In-Reply-To: <5612DFD0.2010406@undercouch.de> References: <5612BB4B.3020303@undercouch.de> <5612D0AA.3030804@oracle.com> <5612D3AF.3000604@undercouch.de> <5612DB6E.4010109@oracle.com> <5612DFD0.2010406@undercouch.de> Message-ID: <5625D2FD.9010703@undercouch.de> Hi! I can confirm that metaspace usage is much better with JDK 9 Build b85. My little sample program now only needs 1 GB of resident memory and not 1.5 GB like before. That's a huge improvement! Thank you so much! Still I'm wondering - if the heap usage is only at 150 MB, why does Nashorn need 850 MB of metaspace after all just to execute a JavaScript program. OK, the TypeScript compiler is not really small, but 850 MB seems to be a lot compared to what the V8 engine needs for example (just a few MB). Maybe it's worth looking deeper into this issue? Is there any chance these fixes might be backported to Java 8 or is it too much work? Cheers, Michel Am 05.10.2015 um 22:38 schrieb Michel Kr?mer: > (Ooops. I didn't press the reply-to-list button.) > > Thanks for the link to the bug report. I will keep observing the issue > and let you know if I find something. If possible I'll also do a test > with a snapshot build of JDK9 and see if things have changed. > > Thanks, > Michel > > > Am 05.10.2015 um 22:19 schrieb Hannes Wallnoefer: >> Well maybe there is a problem if the process is killed because it uses >> too much memory. I just think it's not heap space, at least not in that >> particular code in your github repository. Is that the same code that is >> running in the CI environments? >> >> I must say I did see increased GC activity and a slowdown after half the >> iterations. >> >> We did fix some problems recently that may cause memory problems under >> certain circumstances, such as >> https://bugs.openjdk.java.net/browse/JDK-8137333 >> >> So I'm not saying there isn't a problem - there may well be one. I just >> think that the observed memory numbers on Linux are not that >> extraordinary. Please keep observing and let us know if you find >> anything new and noteworthy. >> >> Hannes >> >> >> Am 2015-10-05 um 21:46 schrieb Michel Kr?mer: >>> Hannes, >>> >>> Thanks for the quick response. I see... >>> >>> The reason why I'm asking all this is because I tried to run the unit >>> tests for vertx-lang-typescript on Travis CI and Circle CI and they >>> both killed the process after it had reached 4GB (in fact very quickly >>> after the process had started). I had to play with environment >>> variables such as MALLOC_ARENA_MAX to get it down to 2.5 GB. >>> >>> At least it runs now, but I figured it might be something of interest >>> for you as I've never experienced this behaviour with any other code >>> that I ran on Travis CI or Circle CI (and I have a couple of open >>> source projects running there). The memory usage increased quickly >>> when I ran JavaScript code so I thought it might have something to do >>> with Nashorn. >>> >>> I was able to reproduce the issue on my own Ubuntu machine so it's not >>> related to Travis or Circle. >>> >>> As far as I can tell heap memory is not the problem. It seems >>> metaspace is used a lot or maybe direct memory buffers or maybe even >>> something else!? >>> >>> Anyway, if you say this much of memory is normal under Linux then I'm >>> completely fine with it. I just thought if it wasn't the case you >>> might want to know. >>> >>> Cheers, >>> Michel >>> >>> >>> Am 05.10.2015 um 21:34 schrieb Hannes Wallnoefer: >>>> Hi Michel, >>>> >>>> Thanks for the quick and easy github repository to reproduce this. >>>> >>>> Looking at the code running with jvisualvm I can't see any excessive >>>> memory usage. Both with JDK 8u60 and 9 heap usage is around 150 MB. >>>> >>>> The fact that Java reserves a lot of memory on Linux is a well-known >>>> fact. It's not related to Nashorn, but rather to how Java interacts >>>> with >>>> the Linux memory system. It is a bit annoying, but usually it's not a >>>> problem and does not reflect Java heap usage. >>>> >>>> Hannes >>>> >>>> >>>> Am 2015-10-05 um 20:02 schrieb Michel Kr?mer: >>>>> Hi! >>>>> >>>>> I'm currently working on TypeScript support for Vert.x. I'm trying to >>>>> run the TypeScript compiler on Nashorn. It works well, but the process >>>>> uses a lot of memory. I'm wondering if there is a bug in Nashorn or if >>>>> I'm doing something wrong. >>>>> >>>>> I uploaded a small example project demonstrating the issue: >>>>> https://github.com/michel-kraemer/nashorn-memory-test >>>>> >>>>> I tested it under Ubuntu 14.04 with JDK 8u60. I run >>>>> >>>>> javac Main.java && java -Xmx256M -cp . Main >>>>> >>>>> and watch the process with top. The resident memory quickly goes up to >>>>> 1 GB and after about 20 iterations grows even further to 1.2 GB. After >>>>> about 500 iterations it sometimes even goes up to 1.5 GB where it >>>>> stays until the end of the program. That's 1.3 GB more than I >>>>> specified with -Xmx. I know this is metaspace, but I wonder why >>>>> Nashorn needs so much of it. By the way, even if I do only 1 iteration >>>>> the process still goes up to 400-500 MB. >>>>> >>>>> Any ideas? >>>>> >>>>> Cheers, >>>>> Michel >>>> >>>> >> >> > From attila.szegedi at oracle.com Tue Oct 20 07:39:35 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 20 Oct 2015 09:39:35 +0200 Subject: Review request for JDK-8139895: Introduce GuardingDynamicLinkerExporter In-Reply-To: <5625B2B2.4080606@oracle.com> References: <325EA0C3-A81C-45C6-8D2A-48068944AC61@oracle.com> <5625B2B2.4080606@oracle.com> Message-ID: > On Oct 20, 2015, at 5:19 AM, Sundararajan Athijegannathan wrote: > > > > * File: DynamicLinkerFactory: > > + String autoLoaderClassName = "unknown"; > + final GuardingDynamicLinkerExporter autoLoader = it.next(); > + try { > + autoLoaderClassName = autoLoader.getClass().getName(); > + final String knownAutoLoaderClassName = autoLoaderClassName; > > Do we need 2 variables to store auto loaded class name? autoLoaderClassName seems to be used only to initialize second (final) variable. Am I missing something? autoLoaderClassName is also used in the catch(Throwable t) block, so if e.g. it.next() throws an exception, we?ll report it as ?with unknown? (FWIW, it?ll mostly be a ServiceConfigurationError thrown from it.next() and that?ll put the class name in it). Actually, thinking a bit more about it, it.next() will *only* throw a SCE, so this initial setting to ?unknown? is indeed not needed. I?ll change that. > > * If a particular linker exporter jar does not have necessary permission to export, it appears that it can still do "deniel of service". i.e., SecurityException will force for loop in "discoverAutoLoadLinkers"method to exit early and prevent other legitimate 'linker exporters" from working. ServiceLoader catches all instantiation errors and creates a ServiceConfigurationError in response to them, see java.util.ServiceLoader$LazyIterator.nextService() code around c.newInstance(). We have a try/catch for ServiceConfigurationError within the loop, so it will continue with the next linker. There is another try/catch outside the loop, and it will only catch non-recoverable errors, namely any ServiceConfigurationError happening in ServiceLoader.load(), .iterator(), or .hasNext(), but those don?t involve custom code and are to do with IO errors, misconfigured META-INF/services files etc. Mind you, I explicitly exempted any subclass of VirtualMachineError from the recovery process, but that actually doesn?t allow a malicious linker to abort the discovery process by throwing, say, an OutOfMemoryError as ServiceLoader just catches all throwables; so this only guards against a VM error in our code. Attila. > > -Sundar > > On 10/19/2015 9:51 PM, Attila Szegedi wrote: >> Please review JDK-8139895 "Introduce GuardingDynamicLinkerExporter" at for >> >> Remarks: >> - DynamicLinkerFactory now loads the linkers in a doPrivileged block so that the lack of ?dynalink.exportLinkersAutomatically? permission in the caller doesn?t preclude it from loading trusted linkers. This is consistent with how e.g. ScriptEngineManager uses ServiceLoader. >> - DynamicLinkerFactory now has a new method "List getAutoLoadingErrors()? so that the user can inspect if some automatically loaded linkers failed to load. This is especially significant as the GuardingDynamicLinkerExporter can have some failure modes: it can lack the dynalink.exportLinkersAutomatically permission, it can return null from get() or any element of the returned element might be null >> >> Thanks, >> Attila. > From sundararajan.athijegannathan at oracle.com Tue Oct 20 07:42:57 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 20 Oct 2015 13:12:57 +0530 Subject: Review request for JDK-8139895: Introduce GuardingDynamicLinkerExporter In-Reply-To: References: <325EA0C3-A81C-45C6-8D2A-48068944AC61@oracle.com> <5625B2B2.4080606@oracle.com> Message-ID: <5625F081.6040605@oracle.com> Explanations satisfactory. +1 with initialization change. -Sundar On 10/20/2015 1:09 PM, Attila Szegedi wrote: >> On Oct 20, 2015, at 5:19 AM, Sundararajan Athijegannathan wrote: >> >> >> >> * File: DynamicLinkerFactory: >> >> + String autoLoaderClassName = "unknown"; >> + final GuardingDynamicLinkerExporter autoLoader = it.next(); >> + try { >> + autoLoaderClassName = autoLoader.getClass().getName(); >> + final String knownAutoLoaderClassName = autoLoaderClassName; >> >> Do we need 2 variables to store auto loaded class name? autoLoaderClassName seems to be used only to initialize second (final) variable. Am I missing something? > autoLoaderClassName is also used in the catch(Throwable t) block, so if e.g. it.next() throws an exception, we?ll report it as ?with unknown? (FWIW, it?ll mostly be a ServiceConfigurationError thrown from it.next() and that?ll put the class name in it). Actually, thinking a bit more about it, it.next() will *only* throw a SCE, so this initial setting to ?unknown? is indeed not needed. I?ll change that. > >> * If a particular linker exporter jar does not have necessary permission to export, it appears that it can still do "deniel of service". i.e., SecurityException will force for loop in "discoverAutoLoadLinkers"method to exit early and prevent other legitimate 'linker exporters" from working. > ServiceLoader catches all instantiation errors and creates a ServiceConfigurationError in response to them, see java.util.ServiceLoader$LazyIterator.nextService() code around c.newInstance(). We have a try/catch for ServiceConfigurationError within the loop, so it will continue with the next linker. There is another try/catch outside the loop, and it will only catch non-recoverable errors, namely any ServiceConfigurationError happening in ServiceLoader.load(), .iterator(), or .hasNext(), but those don?t involve custom code and are to do with IO errors, misconfigured META-INF/services files etc. > > Mind you, I explicitly exempted any subclass of VirtualMachineError from the recovery process, but that actually doesn?t allow a malicious linker to abort the discovery process by throwing, say, an OutOfMemoryError as ServiceLoader just catches all throwables; so this only guards against a VM error in our code. > > Attila. > >> -Sundar >> >> On 10/19/2015 9:51 PM, Attila Szegedi wrote: >>> Please review JDK-8139895 "Introduce GuardingDynamicLinkerExporter" at for >>> >>> Remarks: >>> - DynamicLinkerFactory now loads the linkers in a doPrivileged block so that the lack of ?dynalink.exportLinkersAutomatically? permission in the caller doesn?t preclude it from loading trusted linkers. This is consistent with how e.g. ScriptEngineManager uses ServiceLoader. >>> - DynamicLinkerFactory now has a new method "List getAutoLoadingErrors()? so that the user can inspect if some automatically loaded linkers failed to load. This is especially significant as the GuardingDynamicLinkerExporter can have some failure modes: it can lack the dynalink.exportLinkersAutomatically permission, it can return null from get() or any element of the returned element might be null >>> >>> Thanks, >>> Attila. From attila.szegedi at oracle.com Tue Oct 20 08:11:22 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 20 Oct 2015 10:11:22 +0200 Subject: Review request for JDK-8139931: Introduce Operation objects in Dynalink instead of string encoding Message-ID: Please review JDK-8139931 "Introduce Operation objects in Dynalink instead of string encoding" at for This is admittedly a big one. It is also the last in the pipeline of the internal Dynalink cleanups, so we?ve reached the end of that! Thanks, Attila. From attila.szegedi at oracle.com Tue Oct 20 08:13:06 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 20 Oct 2015 10:13:06 +0200 Subject: Review request for JDK-8139905: Add a convenience AccessControlContext factory In-Reply-To: <5625B655.8010001@oracle.com> References: <751C3D8B-EFF8-42FC-BCFA-042B63BDEAFD@oracle.com> <5625B655.8010001@oracle.com> Message-ID: <57A7B365-7354-4FF0-B663-1823085B9012@oracle.com> There?s actually IntDeque and AssertsEnabled in jdk.nashorn.internal. OTOH, all its users are themselves in internal.runtime.* package space, so it doesn?t hurt to move it there - will do that. Attila. > On Oct 20, 2015, at 5:34 AM, Sundararajan Athijegannathan wrote: > > +1 > > PS. Should the nashorn's AccessControlContextFactory be under jdk.nashorn.internal.runtime? I think this is the first class under jdk.nashorn.internal... > > -Sundar > > On 10/20/2015 12:03 AM, Attila Szegedi wrote: >> Please note that there?s two AccessControlContextFactory classes; it?s unfortunate, but we?ll be separating Dynalink from Nashorn, and while Nashorn can rely on Dynalink, we don?t want to expose the ACC factory from Dynalink, so lacking a better place, we?ll duplicate this small utility for now. >> >> Attila. >> >>> On Oct 19, 2015, at 8:07 PM, Attila Szegedi wrote: >>> >>> Please review JDK-8139905 "Add a convenience AccessControlContext factory" at for >>> >>> Thanks, >>> Attila. > From attila.szegedi at oracle.com Tue Oct 20 08:24:42 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 20 Oct 2015 10:24:42 +0200 Subject: Review request for JDK-8139905: Add a convenience AccessControlContext factory In-Reply-To: <57A7B365-7354-4FF0-B663-1823085B9012@oracle.com> References: <751C3D8B-EFF8-42FC-BCFA-042B63BDEAFD@oracle.com> <5625B655.8010001@oracle.com> <57A7B365-7354-4FF0-B663-1823085B9012@oracle.com> Message-ID: <23B1E775-E5EA-443F-AD5B-C3222345A2EB@oracle.com> Updated the webrev in-place to reflect the AccessControlContextFactory is now in jdk.nashorn.internal.runtime. Attila. > On Oct 20, 2015, at 10:13 AM, Attila Szegedi wrote: > > There?s actually IntDeque and AssertsEnabled in jdk.nashorn.internal. OTOH, all its users are themselves in internal.runtime.* package space, so it doesn?t hurt to move it there - will do that. > > Attila. > >> On Oct 20, 2015, at 5:34 AM, Sundararajan Athijegannathan wrote: >> >> +1 >> >> PS. Should the nashorn's AccessControlContextFactory be under jdk.nashorn.internal.runtime? I think this is the first class under jdk.nashorn.internal... >> >> -Sundar >> >> On 10/20/2015 12:03 AM, Attila Szegedi wrote: >>> Please note that there?s two AccessControlContextFactory classes; it?s unfortunate, but we?ll be separating Dynalink from Nashorn, and while Nashorn can rely on Dynalink, we don?t want to expose the ACC factory from Dynalink, so lacking a better place, we?ll duplicate this small utility for now. >>> >>> Attila. >>> >>>> On Oct 19, 2015, at 8:07 PM, Attila Szegedi wrote: >>>> >>>> Please review JDK-8139905 "Add a convenience AccessControlContext factory" at for >>>> >>>> Thanks, >>>> Attila. >> > From sundararajan.athijegannathan at oracle.com Tue Oct 20 08:25:14 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 20 Oct 2015 13:55:14 +0530 Subject: Review request for JDK-8139905: Add a convenience AccessControlContext factory In-Reply-To: <23B1E775-E5EA-443F-AD5B-C3222345A2EB@oracle.com> References: <751C3D8B-EFF8-42FC-BCFA-042B63BDEAFD@oracle.com> <5625B655.8010001@oracle.com> <57A7B365-7354-4FF0-B663-1823085B9012@oracle.com> <23B1E775-E5EA-443F-AD5B-C3222345A2EB@oracle.com> Message-ID: <5625FA6A.6070808@oracle.com> +1 -Sundar On 10/20/2015 1:54 PM, Attila Szegedi wrote: > Updated the webrev in-place to reflect the AccessControlContextFactory is now in jdk.nashorn.internal.runtime. > > Attila. > >> On Oct 20, 2015, at 10:13 AM, Attila Szegedi wrote: >> >> There?s actually IntDeque and AssertsEnabled in jdk.nashorn.internal. OTOH, all its users are themselves in internal.runtime.* package space, so it doesn?t hurt to move it there - will do that. >> >> Attila. >> >>> On Oct 20, 2015, at 5:34 AM, Sundararajan Athijegannathan wrote: >>> >>> +1 >>> >>> PS. Should the nashorn's AccessControlContextFactory be under jdk.nashorn.internal.runtime? I think this is the first class under jdk.nashorn.internal... >>> >>> -Sundar >>> >>> On 10/20/2015 12:03 AM, Attila Szegedi wrote: >>>> Please note that there?s two AccessControlContextFactory classes; it?s unfortunate, but we?ll be separating Dynalink from Nashorn, and while Nashorn can rely on Dynalink, we don?t want to expose the ACC factory from Dynalink, so lacking a better place, we?ll duplicate this small utility for now. >>>> >>>> Attila. >>>> >>>>> On Oct 19, 2015, at 8:07 PM, Attila Szegedi wrote: >>>>> >>>>> Please review JDK-8139905 "Add a convenience AccessControlContext factory" at for >>>>> >>>>> Thanks, >>>>> Attila. From sundararajan.athijegannathan at oracle.com Tue Oct 20 08:52:46 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 20 Oct 2015 14:22:46 +0530 Subject: Review request for JDK-8139931: Introduce Operation objects in Dynalink instead of string encoding In-Reply-To: References: Message-ID: <562600DE.2030907@oracle.com> * StandardOperation.java is missing copyright. * NamedOperation.java is missing copyright. * CompositeOperation.java is missing copyright. * Can CompositeOperation be final? * Unrelated ArrayData change? Unused method? * NashornCallSiteDescriptor may have explanation as to why 18 bits are sufficient for "program point" [now that flag bits are used for encoding operation enums as well] That's all I could find... +1 -Sundar On 10/20/2015 1:41 PM, Attila Szegedi wrote: > Please review JDK-8139931 "Introduce Operation objects in Dynalink instead of string encoding" at for > > This is admittedly a big one. It is also the last in the pipeline of the internal Dynalink cleanups, so we?ve reached the end of that! > > Thanks, > Attila. From attila.szegedi at oracle.com Tue Oct 20 09:30:33 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 20 Oct 2015 11:30:33 +0200 Subject: Review request for JDK-8139884: Use privileged blocks when working with class loaders In-Reply-To: References: Message-ID: Hi Michael, I agree with that in general. I?m using lambdas for doPrivileged here and there; in fact my initial version of the code used them, but then I changed them back to explicit PrivilegedAction objects as this particular change looks like a candidate for backporting to 8u-dev and there we unfortunately can?t use lambdas because of Nashorn?s ?-source 1.7? requirement, so I?ll avoid them here. Attila. > On Oct 19, 2015, at 4:33 PM, Michael Haupt wrote: > > Hi Attila, > > lower-case thumbs up, with just the remark that lambdas could make the code more concise. > > Best, > > Michael > >> Am 19.10.2015 um 15:53 schrieb Attila Szegedi : >> >> Please review JDK-8139884 "Use privileged blocks when working with class loaders" at for >> >> Thanks, >> Attila. > > From attila.szegedi at oracle.com Tue Oct 20 09:39:39 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 20 Oct 2015 11:39:39 +0200 Subject: Review request for JDK-8139931: Introduce Operation objects in Dynalink instead of string encoding In-Reply-To: <562600DE.2030907@oracle.com> References: <562600DE.2030907@oracle.com> Message-ID: <96C075DF-71A3-4260-AB7F-6F7B1517D2BB@oracle.com> > On Oct 20, 2015, at 10:52 AM, Sundararajan Athijegannathan wrote: > > * StandardOperation.java is missing copyright. > > * NamedOperation.java is missing copyright. > > * CompositeOperation.java is missing copyright. Indeed; added copyrights. > * Can CompositeOperation be final? Well, it?s hard to see why would someone want to subclass it, but I also don?t really see why someone shouldn?t be able to do it, to maybe add some language-specific information and still have it be recognized externally as CompositeOperation. (Same reasoning goes for NamedOperation, I guess). Do you have an rationale for making it final? > > * Unrelated ArrayData change? Unused method? Yes. I was following a change in the parameter type from String to Operation and stumbled upon it. > * NashornCallSiteDescriptor may have explanation as to why 18 bits are sufficient for "program point" [now that flag bits are used for encoding operation enums as well] I agree, I added an explanation. > > That's all I could find... > > +1 > > -Sundar > > On 10/20/2015 1:41 PM, Attila Szegedi wrote: >> Please review JDK-8139931 "Introduce Operation objects in Dynalink instead of string encoding" at for >> >> This is admittedly a big one. It is also the last in the pipeline of the internal Dynalink cleanups, so we?ve reached the end of that! >> >> Thanks, >> Attila. > From sundararajan.athijegannathan at oracle.com Tue Oct 20 10:29:13 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 20 Oct 2015 15:59:13 +0530 Subject: Review request for JDK-8139931: Introduce Operation objects in Dynalink instead of string encoding In-Reply-To: <96C075DF-71A3-4260-AB7F-6F7B1517D2BB@oracle.com> References: <562600DE.2030907@oracle.com> <96C075DF-71A3-4260-AB7F-6F7B1517D2BB@oracle.com> Message-ID: <56261779.70903@oracle.com> +1 with changes. On final modifier: nothing specific comes to mind. We can leave it non-final... -Sundar On 10/20/2015 3:09 PM, Attila Szegedi wrote: >> On Oct 20, 2015, at 10:52 AM, Sundararajan Athijegannathan wrote: >> >> * StandardOperation.java is missing copyright. >> >> * NamedOperation.java is missing copyright. >> >> * CompositeOperation.java is missing copyright. > Indeed; added copyrights. > >> * Can CompositeOperation be final? > Well, it?s hard to see why would someone want to subclass it, but I also don?t really see why someone shouldn?t be able to do it, to maybe add some language-specific information and still have it be recognized externally as CompositeOperation. (Same reasoning goes for NamedOperation, I guess). Do you have an rationale for making it final? > >> * Unrelated ArrayData change? Unused method? > Yes. I was following a change in the parameter type from String to Operation and stumbled upon it. > >> * NashornCallSiteDescriptor may have explanation as to why 18 bits are sufficient for "program point" [now that flag bits are used for encoding operation enums as well] > I agree, I added an explanation. > >> That's all I could find... >> >> +1 >> >> -Sundar >> >> On 10/20/2015 1:41 PM, Attila Szegedi wrote: >>> Please review JDK-8139931 "Introduce Operation objects in Dynalink instead of string encoding" at for >>> >>> This is admittedly a big one. It is also the last in the pipeline of the internal Dynalink cleanups, so we?ve reached the end of that! >>> >>> Thanks, >>> Attila. From marcus at lagergren.net Tue Oct 20 10:48:10 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Tue, 20 Oct 2015 12:48:10 +0200 Subject: Review request for JDK-8139919: Make CallSiteDescriptor a concrete class In-Reply-To: <18A20FF5-0E2C-4195-90BA-2E6FB52C0039@oracle.com> References: <18A20FF5-0E2C-4195-90BA-2E6FB52C0039@oracle.com> Message-ID: <4D7842D2-E3FD-4BDA-8892-5B42B2A0F009@lagergren.net> +1 > On 19 Oct 2015, at 20:47, Attila Szegedi wrote: > > Please review JDK-8139919 "Make CallSiteDescriptor a concrete class" at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Tue Oct 20 13:07:50 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 20 Oct 2015 15:07:50 +0200 Subject: Review request for JDK-8139887: Reduce visibility of few methods in TypeUtilities and Guards API In-Reply-To: References: Message-ID: <56263CA6.3030701@oracle.com> +1 Am 2015-10-19 um 16:02 schrieb Attila Szegedi: > Please review JDK-8139887 "Reduce visibility of few methods in TypeUtilities and Guards API" at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Tue Oct 20 13:22:21 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 20 Oct 2015 15:22:21 +0200 Subject: Review request for JDK-8139761: Improve Dynalink class nomenclature and package organization In-Reply-To: References: Message-ID: <5626400D.3010203@oracle.com> Adding the linker.support package is probably the correct thing to do. But it creates two similiarly named packages and a deeper and bigger package structure. My approach would have been to keep the package structure simple, but if most people agree it's better this way I won't stand in the way. Hannes Am 2015-10-16 um 16:04 schrieb Attila Szegedi: > Please review JDK-8139761 "Improve Dynalink class nomenclature and package organization" at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Tue Oct 20 13:30:57 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 20 Oct 2015 15:30:57 +0200 Subject: Excessive memory usage In-Reply-To: <5625D2FD.9010703@undercouch.de> References: <5612BB4B.3020303@undercouch.de> <5612D0AA.3030804@oracle.com> <5612D3AF.3000604@undercouch.de> <5612DB6E.4010109@oracle.com> <5612DFD0.2010406@undercouch.de> <5625D2FD.9010703@undercouch.de> Message-ID: <56264211.5030304@oracle.com> Hi Michel, Thanks for letting us know that this fix improves memory usage for you. The bug has already been backported to 8u, the fix version is 8u72. https://bugs.openjdk.java.net/browse/JDK-8138634 Hannes Am 2015-10-20 um 07:37 schrieb Michel Kr?mer: > Hi! > > I can confirm that metaspace usage is much better with JDK 9 Build > b85. My little sample program now only needs 1 GB of resident memory > and not 1.5 GB like before. That's a huge improvement! Thank you so much! > > Still I'm wondering - if the heap usage is only at 150 MB, why does > Nashorn need 850 MB of metaspace after all just to execute a > JavaScript program. OK, the TypeScript compiler is not really small, > but 850 MB seems to be a lot compared to what the V8 engine needs for > example (just a few MB). Maybe it's worth looking deeper into this issue? > > Is there any chance these fixes might be backported to Java 8 or is it > too much work? > > Cheers, > Michel > > > Am 05.10.2015 um 22:38 schrieb Michel Kr?mer: >> (Ooops. I didn't press the reply-to-list button.) >> >> Thanks for the link to the bug report. I will keep observing the issue >> and let you know if I find something. If possible I'll also do a test >> with a snapshot build of JDK9 and see if things have changed. >> >> Thanks, >> Michel >> >> >> Am 05.10.2015 um 22:19 schrieb Hannes Wallnoefer: >>> Well maybe there is a problem if the process is killed because it uses >>> too much memory. I just think it's not heap space, at least not in that >>> particular code in your github repository. Is that the same code >>> that is >>> running in the CI environments? >>> >>> I must say I did see increased GC activity and a slowdown after half >>> the >>> iterations. >>> >>> We did fix some problems recently that may cause memory problems under >>> certain circumstances, such as >>> https://bugs.openjdk.java.net/browse/JDK-8137333 >>> >>> So I'm not saying there isn't a problem - there may well be one. I just >>> think that the observed memory numbers on Linux are not that >>> extraordinary. Please keep observing and let us know if you find >>> anything new and noteworthy. >>> >>> Hannes >>> >>> >>> Am 2015-10-05 um 21:46 schrieb Michel Kr?mer: >>>> Hannes, >>>> >>>> Thanks for the quick response. I see... >>>> >>>> The reason why I'm asking all this is because I tried to run the unit >>>> tests for vertx-lang-typescript on Travis CI and Circle CI and they >>>> both killed the process after it had reached 4GB (in fact very quickly >>>> after the process had started). I had to play with environment >>>> variables such as MALLOC_ARENA_MAX to get it down to 2.5 GB. >>>> >>>> At least it runs now, but I figured it might be something of interest >>>> for you as I've never experienced this behaviour with any other code >>>> that I ran on Travis CI or Circle CI (and I have a couple of open >>>> source projects running there). The memory usage increased quickly >>>> when I ran JavaScript code so I thought it might have something to do >>>> with Nashorn. >>>> >>>> I was able to reproduce the issue on my own Ubuntu machine so it's not >>>> related to Travis or Circle. >>>> >>>> As far as I can tell heap memory is not the problem. It seems >>>> metaspace is used a lot or maybe direct memory buffers or maybe even >>>> something else!? >>>> >>>> Anyway, if you say this much of memory is normal under Linux then I'm >>>> completely fine with it. I just thought if it wasn't the case you >>>> might want to know. >>>> >>>> Cheers, >>>> Michel >>>> >>>> >>>> Am 05.10.2015 um 21:34 schrieb Hannes Wallnoefer: >>>>> Hi Michel, >>>>> >>>>> Thanks for the quick and easy github repository to reproduce this. >>>>> >>>>> Looking at the code running with jvisualvm I can't see any excessive >>>>> memory usage. Both with JDK 8u60 and 9 heap usage is around 150 MB. >>>>> >>>>> The fact that Java reserves a lot of memory on Linux is a well-known >>>>> fact. It's not related to Nashorn, but rather to how Java interacts >>>>> with >>>>> the Linux memory system. It is a bit annoying, but usually it's not a >>>>> problem and does not reflect Java heap usage. >>>>> >>>>> Hannes >>>>> >>>>> >>>>> Am 2015-10-05 um 20:02 schrieb Michel Kr?mer: >>>>>> Hi! >>>>>> >>>>>> I'm currently working on TypeScript support for Vert.x. I'm >>>>>> trying to >>>>>> run the TypeScript compiler on Nashorn. It works well, but the >>>>>> process >>>>>> uses a lot of memory. I'm wondering if there is a bug in Nashorn >>>>>> or if >>>>>> I'm doing something wrong. >>>>>> >>>>>> I uploaded a small example project demonstrating the issue: >>>>>> https://github.com/michel-kraemer/nashorn-memory-test >>>>>> >>>>>> I tested it under Ubuntu 14.04 with JDK 8u60. I run >>>>>> >>>>>> javac Main.java && java -Xmx256M -cp . Main >>>>>> >>>>>> and watch the process with top. The resident memory quickly goes >>>>>> up to >>>>>> 1 GB and after about 20 iterations grows even further to 1.2 GB. >>>>>> After >>>>>> about 500 iterations it sometimes even goes up to 1.5 GB where it >>>>>> stays until the end of the program. That's 1.3 GB more than I >>>>>> specified with -Xmx. I know this is metaspace, but I wonder why >>>>>> Nashorn needs so much of it. By the way, even if I do only 1 >>>>>> iteration >>>>>> the process still goes up to 400-500 MB. >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> Cheers, >>>>>> Michel >>>>> >>>>> >>> >>> >> From hannes.wallnoefer at oracle.com Tue Oct 20 14:22:34 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 20 Oct 2015 16:22:34 +0200 Subject: Review request for JDK-8139888: Improve Dynalink JavaDoc some more In-Reply-To: <2B610D78-50A5-4D8D-A784-3D0B46BF2245@oracle.com> References: <2B610D78-50A5-4D8D-A784-3D0B46BF2245@oracle.com> Message-ID: <56264E2A.9030304@oracle.com> +1, some very nice documentation there. Two minor issues I found: DefaultInternalObjectFilter.java class javadoc: "on those parameters and return values types that are declared to have type {@link Object}": the first "types" should be removed. DynamicLinker.java class javadoc: "A dynamic linker a main objects when using Dynalink...": not a proper sentence. Hannes Am 2015-10-19 um 16:34 schrieb Attila Szegedi: > Please review JDK-8139888 "Improve Dynalink JavaDoc some more" at for > > This is the last anticipated JavaDoc focused changeset. > > In addition to JavaDoc improvements, there are few minor changes: > - DynamicLinkerFactory rejects nulls in lists of linkers being passed > - LinkRequest.replaceArguments was made variable arity (taking Object? as its last arg instead of Object[]), making it consistent with SipleLinkRequest constructor > - SimpleLinkRequest rejects nulls in constructor parameters now, and clones incoming arguments lists > - Lookup and NameCodec classes were made final > > Thanks, > Attila. From attila.szegedi at oracle.com Tue Oct 20 14:31:46 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 20 Oct 2015 16:31:46 +0200 Subject: Review request for JDK-8139888: Improve Dynalink JavaDoc some more In-Reply-To: <56264E2A.9030304@oracle.com> References: <2B610D78-50A5-4D8D-A784-3D0B46BF2245@oracle.com> <56264E2A.9030304@oracle.com> Message-ID: <845B383A-909F-477F-A961-11FD4638E016@oracle.com> Thanks, fixed those. > On Oct 20, 2015, at 4:22 PM, Hannes Wallnoefer wrote: > > +1, some very nice documentation there. Two minor issues I found: > > DefaultInternalObjectFilter.java class javadoc: "on those parameters and return values types that are declared to have type {@link Object}": the first "types" should be removed. > > DynamicLinker.java class javadoc: "A dynamic linker a main objects when using Dynalink...": not a proper sentence. > > Hannes > > > Am 2015-10-19 um 16:34 schrieb Attila Szegedi: >> Please review JDK-8139888 "Improve Dynalink JavaDoc some more" at for >> >> This is the last anticipated JavaDoc focused changeset. >> >> In addition to JavaDoc improvements, there are few minor changes: >> - DynamicLinkerFactory rejects nulls in lists of linkers being passed >> - LinkRequest.replaceArguments was made variable arity (taking Object? as its last arg instead of Object[]), making it consistent with SipleLinkRequest constructor >> - SimpleLinkRequest rejects nulls in constructor parameters now, and clones incoming arguments lists >> - Lookup and NameCodec classes were made final >> Thanks, >> Attila. > From hannes.wallnoefer at oracle.com Tue Oct 20 14:34:34 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 20 Oct 2015 16:34:34 +0200 Subject: Review request for JDK-8139895: Introduce GuardingDynamicLinkerExporter In-Reply-To: <325EA0C3-A81C-45C6-8D2A-48068944AC61@oracle.com> References: <325EA0C3-A81C-45C6-8D2A-48068944AC61@oracle.com> Message-ID: <562650FA.2010608@oracle.com> +1 Am 2015-10-19 um 18:21 schrieb Attila Szegedi: > Please review JDK-8139895 "Introduce GuardingDynamicLinkerExporter" at for > > Remarks: > - DynamicLinkerFactory now loads the linkers in a doPrivileged block so that the lack of ?dynalink.exportLinkersAutomatically? permission in the caller doesn?t preclude it from loading trusted linkers. This is consistent with how e.g. ScriptEngineManager uses ServiceLoader. > - DynamicLinkerFactory now has a new method "List getAutoLoadingErrors()? so that the user can inspect if some automatically loaded linkers failed to load. This is especially significant as the GuardingDynamicLinkerExporter can have some failure modes: it can lack the dynalink.exportLinkersAutomatically permission, it can return null from get() or any element of the returned element might be null > > Thanks, > Attila. From attila.szegedi at oracle.com Tue Oct 20 14:47:35 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 20 Oct 2015 16:47:35 +0200 Subject: Review request for JDK-8139761: Improve Dynalink class nomenclature and package organization In-Reply-To: <5626400D.3010203@oracle.com> References: <5626400D.3010203@oracle.com> Message-ID: I structured it this way as I think it adds to the clarity of the API; .linker has classes essential for implementing linkers, and .linker.support contains conveniences. Similarly, .support contains conveniences for using the base package. Other approaches I could think of: 1. merge .linker.support into .support: I dislike it as I can imagine some languages not needing .linker or .linker.support (e.g. a scripting shell or a language that doesn?t have its own object model but uses JVM object model straight). I don?t want .support to be a multipurpose ?util? package. 2. merge .linker.support into .linker: then .linker would look more complicated than it is; right now it only contains the specification essentials 3. instead of .linker.support use .support.linker: same depth of package names, not sure what?s the benefit. I?d be for keeping the current structure (obviously :-) ) Attila. > On Oct 20, 2015, at 3:22 PM, Hannes Wallnoefer wrote: > > Adding the linker.support package is probably the correct thing to do. But it creates two similiarly named packages and a deeper and bigger package structure. My approach would have been to keep the package structure simple, but if most people agree it's better this way I won't stand in the way. > > Hannes > > Am 2015-10-16 um 16:04 schrieb Attila Szegedi: >> Please review JDK-8139761 "Improve Dynalink class nomenclature and package organization" at for >> >> Thanks, >> Attila. > From hannes.wallnoefer at oracle.com Tue Oct 20 17:11:57 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 20 Oct 2015 19:11:57 +0200 Subject: Review request for JDK-8139761: Improve Dynalink class nomenclature and package organization In-Reply-To: References: <5626400D.3010203@oracle.com> Message-ID: <562675DD.5010300@oracle.com> Fair enough. You know the library best and I trust your judgement. Also, it's not a library built for the casual user, so clean structure may be more important than simplicity. Hannes Am 2015-10-20 um 16:47 schrieb Attila Szegedi: > I structured it this way as I think it adds to the clarity of the API; .linker has classes essential for implementing linkers, and .linker.support contains conveniences. Similarly, .support contains conveniences for using the base package. > > Other approaches I could think of: > 1. merge .linker.support into .support: I dislike it as I can imagine some languages not needing .linker or .linker.support (e.g. a scripting shell or a language that doesn?t have its own object model but uses JVM object model straight). I don?t want .support to be a multipurpose ?util? package. > 2. merge .linker.support into .linker: then .linker would look more complicated than it is; right now it only contains the specification essentials > 3. instead of .linker.support use .support.linker: same depth of package names, not sure what?s the benefit. > > I?d be for keeping the current structure (obviously :-) ) > > Attila. > >> On Oct 20, 2015, at 3:22 PM, Hannes Wallnoefer wrote: >> >> Adding the linker.support package is probably the correct thing to do. But it creates two similiarly named packages and a deeper and bigger package structure. My approach would have been to keep the package structure simple, but if most people agree it's better this way I won't stand in the way. >> >> Hannes >> >> Am 2015-10-16 um 16:04 schrieb Attila Szegedi: >>> Please review JDK-8139761 "Improve Dynalink class nomenclature and package organization" at for >>> >>> Thanks, >>> Attila. From attila.szegedi at oracle.com Tue Oct 20 18:28:55 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 20 Oct 2015 20:28:55 +0200 Subject: Review request for JDK-8139761: Improve Dynalink class nomenclature and package organization In-Reply-To: <562675DD.5010300@oracle.com> References: <5626400D.3010203@oracle.com> <562675DD.5010300@oracle.com> Message-ID: <0C72A55C-60AC-4E86-A6A4-588CB1B9E58B@oracle.com> so, is that a +1? :-) > On Oct 20, 2015, at 7:11 PM, Hannes Wallnoefer wrote: > > Fair enough. You know the library best and I trust your judgement. Also, it's not a library built for the casual user, so clean structure may be more important than simplicity. > > Hannes > > Am 2015-10-20 um 16:47 schrieb Attila Szegedi: >> I structured it this way as I think it adds to the clarity of the API; .linker has classes essential for implementing linkers, and .linker.support contains conveniences. Similarly, .support contains conveniences for using the base package. >> >> Other approaches I could think of: >> 1. merge .linker.support into .support: I dislike it as I can imagine some languages not needing .linker or .linker.support (e.g. a scripting shell or a language that doesn?t have its own object model but uses JVM object model straight). I don?t want .support to be a multipurpose ?util? package. >> 2. merge .linker.support into .linker: then .linker would look more complicated than it is; right now it only contains the specification essentials >> 3. instead of .linker.support use .support.linker: same depth of package names, not sure what?s the benefit. >> >> I?d be for keeping the current structure (obviously :-) ) >> >> Attila. >> >>> On Oct 20, 2015, at 3:22 PM, Hannes Wallnoefer wrote: >>> >>> Adding the linker.support package is probably the correct thing to do. But it creates two similiarly named packages and a deeper and bigger package structure. My approach would have been to keep the package structure simple, but if most people agree it's better this way I won't stand in the way. >>> >>> Hannes >>> >>> Am 2015-10-16 um 16:04 schrieb Attila Szegedi: >>>> Please review JDK-8139761 "Improve Dynalink class nomenclature and package organization" at for >>>> >>>> Thanks, >>>> Attila. > From hannes.wallnoefer at oracle.com Tue Oct 20 20:12:33 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 20 Oct 2015 22:12:33 +0200 Subject: Review request for JDK-8139761: Improve Dynalink class nomenclature and package organization In-Reply-To: <0C72A55C-60AC-4E86-A6A4-588CB1B9E58B@oracle.com> References: <5626400D.3010203@oracle.com> <562675DD.5010300@oracle.com> <0C72A55C-60AC-4E86-A6A4-588CB1B9E58B@oracle.com> Message-ID: <5626A031.1020000@oracle.com> Am 2015-10-20 um 20:28 schrieb Attila Szegedi: > so, is that a +1? :-) Yes :) I thought about adding a +1 at the end but thought it would be redundant. Hannes >> On Oct 20, 2015, at 7:11 PM, Hannes Wallnoefer wrote: >> >> Fair enough. You know the library best and I trust your judgement. Also, it's not a library built for the casual user, so clean structure may be more important than simplicity. >> >> Hannes >> >> Am 2015-10-20 um 16:47 schrieb Attila Szegedi: >>> I structured it this way as I think it adds to the clarity of the API; .linker has classes essential for implementing linkers, and .linker.support contains conveniences. Similarly, .support contains conveniences for using the base package. >>> >>> Other approaches I could think of: >>> 1. merge .linker.support into .support: I dislike it as I can imagine some languages not needing .linker or .linker.support (e.g. a scripting shell or a language that doesn?t have its own object model but uses JVM object model straight). I don?t want .support to be a multipurpose ?util? package. >>> 2. merge .linker.support into .linker: then .linker would look more complicated than it is; right now it only contains the specification essentials >>> 3. instead of .linker.support use .support.linker: same depth of package names, not sure what?s the benefit. >>> >>> I?d be for keeping the current structure (obviously :-) ) >>> >>> Attila. >>> >>>> On Oct 20, 2015, at 3:22 PM, Hannes Wallnoefer wrote: >>>> >>>> Adding the linker.support package is probably the correct thing to do. But it creates two similiarly named packages and a deeper and bigger package structure. My approach would have been to keep the package structure simple, but if most people agree it's better this way I won't stand in the way. >>>> >>>> Hannes >>>> >>>> Am 2015-10-16 um 16:04 schrieb Attila Szegedi: >>>>> Please review JDK-8139761 "Improve Dynalink class nomenclature and package organization" at for >>>>> >>>>> Thanks, >>>>> Attila. From hannes.wallnoefer at oracle.com Wed Oct 21 07:34:06 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 21 Oct 2015 09:34:06 +0200 Subject: Review request for JDK-8139905: Add a convenience AccessControlContext factory In-Reply-To: <23B1E775-E5EA-443F-AD5B-C3222345A2EB@oracle.com> References: <751C3D8B-EFF8-42FC-BCFA-042B63BDEAFD@oracle.com> <5625B655.8010001@oracle.com> <57A7B365-7354-4FF0-B663-1823085B9012@oracle.com> <23B1E775-E5EA-443F-AD5B-C3222345A2EB@oracle.com> Message-ID: <56273FEE.9030402@oracle.com> +1 Am 2015-10-20 um 10:24 schrieb Attila Szegedi: > Updated the webrev in-place to reflect the AccessControlContextFactory is now in jdk.nashorn.internal.runtime. > > Attila. > >> On Oct 20, 2015, at 10:13 AM, Attila Szegedi wrote: >> >> There?s actually IntDeque and AssertsEnabled in jdk.nashorn.internal. OTOH, all its users are themselves in internal.runtime.* package space, so it doesn?t hurt to move it there - will do that. >> >> Attila. >> >>> On Oct 20, 2015, at 5:34 AM, Sundararajan Athijegannathan wrote: >>> >>> +1 >>> >>> PS. Should the nashorn's AccessControlContextFactory be under jdk.nashorn.internal.runtime? I think this is the first class under jdk.nashorn.internal... >>> >>> -Sundar >>> >>> On 10/20/2015 12:03 AM, Attila Szegedi wrote: >>>> Please note that there?s two AccessControlContextFactory classes; it?s unfortunate, but we?ll be separating Dynalink from Nashorn, and while Nashorn can rely on Dynalink, we don?t want to expose the ACC factory from Dynalink, so lacking a better place, we?ll duplicate this small utility for now. >>>> >>>> Attila. >>>> >>>>> On Oct 19, 2015, at 8:07 PM, Attila Szegedi wrote: >>>>> >>>>> Please review JDK-8139905 "Add a convenience AccessControlContext factory" at for >>>>> >>>>> Thanks, >>>>> Attila. From hannes.wallnoefer at oracle.com Wed Oct 21 07:41:18 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 21 Oct 2015 09:41:18 +0200 Subject: Review request for JDK-8139919: Make CallSiteDescriptor a concrete class In-Reply-To: <18A20FF5-0E2C-4195-90BA-2E6FB52C0039@oracle.com> References: <18A20FF5-0E2C-4195-90BA-2E6FB52C0039@oracle.com> Message-ID: <5627419E.9070505@oracle.com> +1 Am 2015-10-19 um 20:47 schrieb Attila Szegedi: > Please review JDK-8139919 "Make CallSiteDescriptor a concrete class" at for > > Thanks, > Attila. From attila.szegedi at oracle.com Wed Oct 21 10:48:52 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 21 Oct 2015 12:48:52 +0200 Subject: Review request for JDK-8139931: Introduce Operation objects in Dynalink instead of string encoding In-Reply-To: <56261779.70903@oracle.com> References: <562600DE.2030907@oracle.com> <96C075DF-71A3-4260-AB7F-6F7B1517D2BB@oracle.com> <56261779.70903@oracle.com> Message-ID: Here?s an updated webrev, please review: I removed CompositeOperation.contains and containsAny operations and in Nashorn replaced their use with a new NashornCallSiteDescriptor.getFirstStandardOperation method; this allowed us to go back to using switch statement everywhere in linker logic where we were able to use it earlier, resulting in smaller diff and overall nicer code. Also, following a discussion with Hannes, we now enforce in CompositeOperation constructor that no components can themselves be either a CompositeOperation or a NamedOperation, and we enforce in NamedOperation that its base operation can?t itself be a NamedOperation. Thanks, Attila. > On Oct 20, 2015, at 12:29 PM, Sundararajan Athijegannathan wrote: > > +1 with changes. > > On final modifier: nothing specific comes to mind. We can leave it non-final... > > -Sundar > > On 10/20/2015 3:09 PM, Attila Szegedi wrote: >>> On Oct 20, 2015, at 10:52 AM, Sundararajan Athijegannathan wrote: >>> >>> * StandardOperation.java is missing copyright. >>> >>> * NamedOperation.java is missing copyright. >>> >>> * CompositeOperation.java is missing copyright. >> Indeed; added copyrights. >> >>> * Can CompositeOperation be final? >> Well, it?s hard to see why would someone want to subclass it, but I also don?t really see why someone shouldn?t be able to do it, to maybe add some language-specific information and still have it be recognized externally as CompositeOperation. (Same reasoning goes for NamedOperation, I guess). Do you have an rationale for making it final? >> >>> * Unrelated ArrayData change? Unused method? >> Yes. I was following a change in the parameter type from String to Operation and stumbled upon it. >> >>> * NashornCallSiteDescriptor may have explanation as to why 18 bits are sufficient for "program point" [now that flag bits are used for encoding operation enums as well] >> I agree, I added an explanation. >> >>> That's all I could find... >>> >>> +1 >>> >>> -Sundar >>> >>> On 10/20/2015 1:41 PM, Attila Szegedi wrote: >>>> Please review JDK-8139931 "Introduce Operation objects in Dynalink instead of string encoding" at for >>>> >>>> This is admittedly a big one. It is also the last in the pipeline of the internal Dynalink cleanups, so we?ve reached the end of that! >>>> >>>> Thanks, >>>> Attila. > From sundararajan.athijegannathan at oracle.com Wed Oct 21 10:50:36 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 21 Oct 2015 16:20:36 +0530 Subject: RFR 8140235: Clean up dynamic module creation in jake/nashorn Message-ID: <56276DFC.8010103@oracle.com> Hi, Please review http://cr.openjdk.java.net/~sundar/8140235/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8140235 Thanks, -Sundar From sundararajan.athijegannathan at oracle.com Wed Oct 21 11:13:50 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 21 Oct 2015 16:43:50 +0530 Subject: Review request for JDK-8139931: Introduce Operation objects in Dynalink instead of string encoding In-Reply-To: References: <562600DE.2030907@oracle.com> <96C075DF-71A3-4260-AB7F-6F7B1517D2BB@oracle.com> <56261779.70903@oracle.com> Message-ID: <5627736E.3050501@oracle.com> Using enums instead of Strings makes much better reading! Nice! * File: NamedOperation.java doc comment: gettng -> getting * File: AbstractJavaLinker.java + List operations = Arrays.asList( final missing? +1 -Sundar On 10/21/2015 4:18 PM, Attila Szegedi wrote: > Here?s an updated webrev, please review: > > I removed CompositeOperation.contains and containsAny operations and in Nashorn replaced their use with a new NashornCallSiteDescriptor.getFirstStandardOperation method; this allowed us to go back to using switch statement everywhere in linker logic where we were able to use it earlier, resulting in smaller diff and overall nicer code. > > Also, following a discussion with Hannes, we now enforce in CompositeOperation constructor that no components can themselves be either a CompositeOperation or a NamedOperation, and we enforce in NamedOperation that its base operation can?t itself be a NamedOperation. > > Thanks, > Attila. > >> On Oct 20, 2015, at 12:29 PM, Sundararajan Athijegannathan wrote: >> >> +1 with changes. >> >> On final modifier: nothing specific comes to mind. We can leave it non-final... >> >> -Sundar >> >> On 10/20/2015 3:09 PM, Attila Szegedi wrote: >>>> On Oct 20, 2015, at 10:52 AM, Sundararajan Athijegannathan wrote: >>>> >>>> * StandardOperation.java is missing copyright. >>>> >>>> * NamedOperation.java is missing copyright. >>>> >>>> * CompositeOperation.java is missing copyright. >>> Indeed; added copyrights. >>> >>>> * Can CompositeOperation be final? >>> Well, it?s hard to see why would someone want to subclass it, but I also don?t really see why someone shouldn?t be able to do it, to maybe add some language-specific information and still have it be recognized externally as CompositeOperation. (Same reasoning goes for NamedOperation, I guess). Do you have an rationale for making it final? >>> >>>> * Unrelated ArrayData change? Unused method? >>> Yes. I was following a change in the parameter type from String to Operation and stumbled upon it. >>> >>>> * NashornCallSiteDescriptor may have explanation as to why 18 bits are sufficient for "program point" [now that flag bits are used for encoding operation enums as well] >>> I agree, I added an explanation. >>> >>>> That's all I could find... >>>> >>>> +1 >>>> >>>> -Sundar >>>> >>>> On 10/20/2015 1:41 PM, Attila Szegedi wrote: >>>>> Please review JDK-8139931 "Introduce Operation objects in Dynalink instead of string encoding" at for >>>>> >>>>> This is admittedly a big one. It is also the last in the pipeline of the internal Dynalink cleanups, so we?ve reached the end of that! >>>>> >>>>> Thanks, >>>>> Attila. From attila.szegedi at oracle.com Wed Oct 21 11:35:42 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 21 Oct 2015 13:35:42 +0200 Subject: RFR 8140235: Clean up dynamic module creation in jake/nashorn In-Reply-To: <56276DFC.8010103@oracle.com> References: <56276DFC.8010103@oracle.com> Message-ID: +1 > On Oct 21, 2015, at 12:50 PM, Sundararajan Athijegannathan wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8140235/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8140235 > > Thanks, > -Sundar From attila.szegedi at oracle.com Wed Oct 21 12:21:47 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 21 Oct 2015 14:21:47 +0200 Subject: Review request for JDK-8139931: Introduce Operation objects in Dynalink instead of string encoding In-Reply-To: <5627736E.3050501@oracle.com> References: <562600DE.2030907@oracle.com> <96C075DF-71A3-4260-AB7F-6F7B1517D2BB@oracle.com> <56261779.70903@oracle.com> <5627736E.3050501@oracle.com> Message-ID: <580CB0DC-ABCD-467B-BD38-DA28CE14279F@oracle.com> > On Oct 21, 2015, at 1:13 PM, Sundararajan Athijegannathan wrote: > > Using enums instead of Strings makes much better reading! Nice! Thanks! > > * File: NamedOperation.java > > doc comment: gettng -> getting Fixed. > > * File: AbstractJavaLinker.java > > + List operations = Arrays.asList( > > final missing? No, it?s reassigned in the loop below. > > +1 > > -Sundar > > On 10/21/2015 4:18 PM, Attila Szegedi wrote: >> Here?s an updated webrev, please review: >> >> I removed CompositeOperation.contains and containsAny operations and in Nashorn replaced their use with a new NashornCallSiteDescriptor.getFirstStandardOperation method; this allowed us to go back to using switch statement everywhere in linker logic where we were able to use it earlier, resulting in smaller diff and overall nicer code. >> >> Also, following a discussion with Hannes, we now enforce in CompositeOperation constructor that no components can themselves be either a CompositeOperation or a NamedOperation, and we enforce in NamedOperation that its base operation can?t itself be a NamedOperation. >> >> Thanks, >> Attila. >> >>> On Oct 20, 2015, at 12:29 PM, Sundararajan Athijegannathan wrote: >>> >>> +1 with changes. >>> >>> On final modifier: nothing specific comes to mind. We can leave it non-final... >>> >>> -Sundar >>> >>> On 10/20/2015 3:09 PM, Attila Szegedi wrote: >>>>> On Oct 20, 2015, at 10:52 AM, Sundararajan Athijegannathan wrote: >>>>> >>>>> * StandardOperation.java is missing copyright. >>>>> >>>>> * NamedOperation.java is missing copyright. >>>>> >>>>> * CompositeOperation.java is missing copyright. >>>> Indeed; added copyrights. >>>> >>>>> * Can CompositeOperation be final? >>>> Well, it?s hard to see why would someone want to subclass it, but I also don?t really see why someone shouldn?t be able to do it, to maybe add some language-specific information and still have it be recognized externally as CompositeOperation. (Same reasoning goes for NamedOperation, I guess). Do you have an rationale for making it final? >>>> >>>>> * Unrelated ArrayData change? Unused method? >>>> Yes. I was following a change in the parameter type from String to Operation and stumbled upon it. >>>> >>>>> * NashornCallSiteDescriptor may have explanation as to why 18 bits are sufficient for "program point" [now that flag bits are used for encoding operation enums as well] >>>> I agree, I added an explanation. >>>> >>>>> That's all I could find... >>>>> >>>>> +1 >>>>> >>>>> -Sundar >>>>> >>>>> On 10/20/2015 1:41 PM, Attila Szegedi wrote: >>>>>> Please review JDK-8139931 "Introduce Operation objects in Dynalink instead of string encoding" at for >>>>>> >>>>>> This is admittedly a big one. It is also the last in the pipeline of the internal Dynalink cleanups, so we?ve reached the end of that! >>>>>> >>>>>> Thanks, >>>>>> Attila. > From marcus at lagergren.net Wed Oct 21 12:31:25 2015 From: marcus at lagergren.net (Marcus Lagergren) Date: Wed, 21 Oct 2015 14:31:25 +0200 Subject: RFR 8140235: Clean up dynamic module creation in jake/nashorn In-Reply-To: <56276DFC.8010103@oracle.com> References: <56276DFC.8010103@oracle.com> Message-ID: +1 > On 21 Oct 2015, at 12:50, Sundararajan Athijegannathan wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8140235/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8140235 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Wed Oct 21 13:02:04 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 21 Oct 2015 15:02:04 +0200 Subject: Review request for JDK-8139931: Introduce Operation objects in Dynalink instead of string encoding In-Reply-To: References: <562600DE.2030907@oracle.com> <96C075DF-71A3-4260-AB7F-6F7B1517D2BB@oracle.com> <56261779.70903@oracle.com> Message-ID: <56278CCC.1080803@oracle.com> Very nice that we can keep using switch statements! +1 Hannes Am 2015-10-21 um 12:48 schrieb Attila Szegedi: > Here?s an updated webrev, please review: > > I removed CompositeOperation.contains and containsAny operations and in Nashorn replaced their use with a new NashornCallSiteDescriptor.getFirstStandardOperation method; this allowed us to go back to using switch statement everywhere in linker logic where we were able to use it earlier, resulting in smaller diff and overall nicer code. > > Also, following a discussion with Hannes, we now enforce in CompositeOperation constructor that no components can themselves be either a CompositeOperation or a NamedOperation, and we enforce in NamedOperation that its base operation can?t itself be a NamedOperation. > > Thanks, > Attila. > >> On Oct 20, 2015, at 12:29 PM, Sundararajan Athijegannathan wrote: >> >> +1 with changes. >> >> On final modifier: nothing specific comes to mind. We can leave it non-final... >> >> -Sundar >> >> On 10/20/2015 3:09 PM, Attila Szegedi wrote: >>>> On Oct 20, 2015, at 10:52 AM, Sundararajan Athijegannathan wrote: >>>> >>>> * StandardOperation.java is missing copyright. >>>> >>>> * NamedOperation.java is missing copyright. >>>> >>>> * CompositeOperation.java is missing copyright. >>> Indeed; added copyrights. >>> >>>> * Can CompositeOperation be final? >>> Well, it?s hard to see why would someone want to subclass it, but I also don?t really see why someone shouldn?t be able to do it, to maybe add some language-specific information and still have it be recognized externally as CompositeOperation. (Same reasoning goes for NamedOperation, I guess). Do you have an rationale for making it final? >>> >>>> * Unrelated ArrayData change? Unused method? >>> Yes. I was following a change in the parameter type from String to Operation and stumbled upon it. >>> >>>> * NashornCallSiteDescriptor may have explanation as to why 18 bits are sufficient for "program point" [now that flag bits are used for encoding operation enums as well] >>> I agree, I added an explanation. >>> >>>> That's all I could find... >>>> >>>> +1 >>>> >>>> -Sundar >>>> >>>> On 10/20/2015 1:41 PM, Attila Szegedi wrote: >>>>> Please review JDK-8139931 "Introduce Operation objects in Dynalink instead of string encoding" at for >>>>> >>>>> This is admittedly a big one. It is also the last in the pipeline of the internal Dynalink cleanups, so we?ve reached the end of that! >>>>> >>>>> Thanks, >>>>> Attila. From Alan.Bateman at oracle.com Wed Oct 21 14:15:03 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 21 Oct 2015 15:15:03 +0100 Subject: RFR 8140235: Clean up dynamic module creation in jake/nashorn In-Reply-To: <56276DFC.8010103@oracle.com> References: <56276DFC.8010103@oracle.com> Message-ID: <56279DE7.2000901@oracle.com> On 21/10/2015 11:50, Sundararajan Athijegannathan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8140235/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8140235 This looks okay to me. -Alan From tal.liron at threecrickets.com Wed Oct 21 18:38:12 2015 From: tal.liron at threecrickets.com (Tal Liron) Date: Wed, 21 Oct 2015 13:38:12 -0500 Subject: Developer API docs In-Reply-To: <56206771.1040308@oracle.com> References: <559844B1.60409@threecrickets.com> <559A0214.8040502@oracle.com> <559A19A3.4090008@threecrickets.com> <9AC00CD0-2210-4934-88A7-6120BDAF5841@oracle.com> <559B3526.2010802@threecrickets.com> <561FD98F.1060803@threecrickets.com> <56206771.1040308@oracle.com> Message-ID: <5627DB94.6090103@threecrickets.com> Thank you for your reply, Sundar. Unfortunately, your suggestions are insufficient. In the BSON translator, I do not have access to the script engine at all. It might not even be created: after all, the BSON translator can be invoked by Nashorn directly, not in JSR-223 mode. Likewise, you have not addressed much more of what I write about: access to Script, Source, Context, etc. I understand that you do not want to have to support internal APIs. I merely wanted to prove to you that there is a cost in doing so: many powerful things can only be achieved by access to those APIs. This means that various 3rd party products might break with newer versions of Nashorn. This is not the end of the world: many libraries, of course, break dependent products, even in regards to public APIs. Still, I hope you can read my original email in depth and think more about what I'm trying to do. Perhaps you will agree that some of those APIs could benefit from being public, or suggest other solutions for me. On my end, I will continue to maintain my code as is, even if it uses internal APIs, because it allows me to use Nashorn for some very cool projects. -Tal On 10/15/2015 09:56 PM, Sundararajan Athijegannathan wrote: > Hi Tal Liron, > > Sorry about missing reply for this email. I somehow remember replying > similar nashorn internal usage email. > It is difficult maintain all of jdk.nashorn.internal.* between > versions. Also, with security manager around, jdk.nashorn.internal.* > are not accessible without explicit 'package access' > RuntimePermission. In addition, with jdk9, nashorn module exports only > jdk.nashorn.api.* packages. i.e., even without any security manager, > user code won't be able to access nashorn internal implementation > classes. It is possible to use jdk.nashorn.api.scripting.JSObject to > get constructors and create objecs. > > JSObject numberConstructor = (JSObject) engine.eval("Number"); > JSObject numberObj = numberConstructor.newObject(); > > Is it not possible to work with these? Please check out latest 8u-dev > code. Mostly explicit wrap/unwrap won't be required from user's code. > > Thanks, > -Sundar > > On 10/15/2015 10:21 PM, Tal Liron wrote: >> Hey guys, nobody ever responded to my message... >> >> Do you really think that my usage of these internal Nashorn APIs is >> so unwarranted? >> >> I tried to prove that some useful libraries need to use Nashorn APIs >> that some of you insist should not be made public. >> >> On 07/06/2015 09:10 PM, Tal Liron wrote: >>> Hi Atilla (and Sundar and everyone else, really), >>> >>> You asked which Nashorn APIs I'm using that are not documented. I >>> will reply in full detail. >>> >>> For the BSON/JSON codecs, the most important thing is to access the >>> NativeBoolean, NativeNumber, NativeArray, ConsString, Undefined, >>> etc., classes. This allows the codecs to check for these classes >>> incoming, and also to easily create instances of them using their >>> constructor() static method. >>> >>> ScriptObject has no constructor(), so I use >>> Global.newEmptyInstance(). (By the way: NativeDate and NativeArray >>> name the method construct() instead of constructor(). I assume this >>> is a consistency mistake.) >>> >>> But I also need to access their data. This means get()/set() for >>> NativeScriptObject and NativeArray, getOwnKeys(), getArray() (which >>> means I need access to the ArrayData class), and also getTime() for >>> NativeData. NativeRegExp is a bit harder, but I use get("source"), >>> get("multiline"), etc. >>> >>> (In Rhino, some of these classes are actually private! This required >>> an awkward workaround: I do a string equality check on the >>> classname. That's neither efficient nor portable, though more >>> "dynamic", I guess. Also, for these classes I can use >>> Context.newObject() to create instances by JS name, for example >>> "RegExp". Then I can do ScriptableObject.callMethod() to access >>> their internals. So, there are workarounds to not being to able to >>> access them.) >>> >>> ScriptObjectMirror is awkward. Though it's stable and documented, >>> the issue with unwrap() is that it needs a global. Documented, but >>> of course unclear what to do! For me, this actually means calling >>> Context.getGlobal(), which is not publicly documented. (Another >>> issue is that, of course, unwrap won't work for other globals. This >>> has created difficulties in some threaded environments in which >>> multiple globals are used intentionally. More on that below.) >>> >>> So much for BSON/JSON. The Scripturian implementation of Nashorn is >>> much more complex. As you may know, Scripturian is a rethinking of >>> and alternative to JSR-223, so it has to do much of the same work. >>> >>> Scripturian works by purposely creating different global instances >>> for each "execution context" (which *can* be a thread, but doesn't >>> have to be: it's an abstraction over, well, execution contexts). I >>> use Context.createGlobal(), and set it via Context.setGlobal(). >>> >>> We then need to compile scripts in the Context, so I use >>> Source.sourceFor() and Context.compileScript(), which returns a >>> ScriptFunction, so I also need access to that. Compilations errors >>> are via Context.getErrorManager(), so I need access to ErrorManager. >>> To run the scripts, I use ScriptRuntime.apply(). A small fix I need >>> to add is that Nashorn's NativeArray does not support >>> java.util.List, so if an array is returned from apply(), I call >>> NativeJava.to() to get list access. Thats's just a bit friendlier >>> for users of Scripturian, who are otherwise agnostic about >>> implementation specifics. >>> >>> There's an important issue here: remember, there might be many >>> different globals, but of course I want them all to use the same >>> code cache, which is stored in the Context. So, I use one singleton >>> Context and switch globals via Context.setGlobal(). To create a >>> Context, I also need access to Options. A limitation in Nashorn is >>> that I can't change stdout and stderr after I create the Context >>> (Scripturian allows different onces per ExecutionContext), so my >>> workaround is to use a custom Writer wrapper class that underneath >>> delegates to the correct "real" Writers (I use the same mechanism >>> for a few other Scripturian language engines, too). >>> >>> I grumbled here before that I have no programmatic access to the >>> code cache. Behind the scenes, ScriptFunction might retrieve from >>> the cache instead of being compiled. I can control the cache base >>> location via the "nashorn.persistent.code.cache" system property, >>> but it's unfortunate that I can't control the structure and naming >>> the way I can with other languages supported by Scripturian. In >>> particular, the problem is that it's a global property for the whole >>> JVM, whereas compilation and caching location is ideally controlled >>> per ExecutionContext in Scripturian. This makes Nashorn support in >>> Scripturian a bit more limited. >>> >>> Finally, for errors during execution, I use NashornException >>> (documented!) to extract specific information into Scripturian's >>> more generic ExecutionException. >>> >>> Small extras: I use Version.version() and >>> NashornScriptEngineFactory.getLanguageVersion() to get version data. >>> >>> I think that's everything! Of course, I also had to "reverse >>> engineer" much of this (=read a lot of code) and work around many >>> quirks (and big differences to Rhino's implementation) before >>> streamlining it down to just these few classes. (I tried to work >>> around the caching limitations, but gave up due to its complexity. >>> Also, I think some of the key classes I would need are private.) I >>> did my best not to delve to much into internals, but I hope I made >>> it clear to you that it would have been impossible to achieve all >>> the above goals without it. >>> >>> -Tal >>> >>> On 07/06/2015 04:18 AM, Attila Szegedi wrote: >>>> What APIs are you using, BTW? Just curious if I can suggest an >>>> alternative approach, or even consider if something you use should >>>> be publicly supported. >>> >> > From attila.szegedi at oracle.com Wed Oct 21 21:32:36 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 21 Oct 2015 23:32:36 +0200 Subject: Review request for JDK-8140273: restore use of CompositeOperation.contains where it is needed Message-ID: Please review JDK-8140273 "restore use of CompositeOperation.contains where it is needed" at for I also snuck in a previously forgotten JavaDoc fix for DynamicLinker. Thanks, Attila. From sundararajan.athijegannathan at oracle.com Thu Oct 22 04:07:36 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 22 Oct 2015 09:37:36 +0530 Subject: Review request for JDK-8140273: restore use of CompositeOperation.contains where it is needed In-Reply-To: References: Message-ID: <56286108.8070705@oracle.com> Please add appropriate label to the bug to say "no reg test" [as this is to fix a test failure]. +1 -Sundar On 10/22/2015 3:02 AM, Attila Szegedi wrote: > Please review JDK-8140273 "restore use of CompositeOperation.contains where it is needed" at for > > I also snuck in a previously forgotten JavaDoc fix for DynamicLinker. > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Thu Oct 22 07:41:36 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 22 Oct 2015 09:41:36 +0200 Subject: Review request for JDK-8140273: restore use of CompositeOperation.contains where it is needed In-Reply-To: References: Message-ID: <56289330.2040604@oracle.com> +1 Am 2015-10-21 um 23:32 schrieb Attila Szegedi: > Please review JDK-8140273 "restore use of CompositeOperation.contains where it is needed" at for > > I also snuck in a previously forgotten JavaDoc fix for DynamicLinker. > > Thanks, > Attila. From attila.szegedi at oracle.com Fri Oct 23 09:28:42 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 23 Oct 2015 11:28:42 +0200 Subject: RFR 8134941: Implement ES6 template literal support In-Reply-To: <56040C69.7010903@oracle.com> References: <55E87A0D.8020608@oracle.com> <56040C69.7010903@oracle.com> Message-ID: <353AE58A-CA53-45C5-9B27-19BD8408F2FA@oracle.com> +1 from me as well. Another apology from me for having to wait even more for the second review. Very nice work. I?m sometimes in two minds about RuntimeNode (especially the fact that it currently can?t receive primitive parameters), but I have to admit that in this particular case it made the integration of the feature into the runtime fairly easy; it was really the parser parts that were tricky. Attila. > On Sep 24, 2015, at 4:44 PM, Hannes Wallnoefer wrote: > > Hi Andreas, > > Thanks for the contribution, and sorry for the long time it took to get back to you. > > I like the way you implemented this feature, the code looks very good. Comments inlined below. > > Am 2015-09-03 um 18:49 schrieb Andreas Woess: >> Template literals are always scanned as a whole, quote-to-quote (as with EditStringLexer). This turned out to be a problem with embedded functions in expressions and lazy/optimistic compilation on: Parser#skipFunctionBody would skip over the body and restart lexing at the RBRACE, forgetting about the embedding string context. I've worked around this in skipFunctionBody by skipping over to the RBRACE directly if it is already in the token stream (which it is because we've already scanned to the end quote). > > It took me some time to figure this out. Maybe some more explanatory comments would be good. Does this also apply in other cases? > >> >> Outstanding correctness issues not dealt with: >> * 12.2.9.3 GetTemplateObject stipulates that the returned template object be cached and unique. I don't know why you'd want the spec to demand caching rather than allow it (functionally it does not make a difference, but you could observe it not being cached in a test). > > Actually object identity can be observed by the tag function, and that was the reason for the committee to specify this. They chose caching of objects for performance reasons. The discussion can be found here: > > https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-11/nov-18.md#48-template-literal-call-site-object-caching > > Even though it's a minor issue we should follow the spec here. > >> * 12.2.9.5 Evaluation: string concatenation using + is slightly off-spec. There are two way to solve this: (a) wrap the expressions in a ToString UnaryExpression (or RuntimeCall) or (b) generate a call to concat with interleaved string and expression arguments. >> > > The difference is between ToPrimitive being called with Number hint vs. String hint. This should not make a difference for the vast share of objects (all except those having a custom valueOf function I think), but it's something we should also get right. I've started experimenting with the solutions you suggested, I think adding a ToString conversion wrapper of some kind would be best. > > All in all I think your patch looks good. We can probably file the issues as separate bugs and fix them later. One thing I want to do is add some more tests. Although your test script covers a lot of stuff (for its size) I would like to add a bit to it. > > Thanks, > Hannes > > > > > From vpasquier at nuxeo.com Tue Oct 27 14:11:56 2015 From: vpasquier at nuxeo.com (Vladimir Pasquier) Date: Tue, 27 Oct 2015 10:11:56 -0400 Subject: Stdout Option Message-ID: Hello, I'm sorry I couldn't search in the nashorn-dev at openjdk.java.net archives if the subject has popped up during some discussions, so I let myself to write you to get some informations about Options in general in Nashorn and especially the redirection of Javascript console output to some files. Here we have the option --stdout: return nashornScriptEngineFactory.getScriptEngine(new String[] { "-strict", "--persistent-code-cache", "--class-cache-size=50", "--stdout=\"nx-nashorn.log\"" }, null, new AutomationScriptingClassFilter()); But I cannot see the nx-nashorn.log creation anywhere. Could it be possible to have examples for all of those options in general? Thank you a lot for the work on Nashorn we use it massively! -- Vladimir Pasquier Nuxeo Dev nuxeo.com [image: www.nuxeo.com - Content Management Platform] From james.falkner at liferay.com Tue Oct 27 23:48:46 2015 From: james.falkner at liferay.com (James Falkner) Date: Tue, 27 Oct 2015 16:48:46 -0700 Subject: Parameterized Types Message-ID: <56300D5E.4040108@liferay.com> Hey all, Currently @ JavaOne enjoying the Nashorn talks. But I have a question. Is it possible to create extended classes using parameterized types? What I want to do is create these: class SomeClass extends SomeBaseClass { ... } I know parameterized types are mostly a compile-time thing, but they are encoded into the class bytes and can be accessed in Java using: ParameterizedType t = (ParameterizedType) clazz.getGenericSuperclass(); Type[] types = parameterizedType.getActualTypeArguments(); So I was wondering if it was possible to instantiate a concrete Java class from Javascript such that it would appear just as though I had created it as above? Using Java.type() and Java.extend() doesn't seem to create the class in the same way as the Java code with Parameterized types. Thanks! -James From mitiaalexandrov at gmail.com Wed Oct 28 00:59:14 2015 From: mitiaalexandrov at gmail.com (Mitia Alexandrov) Date: Tue, 27 Oct 2015 17:59:14 -0700 Subject: Parameterized Types In-Reply-To: <56300D5E.4040108@liferay.com> References: <56300D5E.4040108@liferay.com> Message-ID: yep... and may be some how introduce annotations support... 2015-10-27 16:48 GMT-07:00 James Falkner : > Hey all, > > Currently @ JavaOne enjoying the Nashorn talks. But I have a question. Is > it possible to create extended classes using parameterized types? > > What I want to do is create these: > > class SomeClass extends SomeBaseClass { > ... > } > > I know parameterized types are mostly a compile-time thing, but they are > encoded into the class bytes and can be accessed in Java using: > > ParameterizedType t = (ParameterizedType) clazz.getGenericSuperclass(); > Type[] types = parameterizedType.getActualTypeArguments(); > > So I was wondering if it was possible to instantiate a concrete Java class > from Javascript such that it would appear just as though I had created it > as above? > > Using Java.type() and Java.extend() doesn't seem to create the class in > the same way as the Java code with Parameterized types. Thanks! > > -James > > From tal.liron at threecrickets.com Wed Oct 28 01:10:23 2015 From: tal.liron at threecrickets.com (Tal Liron) Date: Tue, 27 Oct 2015 20:10:23 -0500 Subject: Parameterized Types In-Reply-To: <56300D5E.4040108@liferay.com> References: <56300D5E.4040108@liferay.com> Message-ID: <5630207F.1000700@threecrickets.com> You answered your own question: the Java compiler "erases" these types, so they are not available to you. It's purely a Java compiler feature, not part of the JVM. However, JavaScript can provide a workaround. Just create your own wrapper (a JavaScript dict) that includes custom type information: var myList = {}; myList.list = new java.util.ArrayList(); myList.type = String; You can then can create JavaScript functions that check for the type and then delegate to this.list: myList.add = function(value) { if (!(value instanceof this.type) throw 'Wrong!'; this.list.add(value); } Note that if you want to use JavaScript (as opposed to JVM) types, you must explicitly use their constructor: myList.add(new String('this will work')) myLast.add('this won't work') On 10/27/2015 06:48 PM, James Falkner wrote: > Hey all, > > Currently @ JavaOne enjoying the Nashorn talks. But I have a question. > Is it possible to create extended classes using parameterized types? > > What I want to do is create these: > > class SomeClass extends SomeBaseClass { > ... > } > > I know parameterized types are mostly a compile-time thing, but they > are encoded into the class bytes and can be accessed in Java using: > > ParameterizedType t = (ParameterizedType) clazz.getGenericSuperclass(); > Type[] types = parameterizedType.getActualTypeArguments(); > > So I was wondering if it was possible to instantiate a concrete Java > class from Javascript such that it would appear just as though I had > created it as above? > > Using Java.type() and Java.extend() doesn't seem to create the class > in the same way as the Java code with Parameterized types. Thanks! > > -James > From hannes.wallnoefer at oracle.com Wed Oct 28 07:46:48 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 28 Oct 2015 08:46:48 +0100 Subject: Stdout Option In-Reply-To: References: Message-ID: <56307D68.1040900@oracle.com> Hi Vladimir, I haven't used this option myself, and looking at the code it seems like --stdout and --stderr are not supported anymore. I'm not entirely shure about this. I'll check with the team and get back to you. Hannes Am 2015-10-27 um 15:11 schrieb Vladimir Pasquier: > Hello, > > I'm sorry I couldn't search in the nashorn-dev at openjdk.java.net archives if > the subject has popped up during some discussions, so I let myself to write > you to get some informations about Options in general in Nashorn and > especially the redirection of Javascript console output to some files. > > Here we have the option --stdout: > > return nashornScriptEngineFactory.getScriptEngine(new String[] { > "-strict", "--persistent-code-cache", > "--class-cache-size=50", "--stdout=\"nx-nashorn.log\"" }, > null, new AutomationScriptingClassFilter()); > > But I cannot see the nx-nashorn.log creation anywhere. > > Could it be possible to have examples for all of those options > > in general? > > Thank you a lot for the work on Nashorn we use it massively! From michael.haupt at oracle.com Wed Oct 28 10:08:41 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 28 Oct 2015 11:08:41 +0100 Subject: RFR 8134941: Implement ES6 template literal support In-Reply-To: <353AE58A-CA53-45C5-9B27-19BD8408F2FA@oracle.com> References: <55E87A0D.8020608@oracle.com> <56040C69.7010903@oracle.com> <353AE58A-CA53-45C5-9B27-19BD8408F2FA@oracle.com> Message-ID: <37059C37-3313-4007-A0F1-5F05C4874E89@oracle.com> Hi all, excellent - I'll sponsor the change. Best, Michael > Am 23.10.2015 um 11:28 schrieb Attila Szegedi : > > +1 from me as well. Another apology from me for having to wait even more for the second review. > > Very nice work. I?m sometimes in two minds about RuntimeNode (especially the fact that it currently can?t receive primitive parameters), but I have to admit that in this particular case it made the integration of the feature into the runtime fairly easy; it was really the parser parts that were tricky. > > Attila. > >> On Sep 24, 2015, at 4:44 PM, Hannes Wallnoefer wrote: >> >> Hi Andreas, >> >> Thanks for the contribution, and sorry for the long time it took to get back to you. >> >> I like the way you implemented this feature, the code looks very good. Comments inlined below. >> >> Am 2015-09-03 um 18:49 schrieb Andreas Woess: >>> Template literals are always scanned as a whole, quote-to-quote (as with EditStringLexer). This turned out to be a problem with embedded functions in expressions and lazy/optimistic compilation on: Parser#skipFunctionBody would skip over the body and restart lexing at the RBRACE, forgetting about the embedding string context. I've worked around this in skipFunctionBody by skipping over to the RBRACE directly if it is already in the token stream (which it is because we've already scanned to the end quote). >> >> It took me some time to figure this out. Maybe some more explanatory comments would be good. Does this also apply in other cases? >> >>> >>> Outstanding correctness issues not dealt with: >>> * 12.2.9.3 GetTemplateObject stipulates that the returned template object be cached and unique. I don't know why you'd want the spec to demand caching rather than allow it (functionally it does not make a difference, but you could observe it not being cached in a test). >> >> Actually object identity can be observed by the tag function, and that was the reason for the committee to specify this. They chose caching of objects for performance reasons. The discussion can be found here: >> >> https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-11/nov-18.md#48-template-literal-call-site-object-caching >> >> Even though it's a minor issue we should follow the spec here. >> >>> * 12.2.9.5 Evaluation: string concatenation using + is slightly off-spec. There are two way to solve this: (a) wrap the expressions in a ToString UnaryExpression (or RuntimeCall) or (b) generate a call to concat with interleaved string and expression arguments. >>> >> >> The difference is between ToPrimitive being called with Number hint vs. String hint. This should not make a difference for the vast share of objects (all except those having a custom valueOf function I think), but it's something we should also get right. I've started experimenting with the solutions you suggested, I think adding a ToString conversion wrapper of some kind would be best. >> >> All in all I think your patch looks good. We can probably file the issues as separate bugs and fix them later. One thing I want to do is add some more tests. Although your test script covers a lot of stuff (for its size) I would like to add a bit to it. >> >> Thanks, >> Hannes -- 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 michael.haupt at oracle.com Thu Oct 29 10:22:35 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 29 Oct 2015 11:22:35 +0100 Subject: RFR(S): 8140759: add ES6 template literal test Message-ID: <956DAF90-4980-4294-A682-79049A234CC7@oracle.com> Dear all, please review this change. Issue: https://bugs.openjdk.java.net/browse/JDK-8140759 Webrev: http://cr.openjdk.java.net/~mhaupt/8140759/webrev.00 In preparing the push of ES6 template literal support yesterday, I forgot to add the test files. Sorry about that. Best, 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 hannes.wallnoefer at oracle.com Thu Oct 29 10:22:25 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 29 Oct 2015 11:22:25 +0100 Subject: RFR(S): 8140759: add ES6 template literal test In-Reply-To: <956DAF90-4980-4294-A682-79049A234CC7@oracle.com> References: <956DAF90-4980-4294-A682-79049A234CC7@oracle.com> Message-ID: <5631F361.8020505@oracle.com> +1 Am 2015-10-29 um 11:22 schrieb Michael Haupt: > Dear all, > > please review this change. > Issue: https://bugs.openjdk.java.net/browse/JDK-8140759 > Webrev: http://cr.openjdk.java.net/~mhaupt/8140759/webrev.00 > > In preparing the push of ES6 template literal support yesterday, I forgot to add the test files. Sorry about that. > > Best, > > Michael > From sundararajan.athijegannathan at oracle.com Thu Oct 29 10:23:51 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 29 Oct 2015 15:53:51 +0530 Subject: RFR(S): 8140759: add ES6 template literal test In-Reply-To: <956DAF90-4980-4294-A682-79049A234CC7@oracle.com> References: <956DAF90-4980-4294-A682-79049A234CC7@oracle.com> Message-ID: <5631F3B7.4040609@oracle.com> +1 On 10/29/2015 3:52 PM, Michael Haupt wrote: > Dear all, > > please review this change. > Issue: https://bugs.openjdk.java.net/browse/JDK-8140759 > Webrev: http://cr.openjdk.java.net/~mhaupt/8140759/webrev.00 > > In preparing the push of ES6 template literal support yesterday, I forgot to add the test files. Sorry about that. > > Best, > > Michael >