[jira] [Updated] (SLING-8574) Memory leak via cached JavaScript factory functions in SlyBindingsValuesProvider

["Olaf Otto (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-8574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Olaf Otto updated SLING-8574:
-----------------------------
    Summary: Memory leak via cached JavaScript factory functions in SlyBindingsValuesProvider  (was: Memory leak fia cached JavaScript facotry functions in SlyBindingsValuesProvider)

> Memory leak via cached JavaScript factory functions in SlyBindingsValuesProvider
> --------------------------------------------------------------------------------
>
>                 Key: SLING-8574
>                 URL: https://issues.apache.org/jira/browse/SLING-8574
>             Project: Sling
>          Issue Type: Bug
>          Components: Scripting
>    Affects Versions: Scripting HTL JS Use Provider 1.0.28
>            Reporter: Olaf Otto
>            Priority: Critical
>              Labels: memory, memory-leak
>         Attachments: Heap_walker_Reference_Graph.html
>
>
> While analyzing excessive memory usage in an AEM 6.4 instance I discovered a memory leak transitively introduced via the SlyBindingsValues Provider.
> Here, a configurable list of JavaScripts is run to produce factory functions. These functions are retained in an application-scoped map in order to be injected into the bindings of future script executions.
> Here, the SlyBindingsValuesProvider creates these factory function instances by executing the factory scripts using, amongst others, the current ENGINE-scoped script bindings.
> The resulting compiled JS representations reference a org.mozilla.javascript.NativeCall instance, which is referencing a org.mozilla.javascript.ImporterTopLevel instance. This ImporterTopLevel instance has a slots[] array member who's Slot instances point to org.mozilla.javascript.NativeJavaObject instances representing at least all objects present in the bindings during the factory script execution.
> Thus, a chain of strong references is formed to request-scoped instances. This keeps open dozens to potentially thousands of request-scoped Objects such as Sling Models, requests, resources, resource resolvers and their respective transitive hull, resulting in significant memory consumption.
>  
> I have attached an excerpt of the respective view on the Heap generated using JProfiler.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)