harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <alexei.fedo...@gmail.com>
Subject Re: Google Summer of Code 2009
Date Sun, 01 Mar 2009 14:23:47 GMT
I like the task about jars.

I have a hint for a student who wants to approach it. Harmony jar
reading code has numerous limitations and assumptions (e.g. Harmony
limits a size of a jar file). It is important to keep most of
limitations as is, resisting a desire to eliminate them all at once.
Otherwise instead of performance gain one may face that popular
applications slow down.


On Sun, Mar 1, 2009 at 5:05 PM, Mark Hindess
<mark.hindess@googlemail.com> wrote:
> In message <E1Lcynw-0002tc-Ee@fhw-relay07.plus.net>, Mark Hindess writes:
>> In message <fc2fc95c0902230906k50896634tfc45df549348c690@mail.gmail.com>,
>> Sian January writes:
>> >
>> > Hi everyone,
>> >
>> > Do we want to propose any projects for Google Summer of Code 2009?  It
>> > was quite successful last year for Harmony, with two students
>> > completing the programme, so definitely worth doing in my opinion.
>> >
>> > http://code.google.com/soc/
>> >
>> > Thanks,
>> > Sian
>> I've a couple of items on my todo list that might make an interesting
>> GSoC project.  While looking at file descriptor usage between Harmony
>> and RI I noticed that the RI typically reads jar files with an
>> open/mmap/close sequence and then uses the mapped memory to access the
>> file.  Harmony uses open and uses seek/read to access the file.  There
>> are a couple of issues here:
>>   * some applications that use lots of jar files will not work on Harmony
>>     because they will run out of file descriptors even though they will
>>     work on the RI
> I notice while looking a the strace from the latest "trival" test case
> in the "Problems with NIO" thread that on the RI the client connect
> socket is always fd=4 where as on DRLVM it is fd=110 so the difference
> is quite significant.  This got me wondering what the difference would
> be when running something like Eclipse with lots of plugin jars.  Just
> loading a fairly trivial workspace on Sun and DRLVM results in using
> 586 and 674 file descriptors respectively.  So it looks like not all
> jars are loaded using the mmap trick but DRLVM would still run out of
> descriptors roughly 100 sooner than the RI.
> -Mark
>>   * code with memory access rather than seek/read will be a lots simpler
>>     to read/maintain
>>   * what are the performance implications?
>> I'd quite like to investigate this but don't seem to be finding the time.
>> It might also be interesting to explore the possibility of exploiting
>> parallelism (compare gzip/pigz).
>> It might also be worth seeing if there is any performance benefit to using
>> the inflateBack api (compare gzip/gun - gun is in the zlib source examples
>> directory).
>> If people think these ideas are concrete enough to explore then I'll add
>> an item to the wiki.
>> Regards,
>>  Mark.

С уважением,
Алексей Федотов,

View raw message