Hello folks, Let me try to share my ideas on GSoC project. I need your feedback on this.
1. I believe a tool from [1] should be replaced with one based on Google Code search, preferably using its nice java API. The tool should have a sort of configurable AI, e.g. understand that misspels in comments are more important than typical performance optimizations. This would help us and others checking bulk contributions. 2. I want to start incubating a project [2] (mentors welcome), but it have logging with incompatible license. Re-using a logger from Harmony VM in this project would solve this problem. Also, one might find a better way to our localization - symbolic identifiers are hard to maintain. I simply love my fine logger, so in case of possible org difficulties with the project [1], it can be replaced with another one with ugly logging. What do you think? With best regards, Alexei [1] https://issues.apache.org/jira/browse/HARMONY-15 [2] http://markmail.org/thread/yiyyqtyb7f7csxui On Fri, Feb 27, 2009 at 12:14 PM, Mark Hindess <[email protected]> wrote: > > In message <[email protected]>, > 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 > > * 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. > > > -- С уважением, Алексей Федотов, http://people.apache.org/~aaf/
