Skip to main content

Just-In-Time compiler in Java

8 replies [Last post]
faslam
Offline
Joined: 2008-01-19
Points: 0

Hi,

If I write JIT compiler in Java then how can I will be able to convert it into machine code? It is because it cannot be in bytecode. I know one can use GNU-GCJ however, it produces really big executable which is not good for small devices.

Secondly, I cannot find JIT compiler code in Squawk code. Can someone tell me that this C code is located where?

I have another question. I wish to produce optimized suite file on PC (instead on device/SunSpot) so that I can check its size and see how much size reduction it gives. Please give me some guideline, that how to do this.

looking for your reply,
Faisal

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
eric_arseneau
Offline
Joined: 2004-07-15
Points: 0

- if you write JIT compiler in Java then how can I convert it to machine code ?
-- vm2c module in Squawk is a starting point to translate Java source into C source
-- the module is currently used to translate the GC into C, so we can get native speeds

- Cannot find JIT compiler code in Squawk
-- there is no JIT, and is likely to never be
-- if you are looking for good JIT, then see openJDK or phoneME
-- Squawk intends to do AOT (Ahead-Of-Time) compilation, as some of our intended targets may not be able to support JIT

- wish to produce optimized suite file on PC, instead of on device
-- I am not sure I completely understand here, Squawk already produces an partially optimized suite on desktop, it is part of its split VM design
-- the device/vm expects an execute in place compact format

Message was edited by: eric_arseneau

faslam
Offline
Joined: 2008-01-19
Points: 0

Thank you Eric Arseneau, for your reply. However, I need some more help.

- [i]"Squawk intends to do AOT (Ahead-Of-Time) compilation, as some of our intended targets may not be able to support JIT"[/i]

yes mica2 has Harvard architecture and cannot support JIT. But we can still use an interpreter on it and running Java code already on mica2. The problem with AOT compilation is lack of portability. It will give speed but compromise portability. I thought Squwak is highly portable? Do you use AOT on SunSpot motes?

- [i]"Squawk already produces an partially optimized suite on desktop"[/i]

I came to know from Squawk's one of the oldest developer that I have to use some special program to produce suite file on the PC. He said that program name should be similar to Mapper or ClassFileMapper. However, I am not able to identify it so far by looking at Squawk source. If I want to change suite file format and optimize it further then I will need such a utility. I want to see/change the format and final size of suite file that actually runs on mote. I am not sure if I could use suite file produce on desktop for my purpose? May be I am wrong here....

[b]There is another question.[/b] I believe that suite file are variant of jar files. Right? It implies that suite file needs to be decompressed on mote during transfer of code or otherwise during run time. I want to know if that adds extra overhead in term of speed and computation power or not? Note that mica2 has only 8-bit processor and we are working on them (besides working on SunSpots). Hence we cannot afford decompression. Any suggestions please?

Thank you,

Faisal

Message was edited by: faslam

eric_arseneau
Offline
Joined: 2004-07-15
Points: 0

- [i]The problem with AOT compilation is lack of portability. It will give speed but compromise portability. I thought Squwak is highly portable? Do you use AOT on SunSpot motes?[/i]
The AOT story is still in the works, but AOT does not imply lack of portability. Our intent with AOT is to generate what we call target source code, to be compiled by the tool chain of the target. We will not be generating native code directly, which would make porting a little more difficult.

There are 3 forms of AOT that Squawk does and will do
1) Java source -> C/native source
Module is vm2c, and it is used today for the GC. Will be extended to support the interpreter.
2) Application JAR -> suite
Create an execute in place binary package that can be deployed to target.
3) Application JAR -> C/native source
Not being done yet, but will be in the works.

- [i]If I want to change suite file format and optimize it further then I will need such a utility[/i]
There is still a class called SuiteCreator, but it is no longer used. In the old days Squawk had to run in order to create a suite. However we've made some changes where suite creation is handled by the romizer now. romizer is run on desktop Java. So look in the romizer module to get information on how suites are done.

We are doing some work on optimizing it further, but I would be interested to know what kind of optimizations you are thinking of doing. Maybe we can align some and share some of the work ?

- [i]It implies that suite file needs to be decompressed on mote during transfer of code or otherwise during run time. [/i]
Why is compression implied ? The suite is intended to be an execute in place binary. As much indirection as possible is removed, there are direct pointers to appropriate structures, and so on. There is no decompression.

That said, I dont think that decompression is necessarily a bad thing, we have some plans for the way distant future where we think we will be doing compression, but we need to experiment with it first.

There are other things that impact performance as well, such as the size of your data bus. If your data bus is 8 bits, then you may find that running smaller instructions improves performance, as there is less "data" to fetch in order to execute your code.

What are the specs on the mica2 you are working with ? Not to sound like a commercial, but we are in need of an intern and this is a project that we would love to do as an internship :)

faslam
Offline
Joined: 2008-01-19
Points: 0

Dear Eric Arseneau
Mica2 has 8 bit processor, only 4k RAM, 128K flash and CC1000 transceiver. However, we think mica2 has too big flash and our target is to support machines with 32 K flash. Hence we are targeting devices with following specifications[b] [i]4k RAM, 32 K flash, 8-bit processor[/i][/b].
We started working in December last year and so far following has been achieved.

[b]1)[/b]. We optimize class files around 80% to their original size and we think we can do better. Most of the optimization currently achieved are by changing the way constant pool is stored, changing class file format and removing information from class files which is not required during run time. We know the in case of squawk most of the optimization are achieved by changing byte-code. That is why we are optimistic that we can do better by using the byte-code optimization already exist in squawk.
[b]2)[/b] We verify our optimized class files on PC. Usually verification involves 4 pass. We already have nearly completed 4 passes and wish to start working on 5th pass. The 5th pass will verify some extra things (some easily checkable run-time errors).
[b]3)[/b] We generate preloaded file on PC using optimized class files. We have named this file as TUK file. The preloaded files has machine independent memory addresses in it and is NOT REQUIRED to load in RAM during execution. Hence one can use it directly from flash so that RAM is spare to be used by only heap/stack and do not have anything extra (i.e. constant pools, bytecode etc).
[b]4)[/b] We are developing an interpreter in C. Here we need your help. interpreter is written in C because we do not know how to convert it in native/C code after writing it in Java (I will check vm2c tool). We have to develop an interpreter instead of JIT because mica2 has Harvard architecture.

In short we can now take small applications, compile, optimize, pre-load, pre-verify on PC and then transfer them on mica2. We can run simple Java applications on mica2 and it is a great feeling.

[b]Missing things are following[/b]:
----------------------------------------
Right now our TUK file (preloaded, preverified, optimized file) is not JARRED (compressed). Our TUK file is only little bit smaller than Jar file but much smaller than original class files. If we Jar our TUK file then it become very small as compared to Jar files too. However, we do not know that how to use JAR file directly on mote without decompression. See we do not know simple things :( Can you please help by answering this thing again ? sorry to be naive/bothersome.
We wish to change format of Strings, UTF8 takes too much space. Do you have any ideas about it?
Interpreter is still not 100% complete and I will say it is around 50-60% complete. We have currently [i]no[/i] support for threads and exceptions but we are working on it and hope to complete it within next couple of months. We need to have bytecode optimization like squawk because we need to reduce more size (as much as possible). We are trying to develop a real-time garbage collector but need more work on it. We think that most of the garbage collection work could also be shifted on PC and adding some extra instruction (say couple of K bytes) on mote flash could make it work really fast. We believe that if our [i]mostly[/i] offline garbage collection (on PC) could save significant amount RAM and computation (cpu cycles)while wasting couple of K bytes of flash then it is a good deal. We have developed drivers of CC1000 transceiver but now trying to develop MAC protocol in Java (cannot copy MAC protocol from Squawk/SunSpot as it does not have one). We wish to use Routing protocols already exist in Squawk.
We have bought 6 SunSpot motes and I wish to learn squawk so that we could have good things from it and could also give you feedback to improve Squawk. So far we have not done any work on Squawk and have been developing independently. I think we could have first open-source beta version of VM by [u]August/September[/u]. I hope we will have your help and guidance. It is a really huge task and not possible without help from experts like yourself :).

best regards,
Faisal

Message was edited by: faslam

eric_arseneau
Offline
Joined: 2004-07-15
Points: 0

It sounds like we have some very common goals here, I wish Squawk ran now on something like the Mica2. Would there be any way we could work together to make this work ? I know Squawk needs a lot of work to get this small, but we may be able to save both sides a lot of time and effort.

This is getting to be really long and hard to respond to in forums it seems, but lets see what I can say here to help.
1) we do the same optimizations as you do. We dont get much, if any, compression from the byte code optimization. We do get significant amounts of savings from doing dead code elimination.
2) We verify on PC as well, then sign the resulting suite. We verify using the WTK preverifier and our own.
3) Your TUK file is our suite. Our suites are not required to be loaded in RAM either, nor is the VM itself.
4) We have an interpreter written in C as well :( We are supposed to be moving it to Java, but things keep getting in the way of doing it. We have no JIT.

a) We dont do any form of compression on our side either, for the suite file. We assume the suite is run as is. We intend to investigate compression at a later date, but for now we have higher priority things to work on. So not sure what you dont understand ?

Also, very important, we include objects in our suite, so that the desktop can pre-compute objects if we wanted to.
b) we do some cool tricks with Strings, where we are able to use single byte platform specific strings, I am not sure how its done.

Here is some info from Derek
"It's mostly in String.java, but there are bits in GC.java and Klass.java. Maybe some more in the translator. The main parts are in String.java."
"Also see Klass.STRING vs. Klass.STRING_OF_BYTES
These are both "classes" which are really arrays"
c) Good luck to you on the real-time GC. We have done a fair amount of research and we have found that adding real-time GC is very costly. As is adding real-time semantics to Java. So we have decided to go with a dual vm approach, where real-time code runs in one, and regular code runs in other. This two VM scheme btw, is intended to be done very cheaply.
d) GC on PC ? I am confused here. As it seems to me that using PC to do GC would imply significant communication requirements between device and PC.

We will be working on supporting pre-initialized/pre-computed objects also. Likely via some kind of annotation to indicate that this initializer should be run ahead of time. This type of scheme we can understand.

There is also static analysis you can do to pre-allocate some RAM and know exactly when its needed. Is this what you are intending ?

How can we work together to achieve your goals, which are in line with ours ?

Can you e-mail me direct, eric dot arseneau at sun dot com.

faslam
Offline
Joined: 2008-01-19
Points: 0

Dear Eric Arseneau,
I have sent you an email as you asked.

best regards,
Faisal

nepalese
Offline
Joined: 2006-04-04
Points: 0

take a look at the source files in openjdk\hotspot\src\cpu\x86\vm

faslam
Offline
Joined: 2008-01-19
Points: 0

Thanks. I believe that the URL is for JIT used in Squwak. Right?
I have now six Sun-Spot motes and I wish to write the JIT in Java. However, I have no idea how to compile it to machine code because obviously it cannot be in byte code. What compiler I could use? or May be the JIT compiler should compile itself to machine code. However, in that case I have to wait until JIT compiler is fully functional before I can test it on Sun-Spots.

Looking for some replies.

best regards,
Faisal