harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Wilson <jessewil...@google.com>
Subject Re: [jira] Commented: (HARMONY-6312) Concurrency problems in NIO
Date Thu, 08 Oct 2009 16:58:12 GMT
Mark,
Thanks for hanging along with me on these changes, and also for the heads up
on Regis' holiday.


On Thu, Oct 8, 2009 at 2:57 AM, Mark Hindess <mark.hindess@googlemail.com>wrote:

> I think there is usually quite a lot of overlap between the goals of memory
> efficiency and high throughput.
>

Agreed. Only indices and caches tend to trade memory for throughput.


I'd argue that simplicity isn't necessarily a good metric for either Android
> nor Harmony since you rarely ever want to maximize simplicity at the cost of
> other more significant factors.


Agreed again. But I think that complexity should be justified. Making code
faster is worthy of complexity it the code is hotspot: something that the
CPU spends a significant amount of time executing. We could optimize the
heck out of GregorianCalendar.setGregorianChange(), but it wouldn't matter
because applications don't spend time executing this method.

For the specific case of selector indices, my main concern has been that the
epoll microbenchmark inflated the benefit and hid the cost.



> For example, your changes to make fewer object allocations (doubling the
> number of parameters to the select method) don't improve simplicity but are
> brilliant idea.
>

Actually, this is Regis' brilliance. Yay Regis!



> I'd certainly find it easier to apply your patches if they were closer to
> the final commits I make.
>

Thanks for going the distance on my patches; I'm sorry they're so scary!

Since I was recently complaining to Regis about his use of too-many small
patches, it seems we've simply got different workflow patterns! I read
patches in my IDE, which takes care of hiding whitespace problems, etc. And
I find the JIRA process slightly cumbersome, so it's easy just to send one
uberpatch.

So as you probably all know, Dalvik's core library was forked from Harmony
several years ago. We recently caught back up-to-date with Harmony, so all
of your bugfixes will be shipping on our devices this holiday season. But we
also have made lots of changes of our own including whitespace, bugfixes,
optimizations, simplifications, spelling corrections and removing author
tags. To send these changes upstream, I can either do it as a single giant
scary patch, or as a series of focused patches.

The primary drawback of focused changes is what they use as a baseline. I
can create patches that depend on each other in series, so you need the
whitespace change in order to get the bugfixes. Or patches that all apply to
Harmony's HEAD, so the patches could slightly conflict with one another (if
there's a whitespace change near a bugfix). Or I could wait for the
whitespace change to be applied, and send a second patch with the bugfixes.
In any case it'll just be me taking the giant patch, and then trying to
split it up into chewable pieces. Any preference from you guys?

Thanks again Mark!

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