harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Spark Shen" <smallsmallor...@gmail.com>
Subject Re: [general] jre bundle size
Date Thu, 18 Oct 2007 02:25:38 GMT
2007/10/18, Rana Dasgupta <rdasgupt@gmail.com>:
>
> Even in drlvm we have a lot of dll's, and I am not sure that this is a
> bad thing. It allows the components to be more modular and actually
> can reduce memory footprint, we just have to be more judicious about
> what we load at startup. We could also drop things like gc_cc.dll etc.
> if we really need to.
>
> Not sure why distribution size is a big problem, it is the memory
> image size that seems more important.


Agree.  And sometimes, efforts to reduce memory image size will lead to
smaller distribution size.
For example to customize ICU data or leave out some unnecessary dlls as you
mentioned.

IMHO, Leave these as an option for our users will not be a bad idea.

Rana
>
> On 10/17/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > Egor Pasko wrote:
> > > On the 0x372 day of Apache Harmony Spark Shen wrote:
> > >> 2007/10/17, Sean Qiu <sean.xx.qiu@gmail.com>:
> > >>> I suggest we maintain our classlib modules (jar) in a central
> repository.
> > >>> So we can just get a kernel bundle, and it will download the
> required
> > >>> jars.
> > >>
> > >> +1 for kernel bundle.
> > >>
> > >> We can add options for the default build task. Using these options to
> > >> determine whether
> > >> to include source code ,debug information etc.
> > >>
> > >> And what about  and a new build target 'build-core' for only those
> kernel
> > >> bundles necessary
> > >> to start JRE.
> > >
> > > Sorry, guys:
> > > -1
> > >
> > > First of all, -1 to removing debug information. When you need it, it
> > > is time when you really need it and you are really stuck and blaming
> > > your JRE for various aspects if debug info is not there.
> > >
> > > Secondly, to the kernel bundle:
> > >
> > > 1. how many people want to download just 1/3 of the JRE and then keep
> > >    looking of the damn slow download when running some app? This would
> > >    be an unpleasant surprize because people just did not ask you to go
> > >    web. Looks suspicious, slow and ugly. I do not like unpleasant
> > >    surpizes.
> > >
> > > 2. it is a lot of work. We will need to identify places that can be
> > >    stripped, tweak classloader to download stuff instead of throwing
> > >    complains. Ideally, we will need to measure user experience: how
> > >    many users did not want to download more, and what we can do to
> > >    increase the number of users? Seems pretty hard. So, unless
> > >    somebody has a good design in their mind, I would object to this
> > >    effort. And if they have, please, publish the design on wiki.
> > >
> > > 3. how about permissions? anyone who runs a Java app is sometimes
> > >    asked for a root password to update the JRE? not very convenient
> > >
> > > 4. I believe Linux package managers would anyway stick to the full
> > >    package (otherwize it turns to a nightmare of permissions, security
> > >    issues and such). So, we won't get any lovers of this stuff in the
> > >    Linux community, which is completely not impressing.
> > >
> > > Slow, ugly, surprizing unpleasantly, vulnerable to attacks. gosh.
> > >
> > > If Sun likes that, just let them have fun.
> >
> > I think you are being a bit harsh Egor.  I have to admit that this is
> > not where I would invest my time because I think there is plenty of
> > low-hanging fruit to be picked for space savings in the current code,
> > and that producing a downloadable version is not going to solve that
> > problem.   However, if that is Xiao-Feng / Sean's itch then I'd let them
> > go at it.
> >
> > It would have to be available as an option since I also agree that there
> > are many occasions when people just want the whole thing.
> >
> > Regards,
> > Tim
> >
>



-- 
Spark Shen
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message