harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Wilson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-6312) Concurrency problems in NIO
Date Thu, 24 Sep 2009 23:28:16 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759321#action_12759321
] 

Jesse Wilson commented on HARMONY-6312:
---------------------------------------

I've finally had time to take a look at this issue.

>From Regis' August 28 email to our dev@ list: "The more registered channels, the slower
prepareChannels, even more, we have to travel the whole set more than once! Current implementation
maintains several mapping to avoid this. So do you have any data to prove this patch is good
as old one when large number of channels are registered?"

I benchmarked this code to test whether the mappings are worthwhile. The benchmark (which
I'll attach) executes the following pseudocode:
  Create N pipes.
  Create a direct buffer of size X.
  while (true) {
    Register/deregister a random subset of the 2N channels (source and sink of N pipes).
    Select
    Read or write as much data as possible to/from the buffer
  }

Because of the many, many moving parts, there was a high amount of variance in this benchmark.
Here's some typical results from my desktop:
  32 Pipes
    RI: 7.3ms per KB
    Hy with mappings: 14.3ms per KB
    Hy no mappings: 14.3ms per KB
  512 Pipes
    RI: 12.2ms per KB
    Hy with mappings: 21.9ms per KB
    Hy no mappings: 21.0ms per KB

Aside from the fact that DRLVM+working_classlib takes twice as long as the RI, the mappings
yield no performance improvement and are not worth the additional complexity. Furthermore,
the mappings will have a negative impact on performance for platforms where memory is constrained
or garbage collection is slow (ie. embedded). 

Therefore I'm going to prepare a patch to remove the mappings. Let me know if you see mistakes
in this analysis or flaws in the benchmark.

Cheers,
Jesse

> Concurrency problems in NIO
> ---------------------------
>
>                 Key: HARMONY-6312
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6312
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>         Environment: SVN Revision: 801399
>            Reporter: Jesse Wilson
>            Assignee: Regis Xu
>         Attachments: cancelledkey.diff, harmony_svn.html, harmony_svn_plus_patch_2009-08-19.html,
NIO_Concurrency_issues.patch, ri.html, selector.zip, SelectorBenchmark.java
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> There's several potential concurrency problems in our NIO implementation...
>  - Charset#isSupported isn't synchronized, but it accesses mutable member cachedCharsetTable.
>  - In SelectionKeyImpl, stHash++ is a non-atomic operation so multiple SelectionKey instances
may receive the same hash code. (Why not use the default hash code?)
>  - In SelectorImpl, the unmodifiableKeys member is never synchronized on. But the documentation
specifies that clients can synchronize on that set to guard against changes
> These are the obvious problems; I suspect there are more subtle concurrency defects at
play here. I'll prepare a patch to address the major issues, and we should consider a rigorous
approach (Findbugs?) to discover concurrency problems.
> #Android

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message