From srinivas.dama at oracle.com Wed Jul 12 09:00:58 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Wed, 12 Jul 2017 02:00:58 -0700 (PDT) Subject: RFR: 8184239(Fix broken nashorn/samples) Message-ID: Hi, Please review http://cr.openjdk.java.net/~sdama/8184239/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184239 Regards, Srinivas From sundararajan.athijegannathan at oracle.com Wed Jul 12 09:10:25 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 12 Jul 2017 14:40:25 +0530 Subject: RFR: 8184239(Fix broken nashorn/samples) In-Reply-To: References: Message-ID: <5965E781.8070303@oracle.com> +1 -Sundar On 12/07/17, 2:30 PM, Srinivas Dama wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8184239/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184239 > > Regards, > Srinivas From hannes.wallnoefer at oracle.com Wed Jul 12 09:28:41 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 12 Jul 2017 11:28:41 +0200 Subject: RFR: 8184239(Fix broken nashorn/samples) In-Reply-To: <5965E781.8070303@oracle.com> References: <5965E781.8070303@oracle.com> Message-ID: <48C3ABA2-E3A5-4031-93AC-F45374F91969@oracle.com> +1 Hannes > Am 12.07.2017 um 11:10 schrieb Sundararajan Athijegannathan : > > +1 > > -Sundar > > On 12/07/17, 2:30 PM, Srinivas Dama wrote: >> Hi, >> >> Please review http://cr.openjdk.java.net/~sdama/8184239/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184239 >> >> Regards, >> Srinivas From james.laskey at oracle.com Wed Jul 12 12:03:33 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 12 Jul 2017 09:03:33 -0300 Subject: RFR: 8184239(Fix broken nashorn/samples) In-Reply-To: References: Message-ID: <27BCC276-9079-4409-AD51-838784AE43B0@oracle.com> +1 > On Jul 12, 2017, at 6:00 AM, Srinivas Dama wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8184239/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184239 > > Regards, > Srinivas From srinivas.dama at oracle.com Wed Jul 12 18:41:29 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Wed, 12 Jul 2017 11:41:29 -0700 (PDT) Subject: RFR: 8184239(Fix broken nashorn/samples) In-Reply-To: <27BCC276-9079-4409-AD51-838784AE43B0@oracle.com> References: <27BCC276-9079-4409-AD51-838784AE43B0@oracle.com> Message-ID: <8b386b64-131c-4649-9c1b-3d788f7c3cd3@default> Hi, Please review the updated patch. Sorry I missed one sample earlier. http://cr.openjdk.java.net/~sdama/8184239/webrev.01/ Regards, Srinivas -----Original Message----- From: Jim Laskey (Oracle) Sent: Wednesday, July 12, 2017 5:34 PM To: Srinivas Dama Cc: Nashorn-Dev Subject: Re: RFR: 8184239(Fix broken nashorn/samples) +1 > On Jul 12, 2017, at 6:00 AM, Srinivas Dama wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8184239/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184239 > > Regards, > Srinivas From james.laskey at oracle.com Wed Jul 12 19:18:20 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 12 Jul 2017 16:18:20 -0300 Subject: RFR: 8184239(Fix broken nashorn/samples) In-Reply-To: <8b386b64-131c-4649-9c1b-3d788f7c3cd3@default> References: <27BCC276-9079-4409-AD51-838784AE43B0@oracle.com> <8b386b64-131c-4649-9c1b-3d788f7c3cd3@default> Message-ID: +1 > On Jul 12, 2017, at 3:41 PM, Srinivas Dama wrote: > > Hi, > > Please review the updated patch. Sorry I missed one sample earlier. > http://cr.openjdk.java.net/~sdama/8184239/webrev.01/ > > Regards, > Srinivas > > -----Original Message----- > From: Jim Laskey (Oracle) > Sent: Wednesday, July 12, 2017 5:34 PM > To: Srinivas Dama > Cc: Nashorn-Dev > Subject: Re: RFR: 8184239(Fix broken nashorn/samples) > > +1 > >> On Jul 12, 2017, at 6:00 AM, Srinivas Dama wrote: >> >> Hi, >> >> Please review http://cr.openjdk.java.net/~sdama/8184239/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184239 >> >> Regards, >> Srinivas > From sundararajan.athijegannathan at oracle.com Thu Jul 13 01:35:02 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 13 Jul 2017 07:05:02 +0530 Subject: RFR: 8184239(Fix broken nashorn/samples) In-Reply-To: <8b386b64-131c-4649-9c1b-3d788f7c3cd3@default> References: <27BCC276-9079-4409-AD51-838784AE43B0@oracle.com> <8b386b64-131c-4649-9c1b-3d788f7c3cd3@default> Message-ID: <5966CE46.9010402@oracle.com> +1 -Sundar On 13/07/17, 12:11 AM, Srinivas Dama wrote: > Hi, > > Please review the updated patch. Sorry I missed one sample earlier. > http://cr.openjdk.java.net/~sdama/8184239/webrev.01/ > > Regards, > Srinivas > > -----Original Message----- > From: Jim Laskey (Oracle) > Sent: Wednesday, July 12, 2017 5:34 PM > To: Srinivas Dama > Cc: Nashorn-Dev > Subject: Re: RFR: 8184239(Fix broken nashorn/samples) > > +1 > >> On Jul 12, 2017, at 6:00 AM, Srinivas Dama wrote: >> >> Hi, >> >> Please review http://cr.openjdk.java.net/~sdama/8184239/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184239 >> >> Regards, >> Srinivas From srinivas.dama at oracle.com Wed Jul 19 08:45:20 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Wed, 19 Jul 2017 01:45:20 -0700 (PDT) Subject: RFR: 8184241(Fix nashorn/samples/filebrowser.js) Message-ID: <6d511d85-0fcb-47c8-a81c-bc7c830e8581@default> Hi, Please review http://cr.openjdk.java.net/~sdama/8184241/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184241. Regards, Srinivas From hannes.wallnoefer at oracle.com Wed Jul 19 09:21:13 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 19 Jul 2017 11:21:13 +0200 Subject: RFR: 8184241(Fix nashorn/samples/filebrowser.js) In-Reply-To: <6d511d85-0fcb-47c8-a81c-bc7c830e8581@default> References: <6d511d85-0fcb-47c8-a81c-bc7c830e8581@default> Message-ID: <0B988C5E-D81F-4766-A389-78ACF76CCF2C@oracle.com> Hi Srini, The fix looks good, but what for is the arguments handling in the test? Also, I would prefer to use our own base class (constructor must invoke overridable method, what if TreeItem is refactored in the future?) Hannes > Am 19.07.2017 um 10:45 schrieb Srinivas Dama : > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8184241/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184241. > > Regards, > Srinivas From srinivas.dama at oracle.com Wed Jul 19 17:35:37 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Wed, 19 Jul 2017 10:35:37 -0700 (PDT) Subject: RFR: 8184241(Fix nashorn/samples/filebrowser.js) In-Reply-To: <0B988C5E-D81F-4766-A389-78ACF76CCF2C@oracle.com> References: <6d511d85-0fcb-47c8-a81c-bc7c830e8581@default> <0B988C5E-D81F-4766-A389-78ACF76CCF2C@oracle.com> Message-ID: <432dbe2d-1ff3-4d31-b476-ff525ba62b5e@default> Hi Hannes, Thank you for the comments. Here is the new patch using our own base class instead of TreeItem in test case. http://cr.openjdk.java.net/~sdama/8184241/webrev.02/ Regards, Srinivas -----Original Message----- From: Hannes Walln?fer Sent: Wednesday, July 19, 2017 2:51 PM To: Srinivas Dama Cc: Nashorn-Dev Subject: Re: RFR: 8184241(Fix nashorn/samples/filebrowser.js) Hi Srini, The fix looks good, but what for is the arguments handling in the test? Also, I would prefer to use our own base class (constructor must invoke overridable method, what if TreeItem is refactored in the future?) Hannes > Am 19.07.2017 um 10:45 schrieb Srinivas Dama : > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8184241/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184241. > > Regards, > Srinivas From james.laskey at oracle.com Wed Jul 19 17:37:41 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 19 Jul 2017 14:37:41 -0300 Subject: RFR: 8184241(Fix nashorn/samples/filebrowser.js) In-Reply-To: <6d511d85-0fcb-47c8-a81c-bc7c830e8581@default> References: <6d511d85-0fcb-47c8-a81c-bc7c830e8581@default> Message-ID: <3E6F5329-DB56-42EB-AA87-4157A6784AA5@oracle.com> Forgot. +1 > On Jul 19, 2017, at 5:45 AM, Srinivas Dama wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8184241/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184241. > > Regards, > Srinivas From hannes.wallnoefer at oracle.com Thu Jul 20 08:29:29 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 20 Jul 2017 10:29:29 +0200 Subject: RFR: 8184241(Fix nashorn/samples/filebrowser.js) In-Reply-To: <432dbe2d-1ff3-4d31-b476-ff525ba62b5e@default> References: <6d511d85-0fcb-47c8-a81c-bc7c830e8581@default> <0B988C5E-D81F-4766-A389-78ACF76CCF2C@oracle.com> <432dbe2d-1ff3-4d31-b476-ff525ba62b5e@default> Message-ID: Hi Srini, looks good! Hannes > Am 19.07.2017 um 19:35 schrieb Srinivas Dama : > > Hi Hannes, > Thank you for the comments. > > Here is the new patch using our own base class instead of TreeItem in test case. > http://cr.openjdk.java.net/~sdama/8184241/webrev.02/ > > Regards, > Srinivas > > -----Original Message----- > From: Hannes Walln?fer > Sent: Wednesday, July 19, 2017 2:51 PM > To: Srinivas Dama > Cc: Nashorn-Dev > Subject: Re: RFR: 8184241(Fix nashorn/samples/filebrowser.js) > > Hi Srini, > > The fix looks good, but what for is the arguments handling in the test? > > Also, I would prefer to use our own base class (constructor must invoke overridable method, what if TreeItem is refactored in the future?) > > Hannes > > >> Am 19.07.2017 um 10:45 schrieb Srinivas Dama : >> >> Hi, >> >> Please review http://cr.openjdk.java.net/~sdama/8184241/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184241. >> >> Regards, >> Srinivas > From marcus at lagergren.net Sun Jul 23 11:55:13 2017 From: marcus at lagergren.net (Marcus Lagergren) Date: Sun, 23 Jul 2017 13:55:13 +0200 Subject: RFR (10): JDK-8181191: getUint32 returning Long In-Reply-To: <124BFC78-108D-4C6A-961B-ED560EF80D9A@oracle.com> References: <4FEBF39E-2B92-47DB-9C42-4B5788230993@oracle.com> <63AC75E0-F5BB-4E0B-AB5D-045FFFE0A5D9@gmail.com> <124BFC78-108D-4C6A-961B-ED560EF80D9A@oracle.com> Message-ID: This cache thing is my least favourite behavior in the entire JLS. Crazy that it?s actually a mandated part of the language specification. +1 /M > On 13 Jun 2017, at 18:28, Hannes Walln?fer wrote: > > >> Am 13.06.2017 um 18:17 schrieb Attila Szegedi : >> >> the test described in the issue was failing because we treated Long objects as JS objects, right? >> > > Yes. 127 compared equal to itself because Long instances between -128 and 127 are cached, 128 is just outside that range. > > Thanks for the review! > Hannes > >> Attila. >> >>> On 13 Jun 2017, at 17:51, Hannes Walln?fer wrote: >>> >>> Please review: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181191 >>> Webrev: http://cr.openjdk.java.net/~hannesw/8181191/webrev/ >>> >>> Thanks, >>> Hannes >> > From forax at univ-mlv.fr Sun Jul 23 16:52:28 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 23 Jul 2017 16:52:28 +0000 Subject: RFR (10): JDK-8181191: getUint32 returning Long In-Reply-To: References: <4FEBF39E-2B92-47DB-9C42-4B5788230993@oracle.com> <63AC75E0-F5BB-4E0B-AB5D-045FFFE0A5D9@gmail.com> <124BFC78-108D-4C6A-961B-ED560EF80D9A@oracle.com> Message-ID: <0098DCC5-6DE0-4FDF-BACB-6DC047EFCB51@univ-mlv.fr> What about checked exceptions ? R?mi On July 23, 2017 1:55:13 PM GMT+02:00, Marcus Lagergren wrote: >This cache thing is my least favourite behavior in the entire JLS. >Crazy that it?s actually a mandated part of the language specification. > >+1 > >/M > >> On 13 Jun 2017, at 18:28, Hannes Walln?fer > wrote: >> >> >>> Am 13.06.2017 um 18:17 schrieb Attila Szegedi : >>> >>> the test described in the issue was failing because we treated Long >objects as JS objects, right? >>> >> >> Yes. 127 compared equal to itself because Long instances between -128 >and 127 are cached, 128 is just outside that range. >> >> Thanks for the review! >> Hannes >> >>> Attila. >>> >>>> On 13 Jun 2017, at 17:51, Hannes Walln?fer > wrote: >>>> >>>> Please review: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181191 >>>> Webrev: http://cr.openjdk.java.net/~hannesw/8181191/webrev/ >>>> >>>> Thanks, >>>> Hannes >>> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From hannes.wallnoefer at oracle.com Tue Jul 25 13:44:14 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 25 Jul 2017 15:44:14 +0200 Subject: [10] RFR: 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks Message-ID: Please review 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks Kraken benchmark contains some files that invokes the Array constructor with lots of number literal arguments. We assume too low code footprint for these number literals in WeighNodes.java, resulting in the function not being split. Bug: https://bugs.openjdk.java.net/browse/JDK-8184893 Webrev: http://cr.openjdk.java.net/~hannesw/8184893/webrev/ Thanks, Hannes From srinivas.dama at oracle.com Tue Jul 25 13:54:12 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Tue, 25 Jul 2017 06:54:12 -0700 (PDT) Subject: RFR: 8180727(Use jdk.editpad to replace jdk.nashorn.tools.jjs.EditPad duplicated class) Message-ID: <13264dbe-c245-49b9-a471-2403bc440f75@default> Hi, Please review http://cr.openjdk.java.net/~sdama/8180727/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8180727 Regards, Srinivas From srinivas.dama at oracle.com Tue Jul 25 15:55:59 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Tue, 25 Jul 2017 08:55:59 -0700 (PDT) Subject: [10] RFR: 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks In-Reply-To: References: Message-ID: <240ff8f5-86de-4e1e-80fe-0fded10696ba@default> Hi Hannes, Lower-case thumbs up. -----Original Message----- From: Hannes Walln?fer Sent: Tuesday, July 25, 2017 7:14 PM To: Nashorn-dev Subject: [10] RFR: 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks Please review 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks Kraken benchmark contains some files that invokes the Array constructor with lots of number literal arguments. We assume too low code footprint for these number literals in WeighNodes.java, resulting in the function not being split. Bug: https://bugs.openjdk.java.net/browse/JDK-8184893 Webrev: http://cr.openjdk.java.net/~hannesw/8184893/webrev/ Thanks, Hannes From james.laskey at oracle.com Tue Jul 25 16:15:15 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 25 Jul 2017 13:15:15 -0300 Subject: [10] RFR: 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks In-Reply-To: References: Message-ID: +1 > On Jul 25, 2017, at 10:44 AM, Hannes Walln?fer wrote: > > Please review 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks > > Kraken benchmark contains some files that invokes the Array constructor with lots of number literal arguments. We assume too low code footprint for these number literals in WeighNodes.java, resulting in the function not being split. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184893 > Webrev: http://cr.openjdk.java.net/~hannesw/8184893/webrev/ > > Thanks, > Hannes From james.laskey at oracle.com Tue Jul 25 16:15:24 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 25 Jul 2017 13:15:24 -0300 Subject: RFR: 8180727(Use jdk.editpad to replace jdk.nashorn.tools.jjs.EditPad duplicated class) In-Reply-To: <13264dbe-c245-49b9-a471-2403bc440f75@default> References: <13264dbe-c245-49b9-a471-2403bc440f75@default> Message-ID: <6D735AD9-144F-40D5-BDCE-BDDE4F0C6A35@oracle.com> +1 > On Jul 25, 2017, at 10:54 AM, Srinivas Dama wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8180727/webrev.00/ > > for https://bugs.openjdk.java.net/browse/JDK-8180727 > > > > Regards, > > Srinivas From hannes.wallnoefer at oracle.com Tue Jul 25 16:21:43 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 25 Jul 2017 18:21:43 +0200 Subject: RFR: 8180727(Use jdk.editpad to replace jdk.nashorn.tools.jjs.EditPad duplicated class) In-Reply-To: <6D735AD9-144F-40D5-BDCE-BDDE4F0C6A35@oracle.com> References: <13264dbe-c245-49b9-a471-2403bc440f75@default> <6D735AD9-144F-40D5-BDCE-BDDE4F0C6A35@oracle.com> Message-ID: <13E54260-336B-4FFB-BD58-FBB52B7AD3BD@oracle.com> +1 > Am 25.07.2017 um 18:15 schrieb Jim Laskey (Oracle) : > > +1 > >> On Jul 25, 2017, at 10:54 AM, Srinivas Dama wrote: >> >> Hi, >> >> Please review http://cr.openjdk.java.net/~sdama/8180727/webrev.00/ >> >> for https://bugs.openjdk.java.net/browse/JDK-8180727 >> >> >> >> Regards, >> >> Srinivas > From sundararajan.athijegannathan at oracle.com Wed Jul 26 13:53:42 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 26 Jul 2017 19:23:42 +0530 Subject: [10] RFR: 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks In-Reply-To: References: Message-ID: <59789EE6.4060206@oracle.com> +1 -Sundar On 25/07/17, 7:14 PM, Hannes Walln?fer wrote: > Please review 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks > > Kraken benchmark contains some files that invokes the Array constructor with lots of number literal arguments. We assume too low code footprint for these number literals in WeighNodes.java, resulting in the function not being split. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184893 > Webrev: http://cr.openjdk.java.net/~hannesw/8184893/webrev/ > > Thanks, > Hannes From jesse at dreamtsoft.com Fri Jul 28 00:08:41 2017 From: jesse at dreamtsoft.com (Jesse Schulman) Date: Fri, 28 Jul 2017 00:08:41 +0000 Subject: Avoiding excessive creation of LambdaForm classes Message-ID: We have noticed on a high traffic instance of our application that the number of loaded classes continues to grow, this in turn increases the amount of Metaspace and native memory used by the JVM. Moving forward we are working on a safe value for MaxMetaspaceSize which should eventually trigger a GC that cleans up these classes, but we would like to avoid these classes piling up unnecessarily if possible. During investigation we found that the large majority of these classes are LambdaForm that are created as a result of how we convert java Map and List instances into proper javascript Object and Array instances. We run with the --no-java option and expose functionality to javascript via our own implementations of JSObject. The attached reproducer represents how we convert java Maps and Lists in order to return them from our JSObject implementations. My best guess from investigating is that when we convert a complex java Map/List that contains many nested Maps/Lists we create many new instances of javascript Objects/Arrays as seen in the attached reproducer. It seems we go thru the Invoker.maybeCustomize every time we call getMember and every time we call newObject in createNewGlobalObject method of the reproducer. Each time it increments the MethodHandle.customizationCount until that is 127, and then another LambdaForm is created. I ran the attached reproducer with -verbose:class turned on and a logging breakpoint in my IDE that logs the mh.customizationCount every time Invokers.maybeCustomize calls mh.customize(). Once the reproducer logs "STARTING TEST" and loads some initial classes I see the breakpoint log that we've hit 127 customizations followed by the loading of another LambdaForm class: customize 127 customize 127 [Loaded java.lang.invoke.LambdaForm$BMH/1049817027 from java.lang.invoke.LambdaForm] [Loaded java.lang.invoke.LambdaForm$BMH/23211803 from java.lang.invoke.LambdaForm] customize 127 [Loaded java.lang.invoke.LambdaForm$BMH/1923598304 from java.lang.invoke.LambdaForm] customize 127 [Loaded java.lang.invoke.LambdaForm$BMH/776700275 from java.lang.invoke.LambdaForm] customize 127 customize 127 [Loaded java.lang.invoke.LambdaForm$BMH/118394766 from java.lang.invoke.LambdaForm] [Loaded java.lang.invoke.LambdaForm$BMH/386163331 from java.lang.invoke.LambdaForm] customize 127 [Loaded java.lang.invoke.LambdaForm$BMH/1540374340 from java.lang.invoke.LambdaForm] So I have 2 questions... 1. Is there a better/faster way for us to create the proper javascript Object/Array instances within our java code so we don't trigger these classes to be loaded? 2. Is this the intended behavior given: a. We don't actually evaluate any javascript at all in the reproducer, I can see generating these classes if we were evaluating a lot of different javascript b. Every time we call getMember against the global bindings we only ever pass "Array" or "Object" and when calling newObject against the Array/Object constructors we always do so with zero arguments, meaning we only call 4 different signatures yet the MethodHandle seems to be "customized" hundreds of times My assessment may be off or this may be exactly the expected behavior, but would still really appreciate any guidance on doing this type of conversion to avoid loading so many LambdaForm classes. Thanks! Jesse