Er,...really?

Post #79,321 by jb4 2/4/03 6:47:07 PM Reply	Er,...really? It never would have been a problem in Java or another language that didn't deal with memory directly (using references). Actually it would have. As Scott points out, Java "references" are really pointers, probably "smart pointers", with the inard hidden to protect the illiterati. A "Reference" in Java would have had the same problem that pointers in C++ had. The problem was the memory model; your Intel box used 16-bit code, and a small pointer model, allowing for 16-bit pointers. Your 'nix box used a 32-bit pointer model, which was incompatible with the 16-bit poitners stored in your file. (I am assuming that you did not try to read pointers generated on the Intel system with your 'nix system, or vice versa....) If your 'nix box were to have been an Intel device, and your 'nix supported small pointer models, your code would probably have worked just fine. jb4 "They lead. They don't manage. The carrot always wins over the stick. Ask your horse. You can lead your horse to water, but you can't manage him to drink." Richard Kerr, United Technologies Corporation, 1990
Post #79,363 by ChrisR 2/4/03 9:32:06 PM Reply	Java pointer problems Not that I really want to jump into the fray.... A "Reference" in Java would have had the same problem that pointers in C++ had. Java code is compiled into a common bytecode for all machines - not compiled per machine. The JVM is the machine that is running the compiled code - not the underlying cpu. Assuming the VM implementor took care of their business, the differences in hardware and OS are abstracted away from the programming chore. You don't program Java for Sparc, Risc, or Intel CPUs - you program them to the Java Virtual Machine. Not that this is always perfect. Sometimes the Java specs are ragged around the edges - for example threading has quite different results on the various OS's. Also, there's the problem that the JVM is not optimized for any particular cpu, making the code unoptimized.
Post #79,366 by admin 2/4/03 9:36:29 PM Reply	OT: threading Threading variations are probably more a result of the underlying thread library than the Java spec. As an example, Linux posix threads use a single process per thread, which means that each thread also gets a different pid (via getpid()). Even worse, the signal handling gets all screwed up, and you can't task a single thread to receive signals for all the threads in a process (which is how you should do it). The Solaris and Win32 thread libraries do not have these problems. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #80,163 by dshellman 2/7/03 1:13:26 PM Reply	Just a nit Just a quick nit... The JVM can be optimized for the particular OS/hardware. There's nothing that prevents it (I think what you meant was that the bytecode couldn't be optimized for a particular hardware/OS...which is true, but isn't particularly interesting, as it can be modified on the fly and be optimized for a particular hardware CPU, etc.). And the optimization can be done at runtime, which (in some cases) can be faster than a compiled optimization. Remember, I said "can." Dan

Welcome to IWETHEY!