cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [small RT] The impact of Generics on server pages.
Date Fri, 15 Jun 2001 14:19:07 GMT
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&lt;Integer&gt; myList = new LinkedList&lt;Integer&gt;(); 
 </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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message