RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()
OGATAK at jp.ibm.com
Tue Oct 10 09:50:59 UTC 2017
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?
I think readResolve() won't use the cached loader because readResolve() of
a deserialized class can't call OIS.resolveClass().
Alan Bateman <Alan.Bateman at oracle.com> wrote on 2017/10/09 20:24:20:
> From: Alan Bateman <Alan.Bateman at oracle.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>, core-libs-dev at openjdk.java.net
> Date: 2017/10/09 20:24
> Subject: Re: RFR: 8188858: Caching latestUserDefinedLoader() results in
> 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
> > are deserialized, so the decerializer can avoid redundant stack
> > 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
More information about the core-libs-dev