On 2010-01-13 13:49, Jesse Wilson wrote:
On Tue, Jan 12, 2010 at 7:47 PM, Charles Lee<littlee1...@gmail.com> wrote:
What's the reason of bad idea? limited memory?
A cache that cannot be cleared is a disservice to users. It's an error in
our implementation (and the RI!) to assume that an application requesting
the canonical path two times wants to receive the same result. If the
application wants the same value, why doesn't the *application* cache the
result?!
canonical path is heavily used when checking file permission. So if a
SecurityManager is installed, canonical path will be calculated by every file
operation at least once, that the killer of performance, application cache can't
help that.
If we want to make Harmony faster, there are better ways to do so. The
simpler optimization is to streamline the code that looks up the canonical
path *the first time*. Reducing the number of times we cross a JNI boundary
is one of many opportunities here.
Yes, as I know resolving symbol links part on Linux can be done in one JNI call.
But it's not conflict with the cache.
What's the reason of bad implement? Anyone knows?
The canonical path cache code we shipped with Android 2.0 occasionally
caused applications to crash with a NoSuchElementException.
It is fixed by HARMONY-6414.
--
Best Regards,
Regis.
