Approved; thanks David,
-Joe
On 9/8/2015 9:38 PM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8133611
Webrev: http://cr.openjdk.java.net/~dholmes/8133611/webrev/
Patch inline below.
Now the hotspot fix is in place the test can be removed from the
problem list and need
Bug: https://bugs.openjdk.java.net/browse/JDK-8133611
Webrev: http://cr.openjdk.java.net/~dholmes/8133611/webrev/
Patch inline below.
Now the hotspot fix is in place the test can be removed from the problem
list and need not be marked "intermittent".
Thanks,
David
-
--- old/test/Problem
On 9/4/15 1:35 AM, Paul Sandoz wrote:
Hi Stuart,
This is looking very good.
Just some comments on the tricky aspect related to late-binding of the Stream
to the scanner state:
2652 * This scanner's state should not be modified during execution of
the returned
2653 * stream's pipe
On 09/08/2015 09:15 PM, Remi Forax wrote:
On 09/08/2015 03:29 PM, Andrew Haley wrote:
On 09/08/2015 02:05 PM, Andrew Haley wrote:
I don't think you'd actually need to unmap anything until a safepoint.
I don't think that the speed of unmapping is critical as long as it
happens "soon".
Althoug
> On 8 Sep 2015, at 22:34, Roger Riggs wrote:
>
> Oops, Corrected links to webrev:
>
> On 9/8/2015 5:10 PM, Roger Riggs wrote:
>> Please review this test fix.
>> The test assumes that the pathname of the command is literally the same as
>> the executable path provides to ProcessBuilder. However
With link to webrev corrected:
On 9/8/2015 5:08 PM, Roger Riggs wrote:
Please review an intermittent test bug fix.
The test setup time is very short and the user may be returned as 0
which is reported as root.
The correction lengthens the time allowed for the process to start.
The test is rem
Oops, Corrected links to webrev:
On 9/8/2015 5:10 PM, Roger Riggs wrote:
Please review this test fix.
The test assumes that the pathname of the command is literally the
same as
the executable path provides to ProcessBuilder. However, if the path
contains
a symbolic link, it is resolved and the
Please review this test fix.
The test assumes that the pathname of the command is literally the same as
the executable path provides to ProcessBuilder. However, if the path
contains
a symbolic link, it is resolved and the real path is reported as the
command.
Webrev:
http://bussund0416.us.orac
Please review an intermittent test bug fix.
The test setup time is very short and the user may be returned as 0
which is reported as root.
The correction lengthens the time allowed for the process to start.
The test is removed from the ProblemList.
Webrev:
http://bussund0416.us.oracle.com/~rri
Am 08.09.2015 um 20:37 schrieb Andrew Haley:
I think that MR is referring to Windows when he talks about race conditions. Andrew.
Couldn't we introduce a unmap() method which throws an UnsupportedOperationException if the
underlying OS isn't able to unmap the the buffer safely in the mean time
Anyone like to take this on please?
Stephen
On 28 Aug 2015 00:07, "Stephen Colebourne" wrote:
> External question sites indicate that users have difficulty converting
> between java.util.Date and LocalDate, and also between Instant and
> LocalDate/LocalTime. This user difficulty can be resolved w
>
> I think that MR is referring to Windows when he talks about
> race conditions.
The race can happen on any platform if you can't do an atomic unmap of a
file and remap to some kind of guard page. I guess on Linux you can, maybe?
I've never tried it.
It may be that on Windows if you remap a fi
You'd want to then MapViewOfFileEx later using VirtualAllocEx reservation
(to change the mapping), but I don't think MapViewOfFileEx allows
specifying a base address that is reserved via VirtualAllocEx.
On Tue, Sep 8, 2015 at 3:41 PM, Mike Hearn wrote:
> Sorry, seems I must have hit send without
Sorry, seems I must have hit send without noticing.
Windows has this:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366890(v=vs.85).aspx
However the question is, what happens if you remap a range and then unmap
the file from that same range?
I'm assuming the file unmap operation de
>
> So Windows has no operation which can remap a previously mapped section of
> memory to something else? (say, just a block of non-access memory)
>
> Note that such an operation has to be atomic with respect to all other
> operations which affect the address space of the process (or at least,
> w
On 09/08/2015 03:29 PM, Andrew Haley wrote:
> On 09/08/2015 02:05 PM, Andrew Haley wrote:
>> I don't think you'd actually need to unmap anything until a safepoint.
>> I don't think that the speed of unmapping is critical as long as it
>> happens "soon".
>
> Although given the desire to do
>
> buf
On 09/08/2015 01:37 PM, Andrew Haley wrote:
On 09/08/2015 06:54 PM, David M. Lloyd wrote:
I think the only questionable platform at this point is Windows (to me
at least, given that I do not have much experience on it).
That's right, and it's Windows which has the worst problem: on UNIX
you ca
On 09/08/2015 06:54 PM, David M. Lloyd wrote:
> I think the only questionable platform at this point is Windows (to me
> at least, given that I do not have much experience on it).
That's right, and it's Windows which has the worst problem: on UNIX
you can delete a file which is mapped, on Windows
On 09/08/2015 12:40 PM, Andrew Haley wrote:
On 09/08/2015 06:03 PM, David M. Lloyd wrote:
On 09/08/2015 08:11 AM, Andrew Haley wrote:
On 09/08/2015 12:37 PM, David M. Lloyd wrote:
Then you do the real unmap when
the buffer is GC'd (maybe via Cleaner). This is very akin to how file
descriptors
On 09/08/2015 06:03 PM, David M. Lloyd wrote:
> On 09/08/2015 08:11 AM, Andrew Haley wrote:
>> On 09/08/2015 12:37 PM, David M. Lloyd wrote:
>>> Then you do the real unmap when
>>> the buffer is GC'd (maybe via Cleaner). This is very akin to how file
>>> descriptors are cleaned up, AFAICT.
>>
>> I
On 09/08/2015 08:11 AM, Andrew Haley wrote:
On 09/08/2015 12:37 PM, David M. Lloyd wrote:
Then you do the real unmap when
the buffer is GC'd (maybe via Cleaner). This is very akin to how file
descriptors are cleaned up, AFAICT.
Indeed it is, and it's no better than the status quo. This is an
On 09/08/2015 08:03 AM, Mike Hearn wrote:
If you're already doing this, why not skip the level of indirection
and mprotect the entire mapped region to PROT_NONE when the user
unmaps? ... Then you do the real unmap when the buffer is GC'd
(maybe via Cleaner).
Because the reas
On 09/08/2015 02:05 PM, Andrew Haley wrote:
> I don't think you'd actually need to unmap anything until a safepoint.
> I don't think that the speed of unmapping is critical as long as it
> happens "soon".
Although given the desire to do
buffer.unmap();
file.delete();
that belief may be mispl
> Because the reason users are working around this is Windows, where they
> need the ability to do:
>
> buffer.unmap();
> file.delete();
This is exactly the case in Lucene, for example. Which currently
resorts to ugly hacks (the entire documentation of this class is
interesting -- concerns memory
On 09/08/2015 12:37 PM, David M. Lloyd wrote:
> Then you do the real unmap when
> the buffer is GC'd (maybe via Cleaner). This is very akin to how file
> descriptors are cleaned up, AFAICT.
Indeed it is, and it's no better than the status quo. This is an attempt
to do better.
Andrew.
On 09/08/2015 12:37 PM, David M. Lloyd wrote:
> On 09/08/2015 04:30 AM, Andrew Haley wrote:
>> On 09/08/2015 09:58 AM, Paul Sandoz wrote:
>
>> However, I think that some cleverness in HotSpot could make that cost
>> go away. For example, we could associate with every
>> MappedByteBufferForwarding
that's true, the documentation is a bit nebulous on this issue.
but the inference is that the file descriptors are indeterminate state.
some older man pages allude to this
as per solaris man pages, close will
" If close() is interrupted by a signal that is to be caught,
it will return -1 with
On 09/08/2015 11:42 AM, Paul Sandoz wrote:
>
> On 8 Sep 2015, at 11:30, Andrew Haley wrote:
>> But never mind that; how about this idea? Create a
>> MappedByteBufferForwardingObject whose only job is to forward requests
>> to a MappedByteBuffer. That MappedByteBuffer does not escape from the
>
>
> If you're already doing this, why not skip the level of indirection and
> mprotect the entire mapped region to PROT_NONE when the user unmaps?
> ... Then you do the real unmap when the buffer is GC'd (maybe via
> Cleaner).
Because the reason users are working around this is Windows, where
On 08/09/2015 09:58, Paul Sandoz wrote:
HI Mike,
This is fundamentally about *integrity* of the runtime. It follows there are
security implications, but it’s still fundamentally an integrity issue and
guarding an unsafe operation with a Security Manager is unfortunately an
insufficient solu
On 09/08/2015 04:30 AM, Andrew Haley wrote:
On 09/08/2015 09:58 AM, Paul Sandoz wrote:
This is fundamentally about *integrity* of the runtime. It follows
there are security implications, but it’s still fundamentally an
integrity issue and guarding an unsafe operation with a Security
Manager is
On 8 Sep 2015, at 11:30, Andrew Haley wrote:
> On 09/08/2015 09:58 AM, Paul Sandoz wrote:
>
>> This is fundamentally about *integrity* of the runtime. It follows
>> there are security implications, but it’s still fundamentally an
>> integrity issue and guarding an unsafe operation with a Securi
On 09/08/2015 09:58 AM, Paul Sandoz wrote:
> This is fundamentally about *integrity* of the runtime. It follows
> there are security implications, but it’s still fundamentally an
> integrity issue and guarding an unsafe operation with a Security
> Manager is unfortunately an insufficient solution.
HI Mike,
This is fundamentally about *integrity* of the runtime. It follows there are
security implications, but it’s still fundamentally an integrity issue and
guarding an unsafe operation with a Security Manager is unfortunately an
insufficient solution.
Paul.
On 7 Sep 2015, at 18:41, Mike
On 7 Sep 2015, at 17:41, Mark Sheppard wrote:
> a couple of other considerations in the context of this issue perhaps?
>
> in this s is being duped onto fd, and part of the dup2 operation is the
> closing of fd, but
> what's is the expected state of file descriptor fd in the event of a dup2
>
35 matches
Mail list logo
