You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <de...@db.apache.org> on 2005/12/01 21:46:35 UTC
[jira] Created: (DERBY-739) Reduce generated code required to access a parameter's value
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
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
[jira] Commented: (DERBY-739) Reduce generated code required to access a parameter's value
Posted by "Satheesh Bandaram (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-739?page=comments#action_12361450 ]
Satheesh Bandaram commented on DERBY-739:
-----------------------------------------
Kathey, if you are done with this bug, can you resolve it (and close if appropriate)?
> 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
[jira] Closed: (DERBY-739) Reduce generated code required to access a parameter's value
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-739?page=all ]
Kathey Marsden closed DERBY-739:
--------------------------------
> 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
[jira] Assigned: (DERBY-739) Reduce generated code required to access a parameter's value
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-739?page=all ]
Kathey Marsden reassigned DERBY-739:
------------------------------------
Assign To: Kathey Marsden
> 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
[jira] Updated: (DERBY-739) Reduce generated code required to
access a parameter's value
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-739:
---------------------------------
Fix Version/s: 10.1.3.2
> Reduce generated code required to access a parameter's value
> ------------------------------------------------------------
>
> Key: DERBY-739
> URL: https://issues.apache.org/jira/browse/DERBY-739
> Project: Derby
> Issue Type: Sub-task
> Components: Services
> Affects Versions: 10.1.3.2
> Reporter: Daniel John Debrunner
> Assignee: Kathey Marsden
> Priority: Minor
> Fix For: 10.1.3.2, 10.2.1.6
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-739) Reduce generated code required to
access a parameter's value
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-739?page=all ]
Kathey Marsden updated DERBY-739:
---------------------------------
Component: Services
> 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
> Components: Services
> 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
[jira] Commented: (DERBY-739) Reduce generated code required to
access a parameter's value
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Commented: (DERBY-739) Reduce generated code required to access a parameter's value
Posted by "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
Re: [jira] Commented: (DERBY-739) Reduce generated code required to access a parameter's value
Posted by Mamta Satoor <ms...@gmail.com>.
Hi Kathey,
I am not very familiar with code generation but I looked at your latest
patch anyways and it seems to address Dan's concern. So, it looks good to
me.
thanks,
Mamta
On 12/13/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
>
> Kathey Marsden (JIRA) wrote:
>
> > [
> http://issues.apache.org/jira/browse/DERBY-739?page=comments#action_12360362]
> >
> > Kathey Marsden commented on DERBY-739:
> > --------------------------------------
> >
> > Date: Tue Dec 13 13:06:11 2005
> > New Revision: 356621
> >
> > URL: http://svn.apache.org/viewcvs?rev=356621&view=rev
>
> I belive there is a problem with this patch.
>
> - mb.callMethod(VMOpcode.INVOKEINTERFACE, (String) null,
> "getParameter",
> + mb.callMethod(VMOpcode.INVOKEVIRTUAL, (String) null,
> "getParameter",
> ClassName.DataValueDescriptor, 1);
>
>
> The new call to "getParameter" says that the declared type of the method
> is picked up from the type on the stack, which is 'this', which will
> have the type of the generated class. But the getParameter() method is
> defined by BaseActivation. Thus the declared type should be passed in.
>
> Dan.
>
>
>
Re: [jira] Commented: (DERBY-739) Reduce generated code required
to access a parameter's value
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Kathey Marsden (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-739?page=comments#action_12360362 ]
>
> Kathey Marsden commented on DERBY-739:
> --------------------------------------
>
> Date: Tue Dec 13 13:06:11 2005
> New Revision: 356621
>
> URL: http://svn.apache.org/viewcvs?rev=356621&view=rev
I belive there is a problem with this patch.
- mb.callMethod(VMOpcode.INVOKEINTERFACE, (String) null,
"getParameter",
+ mb.callMethod(VMOpcode.INVOKEVIRTUAL, (String) null,
"getParameter",
ClassName.DataValueDescriptor, 1);
The new call to "getParameter" says that the declared type of the method
is picked up from the type on the stack, which is 'this', which will
have the type of the generated class. But the getParameter() method is
defined by BaseActivation. Thus the declared type should be passed in.
Dan.
[jira] Commented: (DERBY-739) Reduce generated code required to access a parameter's value
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-739?page=comments#action_12360362 ]
Kathey Marsden commented on DERBY-739:
--------------------------------------
Date: Tue Dec 13 13:06:11 2005
New Revision: 356621
URL: http://svn.apache.org/viewcvs?rev=356621&view=rev
> 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
[jira] Commented: (DERBY-739) Reduce generated code required to access a parameter's value
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-739?page=comments#action_12359091 ]
Daniel John Debrunner commented on DERBY-739:
---------------------------------------------
Not sure exactly what you are asking, but I'll tell you what I did.
Given the information you had provided, I assumed the query was generating a method that was too big for the class file format in some way.
[this could be a wrong assumption, maybe it's really a bug in the jump offset calculation]
De-compiled the class with javap, which comes with a JDK. Javap decompiles the class into bytecode, not Java source code. I think this tends to be ok because Derby's query nodes are basically writing at the byte code level. If you try to convert a generated class back into Java source there's a good chance it will fail. Javap also seems to not require other classes in the class path, it just takes the class contents and dumps it.
javap -private -c -classpath . org.apache.derby.exe.ac601a400fx0107xe7aaxc957x0000001ac9880
You can also use the JVM as you did to get some idea of the verifier error.
java -verify -classpath ".;../classes" org.apache.derby.exe.ac601a400fx0107xe7aaxc957x0000001ac9880
While looking at the class I saw some code I didn't understand and thus I investigated. This was the multiple calls to setStorableDataValue() that were passing "java.lang.Integer". It seemed strange to me that type information was being passed as a runtime value.
After finding the source for setStorableDataValue (using Eclipse), I then searched for *generated* callers of setStorableDataValue. Since these will not appear in Eclipse's Java method references search, I always search for the method name in double quotes. "setStorableDataValue". This is how the method name is usually passed into the byte code compiler by the query nodes, ie a String in Java code. This took me to the only caller, ParameterNode, and from there I could see when & why it was being called.
Then seeing there were 360+ parameters in the SQL statement I thought let's see how a parameter is accessed in the generated code, because every byte saving there is going to be multipled by 360+. So that lead to this task.
A similar exercise could be taken for column reference, since there are also 360 of those. Any way to make the corresponding node generate less code will be multipled 360 times, and then for AND and OR nodes and any other nodes repeated in the query.
These tend to be simple fixes, as they are small contained improvements, and thus have a small pay-back. E.g. fixing parameter node and column reference node might allow this specific query to succeed, but the underlying problem would still be there , and a similar query with a couple more of the repeated lines may fail. The good thing is that these small fixes are good in themselves, even if they are not solving the more generic problem.
I actually thought I would start looking at seeing how the compilation system could generic the code for '(ITEMID=? AND VERSIONID=?)' once and re-use for all the repeated uses. But I got distracted by the low-hanging fruit.
I'm still thinking about how to be able to compile similar blocks once and re-use them, not sure if it would be best at the language level, or handle it at the byte code level.
> 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
[jira] Updated: (DERBY-739) Reduce generated code required to access a parameter's value
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-739?page=all ]
Kathey Marsden updated DERBY-739:
---------------------------------
Attachment: (was: derby739.diff)
> 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
[jira] Updated: (DERBY-739) Reduce generated code required to access a parameter's value
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-739?page=all ]
Kathey Marsden updated DERBY-739:
---------------------------------
Attachment: derby739.diff
As per the description of this bug , this patch adds a getParameter() method to BaseActivation so that code can be generated as
this.getParameter(position) instead of this.pvs.getParameter(postition).
For an IN predicate the maximum number of parameters increased from 2700 to 3400.
I'll commit this tomorrow if noone sees issues.
> 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
> Attachments: derby739.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
[jira] Updated: (DERBY-739) Reduce generated code required to
access a parameter's value
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-739:
---------------------------------
Affects Version/s: 10.1.3.2
> Reduce generated code required to access a parameter's value
> ------------------------------------------------------------
>
> Key: DERBY-739
> URL: https://issues.apache.org/jira/browse/DERBY-739
> Project: Derby
> Issue Type: Sub-task
> Components: Services
> Affects Versions: 10.1.3.2
> Reporter: Daniel John Debrunner
> Assignee: Kathey Marsden
> Priority: Minor
> Fix For: 10.2.1.6
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-739) Reduce generated code required to access a parameter's value
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-739?page=all ]
Kathey Marsden resolved DERBY-739:
----------------------------------
Fix Version: 10.2.0.0
Resolution: Fixed
Submtted second patch to resolve issue with the first patch not specifying the declaring class with callMethod. Thanks Dan for the catch.
New Revision: 357057
URL: http://svn.apache.org/viewcvs?rev=357057&view=rev
> 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
[jira] Updated: (DERBY-739) Reduce generated code required to access a parameter's value
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-739?page=all ]
Kathey Marsden updated DERBY-739:
---------------------------------
Attachment: derby739_2.diff
Here is a patch to correct the issue that callMethod did not specify the declaring class.
Passed derbyall except for the following 3 tests that fail on the nightly test report as well.
http://db.apache.org/derby/derby_tests.html
derbyall/storeall/storeall.fail:store/lockTableVti.sql
derbyall/storeall/storeall.fail:store/onlineBackupTest2.sql
derbyall/storeall/storeall.fail:storetests/st_1.sql
> 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
> 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