db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-739) Reduce generated code required to access a parameter's value
Date Thu, 01 Dec 2005 21:54:32 GMT
    [ 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 


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:
For more information on JIRA, see:

View raw message