Issue Summary

This is reproducible on Data Center: (yes)
When the number of children gets large and issues contain data that is heavy, calling childIssuesOf() can cause slowness or even Out Of Memory Exception.
Slowness is caused because JVM needs to perform excessive numbers of GC activities to allocate memory for whole Lucene documents.
If your instance is under pressure, multiple calls can even cause OOM.

This is one of the culprits for the slowness for more see JSWSERVER-24980

Steps to Reproduce

1. Create 64k~ issues(dependency tree) that are connected together via Parent Link, Epic Link and Parent fields. Each issue should have a field/fields that occupy more memory for example 0.8KB/issue. This is around ~400 characters long description for each issue.
2. Search by JQL

issuekey in childIssuesOf(<parent-issue-key>) 

Expected Results

There is no significant memory footprint.

Actual Results

One Jira call can generate more than 500 MB of heap, which can even cause OOM.
On the heap dump you can see many documents that are connected with childIssuesOf() function:

Workaround

Users may want to write new JQLs using a combination of ScriptRunner functions:

• issuesInEpics
• portfolioChildrenOf

The Jira administrator may choose to prevent the usage of this JQL function by disabling the following module of the Advanced Roadmaps plans plugin:

• Child issues of (jpo-jql-function-recursive-children-lookup)

 
If you'd like to follow that route, you can follow the steps below:

1. Go to Jira administration (gear icon) > Manage Apps > Manage Apps
2. Change the filter to "All apps".
3. Locate and expand the "Advanced Roadmaps plans" section.
4. Locate and turn off the "Child issues of (jpo-jql-function-recursive-children-lookup)" module.

This is a choice between stability and feature that an admin might want to take if the childIssuesOf JQL function becomes a major problem to an instance.