You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Sebastien Koechlin <sk...@ivision.fr> on 2000/09/06 12:59:11 UTC
Re: new version of the sql logicsheet under development
Ricardo Rocha wrote:
> 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.
I agree.
> 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.
Having a separate file would be expensive.
Open a file, read it, parse it...
What about using 'public static final string' fields?
About thread safety for fields, this can be solved with
java.lang.ThreadLocal (Java 1.2).
--
Sébastien Koechlin
Re: new version of the sql logicsheet under development
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Sebastien Koechlin" <sk...@ivision.fr>
To: <co...@xml.apache.org>
Sent: Thursday, September 07, 2000 1:03 PM
Subject: Re: new version of the sql logicsheet under development
> Giacomo Pati wrote:
> >
> > Sebastien Koechlin wrote:
> (...)
> > > Separate data from code is not the solution.
> >
> > What is your preferred solution to the 64k problem?
>
> * Constant strings are not taken into account, so putting them
> outside does not solve the problem.
> * Java Bytecode generation is paintful, and we still need a way
> to split produced code without breaking variable scope.
> * Automatic split of XML is difficult because you can not know
> where is the limit. Also, it's a tree, and you need to
> make compiled branch (?) under 64K.
>
> I think something like this could be implemended easilly in
> Cocoon 1 and will solve the 64k problem:
>
> <xsp:page ...>
> <xsp:logic>
> ThreadLocal vars = new ThreadLocal();
> Hashtable getVars() { return (Hashtable) vars.get(); };
> </xsp:logic>
>
> <page>
>
> <xsp:split name="InitFunc">
> <xsp:logic>
> vars.set(new Hashtable());
> getVars().put("i", new Integer(5));
> getVars().put("j", "This is a string");
> </xsp:logic>
> </xsp:split>
>
> <xsp:split name="FirstPart">
> <integer>
> <xsp:expr>(Integer) getVars().get("i")</xsp:expr>
> </integer>
> </xsp:split>
>
> <xsp:split name="SecondPart">
> <string>
> <xsp:expr>(String) getVars().get("j")</xsp:expr>
> </string>
> </xsp:split>
>
> </page>
> </xsp:page>
>
> The user has to manually split it in many functions, and it's Java 1.2.
> But it should works.
At http://www-i2.informatik.rwth-aachen.de/~markusj/jopt/index.html there
is a Java class optimizer that reducers size to up to 95% (less realistically)
by:
[[
a.. removing debug info
line number table, local variable table
b.. removing attributes that are unnecessary for execution
sourcefile, innerclass, synthetic, deprecated, user-defined
c.. removing unused private methods and fields
d.. removing unused entries from the constant pool
any entry that is not referenced from anywhere inside the class file, e.g. the constant_utf8 ``SourceFile'' and the name of the
sourcefile that were lost when the sourcefile attribute was removed
e.. optimizing the order of local variable slots
f.. new: compressing local variable slots
g.. obfuscating private method- and fieldnames
the new names are usually shorter than the old ones, so the optimized class file is also shorter
optimizing the bytecode in different ways
a.. removing NOP instructions
b.. removing GOTO instructions that jump to the following instruction
c.. redirecting GOTO instructions that jump to another GOTO instruction
d.. replacing GOTO instructions that jump to a RETURN instruction
e.. removing dead code
f.. replacing xSTOREn/xLOADn by DUP/xSTOREn, which can entail other optimizations
g.. new: live variable analysis
h.. new: constant analysis
]]
There is a similar thing at the AlphaWorks website (IBM).
nicola_ken
Re: new version of the sql logicsheet under development
Posted by Sebastien Koechlin <sk...@ivision.fr>.
Giacomo Pati wrote:
>
> Sebastien Koechlin wrote:
(...)
> > Separate data from code is not the solution.
>
> What is your preferred solution to the 64k problem?
* Constant strings are not taken into account, so putting them
outside does not solve the problem.
* Java Bytecode generation is paintful, and we still need a way
to split produced code without breaking variable scope.
* Automatic split of XML is difficult because you can not know
where is the limit. Also, it's a tree, and you need to
make compiled branch (?) under 64K.
I think something like this could be implemended easilly in
Cocoon 1 and will solve the 64k problem:
<xsp:page ...>
<xsp:logic>
ThreadLocal vars = new ThreadLocal();
Hashtable getVars() { return (Hashtable) vars.get(); };
</xsp:logic>
<page>
<xsp:split name="InitFunc">
<xsp:logic>
vars.set(new Hashtable());
getVars().put("i", new Integer(5));
getVars().put("j", "This is a string");
</xsp:logic>
</xsp:split>
<xsp:split name="FirstPart">
<integer>
<xsp:expr>(Integer) getVars().get("i")</xsp:expr>
</integer>
</xsp:split>
<xsp:split name="SecondPart">
<string>
<xsp:expr>(String) getVars().get("j")</xsp:expr>
</string>
</xsp:split>
</page>
</xsp:page>
The user has to manually split it in many functions, and it's Java 1.2.
But it should works.
--
Sébastien Koechlin
Re: new version of the sql logicsheet under development
Posted by Giacomo Pati <Gi...@pwr.ch>.
Sebastien Koechlin wrote:
>
> I wrote:
> >
> > Ricardo Rocha wrote:
> >
> > > 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.
> >
> > I agree.
>
> Sorry, I just came back after two weeks, and I thought this mail-thread
> was closed. 5 min ago, I found that there are a lot more message about
> this
> under others titles.
>
> Separate data from code is not the solution.
What is your preferred solution to the 64k problem?
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen Mailto:Giacomo.Pati@pwr.ch
Web: http://www.pwr.ch
Re: new version of the sql logicsheet under development
Posted by Sebastien Koechlin <sk...@ivision.fr>.
I wrote:
>
> Ricardo Rocha wrote:
>
> > 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.
>
> I agree.
Sorry, I just came back after two weeks, and I thought this mail-thread
was closed. 5 min ago, I found that there are a lot more message about
this
under others titles.
Separate data from code is not the solution.
--
Sébastien Koechlin
Re: new version of the sql logicsheet under development
Posted by Giacomo Pati <Gi...@pwr.ch>.
Donald Ball wrote:
>
> On Wed, 6 Sep 2000, Sebastien Koechlin wrote:
>
> > About thread safety for fields, this can be solved with
> > java.lang.ThreadLocal (Java 1.2).
>
> hm. mind giving me a quick overview of how that works?
You can also look at
http://tyrex.exolab.org/javadoc/tyrex/util/FastThreadLocal.html
for an other implementation of that behaviour.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen Mailto:Giacomo.Pati@pwr.ch
Web: http://www.pwr.ch
Re: new version of the sql logicsheet under development
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 6 Sep 2000, Sebastien Koechlin wrote:
> About thread safety for fields, this can be solved with
> java.lang.ThreadLocal (Java 1.2).
hm. mind giving me a quick overview of how that works?
- donald