RFR 6415680 handle windows EXCEPTION_IN_PAGE_ERROR just as SIGBUS is handled

[Martin Sawicki]

Hi all
Any other news/feedback on this bug fix submission?
Best regards
Martin

-----Original Message-----
From: Martin Sawicki 
Sent: Monday, September 28, 2015 11:11 AM
To: 'Andrei Pangin' <andrei.pangin at gmail.com>; hotspot-runtime-dev at openjdk.java.net; Vladimir Shcherbakov <vlashch at microsoft.com>
Subject: RE: RFR 6415680 handle windows EXCEPTION_IN_PAGE_ERROR just as SIGBUS is handled

Hi all
Here is the updated webrev attempting to take into account the feedback we've received.

Issue:  
  https://bugs.openjdk.java.net/browse/JDK-6415680

Webrev:
  http://cr.openjdk.java.net/~kshoop/6415680/webrev.01/ 

(Vladimir Shcherbakov is working on this now from our side)

Looking forward to any other feedback
Thanks

-----Original Message-----
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Andrei Pangin
Sent: Wednesday, June 24, 2015 5:49 PM
To: Kirk Shoop (MS OPEN TECH) <Kirk.Shoop at microsoft.com>
Cc: Valery Kopylov (Akvelon) <v-valkop at microsoft.com>; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR 6415680 handle windows EXCEPTION_IN_PAGE_ERROR just as SIGBUS is handled

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