Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)
Vitaly Davidovich
vitalyd at gmail.com
Thu Sep 10 14:13:17 UTC 2015
So what happens after safepoint is done and thread accesses the mapping (it
would need protection NONE, not just write)? JVM is then going to trap the
signal and convert to an exception?
sent from my phone
On Sep 10, 2015 10:06 AM, "Andrew Haley" <aph at redhat.com> wrote:
> On 09/10/2015 02:48 PM, David M. Lloyd wrote:
> > On 09/10/2015 08:22 AM, Andrew Haley wrote:
> >> On 09/10/2015 12:25 PM, Vitaly Davidovich wrote:
> >>
> >>> The safepoint happiness is unfortunately a separate issue in
> >>> Hotspot, and it's definitely not happy times :). Part of the
> >>> problem is the piggybacking of various operations on a safepoint -
> >>> the safepoint time alone (not counting GC, say) keeps growing. You
> >>> probably could piggyback this on GuaranteedSafepointInterval
> >>> safepoints, but those are currently predicated on IC buffers needing
> >>> to be cleaned.
> >>
> >> OK. I see that there is a conflict here.
> >
> > Is it possible that the operation could be simplified - down to setting
> > a flag maybe - so that the expensive/potentially dangerous stuff (the
> > actual unmap) can be done in a proper thread?
>
> Sure.
>
> The mapping can't be removed until you know for sure that no thread is
> using it. For that to be known you need a safepoint, but (you may
> like this) the safepoint itself doesn't have to actually do anything.
> I imagine it would go like this:
>
> write-protect the guard page
> trigger a safepoint ...
> ... wait for safepoint to complete
> remove the mapping
>
> >>> Would we exceed the complexity budget if posix systems would use
> >>> memory remapping and windows safepoints?
> >>
> >> I can still see address space exhaustion happening on unices.
> >
> > Still, it's important to remember that the status quo currently
> > exhausts address space *and* actual backing resources, so anything
> > is really an improvement at this point...
>
> Yea, but much of the effort of developing something like this is the
> overhead of discussions, creating bugs, and so on. Once the box is
> opened the extra effort of doing it properly is relatively cheap. And
> besides, where is the pleasure in writing a half-arsed solution?
>
> Andrew.
>
More information about the core-libs-dev
mailing list