[RFC] [openjdk] provide milisecond modification timestamps

[Thomas Meyer]

Am Dienstag, den 24.04.2012, 20:39 -0400 schrieb Andrew Hughes:
> ----- Original Message -----
> > Am Montag, den 23.04.2012, 14:22 -0400 schrieb Andrew Hughes:
> > > ----- Original Message -----
> > > > Am Montag, den 23.04.2012, 12:41 -0400 schrieb Andrew Hughes:
> > > > > ----- Original Message -----
> > > > > > diff -r 8ac52c85f9e9
> > > > > > src/solaris/native/java/io/UnixFileSystem_md.c
> > > > > > --- a/src/solaris/native/java/io/UnixFileSystem_md.c	Wed Feb
> > > > > > 23
> > > > > > 15:49:19
> > > > > > 2011 -0800
> > > > > > +++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Sat Apr
> > > > > > 21
> > > > > > 10:11:26
> > > > > > 2012 +0200
> > > > > > @@ -197,7 +197,10 @@
> > > > > >      WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
> > > > > >          struct stat64 sb;
> > > > > >          if (stat64(path, &sb) == 0) {
> > > > > > -            rv = 1000 * (jlong)sb.st_mtime;
> > > > > > +            if(sb.st_mtimensec != 0)
> > > > > > +            	rv = (jlong)sb.st_mtimensec / 1000000;
> > > > > > +            else
> > > > > > +                rv = 1000 * (jlong)sb.st_mtime;
> > > > > >          }
> > > > > >      } END_PLATFORM_STRING(env, path);
> > > > > >      return rv;
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > > Hi Andrew,
> > > > 
> > > > > This looks a sensible improvement to me.  I can add it to the
> > > > > IcedTea
> > > > > repository.
> > > > 
> > > > But it only looks sensible :-) The correct patch against jdk7 is
> > > > attached!
> > > > 
> > > > I looks like the field st_mtim.tv_nsec is just an extension to
> > > > the
> > > > second accuracy provided by st_mtim.tv_sec.
> > > > 
> > > 
> > > Ah right, yes this is the same way clock_gettime works, which we
> > > use
> > > to implement System.nanoTime in GNU Classpath:
> > > 
> > >   result = (jlong) tp.tv_sec;
> > >   result *= (jlong)1000000000L;
> > >   result += (jlong)tp.tv_nsec;
> > > 
> > > The difference here is that the Java API means that most of the
> > > accuracy
> > > gain is lost in the division.  I wonder if there is a case for a
> > > deeper
> > > patch that allows nanosecond accuracy to be fully exposed?
> > 
> > At least not for File.lastModified() which returns "a long value
> > representing the time the file was last modified, measured in
> > milliseconds since the epoch".
> > 
> 
> Yes, I guessed that.  But it doesn't mean another method couldn't be added.
> But...
> 
> > [me having a quick look at the new stuff in 1.7]
> > 
> > Oh, nice! Java 7 seems to have FileTime and
> > Files.getLastModifiedTime().
> > 
> 
> ...I'm guessing Oracle will just point to this new API.  Does it provide
> nanosecond accuracy?

The API looks like it could support nanosecond timestamps (because of
the abstraction via FileTime class), but surprisingly it doesn't support
it!

[jdk7]$ grep -R st_mtim *
hotspot/src/share/vm/memory/filemap.cpp:      _header._jar[_header._num_jars]._timestamp = st.st_mtime;
hotspot/src/share/vm/memory/filemap.cpp:        if (_header._jar[num_jars_now]._timestamp != st.st_mtime ||
hotspot/src/os/windows/vm/os_windows.cpp:    // Fix for 6539723.  st_mtime returned from stat() is dependent on
hotspot/src/os/windows/vm/os_windows.cpp:    sbuf->st_mtime += (tz.Bias + daylightBias) * 60;
-> Hotspot stuff

jdk/src/solaris/native/java/io/UnixFileSystem_md.c:            rv = 1000 * (jlong)sb.st_mtim.tv_sec + (jlong)sb.st_mtim.tv_nsec / 1000000;
-> My patch applied. unix syscall happens here for old File.lastModified()

jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c:static jfieldID attrs_st_mtime;
jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c:    attrs_st_mtime = (*env)->GetFieldID(env, clazz, "st_mtime", "J");
jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c:    (*env)->SetLongField(env, attrs, attrs_st_mtime, (jlong)buf->st_mtime);
jdk/src/solaris/classes/sun/nio/fs/UnixFileAttributes.java:    private long    st_mtime;
jdk/src/solaris/classes/sun/nio/fs/UnixFileAttributes.java:        return FileTime.from(st_mtime, TimeUnit.SECONDS);
-> New Java 1.7 API stuff


The read of the st_mtim for File.lastModified() seems to happen in the
file I patched:
 jdk/src/solaris/native/java/io/UnixFileSystem_md.c

The new 1.7 API seems to always return FileTime in units "SECONDS", see:
 jdk/src/solaris/classes/sun/nio/fs/UnixFileAttributes.java

and the read (stat64 syscall) happens here:
 jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
 jdk/src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java
-> only st_mtime is used! So no nanosecond accuracy for the new API... 

> 
> > But I guess the 1.7 API is no option for icedtea-web (yet)?!
> > 
> 
> I don't see why IcedTea-Web is relevant to this discussion?

I'm about to implement a check in icedtea-web to not reload the cache
index file when the file modification timestamp has not changed since
the last save of the file. I stumbled upon this while trying to write
some unit tests to check if the file needs to be reloaded resp. has been
reloaded. Given that my underlying ext4 file system support nanosecond
resolution I did wonder why my check for the modification timestamp did
not work, i.e. the file was not reloaded as expected.

with kind regards
thomas