Re: Using APR for Harmony's native link to the OS?

Artem Aliev wrote:
> Hello,
>
> 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.

You are correct about that. There is no free call. Memory can
be either reused by calling apr_pool_clear or freed by calling
apr_pool_destroy.
Because for any IO system object (file, socket, mutex, etc.)
you usually need some additional struct, the standard implementation
look like:
struct my_struct;
my_struct = malloc(...);
my_truct->fh = open(...)
... do something with object
close(my_truct->fh);
free(my_struct);

With APR it would look like:

struct my_struct;
pool = apr_pool_create(...)
my_struct = apr_palloc(pool, ...)
my_truct->fh = apr_xxx_open(pool, ...)
... do something with object
apr_xxx_close(my_truct->fh);
apr_pool_destroy(pool);

Since each created object has it's own cleanup function
when calling apr_pool_destroyed all objects created with
that pool will call it's cleanup functions, so there is
no need to call the apr_xxx_close.



> So APR memory model should be extended. For example portlib memory
> pools could be integrated into APR.

Not needed.
For any Java object you are actually always doing what apr_pool does
anyhow, meaning that during the object lifecycle you allocate memory
and on GC you must free all allocated resources.
If there is a need for short lived memory standard malloc/free can
be used (of course except for apr_* objects).

> 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.

Right, but on most systems 'read' is not a system call.
If you look at the source code for MSVCRT read, you'll see it's
much more complex then APR implementation.

Anyhow since APR is portable across majority of platforms,
there is no need to have the portlib->hyfile_read thought.

Regards,
Mladen.