PS3 and GCJ

Just a question I’m asking myself for a time:

Would it cost that much effort to write an Java AOT compiler for the PS3 based on GCJ?

If it is possible, we have to convince sony to to that, because porting a java title to Runtime(PC) or vice versa still should be eaiser then with C++. Furthermore Sony can rely on well tested code (GCJ) for threading, …

I mean, for PC I prefer a Runtime because it’s JIT can optimize the code for individual CPU(s) in the gamer’s pc, which even may not available during the engine developing. But to me a runtime for a console seems idioteque, since the hardware never changes and performance counts so much.

Any comments are welcome :wink:

The problem is there aren’t enough quality games written in Java yet (or companies using Java for games) for the consoles to care to create a VM. Consider yourself a pioneer :slight_smile: This generation of consoles probably won’t have a VM (I hope I am wrong), but the next might.

Oh, you got my wrong.

I don’t want a VM on the PS3, a want an Ahead of Time compilier, like an ordinary one for C++, which compiles Java code to the PS3. Moreover, I am questioning myself, whether the GCJ (GNU compiler for Java) would be a good starting point.

The next point is that i don’t believe on of us could the job, because you’ll need to have many information on the ps3 hardware. Ideal would be to convince Sony to do that, arguing the Java langauge can solve developer problems, e.g. the threading issues. And perhaps some modificatinos of the well tested and stable GCJ compiler are sufficient.

Btw. I doubt that even the console generatino after x-box360,ps3 and the n-revolution have enough memory, … to run a VM and and IMHO the benfits of a VM are not that great for consoles, at least in the near future.

Oh - I see what you mean - but the same point still applies - not enough games and not enough companies developing with it.

yes you’re right! let’s conquer the pc-market first, THEN make a strategy for the consoles. :wink:

You will still need some sort of runtime to do garbage collection, will you not?

ps3’s blu ray drive will have a java vm, but whether software can use it that i’m not sure! also ps3 will have an opengl variation, so a binding to that and the java vm could make an excellent and attactive choice but its all just speculation atm.

SWp hits it on the head.

The hardest pasrt of implermenting Java in any form is getting an acceptable GC, particularly one aceptable for games work.

Hotspot has just reached that point after many years of rocket-science development by soem of the best VM gusy in the business.

GCJ has a crappy basic mark-sweep collector which is totally unsuited to games.

Next?

Jet’s collector and compiler are pretty much state-of-the-art too :slight_smile: Seeing as Jet can build a dll… presumably… it’s a matter of just a bit of jiggery pokery to get it to compile for Xbox, at least?

(Anyone with problems with GC might just consider going back to the Old Ways and using object pools - worked a treat for Flux)

Cas :slight_smile:

Well, don’t know much about Java AOTs, I have just mentioned GCJ because its open source and I thought of the pricing barrier. But if gcj isn’t suitable because of the gc and JET is, fine. Anyway, if we can’t get a VM for a console, at least the Java language should be there. And at a time when consoles hae enough memory for a VM these will follow.

P.S. I’d be lucky, if anyone can convince me that the perfomance of a VM on the ps3/x-box360/nintendo revolution could ce compared to native code.

Performance of a VM on normal XBox will be identical to any other x86 VM if it uses Hotspot, won’t it? But that new PowerPC based one, I don’t know… I do know that the VM on my G5 seems considerably slower than the equivalent on Windows but it might be my imagination.

Cas :slight_smile:

Form the CPU’s point of view of course, but a PC often has much more memory. A normal X-Box has 64 MB Total Memory, I doubt that enough for a Java VM and all its optimizations. I assume the same for the ps3 with its 256MB. If the the X-Box 360 has 512MB, as I believe, that should be enough, but Java on a MS console before .NET? :wink:

[quote=“princec,post:11,topic:25337”]
Try some benchmarks that don’t involve UI.

[quote=“swpalmer,post:13,topic:25337”]

The one thing that really crawls on the mac is rendering to a BufferedImage that has had GetRaster applied to it. I got around 40fps on the PC and less than 1fps ( yes thats ‘one’ fps) on the mac.

[quote=“Alan_W,post:14,topic:25337”]

WOW, that is in need for some serious tweaking :-\

VMs are very nice and wend we all have 10+GHz with 1T Ram and no hard discs they will be the only option (a bit of sci-fi :wink: ), but One thing that i hate about VMs is the constant tweaking that one has to do >:(

Yep, The Mac JRE is overly sensitive to the image type, I think images are converted to a type that is compatible with Quartz, the Apple UI rendering engine. Getting the raster probably means that any sort of behind the scenes acceleration is gone, so if the BufferedImage isn’t already TYPE_INT_ARGB_PRE or whatever it is that the Mac likes, there is probably an ugly software loop that converts it every time it’s drawn.

Or was this using a “compatible” image type? In which case that really stinks. In ANY case if you aren’t happy with that performance file a bug report with Apple. Apple engineers have stated publicly that Apple uses their bug database as an indicator of what the developers want and they may adjust their priorities accordingly.

Graphics operations in general have always been a sore spot on the Apple JRE… it’s actually a lot better now than it was.

Nothing to do with VM’s. Ask any commercial game developer what they spend most of their time doing (answer: constant tweaking to make it work fast on all the different hardware ;)).

One of the advantages to VM’s is that you can do this tweaking once only, and because it’s a VM all machines will behave that way, instead of doing it once for every conceivable machine.

EDIT: the problem hilighted above is that the VM itself is not being implemented consistenly from machine to machine; that is normally considered a “bug” :slight_smile:

See my post above about the sensitivity of Mac to the pixel format of your images :). TI think you still have to tweak on multiple platforms even when you have a VM… though it may be less of an issue, since the Sun folks have already done some of that tweaking for you (e.g. enabling certian feturs in the Java2D pipeline based on the available graphcis hardware etc.)

64mb would be just fine for “smaller” games (up to the size of Tribal Trouble I would say) and with 256mb you have lots of memory. Remember that there isnt an OS which grabs 128mb just for the fun of it.

If the PS3 allows me to run java stuff, I would buy it. Heck… I would even buy a xbox360 under that circumstances :wink:

COmmon misconception.

To hit equivalent spoeed to a JIT with an AOT you need to bloat the code significantly (basically create multiple evrsiosn of the code in one executable to cover the same kinds of decisions that the JIT cna make at run time by recompiling to optimize the code paths.)

End result-- for equivalent speed, a VM and JIT is actually singificantly smaller then precompiled code.