[8u] RFR: JDK-8150460 (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Andrew Haley aph at redhat.com
Mon Jan 6 10:40:30 UTC 2020


On 1/2/20 12:02 PM, Andrew Dinn wrote:
> On 02/01/2020 10:12, Andrew Haley wrote:
>> On 1/2/20 9:35 AM, Andrew Dinn wrote:
>>> Updated Patch:
>>> The patch applies cleanly after tweaking the file paths and fixing up
>>> some minor whitespace and copyright headers differences
>>>
>>>   http://cr.openjdk.java.net/~adinn/8150460/webrev.00
>>
>> OK, thanks. I too thought that the MAP_NORESERVE solution was obvious,
>> but then I read the GraalVM discussion you referenced.
>
> Yes, that is an interesting constraint which Christian Wimmer did not
> actually confirm. If it really still applies (and, given that the desire
> to embed GraalVM programs seamlessly into OracleDB continues to exist, I
> think it does) then the Graal team's switch to using OpenJDK libraries
> has two alternative consequences: it either leaves GraalVM hostage to
> whatever decisions OpenJDK team members arrive at regarding importing
> system APIs into native libs; or it leaves the OpenJDK team hostage to
> this externally imposed restriction. I wonder if that is a good idea?

I'm not going to add GraalVM as an additional external constraint when
reviewing patches to libjvm. Apart from anything else, having to go through
both the GraalVM and OpenJDK processes would be intolerable.

> Regarding the patch: Does the above acknowledgement mean that I can push
> the patch to jdk8u-dev? If so does that also imply that the JIRA label
> should be switched from jdk8u-fix-request to jdk8u-fix-yes?

Done.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



More information about the jdk8u-dev mailing list