[JENKINS-16341] Memory leak in createJavaScriptProxy

[jenkins-infra-bot]

Never seems to release bound objects, even after they have been rendered.

---

Originally reported by jglick, imported from: Memory leak in createJavaScriptProxy

• assignee: jglick
• status: Closed
• priority: Major
• component(s): core
• label(s): 2.528.1-rejected, memory-leak, performance, stapler
• resolution: Fixed
• resolved: 2025-09-23T01:48:50+00:00
• votes: 0
• watchers: 11
• imported: 2025-11-24

Raw content of original issue

Never seems to release bound objects, even after they have been rendered.

1 attachment

• JENKINS-16341.png

  

[jenkins-infra-bot]

• Remote link associated with this issue:

  • stapler #​663

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  In Jenkins Enterprise, merely opening the config page for a newly created freestyle job results in >100 RenderOnDemandClosure instances being bound, none of which are ever released.
  

In Jenkins Enterprise, merely opening the config page for a newly created freestyle job results in >100 RenderOnDemandClosure instances being bound, none of which are ever released.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  Heap delta in OSS trunk, after ~18 requests from
  
  
  curl -I http://localhost:8080/job/x/configure >&-
  
  
  

Heap delta in OSS trunk, after ~18 requests from

curl -I http://localhost:8080/job/x/configure >&-

[jenkins-infra-bot]

scm_issue_link:

• Original comment link
• Raw content of original comment:

  Code changed in jenkins
  User: Jesse Glick
  Path:
   changelog.html
   core/src/main/java/hudson/widgets/RenderOnDemandClosure.java
  http://jenkins-ci.org/commit/jenkins/08efdf5d3ab962cfd4c4c489266592fe1db7df8e
  Log:
    JENKINS-16341 Amelioration of memory leak by at least interning some heavily redundant strings.
  
  
  

Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
core/src/main/java/hudson/widgets/RenderOnDemandClosure.java
http://jenkins-ci.org/commit/jenkins/08efdf5d3ab962cfd4c4c489266592fe1db7df8e
Log:
JENKINS-16341 Amelioration of memory leak by at least interning some heavily redundant strings.

[jenkins-infra-bot]

dogfood:

• Original comment link
• Raw content of original comment:

  Integrated in  jenkins_main_trunk #2190
       JENKINS-16341 Amelioration of memory leak by at least interning some heavily redundant strings. (Revision 08efdf5d3ab962cfd4c4c489266592fe1db7df8e)
  
       Result = SUCCESS
  Jesse Glick : 08efdf5d3ab962cfd4c4c489266592fe1db7df8e
  Files : 
  
  	
  changelog.html
  	
  core/src/main/java/hudson/widgets/RenderOnDemandClosure.java
  
  
  

Integrated in jenkins_main_trunk #2190
JENKINS-16341 Amelioration of memory leak by at least interning some heavily redundant strings. (Revision 08efdf5)

Result = SUCCESS
Jesse Glick : 08efdf5d3ab962cfd4c4c489266592fe1db7df8e
Files :

• changelog.html
• core/src/main/java/hudson/widgets/RenderOnDemandClosure.java

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  JENKINS-9142 describes how to enable logging in bound objects.
  

JENKINS-9142 describes how to enable logging in bound objects.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  The hard part is that there is no way to know when the page is being rendered when the bound object can be released: it may be used zero, one, or several times while the page is opened, at any time the user likes.
  
  Possible resolution: release the binding if no “ping” has been received from the rendered page for at least a minute; send a ping every fifteen seconds. Means creating some kind of Stapler adjunct and helper script and REST endpoint that lets the page send a short request to Jenkins periodically; Jenkins would keep a list of ping IDs and for each of these a list of bound objects.
  

The hard part is that there is no way to know when the page is being rendered when the bound object can be released: it may be used zero, one, or several times while the page is opened, at any time the user likes.

Possible resolution: release the binding if no “ping” has been received from the rendered page for at least a minute; send a ping every fifteen seconds. Means creating some kind of Stapler adjunct and helper script and REST endpoint that lets the page send a short request to Jenkins periodically; Jenkins would keep a list of ping IDs and for each of these a list of bound objects.

[jenkins-infra-bot]

scm_issue_link:

• Original comment link
• Raw content of original comment:

  Code changed in jenkins
  User: Jesse Glick
  Path:
   test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
   test/src/test/java/lib/layout/RenderOnDemandTest.java
  http://jenkins-ci.org/commit/jenkins/f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410
  Log:
    JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5.
  
  
  

Code changed in jenkins
User: Jesse Glick
Path:
test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
test/src/test/java/lib/layout/RenderOnDemandTest.java
http://jenkins-ci.org/commit/jenkins/f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410
Log:
JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5.

[jenkins-infra-bot]

dogfood:

• Original comment link
• Raw content of original comment:

  Integrated in  jenkins_main_trunk #2193
       JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5. (Revision f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410)
  
       Result = SUCCESS
  Jesse Glick : f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410
  Files : 
  
  	
  test/src/test/java/lib/layout/RenderOnDemandTest.java
  	
  test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
  
  
  

Integrated in jenkins_main_trunk #2193
JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5. (Revision f178f0c)

Result = SUCCESS
Jesse Glick : f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410
Files :

• test/src/test/java/lib/layout/RenderOnDemandTest.java
• test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java

[jenkins-infra-bot]

kohsuke:

• Original comment link
• Raw content of original comment:

  The other thing that helps is to make proxies have well-known URLs. If the fragment rendered on-demand do not depend on the request context (or if it can be recreated from future requests), then there won't be any need to keep session-scoped objects.
  
  Some of the core tags might very well fit with this, since they explicitly lists variables that get captured.
  
  But otherwise I agree that ping is the only way I can think of.
  

The other thing that helps is to make proxies have well-known URLs. If the fragment rendered on-demand do not depend on the request context (or if it can be recreated from future requests), then there won't be any need to keep session-scoped objects.

Some of the core tags might very well fit with this, since they explicitly lists variables that get captured.

But otherwise I agree that ping is the only way I can think of.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  RenderOnDemandClosure cannot be done this way AFAICT, since its variables are of unrestricted type. Nor can other uses of @JavaScriptMethod, unless we can somehow establish that the receiver object is a singleton.
  

RenderOnDemandClosure cannot be done this way AFAICT, since its variables are of unrestricted type. Nor can other uses of @​JavaScriptMethod, unless we can somehow establish that the receiver object is a singleton.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  @kohsuke points out that WithWellKnownURL may be used for singleton objects with a @JavaScriptMethod to avoid this bug. That is no help for <l:renderOnDemand>.
  

@​kohsuke points out that WithWellKnownURL may be used for singleton objects with a @​JavaScriptMethod to avoid this bug. That is no help for .

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  Also users of ProgressiveRendering would be affected. Though this class implements its own ping-based timeout, returning "canceled" from news(), that does not also call Bound.release. The only fix for that, other than a general fix of this issue, would be to make ProgressiveRendering implement WithWellKnownURL, adding ongoing renders to a map keyed by random UUID  and deleting them after sending back a cancel status.
  

Also users of ProgressiveRendering would be affected. Though this class implements its own ping-based timeout, returning "canceled" from news(), that does not also call Bound.release. The only fix for that, other than a general fix of this issue, would be to make ProgressiveRendering implement WithWellKnownURL, adding ongoing renders to a map keyed by random UUID and deleting them after sending back a cancel status.

[jenkins-infra-bot]

scm_issue_link:

• Original comment link
• Raw content of original comment:

  Code changed in jenkins
  User: Jesse Glick
  Path:
   changelog.html
   core/src/main/java/hudson/widgets/RenderOnDemandClosure.java
  http://jenkins-ci.org/commit/jenkins/47d6811666d5eb20bc491ea6ad4bda8f54f83be4
  Log:
    JENKINS-16341 Amelioration of memory leak by at least interning some heavily redundant strings.
  (cherry picked from commit 08efdf5d3ab962cfd4c4c489266592fe1db7df8e)
  
  Conflicts:
  	changelog.html
  	core/src/main/java/hudson/widgets/RenderOnDemandClosure.java
  
  
  

Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
core/src/main/java/hudson/widgets/RenderOnDemandClosure.java
http://jenkins-ci.org/commit/jenkins/47d6811666d5eb20bc491ea6ad4bda8f54f83be4
Log:
JENKINS-16341 Amelioration of memory leak by at least interning some heavily redundant strings.
(cherry picked from commit 08efdf5)

Conflicts:
changelog.html
core/src/main/java/hudson/widgets/RenderOnDemandClosure.java

[jenkins-infra-bot]

scm_issue_link:

• Original comment link
• Raw content of original comment:

  Code changed in jenkins
  User: Jesse Glick
  Path:
   test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
   test/src/test/java/lib/layout/RenderOnDemandTest.java
  http://jenkins-ci.org/commit/jenkins/5fe628076b6ee03f57bfa0767c6d0775aeafac1e
  Log:
    JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5.(cherry picked from commit f178f0cef4bf86c5fb4cf4a2c40afce4c2b43410)
  
  Conflicts:
  	test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
  	test/src/test/java/lib/layout/RenderOnDemandTest.java
  
  
  

Code changed in jenkins
User: Jesse Glick
Path:
test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
test/src/test/java/lib/layout/RenderOnDemandTest.java
http://jenkins-ci.org/commit/jenkins/5fe628076b6ee03f57bfa0767c6d0775aeafac1e
Log:
JENKINS-16341 INSANE testing shows that a RenderOnDemandClosure binding adds about 380k, with or wothout 08efdf5.(cherry picked from commit f178f0c)

Conflicts:
test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
test/src/test/java/lib/layout/RenderOnDemandTest.java