Just saw this on the Cocoon list. Having discussed the possibility of compiling .vm templates in the future, perhaps this is not such great idea after all. (scroll down midways) - Kasper ----- Original Message ----- From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: "Cocoon" <[EMAIL PROTECTED]> Cc: "Ricardo Rocha" <[EMAIL PROTECTED]>; "Eduardo Pelegri-Llopart" <[EMAIL PROTECTED]> Sent: Friday, June 15, 2001 4:19 PM Subject: [small RT] The impact of Generics on server pages. > Generics will be introduced in the Java language in 2003 (probably June > for JavaONE). > > [for more info look here > http://www.javaworld.com/javaworld/javaone01/j1-01-improvements_p.html] > > Generics are a cool feature that allows you to avoid the problems with > runtime casting of objects (and may lead to performance optimization at > compilation time or even jit-interpretation time) but for the Cocoon > project they will have a weird side effect: the syntax uses XML-like > markup to introduce the genericity of the object containers. > > For example > > List<Integer> myList = new LinkedList<Integer>(); > > which must be written as > > <xsp:logic> > List<Integer> myList = new LinkedList<Integer>(); > </xsp:logic> > > or > > <xsp:logic><![CDATA[ > List<Integer> myList = new LinkedList<Integer>(); > ]]></xsp:logic> > > since writing something like > > <xsp:logic> > List<Integer> myList = new LinkedList<Integer>(); > </xsp:logic> > > will generate three syntax errors for java and two well-formness errors > for the XML, since the XSP engine (which is based on a XML parser) will > believe that the two <Integer> are markup. > > XSP was based on the fact that XML syntax and java code were "mostly" > orthogonal (except for the < and > signs used for conditionals that must > be escaped). Since the Collection API will be fully genericized in Java > 1.5, I forsee an extensive use of this syntax, thus making XSP even less > readable (thus, more expensive to write and maintain). > > Note that this very same thing will plague the xml-ized version of JSP > as well. > > This is the last step of a reasoning that indicates how mixing markup > and code is indeed bad practice and should not only be incouradged > against (as both XSP and JSP do with taglibs) but should be > architecturally prohibited. > > I know this is where Ricardo is leading with his yet-to-be announced > research on an XSP successor. I'm curious to see where this leads to. > > Another thing that some "behind close doors" tests show is that server > page compilation may indeed turn out to be a "slower" solution that > interpretation. This is very likely to hold true for sitemap compilation > as well. > > Why? one word: hotspots. Modern JVMs are entirely based on the concept > that hotspots should be optimized into native code the more they are > executed. Well, by compiling a server page or a sitemap, we are, in > fact, "unrolling" the interpretation hotspots in a series of actions > built at compilation time. > > This was a great optimization feature for x86 assembly up until > Pentiums, but is likely to reduce performance on more modern processors > (Itanium processors given the 64 bit instructions and granularity of > first level caching). > > Just like assembly optimization is inherently tied to the silicon used, > I suspect that page compilation is a performance improvement that is > tied to the JVM technology as well. (in fact, it makes a perfect > parallel if you think at Transmeta's code morphing techniques which are > something in between a CISC-2-RISC-ifier and a JVM. > > Anyway, it is for sure that the first "n" executions of the compiled > page will be faster than their interpreted counterpart, but what happens > after 10000 iterations? 1000000? or what happens of the interpreting > hotspot is shared by "all" the dynamic pages on the server side and the > server has an uptime of 6 months? or what happens when Sun sees its > hardware market shrink and starts selling hardware-accelerated java > virtual machines? will compilation (read: optimization done by a > software known as compiler) be inherently more performant than > interpretation (read: optimiation done by a software known as virtual > processor) no matter what? > > I sure see more research into JVMs than into java compilers. And to tell > the truth, there is not much a java compiler can optimize rather than > avoiding the need for interpretation overhead, but that, since executed > all the time, will very likely be hotspotted and just-in-time-compiled > down to the very native bit. > > I came to the conclusion that code inlining in markup and markup code > compilation (which account for much of the Cocoon2 architecture and are > the overlap with JSP) were architectural mistakes and will need to be > corrected. > > This has the interesting side effect of considering dynamic tags as the > only good design idea that came from JSP. Which, interesting enough, was > "borrowed" from ColdFusion and now makes the concept of XSLT extensions > much more appealing from an architectural point of view (even if the > syntax still sucks big time and portability is almost unexistant). > > Anyway, don't worry, we have years to overcome these architectural > details and will be so smooth that won't break any of your work but will > rather be you to push for this to happen, just like the transition from > Cocoon1 to Cocoon2. :) > > Anyway just the usual bunch of RT to make your synapses fire in unusual > directions. > > ----------- o ----------- > > Ah, FYI, an headup on my status: I finished my college exams and my > thesis is due June 29 with the title > > "Reducing the effect of growth saturation on web sites > with the use of a publishing framework based on XML technologies" > > I will discuss it July 16. If you happen to be around Pavia, Italy, and > want to be present, let me know privately and we can arrange that. > > Anyway, for those of you who won't make it, the thesis will be written > in english and will be available on my web site > (http://www.apache.org/~stefano/) the day after. > > Take care. > > -- > Stefano Mazzocchi One must still have chaos in oneself to be > able to give birth to a dancing star. > <[EMAIL PROTECTED]> Friedrich Nietzsche > -------------------------------------------------------------------- > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] >
