I think it is a duplicate. I will close it with a link to H3289.
On 5/25/07, Alexey Varlamov (JIRA) <[EMAIL PROTECTED]> 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
