Re: [xmlvm-dev] Several questions about generated code

[Shai <sha...@ya...>]

Thanks for the prompt reply.


>We have a #define for NPE checks but no runtime checks for array bounds. 
>If your code depends on this, it might be a clue why things don't work. 
>Adding array bound checks shouldn't be that difficult.


That must be the problem it has all the markings of a memory corruption & that code occasionally fails with array boundary issues which despite repeated efforts we were unable to resolve in a performant way. 

Do you have any tips for implementing the checks? 
My general thought is to just create a macro next to the null check macro (with the option to switch it off/on) that performs a check against the array length and given offset.
Then just place that macro in the current XSLT code although I'm not exactly sure as to where?
I'm guessing here (and obviously for the other types too):
<xsl:when test="@type = 'byte'"><xsl:text>((java_lang_Byte*) argsArray[</xsl:text><xsl:value-of select="$index"/><xsl:text>])->fields.java_lang_Byte.value_</xsl:text></xsl:when>


While we are on the subject are there other things from the JVM spec that weren't implemented, off the top of my head I think we also depend on variables defaulting to 0/false especially in arrays.


>> Another issue I'm facing is when I select the IDE option to modernize
>> the project to LLVM things stop working. I'm guessing its related to
>> endianess of math functions? Moving to LLVM would be huge both because
>> of the performance boost on ARM and because of the MUCH shorter compile
>> time.
>
>No idea. What do you mean with "stop working"? It doesn't compile or the 
>executable crashes?


Neither. The code just doesn't behave correctly and its hard for me to see the reason for the failure. I see a method call in the debugger and values effectively get garbled, math calculations produce the wrong result (which has quite a few implications in the code). I can investigate this further and let you know if I come up with something, I just hoped I wasn't the first to run into this.


>We call those "proxy classes": classes in src/xmlvm2c/lib/proxies have 
>precedence over the original Harmony version. You should grab the 
>original version from the Harmony sources and then modify it to what you 
>need. You can add a native method and then run "ant gen-c-wrappers" 
>which will put a skeleton for the native method in src/xmlvm2c/lib/native


Thanks.