Hi Alan, Thank you for your comment.
I agree that the current code is not thread safe, but I think OIS itself is not thread safe either. The issue you pointed out occurs when two threads calls readObject()/readUnshared() simultaneously, and the result of such situation is undefined in any way in my understanding. Do we need to ensure the same behavior for such an error case? Regarding readResolve, I think readResolve() won't use the cached loader because readResolve() of a deserialized class can't call OIS.resolveClass(). Regards, Ogata Alan Bateman <alan.bate...@oracle.com> wrote on 2017/10/09 20:24:20: > From: Alan Bateman <alan.bate...@oracle.com> > To: Kazunori Ogata <oga...@jp.ibm.com>, core-libs-dev@openjdk.java.net > Date: 2017/10/09 20:24 > Subject: Re: RFR: 8188858: Caching latestUserDefinedLoader() results in > ObjectInputStream.readObject() > > On 06/10/2017 11:34, Kazunori Ogata wrote: > > Hi all, > > > > Please review a change for JDK-8188858. > > > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8188858 > > Webrev: http://cr.openjdk.java.net/~horii/8188858/webrev.00/ > > > > This change caches the result of latestUserDefinedLoader() when objects > > are deserialized, so the decerializer can avoid redundant stack walking to > > resolve classes of deserializing objects. > Some of the bugs/abuses of OIS come about from calling it on different > threads with different contexts. So I think this optimization can only > work if to confine it to the thread calling readUnshared, meaning > readResolve cannot skip latestUserDefinedLoader() when called on other > threads. > > -Alan >
