What exactly is the ScriptRunner Groovy Cache?

[Daniel Garcia]

Is it a standard groovy thing or unique to scriptrunner?

Is it just the list of classes that the class loader knows about?

Can it be interrogated (to help diagnose compile performance issues)?

Is there 1 system-wide instance? 1 per class loader ? what happens during a compile, when existing scripts are still running (presumably with a different class loader) ?

How big is it, can that size be tuned?

[Gonchik Tsymzhitov · Accepted solution]

Based on the community answer from previous post it is:

The Groovy Cache is essentially a cache of compiled Groovy scripts that have been executed previously. When a script is executed, the Groovy compiler produces a Java class file which is loaded into memory by the Java Virtual Machine (JVM). The Groovy Cache stores these compiled classes so that they can be reused in subsequent script executions, improving the performance of the ScriptRunner app.

But based on previous docs and links to the Adaptavist docs, no detailed info.

• https://community.atlassian.com/t5/Jira-Software-questions/Is-there-a-caching-in-scriptrunner-behaviours/qaq-p/1376216
• https://docs.adaptavist.com/sr4js/latest/features/built-in-scripts/clear-groovy-class-loader

But in Jira tickets in Adaptavist tracker, it's everything about GroovyClassLoader

• https://productsupport.adaptavist.com/browse/SRJIRA-4237
• https://productsupport.adaptavist.com/browse/SRJIRA-5022
• https://docs.groovy-lang.org/latest/html/api/groovy/lang/GroovyClassLoader.html

Overall, GroovyClassLoader is a powerful tool that allows for dynamic loading and compilation of Groovy code at runtime, providing flexibility and extensibility to Groovy applications.

And if it's reinitialized, as result some components  can be recompile. 

[Tuncay Senturk · Accepted solution]

Hi @Daniel Garcia 

ScriptRunner Groovy Cache is a feature in the ScriptRunner for Jira which enables caching of compiled Groovy scripts.

To clarify, I need to describe how Gorrvy scripts work. When you use ScriptRunner to run Groovy scripts, the plugin compiles the scripts into bytecode before executing them. This compilation process takes some time. The larger the script is, the more time it takes. To avoid compilation time every time the same script runs, the ScriptRunner Groovy Cache caches the compiled bytecode for frequently used scripts, to be executed faster on subsequent calls.

Is it just the list of classes that the class loader knows about?

It is not just the list of classes that the classloader knows about. The ScriptRunner Groovy Cache intercepts the process of compiling the Groovy script and caches the resulting bytecode, which can then be reused on subsequent runs of the same script.

Can it be interrogated (to help diagnose compile performance issues)?

Yes, the ScriptRunner Groovy Cache can be interrogated to help diagnose compile performance issues. It provides a number of metrics (the number of scripts, how many times they have been hit, and the total number of compilations) that can be accessed through the plugin console. By monitoring these metrics, you can gain insights about your scripts. You can also enable debug logging for the ScriptRunner Groovy Cache to get more detailed information about how the cache is behaving.

Is there 1 system-wide instance? 1 per class loader ? what happens during a compile, when existing scripts are still running (presumably with a different class loader) ?

As far as I know, there is one Groovy Cache per JVM, which means there is one cache shared across all the ScriptRunner instances running within the same JVM.

(Please take it with a pinch of salt,) In a typical Atlassian product environment, each plugin runs within its own class loader. However, the ScriptRunner Groovy Cache is shared across all the ScriptRunner instances, regardless of which class loader they belong to. This means that when a Groovy script is executed by one ScriptRunner instance, the compiled bytecode can be stored in the cache and then accessed by other ScriptRunner instances running within the same JVM.

How big is it, can that size be tuned?

I think the size of the ScriptRunner Groovy Cache is by default set to 500, which means that it can store up to 500 compiled Groovy scripts. I am not sure though.

I hope this helps!

[PD Sheehan]

Yes, the ScriptRunner Groovy Cache can be interrogated to help diagnose compile performance issues. It provides a number of metrics (the number of scripts, how many times they have been hit, and the total number of compilations) that can be accessed through the plugin console. By monitoring these metrics, you can gain insights about your scripts. You can also enable debug logging for the ScriptRunner Groovy Cache to get more detailed information about how the cache is behaving.

Is there any links/documentation on how to interrogate and monitor this cache?

[Daniel Garcia]

@Tuncay Senturk Thank you for a very detailed answer.

In terms of interrogating the ScriptRunner Groovy Cache, what classes should I be looking at?