JDK1.2, newobject() and methodtables
Hi,
as a small part of my PhD, I'm currently implementing a special
JIT-compiler
based (for a start) on JDK1.2 for x86 and Alpha (should really easily
portable to other CPUs). Now I'm having the problem that the
newobject()-call
from the JDK (and also ObjAlloc) doesn't initialize the object's
method/virtual function tables. But it seems that it does this in JDK1.1
(tried with the tya-JIT).
Is this a bug, a feature, or have I missed something?
Since I want to concentrate on the JIT system itself (and BTW: I'm only
making a SW model of it, it should later run as real logic in an FPGA) I
would really like to avoid the assembling of the tables myself ;-)
PS: Some preliminary benchmarks showed that the JIT gives faster code
than libsunwjit.so on x86...
--
Bye
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java and multithreading
Hi,
<... prg deleted>
> This did not look like multithreading. It is the same if I use native
> threads and not green threads.
> Has anybody an idea how to write a real multithread programm under
> linux. I have to know it because we wrote a server and we want to run it
> under linux and not under windows.
The Linux output makes perfekt sense to me, and it it what I expected.
I'm not exactly familiar how the java thread semantic is defined, but it
certainly isn't defined like you think it is... The example you gave
uses multithreading, but each thread needs less than a timeslice, so it
can
complete its output before it is interupted by another thread. Try an
infinite while loop in the thread (or some time consuming calculation)
and you will see the timeslicing.
BTW: The windows output on the other hand seems very strange, the VM has
to change the thread context at each println-call... Sounds not very
performance promoting...
--
Bye
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (0.3 * 3) = 0,8999999999 ????
Hi, dan wrote: > > Actually, Java is supposed to have bitwise compatibility accross platforms (unlike > C). I know they (Sun) had severe performance problems in the early days > implementing Sun's floating point model under the Intel architecture, and that > changes were made to the VM as a result. Is this one of the consequences of these > changes? Are there ways to ensure bitwise compatibility? No, the problem with the JVM spec was that the float values should always conform to the IEEE float(32bit)/double(64bit) spec. x86 internally always calculates with extended precision (80bit), so for a correct implementation on x86 the VM had to store the 80bit value after _each_ calculation from the FPU to memory (and round it to 64bit), then load it back. This is very slow. The changes made to the spec more or less say that now the VM can calculate with higher precision, and only convert down to double when needed (fpstrict). This has nothing to do with your problem. Your problem simply shows, that some numbers can't be correctly stored in float/double/whatever format. This is a conceptual problem with floating point numbers, and for some calculations it's a big problem. -- Bye Georg Acher, [EMAIL PROTECTED] http://www.in.tum.de/~acher/ "Oh no, not again !" The bowl of petunias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
