From vivek.r.deshpande at intel.com  Thu Aug  1 00:43:30 2019
From: vivek.r.deshpande at intel.com (Deshpande, Vivek R)
Date: Thu, 1 Aug 2019 00:43:30 +0000
Subject: The result of Math.log(3.0) is different on x86_64 and aarch64?
In-Reply-To: <12e94f29-c295-678b-98bc-55e02666ffc9@redhat.com>
References: <CAKzHFyUgiPdm-BVwMzQ7-mM0xfgpwpRwpOzMKx5i8i4jGOqR_w@mail.gmail.com>
 <CAKzHFyWKSS+VifP9MkbvjAKkMbWWoUKphwd+=aYA7tvFi7qT9g@mail.gmail.com>
 <CAMrVzXXv-FcfrGfAQ-aU2Kn6s3fb5h8jQQOC9RsEpRqgN=NZRA@mail.gmail.com>
 <DB7PR08MB311542FAAC85AA05BF492BD196DD0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <551d3025-1876-acbf-8633-9dada14f3176@redhat.com>
 <CA+kOe0_9OOKygv4Wizts-YRL46nhvarCyP4Dj5GwPVZQ8yWzOw@mail.gmail.com>
 <12e94f29-c295-678b-98bc-55e02666ffc9@redhat.com>
Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2AAB6BE17A@fmsmsx121.amr.corp.intel.com>

Hi Andrew

We have used the assembly code generated from the Intel Libm Math library as intrinsics and they follow the Spec as you have mentioned in your earlier email.
Let me know if need any more information.

Regards,
Vivek

-----Original Message-----
From: Andrew Dinn [mailto:adinn at redhat.com] 
Sent: Monday, July 29, 2019 7:44 AM
To: Martin Buchholz <martinrb at google.com>
Cc: Pengfei Li (Arm Technology China) <Pengfei.Li at arm.com>; bo zhaobo <bzhaojyathousandy at gmail.com>; Tianhua huang <huangtianhua223 at gmail.com>; Deshpande, Vivek R <vivek.r.deshpande at intel.com>; nd <nd at arm.com>; jdk-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net
Subject: Re: The result of Math.log(3.0) is different on x86_64 and aarch64?

On 29/07/2019 15:25, Martin Buchholz wrote:
> I was surprised to see the doc of Math.log make it explicit:
> 
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang
> /Math.html#log(double)
> 
> """The computed result must be within 1 ulp of the exact result. 
> Results must be semi-monotonic."""

Yes, indeed. I had to look up semi-monotonic even though I really ought to have known what it meant :-)

Anyway, there is no surprise really once you correlate the thoroughness of that documentation (and the rest ...) with the inestimably efficient purring of the engine that is Joe Darcy's brain. This is one area that really can be nailed down by spec and it is very nice to see that it has been.

regards,


Andrew Dinn
-----------


From adinn at redhat.com  Thu Aug  1 09:55:40 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 1 Aug 2019 10:55:40 +0100
Subject: The result of Math.log(3.0) is different on x86_64 and aarch64?
In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2AAB6BE17A@fmsmsx121.amr.corp.intel.com>
References: <CAKzHFyUgiPdm-BVwMzQ7-mM0xfgpwpRwpOzMKx5i8i4jGOqR_w@mail.gmail.com>
 <CAKzHFyWKSS+VifP9MkbvjAKkMbWWoUKphwd+=aYA7tvFi7qT9g@mail.gmail.com>
 <CAMrVzXXv-FcfrGfAQ-aU2Kn6s3fb5h8jQQOC9RsEpRqgN=NZRA@mail.gmail.com>
 <DB7PR08MB311542FAAC85AA05BF492BD196DD0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <551d3025-1876-acbf-8633-9dada14f3176@redhat.com>
 <CA+kOe0_9OOKygv4Wizts-YRL46nhvarCyP4Dj5GwPVZQ8yWzOw@mail.gmail.com>
 <12e94f29-c295-678b-98bc-55e02666ffc9@redhat.com>
 <53E8E64DB2403849AFD89B7D4DAC8B2AAB6BE17A@fmsmsx121.amr.corp.intel.com>
Message-ID: <b9ecac08-702e-373a-d4b6-21e74af84607@redhat.com>

Hi Vivek,

On 01/08/2019 01:43, Deshpande, Vivek R wrote:
> Hi Andrew
> 
> We have used the assembly code generated from the Intel Libm Math
> library as intrinsics and they follow the Spec as you have mentioned
> in your earlier email. Let me know if need any more information.

Thanks for explaining the provenance of this code. I am fine with that
explanation (and most of all with you maintaining it ;-).

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From dms at samersoff.net  Thu Aug  1 13:03:16 2019
From: dms at samersoff.net (Dmitry Samersoff)
Date: Thu, 1 Aug 2019 16:03:16 +0300
Subject: CFV: New JDK Reviewer: Dmitrij Pochepko
In-Reply-To: <69ec9493-a53f-fa6f-e5c0-0858f40dd234@redhat.com>
References: <117eeec5-d646-d92f-dca1-41e35433162b@oracle.com>
 <9d1deb56-d5b4-3a8f-5924-7dc939341a51@redhat.com>
 <da0ef8d7-0011-efcf-7285-cdffa5c1f1a6@samersoff.net>
 <69ec9493-a53f-fa6f-e5c0-0858f40dd234@redhat.com>
Message-ID: <bfc7cfc2-054c-a45c-2226-fef537cc70ea@samersoff.net>

Hello Andrew and Andrew,

Your position with this CFV is understood and I can only second my
proposal to sit down with both of you. I hope we'll work out a plan that
will allow us to make changes and implement new functionality, enhance
speed and maintainability of AArch64 port while keeping the quality bar
at least as high as it currently stands.

To make it crystal clear, we do not insist on Reviewer status of Dmitrij
for now.

-Dmitry\S


On 31.07.19 21:16, Andrew Haley wrote:
> On 7/30/19 2:44 PM, Dmitry Samersoff wrote:
>> Thank you for sharing your view, we appreciate your candid feedback.
>> Needless to say, that we greatly appreciate the value that you
>> constantly bring to OpenJDK.
>>
>> However, our perception of the situation is different. We believe that
>> you might have missed some facts, for example that, Dmitrij did his best
>> to address your concerns promptly and the 5 RFRs from Dmitrij are
>> waiting for review.
> 
> Yes, they are, because they are difficult to review, and the expected
> payoff makes that time hard to justify.
> 
> I have to be very clear about this: my first priority is to protect
> OpenJDK from breakage, and if I have any doubts -- even small ones --
> I have to block a change.
> 
>> I hope that all the issues can be resolved if we just speak to each
>> other. We would like to have an opportunity to clarify your remaining
>> concerns and work out a solution plan to address it.
>>
>> Therefore, as the first step to
>> "work together to reach a mutually-agreeable resolution" could we sync
>> with you, Andrew Haley and Dmitrij on CW32 by zoom call?
> 
> Certainly. I'm always happy to talk.
> 

From goetz.lindenmaier at sap.com  Mon Aug  5 08:00:01 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 5 Aug 2019 08:00:01 +0000
Subject: 8227717: Give more helpful NullPointerException messages and add flag
 -XX:ShowCodeDetailsInExceptionMessages
Message-ID: <AM6PR02MB53475C24FE84D289892CB4F6ECDA0@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi Joe, 

I have changed the naming of the flag. 

What else should I add to the CSR? What is still missing?

> Not that the CSR covers a particular snapshot of a change so if there 
> are specific interfaces being modified, just referring to a JEP is not 
> sufficient since the JEP can be changed independently of the CSR. 
> In particular, a JEP can be modified after a CSR is approved.
Shouldn't the CSR cover what is submitted to the code base? I.e., 
the final state?  
What should I add to the text to cover this?  Do you want to know more
about the message texts that will be generated? Should I explain
in more detail which exceptions will get a message added?  Should
I describe the changes to NullPointerException.java?

Best regards,
  Goetz.

From alex.buckley at oracle.com  Mon Aug  5 18:23:14 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 5 Aug 2019 11:23:14 -0700
Subject: Preview APIs for preview features -- JDK 14+
Message-ID: <b3e5bb1c-e90d-abd7-2da9-bf9880c65ec2@oracle.com>

Hi,

Preview language features such as text blocks (JEP 355) sometimes depend 
on associated APIs in `java.*` (e.g. String::stripIndent). If a 
developer enables preview features at compile time and explicitly calls 
APIs associated with the preview feature, then all is well; but if a 
developer _doesn't_ enable preview features and still calls those APIs, 
then Java compilers need to shout loudly about how the API could change 
or disappear in future, depending on the fate of the preview feature.

JEP 12 has traditionally forced compilers' hands by proposing that 
associated APIs are marked as terminally deprecated at birth 
(https://openjdk.java.net/jeps/12#Relationship-to-Java-SE-APIs). 
However, this results in compile-time warnings that express no 
relationship to preview features, and worse, can be permanently 
suppressed in source code.

Joe Darcy has proposed that associated APIs are annotated explicitly 
(e.g. @java.lang.annotation.PreviewFeature) so that their use can be 
detected at compile time. Consequently:

- If code is compiled with preview features enabled (e.g. 
--enable-preview in javac; other compilers may differ), then the APIs 
can be used (i.e. invoked/overridden/subclassed) with only the 
compiler's usual warnings about use of preview features.

- If code is compiled _without_ preview features enabled, then use of 
the APIs would cause a compile-time error. The JLS would spell out this 
treatment for use of @PreviewFeature APIs (the rules are substantially 
the same as for use of @Deprecated APIs).

To be clear: this proposal means there will be APIs in the Java SE 
Platform that can only be used when preview features are enabled -- just 
as there are already language features in the Platform that can only be 
used when preview features are enabled.

JEP 12 already exhorts the owner of a preview feature to write javadoc 
for associated APIs that clearly describes how their presence and 
evolution is tied to the fate of the preview feature. That's still true; 
in fact, with a little support for @PreviewFeature in the standard 
doclet, the javadoc can highlight the association for casual readers of 
the API -- this will tend to dial down attempts to use the API standalone.

Alex

P.S. Starting in JLS 13, preview features will be enumerated in section 
1.1 "Organization of this Specification" and their actual specifications 
will be co-located with the JLS. This will underpin the new JLS section 
about @PreviewFeature when it refer to preview features, their 
enablement at compile time, and their associated APIs.

From alex.buckley at oracle.com  Mon Aug  5 19:11:31 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 5 Aug 2019 12:11:31 -0700
Subject: Preview APIs for preview features -- JDK 14+
In-Reply-To: <56294c0c-3817-a05f-83f0-b1ff2294cef4@oracle.com>
References: <b3e5bb1c-e90d-abd7-2da9-bf9880c65ec2@oracle.com>
 <56294c0c-3817-a05f-83f0-b1ff2294cef4@oracle.com>
Message-ID: <4c69f8cd-3a6a-aedc-cf32-98034b5d8026@oracle.com>

On 8/5/2019 12:00 PM, Alan Bateman wrote:
> On 05/08/2019 11:23, Alex Buckley wrote:
>> To be clear: this proposal means there will be APIs in the Java SE 
>> Platform that can only be used when preview features are enabled -- 
>> just as there are already language features in the Platform that can 
>> only be used when preview features are enabled.
>>
> Just to double check my understanding: There is no run-time enforcement 
> and also no run-time filtering of methods for preview features when not 
> running with --enable-preview. The methods for preview features will be 
> discoverable (and usable) by reflection but that an untypical usage that 
> we shouldn't be concerned about.

Correct. This proposal is about strengthening the developer's awareness 
of incautious usage of associated APIs, by strengthening the 
compile-time story from a removal warning to an error. At run time, we 
do NOT propose to reject a class file referencing String::stripIndent 
when preview features are disabled; the checking would be heavyweight 
and could never account for reflective use. Again, the goal here is 
developer awareness when they read javadoc and write code.

Alex

From aph at redhat.com  Wed Aug  7 08:49:24 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 7 Aug 2019 09:49:24 +0100
Subject: Please implement client switch in 64-bit server JDK 14 builds
In-Reply-To: <36722c0b-1383-f2ab-315e-060aad41a5c2@gmail.com>
References: <36722c0b-1383-f2ab-315e-060aad41a5c2@gmail.com>
Message-ID: <d83c6975-006c-07d5-43bf-d4ae1be715e1@redhat.com>

On 7/19/19 3:46 AM, Ty Young wrote:

> A "client" JVM variant is geared towards graphical end-user
> applications. According to a URL link found in the man entry for
> java[1] this supposedly results in faster startups. While this *may*
> be true, a much larger and more important benefit is a massive
> committed memory reduction in the range of about 25% to 50% when
> running a JavaFX application. At minimum with similar heap sizes,
> that is a 75 MB memory savings at 300MB (a somewhat typical peak
> usage with JavaFX applications) with a typical server JVM. That's
> huge.

The problem is to some extent that Java sizes itself based on the
machine that it is running on. If it sees plenty of memory and threads
it uses them, in an attempt to improve performance.

I think you should be able to achieve some similar results to -client
by trying -XX:TieredStopAtLevel=1 and sizing the heap appropriately
for your application. There is also a bunch of GC settings which cause
it to be very frugal with memory. These together will, I suspect, be
more effective than the old "-client" option.

In general, I think we do need a "-small" option for the JVM. The GC
defaults are inappropriate for a lot of applications. However, I'm not
exactly sure what "-small" should be.

One set of options we use is:

USE_JVM_ARGS="-XX:+UseParallelGC -XX:MinHeapFreeRatio=5 \
   -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4 \
   -XX:AdaptiveSizePolicyWeight=90 -Xms20M -Xmx500M \
   -XX:MaxMetaspaceSize=100m -XX:+UnlockExperimentalVMOptions \
   -XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true"

Please let us know if this helps in your case.

-- 
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

From gunnar at hibernate.org  Wed Aug  7 11:00:50 2019
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 7 Aug 2019 13:00:50 +0200
Subject: Preview APIs for preview features -- JDK 14+
Message-ID: <CADGJaX-5sQfMt6RAnz=m39gt6KfyRNDcxAVUL-YCWBqtZkULoQ@mail.gmail.com>

Hi all,

> Joe Darcy has proposed that associated APIs are annotated explicitly
> (e.g. @java.lang.annotation.PreviewFeature) so that their use can be
> detected at compile time.

I think that's a very useful addition.

IIUC, this is only geared towards usage within the JDK APIs themselves;
maybe it could be considered to widen the scope of the proposal and enable
usage of this functionality by 3rd party APIs? Specifically, I'm thinking
of supporting similar, already existing annotations, e.g. @Beta in Guava or
or @Incubating in Hibernate. So for that it'd help if:

* it were configurable which annotation(s) are used as the preview API
marker(s)
* it were possible to distinguish between opting into using preview
*language features* and preview *APIs*. Oftentimes, one might be more
willing to accept the potential risks associated to using the latter as
than to using the former.

Currently, specific tooling is needed to check for usage of APIs marked
with such annotations (e.g. there's an ErrorProne plug-in for @Beta), but
unlike a compiler option which *prevents* usage of preview APIs by default,
this tooling must be explicitly set up as part of the compilation,
*allowing* their usage by default. Hence I think it'd be great to have
support for this by the compiler itself.

Any thoughts?

Thanks,

--Gunnar

From Markus.Duft at ssi-schaefer.com  Wed Aug  7 11:34:01 2019
From: Markus.Duft at ssi-schaefer.com (Duft Markus)
Date: Wed, 7 Aug 2019 11:34:01 +0000
Subject: ProcessHandle.Info startInstant() drifts with system time on Linux
Message-ID: <1565177641838.63922@ssi-schaefer.com>

Hey,


Just checking in to see whether this is a bug, or by design (and where I should report this if it /is/ a bug :)).


We discovered, that ProcessHandle.Info.startInstant() seems to be non-constant for a given long running process when restarting the Java VM. We have a deployment tool (https://bdeploy.io) which monitors processes and tries to recover running process information when starting up. The general process would be:


1) Start BDeploy

2) BDeploy starts a child process, records its PID and startInstant to be able to find it again later

3) BDeploy is stopped (for whatever reason) and the child process keeps running (we do make sure that this is the case :)).

4) BDeploy is started again, tries to find running processes from its previous life to resume monitoring.

5) BDeploy reads PID and startInstant from a file, finds a ProcessHandle using the PID and compares the startInstant. This is to avoid finding wrong processes when PIDs wrap.


Now we have the problem that this does not work always. Analysis have led us to the point where we identifier NTPD or manual clock setting as the root cause. It seems that a system clock change will change the absolute timestamp of a process start. I had a look at the JDK sources and found that this is actually true :) Here is what I found out and documented on our own bugtracker:


The relevant java native method on l??inux does this:

     /*
     * Try to stat and then open /proc/%d/stat
     */
    snprintf(fn, sizeof fn, "/proc/%d/stat", pid);

    fp = fopen(fn, "r");
    ...

    // Scan the needed fields from status, retaining only ppid(4),
    // utime (14), stime(15), starttime(22)
    if (4 != sscanf(s, " %*c %d %*d %*d %*d %*d %*d %*u %*u %*u %*u %lu %lu %*d %*d %*d %*d %*d %*d %llu",
            &parentPid, &utime, &stime, &start)) {
        return 0;              // not all values parsed; return error
    }

    *totalTime = (utime + stime) * (jlong)(1000000000 / clock_ticks_per_second);

    *startTime = bootTime_ms + ((start * 1000) / clock_ticks_per_second);
    ...


So the process start time is calculated rela?tive to the system kernel boot time. The boot time is calculated ONCE when starting the java VM like this:

    fp = fopen("/proc/stat", "r");
    ...

    while (getline(&line, &len, fp) != -1) {
        if (sscanf(line, "btime %llu", &bootTime) == 1) {
            break;
        }
    }
    ...

    return bootTime * 1000;


However, the /proc/stat btime field does not seem to be constant. When I manually set the clock 2 minutes ahead, the btime field follows along, and is now two minutes later than before. Thus any system time correction (manual, ntpd, ...) will change the system boot time, which will make the timestamp different, but only after restarting the JVM.

This is IMHO a bug in the JVM. The btime is a relative timestamp (uptime in nanoseconds if i'm correct). The absolute representation of this timestamp is calculated on the fly when reading /proc/stat from the current date/time (assuming that the current date/time is correct). This is not a problem (and correct!) for a human reader. The field should just never be taken to calculate another absolute timestamp, which java does...

So we pseudo-have:

btime = current-clock-timestamp - kernel-uptime;

proc-start = btime + process-uptime;

All three variables are mutable and may (and will) change. If (and only if) kernel-uptime and process-uptime are updated correctly, calculating the absolute start-time will yield a reproducible result only as long as the system clock does not change.


I'm pretty sure this qualifies as bug, but not whether it's a java a kernel (or whatever) bug... Any advice, also how to get around this, would be greatly appreciated. I would really like to avoid hard-coding allowed drift ranges or something like this, especially as we'll be running into timezone, summer time, etc. issues AFAICT...


Cheers,

Thanks for ANY help,

Markus

SSI Sch?fer IT Solutions GmbH | Friesachstrasse 15 | 8114 Friesach | Austria
Registered Office: Friesach | Commercial Register: 49324 K | VAT no. ATU28654300
Commercial Court: Landesgericht f?r Zivilrechtssachen Graz
Unsere Hinweise zum Umgang mit personenbezogenen Daten finden Sie hier<https://www.ssi-schaefer.com/de-at/datenschutz-49548>.
You can find our information on the handling of personal data here<https://www.ssi-schaefer.com/en-at/privacy-13258>.

From Alan.Bateman at oracle.com  Wed Aug  7 12:04:16 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 7 Aug 2019 13:04:16 +0100
Subject: Preview APIs for preview features -- JDK 14+
In-Reply-To: <4c69f8cd-3a6a-aedc-cf32-98034b5d8026@oracle.com>
References: <b3e5bb1c-e90d-abd7-2da9-bf9880c65ec2@oracle.com>
 <56294c0c-3817-a05f-83f0-b1ff2294cef4@oracle.com>
 <4c69f8cd-3a6a-aedc-cf32-98034b5d8026@oracle.com>
Message-ID: <b388bdd5-637f-d16f-0501-57a293eb52c5@oracle.com>

On 05/08/2019 12:11, Alex Buckley wrote:
>
> Correct. This proposal is about strengthening the developer's 
> awareness of incautious usage of associated APIs, by strengthening the 
> compile-time story from a removal warning to an error. At run time, we 
> do NOT propose to reject a class file referencing String::stripIndent 
> when preview features are disabled; the checking would be heavyweight 
> and could never account for reflective use. Again, the goal here is 
> developer awareness when they read javadoc and write code.
This make sense. For developers working on the JDK itself there will 
likely be cases in the future where methods associated with a preview 
feature need to be used, maybe an existing method expands its behavior 
when preview features are enabled. We can deal with those using 
reflection or method handles as needed.

One thing that isn't clear from the write-up is whether the APIs will 
have both @Deprecated(forRemoval=true) and @PreviewFeature. I assume 
not, esp. if the standard doclet will highlight the method as it does 
with deprecated methods today. IDEs typically strike-through usages of 
deprecated methods and I assume they will need to do something similar 
for methods associated with preview features.

-Alan

From Markus.Duft at ssi-schaefer.com  Wed Aug  7 12:48:50 2019
From: Markus.Duft at ssi-schaefer.com (Duft Markus)
Date: Wed, 7 Aug 2019 12:48:50 +0000
Subject: ProcessHandle.Info startInstant() drifts with system time on Linux
In-Reply-To: <1565177641838.63922@ssi-schaefer.com>
References: <1565177641838.63922@ssi-schaefer.com>
Message-ID: <1565182130704.26675@ssi-schaefer.com>

Hey,

I have a test program to demonstrate the issue as well now:

mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $ date
Wed Aug  7 14:44:30 CEST 2019
mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $ $JAVA_HOME/bin/java TEST start
Started. PID=17210, start=1565181874360
mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $ $JAVA_HOME/bin/java TEST recover
Found handle. PID=17210, start=1565181874360
mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $ date
Wed Aug  7 14:44:38 CEST 2019
# changed system time to 5 minutes in the future here!
mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $ date
Wed Aug  7 14:49:03 CEST 2019
mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $ $JAVA_HOME/bin/java TEST recover
Found handle. PID=17210, start=1565182127360
Time drift detected! Start times: recorded=1565181874360, actual=1565182127360
mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $

The program is attached... Its as simple as possible, no error handling whatsoever, don't bash me ;)

I run and tested with:

openjdk 10.0.2-adoptopenjdk 2018-07-17
OpenJDK Runtime Environment (build 10.0.2-adoptopenjdk+13)
OpenJDK 64-Bit Server VM (build 10.0.2-adoptopenjdk+13, mixed mode)

(yep, we're still on 10, 11 is effort and we need third parties to support it first ;)).

Cheers,
Markus

________________________________________
From: jdk-dev <jdk-dev-bounces at openjdk.java.net> on behalf of Duft Markus
Sent: Wednesday, August 7, 2019 13:34
To: jdk-dev at openjdk.java.net
Subject: ProcessHandle.Info startInstant() drifts with system time on Linux

Hey,


Just checking in to see whether this is a bug, or by design (and where I should report this if it /is/ a bug :)).


We discovered, that ProcessHandle.Info.startInstant() seems to be non-constant for a given long running process when restarting the Java VM. We have a deployment tool (https://bdeploy.io) which monitors processes and tries to recover running process information when starting up. The general process would be:


1) Start BDeploy

2) BDeploy starts a child process, records its PID and startInstant to be able to find it again later

3) BDeploy is stopped (for whatever reason) and the child process keeps running (we do make sure that this is the case :)).

4) BDeploy is started again, tries to find running processes from its previous life to resume monitoring.

5) BDeploy reads PID and startInstant from a file, finds a ProcessHandle using the PID and compares the startInstant. This is to avoid finding wrong processes when PIDs wrap.


Now we have the problem that this does not work always. Analysis have led us to the point where we identifier NTPD or manual clock setting as the root cause. It seems that a system clock change will change the absolute timestamp of a process start. I had a look at the JDK sources and found that this is actually true :) Here is what I found out and documented on our own bugtracker:


The relevant java native method on l??inux does this:

     /*
     * Try to stat and then open /proc/%d/stat
     */
    snprintf(fn, sizeof fn, "/proc/%d/stat", pid);

    fp = fopen(fn, "r");
    ...

    // Scan the needed fields from status, retaining only ppid(4),
    // utime (14), stime(15), starttime(22)
    if (4 != sscanf(s, " %*c %d %*d %*d %*d %*d %*d %*u %*u %*u %*u %lu %lu %*d %*d %*d %*d %*d %*d %llu",
            &parentPid, &utime, &stime, &start)) {
        return 0;              // not all values parsed; return error
    }

    *totalTime = (utime + stime) * (jlong)(1000000000 / clock_ticks_per_second);

    *startTime = bootTime_ms + ((start * 1000) / clock_ticks_per_second);
    ...


So the process start time is calculated rela?tive to the system kernel boot time. The boot time is calculated ONCE when starting the java VM like this:

    fp = fopen("/proc/stat", "r");
    ...

    while (getline(&line, &len, fp) != -1) {
        if (sscanf(line, "btime %llu", &bootTime) == 1) {
            break;
        }
    }
    ...

    return bootTime * 1000;


However, the /proc/stat btime field does not seem to be constant. When I manually set the clock 2 minutes ahead, the btime field follows along, and is now two minutes later than before. Thus any system time correction (manual, ntpd, ...) will change the system boot time, which will make the timestamp different, but only after restarting the JVM.

This is IMHO a bug in the JVM. The btime is a relative timestamp (uptime in nanoseconds if i'm correct). The absolute representation of this timestamp is calculated on the fly when reading /proc/stat from the current date/time (assuming that the current date/time is correct). This is not a problem (and correct!) for a human reader. The field should just never be taken to calculate another absolute timestamp, which java does...

So we pseudo-have:

btime = current-clock-timestamp - kernel-uptime;

proc-start = btime + process-uptime;

All three variables are mutable and may (and will) change. If (and only if) kernel-uptime and process-uptime are updated correctly, calculating the absolute start-time will yield a reproducible result only as long as the system clock does not change.


I'm pretty sure this qualifies as bug, but not whether it's a java a kernel (or whatever) bug... Any advice, also how to get around this, would be greatly appreciated. I would really like to avoid hard-coding allowed drift ranges or something like this, especially as we'll be running into timezone, summer time, etc. issues AFAICT...


Cheers,

Thanks for ANY help,

Markus

SSI Sch?fer IT Solutions GmbH | Friesachstrasse 15 | 8114 Friesach | Austria
Registered Office: Friesach | Commercial Register: 49324 K | VAT no. ATU28654300
Commercial Court: Landesgericht f?r Zivilrechtssachen Graz
Unsere Hinweise zum Umgang mit personenbezogenen Daten finden Sie hier<https://www.ssi-schaefer.com/de-at/datenschutz-49548>.
You can find our information on the handling of personal data here<https://www.ssi-schaefer.com/en-at/privacy-13258>.

SSI Sch?fer IT Solutions GmbH | Friesachstrasse 15 | 8114 Friesach | Austria
Registered Office: Friesach | Commercial Register: 49324 K | VAT no. ATU28654300
Commercial Court: Landesgericht f?r Zivilrechtssachen Graz
Unsere Hinweise zum Umgang mit personenbezogenen Daten finden Sie hier<https://www.ssi-schaefer.com/de-at/datenschutz-49548>.
You can find our information on the handling of personal data here<https://www.ssi-schaefer.com/en-at/privacy-13258>.

From Markus.Duft at ssi-schaefer.com  Wed Aug  7 13:28:26 2019
From: Markus.Duft at ssi-schaefer.com (Duft Markus)
Date: Wed, 7 Aug 2019 13:28:26 +0000
Subject: ProcessHandle.Info startInstant() drifts with system time on Linux
In-Reply-To: <1565182130704.26675@ssi-schaefer.com>
References: <1565177641838.63922@ssi-schaefer.com>,
 <1565182130704.26675@ssi-schaefer.com>
Message-ID: <1565184506672.36851@ssi-schaefer.com>

Hey,

Since attachments don't seem to work and our company blocks all file sharing (yikes), here the source inline, sorry for the noise...

----------- TEST.java ---------------
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;

public class TEST {

    private static final String FN = "info.pid";
    private static final String[] CMD = { "/usr/bin/sleep", "10m" };

    public static void main(String[] args) throws Exception {
        if (args[0].equals("start")) {
            doStart();
        } else if (args[0].equals("recover")) {
            doRecover();
        }
    }

    private static void doRecover() throws Exception {
        Path f = Paths.get(FN);
        if (!Files.exists(f)) {
            System.err.println(f + " does not exist, run with 'start' first");
        }

        String[] fields = new String(Files.readAllBytes(f), StandardCharsets.UTF_8).split(",");
        long pid = Long.valueOf(fields[0]);
        long recStartMillis = Long.valueOf(fields[1]);

        ProcessHandle ph = ProcessHandle.of(pid).orElseThrow();
        long phStartMillis = ph.info().startInstant().orElseThrow().toEpochMilli();
        System.out.println("Found handle. PID=" + ph.pid() + ", start=" + phStartMillis);

        if (recStartMillis != phStartMillis) {
            System.err.println("Time drift detected! Start times: recorded=" + recStartMillis + ", actual=" + phStartMillis);
        }
    }

    private static void doStart() throws Exception {
        Path f = Paths.get(FN);
        if (Files.exists(f)) {
            Files.delete(f);
        }

        ProcessBuilder builder = new ProcessBuilder(CMD);
        ProcessHandle handle = builder.start().toHandle();

        long startMillis = handle.info().startInstant().orElseThrow().toEpochMilli();
        System.out.println("Started. PID=" + handle.pid() + ", start=" + startMillis);

        // write to file, remember
        Files.write(f,
                String.join(",", String.valueOf(handle.pid()), String.valueOf(startMillis)).getBytes(StandardCharsets.UTF_8));
    }

}
----------------------------------------

Meanwhile I've been digging deeper and ended up in the kernel sources. Ultimately the function getboottime64 from ./kernel/time/timekeeping.c is used to determine the boot time. It's documentation tells a lot :)

/**
 * getboottime64 - Return the real time of system boot.
 * @ts:     pointer to the timespec64 to be set
 *
 * Returns the wall-time of boot in a timespec64.
 *
 * This is based on the wall_to_monotonic offset and the total suspend
 * time. Calls to settimeofday will affect the value returned (which
 * basically means that however wrong your real time clock is at boot time,
 * you get the right time here).
 */
void getboottime64(struct timespec64 *ts)
{
    struct timekeeper *tk = &tk_core.timekeeper;
    ktime_t t = ktime_sub(tk->offs_real, tk->offs_boot);

    *ts = ktime_to_timespec64(t);
}

Cheers,
Markus
________________________________________
From: jdk-dev <jdk-dev-bounces at openjdk.java.net> on behalf of Duft Markus
Sent: Wednesday, August 7, 2019 14:48
To: jdk-dev at openjdk.java.net
Subject: Re: ProcessHandle.Info startInstant() drifts with system time on Linux

Hey,

I have a test program to demonstrate the issue as well now:

mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $ date
Wed Aug  7 14:44:30 CEST 2019
mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $ $JAVA_HOME/bin/java TEST start
Started. PID=17210, start=1565181874360
mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $ $JAVA_HOME/bin/java TEST recover
Found handle. PID=17210, start=1565181874360
mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $ date
Wed Aug  7 14:44:38 CEST 2019
# changed system time to 5 minutes in the future here!
mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $ date
Wed Aug  7 14:49:03 CEST 2019
mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $ $JAVA_HOME/bin/java TEST recover
Found handle. PID=17210, start=1565182127360
Time drift detected! Start times: recorded=1565181874360, actual=1565182127360
mduft at fril0041 /ssd/workspaces/deployment/git/deployment/minion/bin/main $

The program is attached... Its as simple as possible, no error handling whatsoever, don't bash me ;)

I run and tested with:

openjdk 10.0.2-adoptopenjdk 2018-07-17
OpenJDK Runtime Environment (build 10.0.2-adoptopenjdk+13)
OpenJDK 64-Bit Server VM (build 10.0.2-adoptopenjdk+13, mixed mode)

(yep, we're still on 10, 11 is effort and we need third parties to support it first ;)).

Cheers,
Markus

________________________________________
From: jdk-dev <jdk-dev-bounces at openjdk.java.net> on behalf of Duft Markus
Sent: Wednesday, August 7, 2019 13:34
To: jdk-dev at openjdk.java.net
Subject: ProcessHandle.Info startInstant() drifts with system time on Linux

Hey,


Just checking in to see whether this is a bug, or by design (and where I should report this if it /is/ a bug :)).


We discovered, that ProcessHandle.Info.startInstant() seems to be non-constant for a given long running process when restarting the Java VM. We have a deployment tool (https://bdeploy.io) which monitors processes and tries to recover running process information when starting up. The general process would be:


1) Start BDeploy

2) BDeploy starts a child process, records its PID and startInstant to be able to find it again later

3) BDeploy is stopped (for whatever reason) and the child process keeps running (we do make sure that this is the case :)).

4) BDeploy is started again, tries to find running processes from its previous life to resume monitoring.

5) BDeploy reads PID and startInstant from a file, finds a ProcessHandle using the PID and compares the startInstant. This is to avoid finding wrong processes when PIDs wrap.


Now we have the problem that this does not work always. Analysis have led us to the point where we identifier NTPD or manual clock setting as the root cause. It seems that a system clock change will change the absolute timestamp of a process start. I had a look at the JDK sources and found that this is actually true :) Here is what I found out and documented on our own bugtracker:


The relevant java native method on l??inux does this:

     /*
     * Try to stat and then open /proc/%d/stat
     */
    snprintf(fn, sizeof fn, "/proc/%d/stat", pid);

    fp = fopen(fn, "r");
    ...

    // Scan the needed fields from status, retaining only ppid(4),
    // utime (14), stime(15), starttime(22)
    if (4 != sscanf(s, " %*c %d %*d %*d %*d %*d %*d %*u %*u %*u %*u %lu %lu %*d %*d %*d %*d %*d %*d %llu",
            &parentPid, &utime, &stime, &start)) {
        return 0;              // not all values parsed; return error
    }

    *totalTime = (utime + stime) * (jlong)(1000000000 / clock_ticks_per_second);

    *startTime = bootTime_ms + ((start * 1000) / clock_ticks_per_second);
    ...


So the process start time is calculated rela?tive to the system kernel boot time. The boot time is calculated ONCE when starting the java VM like this:

    fp = fopen("/proc/stat", "r");
    ...

    while (getline(&line, &len, fp) != -1) {
        if (sscanf(line, "btime %llu", &bootTime) == 1) {
            break;
        }
    }
    ...

    return bootTime * 1000;


However, the /proc/stat btime field does not seem to be constant. When I manually set the clock 2 minutes ahead, the btime field follows along, and is now two minutes later than before. Thus any system time correction (manual, ntpd, ...) will change the system boot time, which will make the timestamp different, but only after restarting the JVM.

This is IMHO a bug in the JVM. The btime is a relative timestamp (uptime in nanoseconds if i'm correct). The absolute representation of this timestamp is calculated on the fly when reading /proc/stat from the current date/time (assuming that the current date/time is correct). This is not a problem (and correct!) for a human reader. The field should just never be taken to calculate another absolute timestamp, which java does...

So we pseudo-have:

btime = current-clock-timestamp - kernel-uptime;

proc-start = btime + process-uptime;

All three variables are mutable and may (and will) change. If (and only if) kernel-uptime and process-uptime are updated correctly, calculating the absolute start-time will yield a reproducible result only as long as the system clock does not change.


I'm pretty sure this qualifies as bug, but not whether it's a java a kernel (or whatever) bug... Any advice, also how to get around this, would be greatly appreciated. I would really like to avoid hard-coding allowed drift ranges or something like this, especially as we'll be running into timezone, summer time, etc. issues AFAICT...


Cheers,

Thanks for ANY help,

Markus

SSI Sch?fer IT Solutions GmbH | Friesachstrasse 15 | 8114 Friesach | Austria
Registered Office: Friesach | Commercial Register: 49324 K | VAT no. ATU28654300
Commercial Court: Landesgericht f?r Zivilrechtssachen Graz
Unsere Hinweise zum Umgang mit personenbezogenen Daten finden Sie hier<https://www.ssi-schaefer.com/de-at/datenschutz-49548>.
You can find our information on the handling of personal data here<https://www.ssi-schaefer.com/en-at/privacy-13258>.

SSI Sch?fer IT Solutions GmbH | Friesachstrasse 15 | 8114 Friesach | Austria
Registered Office: Friesach | Commercial Register: 49324 K | VAT no. ATU28654300
Commercial Court: Landesgericht f?r Zivilrechtssachen Graz
Unsere Hinweise zum Umgang mit personenbezogenen Daten finden Sie hier<https://www.ssi-schaefer.com/de-at/datenschutz-49548>.
You can find our information on the handling of personal data here<https://www.ssi-schaefer.com/en-at/privacy-13258>.

SSI Sch?fer IT Solutions GmbH | Friesachstrasse 15 | 8114 Friesach | Austria
Registered Office: Friesach | Commercial Register: 49324 K | VAT no. ATU28654300
Commercial Court: Landesgericht f?r Zivilrechtssachen Graz
Unsere Hinweise zum Umgang mit personenbezogenen Daten finden Sie hier<https://www.ssi-schaefer.com/de-at/datenschutz-49548>.
You can find our information on the handling of personal data here<https://www.ssi-schaefer.com/en-at/privacy-13258>.

From alex.buckley at oracle.com  Wed Aug  7 15:03:34 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 7 Aug 2019 08:03:34 -0700
Subject: Preview APIs for preview features -- JDK 14+
In-Reply-To: <CADGJaX-5sQfMt6RAnz=m39gt6KfyRNDcxAVUL-YCWBqtZkULoQ@mail.gmail.com>
References: <CADGJaX-5sQfMt6RAnz=m39gt6KfyRNDcxAVUL-YCWBqtZkULoQ@mail.gmail.com>
Message-ID: <7b3c4e7a-f2bc-7e18-f821-152f17be4c4d@oracle.com>

On 8/7/2019 4:00 AM, Gunnar Morling wrote:
>> Joe Darcy has proposed that associated APIs are annotated explicitly
>> (e.g. @java.lang.annotation.PreviewFeature) so that their use can be
>> detected at compile time.
> 
> I think that's a very useful addition.
> 
> IIUC, this is only geared towards usage within the JDK APIs themselves;
> maybe it could be considered to widen the scope of the proposal and enable
> usage of this functionality by 3rd party APIs? Specifically, I'm thinking
> of supporting similar, already existing annotations, e.g. @Beta in Guava or
> or @Incubating in Hibernate. 

There's a misconception in your model of "preview APIs", regrettably 
caused my use of the term as shorthand in the subject line. Let's be 
clear what we're discussing: an API defined by the Java SE Platform that 
is intimately connected with a preview language/VM feature. (JEP 12 
refers to this as an "essential" API because the JLS cannot avoid 
referring to it in normative text; see the JEP for examples.) If the 
preview language/VM feature changes or disappears, then the API will 
most likely change or disappear too. We are NOT looking to have APIs in 
the Java SE Platform that are "standalone" (independent of preview 
features) yet impermanent and in search of developer feedback. We have 
already settled on incubating APIs (JEP 11) as the mechanism for 
"standalone" impermanent APIs. Incubating APIs are deliberately kept out 
of the Java SE Platform (recall their `jdk.incubator` module and package 
prefix) to ensure developers realize that their use is risky.

Alex

From alex.buckley at oracle.com  Wed Aug  7 15:07:02 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 7 Aug 2019 08:07:02 -0700
Subject: Preview APIs for preview features -- JDK 14+
In-Reply-To: <b388bdd5-637f-d16f-0501-57a293eb52c5@oracle.com>
References: <b3e5bb1c-e90d-abd7-2da9-bf9880c65ec2@oracle.com>
 <56294c0c-3817-a05f-83f0-b1ff2294cef4@oracle.com>
 <4c69f8cd-3a6a-aedc-cf32-98034b5d8026@oracle.com>
 <b388bdd5-637f-d16f-0501-57a293eb52c5@oracle.com>
Message-ID: <d9a2dafd-e77a-e98c-d160-9cd3cb281d1d@oracle.com>

On 8/7/2019 5:04 AM, Alan Bateman wrote:
> One thing that isn't clear from the write-up is whether the APIs will 
> have both @Deprecated(forRemoval=true) and @PreviewFeature.

JEP 12 will be changed to propose @PreviewFeature only. The use of 
terminal deprecation will just dissolve into history, an aspect of Java 
SE 13 only.

Alex

From Roger.Riggs at oracle.com  Wed Aug  7 17:42:20 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 7 Aug 2019 13:42:20 -0400
Subject: ProcessHandle.Info startInstant() drifts with system time on Linux
In-Reply-To: <1565177641838.63922@ssi-schaefer.com>
References: <1565177641838.63922@ssi-schaefer.com>
Message-ID: <3190f880-7a18-e931-cf36-864ed9a10586@oracle.com>

Hi Markus,

core-libs-dev at openjdk.java.net is the more appropriate list for this 
question.

The ProcessHandle info is based directly on the OS information about a 
process, there is no separate information stored or kept.
If Linux had a stable way to represent the start time it would be 
reflected in the ProcessHandle info.
Changing the clock on any running system is fraught.? So many time 
related actions depend on linear and/or monotonic progression of time.

Re-reading the boot time would be a performance hit and be subject to a 
race condition with setting time.
The process handle also uses the start time to validate a ProcessHandle; 
since the cached boot time does not change the value is stable for that 
check.

A workaround for your application might be to save the relative start 
time by reading the boot time directly from /proc or the relative start 
time from /proc.

Roger

On 8/7/19 7:34 AM, Duft Markus wrote:
> Hey,
>
>
> Just checking in to see whether this is a bug, or by design (and where I should report this if it /is/ a bug :)).
>
>
> We discovered, that ProcessHandle.Info.startInstant() seems to be non-constant for a given long running process when restarting the Java VM. We have a deployment tool (https://bdeploy.io) which monitors processes and tries to recover running process information when starting up. The general process would be:
>
>
> 1) Start BDeploy
>
> 2) BDeploy starts a child process, records its PID and startInstant to be able to find it again later
>
> 3) BDeploy is stopped (for whatever reason) and the child process keeps running (we do make sure that this is the case :)).
>
> 4) BDeploy is started again, tries to find running processes from its previous life to resume monitoring.
>
> 5) BDeploy reads PID and startInstant from a file, finds a ProcessHandle using the PID and compares the startInstant. This is to avoid finding wrong processes when PIDs wrap.
>
>
> Now we have the problem that this does not work always. Analysis have led us to the point where we identifier NTPD or manual clock setting as the root cause. It seems that a system clock change will change the absolute timestamp of a process start. I had a look at the JDK sources and found that this is actually true :) Here is what I found out and documented on our own bugtracker:
>
>
> The relevant java native method on l??inux does this:
>
>       /*
>       * Try to stat and then open /proc/%d/stat
>       */
>      snprintf(fn, sizeof fn, "/proc/%d/stat", pid);
>
>      fp = fopen(fn, "r");
>      ...
>
>      // Scan the needed fields from status, retaining only ppid(4),
>      // utime (14), stime(15), starttime(22)
>      if (4 != sscanf(s, " %*c %d %*d %*d %*d %*d %*d %*u %*u %*u %*u %lu %lu %*d %*d %*d %*d %*d %*d %llu",
>              &parentPid, &utime, &stime, &start)) {
>          return 0;              // not all values parsed; return error
>      }
>
>      *totalTime = (utime + stime) * (jlong)(1000000000 / clock_ticks_per_second);
>
>      *startTime = bootTime_ms + ((start * 1000) / clock_ticks_per_second);
>      ...
>
>
> So the process start time is calculated rela?tive to the system kernel boot time. The boot time is calculated ONCE when starting the java VM like this:
>
>      fp = fopen("/proc/stat", "r");
>      ...
>
>      while (getline(&line, &len, fp) != -1) {
>          if (sscanf(line, "btime %llu", &bootTime) == 1) {
>              break;
>          }
>      }
>      ...
>
>      return bootTime * 1000;
>
>
> However, the /proc/stat btime field does not seem to be constant. When I manually set the clock 2 minutes ahead, the btime field follows along, and is now two minutes later than before. Thus any system time correction (manual, ntpd, ...) will change the system boot time, which will make the timestamp different, but only after restarting the JVM.
>
> This is IMHO a bug in the JVM. The btime is a relative timestamp (uptime in nanoseconds if i'm correct). The absolute representation of this timestamp is calculated on the fly when reading /proc/stat from the current date/time (assuming that the current date/time is correct). This is not a problem (and correct!) for a human reader. The field should just never be taken to calculate another absolute timestamp, which java does...
>
> So we pseudo-have:
> bootTime_ms
> btime = current-clock-timestamp - kernel-uptime;
>
> proc-start = btime + process-uptime;
>
> All three variables are mutable and may (and will) change. If (and only if) kernel-uptime and process-uptime are updated correctly, calculating the absolute start-time will yield a reproducible result only as long as the system clock does not change.
>
>
> I'm pretty sure this qualifies as bug, but not whether it's a java a kernel (or whatever) bug... Any advice, also how to get around this, would be greatly appreciated. I would really like to avoid hard-coding allowed drift ranges or something like this, especially as we'll be running into timezone, summer time, etc. issues AFAICT...
>
>
> Cheers,
>
> Thanks for ANY help,
>
> Markus
>
> SSI Sch?fer IT Solutions GmbH | Friesachstrasse 15 | 8114 Friesach | Austria
> Registered Office: Friesach | Commercial Register: 49324 K | VAT no. ATU28654300
> Commercial Court: Landesgericht f?r Zivilrechtssachen Graz
> Unsere Hinweise zum Umgang mit personenbezogenen Daten finden Sie hier<https://www.ssi-schaefer.com/de-at/datenschutz-49548>.
> You can find our information on the handling of personal data here<https://www.ssi-schaefer.com/en-at/privacy-13258>.


From gunnar at hibernate.org  Thu Aug  8 06:48:43 2019
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 8 Aug 2019 08:48:43 +0200
Subject: Preview APIs for preview features -- JDK 14+
In-Reply-To: <7b3c4e7a-f2bc-7e18-f821-152f17be4c4d@oracle.com>
References: <CADGJaX-5sQfMt6RAnz=m39gt6KfyRNDcxAVUL-YCWBqtZkULoQ@mail.gmail.com>
 <7b3c4e7a-f2bc-7e18-f821-152f17be4c4d@oracle.com>
Message-ID: <CADGJaX8mzmJeJysNp72RSVT0xErQBnUP0tserJ4VrRMw73qDWg@mail.gmail.com>

Thanks, Alex; gotcha, and it's in line with how I understood what the
proposal is about.

Essentially, my question is whether one couldn't come up with a slightly
more versatile solution, which solves both the issue the Java SE Platform
encounters when adding new APIs connected to preview language/VM features,
*and* the similar, yet slightly different situation often-times encountered
by 3rd party library developers.

--Gunnar


Am Mi., 7. Aug. 2019 um 17:04 Uhr schrieb Alex Buckley <
alex.buckley at oracle.com>:

> On 8/7/2019 4:00 AM, Gunnar Morling wrote:
> >> Joe Darcy has proposed that associated APIs are annotated explicitly
> >> (e.g. @java.lang.annotation.PreviewFeature) so that their use can be
> >> detected at compile time.
> >
> > I think that's a very useful addition.
> >
> > IIUC, this is only geared towards usage within the JDK APIs themselves;
> > maybe it could be considered to widen the scope of the proposal and
> enable
> > usage of this functionality by 3rd party APIs? Specifically, I'm thinking
> > of supporting similar, already existing annotations, e.g. @Beta in Guava
> or
> > or @Incubating in Hibernate.
>
> There's a misconception in your model of "preview APIs", regrettably
> caused my use of the term as shorthand in the subject line. Let's be
> clear what we're discussing: an API defined by the Java SE Platform that
> is intimately connected with a preview language/VM feature. (JEP 12
> refers to this as an "essential" API because the JLS cannot avoid
> referring to it in normative text; see the JEP for examples.) If the
> preview language/VM feature changes or disappears, then the API will
> most likely change or disappear too. We are NOT looking to have APIs in
> the Java SE Platform that are "standalone" (independent of preview
> features) yet impermanent and in search of developer feedback. We have
> already settled on incubating APIs (JEP 11) as the mechanism for
> "standalone" impermanent APIs. Incubating APIs are deliberately kept out
> of the Java SE Platform (recall their `jdk.incubator` module and package
> prefix) to ensure developers realize that their use is risky.
>
> Alex
>

From youngty1997 at gmail.com  Thu Aug  8 08:23:50 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Thu, 8 Aug 2019 03:23:50 -0500
Subject: Please implement client switch in 64-bit server JDK 14 builds
In-Reply-To: <d83c6975-006c-07d5-43bf-d4ae1be715e1@redhat.com>
References: <36722c0b-1383-f2ab-315e-060aad41a5c2@gmail.com>
 <d83c6975-006c-07d5-43bf-d4ae1be715e1@redhat.com>
Message-ID: <5c2a36f2-c405-da09-22b4-202332328630@gmail.com>


On 8/7/19 3:49 AM, Andrew Haley wrote:
> On 7/19/19 3:46 AM, Ty Young wrote:
>
>> A "client" JVM variant is geared towards graphical end-user
>> applications. According to a URL link found in the man entry for
>> java[1] this supposedly results in faster startups. While this *may*
>> be true, a much larger and more important benefit is a massive
>> committed memory reduction in the range of about 25% to 50% when
>> running a JavaFX application. At minimum with similar heap sizes,
>> that is a 75 MB memory savings at 300MB (a somewhat typical peak
>> usage with JavaFX applications) with a typical server JVM. That's
>> huge.
> The problem is to some extent that Java sizes itself based on the
> machine that it is running on. If it sees plenty of memory and threads
> it uses them, in an attempt to improve performance.
>
> I think you should be able to achieve some similar results to -client
> by trying -XX:TieredStopAtLevel=1 and sizing the heap appropriately
> for your application. There is also a bunch of GC settings which cause
> it to be very frugal with memory. These together will, I suspect, be
> more effective than the old "-client" option.
>
> In general, I think we do need a "-small" option for the JVM. The GC
> defaults are inappropriate for a lot of applications. However, I'm not
> exactly sure what "-small" should be.


Right, "-small" is really ambiguous. Since, as other people have pointed 
out, noone can agree on the exact meaning, how about mapping various 
arguments to a JVM memory behavior level argument and just letting the 
end JVM user choose?

Presumably these standards would just be meta JVM arguments that could 
be done manually with individual JVM arguments. If an end JVM user wants 
a bit more max memory size for example, they could just manually set Xmx 
to their desired amount and keep the rest of the mode JVM arguments as 
they are. Something like:


-XX:VMMemoryManagementMode=0 // server mode?

-XX:VMMemoryManagementMode=1 // desktop application mode?

-XX:VMMemoryManagementMode=2 // IoT/Kiosk application mode?


Again, the idea here is that these are overridable meta arguments and 
not concrete absolutes. If this was implemented in such a more flexible 
and expandable way there would presumably be less disagreements on the 
specifics since you can just override mode defaults. Say, for example, 
you want 2GB max heap size instead of a default max heap size of 256MB 
for desktop application mode but would like the rest to stay the same.


>
> One set of options we use is:
>
> USE_JVM_ARGS="-XX:+UseParallelGC -XX:MinHeapFreeRatio=5 \
>     -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4 \
>     -XX:AdaptiveSizePolicyWeight=90 -Xms20M -Xmx500M \
>     -XX:MaxMetaspaceSize=100m -XX:+UnlockExperimentalVMOptions \
>     -XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true"
>
> Please let us know if this helps in your case.

Yes, this halves the committed memory usage at least just as a client VM 
did. I'm a bit worried about the max/used heap size, surviving 
generations, and GC runs behavior though. These options unmodified 
basically result in a huge influx of surviving generations over time and 
about 3.7% GC time... modifying a few of them:


-XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 
-XX:AdaptiveSizePolicyWeight=80


Helps but it still seems to happen? It's like the GC is doing only 
partial runs until it literally can't go anymore without doing a full GC.


My understanding of the relationship between heap and surviving 
generations basically boils down to increasing surviving generations = 
bad so I'm at a bit of a loss here. Sometimes it'll show normal heap 
size behavior by plateauing and other times it'll look more like a 
jagged line. Eventually the massive amounts of surviving generations 
will start plateauing alongside heap[1].


I don't know how much it matters, but -XX:+UseCGroupMemoryLimitForHeap 
doesn't seem to be valid on JDK12. Is this a new JDK13 switch?


[1] https://imgur.com/a/yXCkcot


>

From christoph.langer at sap.com  Thu Aug  8 14:23:55 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 8 Aug 2019 14:23:55 +0000
Subject: Mail notification for JBS changes
Message-ID: <AM6PR02MB51924A5656434D87AE4C343C8AD70@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi ops,

I recognize that JBS does not send out mail notifications for changes of JBS items that I'm watching.

Is that a known problem which is going to be fixed soon?

Thanks
Christoph


From daniel.daugherty at oracle.com  Thu Aug  8 14:43:46 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 8 Aug 2019 10:43:46 -0400
Subject: Mail notification for JBS changes
In-Reply-To: <AM6PR02MB51924A5656434D87AE4C343C8AD70@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB51924A5656434D87AE4C343C8AD70@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <a6769048-1e34-a876-8e97-ed5223d5e5d9@oracle.com>

Hi Christop,

This is an issue that we noticed internally in Oracle yesterday. Thanks
for letting us know that external folks are also not getting expected
JBS emails. I'll update the internal ticket with that info...

Dan


On 8/8/19 10:23 AM, Langer, Christoph wrote:
> Hi ops,
>
> I recognize that JBS does not send out mail notifications for changes of JBS items that I'm watching.
>
> Is that a known problem which is going to be fixed soon?
>
> Thanks
> Christoph
>


From christoph.langer at sap.com  Thu Aug  8 14:59:06 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 8 Aug 2019 14:59:06 +0000
Subject: Mail notification for JBS changes
In-Reply-To: <a6769048-1e34-a876-8e97-ed5223d5e5d9@oracle.com>
References: <AM6PR02MB51924A5656434D87AE4C343C8AD70@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <a6769048-1e34-a876-8e97-ed5223d5e5d9@oracle.com>
Message-ID: <AM6PR02MB51923CF5F83CDC9601C616938AD70@AM6PR02MB5192.eurprd02.prod.outlook.com>

Thanks, Dan, for letting me know. I guess I'll also recognize quite quickly once it's fixed again. ??

> -----Original Message-----
> From: Daniel D. Daugherty <daniel.daugherty at oracle.com>
> Sent: Donnerstag, 8. August 2019 16:44
> To: Langer, Christoph <christoph.langer at sap.com>; ops at openjdk.java.net
> Cc: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: Re: Mail notification for JBS changes
> 
> Hi Christop,
> 
> This is an issue that we noticed internally in Oracle yesterday. Thanks
> for letting us know that external folks are also not getting expected
> JBS emails. I'll update the internal ticket with that info...
> 
> Dan
> 
> 
> On 8/8/19 10:23 AM, Langer, Christoph wrote:
> > Hi ops,
> >
> > I recognize that JBS does not send out mail notifications for changes of JBS
> items that I'm watching.
> >
> > Is that a known problem which is going to be fixed soon?
> >
> > Thanks
> > Christoph
> >


From mark.reinhold at oracle.com  Thu Aug  8 16:03:39 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  8 Aug 2019 09:03:39 -0700 (PDT)
Subject: JDK 13 is now in the Release Candidate Phase
Message-ID: <20190808160339.6880C2B91D8@eggemoggin.niobe.net>

Per the JDK 13 schedule [1], we are now in the Release Candidate phase.
The stabilization repository, jdk/jdk13, is open for P1 bug fixes per
the JDK Release Process (JEP 3) [2].  All changes require approval via
the Fix-Request Process [3].

If you?re responsible for any of the bugs on the RC candidate-bug list
[4] then please see JEP 3 for guidance on how to handle them.

We?ll tag the first Release Candidate build shortly.

- Mark


[1] https://openjdk.java.net/projects/jdk/13/#Schedule
[2] https://openjdk.java.net/jeps/3
[3] https://openjdk.java.net/jeps/3#Fix-Request-Process
[4] https://j.mp/jdk-rc

From john.r.rose at oracle.com  Thu Aug  8 18:52:15 2019
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 8 Aug 2019 11:52:15 -0700
Subject: Please implement client switch in 64-bit server JDK 14 builds
In-Reply-To: <d83c6975-006c-07d5-43bf-d4ae1be715e1@redhat.com>
References: <36722c0b-1383-f2ab-315e-060aad41a5c2@gmail.com>
 <d83c6975-006c-07d5-43bf-d4ae1be715e1@redhat.com>
Message-ID: <419612C7-6D2A-4328-AAB2-9BE881CE9BC6@oracle.com>

On Aug 7, 2019, at 1:49 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> The problem is to some extent that Java sizes itself based on the
> machine that it is running on. If it sees plenty of memory and threads
> it uses them, in an attempt to improve performance.
> 
> I think you should be able to achieve some similar results to -client
> by trying -XX:TieredStopAtLevel=1 and sizing the heap appropriately
> for your application. There is also a bunch of GC settings which cause
> it to be very frugal with memory. These together will, I suspect, be
> more effective than the old "-client" option.
> 
> In general, I think we do need a "-small" option for the JVM. The GC
> defaults are inappropriate for a lot of applications. However, I'm not
> exactly sure what "-small" should be.

This is a hard problem, since any additional switch we add will almost
certainly have an unstable impact (behavior, meaning) across releases
and platforms.  Somehow users would have to be coaxed to use a combo
switch like ?-small? as a starting point, rather than a final solution.

(We?ve had switches like this before, such as AggressiveOpts, which
is deprecated in part because it has no stable meaning.)

That said, I have one idea to add to the conversation:  If we are already
setting flags ergonomically based on machine size, a somewhat conservative
thing to do is to allow another switch or dial that alters the apparent size of
the platform, as observed by ergonomic logic (Arguments::apply_ergo).
(Think of it as like a golf handicap, to make a strong player look like a
weaker one?)

Note that the JVM settings after ergo logic can be observed with the
switch -XX:+PrintCommandLineFlags, which (to me) is confusingly similar
to -XX:+PrintVMOptions.  A reasonable thing to do if you are sizing JVMs
would be to run on the target machine with -XX:+PrintCommandLineFlags
and use the displayed values as a starting point for further tuning.
This is true today, and also would be true if we allowed machine sizing
adjuster.

So, if the above is reasonable, then some flags affecting machine
size sensing might make sense.  And, in fact, there are such flags
already, such as -XX:+NeverActAsServerClassMachine.

-XX:CompileThresholdScaling is also such a scaling flag, although
it interacts with a fixed compilation policy.

(BTW, it?s probably an interesting exercise to troll through the sources
looking at all the uses of FLAG_SET_ERGO, and figuring out what
they really mean and how they might be made more tweakable along
the lines of a ?-small? switch.)

Another aspect of ?-small? is minimum values.  Some use cases may
want to say ?give me 2x the minimum? instead of ?give me 50% of the
machine?.  There are minimums today such as CodeCacheMinimumUseSpace
which are set on a per-platform basis.

Putting it together, maybe gross sizing could be controlled as a rough multiplier,
such as 1..9 (qualitative, as with zip) or a (quantitative) percentage, to be applied
either to the minimum setting or the maximum.  The default is then ?100% of maximum?.
Setting to ?1 x minimum?, followed by PrintCommandLineFlags and OS information
displays, would allow operators a somewhat smoother way to detect the minimum and
use that information to size JVMs and their host machines.

But I?ll end where I started:  Such combo switches tends to be unpleasant to maintain,
because their meaning must shift over time, and so (I think) they never really please
the end users.

My $0.02.

? John

From aph at redhat.com  Thu Aug  8 18:53:08 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 8 Aug 2019 19:53:08 +0100
Subject: Please implement client switch in 64-bit server JDK 14 builds
In-Reply-To: <5c2a36f2-c405-da09-22b4-202332328630@gmail.com>
References: <36722c0b-1383-f2ab-315e-060aad41a5c2@gmail.com>
 <d83c6975-006c-07d5-43bf-d4ae1be715e1@redhat.com>
 <5c2a36f2-c405-da09-22b4-202332328630@gmail.com>
Message-ID: <7dea68a8-b3e3-0e2e-5252-62e4a7346f8a@redhat.com>

On 8/8/19 9:23 AM, Ty Young wrote:
> Presumably these standards would just be meta JVM arguments that could 
> be done manually with individual JVM arguments. If an end JVM user wants 
> a bit more max memory size for example, they could just manually set Xmx 
> to their desired amount and keep the rest of the mode JVM arguments as 
> they are. Something like:
> 
> -XX:VMMemoryManagementMode=0 // server mode?
> 
> -XX:VMMemoryManagementMode=1 // desktop application mode?
> 
> -XX:VMMemoryManagementMode=2 // IoT/Kiosk application mode?

Funnily enough, I was talking to John Rose the other day and he
suggested exactly this, but perhaps a scale from 0-10. This idea has
some promise, I think.

-- 
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

From youngty1997 at gmail.com  Thu Aug  8 21:02:09 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Thu, 8 Aug 2019 16:02:09 -0500
Subject: Please implement client switch in 64-bit server JDK 14 builds
In-Reply-To: <7dea68a8-b3e3-0e2e-5252-62e4a7346f8a@redhat.com>
References: <36722c0b-1383-f2ab-315e-060aad41a5c2@gmail.com>
 <d83c6975-006c-07d5-43bf-d4ae1be715e1@redhat.com>
 <5c2a36f2-c405-da09-22b4-202332328630@gmail.com>
 <7dea68a8-b3e3-0e2e-5252-62e4a7346f8a@redhat.com>
Message-ID: <4d014c2f-6e30-536c-8fe3-ae81a7e4382e@gmail.com>


On 8/8/19 1:53 PM, Andrew Haley wrote:
> On 8/8/19 9:23 AM, Ty Young wrote:
>> Presumably these standards would just be meta JVM arguments that could
>> be done manually with individual JVM arguments. If an end JVM user wants
>> a bit more max memory size for example, they could just manually set Xmx
>> to their desired amount and keep the rest of the mode JVM arguments as
>> they are. Something like:
>>
>> -XX:VMMemoryManagementMode=0 // server mode?
>>
>> -XX:VMMemoryManagementMode=1 // desktop application mode?
>>
>> -XX:VMMemoryManagementMode=2 // IoT/Kiosk application mode?
> Funnily enough, I was talking to John Rose the other day and he
> suggested exactly this, but perhaps a scale from 0-10. This idea has
> some promise, I think.
>

Ah, no those numbers aren't part of a scale and personally I don't think 
using a scale is a good idea. If you do a hard 0-10 scale you are 
backing yourself into a corner when the standards of today change.


Remember when 32-bit was assumed to be more than we'd ever need? Or the 
Y2K non-crisis?


You could change the scale internally at a later date, sure, but then 
you'd presumably wind up making people who depended on the old scale 
meanings a bit upset. I guess they'd be using an older JDK but still... 
it'd be nice if this wasn't yet another thing people needed to look out 
for when upgrading JDK versions.


So maybe something like:


-XX:VMMemoryManagementMode=00000 // server mode?

-XX:VMMemoryManagementMode=10000 // desktop application mode?

-XX:VMMemoryManagementMode=20000 // IoT/Kiosk application mode?



The first number in the 5th position represents a mode type while the 
remaining 4 numbers represent iterations of that mode type. The idea 
here is that new iterations of a spec can be added on later. For 
example, 00000 represents a server spec as it would be defined today. 
If, in the future, that changes at all, a new server spec can be made 
like: 00001. This also makes these mode iterations opt-in instead of a 
"fun" little surprise people have to look out for every JDK release.


If there are more than 9999 iterations of a spec mode then I guess that 
mode type could be expanded into the next free mode type position(4, 5, 
6, etc).


I can imagine this getting to become very unmaintainable in such a 
situation to the point that you JVM people will start banging your heads 
against a wall... so maybe a more maintainable solution could be made 
based off of this?


From simon at cjnash.com  Fri Aug  9 05:54:45 2019
From: simon at cjnash.com (Simon Nash)
Date: Fri, 9 Aug 2019 06:54:45 +0100
Subject: Please implement client switch in 64-bit server JDK 14 builds
In-Reply-To: <7dea68a8-b3e3-0e2e-5252-62e4a7346f8a@redhat.com>
References: <36722c0b-1383-f2ab-315e-060aad41a5c2@gmail.com>
 <d83c6975-006c-07d5-43bf-d4ae1be715e1@redhat.com>
 <5c2a36f2-c405-da09-22b4-202332328630@gmail.com>
 <7dea68a8-b3e3-0e2e-5252-62e4a7346f8a@redhat.com>
Message-ID: <b31a3e5e-6923-9ad2-75b2-f26b33f9fffb@cjnash.com>

On 08/08/2019 19:53, Andrew Haley wrote:
> On 8/8/19 9:23 AM, Ty Young wrote:
>> Presumably these standards would just be meta JVM arguments that could
>> be done manually with individual JVM arguments. If an end JVM user wants
>> a bit more max memory size for example, they could just manually set Xmx
>> to their desired amount and keep the rest of the mode JVM arguments as
>> they are. Something like:
>>
>> -XX:VMMemoryManagementMode=0 // server mode?
>>
>> -XX:VMMemoryManagementMode=1 // desktop application mode?
>>
>> -XX:VMMemoryManagementMode=2 // IoT/Kiosk application mode?
> Funnily enough, I was talking to John Rose the other day and he
> suggested exactly this, but perhaps a scale from 0-10. This idea has
> some promise, I think.
>
I like this idea, with 0 being the smallest resource consumption and 10 the largest. It is simple and anyone can understand it. The meaning shouldn't change as 
the JVM evolves, as these are relative rather than absolute values.

Simon

From aph at redhat.com  Fri Aug  9 13:15:32 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 9 Aug 2019 14:15:32 +0100
Subject: Please implement client switch in 64-bit server JDK 14 builds
In-Reply-To: <4d014c2f-6e30-536c-8fe3-ae81a7e4382e@gmail.com>
References: <36722c0b-1383-f2ab-315e-060aad41a5c2@gmail.com>
 <d83c6975-006c-07d5-43bf-d4ae1be715e1@redhat.com>
 <5c2a36f2-c405-da09-22b4-202332328630@gmail.com>
 <7dea68a8-b3e3-0e2e-5252-62e4a7346f8a@redhat.com>
 <4d014c2f-6e30-536c-8fe3-ae81a7e4382e@gmail.com>
Message-ID: <1cbaf060-4afa-2802-ae2b-345ce9e182ff@redhat.com>

On 8/8/19 10:02 PM, Ty Young wrote:
> If there are more than 9999 iterations of a spec mode then I guess that 
> mode type could be expanded into the next free mode type position(4, 5, 
> 6, etc).

I think you're getting carried away.

-- 
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

From aph at redhat.com  Fri Aug  9 13:18:01 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 9 Aug 2019 14:18:01 +0100
Subject: Please implement client switch in 64-bit server JDK 14 builds
In-Reply-To: <419612C7-6D2A-4328-AAB2-9BE881CE9BC6@oracle.com>
References: <36722c0b-1383-f2ab-315e-060aad41a5c2@gmail.com>
 <d83c6975-006c-07d5-43bf-d4ae1be715e1@redhat.com>
 <419612C7-6D2A-4328-AAB2-9BE881CE9BC6@oracle.com>
Message-ID: <17ffca25-cfe2-f7af-6bd7-ef0fd353eafc@redhat.com>

On 8/8/19 7:52 PM, John Rose wrote:
> But I?ll end where I started: ?Such combo switches tends to be unpleasant to maintain,
> because their meaning must shift over time, and so (I think) they never really please
> the end users.

True, but the current situation is a real PITA. When someone says
"Java is huge! Why can't it be smaller!" it'd be nice to be able to
give them a simple (if crude) answer.

-- 
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

From mark.reinhold at oracle.com  Fri Aug  9 18:32:34 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 09 Aug 2019 11:32:34 -0700
Subject: JDK 13: First Release Candidate
Message-ID: <20190809113234.791543658@eggemoggin.niobe.net>

There are no unresolved P1 bugs in build 33, so that is our
first JDK 13 Release Candidate.

Binaries available here, as usual: https://jdk.java.net/13

- Mark

From julia.boes at oracle.com  Tue Aug 13 10:16:21 2019
From: julia.boes at oracle.com (Julia Boes)
Date: Tue, 13 Aug 2019 11:16:21 +0100
Subject: RFR: 8229337: java.lang.Math class doc should be adjusted regarding
 -Exact methods
In-Reply-To: <c0a5898f-6f82-a8e7-df7b-0b56f773e0bf@oracle.com>
References: <c0a5898f-6f82-a8e7-df7b-0b56f773e0bf@oracle.com>
Message-ID: <764b3be1-f820-4289-610e-fa4887512dc0@oracle.com>

Hi,

This is a minor fix of the javadoc in java.lang.Math. The methods 
decrementExact(), incrementExact() and negateExact()? declare they throw 
a ArithmeticException, and as such should be included in the list of 
operations that can detect overflow in the class-level javadoc.

Bug: https://bugs.openjdk.java.net/browse/JDK-8229337
Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229337/webrev.00/

Is a CSR request needed?

Thanks,
Julia



From lance.andersen at oracle.com  Tue Aug 13 10:25:10 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 13 Aug 2019 06:25:10 -0400
Subject: RFR: 8229337: java.lang.Math class doc should be adjusted
 regarding -Exact methods
In-Reply-To: <764b3be1-f820-4289-610e-fa4887512dc0@oracle.com>
References: <c0a5898f-6f82-a8e7-df7b-0b56f773e0bf@oracle.com>
 <764b3be1-f820-4289-610e-fa4887512dc0@oracle.com>
Message-ID: <91637816-6315-45DF-98A3-88FD77D16CB2@oracle.com>

Hi Julia,

I think this looks OK.  I would create a CSR as the changes while minor should get tracked and a final approval via a CSR. 

Best
Lance
> On Aug 13, 2019, at 6:16 AM, Julia Boes <julia.boes at oracle.com> wrote:
> 
> Hi,
> 
> This is a minor fix of the javadoc in java.lang.Math. The methods decrementExact(), incrementExact() and negateExact()  declare they throw a ArithmeticException, and as such should be included in the list of operations that can detect overflow in the class-level javadoc.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229337
> Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229337/webrev.00/
> 
> Is a CSR request needed?
> 
> Thanks,
> Julia
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From julia.boes at oracle.com  Tue Aug 13 11:32:24 2019
From: julia.boes at oracle.com (Julia Boes)
Date: Tue, 13 Aug 2019 12:32:24 +0100
Subject: RFR: 8229337: java.lang.Math class doc should be adjusted
 regarding -Exact methods
In-Reply-To: <91637816-6315-45DF-98A3-88FD77D16CB2@oracle.com>
References: <c0a5898f-6f82-a8e7-df7b-0b56f773e0bf@oracle.com>
 <764b3be1-f820-4289-610e-fa4887512dc0@oracle.com>
 <91637816-6315-45DF-98A3-88FD77D16CB2@oracle.com>
Message-ID: <ae4b179b-95ab-70f6-2e58-c13341e09277@oracle.com>

Hi Lance,

Thanks for the info.

CSR: https://bugs.openjdk.java.net/browse/JDK-8229473

Best,

Julia

On 13/08/2019 11:25, Lance Andersen wrote:
> Hi Julia,
>
> I think this looks OK. ?I would create a CSR as the changes while 
> minor should get tracked and a final approval via a CSR.
>
> Best
> Lance
>> On Aug 13, 2019, at 6:16 AM, Julia Boes <julia.boes at oracle.com 
>> <mailto:julia.boes at oracle.com>> wrote:
>>
>> Hi,
>>
>> This is a minor fix of the javadoc in java.lang.Math. The methods 
>> decrementExact(), incrementExact() and negateExact()? declare they 
>> throw a ArithmeticException, and as such should be included in the 
>> list of operations that can detect overflow in the class-level javadoc.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229337
>> Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229337/webrev.00/
>>
>> Is a CSR request needed?
>>
>> Thanks,
>> Julia
>>
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>

From lance.andersen at oracle.com  Tue Aug 13 11:55:07 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 13 Aug 2019 07:55:07 -0400
Subject: RFR: 8229337: java.lang.Math class doc should be adjusted
 regarding -Exact methods
In-Reply-To: <ae4b179b-95ab-70f6-2e58-c13341e09277@oracle.com>
References: <c0a5898f-6f82-a8e7-df7b-0b56f773e0bf@oracle.com>
 <764b3be1-f820-4289-610e-fa4887512dc0@oracle.com>
 <91637816-6315-45DF-98A3-88FD77D16CB2@oracle.com>
 <ae4b179b-95ab-70f6-2e58-c13341e09277@oracle.com>
Message-ID: <B69FA62B-CE9B-4CF4-A711-4C8322339A53@oracle.com>

Hi Julia,

I added myself as a reviewer.  

A couple of suggestions to consider:

Update:

??????
A minor fix of the javadoc in java.lang.Math. The methods decrementExact(), incrementExact(), and negateExact()  declare they throw a ArithmeticException, and as such should be included in the list of operations that can detect overflow in the class-level javadoc.
????????

to

???
Clarify the javadoc class summary for java.lang.Math class  to indicate that the methods s decrementExact(), incrementExact() and negateExact()   throw a ArithmeticException when the results overflow 
????

For compatibility risk it  would be none (there is no behavioral change);

For the compatibility description  I would also clarify that there is no behavioral change 

Compatibility kind is probably best as behavioral given you are clarifying what actually can happen for the methods.


You are good to go and you can finalize as this will be an easy (famous last words) review/approval :-)

HTH

Best
Lance

> On Aug 13, 2019, at 7:32 AM, Julia Boes <julia.boes at oracle.com> wrote:
> 
> Hi Lance,
> 
> Thanks for the info. 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8229473 <https://bugs.openjdk.java.net/browse/JDK-8229473>
> Best,
> 
> Julia
> On 13/08/2019 11:25, Lance Andersen wrote:
>> Hi Julia,
>> 
>> I think this looks OK.  I would create a CSR as the changes while minor should get tracked and a final approval via a CSR. 
>> 
>> Best
>> Lance
>>> On Aug 13, 2019, at 6:16 AM, Julia Boes <julia.boes at oracle.com <mailto:julia.boes at oracle.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> This is a minor fix of the javadoc in java.lang.Math. The methods decrementExact(), incrementExact() and negateExact()  declare they throw a ArithmeticException, and as such should be included in the list of operations that can detect overflow in the class-level javadoc.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229337 <https://bugs.openjdk.java.net/browse/JDK-8229337>
>>> Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229337/webrev.00/ <http://cr.openjdk.java.net/~dfuchs/jboes/8229337/webrev.00/>
>>> 
>>> Is a CSR request needed?
>>> 
>>> Thanks,
>>> Julia
>>> 
>>> 
>> 
>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>> 
>> 
>> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From julia.boes at oracle.com  Tue Aug 13 12:51:02 2019
From: julia.boes at oracle.com (Julia Boes)
Date: Tue, 13 Aug 2019 13:51:02 +0100
Subject: RFR: 8229337: java.lang.Math class doc should be adjusted
 regarding -Exact methods
In-Reply-To: <B69FA62B-CE9B-4CF4-A711-4C8322339A53@oracle.com>
References: <c0a5898f-6f82-a8e7-df7b-0b56f773e0bf@oracle.com>
 <764b3be1-f820-4289-610e-fa4887512dc0@oracle.com>
 <91637816-6315-45DF-98A3-88FD77D16CB2@oracle.com>
 <ae4b179b-95ab-70f6-2e58-c13341e09277@oracle.com>
 <B69FA62B-CE9B-4CF4-A711-4C8322339A53@oracle.com>
Message-ID: <9eb74cb1-7f86-4068-52e1-ff79b669671f@oracle.com>

Hi Lance,

Thanks for your suggestions. I incorporated them, except for the change 
of the compatibility risk because that Jira doesn't accept the option 
'None' for this field :(

Best,

Julia

On 13/08/2019 12:55, Lance Andersen wrote:
> Hi Julia,
>
> I added myself as a reviewer.
>
> A couple of suggestions to consider:
>
> Update:
>
> ??????
> A minor fix of the javadoc in java.lang.Math. The methods 
> decrementExact(), incrementExact(), and negateExact() ?declare they 
> throw a ArithmeticException, and as such should be included in the 
> list of operations that can detect overflow in the class-level javadoc.
> ????????
>
> to
>
> ???
> Clarify the javadoc class summary for java.lang.Math class ?to 
> indicate that the methods s decrementExact(), incrementExact() and 
> negateExact() ? throw a ArithmeticException when the results overflow
> ????
>
> For compatibility risk it ?would be none (there is no behavioral change);
>
> For the compatibility description ?I would also clarify that there is 
> no behavioral change
>
> Compatibility kind is probably best as behavioral given you are 
> clarifying what actually can happen for the methods.
>
>
> You are good to go and you can finalize as this will be an easy 
> (famous last words) review/approval :-)
>
> HTH
>
> Best
> Lance
>
>> On Aug 13, 2019, at 7:32 AM, Julia Boes <julia.boes at oracle.com 
>> <mailto:julia.boes at oracle.com>> wrote:
>>
>> Hi Lance,
>>
>> Thanks for the info.
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8229473
>>
>> Best,
>>
>> Julia
>>
>> On 13/08/2019 11:25, Lance Andersen wrote:
>>> Hi Julia,
>>>
>>> I think this looks OK. ?I would create a CSR as the changes while 
>>> minor should get tracked and a final approval via a CSR.
>>>
>>> Best
>>> Lance
>>>> On Aug 13, 2019, at 6:16 AM, Julia Boes <julia.boes at oracle.com 
>>>> <mailto:julia.boes at oracle.com>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> This is a minor fix of the javadoc in java.lang.Math. The methods 
>>>> decrementExact(), incrementExact() and negateExact()? declare they 
>>>> throw a ArithmeticException, and as such should be included in the 
>>>> list of operations that can detect overflow in the class-level javadoc.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229337
>>>> Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229337/webrev.00/
>>>>
>>>> Is a CSR request needed?
>>>>
>>>> Thanks,
>>>> Julia
>>>>
>>>>
>>>
>>> <oracle_sig_logo.gif> 
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle?Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>
>>>
>>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>

From vladimir.x.ivanov at oracle.com  Thu Aug 15 13:31:41 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 15 Aug 2019 16:31:41 +0300
Subject: Result: New JDK Reviewer: Dmitrij Pochepko
In-Reply-To: <117eeec5-d646-d92f-dca1-41e35433162b@oracle.com>
References: <117eeec5-d646-d92f-dca1-41e35433162b@oracle.com>
Message-ID: <46dc51ef-60be-e834-ff11-baa4daeca6ca@oracle.com>

Voting for Dmitrij Pochepko [1] is now closed.

Yes: 7
Veto: 2 [2][3]
Abstain: 1

According to the Bylaws definition of Three-Vote Consensus, this is
insufficient to approve the nomination.

Best regards,
Vladimir Ivanov

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-July/003188.html
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-July/003214.html
[3] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-July/003228.html

From sixcorners at gmail.com  Thu Aug 15 09:48:51 2019
From: sixcorners at gmail.com (Stephen Buergler)
Date: Thu, 15 Aug 2019 04:48:51 -0500
Subject: flatMap still prevents short circuiting when using .iterator()
Message-ID: <CAJxPRwWYT6j988ufnoPeX=Gqv2eQrqgtv_fmw1t2ao4deCHvRg@mail.gmail.com>

Not really sure where to send this.
flatMap was fixed so that it doesn't prevent short circuiting.
https://bugs.openjdk.java.net/browse/JDK-8075939
If you replace the test cases in the ticket with versions that use
.iterator().next() instead of .findFirst().get() then the problem
still happens.
I just tested this with openjdk:14 on docker hub.

From ioi.lam at oracle.com  Fri Aug 16 00:09:59 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 15 Aug 2019 17:09:59 -0700
Subject: CFV: New JDK Reviewer: Yumin Qi
Message-ID: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>

I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.

Yumin is currently a JDK Project Committer and a member of the HotSpot 
Group [3]. He has contributed over 50 changesets [1].

Yumin has primarily worked on Hotspot Runtime and Serviceability areas. 
He is now working on the JWarmup JEP [2] to help improve application 
peak load time performance. Yumin also worked on AppCDS (Application 
Class Data Sharing) and made contribution to the feature. He is an 
active member in the OpenJDK community.

Only current JDK Reviewers [3] are eligible to vote on this nomination. 
Votes must be cast in the open by replying to this mailing list.

For Three-Vote Consensus voting instructions, see [4].

[1] 
http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
[2] http://openjdk.java.net/jeps/8203832
[3] http://openjdk.java.net/census
[4] http://openjdk.java.net/projects/#reviewer-vote

From volker.simonis at gmail.com  Fri Aug 16 07:45:51 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 16 Aug 2019 09:45:51 +0200
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <CA+3eh13bf6S4Y45mtxQhPJ2QGjktHVrkR5uPHSqmD3GzMZrvcQ@mail.gmail.com>

Vote: yes


Ioi Lam <ioi.lam at oracle.com> schrieb am Fr., 16. Aug. 2019, 02:11:

> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
>
> Yumin is currently a JDK Project Committer and a member of the HotSpot
> Group [3]. He has contributed over 50 changesets [1].
>
> Yumin has primarily worked on Hotspot Runtime and Serviceability areas.
> He is now working on the JWarmup JEP [2] to help improve application
> peak load time performance. Yumin also worked on AppCDS (Application
> Class Data Sharing) and made contribution to the feature. He is an
> active member in the OpenJDK community.
>
> Only current JDK Reviewers [3] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> [1]
>
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
>

From sean.coffey at oracle.com  Fri Aug 16 07:49:05 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 16 Aug 2019 08:49:05 +0100
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <183e1de7-5a13-1616-5bd3-bb8b22a8b52d@oracle.com>

Vote: yes

regards,
Sean.

On 16/08/2019 01:09, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
>
> Yumin is currently a JDK Project Committer and a member of the HotSpot 
> Group [3]. He has contributed over 50 changesets [1].
>
> Yumin has primarily worked on Hotspot Runtime and Serviceability 
> areas. He is now working on the JWarmup JEP [2] to help improve 
> application peak load time performance. Yumin also worked on AppCDS 
> (Application Class Data Sharing) and made contribution to the feature. 
> He is an active member in the OpenJDK community.
>
> Only current JDK Reviewers [3] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote

From adinn at redhat.com  Fri Aug 16 08:08:01 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 16 Aug 2019 09:08:01 +0100
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <868eb41c-6eaf-c879-3827-a346cd1666ce@redhat.com>

Vote: Yes

On 16/08/2019 01:09, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
> 
> Yumin is currently a JDK Project Committer and a member of the HotSpot
> Group [3]. He has contributed over 50 changesets [1].
> 
> Yumin has primarily worked on Hotspot Runtime and Serviceability areas.
> He is now working on the JWarmup JEP [2] to help improve application
> peak load time performance. Yumin also worked on AppCDS (Application
> Class Data Sharing) and made contribution to the feature. He is an
> active member in the OpenJDK community.
> 
> Only current JDK Reviewers [3] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
> 
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
> 

-- 
regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From sgehwolf at redhat.com  Fri Aug 16 08:22:29 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 16 Aug 2019 10:22:29 +0200
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <92789c356369dec9af155651a70b0b6adb8b002a.camel@redhat.com>

Vote: yes

On Thu, 2019-08-15 at 17:09 -0700, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.


From zgu at redhat.com  Fri Aug 16 11:28:14 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Fri, 16 Aug 2019 07:28:14 -0400
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <5a7d546f-5a9d-7ffd-5075-b21660c28c9e@redhat.com>

Vote: yes.

-Zhengyu

On 8/15/19 8:09 PM, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
> 
> Yumin is currently a JDK Project Committer and a member of the HotSpot 
> Group [3]. He has contributed over 50 changesets [1].
> 
> Yumin has primarily worked on Hotspot Runtime and Serviceability areas. 
> He is now working on the JWarmup JEP [2] to help improve application 
> peak load time performance. Yumin also worked on AppCDS (Application 
> Class Data Sharing) and made contribution to the feature. He is an 
> active member in the OpenJDK community.
> 
> Only current JDK Reviewers [3] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29 
> 
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote

From harold.seigel at oracle.com  Fri Aug 16 11:54:11 2019
From: harold.seigel at oracle.com (Harold Seigel)
Date: Fri, 16 Aug 2019 07:54:11 -0400
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <d95e3a3c-0f7c-d3a6-e5f2-16d992a53e74@oracle.com>

Vote: yes

Harold

On 8/15/2019 8:09 PM, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
>
> Yumin is currently a JDK Project Committer and a member of the HotSpot 
> Group [3]. He has contributed over 50 changesets [1].
>
> Yumin has primarily worked on Hotspot Runtime and Serviceability 
> areas. He is now working on the JWarmup JEP [2] to help improve 
> application peak load time performance. Yumin also worked on AppCDS 
> (Application Class Data Sharing) and made contribution to the feature. 
> He is an active member in the OpenJDK community.
>
> Only current JDK Reviewers [3] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote

From lois.foltan at oracle.com  Fri Aug 16 12:45:39 2019
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 16 Aug 2019 08:45:39 -0400
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <2416387c-9814-818d-623c-3ce437a5646e@oracle.com>

Vote: yes

Lois

On 8/15/2019 8:09 PM, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
>
> Yumin is currently a JDK Project Committer and a member of the HotSpot 
> Group [3]. He has contributed over 50 changesets [1].
>
> Yumin has primarily worked on Hotspot Runtime and Serviceability 
> areas. He is now working on the JWarmup JEP [2] to help improve 
> application peak load time performance. Yumin also worked on AppCDS 
> (Application Class Data Sharing) and made contribution to the feature. 
> He is an active member in the OpenJDK community.
>
> Only current JDK Reviewers [3] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote


From daniel.daugherty at oracle.com  Fri Aug 16 13:23:49 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 16 Aug 2019 09:23:49 -0400
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <c57ce9db-c369-b8db-f628-f3ba36ba9064@oracle.com>

Vote: yes

Dan


On 8/15/19 8:09 PM, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
>
> Yumin is currently a JDK Project Committer and a member of the HotSpot 
> Group [3]. He has contributed over 50 changesets [1].
>
> Yumin has primarily worked on Hotspot Runtime and Serviceability 
> areas. He is now working on the JWarmup JEP [2] to help improve 
> application peak load time performance. Yumin also worked on AppCDS 
> (Application Class Data Sharing) and made contribution to the feature. 
> He is an active member in the OpenJDK community.
>
> Only current JDK Reviewers [3] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
>


From coleen.phillimore at oracle.com  Fri Aug 16 13:42:36 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 16 Aug 2019 09:42:36 -0400
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <e0624107-be1c-4b06-a8e6-a5497314d027@oracle.com>

Vote: yes

On 8/15/19 8:09 PM, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
>
> Yumin is currently a JDK Project Committer and a member of the HotSpot 
> Group [3]. He has contributed over 50 changesets [1].
>
> Yumin has primarily worked on Hotspot Runtime and Serviceability 
> areas. He is now working on the JWarmup JEP [2] to help improve 
> application peak load time performance. Yumin also worked on AppCDS 
> (Application Class Data Sharing) and made contribution to the feature. 
> He is an active member in the OpenJDK community.
>
> Only current JDK Reviewers [3] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote


From vladimir.x.ivanov at oracle.com  Fri Aug 16 14:15:18 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 16 Aug 2019 17:15:18 +0300
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <a79df548-28ec-4b45-73c7-08d6d4b5bcd4@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

On 15/08/2019 17:09, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.

From xuelei.fan at oracle.com  Fri Aug 16 15:56:12 2019
From: xuelei.fan at oracle.com (Xue-Lei Fan)
Date: Fri, 16 Aug 2019 08:56:12 -0700 (PDT)
Subject: CFV: New JDK Reviewer: Yumin Qi
Message-ID: <b889a387-f22e-4abb-beca-d8863056a4ae@default>

Vote: Yes

----- Original Message -----
From: ioi.lam at oracle.com
To: jdk-dev at openjdk.java.net
Sent: Thursday, August 15, 2019 5:11:02 PM GMT -08:00 US/Canada Pacific
Subject: CFV: New JDK Reviewer: Yumin Qi

I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.

Yumin is currently a JDK Project Committer and a member of the HotSpot 
Group [3]. He has contributed over 50 changesets [1].

Yumin has primarily worked on Hotspot Runtime and Serviceability areas. 
He is now working on the JWarmup JEP [2] to help improve application 
peak load time performance. Yumin also worked on AppCDS (Application 
Class Data Sharing) and made contribution to the feature. He is an 
active member in the OpenJDK community.

Only current JDK Reviewers [3] are eligible to vote on this nomination. 
Votes must be cast in the open by replying to this mailing list.

For Three-Vote Consensus voting instructions, see [4].

[1] 
http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
[2] http://openjdk.java.net/jeps/8203832
[3] http://openjdk.java.net/census
[4] http://openjdk.java.net/projects/#reviewer-vote

From tobias.hartmann at oracle.com  Mon Aug 19 06:59:25 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 19 Aug 2019 08:59:25 +0200
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <22578233-f692-66eb-6c63-064b0a175cf5@oracle.com>

Vote: yes

Best regards,
Tobias

On 16.08.19 02:09, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
> 
> Yumin is currently a JDK Project Committer and a member of the HotSpot Group [3]. He has contributed
> over 50 changesets [1].
> 
> Yumin has primarily worked on Hotspot Runtime and Serviceability areas. He is now working on the
> JWarmup JEP [2] to help improve application peak load time performance. Yumin also worked on AppCDS
> (Application Class Data Sharing) and made contribution to the feature. He is an active member in the
> OpenJDK community.
> 
> Only current JDK Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the
> open by replying to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> [1] http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote

From tprintezis at twitter.com  Mon Aug 19 12:41:55 2019
From: tprintezis at twitter.com (Tony Printezis)
Date: Mon, 19 Aug 2019 08:41:55 -0400
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <CAOzU2ine+ecMBdfa4btsWY0xJrtuEAMCKcF70J6P5_nTjEp6bw@mail.gmail.com>

Yes.

Tony


?????
Tony Printezis | @TonyPrintezis | tprintezis at twitter.com


On August 15, 2019 at 8:21:27 PM, Ioi Lam (ioi.lam at oracle.com) wrote:

I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.

Yumin is currently a JDK Project Committer and a member of the HotSpot
Group [3]. He has contributed over 50 changesets [1].

Yumin has primarily worked on Hotspot Runtime and Serviceability areas.
He is now working on the JWarmup JEP [2] to help improve application
peak load time performance. Yumin also worked on AppCDS (Application
Class Data Sharing) and made contribution to the feature. He is an
active member in the OpenJDK community.

Only current JDK Reviewers [3] are eligible to vote on this nomination.
Votes must be cast in the open by replying to this mailing list.

For Three-Vote Consensus voting instructions, see [4].

[1]
http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
[2] http://openjdk.java.net/jeps/8203832
[3] http://openjdk.java.net/census
[4] http://openjdk.java.net/projects/#reviewer-vote

From Michael.Rasmussen at roguewave.com  Mon Aug 19 15:11:03 2019
From: Michael.Rasmussen at roguewave.com (Michael Rasmussen)
Date: Mon, 19 Aug 2019 15:11:03 +0000
Subject: Switch Expressions (Preview) release notes links to wrong URL
Message-ID: <CH2PR02MB6054A9CA6352303D5911FDDEE0A80@CH2PR02MB6054.namprd02.prod.outlook.com>

Hi

Was looking at some of the release notes today for JDK13 and noticed that the release notes for the Switch Expressions (Preview) links to the wrong JEP for Preview features; it incorrectly link to JEP13 (that doesn't exists) instead of JEP12.
https://bugs.openjdk.java.net/browse/JDK-8226915

On a side note, does it actually make sense to reference JEP305 from switch expressions anymore, considering the current wording of that JEP?

/Michael

From jan.lahoda at oracle.com  Mon Aug 19 15:35:51 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 19 Aug 2019 17:35:51 +0200
Subject: Switch Expressions (Preview) release notes links to wrong URL
In-Reply-To: <CH2PR02MB6054A9CA6352303D5911FDDEE0A80@CH2PR02MB6054.namprd02.prod.outlook.com>
References: <CH2PR02MB6054A9CA6352303D5911FDDEE0A80@CH2PR02MB6054.namprd02.prod.outlook.com>
Message-ID: <00547ba2-11a7-89cc-936a-1ac2bb3a3260@oracle.com>

Hi Michael,

Thanks for the comments. I've fixed the reference to JEP 12, and change 
the reference to the pattern matching JEP to 8213076, which is about 
pattern matching in switches.

Thanks,
     Jan

On 19. 08. 19 17:11, Michael Rasmussen wrote:
> Hi
> 
> Was looking at some of the release notes today for JDK13 and noticed that the release notes for the Switch Expressions (Preview) links to the wrong JEP for Preview features; it incorrectly link to JEP13 (that doesn't exists) instead of JEP12.
> https://bugs.openjdk.java.net/browse/JDK-8226915
> 
> On a side note, does it actually make sense to reference JEP305 from switch expressions anymore, considering the current wording of that JEP?
> 
> /Michael
> 

From calvin.cheung at oracle.com  Mon Aug 19 15:51:01 2019
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Mon, 19 Aug 2019 08:51:01 -0700
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <f2fa33cb-fcf8-4951-e642-83613caf5284@oracle.com>

Vote: yes

On 8/15/19 5:09 PM, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
>
> Yumin is currently a JDK Project Committer and a member of the HotSpot 
> Group [3]. He has contributed over 50 changesets [1].
>
> Yumin has primarily worked on Hotspot Runtime and Serviceability 
> areas. He is now working on the JWarmup JEP [2] to help improve 
> application peak load time performance. Yumin also worked on AppCDS 
> (Application Class Data Sharing) and made contribution to the feature. 
> He is an active member in the OpenJDK community.
>
> Only current JDK Reviewers [3] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote

From stevenschlansker at gmail.com  Mon Aug 19 20:10:18 2019
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Mon, 19 Aug 2019 13:10:18 -0700
Subject: [JDK-8210527] NullPointerException in jstack exception rendering
Message-ID: <586D7C71-D908-4A7C-A82A-2F731966D409@gmail.com>

Hello jdk-dev, (hopefully this is the best list, I did not see a jshell-dev)

I spent most of my Friday diagnosing a confusing issue
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8229863

which turned out to be a duplicate of JDK-8210527
Unfortunately it's been open most of a year with no progress.

The fix is seemingly trivial:

diff -r 31b7274c7b9e src/jdk.jshell/share/classes/jdk/jshell/Eval.java
--- a/src/jdk.jshell/share/classes/jdk/jshell/Eval.java Fri Aug 09 03:36:59 2019 +0200
+++ b/src/jdk.jshell/share/classes/jdk/jshell/Eval.java Mon Aug 19 13:06:57 2019 -0700
@@ -1106,7 +1106,7 @@
                 Snippet sn = outer.wrapLineToSnippet(wln);
                 String file = "#" + sn.id();
                 elems[i] = new StackTraceElement(klass, method, file, line);
-            } else if (r.getFileName().equals("<none>")) {
+            } else if ("<none>".equals(r.getFileName())) {
                 elems[i] = new StackTraceElement(r.getClassName(), r.getMethodName(), null, r.getLineNumber());
             } else {
                 elems[i] = r;

I verified this fix against jdk13 tip.  Before:

Unexpected exception reading startup: java.lang.NullPointerException
java.lang.NullPointerException
	at jdk.jshell/jdk.jshell.Eval.translateExceptionStack(Eval.java:1109)
	at jdk.jshell/jdk.jshell.Eval.asEvalException(Eval.java:907)
	at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:888)
	at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
	at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3558)
	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1305)
	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1203)
	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1176)
	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.startUpRun(JShellTool.java:1143)
	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.resetState(JShellTool.java:1099)
	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:933)
	at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:254)
	at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.run(JShellToolProvider.java:94)
	at JshellNpe.main(JshellNpe.java:20)

After,

Exception java.lang.IllegalStateException: This helpful exception message is lost
      at JshellNpe.lambda$2 (JshellNpe.java:27)
      at $Proxy0.hashCode (Unknown Source)
      at JshellNpe.init (JshellNpe.java:28)
      at (#s1:1)

Much better!

What can I do to help move this issue forward to resolution?

thanks,
Steven


From martinrb at google.com  Tue Aug 20 02:35:37 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 19 Aug 2019 19:35:37 -0700
Subject: [JDK-8210527] NullPointerException in jstack exception rendering
In-Reply-To: <586D7C71-D908-4A7C-A82A-2F731966D409@gmail.com>
References: <586D7C71-D908-4A7C-A82A-2F731966D409@gmail.com>
Message-ID: <CA+kOe09_kreAJOVRCMxgjGZ1g07G0FHTfMBg2w0=3xA=A5JiaQ@mail.gmail.com>

Thanks, Steven.
I updated the bug system to point to your patch and resolve yet another
duplicate I had reported earlier.
jdk-dev is surely not the right mailing list, but I'm not sure which is.

On Mon, Aug 19, 2019 at 1:11 PM Steven Schlansker <
stevenschlansker at gmail.com> wrote:

> Hello jdk-dev, (hopefully this is the best list, I did not see a
> jshell-dev)
>
> I spent most of my Friday diagnosing a confusing issue
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8229863
>
> which turned out to be a duplicate of JDK-8210527
> Unfortunately it's been open most of a year with no progress.
>
> The fix is seemingly trivial:
>
> diff -r 31b7274c7b9e src/jdk.jshell/share/classes/jdk/jshell/Eval.java
> --- a/src/jdk.jshell/share/classes/jdk/jshell/Eval.java Fri Aug 09
> 03:36:59 2019 +0200
> +++ b/src/jdk.jshell/share/classes/jdk/jshell/Eval.java Mon Aug 19
> 13:06:57 2019 -0700
> @@ -1106,7 +1106,7 @@
>                  Snippet sn = outer.wrapLineToSnippet(wln);
>                  String file = "#" + sn.id();
>                  elems[i] = new StackTraceElement(klass, method, file,
> line);
> -            } else if (r.getFileName().equals("<none>")) {
> +            } else if ("<none>".equals(r.getFileName())) {
>                  elems[i] = new StackTraceElement(r.getClassName(),
> r.getMethodName(), null, r.getLineNumber());
>              } else {
>                  elems[i] = r;
>
> I verified this fix against jdk13 tip.  Before:
>
> Unexpected exception reading startup: java.lang.NullPointerException
> java.lang.NullPointerException
>         at
> jdk.jshell/jdk.jshell.Eval.translateExceptionStack(Eval.java:1109)
>         at jdk.jshell/jdk.jshell.Eval.asEvalException(Eval.java:907)
>         at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:888)
>         at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
>         at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>         at
> jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3558)
>         at
> jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1305)
>         at
> jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1203)
>         at
> jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1176)
>         at
> jdk.jshell/jdk.internal.jshell.tool.JShellTool.startUpRun(JShellTool.java:1143)
>         at
> jdk.jshell/jdk.internal.jshell.tool.JShellTool.resetState(JShellTool.java:1099)
>         at
> jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:933)
>         at
> jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:254)
>         at
> jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.run(JShellToolProvider.java:94)
>         at JshellNpe.main(JshellNpe.java:20)
>
> After,
>
> Exception java.lang.IllegalStateException: This helpful exception message
> is lost
>       at JshellNpe.lambda$2 (JshellNpe.java:27)
>       at $Proxy0.hashCode (Unknown Source)
>       at JshellNpe.init (JshellNpe.java:28)
>       at (#s1:1)
>
> Much better!
>
> What can I do to help move this issue forward to resolution?
>
> thanks,
> Steven
>
>

From serguei.spitsyn at oracle.com  Tue Aug 20 05:03:34 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 19 Aug 2019 22:03:34 -0700
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <4f7a17ff-9d2b-8d5a-aa6b-b44aeaf3c10e@oracle.com>

Vote: yes


From adinn at redhat.com  Tue Aug 20 08:05:20 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 20 Aug 2019 09:05:20 +0100
Subject: Status of submit server?
Message-ID: <c7aa68e9-e951-6e4b-d950-9f6cd768b4d5@redhat.com>

I pushed a commit to the submit repo midday yesterday and still have not
received a response. Could someone from Oracle check whether the server
is running ok?

In case it helps identify any potential problem the commit was for
branch JDK-8224974-10

Thanks to whoever is able to help with this.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From stefan.karlsson at oracle.com  Tue Aug 20 08:14:12 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 20 Aug 2019 10:14:12 +0200
Subject: Status of submit server?
In-Reply-To: <c7aa68e9-e951-6e4b-d950-9f6cd768b4d5@redhat.com>
References: <c7aa68e9-e951-6e4b-d950-9f6cd768b4d5@redhat.com>
Message-ID: <f8cf1bd9-0570-53ab-1492-3e08c4a2ea1c@oracle.com>

Hi Andrew,

On 2019-08-20 10:05, Andrew Dinn wrote:
> I pushed a commit to the submit repo midday yesterday and still have not
> received a response. Could someone from Oracle check whether the server
> is running ok?

I don't know how to check this, but ...

> 
> In case it helps identify any potential problem the commit was for
> branch JDK-8224974-10

... the run succeeded without failures. The change that it ran against 
was 8527e8781f87c6fc86e916ca41f4fb562e20c2e3.

Cheers,
StefanK

> 
> Thanks to whoever is able to help with this.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 

From shade at redhat.com  Tue Aug 20 08:17:33 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 20 Aug 2019 10:17:33 +0200
Subject: Status of submit server?
In-Reply-To: <c7aa68e9-e951-6e4b-d950-9f6cd768b4d5@redhat.com>
References: <c7aa68e9-e951-6e4b-d950-9f6cd768b4d5@redhat.com>
Message-ID: <4c047046-ca67-73a7-fe64-6bbd6f4c4266@redhat.com>

On 8/20/19 10:05 AM, Andrew Dinn wrote:
> I pushed a commit to the submit repo midday yesterday and still have not
> received a response. Could someone from Oracle check whether the server
> is running ok?
> 
> In case it helps identify any potential problem the commit was for
> branch JDK-8224974-10
> 
> Thanks to whoever is able to help with this.
I wonder if notifications are stalled somewhere. I submitted JDK-8152467 last morning, and seen no
reply either...

-- 
Thanks,
-Aleksey


From adinn at redhat.com  Tue Aug 20 08:28:01 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 20 Aug 2019 09:28:01 +0100
Subject: Status of submit server?
In-Reply-To: <f8cf1bd9-0570-53ab-1492-3e08c4a2ea1c@oracle.com>
References: <c7aa68e9-e951-6e4b-d950-9f6cd768b4d5@redhat.com>
 <f8cf1bd9-0570-53ab-1492-3e08c4a2ea1c@oracle.com>
Message-ID: <51f21f82-08d4-eb51-f801-861ef3a11b92@redhat.com>

Hi Stefan,

Thanks very much for looking into this.

On 20/08/2019 09:14, Stefan Karlsson wrote:
> I don't know how to check this, but ...

... nevertheless you still have the advantage over me :-)

Aleksey may be correct that the problem is with notification email
delivery. There is definitely no notice in my spam folder or inbox. Of
course, the problem (if any) might be en route rather than at source. I
would be good to know if others have received notifications in the last
24 hours.

>> In case it helps identify any potential problem the commit was for
>> branch JDK-8224974-10
> 
> ... the run succeeded without failures. The change that it ran against
> was 8527e8781f87c6fc86e916ca41f4fb562e20c2e3.
Now, that's the news I wanted to hear. Cheers!

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From shade at redhat.com  Tue Aug 20 09:11:02 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 20 Aug 2019 11:11:02 +0200
Subject: JDK-8219997
Message-ID: <666ddb90-bbf6-9254-5d71-a766f9999c4c@redhat.com>

Hi,

Does anyone know why this bug is confidential?
  https://bugs.openjdk.java.net/browse/JDK-8219997

It looks like the innocuous testbug:
  https://hg.openjdk.java.net/jdk/jdk/rev/dcaced4cbb83

We would like to have it in the open, so we can tag it for appropriate backports.

-- 
Thanks,
-Aleksey


From david.holmes at oracle.com  Tue Aug 20 12:16:21 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Aug 2019 22:16:21 +1000
Subject: JDK-8219997
In-Reply-To: <666ddb90-bbf6-9254-5d71-a766f9999c4c@redhat.com>
References: <666ddb90-bbf6-9254-5d71-a766f9999c4c@redhat.com>
Message-ID: <e56fba51-d119-d642-deb6-f0bcd068eaf2@oracle.com>

On 20/08/2019 7:11 pm, Aleksey Shipilev wrote:
> Hi,
> 
> Does anyone know why this bug is confidential?
>    https://bugs.openjdk.java.net/browse/JDK-8219997

No reason that I can see. I've made it public.

David

> It looks like the innocuous testbug:
>    https://hg.openjdk.java.net/jdk/jdk/rev/dcaced4cbb83
> 
> We would like to have it in the open, so we can tag it for appropriate backports.
> 

From stanislav.smirnov at oracle.com  Tue Aug 20 12:18:40 2019
From: stanislav.smirnov at oracle.com (Stanislav Smirnov)
Date: Tue, 20 Aug 2019 08:18:40 -0400
Subject: Status of submit server?
In-Reply-To: <51f21f82-08d4-eb51-f801-861ef3a11b92@redhat.com>
References: <c7aa68e9-e951-6e4b-d950-9f6cd768b4d5@redhat.com>
 <f8cf1bd9-0570-53ab-1492-3e08c4a2ea1c@oracle.com>
 <51f21f82-08d4-eb51-f801-861ef3a11b92@redhat.com>
Message-ID: <53BA3566-FCCD-4E9F-A579-58DB3DB8AEA9@oracle.com>

Hi Andrew, Aleksey,

In general I would recommend sending emails regarding jdk/submit to the ops at openjdk.java.net, so that admins, can take a look and investigate.

My initial investigation showed, that for some reason the notification system did not like your email addresses.
I will keep looking into this to find out what has really happened.

Btw, Aleksey, regarding JDK-8152467, everything has passed.

Best regards,
Stanislav Smirnov

> On Aug 20, 2019, at 4:28 AM, Andrew Dinn <adinn at redhat.com> wrote:
> 
> Hi Stefan,
> 
> Thanks very much for looking into this.
> 
> On 20/08/2019 09:14, Stefan Karlsson wrote:
>> I don't know how to check this, but ...
> 
> ... nevertheless you still have the advantage over me :-)
> 
> Aleksey may be correct that the problem is with notification email
> delivery. There is definitely no notice in my spam folder or inbox. Of
> course, the problem (if any) might be en route rather than at source. I
> would be good to know if others have received notifications in the last
> 24 hours.
> 
>>> In case it helps identify any potential problem the commit was for
>>> branch JDK-8224974-10
>> 
>> ... the run succeeded without failures. The change that it ran against
>> was 8527e8781f87c6fc86e916ca41f4fb562e20c2e3.
> Now, that's the news I wanted to hear. Cheers!
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


From sgehwolf at redhat.com  Tue Aug 20 12:27:04 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 20 Aug 2019 14:27:04 +0200
Subject: JDK-8219997
In-Reply-To: <e56fba51-d119-d642-deb6-f0bcd068eaf2@oracle.com>
References: <666ddb90-bbf6-9254-5d71-a766f9999c4c@redhat.com>
 <e56fba51-d119-d642-deb6-f0bcd068eaf2@oracle.com>
Message-ID: <2ac28beba82d37ae4498301fa76c312f877264ef.camel@redhat.com>

On Tue, 2019-08-20 at 22:16 +1000, David Holmes wrote:
> On 20/08/2019 7:11 pm, Aleksey Shipilev wrote:
> > Hi,
> > 
> > Does anyone know why this bug is confidential?
> >    https://bugs.openjdk.java.net/browse/JDK-8219997
> 
> No reason that I can see. I've made it public.

Thanks, David!

Cheers,
Severin

> > It looks like the innocuous testbug:
> >    https://hg.openjdk.java.net/jdk/jdk/rev/dcaced4cbb83
> > 
> > We would like to have it in the open, so we can tag it for
> > appropriate backports.
> > 


From adinn at redhat.com  Tue Aug 20 12:48:35 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 20 Aug 2019 13:48:35 +0100
Subject: Status of submit server?
In-Reply-To: <53BA3566-FCCD-4E9F-A579-58DB3DB8AEA9@oracle.com>
References: <c7aa68e9-e951-6e4b-d950-9f6cd768b4d5@redhat.com>
 <f8cf1bd9-0570-53ab-1492-3e08c4a2ea1c@oracle.com>
 <51f21f82-08d4-eb51-f801-861ef3a11b92@redhat.com>
 <53BA3566-FCCD-4E9F-A579-58DB3DB8AEA9@oracle.com>
Message-ID: <2938008f-27c8-a2fc-acdd-937a5ec0d049@redhat.com>

On 20/08/2019 13:18, Stanislav Smirnov wrote:
> In general I would recommend sending emails regarding jdk/submit to
> the?ops at openjdk.java.net <mailto:ops at openjdk.java.net>, so that admins,
> can take a look and investigate.

Yes, of course. Thank you for the reminder.

> My initial investigation showed, that for some reason the notification
> system did not like your email addresses.
> I will keep looking into this to find out what has really happened.
Hmm, I wonder if something has inadvertently been changed. In case it
helps, I did receive a notification for a push I made last week (change
set was posted 19th August).

Thanks for the follow-up.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From adinn at redhat.com  Tue Aug 20 12:52:06 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 20 Aug 2019 13:52:06 +0100
Subject: Status of submit server?
In-Reply-To: <2938008f-27c8-a2fc-acdd-937a5ec0d049@redhat.com>
References: <c7aa68e9-e951-6e4b-d950-9f6cd768b4d5@redhat.com>
 <f8cf1bd9-0570-53ab-1492-3e08c4a2ea1c@oracle.com>
 <51f21f82-08d4-eb51-f801-861ef3a11b92@redhat.com>
 <53BA3566-FCCD-4E9F-A579-58DB3DB8AEA9@oracle.com>
 <2938008f-27c8-a2fc-acdd-937a5ec0d049@redhat.com>
Message-ID: <ac847fc5-fe53-c549-3e2e-c896d327244b@redhat.com>

On 20/08/2019 13:48, Andrew Dinn wrote:
> Hmm, I wonder if something has inadvertently been changed. In case it
> helps, I did receive a notification for a push I made last week (change
> set was posted 19th August).

Oops, wrong date. Make that ~12th August!

> Thanks for the follow-up.
regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From shade at redhat.com  Tue Aug 20 13:54:37 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 20 Aug 2019 15:54:37 +0200
Subject: Status of submit server?
In-Reply-To: <53BA3566-FCCD-4E9F-A579-58DB3DB8AEA9@oracle.com>
References: <c7aa68e9-e951-6e4b-d950-9f6cd768b4d5@redhat.com>
 <f8cf1bd9-0570-53ab-1492-3e08c4a2ea1c@oracle.com>
 <51f21f82-08d4-eb51-f801-861ef3a11b92@redhat.com>
 <53BA3566-FCCD-4E9F-A579-58DB3DB8AEA9@oracle.com>
Message-ID: <568eb0e6-dc4b-520e-6e0b-c08259c4eb92@redhat.com>

On 8/20/19 2:18 PM, Stanislav Smirnov wrote:
> My initial investigation showed, that for some reason the notification system did not like your 
> email addresses. I will keep looking into this to find out what has really happened.
That would be nice to resolve, indeed.

> Btw, Aleksey, regarding?JDK-8152467, everything has passed.
Thanks!

-- 
-Aleksey


From shade at redhat.com  Tue Aug 20 13:55:29 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 20 Aug 2019 15:55:29 +0200
Subject: JDK-8219997
In-Reply-To: <e56fba51-d119-d642-deb6-f0bcd068eaf2@oracle.com>
References: <666ddb90-bbf6-9254-5d71-a766f9999c4c@redhat.com>
 <e56fba51-d119-d642-deb6-f0bcd068eaf2@oracle.com>
Message-ID: <a49ffd00-c33b-c5aa-831e-0f21c8bb91df@redhat.com>

On 8/20/19 2:16 PM, David Holmes wrote:
> On 20/08/2019 7:11 pm, Aleksey Shipilev wrote:
>> Does anyone know why this bug is confidential?
>> ?? https://bugs.openjdk.java.net/browse/JDK-8219997
> 
> No reason that I can see. I've made it public.

Thanks!

-- 
-Aleksey


From somkadam76 at gmail.com  Tue Aug 20 15:00:20 2019
From: somkadam76 at gmail.com (Somshekar C Kadam)
Date: Tue, 20 Aug 2019 20:30:20 +0530
Subject: Java Httpurlconnection
Message-ID: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>

Hi Team,

I am newbie to Java.
we have on our environment
Linux kernel 4.9, java 1.8 version using tls 1.2 default


   1. using curl when we give any https link , it returns within 2 seconds
   2. using java program using httpurlconnection class we get 10 seconds or
   more delay.
   3. Even removed some ciphers thought it may take sometime but that is
   not the case.
   4. Trying an alternative to httpurlconnection class apache httpclient,
   having issues compiling and running it, any pointers will help.
   5. Also any pointers or suggestion why we have 10 seconds delay on https
   connection ?
   6. I have tested using oracle java 8 also, same result, also tried
   zulu11 version of java same delay.
   7. Any suggestions would help here thanks in advance

regards
Somshekar
Regards
Somshekar C Kadam
9036660538

From somkadam76 at gmail.com  Tue Aug 20 15:02:13 2019
From: somkadam76 at gmail.com (Somshekar C Kadam)
Date: Tue, 20 Aug 2019 20:32:13 +0530
Subject: Java Httpurlconnection
In-Reply-To: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
References: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
Message-ID: <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>

SOrry forgot to mention

This is being tested on Armv7 board, we see the delay.
But when I run this in intel machine its just takes max 1 to 2 seconds
using sam java program.
So stuck on this.

Regards
Somshekar C Kadam
9036660538


On Tue, Aug 20, 2019 at 8:30 PM Somshekar C Kadam <somkadam76 at gmail.com>
wrote:

> Hi Team,
>
> I am newbie to Java.
> we have on our environment
> Linux kernel 4.9, java 1.8 version using tls 1.2 default
>
>
>    1. using curl when we give any https link , it returns within 2
>    seconds
>    2. using java program using httpurlconnection class we get 10 seconds
>    or more delay.
>    3. Even removed some ciphers thought it may take sometime but that is
>    not the case.
>    4. Trying an alternative to httpurlconnection class apache httpclient,
>    having issues compiling and running it, any pointers will help.
>    5. Also any pointers or suggestion why we have 10 seconds delay on
>    https connection ?
>    6. I have tested using oracle java 8 also, same result, also tried
>    zulu11 version of java same delay.
>    7. Any suggestions would help here thanks in advance
>
> regards
> Somshekar
> Regards
> Somshekar C Kadam
> 9036660538
>

From stanislav.smirnov at oracle.com  Tue Aug 20 19:04:27 2019
From: stanislav.smirnov at oracle.com (Stanislav Smirnov)
Date: Tue, 20 Aug 2019 15:04:27 -0400
Subject: Status of jdk/submit notifications
Message-ID: <CFA2443C-D5CD-4EFE-A1E7-6EB08228C06F@oracle.com>

Hello,

we are experiencing some issues with the internal mailing server.
Because of it email notifications for jdk/submit stopped working.

The system itself is working fine, so you can continue using it.
However in order to check results you will have to either ping somebody from Oracle side,
or send a request to the ops at openjdk.java.net <mailto:ops at openjdk.java.net>.

We apologize for any inconvenience this may have caused.

Best regards,
Stanislav Smirnov






From hohensee at amazon.com  Tue Aug 20 19:19:47 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 20 Aug 2019 19:19:47 +0000
Subject: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <78A602F7-BA4E-4D24-886D-F0096FC77C73@amazon.com>

Vote: yes

?On 8/15/19, 5:13 PM, "jdk-dev on behalf of Ioi Lam" <jdk-dev-bounces at openjdk.java.net on behalf of ioi.lam at oracle.com> wrote:

    I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
    
    Yumin is currently a JDK Project Committer and a member of the HotSpot 
    Group [3]. He has contributed over 50 changesets [1].
    
    Yumin has primarily worked on Hotspot Runtime and Serviceability areas. 
    He is now working on the JWarmup JEP [2] to help improve application 
    peak load time performance. Yumin also worked on AppCDS (Application 
    Class Data Sharing) and made contribution to the feature. He is an 
    active member in the OpenJDK community.
    
    Only current JDK Reviewers [3] are eligible to vote on this nomination. 
    Votes must be cast in the open by replying to this mailing list.
    
    For Three-Vote Consensus voting instructions, see [4].
    
    [1] 
    http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
    [2] http://openjdk.java.net/jeps/8203832
    [3] http://openjdk.java.net/census
    [4] http://openjdk.java.net/projects/#reviewer-vote
    


From david.holmes at oracle.com  Fri Aug 16 00:41:00 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 16 Aug 2019 10:41:00 +1000
Subject: flatMap still prevents short circuiting when using .iterator()
In-Reply-To: <CAJxPRwWYT6j988ufnoPeX=Gqv2eQrqgtv_fmw1t2ao4deCHvRg@mail.gmail.com>
References: <CAJxPRwWYT6j988ufnoPeX=Gqv2eQrqgtv_fmw1t2ao4deCHvRg@mail.gmail.com>
Message-ID: <d6f152f0-4e41-4f5c-00f9-9f00be9981f9@oracle.com>

Re-directing to core-libs-dev

David

On 15/08/2019 7:48 pm, Stephen Buergler wrote:
> Not really sure where to send this.
> flatMap was fixed so that it doesn't prevent short circuiting.
> https://bugs.openjdk.java.net/browse/JDK-8075939
> If you replace the test cases in the ticket with versions that use
> .iterator().next() instead of .findFirst().get() then the problem
> still happens.
> I just tested this with openjdk:14 on docker hub.
> 

From stuart.marks at oracle.com  Wed Aug 21 00:07:56 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 20 Aug 2019 17:07:56 -0700
Subject: [JDK-8210527] NullPointerException in jstack exception rendering
In-Reply-To: <586D7C71-D908-4A7C-A82A-2F731966D409@gmail.com>
References: <586D7C71-D908-4A7C-A82A-2F731966D409@gmail.com>
Message-ID: <55482bf8-359e-f050-d37e-c2485b29fa8c@oracle.com>

The jshell mailing list is kulla-dev at openjdk.java.net. I'm cc'ing that list and 
bcc'ing jdk-dev. (Yes, the name "kulla-dev" is quite opaque. Sorry.)

s'marks

On 8/19/19 1:10 PM, Steven Schlansker wrote:
> Hello jdk-dev, (hopefully this is the best list, I did not see a jshell-dev)
> 
> I spent most of my Friday diagnosing a confusing issue
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8229863
> 
> which turned out to be a duplicate of JDK-8210527
> Unfortunately it's been open most of a year with no progress.
> 
> The fix is seemingly trivial:
> 
> diff -r 31b7274c7b9e src/jdk.jshell/share/classes/jdk/jshell/Eval.java
> --- a/src/jdk.jshell/share/classes/jdk/jshell/Eval.java Fri Aug 09 03:36:59 2019 +0200
> +++ b/src/jdk.jshell/share/classes/jdk/jshell/Eval.java Mon Aug 19 13:06:57 2019 -0700
> @@ -1106,7 +1106,7 @@
>                   Snippet sn = outer.wrapLineToSnippet(wln);
>                   String file = "#" + sn.id();
>                   elems[i] = new StackTraceElement(klass, method, file, line);
> -            } else if (r.getFileName().equals("<none>")) {
> +            } else if ("<none>".equals(r.getFileName())) {
>                   elems[i] = new StackTraceElement(r.getClassName(), r.getMethodName(), null, r.getLineNumber());
>               } else {
>                   elems[i] = r;
> 
> I verified this fix against jdk13 tip.  Before:
> 
> Unexpected exception reading startup: java.lang.NullPointerException
> java.lang.NullPointerException
> 	at jdk.jshell/jdk.jshell.Eval.translateExceptionStack(Eval.java:1109)
> 	at jdk.jshell/jdk.jshell.Eval.asEvalException(Eval.java:907)
> 	at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:888)
> 	at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
> 	at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
> 	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3558)
> 	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1305)
> 	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1203)
> 	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1176)
> 	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.startUpRun(JShellTool.java:1143)
> 	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.resetState(JShellTool.java:1099)
> 	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:933)
> 	at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:254)
> 	at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.run(JShellToolProvider.java:94)
> 	at JshellNpe.main(JshellNpe.java:20)
> 
> After,
> 
> Exception java.lang.IllegalStateException: This helpful exception message is lost
>        at JshellNpe.lambda$2 (JshellNpe.java:27)
>        at $Proxy0.hashCode (Unknown Source)
>        at JshellNpe.init (JshellNpe.java:28)
>        at (#s1:1)
> 
> Much better!
> 
> What can I do to help move this issue forward to resolution?
> 
> thanks,
> Steven
> 

From somkadam76 at gmail.com  Wed Aug 21 06:58:44 2019
From: somkadam76 at gmail.com (Somshekar C Kadam)
Date: Wed, 21 Aug 2019 12:28:44 +0530
Subject: Java Httpurlconnection
In-Reply-To: <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>
References: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
 <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>
Message-ID: <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>

Hi All,
Even if I try this simple httpsurlconnection java program to print content
it takes more than 10 seconds on ARM not in intel. Not sure why please help

HttpsClient.java
========================
import java.net.MalformedURLException;
import java.net.URL;
import java.security.cert.Certificate;
import java.io.*;

import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLPeerUnverifiedException;

public class HttpsClient {

   public static void main(String[] args)
   {
        new HttpsClient().testIt();
   }

   private void testIt(){

      //String https_url = "https://www.google.com/";
      String https_url = "
https://transparencyreport.google.com/https/overview?hl=en";
      URL url;
      try {

    url = new URL(https_url);
    HttpsURLConnection con = (HttpsURLConnection)url.openConnection();

    //dumpl all cert info
    print_https_cert(con);

    //dump all the content
    print_content(con);

      } catch (MalformedURLException e) {
    e.printStackTrace();
      } catch (IOException e) {
    e.printStackTrace();
      }

   }

   private void print_https_cert(HttpsURLConnection con){

    if(con!=null){

      try {

System.out.println("Response Code : " + con.getResponseCode());
System.out.println("Cipher Suite : " + con.getCipherSuite());
System.out.println("\n");

Certificate[] certs = con.getServerCertificates();
for(Certificate cert : certs){
  System.out.println("Cert Type : " + cert.getType());
  System.out.println("Cert Hash Code : " + cert.hashCode());
  System.out.println("Cert Public Key Algorithm : "
                                    + cert.getPublicKey().getAlgorithm());
  System.out.println("Cert Public Key Format : "
                                    + cert.getPublicKey().getFormat());
  System.out.println("\n");
}

} catch (SSLPeerUnverifiedException e) {
e.printStackTrace();
} catch (IOException e){
e.printStackTrace();
}

     }

   }

   private void print_content(HttpsURLConnection con){
if(con!=null){

try {

  System.out.println("****** Content of the URL ********");
  BufferedReader br =
new BufferedReader(
new InputStreamReader(con.getInputStream()));

  String input;

  while ((input = br.readLine()) != null){
     System.out.println(input);
  }
  br.close();

} catch (IOException e) {
  e.printStackTrace();
}

       }

   }

}



======================
Regards
Somshekar C Kadam
9036660538


On Tue, Aug 20, 2019 at 8:32 PM Somshekar C Kadam <somkadam76 at gmail.com>
wrote:

> SOrry forgot to mention
>
> This is being tested on Armv7 board, we see the delay.
> But when I run this in intel machine its just takes max 1 to 2 seconds
> using sam java program.
> So stuck on this.
>
> Regards
> Somshekar C Kadam
> 9036660538
>
>
> On Tue, Aug 20, 2019 at 8:30 PM Somshekar C Kadam <somkadam76 at gmail.com>
> wrote:
>
>> Hi Team,
>>
>> I am newbie to Java.
>> we have on our environment
>> Linux kernel 4.9, java 1.8 version using tls 1.2 default
>>
>>
>>    1. using curl when we give any https link , it returns within 2
>>    seconds
>>    2. using java program using httpurlconnection class we get 10 seconds
>>    or more delay.
>>    3. Even removed some ciphers thought it may take sometime but that is
>>    not the case.
>>    4. Trying an alternative to httpurlconnection class apache
>>    httpclient, having issues compiling and running it, any pointers will help.
>>    5. Also any pointers or suggestion why we have 10 seconds delay on
>>    https connection ?
>>    6. I have tested using oracle java 8 also, same result, also tried
>>    zulu11 version of java same delay.
>>    7. Any suggestions would help here thanks in advance
>>
>> regards
>> Somshekar
>> Regards
>> Somshekar C Kadam
>> 9036660538
>>
>

From david.holmes at oracle.com  Wed Aug 21 07:17:24 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Aug 2019 17:17:24 +1000
Subject: Java Httpurlconnection
In-Reply-To: <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>
References: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
 <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>
 <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>
Message-ID: <d20c468f-7815-b18f-9184-f753a65410cd@oracle.com>

Hi,

Under the assumption that this question might actually involve a 
behavioural difference across different platform implementations of the 
JDK, I'd suggest asking it on the net-dev at openjdk.java.net mailing list.

But be sure the ARM system and Intel system are being compared under the 
same conditions, they have to be on the same network with the same (or 
near enough same) OS and with the same network configuration. A 10s 
delay is very often a DNS timeout.

Cheers,
David

On 21/08/2019 4:58 pm, Somshekar C Kadam wrote:
> Hi All,
> Even if I try this simple httpsurlconnection java program to print content
> it takes more than 10 seconds on ARM not in intel. Not sure why please help
> 
> HttpsClient.java
> ========================
> import java.net.MalformedURLException;
> import java.net.URL;
> import java.security.cert.Certificate;
> import java.io.*;
> 
> import javax.net.ssl.HttpsURLConnection;
> import javax.net.ssl.SSLPeerUnverifiedException;
> 
> public class HttpsClient {
> 
>     public static void main(String[] args)
>     {
>          new HttpsClient().testIt();
>     }
> 
>     private void testIt(){
> 
>        //String https_url = "https://www.google.com/";
>        String https_url = "
> https://transparencyreport.google.com/https/overview?hl=en";
>        URL url;
>        try {
> 
>      url = new URL(https_url);
>      HttpsURLConnection con = (HttpsURLConnection)url.openConnection();
> 
>      //dumpl all cert info
>      print_https_cert(con);
> 
>      //dump all the content
>      print_content(con);
> 
>        } catch (MalformedURLException e) {
>      e.printStackTrace();
>        } catch (IOException e) {
>      e.printStackTrace();
>        }
> 
>     }
> 
>     private void print_https_cert(HttpsURLConnection con){
> 
>      if(con!=null){
> 
>        try {
> 
> System.out.println("Response Code : " + con.getResponseCode());
> System.out.println("Cipher Suite : " + con.getCipherSuite());
> System.out.println("\n");
> 
> Certificate[] certs = con.getServerCertificates();
> for(Certificate cert : certs){
>    System.out.println("Cert Type : " + cert.getType());
>    System.out.println("Cert Hash Code : " + cert.hashCode());
>    System.out.println("Cert Public Key Algorithm : "
>                                      + cert.getPublicKey().getAlgorithm());
>    System.out.println("Cert Public Key Format : "
>                                      + cert.getPublicKey().getFormat());
>    System.out.println("\n");
> }
> 
> } catch (SSLPeerUnverifiedException e) {
> e.printStackTrace();
> } catch (IOException e){
> e.printStackTrace();
> }
> 
>       }
> 
>     }
> 
>     private void print_content(HttpsURLConnection con){
> if(con!=null){
> 
> try {
> 
>    System.out.println("****** Content of the URL ********");
>    BufferedReader br =
> new BufferedReader(
> new InputStreamReader(con.getInputStream()));
> 
>    String input;
> 
>    while ((input = br.readLine()) != null){
>       System.out.println(input);
>    }
>    br.close();
> 
> } catch (IOException e) {
>    e.printStackTrace();
> }
> 
>         }
> 
>     }
> 
> }
> 
> 
> 
> ======================
> Regards
> Somshekar C Kadam
> 9036660538
> 
> 
> On Tue, Aug 20, 2019 at 8:32 PM Somshekar C Kadam <somkadam76 at gmail.com>
> wrote:
> 
>> SOrry forgot to mention
>>
>> This is being tested on Armv7 board, we see the delay.
>> But when I run this in intel machine its just takes max 1 to 2 seconds
>> using sam java program.
>> So stuck on this.
>>
>> Regards
>> Somshekar C Kadam
>> 9036660538
>>
>>
>> On Tue, Aug 20, 2019 at 8:30 PM Somshekar C Kadam <somkadam76 at gmail.com>
>> wrote:
>>
>>> Hi Team,
>>>
>>> I am newbie to Java.
>>> we have on our environment
>>> Linux kernel 4.9, java 1.8 version using tls 1.2 default
>>>
>>>
>>>     1. using curl when we give any https link , it returns within 2
>>>     seconds
>>>     2. using java program using httpurlconnection class we get 10 seconds
>>>     or more delay.
>>>     3. Even removed some ciphers thought it may take sometime but that is
>>>     not the case.
>>>     4. Trying an alternative to httpurlconnection class apache
>>>     httpclient, having issues compiling and running it, any pointers will help.
>>>     5. Also any pointers or suggestion why we have 10 seconds delay on
>>>     https connection ?
>>>     6. I have tested using oracle java 8 also, same result, also tried
>>>     zulu11 version of java same delay.
>>>     7. Any suggestions would help here thanks in advance
>>>
>>> regards
>>> Somshekar
>>> Regards
>>> Somshekar C Kadam
>>> 9036660538
>>>
>>

From somkadam76 at gmail.com  Wed Aug 21 07:44:08 2019
From: somkadam76 at gmail.com (Somshekar C Kadam)
Date: Wed, 21 Aug 2019 13:14:08 +0530
Subject: Java Httpurlconnection
In-Reply-To: <d20c468f-7815-b18f-9184-f753a65410cd@oracle.com>
References: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
 <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>
 <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>
 <d20c468f-7815-b18f-9184-f753a65410cd@oracle.com>
Message-ID: <CALbGK-r7LqwpWEqfpVc5Z_uQjwvgpCaC77bEwW3uWQ35gjgdLw@mail.gmail.com>

Thanks David for reply, and yes its the same environment no change at all.

Regards
Somshekar C Kadam
9036660538


On Wed, Aug 21, 2019 at 12:47 PM David Holmes <david.holmes at oracle.com>
wrote:

> Hi,
>
> Under the assumption that this question might actually involve a
> behavioural difference across different platform implementations of the
> JDK, I'd suggest asking it on the net-dev at openjdk.java.net mailing list.
>
> But be sure the ARM system and Intel system are being compared under the
> same conditions, they have to be on the same network with the same (or
> near enough same) OS and with the same network configuration. A 10s
> delay is very often a DNS timeout.
>
> Cheers,
> David
>
> On 21/08/2019 4:58 pm, Somshekar C Kadam wrote:
> > Hi All,
> > Even if I try this simple httpsurlconnection java program to print
> content
> > it takes more than 10 seconds on ARM not in intel. Not sure why please
> help
> >
> > HttpsClient.java
> > ========================
> > import java.net.MalformedURLException;
> > import java.net.URL;
> > import java.security.cert.Certificate;
> > import java.io.*;
> >
> > import javax.net.ssl.HttpsURLConnection;
> > import javax.net.ssl.SSLPeerUnverifiedException;
> >
> > public class HttpsClient {
> >
> >     public static void main(String[] args)
> >     {
> >          new HttpsClient().testIt();
> >     }
> >
> >     private void testIt(){
> >
> >        //String https_url = "https://www.google.com/";
> >        String https_url = "
> > https://transparencyreport.google.com/https/overview?hl=en";
> >        URL url;
> >        try {
> >
> >      url = new URL(https_url);
> >      HttpsURLConnection con = (HttpsURLConnection)url.openConnection();
> >
> >      //dumpl all cert info
> >      print_https_cert(con);
> >
> >      //dump all the content
> >      print_content(con);
> >
> >        } catch (MalformedURLException e) {
> >      e.printStackTrace();
> >        } catch (IOException e) {
> >      e.printStackTrace();
> >        }
> >
> >     }
> >
> >     private void print_https_cert(HttpsURLConnection con){
> >
> >      if(con!=null){
> >
> >        try {
> >
> > System.out.println("Response Code : " + con.getResponseCode());
> > System.out.println("Cipher Suite : " + con.getCipherSuite());
> > System.out.println("\n");
> >
> > Certificate[] certs = con.getServerCertificates();
> > for(Certificate cert : certs){
> >    System.out.println("Cert Type : " + cert.getType());
> >    System.out.println("Cert Hash Code : " + cert.hashCode());
> >    System.out.println("Cert Public Key Algorithm : "
> >                                      +
> cert.getPublicKey().getAlgorithm());
> >    System.out.println("Cert Public Key Format : "
> >                                      + cert.getPublicKey().getFormat());
> >    System.out.println("\n");
> > }
> >
> > } catch (SSLPeerUnverifiedException e) {
> > e.printStackTrace();
> > } catch (IOException e){
> > e.printStackTrace();
> > }
> >
> >       }
> >
> >     }
> >
> >     private void print_content(HttpsURLConnection con){
> > if(con!=null){
> >
> > try {
> >
> >    System.out.println("****** Content of the URL ********");
> >    BufferedReader br =
> > new BufferedReader(
> > new InputStreamReader(con.getInputStream()));
> >
> >    String input;
> >
> >    while ((input = br.readLine()) != null){
> >       System.out.println(input);
> >    }
> >    br.close();
> >
> > } catch (IOException e) {
> >    e.printStackTrace();
> > }
> >
> >         }
> >
> >     }
> >
> > }
> >
> >
> >
> > ======================
> > Regards
> > Somshekar C Kadam
> > 9036660538
> >
> >
> > On Tue, Aug 20, 2019 at 8:32 PM Somshekar C Kadam <somkadam76 at gmail.com>
> > wrote:
> >
> >> SOrry forgot to mention
> >>
> >> This is being tested on Armv7 board, we see the delay.
> >> But when I run this in intel machine its just takes max 1 to 2 seconds
> >> using sam java program.
> >> So stuck on this.
> >>
> >> Regards
> >> Somshekar C Kadam
> >> 9036660538
> >>
> >>
> >> On Tue, Aug 20, 2019 at 8:30 PM Somshekar C Kadam <somkadam76 at gmail.com
> >
> >> wrote:
> >>
> >>> Hi Team,
> >>>
> >>> I am newbie to Java.
> >>> we have on our environment
> >>> Linux kernel 4.9, java 1.8 version using tls 1.2 default
> >>>
> >>>
> >>>     1. using curl when we give any https link , it returns within 2
> >>>     seconds
> >>>     2. using java program using httpurlconnection class we get 10
> seconds
> >>>     or more delay.
> >>>     3. Even removed some ciphers thought it may take sometime but that
> is
> >>>     not the case.
> >>>     4. Trying an alternative to httpurlconnection class apache
> >>>     httpclient, having issues compiling and running it, any pointers
> will help.
> >>>     5. Also any pointers or suggestion why we have 10 seconds delay on
> >>>     https connection ?
> >>>     6. I have tested using oracle java 8 also, same result, also tried
> >>>     zulu11 version of java same delay.
> >>>     7. Any suggestions would help here thanks in advance
> >>>
> >>> regards
> >>> Somshekar
> >>> Regards
> >>> Somshekar C Kadam
> >>> 9036660538
> >>>
> >>
>

From franta-java at frantovo.cz  Wed Aug 21 08:01:33 2019
From: franta-java at frantovo.cz (=?UTF-8?B?RnJhbnRpxaFlayBLdcSNZXJh?=)
Date: Wed, 21 Aug 2019 10:01:33 +0200
Subject: Java Httpurlconnection
In-Reply-To: <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>
References: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
 <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>
 <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>
Message-ID: <f69e4b27-d765-5932-bac3-b4b5361813fe@frantovo.cz>

Dne 21. 08. 19 v 8:58 Somshekar C Kadam napsal(a):
> Hi All,
> Even if I try this simple httpsurlconnection java program to print content
> it takes more than 10 seconds on ARM not in intel. Not sure why please help

Do you observe any differences between HTTPS and HTTP requests? Is it 
slow only on encrypted connection or also unencrypted? If only encrypted 
connections are slow, it is sometimes caused by lack of entropy in the 
random number generator (RNG). If it is slow even with unencrypted HTTP, 
it might relate to IPv6 or DNS problems.

You can try strace -ttf -o strace.log java ... and look and compare the 
strace.log files. Or run it under the Java debugger e.g. in Netbeans 
(can debug also remotely) and find the step where the 10 seconds are spent.

Franta


From somkadam76 at gmail.com  Wed Aug 21 08:43:01 2019
From: somkadam76 at gmail.com (Somshekar C Kadam)
Date: Wed, 21 Aug 2019 14:13:01 +0530
Subject: Java Httpurlconnection
In-Reply-To: <f69e4b27-d765-5932-bac3-b4b5361813fe@frantovo.cz>
References: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
 <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>
 <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>
 <f69e4b27-d765-5932-bac3-b4b5361813fe@frantovo.cz>
Message-ID: <CALbGK-rO5wNHVc5gnRrfxEEFEWiX9rcEWgFc8Gv_e5mQW1Y1ww@mail.gmail.com>

Hi Frantisek,
With http no issues, there is no delay it happens quickly within 1 ~2
seconds.

When used https see this long delay.
I will look in strace once again and let know thanks

regards
Somshekar
Regards
Somshekar C Kadam
9036660538


On Wed, Aug 21, 2019 at 1:32 PM Franti?ek Ku?era <franta-java at frantovo.cz>
wrote:

> Dne 21. 08. 19 v 8:58 Somshekar C Kadam napsal(a):
> > Hi All,
> > Even if I try this simple httpsurlconnection java program to print
> content
> > it takes more than 10 seconds on ARM not in intel. Not sure why please
> help
>
> Do you observe any differences between HTTPS and HTTP requests? Is it
> slow only on encrypted connection or also unencrypted? If only encrypted
> connections are slow, it is sometimes caused by lack of entropy in the
> random number generator (RNG). If it is slow even with unencrypted HTTP,
> it might relate to IPv6 or DNS problems.
>
> You can try strace -ttf -o strace.log java ... and look and compare the
> strace.log files. Or run it under the Java debugger e.g. in Netbeans
> (can debug also remotely) and find the step where the 10 seconds are spent.
>
> Franta
>
>

From somkadam76 at gmail.com  Wed Aug 21 11:16:45 2019
From: somkadam76 at gmail.com (Somshekar C Kadam)
Date: Wed, 21 Aug 2019 16:46:45 +0530
Subject: Java Httpurlconnection
In-Reply-To: <CALbGK-qDNmKRX2Q-1TrqgaYuGy6W2HhjwVtKrg6=rkf++1AjhQ@mail.gmail.com>
References: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
 <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>
 <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>
 <f69e4b27-d765-5932-bac3-b4b5361813fe@frantovo.cz>
 <CALbGK-qDNmKRX2Q-1TrqgaYuGy6W2HhjwVtKrg6=rkf++1AjhQ@mail.gmail.com>
Message-ID: <CALbGK-rbrOs_1gEdBzkJvJ-baH82FQdcGr-DRP8YiWMp8y_Pdg@mail.gmail.com>

Hi Frantisek.

Thanks for your suggestion

I am seeing  on ARM lot many seconds wasted on this as shown below logs.
Where as in Intel I did not see a single reference, seems that is something
to do with it, need to  look further into it.

============
15033 08:10:27.254816 clock_gettime(CLOCK_MONOTONIC, {4286, 606936331}) = 0
15033 08:10:27.255070 clock_gettime(CLOCK_MONOTONIC, {4286, 607189947}) = 0
15033 08:10:27.255504 clock_gettime(CLOCK_MONOTONIC, {4286, 607662716}) = 0
15033 08:10:27.255924 clock_gettime(CLOCK_MONOTONIC, {4286, 608074100}) = 0
==================================
Regards
Somshekar C Kadam
9036660538


On Wed, Aug 21, 2019 at 2:44 PM Somshekar C Kadam <somkadam76 at gmail.com>
wrote:

> Hi Frantisek,
>
> Thanks for your help, I am going through the log.
> Also attached here, to know your opinion too, that will help.
>
> Regards
> Somshekar C Kadam
> 9036660538
>
>
> On Wed, Aug 21, 2019 at 1:32 PM Franti?ek Ku?era <franta-java at frantovo.cz>
> wrote:
>
>> Dne 21. 08. 19 v 8:58 Somshekar C Kadam napsal(a):
>> > Hi All,
>> > Even if I try this simple httpsurlconnection java program to print
>> content
>> > it takes more than 10 seconds on ARM not in intel. Not sure why please
>> help
>>
>> Do you observe any differences between HTTPS and HTTP requests? Is it
>> slow only on encrypted connection or also unencrypted? If only encrypted
>> connections are slow, it is sometimes caused by lack of entropy in the
>> random number generator (RNG). If it is slow even with unencrypted HTTP,
>> it might relate to IPv6 or DNS problems.
>>
>> You can try strace -ttf -o strace.log java ... and look and compare the
>> strace.log files. Or run it under the Java debugger e.g. in Netbeans
>> (can debug also remotely) and find the step where the 10 seconds are
>> spent.
>>
>> Franta
>>
>>

From fweimer at redhat.com  Wed Aug 21 11:28:06 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 21 Aug 2019 13:28:06 +0200
Subject: Java Httpurlconnection
In-Reply-To: <CALbGK-rbrOs_1gEdBzkJvJ-baH82FQdcGr-DRP8YiWMp8y_Pdg@mail.gmail.com>
 (Somshekar C. Kadam's message of "Wed, 21 Aug 2019 16:46:45 +0530")
References: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
 <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>
 <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>
 <f69e4b27-d765-5932-bac3-b4b5361813fe@frantovo.cz>
 <CALbGK-qDNmKRX2Q-1TrqgaYuGy6W2HhjwVtKrg6=rkf++1AjhQ@mail.gmail.com>
 <CALbGK-rbrOs_1gEdBzkJvJ-baH82FQdcGr-DRP8YiWMp8y_Pdg@mail.gmail.com>
Message-ID: <87r25ehi61.fsf@oldenburg2.str.redhat.com>

* Somshekar C. Kadam:

> I am seeing  on ARM lot many seconds wasted on this as shown below logs.
> Where as in Intel I did not see a single reference, seems that is something
> to do with it, need to  look further into it.
>
> ============
> 15033 08:10:27.254816 clock_gettime(CLOCK_MONOTONIC, {4286, 606936331}) = 0
> 15033 08:10:27.255070 clock_gettime(CLOCK_MONOTONIC, {4286, 607189947}) = 0
> 15033 08:10:27.255504 clock_gettime(CLOCK_MONOTONIC, {4286, 607662716}) = 0
> 15033 08:10:27.255924 clock_gettime(CLOCK_MONOTONIC, {4286, 608074100}) = 0
> ==================================

On x86, there is an clock_gettime implementation in the vDSO, with a
fast path that stays in userspace.  It's much faster than the
implementation based on the system call, and calls do not show up in
strace (because there is no system call).

Maybe you can try to get a backtrace, to determine where the calls are
coming from?  And how long do these calls take individually?  Normally,
a clock_gettime call every 400 microseconds or so shouldn't cause a
drastic slowdown, but if CLOCK_MONOTONIC is particularly slow to access
on this platform, it could be the cause.

Thanks,
Florian

From somkadam76 at gmail.com  Wed Aug 21 13:12:08 2019
From: somkadam76 at gmail.com (Somshekar C Kadam)
Date: Wed, 21 Aug 2019 18:42:08 +0530
Subject: Java Httpurlconnection
In-Reply-To: <87r25ehi61.fsf@oldenburg2.str.redhat.com>
References: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
 <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>
 <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>
 <f69e4b27-d765-5932-bac3-b4b5361813fe@frantovo.cz>
 <CALbGK-qDNmKRX2Q-1TrqgaYuGy6W2HhjwVtKrg6=rkf++1AjhQ@mail.gmail.com>
 <CALbGK-rbrOs_1gEdBzkJvJ-baH82FQdcGr-DRP8YiWMp8y_Pdg@mail.gmail.com>
 <87r25ehi61.fsf@oldenburg2.str.redhat.com>
Message-ID: <CALbGK-rVWs5C+2zf=D3feYL1qS8nZaHqk0pyGSCdMFaYcj3_ng@mail.gmail.com>

Thanks Florian, will look into it, entire log id full of clock gettime not
sure why
Regards
Somshekar C Kadam
9036660538


On Wed, Aug 21, 2019 at 4:58 PM Florian Weimer <fweimer at redhat.com> wrote:

> * Somshekar C. Kadam:
>
> > I am seeing  on ARM lot many seconds wasted on this as shown below logs.
> > Where as in Intel I did not see a single reference, seems that is
> something
> > to do with it, need to  look further into it.
> >
> > ============
> > 15033 08:10:27.254816 clock_gettime(CLOCK_MONOTONIC, {4286, 606936331})
> = 0
> > 15033 08:10:27.255070 clock_gettime(CLOCK_MONOTONIC, {4286, 607189947})
> = 0
> > 15033 08:10:27.255504 clock_gettime(CLOCK_MONOTONIC, {4286, 607662716})
> = 0
> > 15033 08:10:27.255924 clock_gettime(CLOCK_MONOTONIC, {4286, 608074100})
> = 0
> > ==================================
>
> On x86, there is an clock_gettime implementation in the vDSO, with a
> fast path that stays in userspace.  It's much faster than the
> implementation based on the system call, and calls do not show up in
> strace (because there is no system call).
>
> Maybe you can try to get a backtrace, to determine where the calls are
> coming from?  And how long do these calls take individually?  Normally,
> a clock_gettime call every 400 microseconds or so shouldn't cause a
> drastic slowdown, but if CLOCK_MONOTONIC is particularly slow to access
> on this platform, it could be the cause.
>
> Thanks,
> Florian
>

From joe.darcy at oracle.com  Wed Aug 21 17:06:09 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 21 Aug 2019 10:06:09 -0700
Subject: Java Httpurlconnection
In-Reply-To: <CALbGK-rVWs5C+2zf=D3feYL1qS8nZaHqk0pyGSCdMFaYcj3_ng@mail.gmail.com>
References: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
 <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>
 <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>
 <f69e4b27-d765-5932-bac3-b4b5361813fe@frantovo.cz>
 <CALbGK-qDNmKRX2Q-1TrqgaYuGy6W2HhjwVtKrg6=rkf++1AjhQ@mail.gmail.com>
 <CALbGK-rbrOs_1gEdBzkJvJ-baH82FQdcGr-DRP8YiWMp8y_Pdg@mail.gmail.com>
 <87r25ehi61.fsf@oldenburg2.str.redhat.com>
 <CALbGK-rVWs5C+2zf=D3feYL1qS8nZaHqk0pyGSCdMFaYcj3_ng@mail.gmail.com>
Message-ID: <a92860ce-989a-4d00-9d0a-a8a0957d321d@oracle.com>

Note that jdk-dev at openjdk.java.net is a mail alias for "Technical 
discussion related to the JDK Project" with hundreds of subscribers; it 
is *not* a channel for general support on particular JDK issues.

I suggest filing a bug with the JDK provider of interest, 
https://bugreport.java.com/bugreport/ or elsewhere.

Cheers,

-Joe

On 8/21/2019 6:12 AM, Somshekar C Kadam wrote:
> Thanks Florian, will look into it, entire log id full of clock gettime not
> sure why
> Regards
> Somshekar C Kadam
> 9036660538
>
>
> On Wed, Aug 21, 2019 at 4:58 PM Florian Weimer <fweimer at redhat.com> wrote:
>
>> * Somshekar C. Kadam:
>>
>>> I am seeing  on ARM lot many seconds wasted on this as shown below logs.
>>> Where as in Intel I did not see a single reference, seems that is
>> something
>>> to do with it, need to  look further into it.
>>>
>>> ============
>>> 15033 08:10:27.254816 clock_gettime(CLOCK_MONOTONIC, {4286, 606936331})
>> = 0
>>> 15033 08:10:27.255070 clock_gettime(CLOCK_MONOTONIC, {4286, 607189947})
>> = 0
>>> 15033 08:10:27.255504 clock_gettime(CLOCK_MONOTONIC, {4286, 607662716})
>> = 0
>>> 15033 08:10:27.255924 clock_gettime(CLOCK_MONOTONIC, {4286, 608074100})
>> = 0
>>> ==================================
>> On x86, there is an clock_gettime implementation in the vDSO, with a
>> fast path that stays in userspace.  It's much faster than the
>> implementation based on the system call, and calls do not show up in
>> strace (because there is no system call).
>>
>> Maybe you can try to get a backtrace, to determine where the calls are
>> coming from?  And how long do these calls take individually?  Normally,
>> a clock_gettime call every 400 microseconds or so shouldn't cause a
>> drastic slowdown, but if CLOCK_MONOTONIC is particularly slow to access
>> on this platform, it could be the cause.
>>
>> Thanks,
>> Florian
>>

From somkadam76 at gmail.com  Wed Aug 21 09:14:31 2019
From: somkadam76 at gmail.com (Somshekar C Kadam)
Date: Wed, 21 Aug 2019 14:44:31 +0530
Subject: Java Httpurlconnection
In-Reply-To: <f69e4b27-d765-5932-bac3-b4b5361813fe@frantovo.cz>
References: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
 <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>
 <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>
 <f69e4b27-d765-5932-bac3-b4b5361813fe@frantovo.cz>
Message-ID: <CALbGK-qDNmKRX2Q-1TrqgaYuGy6W2HhjwVtKrg6=rkf++1AjhQ@mail.gmail.com>

Hi Frantisek,

Thanks for your help, I am going through the log.
Also attached here, to know your opinion too, that will help.

Regards
Somshekar C Kadam
9036660538


On Wed, Aug 21, 2019 at 1:32 PM Franti?ek Ku?era <franta-java at frantovo.cz>
wrote:

> Dne 21. 08. 19 v 8:58 Somshekar C Kadam napsal(a):
> > Hi All,
> > Even if I try this simple httpsurlconnection java program to print
> content
> > it takes more than 10 seconds on ARM not in intel. Not sure why please
> help
>
> Do you observe any differences between HTTPS and HTTP requests? Is it
> slow only on encrypted connection or also unencrypted? If only encrypted
> connections are slow, it is sometimes caused by lack of entropy in the
> random number generator (RNG). If it is slow even with unencrypted HTTP,
> it might relate to IPv6 or DNS problems.
>
> You can try strace -ttf -o strace.log java ... and look and compare the
> strace.log files. Or run it under the Java debugger e.g. in Netbeans
> (can debug also remotely) and find the step where the 10 seconds are spent.
>
> Franta
>
>

From stevenschlansker at gmail.com  Wed Aug 21 17:29:05 2019
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Wed, 21 Aug 2019 10:29:05 -0700
Subject: [JDK-8210527] NullPointerException in jstack exception rendering
In-Reply-To: <55482bf8-359e-f050-d37e-c2485b29fa8c@oracle.com>
References: <586D7C71-D908-4A7C-A82A-2F731966D409@gmail.com>
 <55482bf8-359e-f050-d37e-c2485b29fa8c@oracle.com>
Message-ID: <3A0EE077-EB65-45D4-8E3D-29EC3E78C6D1@gmail.com>

Thanks Stuart and Martin, I never would have found that list myself :)

PS: Kudos to the JDK team on improving the build process.  Back in JDK 7 days it was a nightmare,
and building JDK 13 was a total breeze in comparison.  This really helps the "hackability" of the 
JDK for outsiders.  Well done!


> On Aug 20, 2019, at 5:07 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> The jshell mailing list is kulla-dev at openjdk.java.net. I'm cc'ing that list and bcc'ing jdk-dev. (Yes, the name "kulla-dev" is quite opaque. Sorry.)
> 
> s'marks
> 
> On 8/19/19 1:10 PM, Steven Schlansker wrote:
>> ...


From somkadam76 at gmail.com  Fri Aug 23 05:16:51 2019
From: somkadam76 at gmail.com (Somshekar C Kadam)
Date: Fri, 23 Aug 2019 10:46:51 +0530
Subject: Java Httpurlconnection
In-Reply-To: <a92860ce-989a-4d00-9d0a-a8a0957d321d@oracle.com>
References: <CALbGK-oAv2TV39F2UZ-jvpQgbbkCT_FVVO6smwGo+3PcCYzHpQ@mail.gmail.com>
 <CALbGK-q94S-=nkQ9Jmx=1z7mi6qBc9CWYTx6AbdwjLs2yEW-dg@mail.gmail.com>
 <CALbGK-p1=qzQqJ9r8m9VMPT=pFgSB5uC0iKSQXPsZk6J-U3dNA@mail.gmail.com>
 <f69e4b27-d765-5932-bac3-b4b5361813fe@frantovo.cz>
 <CALbGK-qDNmKRX2Q-1TrqgaYuGy6W2HhjwVtKrg6=rkf++1AjhQ@mail.gmail.com>
 <CALbGK-rbrOs_1gEdBzkJvJ-baH82FQdcGr-DRP8YiWMp8y_Pdg@mail.gmail.com>
 <87r25ehi61.fsf@oldenburg2.str.redhat.com>
 <CALbGK-rVWs5C+2zf=D3feYL1qS8nZaHqk0pyGSCdMFaYcj3_ng@mail.gmail.com>
 <a92860ce-989a-4d00-9d0a-a8a0957d321d@oracle.com>
Message-ID: <CALbGK-rmVczRtpOxwFgNS0kmSVB1cDZYc5Fc2DSb6FFAD0nsRA@mail.gmail.com>

Sure Joe will do that, sorry creating traffic on this mailing list.
In case anybody has pointers please mail directly, thanks in advance

Regards
Somshekar C Kadam
9036660538


On Wed, Aug 21, 2019 at 10:36 PM Joe Darcy <joe.darcy at oracle.com> wrote:

> Note that jdk-dev at openjdk.java.net is a mail alias for "Technical
> discussion related to the JDK Project" with hundreds of subscribers; it
> is *not* a channel for general support on particular JDK issues.
>
> I suggest filing a bug with the JDK provider of interest,
> https://bugreport.java.com/bugreport/ or elsewhere.
>
> Cheers,
>
> -Joe
>
> On 8/21/2019 6:12 AM, Somshekar C Kadam wrote:
> > Thanks Florian, will look into it, entire log id full of clock gettime
> not
> > sure why
> > Regards
> > Somshekar C Kadam
> > 9036660538
> >
> >
> > On Wed, Aug 21, 2019 at 4:58 PM Florian Weimer <fweimer at redhat.com>
> wrote:
> >
> >> * Somshekar C. Kadam:
> >>
> >>> I am seeing  on ARM lot many seconds wasted on this as shown below
> logs.
> >>> Where as in Intel I did not see a single reference, seems that is
> >> something
> >>> to do with it, need to  look further into it.
> >>>
> >>> ============
> >>> 15033 08:10:27.254816 clock_gettime(CLOCK_MONOTONIC, {4286, 606936331})
> >> = 0
> >>> 15033 08:10:27.255070 clock_gettime(CLOCK_MONOTONIC, {4286, 607189947})
> >> = 0
> >>> 15033 08:10:27.255504 clock_gettime(CLOCK_MONOTONIC, {4286, 607662716})
> >> = 0
> >>> 15033 08:10:27.255924 clock_gettime(CLOCK_MONOTONIC, {4286, 608074100})
> >> = 0
> >>> ==================================
> >> On x86, there is an clock_gettime implementation in the vDSO, with a
> >> fast path that stays in userspace.  It's much faster than the
> >> implementation based on the system call, and calls do not show up in
> >> strace (because there is no system call).
> >>
> >> Maybe you can try to get a backtrace, to determine where the calls are
> >> coming from?  And how long do these calls take individually?  Normally,
> >> a clock_gettime call every 400 microseconds or so shouldn't cause a
> >> drastic slowdown, but if CLOCK_MONOTONIC is particularly slow to access
> >> on this platform, it could be the cause.
> >>
> >> Thanks,
> >> Florian
> >>
>

From some-java-user-99206970363698485155 at vodafonemail.de  Fri Aug 23 21:04:35 2019
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Fri, 23 Aug 2019 23:04:35 +0200 (CEST)
Subject: HotJava 1.0 alpha2
Message-ID: <384811677.180985.1566594275746@mail.vodafone.de>

Hello,
it appears HotJava 1.0 alpha2 is available under [0]. This is to my knowledge the oldest publicly 
available Java version. This version is also quite interesting because:
- According to [1] it is the first version after the "O.A.K" -> "Java" rename
- Not all packages start with `java` yet, see [2]
- Its class files use major version 45, minor version 2; back then the class file format was 
slightly different and the JDK has still code for compatibility with these old class files ([3])
- It includes a pretty great picture of the HotJava team ([4])

Sadly discovering all of its files is quite cumbersome, and maybe even impossible (many of them 
are not linked).
I hoped that you (the JDK team) is interested in these files as well and could contact MIT. I 
assume you as official representatives will be more successful than some random guy like me (I 
have not tried yet).
It would be really awesome if all these files were publicly available so people can understand 
the history of Java and the JDK better and maybe even toy with this old version (it appears it 
even includes `javac`[5]!).

Let me know what you think about this. And sorry for this rather off-topic mail on this mailing 
list.

Kind regards

---

[0] http://www.mit.edu/afs.new/sipb/user/marc/hotjava/
Though prefer browsing the archived version (link below), who knows what MIT does when they 
notice a sudden increase in requests to a particular site
https://web.archive.org/web/20190822201611/http://www.mit.edu/afs.new/sipb/user/marc/hotjava/

[1] https://web.archive.org/web/20190822201108/http://www.mit.edu/afs.new/sipb/user/marc/hotjava/doc/changes/changes.html
[2] https://web.archive.org/web/20190822201108/http://www.mit.edu/afs.new/sipb/user/marc/hotjava/doc/api/packages.html
[3] https://github.com/openjdk/jdk/blob/e98ba531a28234b09e3a8a0319a6322a291425a2/src/hotspot/share/classfile/classFileParser.cpp#L2451
[4] https://web.archive.org/web/20190822201619/http://www.mit.edu/afs.new/sipb/user/marc/hotjava/doc/people.html
[5] https://web.archive.org/web/20190822231416/http://www.mit.edu/afs.new/sipb/user/marc/hotjava/bin/sun4/javac

From stanislav.smirnov at oracle.com  Fri Aug 23 21:15:25 2019
From: stanislav.smirnov at oracle.com (Stanislav Smirnov)
Date: Fri, 23 Aug 2019 17:15:25 -0400
Subject: Status of jdk/submit notifications
In-Reply-To: <CFA2443C-D5CD-4EFE-A1E7-6EB08228C06F@oracle.com>
References: <CFA2443C-D5CD-4EFE-A1E7-6EB08228C06F@oracle.com>
Message-ID: <6284C427-3112-406B-9BC1-8CAF1F3B9399@oracle.com>

Hello,

the notification service for jdk/submit is back online.
If you run into any issues please reach out to ops at openjdk.java.net.

Best regards,
Stanislav Smirnov

> On Aug 20, 2019, at 3:04 PM, Stanislav Smirnov <stanislav.smirnov at oracle.com> wrote:
> 
> Hello,
> 
> we are experiencing some issues with the internal mailing server.
> Because of it email notifications for jdk/submit stopped working.
> 
> The system itself is working fine, so you can continue using it.
> However in order to check results you will have to either ping somebody from Oracle side,
> or send a request to the ops at openjdk.java.net <mailto:ops at openjdk.java.net>.
> 
> We apologize for any inconvenience this may have caused.
> 
> Best regards,
> Stanislav Smirnov
> 
> 
> 
> 
> 


From dms at samersoff.net  Sat Aug 24 13:39:16 2019
From: dms at samersoff.net (Dmitry Samersoff)
Date: Sat, 24 Aug 2019 16:39:16 +0300
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <db60e184-8667-fff2-4932-c74e89682e40@samersoff.net>

Vote: yes

On 16.08.2019 3:09, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
> 
> Yumin is currently a JDK Project Committer and a member of the HotSpot
> Group [3]. He has contributed over 50 changesets [1].
> 
> Yumin has primarily worked on Hotspot Runtime and Serviceability areas.
> He is now working on the JWarmup JEP [2] to help improve application
> peak load time performance. Yumin also worked on AppCDS (Application
> Class Data Sharing) and made contribution to the feature. He is an
> active member in the OpenJDK community.
> 
> Only current JDK Reviewers [3] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
> 
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote


From andrey.petushkov at gmail.com  Fri Aug 23 17:28:02 2019
From: andrey.petushkov at gmail.com (Andrey Petushkov)
Date: Fri, 23 Aug 2019 20:28:02 +0300
Subject: RFC: DMH lambda form arguments by jlink
Message-ID: <CADV+1Jp0R+q3bKgwH-OhQ3mf7uuR=ArsVfA2riCuJi5NobJbVQ@mail.gmail.com>

Dear JDK developers,

(I'm apologising if posted to wrong alias, please forward as appropriate)

The question is about lambda form cache, created by jlink. More precisely
by jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java.
It appears to me that it has a bug in set of signatures, specifically in
attempt to create LF for invocation of invokevirtual type with signature of
"L_L" [1]. According to documentation [2] and supported by the code the
arguments to lambda form must be the arguments of the target method
prepended by DMH itself. Hence the invokevirtual linkage should always be
supplied with at least two oop arguments coming first (DMH and receiver)

If I'm correct this bug is totally harmless, since such lambda form
although buggy (the native wrapper for respective MethodHandle intrinsic
have register clash between receiver (receiver_reg) and MemberName
(member_reg) at [3]) it will never be actually used, because the actual MH
invoke will not have such signature. But for the sake of consistency I'd
rather remove the signature in question.

The problem is actually found by jtreg tests on aarch32 platform [4]
(please don't confuse with arm port) where it happen to exist assert
checking for mentioned register clash [5]

Will be happy if someone could confirm if this is indeed correct
description of what's happening or point to mistake in analysis, as
appropriate

Thanks,
Andrey

[1]
http://hg.openjdk.java.net/jdk/jdk/file/00bf1e66de11/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java#l151
[2] https://wiki.openjdk.java.net/display/HotSpot/Direct+method+handles
[3]
http://hg.openjdk.java.net/jdk/jdk/file/00bf1e66de11/src/hotspot/cpu/x86/methodHandles_x86.cpp#l293
[4]
https://mail.openjdk.java.net/pipermail/aarch32-port-dev/2018-September/001093.html
[5]
http://cr.openjdk.java.net/~apetushkov/aarch32jdk11%2b28/src/hotspot/cpu/aarch32/methodHandles_aarch32.cpp.html
line
269

From claes.redestad at oracle.com  Sun Aug 25 19:45:55 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sun, 25 Aug 2019 21:45:55 +0200
Subject: RFC: DMH lambda form arguments by jlink
In-Reply-To: <CADV+1Jp0R+q3bKgwH-OhQ3mf7uuR=ArsVfA2riCuJi5NobJbVQ@mail.gmail.com>
References: <CADV+1Jp0R+q3bKgwH-OhQ3mf7uuR=ArsVfA2riCuJi5NobJbVQ@mail.gmail.com>
Message-ID: <cd39832d-13bf-3a61-5711-11af4e4c203c@oracle.com>

(bcc jdk-dev, add core-libs-dev)

Hi Andrey,

I think you might be right that L_L of invoke virtual is non-sensical
and should be removed. I vaguely recall that it at one point have been
coded so that the receiver was implied for these forms when translating.

Also worth noting that the intent was to remove the hardcoded "default"
signatures as the technique to record the set of LFs generated by
typical applications matured. I think we might be at that point now, and
should evaluate if all these "defaults" in GenerateJLIClassesPlugin can
be removed.

Thanks!

/Claes

On 2019-08-23 19:28, Andrey Petushkov wrote:
> Dear JDK developers,
> 
> (I'm apologising if posted to wrong alias, please forward as appropriate)
> 
> The question is about lambda form cache, created by jlink. More precisely
> by jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java.
> It appears to me that it has a bug in set of signatures, specifically in
> attempt to create LF for invocation of invokevirtual type with signature of
> "L_L" [1]. According to documentation [2] and supported by the code the
> arguments to lambda form must be the arguments of the target method
> prepended by DMH itself. Hence the invokevirtual linkage should always be
> supplied with at least two oop arguments coming first (DMH and receiver)
> 
> If I'm correct this bug is totally harmless, since such lambda form
> although buggy (the native wrapper for respective MethodHandle intrinsic
> have register clash between receiver (receiver_reg) and MemberName
> (member_reg) at [3]) it will never be actually used, because the actual MH
> invoke will not have such signature. But for the sake of consistency I'd
> rather remove the signature in question.
> 
> The problem is actually found by jtreg tests on aarch32 platform [4]
> (please don't confuse with arm port) where it happen to exist assert
> checking for mentioned register clash [5]
> 
> Will be happy if someone could confirm if this is indeed correct
> description of what's happening or point to mistake in analysis, as
> appropriate
> 
> Thanks,
> Andrey
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/file/00bf1e66de11/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java#l151
> [2] https://wiki.openjdk.java.net/display/HotSpot/Direct+method+handles
> [3]
> http://hg.openjdk.java.net/jdk/jdk/file/00bf1e66de11/src/hotspot/cpu/x86/methodHandles_x86.cpp#l293
> [4]
> https://mail.openjdk.java.net/pipermail/aarch32-port-dev/2018-September/001093.html
> [5]
> http://cr.openjdk.java.net/~apetushkov/aarch32jdk11%2b28/src/hotspot/cpu/aarch32/methodHandles_aarch32.cpp.html
> line
> 269
> 

From christoph.langer at sap.com  Mon Aug 26 06:27:32 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 26 Aug 2019 06:27:32 +0000
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <AM6PR02MB519267D6C5582787C27D1DD18AA10@AM6PR02MB5192.eurprd02.prod.outlook.com>

Vote: yes

Cheers,
Christoph

> -----Original Message-----
> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of Ioi Lam
> Sent: Freitag, 16. August 2019 02:10
> To: jdk-dev at openjdk.java.net
> Subject: CFV: New JDK Reviewer: Yumin Qi
> 
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
> 
> Yumin is currently a JDK Project Committer and a member of the HotSpot
> Group [3]. He has contributed over 50 changesets [1].
> 
> Yumin has primarily worked on Hotspot Runtime and Serviceability areas.
> He is now working on the JWarmup JEP [2] to help improve application
> peak load time performance. Yumin also worked on AppCDS (Application
> Class Data Sharing) and made contribution to the feature. He is an
> active member in the OpenJDK community.
> 
> Only current JDK Reviewers [3] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi
> %29+and+not+merge%28%29
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote

From ioi.lam at oracle.com  Mon Aug 26 16:39:15 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 26 Aug 2019 09:39:15 -0700
Subject: CFV: New JDK Reviewer: Yumin Qi
In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com>
Message-ID: <dc15fa2e-aeb4-65c1-9011-f6e25e54c023@oracle.com>

Reminder:

The duration for this vote (sorry I forgot to mention that in my 
original e-mail) is two weeks. The voting deadline is Aug/29/2019.

Thanks
- Ioi

On 8/15/19 5:09 PM, Ioi Lam wrote:
> I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer.
>
> Yumin is currently a JDK Project Committer and a member of the HotSpot 
> Group [3]. He has contributed over 50 changesets [1].
>
> Yumin has primarily worked on Hotspot Runtime and Serviceability 
> areas. He is now working on the JWarmup JEP [2] to help improve 
> application peak load time performance. Yumin also worked on AppCDS 
> (Application Class Data Sharing) and made contribution to the feature. 
> He is an active member in the OpenJDK community.
>
> Only current JDK Reviewers [3] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29
> [2] http://openjdk.java.net/jeps/8203832
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote


From robert.field at oracle.com  Tue Aug 27 01:14:42 2019
From: robert.field at oracle.com (Robert Field)
Date: Mon, 26 Aug 2019 18:14:42 -0700
Subject: [JDK-8210527] NullPointerException in jstack exception rendering
In-Reply-To: <55482bf8-359e-f050-d37e-c2485b29fa8c@oracle.com>
References: <586D7C71-D908-4A7C-A82A-2F731966D409@gmail.com>
 <55482bf8-359e-f050-d37e-c2485b29fa8c@oracle.com>
Message-ID: <37a72c2e-30cb-a4dc-6b33-d5682b66b856@oracle.com>

Fix out for review.

-Robert


On 8/20/19 5:07 PM, Stuart Marks wrote:
> The jshell mailing list is kulla-dev at openjdk.java.net. I'm cc'ing that 
> list and bcc'ing jdk-dev. (Yes, the name "kulla-dev" is quite opaque. 
> Sorry.)
>
> s'marks
>
> On 8/19/19 1:10 PM, Steven Schlansker wrote:
>> Hello jdk-dev, (hopefully this is the best list, I did not see a 
>> jshell-dev)
>>
>> I spent most of my Friday diagnosing a confusing issue
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8229863
>>
>> which turned out to be a duplicate of JDK-8210527
>> Unfortunately it's been open most of a year with no progress.
>>
>> The fix is seemingly trivial:
>>
>> diff -r 31b7274c7b9e src/jdk.jshell/share/classes/jdk/jshell/Eval.java
>> --- a/src/jdk.jshell/share/classes/jdk/jshell/Eval.java Fri Aug 09 
>> 03:36:59 2019 +0200
>> +++ b/src/jdk.jshell/share/classes/jdk/jshell/Eval.java Mon Aug 19 
>> 13:06:57 2019 -0700
>> @@ -1106,7 +1106,7 @@
>> ????????????????? Snippet sn = outer.wrapLineToSnippet(wln);
>> ????????????????? String file = "#" + sn.id();
>> ????????????????? elems[i] = new StackTraceElement(klass, method, 
>> file, line);
>> -??????????? } else if (r.getFileName().equals("<none>")) {
>> +??????????? } else if ("<none>".equals(r.getFileName())) {
>> ????????????????? elems[i] = new StackTraceElement(r.getClassName(), 
>> r.getMethodName(), null, r.getLineNumber());
>> ????????????? } else {
>> ????????????????? elems[i] = r;
>>
>> I verified this fix against jdk13 tip.? Before:
>>
>> Unexpected exception reading startup: java.lang.NullPointerException
>> java.lang.NullPointerException
>> ????at 
>> jdk.jshell/jdk.jshell.Eval.translateExceptionStack(Eval.java:1109)
>> ????at jdk.jshell/jdk.jshell.Eval.asEvalException(Eval.java:907)
>> ????at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:888)
>> ????at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
>> ????at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>> ????at 
>> jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3558)
>> ????at 
>> jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1305)
>> ????at 
>> jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1203)
>> ????at 
>> jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1176)
>> ????at 
>> jdk.jshell/jdk.internal.jshell.tool.JShellTool.startUpRun(JShellTool.java:1143)
>> ????at 
>> jdk.jshell/jdk.internal.jshell.tool.JShellTool.resetState(JShellTool.java:1099)
>> ????at 
>> jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:933)
>> ????at 
>> jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:254)
>> ????at 
>> jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.run(JShellToolProvider.java:94)
>> ????at JshellNpe.main(JshellNpe.java:20)
>>
>> After,
>>
>> Exception java.lang.IllegalStateException: This helpful exception 
>> message is lost
>> ?????? at JshellNpe.lambda$2 (JshellNpe.java:27)
>> ?????? at $Proxy0.hashCode (Unknown Source)
>> ?????? at JshellNpe.init (JshellNpe.java:28)
>> ?????? at (#s1:1)
>>
>> Much better!
>>
>> What can I do to help move this issue forward to resolution?
>>
>> thanks,
>> Steven
>>