[
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: [email protected]
For additional commands, e-mail: [email protected]
