Re: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements

2017-12-12 Thread Priya Lakshmi Muthuswamy
Thanks Attila, I have modified the patch webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.03/ Thanks, Priya On 12/13/2017 12:57 AM, Attila Szegedi wrote: This is generally acceptable, and while I really don’t want to be a pain, I’ll point out few minor things still, because I

Re: Any news from JDK-8151981 in Java8 ?

2017-12-12 Thread forax
It's just that i've seen several times setCallSiteTargetNormal in the profile and each time it was my fault, creating a GWT with the two branches swaped, invalidating SwitchPoints too vigorously, etc. Rémi - Mail original - > De: "Hannes Wallnöfer" > À:

Re: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements

2017-12-12 Thread Attila Szegedi
This is generally acceptable, and while I really don’t want to be a pain, I’ll point out few minor things still, because I really want this code to be the best it can be :-) - in Nashorn code (and OpenJDK in general), we format “else” and “else if” to be on the same line as the closing brace

Re: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements

2017-12-12 Thread Priya Lakshmi Muthuswamy
Hi Attila, I have modified the patch with your suggestions. webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.02/ Thanks, Priya On 12/12/2017 8:49 PM, Attila Szegedi wrote: Hi Priya, This indeed looks much better, although I do have some remarks with regard to the the style

Re: RFR: 8069338: Implement sharedScopeCall for optimistic types

2017-12-12 Thread Attila Szegedi
I personally don’t believe anybody will ever be fidgeting with these, but it doesn’t hurt having them configurable, so… +1 :-) > On Dec 12, 2017, at 2:39 PM, Hannes Wallnöfer > wrote: > > Thanks for the review, Sundar. > > I think making thresholds configurable

Re: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements

2017-12-12 Thread Attila Szegedi
Hi Priya, This indeed looks much better, although I do have some remarks with regard to the the style of the code. Specifically, repetitions of identical code, as well as assignments inside predicates. There are several cases of code that is repeating: First is:

Re: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements

2017-12-12 Thread Hannes Wallnöfer
+1, and I like the fact that the patch has become smaller. Hannes > Am 12.12.2017 um 13:32 schrieb Priya Lakshmi Muthuswamy > : > > Hi, > > Kindly review. I have modified the fix to work with multiple with scopes. > > webrev :

Re: RFR: 8134516(Move getInvokeByName and getDynamicInvoker methods from Global to Context)

2017-12-12 Thread Srinivas Dama
Hi Attila, Thank you for the comments. I have resolved the bug as "will-not-fix" and added appropriate comments in the bug. So I am taking back this RFR. Regards, Srinivas - Original Message - From: szege...@gmail.com To: srinivas.d...@oracle.com Cc: nashorn-dev@openjdk.java.net Sent:

Re: Any news from JDK-8151981 in Java8 ?

2017-12-12 Thread Hannes Wallnöfer
Hi Rémi, Am 12.12.2017 um 14:52 schrieb Remi Forax : > > Hi Hannes, > it can also be Nashorn triggering too much deoptimizations creating a > deoptimization storm. I agree. But given that the problem manifests itself in java.lang.invoke I think the first step is to

Re: Any news from JDK-8151981 in Java8 ?

2017-12-12 Thread João Paulo Varandas
I see... I'm sorry about that, I haven't noticed the subpackage/components in the bug report. 2017-12-12 11:52 GMT-02:00 Remi Forax : > Hi Hannes, > it can also be Nashorn triggering too much deoptimizations creating a > deoptimization storm. > > Rémi > > - Mail

Re: Any news from JDK-8151981 in Java8 ?

2017-12-12 Thread Remi Forax
Hi Hannes, it can also be Nashorn triggering too much deoptimizations creating a deoptimization storm. Rémi - Mail original - > De: "Hannes Wallnöfer" > À: "João Paulo Varandas" > Cc: nashorn-dev@openjdk.java.net > Envoyé: Mardi

Re: RFR: 8069338: Implement sharedScopeCall for optimistic types

2017-12-12 Thread Sundararajan Athijegannathan
+1 -Sundar On 12/12/17, 7:09 PM, Hannes Wallnöfer wrote: Thanks for the review, Sundar. I think making thresholds configurable is a good idea. I’ve uploaded a new webrev where SHARED_CALL_THRESHOLD and SHARED_GET_THRESHOLD are configurable via „nashorn.shared.scope.call.threshold“ and

Re: RFR: 8069338: Implement sharedScopeCall for optimistic types

2017-12-12 Thread Hannes Wallnöfer
Thanks for the review, Sundar. I think making thresholds configurable is a good idea. I’ve uploaded a new webrev where SHARED_CALL_THRESHOLD and SHARED_GET_THRESHOLD are configurable via „nashorn.shared.scope.call.threshold“ and „nashorn.shared.scope.get.threshold“ system properties,

Re: Any news from JDK-8151981 in Java8 ?

2017-12-12 Thread Hannes Wallnöfer
Hi João, this functionality is part of java.lang.invoke package, not Nashorn, so we can’t help you here. The best place to ask about this would be the core-libs-dev mailing list. Regards, Hannes > Am 11.12.2017 um 23:07 schrieb João Paulo Varandas : > > Hi guys! >

Re: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements

2017-12-12 Thread Priya Lakshmi Muthuswamy
Hi, Kindly review. I have modified the fix to work with multiple with scopes. webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.01/ Thanks, Priya On 12/5/2017 12:54 PM, Priya Lakshmi Muthuswamy wrote: Hi Attila, Thanks for review. Yes when I checked with two with scopes as

Re: RFR: 8069338: Implement sharedScopeCall for optimistic types

2017-12-12 Thread Sundararajan Athijegannathan
+1 PS. Not sure if it is worth making SHARED_GET_THRESHOLD configurable via System property? -Sundar On 12/12/17, 5:51 PM, Hannes Wallnöfer wrote: Thanks for the review, Attila. I’ve uploaded a new webrev with your suggested changes (including making ScriptObject.getProto(int) accept 0

Re: Review request for JDK-8193298: Don't run javadoc with test.single

2017-12-12 Thread Hannes Wallnöfer
+1 Hannes > Am 10.12.2017 um 17:26 schrieb Attila Szegedi : > > Please review JDK-8193298 "Don't run javadoc with test.single" at > for > > > Thanks, > Attila.

Re: Review request for JDK-8191905: Add a REMOVE value to jdk.dynalink.StandardOperation

2017-12-12 Thread Hannes Wallnöfer
+1 Hannes > Am 08.12.2017 um 12:13 schrieb Attila Szegedi : > > Please review JDK-8191905 "Add a REMOVE value to > jdk.dynalink.StandardOperation" at > for > > >

Re: RFR: 8069338: Implement sharedScopeCall for optimistic types

2017-12-12 Thread Attila Szegedi
+1 > On Dec 12, 2017, at 1:21 PM, Hannes Wallnöfer > wrote: > > Thanks for the review, Attila. > > I’ve uploaded a new webrev with your suggested changes (including making > ScriptObject.getProto(int) accept 0 argument and refactoring GET_PROTO code > in

Re: RFR: 8069338: Implement sharedScopeCall for optimistic types

2017-12-12 Thread Hannes Wallnöfer
Thanks for the review, Attila. I’ve uploaded a new webrev with your suggested changes (including making ScriptObject.getProto(int) accept 0 argument and refactoring GET_PROTO code in CodeGenerator into a method). I have also done extensive performance testing over the last days and found