Parallelism Per Brinch Hansen argued in 1999 that Java's implementation of parallelism in general, and monitors in particular, does not provide the guarantees and enforcements required for secure and reliable parallel programming. While a programmer can establish design and coding conventions, the compiler can make no attempt to enforce them, so the programmer may unwittingly write insecure or unreliable code. Serialization Java provides a mechanism for object serialization, where an object can be represented as a sequence of bytes that includes its data fields, together with type information about itself and its fields. After an object is serialized, it can later be deserialized; that is, the type information and bytes that represent its data can be used to recreate the object in memory. This raises very serious theoretical and actual security risks. Floating point arithmetic Although Java's floating point arithmetic is largely based on IEEE 754 (Standard for Binary Floating-Point Arithmetic), some mandated standard features are not supported even when using the strictfp modifier, such as Exception Flags and Directed Roundings. The extended precision types defined by IEEE 754 (and supported by many processors) are not supported by Java. Performance Before 2000, when the HotSpot VM was implemented in Java 1.3, there were many criticisms of its performance. Java has been demonstrated to run at a speed comparable with optimized native code, and modern JVM implementations are regularly benchmarked as one of the fastest language platforms available – typically no more than three times slower than C and C++. Performance has improved substantially since early versions. Performance of JIT compilers relative to native compilers has been shown to be quite similar in some optimized tests. Java bytecode can either be interpreted at run time by a virtual machine, or be compiled at load time or run time into native code which runs directly on the computer's hardware. Interpretation is slower than native execution, but compilation at load time or run time has an initial performance penalty. Modern JVM implementations all use the compilation approach, so after the initial startup time the performance is similar to native code. Game designer and programmer John D. Carmack concluded in 2005 about Java on cell-phones: "The biggest problem is that Java is really slow. On a pure cpu / memory / display / communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advance. With Java, on most