db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-739) Reduce generated code required to access a parameter's value
Date Fri, 10 Feb 2006 04:58:57 GMT
    [ http://issues.apache.org/jira/browse/DERBY-739?page=comments#action_12365839 ] 

Daniel John Debrunner commented on DERBY-739:
---------------------------------------------

A minor update on the " interesting separate idea, to reduce the number of constant pool entries
..." from the original description.

First I was wrong that integer constants outside the range of -1 to 5 require constant pool
entries in the class file.
The byte code instruction set has ICONST_n instructions to push the values -1 to 5, BIPUSH
to push an 8-bit value
and SIPUSH to push a 16bit value. Thus only integer constants greater than 32,767 require
a integer constant pool entry.
The push(int) method in the class BCMethod already uses these instructions.

Secondly, I think that the best way to handle this, if it is an issue, is to solve this in
the byte code compiler and not its
callers (ie the sql compiler). The push(int) method could push a value greater than 32767
by calculating it from values
less than equal to 32767 so as not to use a constant pool entry. E.g. to push 100,000 perform
 
(3 * 32,767) + 1699 == 100,000

ICONST_3
SIPUSH 32767
IMUL
SIPUSH 1699
IADD

Then it's 9 bytes of instruction versus 3 bytes plus an constant pool entry.


> Reduce generated code required to access a parameter's value
> ------------------------------------------------------------
>
>          Key: DERBY-739
>          URL: http://issues.apache.org/jira/browse/DERBY-739
>      Project: Derby
>         Type: Sub-task
>     Reporter: Daniel John Debrunner
>     Assignee: Kathey Marsden
>     Priority: Minor
>      Fix For: 10.2.0.0
>  Attachments: derby739_2.diff
>
> When accessing a parameter the generated code is:
> this.pvs.getParameter(23);
> A slightly shorter form would be
> this.getParameter(23);
> if a getParameter() method was added to BaseActivation that simply did:
>  protected final DataValueDescriptor getParameter(int n) { return pvs.getParameter(n);
}
> ------------------------------
> An interesting separate idea, to reduce the number of constant pool entries would be
to have multiple getParameter() methods, that took values from 0-5 to construct the actual
parameter number.
> getParameter(3) -- >  3 parameter (0 based)
> getParameter(2, 1) --> 13 parameter (2*6 + 1)
> getParameter(5, 1, 4) --> 190 parameter (5*36 + 1*6+ 4)
> above the limit of three args, revert to getParameter(n)
> This should probably be a separate issue and probably would increease code size which
would not help DERBY-732 , it's a tradeoff between constant pool entries and code size.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message