Re: [xmlvm-users] Java shrinkers

[Panayotis K. <pan...@pa...>]

First of all, sorry for the late answer.
Last time I thought that it couldn't be done - if it really can then
this is a nice surprise!
Do you remember the actual parameter used for this issue?
I believe if we find a solution with ProGuard, this will help a *lot*
the XMLVM progress and the whole acceptance of XMLVM, even with the
relaxed new iOS SDK agreement.

On 9/1/10, Jeff Palmer <jcp...@ro...> wrote:
> I have used Proguard, and it definitely can delete things below Class level,
> so I am not sure what you mean about method-level optimizations.
>
> If you add the '-printusage filename' to your config or Ant build.xml you
> can see everything removed.  A class name by itself means the whole class
> was delete.  If it is followed by a colon, only the stuff below was removed
> along with line numbers, e.g.
>
> myNamespace.com.stuff.morestuff.CurrentPlatform:
>     public static final byte SERVER_PLATFORM
>     public static final byte DESKTOP_PLATFORM
>     public static final byte PHONE_PLATFORM
>     32:32:public static boolean isServer()
>     34:34:public static boolean isPhone()
>     39:39:public static boolean isValidPlatform(byte)
>     40:40:public static boolean isValidClientPlatform(byte)
>
> It also does much optimization in the methods themselves.  Probably the one
> that should be of most interest to you is method in-lining. Sounds like you
> only want to do this when the space penalty is very low.  This can be
> adjusted using system properties, only documented within Proguard's source
> code.
>
> The package to look at is proguard.optimize.peephole .  The Class is
> MethodInliner.  You will see that there are 2 properties consulted for the
> maximum resulting code length to decide if it should be done.  One for J2SE
> & the other for J2ME.  Specifying a lower value for the J2SE version might
> help.  Looking through the source of this entire directory for other system
> properties may also be good.
>
> I know of another way to get the size down, but think they are going to be
> sort of "empty calories".  Here it is just in case:
> use option '-repackageclasses ${single-package}'.  Use something like
> '<property name="single-package" value="_"/>
>
> Hope this helps
>
>
> On 8/31/10 5:07 PM, "Panayotis Katsaloulis" <pan...@pa...> wrote:
>
>>
> On 31 Αυγ 2010, at 8:44 μ.μ., Sascha Haeberling wrote:
>
>> I am actually
>> working on such an optimized call graph dependency optimizer, which should
>> shrink down the whole compilation size.
>>
>> In addition we will remove the
>> need to compile classes that don't need to be compiled. E.g. all the JDK
>> classes need to be compiled once and we can provide it to our users. These
>> two
>> measures should speed up compilation time a lot.
>>
>> // Sascha
>
> The problem
>> has to do more with size, not time.
> It is really easy to produce static
>> libraries, and thus reduce compilation time to minimum.
> The way it is done
>> right now, though, is again object-level optimization - similar to what
>> ProGuard does (and it does it extremely well - it is even able to deal
>> with
>> simple reflection cases).
>
> The problem is with method-level optimizations.
>> That is why I propose to investigate such methods.
>
> In which level is the
>> optimization you are working
>> on?
> --------------------------------------------------------------------------
>> ----
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel
>> programming skills.
> Enter the Intel(R) Threading Challenge
>> 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> ___________________________________
>> ____________
> xmlvm-users mailing
>> list
> xml...@li...
> https://lists.sourceforge.net/lists/lis
>> tinfo/xmlvm-users
>
>
>
>


-- 
Panayotis Katsaloulis