This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In the new output2 the process output is grabbed using the nio API. The current JDK on OS/2 does not allow some nio operations on STDIN/STDOUT/STDERR. Due to this the following block: try { contents = ch.position(0).map(FileChannel.MapMode.READ_ONLY, 0, mappedRange); this.contents = contents; } catch (IOException ioe) { ioe.printStackTrace(); ErrorManager.getDefault().log("Failed to memory map output file for " + //NOI18N "reading. Trying to read it normally."); //NOI18N //If a lot of processes have crashed with mapped files (generally when testing), //this exception may simply be that the memory cannot be allocated for mapping. //Try to do it non-mapped contents = ByteBuffer.allocate((int) mappedRange); ch.position(0).read(contents); } always continues in the catch block. So a lots of exception logs are generated which makes the output window scrolling slow. Could be the exception logging turned off in this code (if at least for OS/2)?
I can probably just turn off use of memory mapped files on OS/2. It means all output will be stored on the heap, which means more heap usage, but should not be a problem unless the output is huge.
I've digged a bit more, as I've noticed that the STDOUT/STDERR was redirected to a temporary file. So the problem is not that that STDOUT/STDERR couldn't be memory mapped. I also checked the OS/2 file api and there I've found the solution. I'm using a RAM file system for temporary files. Files on this file system doesn't support memory mapping. When I set the temp dir to a standard filesystem, the exceptions were gone, and the performance is good again. Tim, thanks for the short response!
closed