MVEL

OptimizerFactory - ThreadLocal not cleared

Details

  • Type: Bug Bug
  • Status: Reopened Reopened
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0.18
  • Fix Version/s: 2.0.19
  • Component/s: Core
  • Labels:
    None
  • Number of attachments :
    1

Description

The OptimizerFactory is using ThreadLocals to store the threadOptimizer. However - the stored Locals are not cleared after usage.
Using HeapDump Analysis you can see that e.g. in Tomcat the classloader can not be garbage collected, because the optimizer (e.g. the ASMAccessorOptimizer or any other one) is stored in a thread local.
Maybe you can provide some code fix to clear this one or maybe its possible not to use them - don't know whats best here.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Mike Brock added a comment -

I believe I have a more concise and efficient solution that I'm currently testing in trunk.

Show
Mike Brock added a comment - I believe I have a more concise and efficient solution that I'm currently testing in trunk.
Hide
Permalink
Mike Brock added a comment -

Alright, your patch has been implemented with some modifications.

Show
Mike Brock added a comment - Alright, your patch has been implemented with some modifications.
Hide
Permalink
Torsten Krah added a comment -

The OptimizerFactory does still have some static Initializer code - which may be called from external code at class loading time.
Following the execution path it will call this method:

setDefaultOptimizer which calls setThreadAccessorOptimizer which itself does fill the ThreadLocal already. But when this is done the ThreadLocal can not be cleared.

Thats why the patch attached did comment out this - the call to get does already check for null and creates one which after this can be cleared by anyone who does use the Optimizer.
Am i wrong?

Show
Torsten Krah added a comment - The OptimizerFactory does still have some static Initializer code - which may be called from external code at class loading time. Following the execution path it will call this method: setDefaultOptimizer which calls setThreadAccessorOptimizer which itself does fill the ThreadLocal already. But when this is done the ThreadLocal can not be cleared. Thats why the patch attached did comment out this - the call to get does already check for null and creates one which after this can be cleared by anyone who does use the Optimizer. Am i wrong?
Hide
Permalink
Chris Wewerka added a comment -

We successfully patched MVEL 2.0.16 org.mvel2.optimizers.OptimizerFactory with the idea of a SoftThreadLocal, introduced in a comment of this article: http://weblogs.java.net/blog/jjviana/archive/2010/06/09/dealing-glassfish-301-memory-leak-or-threadlocal-thread-pool-bad-ide. Maybe this is a simple workaround for you, too

Show
Chris Wewerka added a comment - We successfully patched MVEL 2.0.16 org.mvel2.optimizers.OptimizerFactory with the idea of a SoftThreadLocal, introduced in a comment of this article: http://weblogs.java.net/blog/jjviana/archive/2010/06/09/dealing-glassfish-301-memory-leak-or-threadlocal-thread-pool-bad-ide . Maybe this is a simple workaround for you, too
Hide
Permalink
Mattias Jiderhamn added a comment -

Any new about the setDefaultOptimizer() problem?

Show
Mattias Jiderhamn added a comment - Any new about the setDefaultOptimizer() problem?

People

  • Assignee:
    Mike Brock
    Reporter:
    Torsten Krah
Vote (3)
Watch (2)

Dates

  • Created:
    Updated: