[ 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
