[jira] Commented: (DERBY-739) Reduce generated code required to access a parameter's value

["Kathey Marsden (JIRA)" <de...@db.apache.org>]

    [ http://issues.apache.org/jira/browse/DERBY-739?page=comments#action_12359088 ] 

Kathey Marsden commented on DERBY-739:
--------------------------------------

Going back one step on this issue, I'd like to understand how to trace the error in the generated code back to the offending source since there is no friendly stack trace providing a trail.     To get the offending class, I  set 

derby.debug.true=DumpClassFile

I could then just run java on the class to see the e1() method was the trouble maker.   The decompiler I sometimes use wouldn't work on the class because it was malformed, so stopped there and filed the bug. What would have been  the best next steps to trace back to the source of the problem?


> 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

>
> 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