RE: Jk2: pools and memory

[GOMEZ Henri]

The current code is using some 'interesting' tricks with the jk_pools -
it does some funny buffer allocations on the stack and use the buffer
to create a pool ( which itself is allocated on the stack ).

While this may have some performance benefits, the code is 
extremely hard
to read, and doesn't 'map' to the new APR pool.

What I would like to do ( if nobody objects ) is to use:
 struct jk_pool {

  ...
  jk_pool_t *(*createChild)( jk_pool_t *_this, int sizeHint );
  ...
 }

The pool_open, etc will be removed - same for the buf[] based 
allocation.

why not. Frankly you love too much java :)

Given that we recycle the endpoint ( and it's pool ) - I don't 
think we'll
loose too much. If APR is used we'll use apr pools anyway ( which don't
have support for the funny stack allocation ). For non-APR case, malloc
will be fine.

I'll also go ahead and replace all mallocs in the code to use the
pools.

However, I'm not an C expert ( or even a C programmer ) - if 
I'm missing
something please let me know.

free must match malloc, that's all for now :=)
Question could be about recycling pools.

PS: Costin, you go too fast, I didn't recognize anything in jk2 ;)

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Jk2: pools and memory

[costinm]

On Fri, 7 Dec 2001, GOMEZ Henri wrote:

 The pool_open, etc will be removed - same for the buf[] based
 allocation.

 why not. Frankly you love too much java :)

I just like simple things.

Stack-allocating buffers and then creating ( stack-allocated ) jk_pools
in the buffer is not that simple, and making it work with apr_pools was
extremely difficult ( or at least I couldn't figure any decent way ).


 However, I'm not an C expert ( or even a C programmer ) - if
 I'm missing
 something please let me know.

 free must match malloc, that's all for now :=)
 Question could be about recycling pools.

That's simple - we do recycle the endpoint ( to preserve the open
connection ). So we don't need to malloc/free its pool on each request,
only when we connect and free.

It seems malloc is considered expensive ( it requires some sync in
mutithreaded environment ) - it's not that bad as in java, but still it's
easier to keep the block allocated.

 PS: Costin, you go too fast, I didn't recognize anything in jk2 ;)

Is it that bad ?

I'm almost done - the only big change I'll do is finally abstract the
message handler ( but that'll be similar with what we have on the java
side ).

The only important thing that changed so far was data structures - and
it's mostly making public what was private in ajp/mod_jk/lb - in order to
make it easier to manage and give config handlers control, and to be able
to use it in jni and other workers as well.

I also added virtual methods, so apr pools and apache logger can be used.

Costin



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]