db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Any ideas for debugging a byte code generation problem
Date Sun, 20 Mar 2005 04:48:14 GMT
Andrew McIntyre wrote:

>On Sun, 20 Mar 2005 02:25:17 +0000 (UTC), RPost <rp0428@pacbell.net> wrote:
>>Couldn't find anything in the JVM spec about a limit on constants
>The limit is 65535 entries in the constant pool, as the index into the
>constant pool is an unsigned short. See:
>Not sure if this would help with debugging the problem, but I modified
>the Unabstract class that was a part of my jdk142-only compile patch
>to dump the constant pool. From the errors in Kathey's original email,
>it appears that there may be too few constants in the constant pool
>and the indexes for the class info and superclass info in the constant
>pool are incorrect (tag 1, UTF8, instead of tag 7, classinfo). If the
>constant pool has too few entries, then in the output of
>DumpConstantPool, the last few entries in the constant pool will read
>"error!". If the constant pool has more entries than the index value,
>then the output for the access flags and class info will be obviously
>incorrect. If the constant pool actually has the correct number of
>entries, then maybe the class info was just written out with bad
Dan helped me with the constant pool problem yesterday.  There were too
many entries in the constant pool.  The jad output seemed to be the
actual number % 65535.   He saw a few areas where we could improve in
this area.    I think I would feel more comfortable letting him comment
on them since I am really a newbie in this area and am bound to mess it
up.  He is away for a few weeks now but promises a post to Derby on the
topic when he gets back.
In general  a couple of the big reclamation items were:

Reuse single set of names for expression methods and fields in generated
Add new method that allows optional creation of a generated field for
holder purposes.

I could post my REALLY rough notes on my crash byte code generation
course with Dan if anyone wants to see them,  filled with holes and
probably as many untruths in the translation, but it is probably better
for Dan to post when he gets back.

With the query I am dealing with, there are also issues with method
sizes.   Dan suggested a generic split working (under the covers of
MethodBuilder) for methods that take zero arguments and whose stack
depth drops to zero
sometime after they reach 55000 code size.

 The one I am grappling with is fillResultSet which is already a spin
off of execute because of a byte code generation problem and is 236K at
the moment.  It does not fall into the category above because the stack
is not empty.   I don't really have questions intelligent enough to ask
right now.  But if anyone has ideas and input I really welcome it. 



View raw message