RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

[Kazunori Ogata]

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.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 
> 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
>