LUCENE-2650: Improve Windows defaults in FSDirectory

git-svn-id: https://svn.apache.org/repos/asf/lucene/dev/trunk@999409 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Robert Muir 2010-09-21 13:40:35 +00:00
parent 2595c91906
commit c89d2d3c3b
4 changed files with 20 additions and 15 deletions

View File

@ -108,6 +108,14 @@ Changes in backwards compatibility policy
* LUCENE-2600: Remove IndexReader.isDeleted in favor of
IndexReader.getDeletedDocs(). (Mike McCandless)
Changes in Runtime Behavior
* LUCENE-2650: The behavior of FSDirectory.open has changed. On 64-bit
Windows systems that support unmapping, FSDirectory.open returns
MMapDirectory. Additionally the behavior of MMapDirectory has been
changed to enable unmapping by default if supported by the JRE.
(Mike McCandless, Uwe Schindler, Robert Muir)
API Changes
* LUCENE-2302, LUCENE-1458, LUCENE-2111, LUCENE-2514: Terms are no longer

View File

@ -183,8 +183,9 @@ public abstract class FSDirectory extends Directory {
* The directory returned uses the {@link NativeFSLockFactory}.
*
* <p>Currently this returns {@link NIOFSDirectory}
* on non-Windows JREs and {@link SimpleFSDirectory}
* on Windows. It is highly recommended that you consult the
* on non-Windows JREs, {@link MMapDirectory} on 64-bit
* Sun Windows JREs, and {@link SimpleFSDirectory} for other
* JRes on Windows. It is highly recommended that you consult the
* implementation's documentation for your platform before
* using this method.
*
@ -193,11 +194,8 @@ public abstract class FSDirectory extends Directory {
* the event that higher performance defaults become
* possible; if the precise implementation is important to
* your application, please instantiate it directly,
* instead. On 64 bit systems, it may also good to
* return {@link MMapDirectory}, but this is disabled
* because of officially missing unmap support in Java.
* For optimal performance you should consider using
* this implementation on 64 bit JVMs.
* instead. For optimal performance you should consider using
* {@link MMapDirectory} on 64 bit JVMs.
*
* <p>See <a href="#subclasses">above</a> */
public static FSDirectory open(File path) throws IOException {
@ -208,7 +206,10 @@ public abstract class FSDirectory extends Directory {
* also specify a custom {@link LockFactory}. */
public static FSDirectory open(File path, LockFactory lockFactory) throws IOException {
if (Constants.WINDOWS) {
return new SimpleFSDirectory(path, lockFactory);
if (MMapDirectory.UNMAP_SUPPORTED && Constants.JRE_IS_64BIT)
return new MMapDirectory(path, lockFactory);
else
return new SimpleFSDirectory(path, lockFactory);
} else {
return new NIOFSDirectory(path, lockFactory);
}

View File

@ -64,7 +64,7 @@ import org.apache.lucene.util.Constants;
* an important limitation to be aware of.
*
* <p>This class supplies the workaround mentioned in the bug report
* (disabled by default, see {@link #setUseUnmap}), which may fail on
* (see {@link #setUseUnmap}), which may fail on
* non-Sun JVMs. It forcefully unmaps the buffer on close by using
* an undocumented internal cleanup functionality.
* {@link #UNMAP_SUPPORTED} is <code>true</code>, if the workaround
@ -78,7 +78,7 @@ import org.apache.lucene.util.Constants;
* </p>
*/
public class MMapDirectory extends FSDirectory {
private boolean useUnmapHack = false;
private boolean useUnmapHack = UNMAP_SUPPORTED;
private int maxBBuf = Constants.JRE_IS_64BIT ? Integer.MAX_VALUE : (256 * 1024 * 1024);
/** Create a new MMapDirectory for the named location.

View File

@ -721,11 +721,7 @@ public abstract class LuceneTestCase extends Assert {
tmpFile.mkdir();
try {
Constructor<? extends Directory> ctor = clazz.getConstructor(File.class);
Directory d = ctor.newInstance(tmpFile);
// try not to enable this hack unless we must.
if (d instanceof MMapDirectory && Constants.WINDOWS && MMapDirectory.UNMAP_SUPPORTED)
((MMapDirectory)d).setUseUnmap(true);
return d;
return ctor.newInstance(tmpFile);
} catch (Exception e2) {
// try .open(File)
Method method = clazz.getMethod("open", new Class[] { File.class });