groovy.indy.callsite.cache.size can control the size of PIC, e.g. -Dgroovy.indy.callsite.cache.size=4
Also, here is a snapshot to reduce the memory usage, if you could give it a try, and give us some feedback, that would be appreciated. https://github.com/apache/groovy/actions/runs/1375230234 Cheers, Daniel Sun On 2021/10/24 17:41:22 MG wrote: > Hi Daniel, > > I have updated the ticket with some VisalVM memory sampling screenshots: > For this short test Groovy 4 uses more than 13 million objects of type > java.util.concurrent.atomic.AtomicReference, together with an more than > 100,000 java.util.concurrent.atomic.AtomicReference[] arrays, which > together makes up about 36% of memory consumption. The overall memory > consumption is nearly 3x as high for Groovy 4: 1.2 GB vs 0.46 GB for > Groovy 3 (heap size: 8 GB) > > That seems a lot to me - would you expect these numbers to be influenced > by any of the JVM settings you proposed ? > > https://issues.apache.org/jira/browse/GROOVY-10307 > > Cheers, > mg > > > On 24/10/2021 18:29, Daniel Sun wrote: > >> What I can tell you for sure is, that invokedynamic has a big problem with > >> 1-time calls. It is much more expensive to generate the callsite for > >> invokedynamic than it is for our old callsite code (which will stop > >> working) and also of course compared to direct method calls. > > In addition, when method is called over 100000 times by default, the method > > will be set as target to the indy call site, so 1-time calls can not > > benefit from optimization of the indy call site. > > > > P.S. the default threshold(100000) mentioned above can be changed by > > setting JVM option "groovy.indy.optimize.threshold", e.g. > > `-Dgroovy.indy.optimize.threshold=100` > > > > Cheers, > > Daniel Sun > > > > On 2021/10/14 11:48:47, Jochen Theodorou <blackd...@gmx.org> wrote: > >> On 14.10.21 01:24, MG wrote: > >> [...] > >>> Alas performance-wise what we surprisingly found was, that the > >>> performance of our main web application dropped by a factor of 2 (table > >>> refresh) to 3 (startup). > >>> Executing our test suite showed a similar picture. Since no immediate > >>> source for this performance drop emerged, we checked the performance of > >>> Groovy 3 Indy, more to rule out that the performance reduction had > >>> something to do with invokedynamic; > >>> as can be seen in the table below, to our surprise performance > >>> degradiation of Groovy 3.0.9 with full invokedynamic (Groovy JARs & > >>> IntelliJ compiler switch/checkbox active) was in fact in most cases > >>> close to the one seen with Groovy 4.0.0-beta-1, pointing to > >>> invokedynamic as the potential cause. > >>> > >>> Right now it looks to us, as if Groovy with invokedynamic for us is just > >>> "leaking performance everywhere", with no clear source. > >>> Speed changes range from about 0.6 (i.e. a speedup) to about 5.0, with a > >>> large bias towards a slowdown by a factor of 2.0 to 2.5. The overall > >>> time of the test suite increased by a factor of 2.37 (G3 Indy) and 2.45 > >>> (G4) respectively. > >>> > >>> Any ideas what could be the cause of this unexpected slowdown or where > >>> we should put our focus in analyzing this, to create a test case > >>> independent of our framwork ? > >> Unless someone here has a concrete candidate it will be difficult to > >> find out what exactly the problem is without having the code itself I > >> guess. > >> > >> What I can tell you for sure is, that invokedynamic has a big problem > >> with 1-time calls. It is much more expensive to generate the callsite > >> for invokedynamic than it is for our old callsite code (which will stop > >> working) and also of course compared to direct method calls. > >> > >> By the nature of performance tests, this is rarely measured though and I > >> don't believe that this is causing the problem here. > >> > >> A profiler, that profiles also the Groovy runtime code, could maybe show > >> code from the indy part, that is involved a lot and maybe should not. > >> > >> If I would have no clue what this really could be I would actually do > >> the following.. I would turn on the hotspot compilation tracing, > >> printing me the machine code it produces and of which methods. Then I > >> would compare.... what methods are not compiled in indy? These are > >> candidates for being significant. > >> > >> I am curious to see what others suggest > >> > >> bye Jochen > >> > >
