db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5210) Use java.nio.ByteBuffer in client.net.Request
Date Sat, 30 Apr 2011 19:36:03 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Knut Anders Hatlen updated DERBY-5210:
--------------------------------------

    Attachment: d5210-1a.diff

Attaching a patch that removes the bytes_ and offset_ fields from the Request class and replaces
them with a java.nio.ByteBuffer field. The Request class and its subclasses were changed to
use the new field. Apart from the mechanical changes (that is, replacing the direct byte array
accesses with accesses via ByteBuffer), the patch changes the following:

1) Changed the meaning of the length parameter in the ensureLength() method. Previously, it
represented the minimum total length of the byte buffer, whereas it now represents the minimum
number of available bytes at the end of the buffer. (Actually, the existing comments in the
method match the new behaviour, so it looks like that was how it was intended to work.) This
seemed like a reasonable simplification now that ensureLength() needed to be rewritten in
any case (because it needed to check and reallocate a ByteBuffer instead of a byte array)
and also all calls needed to be changed (because almost all referred to the removed offset_
field).

2) As I updated various pieces of the code, I noticed that there was a lot of duplication.
The places where I had seen a helper method that did the exact same thing, I changed the code
to use the helper methods instead of just mechanically translating it.

3) Removed some helper methods in client.am.SignedBinary and client.am.FloatingPoint since
we now use methods in java.nio.ByteBuffer that provide the same functionality.

The patch adds 199 lines and removes 414 lines, so it results in a net removal of 215 lines.

All the regression tests ran cleanly with the patch. I'm currently running some performance
tests to see if these changes affect the performance negatively.

> Use java.nio.ByteBuffer in client.net.Request
> ---------------------------------------------
>
>                 Key: DERBY-5210
>                 URL: https://issues.apache.org/jira/browse/DERBY-5210
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Client
>    Affects Versions: 10.9.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         Attachments: d5210-1a.diff
>
>
> We should see if we could use a java.nio.ByteBuffer instead of a byte array in org.apache.derby.client.net.Request,
similar to what we did for DDMWriter in DERBY-2936. ByteBuffer provides some helper methods
that allows us to simplify the code that puts multi-byte values into the buffer (like ByteBuffer.putShort(),
putInt(), putLong()). It may also be a first step on the way to using a CharsetEncoder to
encode strings without going via an intermediate throw-away byte array (see DERBY-5068 for
details).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message