cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@supereva.it>
Subject Re: new version of the sql logicsheet under development
Date Thu, 07 Sep 2000 14:43:00 GMT

----- Original Message -----
From: "Sebastien Koechlin" <skoechlin@ivision.fr>
To: <cocoon-users@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



Mime
View raw message