apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Fwd: Re: Using APR for Harmony's native link to the OS?
Date Thu, 23 Feb 2006 21:00:00 GMT
There's a thread over at harmony on using APR


I thought someone from around here might be interested in following along
and/or helping out. I find the whole JVM GC<->apr mem pool thing quite


PS: not subscribed here...

----- Forwarded message from Artem Aliev <artem.aliev@gmail.com> -----

From: Artem Aliev <artem.aliev@gmail.com>
Date: Wed, 22 Feb 2006 21:37:42 +0300
Subject: Re: Using APR for Harmony's native link to the OS?
To: harmony-dev@incubator.apache.org
Reply-To: harmony-dev@incubator.apache.org
List-Id: <harmony-dev.incubator.apache.org>


I did some experiments with developing harmony portlib over APR.
The main problem for me is an APR memory model.
It is well suitable only for transactions.

There is no free() memory call. You could destroy only whole memory pool.
This works well only for short living threads or tasks. This is
typical for HTTP server, not Java application. (All apr_*_create
functions require apr_pool_t* as argument)
I tried to create sub-pool for each object as workaround. This hits
memory footprint and performance.
So APR memory model should be extended. For example portlib memory
pools could be integrated into APR.

The second problem is ugly "Developing wrappers over wrappers".
For example, a call stack for read() method will look like following,
in case we will develop Portlib over APR:

Java_java_io_FileInputStream_read() calls
portlib->hyfile_read(portLib...) calls
apr_file_read(apr_file, ...) calls
read(....) system calls.

If we change portlib interface to be apr compatible, call stack could
be a little bit better:

Java_java_io_FileInputStream_read(...) calls
portLib->apr_file_read(portLib->files[fd], ...) calls
read(...) system calls.

And definitely we will need to add a lot of new functions into APR.

Thank you,
Artem Aliev
Intel Middleware Products Division

----- End forwarded message -----

View raw message