cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning von Bargen <H.vonBar...@Triestram-Partner.de>
Subject AW: new version of the sql logicsheet under development
Date Mon, 28 Aug 2000 06:56:18 GMT
Why not save all the string constants in a .properties file?
This could even make translation easier.
Henning

> -----Urspr√ľngliche Nachricht-----
> Von:	Ed Staub [SMTP:estaub@mediaone.net]
> Gesendet am:	Montag, 28. August 2000 06:17
> An:	cocoon-users@xml.apache.org
> Betreff:	RE: new version of the sql logicsheet under development
> 
> That's what I thought, too; the problem is strings, not code.
> 
> The strings could be pushed into constants in a sequence of dummy inner
> classes.
> Each class would be filled to around 50KB, then a new class would be
> started.
> 
> I doubt that the gains from looking for common strings are very great in
the
> cases where the 64K limit is a problem.  I suspect that the bulk is
> typically in very large text insertions.
> 
> -Ed Staub
> 
> -----Original Message-----
> From: ricardo@ricardo [mailto:ricardo@ricardo]On Behalf Of Ricardo Rocha
> Sent: Sunday, August 27, 2000 10:35 PM
> To: cocoon-users@xml.apache.org
> Subject: Re: new version of the sql logicsheet under development
> 
> 
> Stefano Mazzocchi wrote:
> > > On Sun, 27 Aug 2000, Donald Ball wrote:
> > > So it looks like this problem is really hard to solve on the XSP side.
> > > Since we cannot expect the Java-Gods to abolish the 64K limitation and
> we
> > > shouldn't expect the cocoon users to knowingly avoid it, what
> possibilites
> > > are left?
> >
> > I have an idea but requires some deep thinking and lots of Java
> > knowledge I don't currently have: assembling java bytecode directly
> > instead of generating source and have a compiler do the bytecode
> > assembling.
> > Or generate java assembly code and have an external assembler do the 64K
> > method splitting for us.
> > Ricardo, did you ever thought about that?
> 
> As I see it, the whole 64k limit problem is an easily avoidable
> consequence of the approach we chose for code generation. I tend
> to think we can improve on this without resorting to additional
> optimizations.
> 
> I don't think any "reasonably sized" XSP document could generate
> 64k bytes of code as such. Rather, we're paying a high price for
> the decission to inline constant strings throughout the generated
> code. Our problem is not code: it's data mismanagement. So, the
> solution lies in coming up with mechanisms to separate data from
> code.
> 
> Just to illustrate the point, let's imagine our code generator
> separates string constants from code in such a way that constant
> data is serialized in a separate file that is loaded by the
> generated class upon instantiation. Thus, given the input XSP
> document "page.xml" the [Java] code generator would produce 2
> files: "page.java" and "page.ser" where the first contains
> node-generation and user-supplied code only and the second one
> contains the serialization of a string array used to supply
> actual tag names, attribute names/values, inlined text and the
> like.
> 
> This alone might well avoid the 64k-limit problem. Yet, we can
> apply more aggresive optimizations such as one we discussed
> some months ago for SAX: we can drastically reduce string size
> by collecting all common substrings so that SAX "characters()"
> method calls just pass a string array element, an offset and
> a length. This should decrease data size even more.
> 
> > > Perhaps we should rethink XSP. It translates XML into Java, so we can
> use
> > > Java in XML. Up to now we were trying to think of a different way to
> > > translate XML into Java.
> > >
> > > Maybe the whole procedure (translate everything into Java) should be
> > > re-thought. As far as I understand XSP: in order to, say, make XSP
> support
> > > perl, we'd have to translate perl into Java. Then we can take the
> > > translated perl and the translated XML and aggregate it in a Java
class,
> > > which cocoon (being written in Java) can use.
> > > . . .
> > No problems, I like to talk about this: first question is "what is Java
> > for you?" is it the "Java Programming Language" or the "Java Virtual
> > Machine Bytecode"?
> >
> > In the first case, the use of java assembly will:
> >
> > 1) remove the need to have a compiler installed
> > 2) improve the XSP construction performance
> > 3) total control on code (a java assembler is much easier to write than
> > a java compiler)
> > 4) total control on issues such as 64K methods (longer methods can be
> > automatically fragmented and calls chained)
> 
> In principle, I oppose the notion of writing our own bytecode
> compiler. Even if we had to fragment larger-than-64k classes
> (which, as I said above, can almost always be avoided) I feel
> we should do so at the source level.
> 
> Existing Java compilers do a terrific work in generating
> bytecodes; why reinvent the wheel when we can generate better
> source code and avoid the problems we've introduced by our
> own approach?
> 
> > the only problem is that requires substantial java bytecode knowledge
> > (not a common thing in the Java world) and rewriting all the XSP
> > logicsheets to generate java assembly (but probably we can precompile
> > the logicsheets into assembly template sheets to simplify logicsheet
> > development... hmmm, maybe SiLLy might come handy in that... Ricardo?)
> 
> SiLLy aims at simplifying logicsheet authoring by providing a
> higher-level layer on top of "raw" XSLT. SiLLy (or "raw" XSLT for
> that matter) deals strictly with source code generation and should
> be kept that way. We should extend the logicsheet processor to provide
> string handling optimizations, yes, but (again) I feel it's better
> to let the Java compiler do its job.
> 
> > Another alternative is to write for another virtual platform or,
> > directly into native code (we could generate x86 assembly out of XSP
> > pages and access them thru JNI, even if the JNI back and forward would
> > probably make things slower than simple java bytecode).
> > C# might be a future alternative if their VM for IL (intermediate
> > language, their java bytecode equivalent) gets ported on non-win32
> > systems (which some IBM folks might plan on doing if the IL is
> > standardized by ECMA, as Microsoft wants).
> > But even in that case, Java might be compiled into IL (which some say
> > it's more easily optimized for performance) and we might compile Cocoon
> > to IL instead of Java bytecode. In that case, we'd have to rewrite our
> > java bytecode assembly logicsheets while in keeping pure-java code we
> > would save that.
> 
> Yes, keeping pure-java code would not only save that but also
> enable us to generate IL code without touching the existing source
> code generation machinery.
> 
> > But, well, C# on non-win32 platforms is high-steam vaporware and the
> > fact that IL is more performant than bytecode is yet to be demonstrated
> > in real life.
> 
> Let's asume C# (or IL for our purposes) truly makes it: it's still
> a matter of improving on the source code generator (constant string
> handling) and writing the proper compiler hook.
> 
> > So, to solve the 64K method issue, to me, java assembly is the only
> > elegant solution that we can think of today.
> 
> I think the most elegant (not the only one, of course) solution is
> to rethink the code generation strategy: let's define a way of
> separating code from data so that large XSP documents compile
> correctly.
> 
> Please, my friends, enlighten me about problems and options I
> may not be seeing right now. In particular, I may be being to
> simplistic with the 64k-limit problem: all I see is a problem
> of separating data from code. Is there something I'm missing?
> 
> Ricardo
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org

Mime
View raw message