RFR: JDK-8240148: Uncaught exceptions from ScheduledThreadPoolExecutor.execute aren't reported

Could I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8240148? The patch is available as a webrev at https://cr.openjdk.java.net/~jpai/webrev/8240148/1/ The patch updates the ScheduledThreadPoolExecutor.execute(Runnable) to wrap the user passed Runnable

RFR: JDK-8247592: refactor test/jdk/tools/launcher/Test7029048.java

Hi, I'd like to refactor test/jdk/tools/launcher/Test7029048.java, make the logic easier to follow and remove some magic numbers from the test: JBS: https://bugs.openjdk.java.net/browse/JDK-8247592 Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/ Testing: the test passes on

RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Hi, Could someone please review myself and Julia's RFE and CSR for JDK-8238286 - 'Add new flatMap stream operation that is more amenable to pushing’? This proposal is to add a new flatMap-like operation: ` Stream mapMulti(BiConsumer, ? super T> mapper)` to the java.util.Stream class. This

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

On 2020-06-18 08:34, Kim Barrett wrote: On Jun 15, 2020, at 7:41 AM, Kim Barrett wrote: On Jun 14, 2020, at 12:45 AM, Philip Race wrote: Kim, Until it says in "the JDK" and not "in HotSpot" you have not addressed my main point. Please rename the JEP. After some off-list discussions I

Build error with GCC 10 in NetworkInterface.c and k_standard.c

Hi all, (I've sent a similar e-mail before to this ML, but I extract the part only related to core-libs-dev ML from the previous one.) I tried to build OpenJDK fastdebug with GCC 10.1 on Ubuntu 18.04, but I saw some compiler warnings as follows:

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

Peter, > On 24 Jun 2020, at 10:16, Peter Levart wrote: > > Hi, > > I wonder why "isRecord" was not encoded in class modifier bits, like "isEnum" > was for example. Are all 32 bits already taken? > These bits are precious and limited! ;-) The record-ness of a class is already implicit by the

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

Hi, I wonder why "isRecord" was not encoded in class modifier bits, like "isEnum" was for example. Are all 32 bits already taken? The isEnum() does not have the performance problem since getModifiers() native method is intrinsified. Regards, Peter On 6/24/20 10:20 AM, Chris Hegarty

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

Hi Chris, On 24/06/2020 2:30 am, Chris Hegarty wrote: On 23 Jun 2020, at 14:49, Peter Levart wrote: ... Ok, I'm going to push this to jdk15. Thank you Peter. This is a really nice change. As a follow on, and not for JDK 15, I observe that Class::isRecord0 / JVM_IsRecord shows up as

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

> On 24 Jun 2020, at 07:03, David Holmes wrote: > > Hi Chris, > > On 24/06/2020 2:30 am, Chris Hegarty wrote: >>> On 23 Jun 2020, at 14:49, Peter Levart wrote: >>> >>> ... >>> >>> Ok, I'm going to push this to jdk15. >> Thank you Peter. This is a really nice change. >> As a follow on, and

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

Consider a ClassValue for this, if there is not an obvious bit to be repurposed somewhere. On 6/23/2020 12:30 PM, Chris Hegarty wrote: I think it is worth considering caching the record-ness state of a j.l.Class, as I’m sure it will be widely used in third-party serialization libraries, as

Re: RFR [15] 8248233: Avoid superfluous Class::isRecord invocations during deserialization

Hi Chris, On 2020-06-24 17:46, Chris Hegarty wrote: A micro-optimisation noticed when working on JDK-8247532. For further details see: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067446.html Webrev: https://cr.openjdk.java.net/~chegar/8248233/webrev.00/ This looks

Re: RFR: JDK-8248239: jpackage adds some arguments twice in case it is re-executed by JLI

Aleksei, If I get it right, the fix would not work for the case when there are `arguments` properties in `ArgOptions` section of a config file. Why not just check if the parent process is the same executable as the current one and if this is the case don't read data from the config file but

Re: RFR [15] 8248233: Avoid superfluous Class::isRecord invocations during deserialization

> On 24 Jun 2020, at 17:15, Claes Redestad wrote: > > ... > It seems ObjectInputStream#isRecord(Class) is now unused. No need for > a new webrev if you choose to remove it. Good catch, now removed. > On 24 Jun 2020, at 17:25, Peter Levart wrote: > > Hi Chris, > > The patch looks good. >

Re: RFR: JDK-8240148: Uncaught exceptions from ScheduledThreadPoolExecutor.execute aren't reported

Thanks for your work on this. Invoking the UEH machinery directly is extremely unusual and would never have occurred to me (outside of a test). In a loom-directed world, any attempt to directly manipulate the current thread is likely to lead to trouble. This code is primarily maintained

RFR: JDK-8248239: jpackage adds some arguments twice in case it is re-executed by JLI

Hi, There are systems that update LD_LIBRARY_PATH or directly return JNI_TRUE in method RequiresSetenv(const char *jvmpath) from java_md.c file to request re-execution of the current executable. This leads to the fact that jpackage application adds some provided arguments twice. Bug:

Re: RFR [15] 8248233: Avoid superfluous Class::isRecord invocations during deserialization

Hi Chris, The patch looks good. Before the patch it made sense to have if (cl != null) in line 750 in ObjectStreamClass, but now nothing in the if block depends on cl, so you could use if (osc != null) instead. It is true that: (cl != null) == (osc != null) always holds there, but

RFR [15] 8248233: Avoid superfluous Class::isRecord invocations during deserialization

A micro-optimisation noticed when working on JDK-8247532. For further details see: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067446.html Webrev: https://cr.openjdk.java.net/~chegar/8248233/webrev.00/ before: RecordSerializationBench.deserializeClasses10

Re: [15] RFR JDK-8247785: Small clarification to the javadoc about builtin class loaders

Hi Mandy, I'm fine with this. Roger On 6/23/20 5:42 PM, Mandy Chung wrote: On 6/23/20 12:01 PM, Roger Riggs wrote: Hi Mandy, There may be a missing "to" in: + * Platform classes are visible the platform class loader ++ * Platform classes are visible *via* the platform class

Contributing to JEP 356: Enhanced Pseudo-Random Number Generators ?

Hi, seems like the last activity in JBS related to this JEP [1, 2] dates back to June 2019. Are there major stumbling blocks? Can I contribute in any way? Greetings Raffaello [1] http://openjdk.java.net/jeps/356 [2] https://bugs.openjdk.java.net/browse/JDK-8193209

Re: [15] RFR: 8248255: [macos] Add failing DMG tests to problem list

Looks good. - Alexey On 6/24/2020 4:09 PM, alexander.matv...@oracle.com wrote: Please review the jpackage fix for bug [1] at [2]. Added EmptyFolderPackageTest, IconTest, AppImagePackageTest, SimplePackageTest, BasicTest to ProblemList.txt. [1]

[15] RFR: 8248255: [macos] Add failing DMG tests to problem list

Please review the jpackage fix for bug [1] at [2]. Added EmptyFolderPackageTest, IconTest, AppImagePackageTest, SimplePackageTest, BasicTest to ProblemList.txt. [1] https://bugs.openjdk.java.net/browse/JDK-8248255 [2] http://cr.openjdk.java.net/~almatvee/8248255/webrev.00/ Thanks, Alexander

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

On Jun 24, 2020, at 1:01 PM, John Rose wrote: > > What’s the performance model? It seems like the SpinedBuffer > implementation makes a worst-case assumption about the number > of pending values, that there will be many instead of zero or one. > > But I guess the pipeline stuff already works

Re: [15] RFR JDK-8247785: Small clarification to the javadoc about builtin class loaders

Hi Roger, David, Thanks for the help in improving this.  As a record, this webrev shows the version as David suggests: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8247785/webrev.00/ Mandy On 6/24/20 9:33 AM, Roger Riggs wrote: Hi Mandy, I'm fine with this. Roger

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hi Alexey, The JNDI/LDAP part looks mostly good. You will need someone from the security libs to review the security lib part of the changes. In the test I would recommend using the test URIBuilder to avoid strange intermittent errors if the test is run on a machine where looking up "localhost"

Re: [15] RFR: 8248255: [macos] Add failing DMG tests to problem list

looks good. /Andy On 6/24/2020 4:09 PM, alexander.matv...@oracle.com wrote: Please review the jpackage fix for bug [1] at [2]. Added EmptyFolderPackageTest, IconTest, AppImagePackageTest, SimplePackageTest, BasicTest to ProblemList.txt. [1] https://bugs.openjdk.java.net/browse/JDK-8248255

Re: RFR [15] 8248233: Avoid superfluous Class::isRecord invocations during deserialization

On 6/24/20 6:53 PM, Chris Hegarty wrote: On 24 Jun 2020, at 17:15, Claes Redestad > wrote: ... It seems ObjectInputStream#isRecord(Class) is now unused. No need for a new webrev if you choose to remove it. Good catch, now removed. On 24 Jun 2020, at

Re: [15] RFR JDK-8247785: Small clarification to the javadoc about builtin class loaders

On 25/06/2020 5:21 am, Mandy Chung wrote: Hi Roger, David, Thanks for the help in improving this.  As a record, this webrev shows the version as David suggests: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8247785/webrev.00/ Looks good to me :) Thanks, David Mandy On 6/24/20 9:33

Re: RFR: JDK-8240148: Uncaught exceptions from ScheduledThreadPoolExecutor.execute aren't reported

Hi Jaikiran, On 24/06/2020 11:44 pm, Jaikiran Pai wrote: Could I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8240148? I missed the filing of this bug. :( The patch is available as a webrev at https://cr.openjdk.java.net/~jpai/webrev/8240148/1/

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Hi, We traded CPS style for reusing existing functional interfaces. Originally the signature (my first choice) was as you indicate. By chance it just so happens that the current signature is the same shape as that for the accumulating argument type of the three arg collect terminal operation:

Re: RFR: JDK-8240148: Uncaught exceptions from ScheduledThreadPoolExecutor.execute aren't reported

Thank you both Martin and David for your inputs. On 25/06/20 5:40 am, David Holmes wrote: > Hi Jaikiran, > > >> The patch is available as a webrev at >> https://cr.openjdk.java.net/~jpai/webrev/8240148/1/ >> >> The patch updates the ScheduledThreadPoolExecutor.execute(Runnable) to >> wrap the

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jun 24, 2020, at 7:01 AM, Magnus Ihse Bursie > wrote: > > On 2020-06-18 08:34, Kim Barrett wrote: >>> On Jun 15, 2020, at 7:41 AM, Kim Barrett wrote: >>> On Jun 14, 2020, at 12:45 AM, Philip Race wrote: Kim, Until it says in "the JDK" and not "in

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

Hi Patrick, - Mail original - > De: "Patrick Concannon" > À: "core-libs-dev" > Envoyé: Mercredi 24 Juin 2020 12:57:01 > Objet: RFR[8238286]: 'Add new flatMap stream operation that is more amenable > to pushing’ > Hi, Hi, > > Could someone please review myself and Julia's RFE and

RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

Hi Andrew/Yang, We couldn’t propose Vector API to target in time for JDK 15 and hoping to do so early in JDK 16 timeframe. The implementation reviews on other components have made good progress. We have so far ok to PPT from (runtime, shared compiler changes, x86 backend). Java API

Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

I like this new API point a lot; it allows flexible, local, temporary control inversion in the context of one stream transform. What’s the performance model? It seems like the SpinedBuffer implementation makes a worst-case assumption about the number of pending values, that there will be many