Re: [VOTE] Release Apache Groovy 2.5.9
+1 (binding) Cheers, Daniel.Sun - Apache Groovy committer & PMC member Blog: http://blog.sunlan.me Twitter: @daniel_sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Release Apache Groovy 2.4.18
+1 (binding) Cheers, Daniel.Sun - Apache Groovy committer & PMC member Blog: http://blog.sunlan.me Twitter: @daniel_sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
[VOTE] Release Apache Groovy 2.5.9
Dear development community, I am happy to start the VOTE thread for a Groovy 2.5.9 release! This release includes 30 bug fixes/improvements as outlined in the changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12345981 Tag: https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_9 Tag commit id: cb31e711bd327b9808e6acaa4601442ee2b34d85 The artifacts to be voted on are located as follows (r37564). Source release: https://dist.apache.org/repos/dist/dev/groovy/2.5.9/sources Convenience binaries: https://dist.apache.org/repos/dist/dev/groovy/2.5.9/distribution Release artifacts are signed with a key from the following file: https://dist.apache.org/repos/dist/dev/groovy/KEYS Please vote on releasing this package as Apache Groovy 2.5.9. Reminder on ASF release approval requirements for PMC members: http://www.apache.org/legal/release-policy.html#release-approval Hints on validating checksums/signatures (but replace md5sum with sha256sum): https://www.apache.org/info/verification.html The vote is open for the next 72 hours and passes if a majority of at least three +1 PMC votes are cast. [ ] +1 Release Apache Groovy 2.5.9 [ ] 0 I don't have a strong opinion about this, but I assume it's ok [ ] -1 Do not release Apache Groovy 2.5.9 because... Here is my vote: +1 (binding)
[VOTE] Release Apache Groovy 2.4.18
Dear development community, I am happy to start the VOTE thread for a Groovy 2.4.18 bug fix release! This release includes 3 bug fixes/improvements as outlined in the changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12345496 Tag: https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_4_18 Tag commit id: ee00dd257711390ecac3c5a3823db428a9a72a26 The artifacts to be voted on are located as follows (r37563). Source release: https://dist.apache.org/repos/dist/dev/groovy/2.4.18/sources Convenience binaries: https://dist.apache.org/repos/dist/dev/groovy/2.4.18/distribution Release artifacts are signed with a key from the following file: https://dist.apache.org/repos/dist/dev/groovy/KEYS Please vote on releasing this package as Apache Groovy 2.4.18. Reminder on ASF release approval requirements for PMC members: http://www.apache.org/legal/release-policy.html#release-approval Hints on validating checksums/signatures (but replace md5sum with sha256sum): https://www.apache.org/info/verification.html The vote is open for the next 72 hours and passes if a majority of at least three +1 PMC votes are cast. [ ] +1 Release Apache Groovy 2.4.18 [ ] 0 I don't have a strong opinion about this, but I assume it's ok [ ] -1 Do not release Apache Groovy 2.4.18 because... Here is my vote: +1 (binding)
Re: About the performance of indy
Hi Jochen, > If you want to get the maximum performance then I would suggest to work with the guards instead of falling back to a hashed map. Thanks for your suggestions :-) After we constructed the following "tree" MH with guards, we have to set target to link the MH to the related callsite. > > Guard(String) > / \ > MH(same(String)Guard(Float) >/ \ >MH(same(float)) Guard(Integer) > / \ > MH(same(int))Fallback to select But the "setTarget" may cause poor performance because JVM may do some de-opt shown as GROOVY-8298: ``` "qtp2078714399-360525": running, holding [771bcf60] at java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native Method) at java.lang.invoke.CallSite.setTargetNormal(CallSite.java:258) at java.lang.invoke.MutableCallSite.setTarget(MutableCallSite.java:154) at org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.doCallSiteTargetSet(Selector.java:909) at org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.setCallSiteTarget(Selector.java:969) at org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:228) at java.lang.invoke.LambdaForm$DMH/1665404403.invokeStatic_L3IL5_L(LambdaForm$DMH) at java.lang.invoke.LambdaForm$BMH/1828868503.reinvoke(LambdaForm$BMH) at java.lang.invoke.LambdaForm$reinvoker/1917025677.dontInline(LambdaForm$reinvoker) at java.lang.invoke.LambdaForm$MH/462773420.guard(LambdaForm$MH) at java.lang.invoke.LambdaForm$MH/1947020920.linkToCallSite(LambdaForm$MH) ``` Cheers, Daniel.Sun - Apache Groovy committer & PMC member Blog: http://blog.sunlan.me Twitter: @daniel_sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Upcoming releases: 2.4.18/2.5.9/final 3.0 RC
Hi Paul, I suggest the following PRs could be included in final 3.0 RC. 1) PR#1135[1] for GROOVY-8298 is ready to merge 2) PR#1137[2] for GROOVY-8296 LGTM Cheers, Daniel.Sun [1] https://github.com/apache/groovy/pull/1135 [2] https://github.com/apache/groovy/pull/1137 - Apache Groovy committer & PMC member Blog: http://blog.sunlan.me Twitter: @daniel_sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Upcoming releases: 2.4.18/2.5.9/final 3.0 RC
Final call for any changes before I make some new releases. Cheers, Paul.
Re: About the performance of indy
On 09.01.20 19:01, Daniel.Sun wrote:
Hi Jochen,
I am still thinking about how to improve indy performance further in
the method overload cases, e.g.
```
def same(String obj) { return obj }
def same(int obj) { return obj }
def same(float obj) { return obj }
for (int i = 0; i < 10; i++) {
[1, 1.0f, '1.0'].each { same(it) }
}
```
If we cache both receiver type and argument types, I find the
performance of this case can be improved a lot, but other cases performance
is reduced quite a bit too... so I am trying 2 levels cache: the 1st level
cache is the current cache for receiver type, its size is fixed as 16 by
default, and I want to add 2nd level cache is for caching argument types,
its size will be fixed as 16 by default too. The 2 caches are seperated, so
receiver types kept in 1st level cache will not be cleared, and 2nd level
cache can provide more hot candidates for better performance.
If you want to get the maximum performance then I would suggest to work
with the guards instead of falling back to a hashed map. The JVM can
quite efficiently check if x is of type X. So for example in the above
case I see something like this (Notes: ASCII art, MH(same(String) means
the method handle to invoke the method same with the parameter type
String, Guard(Integer) a guard checking for the argument type integer,
with positive case on the left and fallback on the right):
Guard(String)
/ \
MH(same(String)Guard(Float)
/ \
MH(same(float)) Guard(Integer)
/ \
MH(same(int))Fallback to select
Ideally we would also take out the exception unrolling and the switch
point guards in the MH and have them in front of the first argument
chart. Heck in this case even the receiver check could be limited to be
done only once. In the end same(String) calls would perform with about
the same performance and same(int) calls would be slowest, but only by a
minimal margin. A hash based cache is never going to beat two simple
instanceof calls.
bye Jochen
