Problems persist in KQueueSelectorProvider (Mac) in 7u6 ea (original) (raw)

Jason T. Greene jason.greene at redhat.com
Fri Aug 17 14:43:44 PDT 2012

On 8/15/12 8:42 AM, Alan Bateman wrote:

On 13/08/2012 22:50, Jason Greene wrote:

On Aug 13, 2012, at 4:42 PM, Alan Bateman<Alan.Bateman at oracle.com> wrote:

: Thanks for trying that out, it's good to hear that the problems have gone away. On the tight loop theory then can you check if a small sleep, or may a Thread.yield, causes the dup2 hang to go away too? Sure I can give that a try. I'll try to get the dump you requested earlier if not. That would be good.

Sleep and yield don't seem to prevent the dup2 issue, so there must be something more complex going on. For whatever reason I have yet to trigger it with the setInterest patch

Here is the kernel stack:

Process ID 65053 is a shambling zombie.

PID: 65053 Process: java Thread ID: 0x71660 Thread state: 0x9 == TH_WAIT |TH_UNINT Thread wait_event: 0xffffff800c3bdda8 Kernel stack: machine_switch_context (in mach_kernel) + 361 (0xffffff80002c2939) thread_continue (in mach_kernel) + 1661 (0xffffff800022f1ad) thread_block_reason (in mach_kernel) + 299 (0xffffff800022f42b) lck_mtx_sleep (in mach_kernel) + 74 (0xffffff8000227efa) wakeup (in mach_kernel) + 267 (0xffffff8000554d3b) msleep (in mach_kernel) + 119 (0xffffff8000555397) fileproc_drain (in mach_kernel) + 249 (0xffffff8000534c59) fstat_extended (in mach_kernel) + 300 (0xffffff800053675c) dup2 (in mach_kernel) + 272 (0xffffff80005369c0) unix_syscall64 (in mach_kernel) + 507 (0xffffff80005cd61b) hndl_unix_scall64 (in mach_kernel) + 19 (0xffffff80002daa13)

: On the patch, are you submitting it here as a contribution (once you are done with your testing)? I haven't looked at it closely yet but I think it is close to what we have in the epoll Selector. Yes I just reused the same approach that epoll is using with slight alterations, since it seems to work well. The patch if useful is a contribution, although as you noticed its mostly a derivative. It make sense too. I've created a bug to track this: 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx] and once you are done with your testing we will look to get this into jdk8. Once we are satisfied they we can seek approval for 7u8.

Ok I have tested this very thoroughly, and I think it's ready for submission. This includes jdk 6 (snow leopard, lion, mountain lion) and 7 (lion, mountain lion). I also ran through the nio selector tests, all pass.

What process should I follow?

A potential change that could be made, that I think should be left for the future should perf testing ever show it's importance, is that the kqueue change list could be combined into one syscall, instead of a list of N syscalls.

-- Jason T. Greene JBoss AS Lead / EAP Platform Architect JBoss, a division of Red Hat

More information about the nio-dev mailing list