> On Jan 13, 2017, at 4:05 PM, Naoto Sato <naoto.s...@oracle.com> wrote: >> >> Daniel asks whether there is any possibility that the target module or >> caller module would be GC’ed. >> >> CacheKey is copied in two places, one in findBundle and the other is >> putBundleInCache which is actually passed with a newly cloned CacheKey. >> IIUC, the cacheKey passed to findBundle ia always a new instance (as it >> subsequently sets to different locale during the lookup). Its caller module >> is the caller on the stack and the target module is also a strong reference >> either caller’s module, unnamed module from a given class loader, or a given >> module. >> >> Naoto will have to double check. > > I think this is correct. The current way of using CacheKey is safe from its > modules to be GC'ed. However in general, it'd be good prepare them to be > GC'ed. I modified the impl to hold them in local variables preventing them to > be GC'ed before instantiating new References. (Also I modified not to call > the other constructor in the copy constructor, reinstating some piece what > Peter's diff originally had). So here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8171139/webrev.04/
So callerRef and moduleRef may be null. getLoader(null) may be called which will throw NPE. Mandy
