Bill Barker wrote:
"Costin Manolache" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Bill Barker wrote:
If I understand you correctly, you want MsgAjp to use ByteBuffer instead
of byte []. At the cost of never supporting JDK 1.3 ever again, this
would probably actually improve the performance of ChannelSocket (after
changing it to use a blocking SocketChannel).
The biggest difference will be if it's a 'direct' buffer, i.e. zero copy.
Classpath ( gcj, kaffe, etc ) also has byte buffer support - so it should
be ok, if anyone needs jdk1.3, they can use the old code.
Yes, the idea was that it would be a direct buffer.
But where is the code ?
It's on my hard-drive. Unlike Remy's APR stuff, o.a.jk is supposed to be a
pretty stable package(s) at this point. I can't just check in stuff like
this without a lot of testing to make sure that it doesn't break anything
more than JDK 1.3 compatibility ;-).
That's why C has conditional compilation - and java has some
options-controlled ugly 'if' code :-) It doesn't break anything if the
option/def is not selected ( just makes the code a bit uglier ). This
way even JDK1.3 will be happy.
The biggest problem in JNI ( and probably - in Java playing nice with
other languages and the rest of the platform ) is the objects and
buffers moving around almost randomly. Yes, it may improve a bit the
garbage collection speed - so people can create millions of garbage
objects without thinking about it, unlike most other languages that
require you to think when allocating objects - but it is the kind of
optimization that has disastrous consequences on the rest of the
systems. Luckily gcj and kaffe and mono don't do this crazy thing.
Direct buffers is one band-aid that should be used whenever possible.
Costin
Costin
Rémy
This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is
PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you
may not read, copy, or distribute this message or any attachment. If you
received this communication in error, please notify us immediately by
e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
