A question about epollwait()

[朱光宇(效山)]

hi guys,

When I do method profiling with jfr on specjbb2015, it always shows epollwait() as the hottest method in jmc event browser. 

int sun.nio.ch.EPollArrayWrapper.epollWait(long, int, long, int) 5400
int sun.nio.ch.EPollArrayWrapper.poll(long) 5400
int sun.nio.ch.EPollSelectorImpl.doSelect(long) 5400
int sun.nio.ch.SelectorImpl.lockAndDoSelect(long) 5400
int sun.nio.ch.SelectorImpl.select(long) 5400
Set org.glassfish.grizzly.nio.DefaultSelectorHandler.select(SelectorRunner) 5400
boolean org.glassfish.grizzly.nio.SelectorRunner.doSelect() 5400
void org.glassfish.grizzly.nio.SelectorRunner.run() 5400
void org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork() 5400
void org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run() 5400
void java.lang.Thread.run() 5400

I guess it could be the same problem described by Jeremy Manson in his blog(http://jeremymanson.blogspot.com/2010/07/why-many-profilers-have-serious.html). I remember someone else ever mentioned jfr uses the same solution like AsyncGetCallTrace and does not sample the TASK_INTERRUPTIBLE tasks (on linux), so I red the source code of jfrThreadSampler... it looks jfr really do sample the os thread in "S" state. When i add several lines of code to skip sampling the thread in "S" state (by reading /proc/pid/stat), all epollwait() gone. Does anyone also notice this? Do you think it's a bug should be fix? Your comments are appreciated!

regards,
guangyu