harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [drlvm][threading] H3288 -- the mods look great. Is it ready to commit?
Date Fri, 16 Mar 2007 16:50:48 GMT
Nathan Beyer wrote:
> This is the set of patches for replacing APR thread constructs with
> PThread constructs, correct?

Pthreads on Linux, Win32 on Windows.

> I don't have any objections to doing this, but I did have a question
> about the removal of the all APR thread constructs. The patch doesn't
> seem to remove all APR thread references, but indicates that this is
> being completed, what's the status on that?

The purpose of the patch is not to eliminate APR completely.
Rather, I wanted to be able to allocated and deallocated mutexes, conditions
and thread blocks freely and explicitly, which was not possible using APR
interfaces due to APR memory pools.

H-3288 makes it possible. The ultimate goal (H-3289 -- work in progress) is to
make use of possibility to deallocate thread blocks to fix the leak associated
with the thread blocks.

> I think that this patch simplifies things, but I want to make sure we
> also get the full benefit of not having to manage the APR memory pools
> and eliminate the seemingly unused overhead.

Actually, before the 3288 patch, each thread in DRLVM created as much as 4 (!)
distinct memory pools, that is
1) apr_thread_t 2) hythread_t 3) VM_thread 4) JVMTI_Thread,
and the hythread_t pool was never deallocated (in fact, it could not be
deallocated at all due to allocation of fat monitors, which can live much
longer than the thread).

After 3288, it reduces the number of pools per thread to two latter,
which I think are deallocated on thread termination.


Weldon asked:
> Re: [drlvm][threading] H3288 Is it ready to commit?

I've still has not pinpointed the root cause of occasional segfault on
gc.SynchronizedFinilazersTest.
Probably we should not commit regressing changes.


Mime
View raw message