Hi Ben, Now we are getting somewhere ;-)
Ben Evans wrote: > Hi Kirk, > > On Thu, Apr 2, 2009 at 4:51 PM, kirk <kirk.pepperd...@gmail.com > <mailto:kirk.pepperd...@gmail.com>> wrote: > > > I see a lot of strawman arguments for standardization but I don't > really > see anything with substance. I'm not against the standardization route > but I'm just not seeing the need to treat this any differently than > say.. a different GC implementation. How about Escape Analysis or the > internals of IBM's equivalent of HotSpot/JIT which is quite different. > What makes tail recursion different? JRockit 1.4 Mission Control > seemed > to force JMX into the 1.5. IMHO, if it is going to make a difference, > others will pick it up and then it will be a lot easier to add it into > the JVM specification. > > > If I'm following this thread right, then what is really meant by TCO > is not "JVM implementations are allowed to spot that a certain pattern > of bytecodes (eg 0xb6 0xXY 0xZW 0xb0) are a tail-call and MAY be > optimised by the JITter" but "a certain, not currently permitted, > sequence of bytecodes MUST be optimised as a tail-call so as to not > grow the stack" Ok, this would be a problem if the spec specifically prohibited a reasonable optimization. > > The MUST condition allows us to make semantic guarantees about certain > recursive cases not blowing up the stack - important for functional > languages. As I understand it, it is not currently possible to > implement Scheme fully on the JVM, as the Scheme spec requires > compilers to make a form of the above MUST guarantee (I am not a > Scheme head, so if this is too much of a simplification, someone > please put me right). Ok, lets inject the Azul JVM into this conversation. If optimizes away a lot of things because it has the hardware support to manage them. Pointer swizzling for moved objects for example, transactional memory affecting synchronization for another. These "optimizations" make the Azul VM much different than any other implementation yet they are able to meet the standard. They don't require special class files that won't run on other VMs. Of course other VMs don't offer the benefits. But then GC works the same, you won't get G1 benefits unless you are using Sun. > > The reason why one implementation can't just unilaterally introduce it > is that the pattern does not cuurently constitute valid Java code as > per the spec, and the results of that - ie trying to run code compiled > with the new bytecode form on a JVM which doesn't support it would not > be good. > > Imagine the situation where code compiled with one vendor's compiler > could not be run on another vendor's JVM, despite them both claiming > to support the same classfile version. Dialectisation, vendor-specific > extensions to core specs and incompatability of binary files, > depending on which compiler you used? Not a world I think we'd like... agreed but I'm not sure that we need to go there. However, if the OpenJDK happens to allow deeper stacks than the others or it knows how to avoid having stacks build up, that would seem to be a competitive advantage, not a violation of a specification or an incompatability unless you did require special byte codes or invalid class files to make it work. At any rate, I havn't said this shouldn't be part of the spec. It is just that IME, it's easier to spec a working implementation than just to go to committee trying to get everyone on board. Like it or hate it, OSGi has helped demonstrate that hasn't it. Regards, Kirk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to jvm-languages+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
