Menu
▾
▴
xmlvm-developers — Used to discuss development of XMLVM itself. Not for developers using XMLVM.
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
(38) |
Apr
(34) |
May
(20) |
Jun
(46) |
Jul
(6) |
Aug
(13) |
Sep
(50) |
Oct
(27) |
Nov
(10) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(7) |
Feb
(3) |
Mar
(4) |
Apr
|
May
|
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Arno P. <ar...@pu...> - 2011-09-22 18:48:18
|
Guys, some of you may know that XMLVM features a little showcase application: Xokoban (sources are in xmlvm/demo/android/xokoban). We've had Xokoban in the Apple AppStore for over two years and Apple has just accepted an updated version. The visual has not changed much but the internal implementation has radically changed. For one, Xokoban now makes use of advanced Android API (activity lifecycle, layout manager, internationalization). One benefit of using Android's layout manager is that Xokoban now is a universal binary that runs on iPhone as well as iPad. However the biggest change is that the new version of Xokoban was cross-compiled with the new C backend. This is a radical departure from the old Objective-C backend. One of the many changes is that applications cross-compiled with the C backend now bundle a garbage collector for better Java compliance. Xokoban is (to my knowledge) the first app that Apple accepted and that was generated with the new C backend. An important milestone. The new version of Xokoban is the combined effort of many people. If you are on this mailing list you will know who they are. Many thanks to all of them! New big changes are in the pipeline. Look forward to source-code-level debugging from Eclipse/Netbeans of cross-compiled Java applications. :) Arno http://itunes.apple.com/us/app/xokoban/id322302746?ls=1&mt=8 |
|
From: Arno P. <ar...@pu...> - 2011-09-22 04:18:06
|
OK, I checked a bit deeper. The core of the problem is that there is a goto that jumps *into* a try-block. This is not permissible and causes the problems. We'll work on it... Arno On 9/21/11 9:02 PM, Shai wrote: > That doesn't seem to solve the problem although it does fail in a slightly different way. It still doesn't pass via the try section. > I did revert the Java side changes entirely so now my code is back to doing return directly from the switch nested in the try/catch. > > BTW the LLVM issue I was experiencing was due to a bug in my native code, I would recommend making LLVM the default since the compile time is a huge improvement (at least 3 times faster). > > Thanks. > > > >> thanks for the nice analysis! It seems that the exception context was >> not properly restored when exiting a switch statement. Can you please >> check if the attached patch fixes this problem? > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Xmlvm-developers mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-developers |
|
From: Shai <sha...@ya...> - 2011-09-22 04:02:14
|
That doesn't seem to solve the problem although it does fail in a slightly different way. It still doesn't pass via the try section. I did revert the Java side changes entirely so now my code is back to doing return directly from the switch nested in the try/catch. BTW the LLVM issue I was experiencing was due to a bug in my native code, I would recommend making LLVM the default since the compile time is a huge improvement (at least 3 times faster). Thanks. > thanks for the nice analysis! It seems that the exception context was > not properly restored when exiting a switch statement. Can you please > check if the attached patch fixes this problem? |
|
From: Arno P. <ar...@pu...> - 2011-09-22 02:26:41
|
whenever you change Java iOS classes, you need to run "ant gen-c-wrappers". Once the wrappers are generated, you should only make modifications between the //XMLVM_BEGIN* and //XMLVM_END* markers. By default we insert the XMLVM_NOT_IMPLEMENTED(). When you compile an iOS application, the Java iOS classes are still required (for computing the vtable). When the C code is emitted, the manually written code in the wrappers is injected into the C files that were created during cross-compilation. Arno On 9/21/11 4:59 AM, Panayotis Katsaloulis wrote: > I have a strangle situation with C backend, iFireworks and generated C code. Of course before doing anything I performed an "ant clean" to be sure. > > For optimization reasons, I've played a bit with the Java iOS compatibility library and made it a bit "lighter", to see what happens. > One of the changes was to remove some unneeded private static methods. > Then I re-created the C-wrappers with the new java files. > > To be sure that the changes were performed, I enter > xmlvm.jar:/main/main.jar:/iphone/cocoa-compat-lib.jar:... > and had a look at the generated files there if they have inherited the change (they did). > I took as an example the CGRect class and its static properties. > > Then I went to iFireworks and recreated the Xcode project. Unfortunately the generated files there recreated some methods, i.e. the CLINIT method which was of course missing from the generated C wrappers. > Not only that, it tagged it as "unimplemented" (which by default was an empty statement). > Of course at this point the application broke. > > If I removed "exit(-1)" from the not-implemented function, the application worked perfectly. So it seems that the problems was with the injected (but not anymore required) CLINT method. > > How can we solve this? Am I missing something? > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Xmlvm-developers mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-developers |
|
From: Arno P. <ar...@pu...> - 2011-09-21 20:28:39
|
thanks for the nice analysis! It seems that the exception context was
not properly restored when exiting a switch statement. Can you please
check if the attached patch fixes this problem?
Arno
On 9/21/11 3:12 AM, Shai wrote:
> OK, I had code that looked something like this (pseudo code):
>
> public void method(SomeClass obj) {
> try {
> switch(field) {
> case 1:
>
> ...
> return;
>
> case 2:
>
> ...
> return;
>
> case 3:
>
> ...
> return;
>
> case 4:
>
> ...
> return;
>
> // no default
>
> }
>
> } catch(Throwable t) {
> System.out.println("Fail message...");
>
> }
>
> }
>
>
> I initially changed all the return methods to breaks which didn't really solve the problem.
> Then I moved the switch statement to a different private method (while keeping the break instead of return) and replaced the System.out with printStackTrace().
> Problem solved...
>
> I'm open for ideas on how to investigate this further.
>
>
>> I think the problem is in the generated code. I have a
>> curThread_w23657aaac46b1c17 variable which is indeed invalid and the reason it
>> is invalid is that the TRY that corresponds to that uniqueId wasn't executed
>> before I reached this line.
>> So I'm guessing that this is a problem with the code generator, I'm
>> trying to review my Java source code to see if there is something special there.
>> The only thing that I can think of is that I have a large switch case in that
>> code and most cases invoke return rather than breaking which is a less common
>> practice.
>> The switch is surrounded by a try/catch pair which might also be related in some
>> way...
>> I'll try making some code modifications to see if it works around the issue.
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
|
|
From: Panayotis K. <pan...@pa...> - 2011-09-21 17:01:39
|
On 21 Σεπ 2011, at 2:59 μ.μ., Panayotis Katsaloulis wrote: > I have a strangle situation with C backend, iFireworks and generated C code. Of course before doing anything I performed an "ant clean" to be sure. Replying to my own self... but probably this might help someone else. It looks to me that the wrappers still need the original java classes to regenerate the C code (for optimizations probably?). This is the reason for this strange behavior. |
|
From: Paul P. <bay...@gm...> - 2011-09-21 16:24:07
|
Haha - yes, I don't know that "fortunate" is the right word. That's
interesting you say that the TRY corresponding to that unique id wasn't
executed. If that's the case, there's our issue. I have a case I can run
to verify, so I will check into that tonight. Thanks for the information!
In my case, the error occurs when doing a XMLVM_MEMCPY to restore the
exception environment right before trying to return from a synchronized
method. I'll do my best to get back with you soon.
Paul
On Wed, Sep 21, 2011 at 5:12 AM, Shai <sha...@ya...> wrote:
> OK, I had code that looked something like this (pseudo code):
>
> public void method(SomeClass obj) {
> try {
> switch(field) {
> case 1:
>
> ...
> return;
>
> case 2:
>
> ...
> return;
>
> case 3:
>
> ...
> return;
>
> case 4:
>
> ...
> return;
>
> // no default
>
> }
>
> } catch(Throwable t) {
> System.out.println("Fail message...");
>
> }
>
> }
>
>
> I initially changed all the return methods to breaks which didn't really
> solve the problem.
> Then I moved the switch statement to a different private method (while
> keeping the break instead of return) and replaced the System.out with
> printStackTrace().
> Problem solved...
>
> I'm open for ideas on how to investigate this further.
>
>
> > I think the problem is in the generated code. I have a
> > curThread_w23657aaac46b1c17 variable which is indeed invalid and the
> reason it
> > is invalid is that the TRY that corresponds to that uniqueId wasn't
> executed
> > before I reached this line.
> > So I'm guessing that this is a problem with the code generator, I'm
> > trying to review my Java source code to see if there is something special
> there.
> > The only thing that I can think of is that I have a large switch case in
> that
> > code and most cases invoke return rather than breaking which is a less
> common
> > practice.
> > The switch is surrounded by a try/catch pair which might also be related
> in some
> > way...
> > I'll try making some code modifications to see if it works around the
> issue.
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>
|
|
From: Panayotis K. <pan...@pa...> - 2011-09-21 11:59:14
|
I have a strangle situation with C backend, iFireworks and generated C code. Of course before doing anything I performed an "ant clean" to be sure. For optimization reasons, I've played a bit with the Java iOS compatibility library and made it a bit "lighter", to see what happens. One of the changes was to remove some unneeded private static methods. Then I re-created the C-wrappers with the new java files. To be sure that the changes were performed, I enter xmlvm.jar:/main/main.jar:/iphone/cocoa-compat-lib.jar:... and had a look at the generated files there if they have inherited the change (they did). I took as an example the CGRect class and its static properties. Then I went to iFireworks and recreated the Xcode project. Unfortunately the generated files there recreated some methods, i.e. the CLINIT method which was of course missing from the generated C wrappers. Not only that, it tagged it as "unimplemented" (which by default was an empty statement). Of course at this point the application broke. If I removed "exit(-1)" from the not-implemented function, the application worked perfectly. So it seems that the problems was with the injected (but not anymore required) CLINT method. How can we solve this? Am I missing something? |
|
From: Panayotis K. <pan...@pa...> - 2011-09-21 11:47:46
|
On 21 Σεπ 2011, at 8:26 π.μ., Markus Heberling wrote: > There is no reason. Will change it after I finished my current patches. Right now I am in the process of (re)creating a compatibility library in Java for iOS, which will also be compatible with Android devices (and possibly others). For this reason, it would be a good idea to be synchronized and discuss changes in the Java library, so that no duplicate work will be performed :) |
|
From: Shai <sha...@ya...> - 2011-09-21 10:12:46
|
OK, I had code that looked something like this (pseudo code):
public void method(SomeClass obj) {
try {
switch(field) {
case 1:
...
return;
case 2:
...
return;
case 3:
...
return;
case 4:
...
return;
// no default
}
} catch(Throwable t) {
System.out.println("Fail message...");
}
}
I initially changed all the return methods to breaks which didn't really solve the problem.
Then I moved the switch statement to a different private method (while keeping the break instead of return) and replaced the System.out with printStackTrace().
Problem solved...
I'm open for ideas on how to investigate this further.
> I think the problem is in the generated code. I have a
> curThread_w23657aaac46b1c17 variable which is indeed invalid and the reason it
> is invalid is that the TRY that corresponds to that uniqueId wasn't executed
> before I reached this line.
> So I'm guessing that this is a problem with the code generator, I'm
> trying to review my Java source code to see if there is something special there.
> The only thing that I can think of is that I have a large switch case in that
> code and most cases invoke return rather than breaking which is a less common
> practice.
> The switch is surrounded by a try/catch pair which might also be related in some
> way...
> I'll try making some code modifications to see if it works around the issue.
|
|
From: Shai <sha...@ya...> - 2011-09-21 08:30:25
|
> I'm trying to look into this, it seems that the particular curThread is > broken the first time I reach this method. I'm trying to understand the > concept and why it fails for this particular case, as far as I understand > curThread ##uniqueId represents the unwindable stack of a particular stack frame > created within a try block. I just need to figure out how it got corrupted. > Maybe its a threading issue since I know the code I'm using has thread > related issues (which is why I occasionally get exceptions there). I think the problem is in the generated code. I have a curThread_w23657aaac46b1c17 variable which is indeed invalid and the reason it is invalid is that the TRY that corresponds to that uniqueId wasn't executed before I reached this line. So I'm guessing that this is a problem with the code generator, I'm trying to review my Java source code to see if there is something special there. The only thing that I can think of is that I have a large switch case in that code and most cases invoke return rather than breaking which is a less common practice. The switch is surrounded by a try/catch pair which might also be related in some way... I'll try making some code modifications to see if it works around the issue. |
|
From: Shai <sha...@ya...> - 2011-09-21 07:40:53
|
Hi Paul, I wouldn't necessarily define this as fortunate ;-) Thanks for the tips, I normally keep the stack traces disabled by default. I'm trying to look into this, it seems that the particular curThread is broken the first time I reach this method. I'm trying to understand the concept and why it fails for this particular case, as far as I understand curThread ##uniqueId represents the unwindable stack of a particular stack frame created within a try block. I just need to figure out how it got corrupted. Maybe its a threading issue since I know the code I'm using has thread related issues (which is why I occasionally get exceptions there). Thanks. > >Hi Shai, > >Fortunately you're not alone in experiencing the XMLVM_MEMCPY issue. I am looking into this as well. Let me know if you find anything. > >Aside from enabling NullPointerException and ArrayIndexOutOfBoundsException checks, you can also enable stack traces: > >#define XMLVM_ENABLE_STACK_TRACES > >All 3 of those are handy, but keep in mind they significantly decrease performance, especially checking for NullPointerExceptions. > >Thanks, >Paul |
|
From: Markus H. <ma...@ti...> - 2011-09-21 05:26:47
|
There is no reason. Will change it after I finished my current patches. Markus Am 21.09.2011 um 01:33 schrieb Panayotis Katsaloulis: > Is there any reason this class is internal to UIPrintInteractionController ? > Up to now, all these classes were externals and I'd prefer to have a continuity in the API. > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Xmlvm-developers mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-developers |
|
From: Panayotis K. <pan...@pa...> - 2011-09-20 23:33:33
|
Is there any reason this class is internal to UIPrintInteractionController ? Up to now, all these classes were externals and I'd prefer to have a continuity in the API. |
|
From: Paul P. <bay...@gm...> - 2011-09-20 21:02:08
|
Hi Shai, Fortunately you're not alone in experiencing the XMLVM_MEMCPY issue. I am looking into this as well. Let me know if you find anything. Aside from enabling NullPointerException and ArrayIndexOutOfBoundsException checks, you can also enable stack traces: #define XMLVM_ENABLE_STACK_TRACES All 3 of those are handy, but keep in mind they significantly decrease performance, especially checking for NullPointerExceptions. Thanks, Paul On Tue, Sep 20, 2011 at 1:36 PM, Shai <sha...@ya...> wrote: > > I just committed support for array bounds check. You need to compile > > > your app with #define XMLVM_ENABLE_ARRAY_BOUNDS_CHECK to enable it. > > Thanks allot. I just updated to get this and unfortunately it doesn't solve > that issue. I'll try to dig in and figure this one out > > >> 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. > > > > We do bzero arrays as well as initialize all variables. Can you send a > > specific example? > > I didn't run into a problem here. I was just trying to figure out if there > are other minor incompatibilities between XMLVM's C backend and the JVM > specification that you are aware of (I gave the zeroing of arrays as an > example). I can't really think of anything specific right now. > > Anyway, thanks again. I'll take another look at the code and try to figure > out why LLVM isn't working and the cause of this crash. > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Xmlvm-developers mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-developers > |
|
From: Panayotis K. <pan...@pa...> - 2011-09-20 18:38:36
|
On 20 Σεπ 2011, at 9:15 μ.μ., Aaron VonderHaar wrote: > I guess I'll leave it to Markus since he's volunteering. > > But out of curiosity, it's preferred to use new values 0, 1, ... > instead of making them equal to the kCGEncodingMacRoman, > kCGEncodingFontSpecific values? > > --Aaron This is an enumeration, so by definition the values are always 0,1,.. unless stated differently. Remember that this is the Java backend, so we need to provide some numeric values, since the "kCGEncodingMacRoman" means nothing to Java. |
|
From: Shai <sha...@ya...> - 2011-09-20 18:37:00
|
> I just committed support for array bounds check. You need to compile > your app with #define XMLVM_ENABLE_ARRAY_BOUNDS_CHECK to enable it. Thanks allot. I just updated to get this and unfortunately it doesn't solve that issue. I'll try to dig in and figure this one out >> 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. > > We do bzero arrays as well as initialize all variables. Can you send a > specific example? I didn't run into a problem here. I was just trying to figure out if there are other minor incompatibilities between XMLVM's C backend and the JVM specification that you are aware of (I gave the zeroing of arrays as an example). I can't really think of anything specific right now. Anyway, thanks again. I'll take another look at the code and try to figure out why LLVM isn't working and the cause of this crash. |
|
From: Aaron V. <gru...@gm...> - 2011-09-20 18:15:48
|
I guess I'll leave it to Markus since he's volunteering.
But out of curiosity, it's preferred to use new values 0, 1, ...
instead of making them equal to the kCGEncodingMacRoman,
kCGEncodingFontSpecific values?
--Aaron
On Tue, Sep 20, 2011 at 2:32 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:
>
> On 20 Σεπ 2011, at 8:45 π.μ., Aaron VonderHaar wrote:
>
>> Oh, thanks for catching that! I had put it off since I didn't quite
>> have time to figure out how the other kCG* constants were implemented,
>> and apparently forgot to come back to it.
>>
>
> This is how they are usually implemented:
>
>
> @XMLVMSkeletonOnly
> public final class CGTextEncoding {
>
> public static final int FontSpecific = 0;
> public static final int MacRoman = 1;
>
> private CGTextEncoding() {
> }
> }
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>
|
|
From: Arno P. <ar...@pu...> - 2011-09-20 12:09:12
|
On 9/20/11 4:12 AM, Shai wrote: > 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> I just committed support for array bounds check. You need to compile your app with #define XMLVM_ENABLE_ARRAY_BOUNDS_CHECK to enable it. > 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. We do bzero arrays as well as initialize all variables. Can you send a specific example? >> 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. Sorry, but you are the first. :) Arno |
|
From: Shai <sha...@ya...> - 2011-09-20 11:12:07
|
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. |
|
From: Arno P. <ar...@pu...> - 2011-09-20 10:20:20
|
On 9/19/11 11:19 PM, Shai wrote:
> Hi,
> I'm running into quite a few issues in the generated code from XML VM.
> Our existing code base is huge and doesn't depend on Android/iPhone
> API's, we use native methods where appropriate but most of the work is
> in Java.
>
> For hello world apps things are starting to work as expected but I'm
> running into some hard difficulties when implementing elaborate
> functionality. The biggest problem I'm facing right now is a bad pointer
> in this code:
> {
> XMLVM_MEMCPY(curThread_w23657aaac46b1c17->fields.java_lang_Thread.xmlvmExceptionEnv_,
> local_env_w23657aaac46b1c17, sizeof(XMLVM_JMP_BUF)); goto label5; };
I can't help you with the information you've provided. We have
successfully cross-compiled complex applications but of course I can't
rule out that there are still issues with the C code generation. Can you
distill a small, self-contained example that would allow me to debug this?
> The debugger is claiming that curThread is 0x1. I would investigate this
> but I'm not sure where to start, I enabled null pointer exception checks
> but that didn't help. I couldn't find the code to enable array boundary
> checks, some of our code really needs that since race conditions could
> trigger a failure and constantly synchronizing is impractical for our
> code which is very performance sensitive. BTW Shouldn't such checks be
> on by default? I understand the cost but since quite allot of third
> party code expects this to work for Java...
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.
> 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?
> I also tried to get java.util.Calendar working without much luck, it has
> too many red dependencies in IBM specific system functions to get
> working. I don't need the entire API and can easily implement it
> natively however I was wondering, can I replace a "System" class with my
> own? E.g. can I just write a java.util.Calendar/GregorianCalendar class
> and have it take precedence over the classes that are generated from the
> Harmony bytecode?
> I'm guessing that I can obviously just change the redclass list to
> remove Calendar entirely and just build a class of my own but I'd rather
> not change XMLVM since I only need a subset of calendar and probably
> won't be able to reimplement calendar in a generic enough way for
> everyone's needs.
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
Arno
|
|
From: Panayotis K. <pan...@pa...> - 2011-09-20 09:32:44
|
On 20 Σεπ 2011, at 8:45 π.μ., Aaron VonderHaar wrote:
> Oh, thanks for catching that! I had put it off since I didn't quite
> have time to figure out how the other kCG* constants were implemented,
> and apparently forgot to come back to it.
>
This is how they are usually implemented:
@XMLVMSkeletonOnly
public final class CGTextEncoding {
public static final int FontSpecific = 0;
public static final int MacRoman = 1;
private CGTextEncoding() {
}
}
|
|
From: Markus H. <ma...@ti...> - 2011-09-20 07:06:34
|
I can fix that in my patch. Am 20.09.2011 um 07:45 schrieb Aaron VonderHaar: > Oh, thanks for catching that! I had put it off since I didn't quite > have time to figure out how the other kCG* constants were implemented, > and apparently forgot to come back to it. > > I can take another look at it as time permits me (hopefully in the next week). > > --Aaron V. > > On Mon, Sep 19, 2011 at 5:17 PM, Panayotis Katsaloulis > <pan...@pa...> wrote: >> After a second thought, I think the definition of CGContext.selectFont should be >> >> public void selectFont(String name, float size, int textEncoding) >> >> while also the CGTextEncoding constants should be defined. >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2dcopy1 >> _______________________________________________ >> Xmlvm-developers mailing list >> Xml...@li... >> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers >> > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Xmlvm-developers mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-developers |
|
From: Shai <sha...@ya...> - 2011-09-20 06:19:26
|
Hi,
I'm running into quite a few issues in the generated code from XML VM. Our existing code base is huge and doesn't depend on Android/iPhone API's, we use native methods where appropriate but most of the work is in Java.
For hello world apps things are starting to work as expected but I'm running into some hard difficulties when implementing elaborate functionality. The biggest problem I'm facing right now is a bad pointer in this code:
{ XMLVM_MEMCPY(curThread_w23657aaac46b1c17->fields.java_lang_Thread.xmlvmExceptionEnv_, local_env_w23657aaac46b1c17, sizeof(XMLVM_JMP_BUF)); goto label5; };
The stack does include java_lang_Thread so curThread should be fine:
#5 0x000bb420 in java_lang_Thread_run0___long
#6 0x008e43e8 in threadRunner ()
#7 0x0090b3b0 in GC_inner_start_routine ()
#8 0x00907ee4 in GC_call_with_stack_base ()
#9 0x0090af87 in GC_start_routine ()
#10 0x92a50ed9 in _pthread_start ()
#11 0x92a546de in thread_start ()
The debugger is claiming that curThread is 0x1. I would investigate this but I'm not sure where to start, I enabled null pointer exception checks but that didn't help. I couldn't find the code to enable array boundary checks, some of our code really needs that since race conditions could trigger a failure and constantly synchronizing is impractical for our code which is very performance sensitive. BTW Shouldn't such checks be on by default? I understand the cost but since quite allot of third party code expects this to work for Java...
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.
I also tried to get java.util.Calendar working without much luck, it has too many red dependencies in IBM specific system functions to get working. I don't need the entire API and can easily implement it natively however I was wondering, can I replace a "System" class with my own? E.g. can I just write a java.util.Calendar/GregorianCalendar class and have it take precedence over the classes that are generated from the Harmony bytecode?
I'm guessing that I can obviously just change the redclass list to remove Calendar entirely and just build a class of my own but I'd rather not change XMLVM since I only need a subset of calendar and probably won't be able to reimplement calendar in a generic enough way for everyone's needs.
Thanks.
|
|
From: Aaron V. <gru...@gm...> - 2011-09-20 05:45:21
|
Oh, thanks for catching that! I had put it off since I didn't quite have time to figure out how the other kCG* constants were implemented, and apparently forgot to come back to it. I can take another look at it as time permits me (hopefully in the next week). --Aaron V. On Mon, Sep 19, 2011 at 5:17 PM, Panayotis Katsaloulis <pan...@pa...> wrote: > After a second thought, I think the definition of CGContext.selectFont should be > > public void selectFont(String name, float size, int textEncoding) > > while also the CGTextEncoding constants should be defined. > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Xmlvm-developers mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-developers > |
