Re: [xmlvm-users] Java shrinkers

[Sascha H. <sa...@xm...>]

As I explained, I am working on two things: Optimizing the amount of code
being pulled in as well as having things pre-compiled.

The first will reduce the size of the binary. The dependency analysis I
implemented a while a go is a very naive approach that pulls in all classes
and all their references, thus pulling in almost the complete JDK. It was
good for getting us started with the C backend. What I am currently working
on does the analysis on a Class::method level, which should reduce code size
significantly.

Stay tuned for updates around this this week, I will let you know when I
have something to try out.

// Sascha

On Tue, Aug 31, 2010 at 11: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/listinfo/xmlvm-users
>