+1, looks fine to me also.
Roger
On 4/13/2016 6:46 AM, Thomas Stüfe wrote:
Thanks Dmitry!
On Wed, Apr 13, 2016 at 12:00 PM, Dmitry Samersoff
mailto:dmitry.samers...@oracle.com>> wrote:
Thomas,
Looks good for me!
-Dmitry
On 2016-04-13 12:12, Thomas Stüfe wrote:
> Hi
Thanks Dmitry!
On Wed, Apr 13, 2016 at 12:00 PM, Dmitry Samersoff <
dmitry.samers...@oracle.com> wrote:
> Thomas,
>
> Looks good for me!
>
> -Dmitry
>
>
> On 2016-04-13 12:12, Thomas Stüfe wrote:
> > Hi Roger, Dmitry,
> >
> > May I ask you both to have a last look at this change before I commit?
Thomas,
Looks good for me!
-Dmitry
On 2016-04-13 12:12, Thomas Stüfe wrote:
> Hi Roger, Dmitry,
>
> May I ask you both to have a last look at this change before I commit?
> It took a while for this to go through our internal tests, hence the delay.
>
> New
> version:
> http://cr.openjdk.java
Hi Roger, Dmitry,
May I ask you both to have a last look at this change before I commit? It
took a while for this to go through our internal tests, hence the delay.
New version:
http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.03/webrev/
Delta to last version:
http://
Thank you Roger!
On Fri, Mar 11, 2016 at 4:26 PM, Roger Riggs wrote:
> Hi Thomas,
>
> When returning the address of the fdentry, the style using &fdTable[fd] is
> preferred over
> the implicit pointer arithmetic (as it was in the previous version).
>
> Occurs in all 3 deltas:
>
> src/java.base/*
Hi Thomas,
When returning the address of the fdentry, the style using &fdTable[fd]
is preferred over
the implicit pointer arithmetic (as it was in the previous version).
Occurs in all 3 deltas:
src/java.base/*/native/libnet/*_close.c:
+result = fdTable + fd;
and
+result = fdO
Thank you Dmitry!
I will fix the typo before comitting.
Kind Regards, Thomas
On Thu, Mar 10, 2016 at 9:19 AM, Dmitry Samersoff <
dmitry.samers...@oracle.com> wrote:
> Thomas,
>
> Looks good for me. But please wait for someone from core-libs team.
>
> PS: Could you also fix a typeo at 79, 51, 53
Thomas,
Looks good for me. But please wait for someone from core-libs team.
PS: Could you also fix a typeo at 79, 51, 53?
s/initialized/initialization/
51 * Heap allocated during initialization - one entry per fd
-Dmitry
On 2016-03-10 10:59, Thomas Stüfe wrote:
> Hi,
>
> may I have a r
Hi,
may I have a review of this new iteration for this fix?
Thank you!
Thomas
On Thu, Mar 3, 2016 at 5:26 PM, Thomas Stüfe
wrote:
> Hi all,
>
> https://bugs.openjdk.java.net/browse/JDK-8150460
>
> thanks to all who took the time to review the first version of this fix!
>
> This is the new ver
Hi all,
https://bugs.openjdk.java.net/browse/JDK-8150460
thanks to all who took the time to review the first version of this fix!
This is the new version:
http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.02/webrev/
I reworked the fix, trying to add in all the input
Thomas,
> The more I look at this, the more I think that the costs for a
> pthread mutex lock are acceptable in this case: we are about to do a
> blocking IO operation anyway, which is already flanked by two mutex
> locking calls (in startOp and endOp). I doubt that a third mutex call
> will be th
Hi Hans,
On Thu, Mar 3, 2016 at 4:08 AM, Hans Boehm wrote:
>
> On Wed, Mar 2, 2016 at 12:09 AM, Thomas Stüfe
> wrote:
> >
> > Hi Hans,
> >
> > thanks for the hint!
> >
> > But how would I do this for my problem:
> >
> > Allocate memory, zero it out and then store the pointer into a variable
> s
Hi Andrew,
On Wed, Mar 2, 2016 at 9:28 AM, Andrew Haley wrote:
> On 01/03/16 10:20, Dmitry Samersoff wrote:
> > The bug: https://bugs.openjdk.java.net/browse/JDK-8150460
> >> The Webrev:
> >>
> http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.00/webrev/
>
> Why use c
On 01/03/16 10:20, Dmitry Samersoff wrote:
> The bug: https://bugs.openjdk.java.net/browse/JDK-8150460
>> The Webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.00/webrev/
Why use calloc here? Surely it makes more sense to use
mmap(MAP_NORESERVE), at least on
le = fdTable[rootArrayIndex]; // no matter if
>>>> rootArrayIndex
>>>> is 0
>>>>
>>>> Then check if entryTable is NULL and if yes then enter a guarded
>>>> section which does the allocation and before that checks if a
<mailto:core-libs-dev-boun...@openjdk.java.net>] On Behalf Of Dmitry
Samersoff
Sent: Dienstag, 1. März 2016 11:20
To: Thomas Stüfe mailto:thomas.stu...@gmail.com>>; Java Core Libs
mailto:core-libs-dev@openjdk.java.net>>
Subject: Re: RFR(s): 8150460: (linux|bsd|aix
ght now it is calculated every time getFdEntry()
> is
> > > called and I don't think this would be optimized by inlining...
> > >
> > > Best regards Christoph
> > >
> > > -Original Message- From: core-libs-dev
&g
nk this would be optimized by inlining...
> >
> > Best regards Christoph
> >
> > -Original Message----- From: core-libs-dev
> > [mailto:core-libs-dev-boun...@openjdk.java.net
> <mailto:core-libs-dev-boun...@openjdk.java.net
t think this would be optimized by
> inlining...
>
> Best regards
> Christoph
>
> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net
> <mailto:core-libs-dev-boun...@openjdk.java.net>] On Behalf Of Dmi
in a static
> > field? Because right now it is calculated every time getFdEntry() is
> > called and I don't think this would be optimized by inlining...
> >
> > Best regards Christoph
> >
> > -Original Message----- From: core-libs-dev
> >
Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
> Behalf Of Dmitry Samersoff
> Sent: Dienstag, 1. März 2016 11:20
> To: Thomas Stüfe ; Java Core Libs <
> core-libs-dev@openjdk.java.net>
> Subject: Re: RFR(s): 8150460: (lin
s
> called and I don't think this would be optimized by inlining...
>
> Best regards Christoph
>
> -Original Message- From: core-libs-dev
> [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Dmitry
> Samersoff Sent: Dienstag, 1. März 2016 11:20 To: Thomas
y inlining...
Best regards
Christoph
-Original Message-
From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
Of Dmitry Samersoff
Sent: Dienstag, 1. März 2016 11:20
To: Thomas Stüfe ; Java Core Libs
Subject: Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descri
Thomas,
Sorry for being later.
I'm not sure we should take a lock at ll. 131 for each fdTable lookup.
As soon as we never deallocate fdTable[base_index] it's safe to try to
return value first and then take a slow path (take a lock and check
fdTable[base_index] again)
-Dmitry
On 2016-02-24 20:
On 1/03/2016 7:27 PM, Thomas Stüfe wrote:
Ping...
Could I have reviewer and a sponsor, please?
You don't need a sponsor for this JDK change - you are a Committer. :)
Cheers,
David
Thanks you!
Thomas
On Thu, Feb 25, 2016 at 5:51 PM, Thomas Stüfe
wrote:
Hi Roger,
thank you for the revie
Ping...
Could I have reviewer and a sponsor, please?
Thanks you!
Thomas
On Thu, Feb 25, 2016 at 5:51 PM, Thomas Stüfe
wrote:
> Hi Roger,
>
> thank you for the review!
>
> New webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.01/webrev/
>
> Please find my
Hi Roger,
thank you for the review!
New webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.01/webrev/
Please find my comments inline.
On Wed, Feb 24, 2016 at 8:28 PM, Roger Riggs wrote:
> Hi Thomas,
>
> On 2/24/2016 12:30 PM, Thomas Stüfe wrote:
>
>> Hi all,
Hi Thomas,
On 2/24/2016 12:30 PM, Thomas Stüfe wrote:
Hi all,
please take a look at this proposed fix.
The bug: https://bugs.openjdk.java.net/browse/JDK-8150460
The Webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.00/webrev/
Basically, the file descriptor
Hi all,
please take a look at this proposed fix.
The bug: https://bugs.openjdk.java.net/browse/JDK-8150460
The Webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.00/webrev/
Basically, the file descriptor table implemented in linux_close.c may not
work for RLIMI
29 matches
Mail list logo
