RFR 6415680 handle windows EXCEPTION_IN_PAGE_ERROR just as SIGBUS is handled

[Andrei Pangin]

Hi Kirk,

Thanks for looking into this long-standing bug.
I personally hit this issue several times and also attempted to address it.
Your fix is good, but it does not work in some cases.
Current implementation of the signal handler sets thread's async exception
and then simply returns control to the next instruction.
This works fine for Unsafe_getX/Unsafe_setX, but not for Unsafe_CopyMemory
which repeats loads or stores in the loop.
Each iteration will repeatedly produce EXCEPTION_IN_PAGE_ERROR until the
loop ends. This can take hours for a long loop, e.g. if the target array is
hundred megabytes large. The process will look hanging utilizing 100% of
one CPU core.

One of the possible solutions is to demarcate the boundaries of the copying
loop so that handle_unsafe_access() could detect if the exception occured
in the loop and bail out.

A similar problem could probably happen in Unsafe_SetMemory as well. So I
suggest to include it in the fix, too.

Regards,
  Andrei

2015-06-24 19:37 GMT+03:00 Kirk Shoop (MS OPEN TECH) <
Kirk.Shoop at microsoft.com>:

> > -----Original Message-----
> > From: David Holmes [mailto:david.holmes at oracle.com]
> > Subject: Re: RFR 6415680 handle windows EXCEPTION_IN_PAGE_ERROR just
> > as SIGBUS is handled
> >
> > On 24/06/2015 4:30 PM, Alan Bateman wrote:
> > >
> > >
> > > Kirk - as this is changing code in HotSpot then it's best to bring
> > > this to hotspot-runtime-dev for review + sponsor.
> >
> > Not only "best" but required :)
> >
> > Hi Kirk, it is great to see active participation from MS here! To push
> this to
> > hotspot it needs to be re-based against one of the team repos - and I
> think
> > runtime is the right fit here as it owns the OS specific code and the
> unsafe
> > interface:
> >
> > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot
>
> Okay, will do.
>
> >
> > Thanks,
> > David
> >
> > > -Alan
>
> Thank you,
> Kirk
>
> Developer
> Microsoft Open Technologies, Inc.
>