Update 01-Jun-2014: The campaign’s over, raised $6,473 this time. Thanks everyone!
We are doing it again:
http://www.excelsiorjet.com/charity
What would be the good places beside JGO and Javalobby to post this announcement?
To moderators: Any chance to get a sticky topic here and/or in the “Engines, Libraries and Tools” forum until May 31? Thanks.
Tweetin’…
Cas 
Very cool.
I just ordered my Win+Linux copy
I just made my first build with this, and I must say I’m impressed with how easy it all is. A native build of a project with some libs and dlls is literally just a few clicks away.
Very impressive stuff.
Performance is comparable to HotSpot; it’s actually a bit slower and in my audio project I get some audio glitching caused by some performance spikes.
I didn’t expect that tbh, but it might have something to do with this being the standard edition that’s missing some features. And my audio project is very sensitive to that due to extremely low audio buffer sizes; I’m sure this is normally not an issue with other projects.
For 100$ for both Win+Linux and knowing you’re helping a good cause, you can’t beat this.
Just like everybody else you’ll have to keep thing fresh all by yourself Sticky posts are usually completely ignored on forums, as they are a sign of stale content. It’s in everybody’s interest to let your thread naturally evolve. :-*
You can verify your hypothesis by compiling your audio project with an Evaluation Package, which has all features of the Enterprise Edition.
Also make sure that nothing is left to JIT. Assuming you are on Windows:
rem Enable console
gui - YourAudioProject.exe
SET JETVMPROP=-Djet.jit.loud
YourAudioProject.exe
You should get something like the following printed to the console:
*** JIT: sun.reflect.misc.Trampoline JITCompiler: compile sun.reflect.misc.Trampoline JITCompiler: compilation finished in 9ms, classes: 1 JITCompiler: total compilation time: 9ms, classes: 1
If you notice instead that your application’s classes get JIT-compiled en masse, you need to check your project settings on the Classes page.
Okay, then can I cross-post to “Engines, Libraries and Tools” and see how it will evolve there? 
I don’t really think which board it’s in has a whole lot of effect on how much exposure a topic gets, because members (people who can give feedback) simply look in their “Unread Posts,” and guests look at the “Recent Posts” and “High Profile Topics” on the homepage. Just my 2 cents, if someone has evidence otherwise, let’s hear it.
Plus, X-posting splits the conversation awkwardly, wouldn’t want that.
EDIT: Also, on topic, this is great! AOT compilation for Java has always fascinated me, but there’s never really been anything decent outside of JET.
Thanks for the tips, dleskov.
I didn’t see any JIT activity in the output, so I guess it got properly AOT compiled.
After doing a bit more research, the performance glitches might actually not have anything to do with JET because with that particular test I did, these audio glitches actually do happen occasionally on HotSpot as well. I probably shouldn’t have tested some new code and JET at the same time :persecutioncomplex:
So although these glitches do seem to happen a bit more regularly in JET, it’s most likely a problem in my own code; and a problem I’ve hit before in my project (float denormals causing very unpredictable and extreme performance spikes).
So never mind me, JET is awesome
I’ll definitely check out the evaluation of the full product too to see if it improves performance, but I’m not really having a performance issue there. Running hundreds of DSP objects at about 350 audio-frames per second in real time still doesn’t doesn’t consume more than about 15% of one core on average, so ~1-2 percent difference doesn’t really matter to me (because that’s the difference I’m seeing with HotSpot).
Float denormals? Care to elaborate?
sun.reflect.misc.Trampoline is always JIT-compiled, so you should see at least those four lines.
Float denormalization is basically when a float gets nearer to 0 than a float can represent normally, and not 0 (see also Float.MIN_NORMAL). My understanding is that this gets treated in the CPU as sort of an exception and doing computations on that will be really slow. I never knew just how slow it can be so I sort of ignored the issue, until I actually got hit by it. It can make things like 25 times slower or worse.
It’s a common issue in DSP code where often signals are calculated to ‘tend towards zero’ (things like slowly decaying signals etc).
Sorry I wasn’t clear.
I did see that Trampoline class getting JIT-ed, but nothing of my own code.
[JIT compiler] compile sun.reflect.misc.Trampoline
[JIT compiler] compilation finished in 12ms, classes: 1
If you don’t need denormals I’d expect you could just use a JNI method to set the FP-control word per thread.
Technically that would be against the JNI spec, which says a native method altering FPU flags is responsible for saving and restoring them. My colleague says HotSpot used to have an option to forcefully save/restore those flags, most likely to guard against the misbehaving native methods.
A more reasonable route would be to simply wrap the entry/exit of the SP with FP-control word change/restores. Although control word changes are pricey individually, amortized across the SP update will probably make them very cheap. That way there’s no concern about gotcha outside of these regions.
Is it possible to script this?
Once you have created the respective project files, compilation and packaging from the command line is as simple as
jc =p project.prj
xpack project.jpn
(There is a twist if you want to further protect the native executable. See section “Installations protected by license managers” in the “Deployment Automation” Chapter of the User’s Guide.)
Is that what you were asking?
Tomorrow is the last day of the campaign, so just bumping up the thread.