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 03:48:34 GMT
RPost wrote:

>Kathey Marsden <kmarsdenderby@...> writes:
>
>  
>
>>>Another thing I would try is paring down the query to make it as small
>>>as possible while still reproducing the problem.
>>>
>>>
>>>      
>>>
>>Aye, there's the rub.  In general with these byte code generation
>>problems it is the size of the query that is the problem.  We are
>>dealing with strict JVM specification  limits on things like method
>>sizes.   So, we split methods into smaller methods and then we have too
>>many constants.  Robbing Peter to pay Paul only works for so long.
>>
>>
>>    
>>
>
>I create a java class with 30,000 constants of the form:
>
>int i1= 1,i2= 1,i3= 1,i4= 1,i5= 1,i6= 1,i7= 1,i8= 1,i9= 1,i10= 1;
>
>Java 1.3.1 compiles it ok but jad 1.5.7g gives an error when trying to 
>decompile it. A dialog box titled 'Program Error' with 'jad.exe has generated 
>errors and will be closed by Windows. You will need to restart the program. An 
>error log is being created.'
>
>Couldn't find anything in the JVM spec about a limit on constants
>
>
>
>
>
>  
>
I actually should have said constant pool entries for which there is a
limit.
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#88659.
Seem to be passed that issue now which was not due to too much method
splitting but other factors and now need to split up one of those >
65535 methods.   I am  actually working on an older release of
Cloudscape but the issues are relevant to Derby, so we'll have to
address them here too.    Currently in our architecture  there is  a
poorly defined upper bound on the complexity of queries due to  the
limits on the byte code generated. 


Mime
View raw message