Problems persist in KQueueSelectorProvider (Mac) in 7u6 ea

[Jason T. Greene]

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