[ https://issues.apache.org/jira/browse/LUCENE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715016#action_12715016 ]
Earwin Burrfoot edited comment on LUCENE-1658 at 6/1/09 1:14 AM: ----------------------------------------------------------------- bq. The buffer is nulled directly after unmapping. Really? Let me quote some code (MacOS, Java 1.6): unsafe.freeMemory(address); address = 0; Bits.unreserveMemory(capacity); Does windows version differ? What we see here is 'zeroing', not 'nulling'. When doing get/set, buffer never checks for address to have sense, so the next access will yield a GPF :) The guys from Sun explained the absence of unmap() in the original design - the only way of closing mapped buffer and not getting unpredictable behaviour is to introduce a synchronized isClosed check on each read/write operation, which kills the performance even if the sync method used is just a volatile variable. was (Author: earwin): Really? Let me quote some code (MacOS, Java 1.6): unsafe.freeMemory(address); address = 0; Bits.unreserveMemory(capacity); Does windows version differ? What we see here is 'zeroing', not 'nulling'. When doing get/set, buffer never checks for address to have sense, so the next access will yield a GPF :) The guys from Sun explained the absence of unmap() in the original design - the only way of closing mapped buffer and not getting unpredictable behaviour is to introduce a synchronized isClosed check on each read/write operation, which kills the performance even if the sync method used is just a volatile variable. > Absorb NIOFSDirectory into FSDirectory > -------------------------------------- > > Key: LUCENE-1658 > URL: https://issues.apache.org/jira/browse/LUCENE-1658 > Project: Lucene - Java > Issue Type: Improvement > Components: Store > Reporter: Michael McCandless > Assignee: Uwe Schindler > Priority: Minor > Fix For: 2.9 > > Attachments: LUCENE-1658-take2.patch, LUCENE-1658-take2.patch, > LUCENE-1658-take3.patch, LUCENE-1658-take3.patch, LUCENE-1658-take3.patch, > LUCENE-1658-take3.patch, LUCENE-1658-take3.patch, LUCENE-1658.patch, > LUCENE-1658.patch, LUCENE-1658.patch > > > I think whether one uses java.io.* vs java.nio.* or eventually > java.nio2.*, or some other means, is an under-the-hood implementation > detail of FSDirectory and doesn't merit a whole separate class. > I think FSDirectory should be the core class one uses when one's index > is in the filesystem. > So, I'd like to deprecate NIOFSDirectory, absorbing it into > FSDirectory, and add a setting "useNIO" to FSDirectory. It should > default to "true" for non-Windows OSs, because it gives far better > concurrent performance on all platforms but Windows (due to known Sun > JRE issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6265734). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org