> From: Darryl L. Miles [mailto:[EMAIL PROTECTED] > Subject: Re: Performance tricks with multiple tomcat instances > > I would hope that JIT compiler engineers would as a minimum > implicitly add the "lock" instruction before all operations > on primitive types declared volatile that are in the platforms > native data width (32bit on i386, 32&64bit on i386_64. 64bit > on ia64).
Not done, since the Java/JVM specs don't require atomic operations except for assignments. If you want to insure that an increment is atomic, you must surround it with a synchronized block. Volatile does not imply atomic. Please read the specs. > So maybe the JVM specification should also adopt a new > keyword for a specific atomic integer data type and another > one to mark those accesses to that it must be atomic. Very unlikely to happen, since the synchronized block covers the required semantics. Modern implementations of synchronized are very fast. > so if you want to write out a 64bit value you have to make > two memory write cycles and this is done with two assembler > instructions, the i386 processor does not provide any > hardware support to make that atomic, so you have to make > that synchronization / lock happen in software there is no > 2 ways about this). Actually, that's not true anymore. Most newer chips have a 64-bit data path, and properly aligned 64-bit loads/stores are implicitly atomic - but there's no guarantee. There's also a compare-and-exchange-8-bytes in the current IA32 instruction set, and that can be made atomic with the lock prefix. > What is not said is that having atomic assignment is > not useful on its own Sorry, but atomic assignment is absolutely critical. Without it, all pointer updates and retrievals would have to be done under storage lock - and that would be prohibitively expensive. > single operations are implicitly atomic Only when properly aligned and supported by the memory system. Since the lowest common denominator of memory access these days is a byte, you cannot assume that anything larger is atomic without reference to the specs for the platform you happen to be running on. (And there are a lot of platforms that are not IA32 - what's in your cell phone?) > A nice clean way to do this in java would be a with > class/method that the JIT would replace with optimized > versions, this would keep keyword pollution down that my > naive example above incites. Already done - see the java.util.concurrent.atomic package in JRE 5. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
