You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Yu-Nan He (JIRA)" <ji...@apache.org> on 2007/05/24 14:16:16 UTC

[jira] Created: (HARMONY-3956) [drlvm][thread] memory leak in thread pool implementation

[drlvm][thread] memory leak in thread pool implementation
---------------------------------------------------------

                 Key: HARMONY-3956
                 URL: https://issues.apache.org/jira/browse/HARMONY-3956
             Project: Harmony
          Issue Type: Bug
          Components: DRLVM
         Environment: Linux
            Reporter: Yu-Nan He


I found a very interesting design issue in threading part about the thread pool implementation. This introduces memory leaks and sometimes fails classlib tests. This can be a potential issue for server side applications. 

The current thread pool is implemented through WeakReference( ThreadWeakRef  ), i.e., each created Java thread will be managed with a WeakReference, and the reference object will be put into the referenceQueue when the thread exits. But the enqueuing of the finished thread depends on WeakReference processing of the JVM, hence depending on the GC collection cycle. If GC has large enough free space, not to collect the heap and process WeakReference, the finished threads will not be returned to the referenceQueue.  It is possible that, lots of finished threads are not enqueued before a GC happen, gradually running out native memory for new thread creation. 
 
To work around this issue, TM can trigger GC from time to time when the referenceQueue is empty. But I guess a right solution is to use some other mechanism for thread pool implementation. Since thread entity is scare resource for the system, we probably donot want to depend its management on the WeakReference processing, since there is no specified behavior on the timing of WeakReference processing. This is the key issue. That means, even the TM triggers GC from time to time, we cannot guarantee the finished threads will be enqueued on time before system crashes. 

In my experiments in Linux32, I found classlib tests (run "ant test" in working_classlib) failed from time to time due to this issue. The error message is new thread cannot be created.

It would be great if the threading guys can think of some good solution for this issue.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Created: (HARMONY-3956) [drlvm][thread] memory leak in thread pool implementation

Posted by Alexey Varlamov <al...@gmail.com>.
2007/5/24, Xiao-Feng Li <xi...@gmail.com>:
> This is indeed a very interesting issue. WeakReference probably should
> not be used for critical resource management.

AFAIK this is an old known flaw in TM, final re-design outcome is
HARMONY-3289 [drlvm][thread] Explicit memory model for thread blocks.


>
> Thanks,
> xiaofeng
>
> On 5/24/07, Yu-Nan He (JIRA) <ji...@apache.org> wrote:
> > [drlvm][thread] memory leak in thread pool implementation
> > ---------------------------------------------------------
> >
> >                  Key: HARMONY-3956
> >                  URL: https://issues.apache.org/jira/browse/HARMONY-3956
> >              Project: Harmony
> >           Issue Type: Bug
> >           Components: DRLVM
> >          Environment: Linux
> >             Reporter: Yu-Nan He
> >
> >
> > I found a very interesting design issue in threading part about the thread pool implementation. This introduces memory leaks and sometimes fails classlib tests. This can be a potential issue for server side applications.
> >
> > The current thread pool is implemented through WeakReference( ThreadWeakRef  ), i.e., each created Java thread will be managed with a WeakReference, and the reference object will be put into the referenceQueue when the thread exits. But the enqueuing of the finished thread depends on WeakReference processing of the JVM, hence depending on the GC collection cycle. If GC has large enough free space, not to collect the heap and process WeakReference, the finished threads will not be returned to the referenceQueue.  It is possible that, lots of finished threads are not enqueued before a GC happen, gradually running out native memory for new thread creation.
> >
> > To work around this issue, TM can trigger GC from time to time when the referenceQueue is empty. But I guess a right solution is to use some other mechanism for thread pool implementation. Since thread entity is scare resource for the system, we probably donot want to depend its management on the WeakReference processing, since there is no specified behavior on the timing of WeakReference processing. This is the key issue. That means, even the TM triggers GC from time to time, we cannot guarantee the finished threads will be enqueued on time before system crashes.
> >
> > In my experiments in Linux32, I found classlib tests (run "ant test" in working_classlib) failed from time to time due to this issue. The error message is new thread cannot be created.
> >
> > It would be great if the threading guys can think of some good solution for this issue.
> >
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>
>
> --
> http://xiao-feng.blogspot.com
>

Re: [jira] Created: (HARMONY-3956) [drlvm][thread] memory leak in thread pool implementation

Posted by Xiao-Feng Li <xi...@gmail.com>.
This is indeed a very interesting issue. WeakReference probably should
not be used for critical resource management.

Thanks,
xiaofeng

On 5/24/07, Yu-Nan He (JIRA) <ji...@apache.org> wrote:
> [drlvm][thread] memory leak in thread pool implementation
> ---------------------------------------------------------
>
>                  Key: HARMONY-3956
>                  URL: https://issues.apache.org/jira/browse/HARMONY-3956
>              Project: Harmony
>           Issue Type: Bug
>           Components: DRLVM
>          Environment: Linux
>             Reporter: Yu-Nan He
>
>
> I found a very interesting design issue in threading part about the thread pool implementation. This introduces memory leaks and sometimes fails classlib tests. This can be a potential issue for server side applications.
>
> The current thread pool is implemented through WeakReference( ThreadWeakRef  ), i.e., each created Java thread will be managed with a WeakReference, and the reference object will be put into the referenceQueue when the thread exits. But the enqueuing of the finished thread depends on WeakReference processing of the JVM, hence depending on the GC collection cycle. If GC has large enough free space, not to collect the heap and process WeakReference, the finished threads will not be returned to the referenceQueue.  It is possible that, lots of finished threads are not enqueued before a GC happen, gradually running out native memory for new thread creation.
>
> To work around this issue, TM can trigger GC from time to time when the referenceQueue is empty. But I guess a right solution is to use some other mechanism for thread pool implementation. Since thread entity is scare resource for the system, we probably donot want to depend its management on the WeakReference processing, since there is no specified behavior on the timing of WeakReference processing. This is the key issue. That means, even the TM triggers GC from time to time, we cannot guarantee the finished threads will be enqueued on time before system crashes.
>
> In my experiments in Linux32, I found classlib tests (run "ant test" in working_classlib) failed from time to time due to this issue. The error message is new thread cannot be created.
>
> It would be great if the threading guys can think of some good solution for this issue.
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>


-- 
http://xiao-feng.blogspot.com

Re: [jira] Created: (HARMONY-3956) [drlvm][thread] memory leak in thread pool implementation

Posted by Xiao-Feng Li <xi...@gmail.com>.
This is indeed a very interesting issue. WeakReference probably should
not be used for critical resource management.

Thanks,
xiaofeng

On 5/24/07, Yu-Nan He (JIRA) <ji...@apache.org> wrote:
> [drlvm][thread] memory leak in thread pool implementation
> ---------------------------------------------------------
>
>                  Key: HARMONY-3956
>                  URL: https://issues.apache.org/jira/browse/HARMONY-3956
>              Project: Harmony
>           Issue Type: Bug
>           Components: DRLVM
>          Environment: Linux
>             Reporter: Yu-Nan He
>
>
> I found a very interesting design issue in threading part about the thread pool implementation. This introduces memory leaks and sometimes fails classlib tests. This can be a potential issue for server side applications.
>
> The current thread pool is implemented through WeakReference( ThreadWeakRef  ), i.e., each created Java thread will be managed with a WeakReference, and the reference object will be put into the referenceQueue when the thread exits. But the enqueuing of the finished thread depends on WeakReference processing of the JVM, hence depending on the GC collection cycle. If GC has large enough free space, not to collect the heap and process WeakReference, the finished threads will not be returned to the referenceQueue.  It is possible that, lots of finished threads are not enqueued before a GC happen, gradually running out native memory for new thread creation.
>
> To work around this issue, TM can trigger GC from time to time when the referenceQueue is empty. But I guess a right solution is to use some other mechanism for thread pool implementation. Since thread entity is scare resource for the system, we probably donot want to depend its management on the WeakReference processing, since there is no specified behavior on the timing of WeakReference processing. This is the key issue. That means, even the TM triggers GC from time to time, we cannot guarantee the finished threads will be enqueued on time before system crashes.
>
> In my experiments in Linux32, I found classlib tests (run "ant test" in working_classlib) failed from time to time due to this issue. The error message is new thread cannot be created.
>
> It would be great if the threading guys can think of some good solution for this issue.
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>


-- 
http://xiao-feng.blogspot.com

Re: [jira] Commented: (HARMONY-3956) [drlvm][thread] memory leak in thread pool implementation

Posted by Xiao-Feng Li <xi...@gmail.com>.
I think it is a duplicate. I will close it with a link to H3289.

On 5/25/07, Alexey Varlamov (JIRA) <ji...@apache.org> wrote:
>
>     [ https://issues.apache.org/jira/browse/HARMONY-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498940 ]
>
> Alexey Varlamov commented on HARMONY-3956:
> ------------------------------------------
>
> Do you think this issue duplicates HARMONY-3289 ?
>
> > [drlvm][thread] memory leak in thread pool implementation
> > ---------------------------------------------------------
> >
> >                 Key: HARMONY-3956
> >                 URL: https://issues.apache.org/jira/browse/HARMONY-3956
> >             Project: Harmony
> >          Issue Type: Bug
> >          Components: DRLVM
> >         Environment: Linux
> >            Reporter: Yu-Nan He
> >
> > I found a very interesting design issue in threading part about the thread pool implementation. This introduces memory leaks and sometimes fails classlib tests. This can be a potential issue for server side applications.
> > The current thread pool is implemented through WeakReference( ThreadWeakRef  ), i.e., each created Java thread will be managed with a WeakReference, and the reference object will be put into the referenceQueue when the thread exits. But the enqueuing of the finished thread depends on WeakReference processing of the JVM, hence depending on the GC collection cycle. If GC has large enough free space, not to collect the heap and process WeakReference, the finished threads will not be returned to the referenceQueue.  It is possible that, lots of finished threads are not enqueued before a GC happen, gradually running out native memory for new thread creation.
> >
> > To work around this issue, TM can trigger GC from time to time when the referenceQueue is empty. But I guess a right solution is to use some other mechanism for thread pool implementation. Since thread entity is scare resource for the system, we probably donot want to depend its management on the WeakReference processing, since there is no specified behavior on the timing of WeakReference processing. This is the key issue. That means, even the TM triggers GC from time to time, we cannot guarantee the finished threads will be enqueued on time before system crashes.
> > In my experiments in Linux32, I found classlib tests (run "ant test" in working_classlib) failed from time to time due to this issue. The error message is new thread cannot be created.
> > It would be great if the threading guys can think of some good solution for this issue.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>


-- 
http://xiao-feng.blogspot.com

Re: [jira] Commented: (HARMONY-3956) [drlvm][thread] memory leak in thread pool implementation

Posted by Xiao-Feng Li <xi...@gmail.com>.
I think it is a duplicate. I will close it with a link to H3289.

On 5/25/07, Alexey Varlamov (JIRA) <ji...@apache.org> wrote:
>
>     [ https://issues.apache.org/jira/browse/HARMONY-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498940 ]
>
> Alexey Varlamov commented on HARMONY-3956:
> ------------------------------------------
>
> Do you think this issue duplicates HARMONY-3289 ?
>
> > [drlvm][thread] memory leak in thread pool implementation
> > ---------------------------------------------------------
> >
> >                 Key: HARMONY-3956
> >                 URL: https://issues.apache.org/jira/browse/HARMONY-3956
> >             Project: Harmony
> >          Issue Type: Bug
> >          Components: DRLVM
> >         Environment: Linux
> >            Reporter: Yu-Nan He
> >
> > I found a very interesting design issue in threading part about the thread pool implementation. This introduces memory leaks and sometimes fails classlib tests. This can be a potential issue for server side applications.
> > The current thread pool is implemented through WeakReference( ThreadWeakRef  ), i.e., each created Java thread will be managed with a WeakReference, and the reference object will be put into the referenceQueue when the thread exits. But the enqueuing of the finished thread depends on WeakReference processing of the JVM, hence depending on the GC collection cycle. If GC has large enough free space, not to collect the heap and process WeakReference, the finished threads will not be returned to the referenceQueue.  It is possible that, lots of finished threads are not enqueued before a GC happen, gradually running out native memory for new thread creation.
> >
> > To work around this issue, TM can trigger GC from time to time when the referenceQueue is empty. But I guess a right solution is to use some other mechanism for thread pool implementation. Since thread entity is scare resource for the system, we probably donot want to depend its management on the WeakReference processing, since there is no specified behavior on the timing of WeakReference processing. This is the key issue. That means, even the TM triggers GC from time to time, we cannot guarantee the finished threads will be enqueued on time before system crashes.
> > In my experiments in Linux32, I found classlib tests (run "ant test" in working_classlib) failed from time to time due to this issue. The error message is new thread cannot be created.
> > It would be great if the threading guys can think of some good solution for this issue.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>


-- 
http://xiao-feng.blogspot.com

[jira] Commented: (HARMONY-3956) [drlvm][thread] memory leak in thread pool implementation

Posted by "Xiao-Feng Li (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HARMONY-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499003 ] 

Xiao-Feng Li commented on HARMONY-3956:
---------------------------------------

I think it is a duplicate. I will close it with a link to H3289.



-- 
http://xiao-feng.blogspot.com


> [drlvm][thread] memory leak in thread pool implementation
> ---------------------------------------------------------
>
>                 Key: HARMONY-3956
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3956
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Linux
>            Reporter: Yu-Nan He
>
> I found a very interesting design issue in threading part about the thread pool implementation. This introduces memory leaks and sometimes fails classlib tests. This can be a potential issue for server side applications. 
> The current thread pool is implemented through WeakReference( ThreadWeakRef  ), i.e., each created Java thread will be managed with a WeakReference, and the reference object will be put into the referenceQueue when the thread exits. But the enqueuing of the finished thread depends on WeakReference processing of the JVM, hence depending on the GC collection cycle. If GC has large enough free space, not to collect the heap and process WeakReference, the finished threads will not be returned to the referenceQueue.  It is possible that, lots of finished threads are not enqueued before a GC happen, gradually running out native memory for new thread creation. 
>  
> To work around this issue, TM can trigger GC from time to time when the referenceQueue is empty. But I guess a right solution is to use some other mechanism for thread pool implementation. Since thread entity is scare resource for the system, we probably donot want to depend its management on the WeakReference processing, since there is no specified behavior on the timing of WeakReference processing. This is the key issue. That means, even the TM triggers GC from time to time, we cannot guarantee the finished threads will be enqueued on time before system crashes. 
> In my experiments in Linux32, I found classlib tests (run "ant test" in working_classlib) failed from time to time due to this issue. The error message is new thread cannot be created.
> It would be great if the threading guys can think of some good solution for this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (HARMONY-3956) [drlvm][thread] memory leak in thread pool implementation

Posted by "Xiao-Feng Li (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HARMONY-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Xiao-Feng Li closed HARMONY-3956.
---------------------------------

    Resolution: Duplicate

Duplicate to HARMONY-3289

> [drlvm][thread] memory leak in thread pool implementation
> ---------------------------------------------------------
>
>                 Key: HARMONY-3956
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3956
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Linux
>            Reporter: Yu-Nan He
>
> I found a very interesting design issue in threading part about the thread pool implementation. This introduces memory leaks and sometimes fails classlib tests. This can be a potential issue for server side applications. 
> The current thread pool is implemented through WeakReference( ThreadWeakRef  ), i.e., each created Java thread will be managed with a WeakReference, and the reference object will be put into the referenceQueue when the thread exits. But the enqueuing of the finished thread depends on WeakReference processing of the JVM, hence depending on the GC collection cycle. If GC has large enough free space, not to collect the heap and process WeakReference, the finished threads will not be returned to the referenceQueue.  It is possible that, lots of finished threads are not enqueued before a GC happen, gradually running out native memory for new thread creation. 
>  
> To work around this issue, TM can trigger GC from time to time when the referenceQueue is empty. But I guess a right solution is to use some other mechanism for thread pool implementation. Since thread entity is scare resource for the system, we probably donot want to depend its management on the WeakReference processing, since there is no specified behavior on the timing of WeakReference processing. This is the key issue. That means, even the TM triggers GC from time to time, we cannot guarantee the finished threads will be enqueued on time before system crashes. 
> In my experiments in Linux32, I found classlib tests (run "ant test" in working_classlib) failed from time to time due to this issue. The error message is new thread cannot be created.
> It would be great if the threading guys can think of some good solution for this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (HARMONY-3956) [drlvm][thread] memory leak in thread pool implementation

Posted by "Alexey Varlamov (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HARMONY-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498940 ] 

Alexey Varlamov commented on HARMONY-3956:
------------------------------------------

Do you think this issue duplicates HARMONY-3289 ?

> [drlvm][thread] memory leak in thread pool implementation
> ---------------------------------------------------------
>
>                 Key: HARMONY-3956
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3956
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Linux
>            Reporter: Yu-Nan He
>
> I found a very interesting design issue in threading part about the thread pool implementation. This introduces memory leaks and sometimes fails classlib tests. This can be a potential issue for server side applications. 
> The current thread pool is implemented through WeakReference( ThreadWeakRef  ), i.e., each created Java thread will be managed with a WeakReference, and the reference object will be put into the referenceQueue when the thread exits. But the enqueuing of the finished thread depends on WeakReference processing of the JVM, hence depending on the GC collection cycle. If GC has large enough free space, not to collect the heap and process WeakReference, the finished threads will not be returned to the referenceQueue.  It is possible that, lots of finished threads are not enqueued before a GC happen, gradually running out native memory for new thread creation. 
>  
> To work around this issue, TM can trigger GC from time to time when the referenceQueue is empty. But I guess a right solution is to use some other mechanism for thread pool implementation. Since thread entity is scare resource for the system, we probably donot want to depend its management on the WeakReference processing, since there is no specified behavior on the timing of WeakReference processing. This is the key issue. That means, even the TM triggers GC from time to time, we cannot guarantee the finished threads will be enqueued on time before system crashes. 
> In my experiments in Linux32, I found classlib tests (run "ant test" in working_classlib) failed from time to time due to this issue. The error message is new thread cannot be created.
> It would be great if the threading guys can think of some good solution for this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (HARMONY-3956) [drlvm][thread] memory leak in thread pool implementation

Posted by "Xiao-Feng Li (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HARMONY-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498625 ] 

Xiao-Feng Li commented on HARMONY-3956:
---------------------------------------

This is indeed a very interesting issue. WeakReference probably should
not be used for critical resource management.

Thanks,
xiaofeng



-- 
http://xiao-feng.blogspot.com


> [drlvm][thread] memory leak in thread pool implementation
> ---------------------------------------------------------
>
>                 Key: HARMONY-3956
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3956
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Linux
>            Reporter: Yu-Nan He
>
> I found a very interesting design issue in threading part about the thread pool implementation. This introduces memory leaks and sometimes fails classlib tests. This can be a potential issue for server side applications. 
> The current thread pool is implemented through WeakReference( ThreadWeakRef  ), i.e., each created Java thread will be managed with a WeakReference, and the reference object will be put into the referenceQueue when the thread exits. But the enqueuing of the finished thread depends on WeakReference processing of the JVM, hence depending on the GC collection cycle. If GC has large enough free space, not to collect the heap and process WeakReference, the finished threads will not be returned to the referenceQueue.  It is possible that, lots of finished threads are not enqueued before a GC happen, gradually running out native memory for new thread creation. 
>  
> To work around this issue, TM can trigger GC from time to time when the referenceQueue is empty. But I guess a right solution is to use some other mechanism for thread pool implementation. Since thread entity is scare resource for the system, we probably donot want to depend its management on the WeakReference processing, since there is no specified behavior on the timing of WeakReference processing. This is the key issue. That means, even the TM triggers GC from time to time, we cannot guarantee the finished threads will be enqueued on time before system crashes. 
> In my experiments in Linux32, I found classlib tests (run "ant test" in working_classlib) failed from time to time due to this issue. The error message is new thread cannot be created.
> It would be great if the threading guys can think of some good solution for this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.