From sean.coffey at oracle.com  Sun Nov  1 07:43:05 2020
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Sun, 01 Nov 2020 07:43:05 +0000
Subject: General Availability version?
In-Reply-To: <DB7P101MB02986640AC3417C1C123A66198200@DB7P101MB0298.NAMP101.PROD.OUTLOOK.COM>
Message-ID: <202011010743.0A17h9gP032717@userv0121.oracle.com>

GA snapshots are now tagged in the src repository with a 'ga' type tag. Looks like b36.
https://hg.openjdk.java.net/jdk/jdk15/tagsRegards,?Sean.
-------- Original message --------From: "Cane, Paul C (GE Digital)" <paul.cane at ge.com> Date: 31/10/2020  23:54  (GMT+00:00) To: jdk-dev at openjdk.java.net Subject: General Availability version? Can you confirm the Build number of the OpenJDK 15 General Availability release? Alternatively if there is another forum for this please send me a link.Thanks

From thomas.stuefe at gmail.com  Mon Nov  2 07:40:25 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 2 Nov 2020 08:40:25 +0100
Subject: SIgnal chaining, JVM_handle_(linux|bsd|aix)_signal,
 and backward compatibility
Message-ID: <CAA-vtUx9126nA-MHA6+WjOLmGr=g7CTnOQE5vuM9Gjy8LQdSyA@mail.gmail.com>

Hi,

While working on some signal handler fixes and cleanups ([1]), I noticed
that we export JVM_handle_(linux|bsd)_signal() on all POSIX platforms.

I wondered why we do this. See also my first question at runtime-dev [2] -
the initial reaction was "probably no reason anymore".

But then, I see a carefully crafted comment in [3]:

<quote>
// This routine may be used by user applications as a "hook" to catch
signals.
// The user-defined signal handler must pass unrecognized signals to this
// routine
...
</quote>

and I also found some bug reports [4], [5], from 2001 and 2004:
JDK-4864136 : "JVM_handle_linux_signal is private in 1.4.2-beta"
JDK-4408646 : "JVM_handle_solaris_signal must be a global function"

So, to me this looks like JVM_handle_xxx_signals() was an official, or at
least deliberate, interface for foreign code to interact with our signal
handling. Specifically, this reads like a third party could install its
signal handlers over ours, and as long as it queried our signal handler
first by calling JVM_handle_xxx_signal(), we still could coexist with it.

But now we have signal chaining [6], which achieves the same by preloading
the libjsig library. Which some consider to be ewww [7] :-), but still
seems to me like the official solution to that problem. Using signal
chaining there would be no need to manually call JVM_handle_xxx_signal()
from outside since the interposed sigaction() in libjsig would take care of
all this stuff automatically.

My question is:
- if JVM_handle_xxx_signal() is (had been?) an official interface, should
there not be some official documentation and regression tests? Was there? I
could not find anything.
- if it is not an official interface, would it be okay to lay it to rest?
  - Pro: it is made obsolete by signal chaining, and removing it would
reduce complexity of signal handling somewhat
  - Con: applications may exist out there which use that interface, and I'd
hate to break them. We give customers enough reasons to cling to old JDK
versions as it is.
     Also, arguably, this interface is useful. Not everyone likes
preloading libjsig, and the signal chaining mechanism is also a whole lot
more fragile.

However, if we let it live on, should we not document and test it?

I am really interested in the history of this. Was this just a solution for
a single customer?

Thanks, Thomas


[1] https://bugs.openjdk.java.net/browse/JDK-8255711
[2]
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-October/043145.html
[3]
https://github.com/openjdk/jdk/blob/64feeab70af61a52ffe4c64df87a33c16754de18/src/hotspot/os/posix/signals_posix.cpp#L411
[4] https://bugs.openjdk.java.net/browse/JDK-4864136
[5] https://bugs.openjdk.java.net/browse/JDK-4408646
[6]
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
[7] https://mail.openjdk.java.net/pipermail/discuss/2019-April/005042.html

From david.holmes at oracle.com  Tue Nov  3 03:27:04 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Nov 2020 13:27:04 +1000
Subject: SIgnal chaining, JVM_handle_(linux|bsd|aix)_signal, and backward
 compatibility
In-Reply-To: <CAA-vtUx9126nA-MHA6+WjOLmGr=g7CTnOQE5vuM9Gjy8LQdSyA@mail.gmail.com>
References: <CAA-vtUx9126nA-MHA6+WjOLmGr=g7CTnOQE5vuM9Gjy8LQdSyA@mail.gmail.com>
Message-ID: <5175268c-c559-cf98-869e-eb6bd25397e7@oracle.com>

Hi Thomas,

On 2/11/2020 5:40 pm, Thomas St?fe wrote:
> Hi,
> 
> While working on some signal handler fixes and cleanups ([1]), I noticed
> that we export JVM_handle_(linux|bsd)_signal() on all POSIX platforms.
> 
> I wondered why we do this. See also my first question at runtime-dev [2] -
> the initial reaction was "probably no reason anymore".
> 
> But then, I see a carefully crafted comment in [3]:
> 
> <quote>
> // This routine may be used by user applications as a "hook" to catch
> signals.
> // The user-defined signal handler must pass unrecognized signals to this
> // routine
> ...
> </quote>
> 
> and I also found some bug reports [4], [5], from 2001 and 2004:
> JDK-4864136 : "JVM_handle_linux_signal is private in 1.4.2-beta"
> JDK-4408646 : "JVM_handle_solaris_signal must be a global function"
> 
> So, to me this looks like JVM_handle_xxx_signals() was an official, or at
> least deliberate, interface for foreign code to interact with our signal
> handling. Specifically, this reads like a third party could install its
> signal handlers over ours, and as long as it queried our signal handler
> first by calling JVM_handle_xxx_signal(), we still could coexist with it.

Did you see this comment:

https://bugs.openjdk.java.net/browse/JDK-4361067?focusedCommentId=12425956&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12425956

This is tied to AllowUserSignalHandlers so we'd have to go through the 
deprecation process to make any changes in this area.

> But now we have signal chaining [6], which achieves the same by preloading
> the libjsig library. Which some consider to be ewww [7] :-), but still
> seems to me like the official solution to that problem. Using signal
> chaining there would be no need to manually call JVM_handle_xxx_signal()
> from outside since the interposed sigaction() in libjsig would take care of
> all this stuff automatically.

Aren't the two mechanisms complementary in that they work in opposite 
ways? Signal chaining keeps the VM in control and allows it to call 
application handlers.  AllowUserSignalHandlers keeps the app in control 
and requires it to call VM handlers.

> My question is:
> - if JVM_handle_xxx_signal() is (had been?) an official interface, should
> there not be some official documentation and regression tests? Was there? I
> could not find anything.
> - if it is not an official interface, would it be okay to lay it to rest?
>    - Pro: it is made obsolete by signal chaining, and removing it would
> reduce complexity of signal handling somewhat
>    - Con: applications may exist out there which use that interface, and I'd
> hate to break them. We give customers enough reasons to cling to old JDK
> versions as it is.
>       Also, arguably, this interface is useful. Not everyone likes
> preloading libjsig, and the signal chaining mechanism is also a whole lot
> more fragile.
> 
> However, if we let it live on, should we not document and test it?

It is not well documented that is for sure.

Not sure about testing ... I tend to see this more a "best effort" 
mechanism. If someone reports it stops working, or doesn't work, then 
we'll make a best effort to fix it.

> I am really interested in the history of this. Was this just a solution for
> a single customer?

Not sure of specific details but it was for hosting the VM in native 
applications that already did their own signal management.

Cheers,
David

> 
> Thanks, Thomas
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8255711
> [2]
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-October/043145.html
> [3]
> https://github.com/openjdk/jdk/blob/64feeab70af61a52ffe4c64df87a33c16754de18/src/hotspot/os/posix/signals_posix.cpp#L411
> [4] https://bugs.openjdk.java.net/browse/JDK-4864136
> [5] https://bugs.openjdk.java.net/browse/JDK-4408646
> [6]
> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
> [7] https://mail.openjdk.java.net/pipermail/discuss/2019-April/005042.html
> 

From thomas.stuefe at gmail.com  Tue Nov  3 05:42:19 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 3 Nov 2020 06:42:19 +0100
Subject: SIgnal chaining, JVM_handle_(linux|bsd|aix)_signal,
 and backward compatibility
In-Reply-To: <5175268c-c559-cf98-869e-eb6bd25397e7@oracle.com>
References: <CAA-vtUx9126nA-MHA6+WjOLmGr=g7CTnOQE5vuM9Gjy8LQdSyA@mail.gmail.com>
 <5175268c-c559-cf98-869e-eb6bd25397e7@oracle.com>
Message-ID: <CAA-vtUzX+mMvW16s6GK8=DYuHYQNCKA9JH=RmkXh6w=9AoCXJg@mail.gmail.com>

Hi David,

On Tue, Nov 3, 2020 at 4:27 AM David Holmes <david.holmes at oracle.com> wrote:

> Hi Thomas,
>
> On 2/11/2020 5:40 pm, Thomas St?fe wrote:
> > Hi,
> >
> > While working on some signal handler fixes and cleanups ([1]), I noticed
> > that we export JVM_handle_(linux|bsd)_signal() on all POSIX platforms.
> >
> > I wondered why we do this. See also my first question at runtime-dev [2]
> -
> > the initial reaction was "probably no reason anymore".
> >
> > But then, I see a carefully crafted comment in [3]:
> >
> > <quote>
> > // This routine may be used by user applications as a "hook" to catch
> > signals.
> > // The user-defined signal handler must pass unrecognized signals to this
> > // routine
> > ...
> > </quote>
> >
> > and I also found some bug reports [4], [5], from 2001 and 2004:
> > JDK-4864136 : "JVM_handle_linux_signal is private in 1.4.2-beta"
> > JDK-4408646 : "JVM_handle_solaris_signal must be a global function"
> >
> > So, to me this looks like JVM_handle_xxx_signals() was an official, or at
> > least deliberate, interface for foreign code to interact with our signal
> > handling. Specifically, this reads like a third party could install its
> > signal handlers over ours, and as long as it queried our signal handler
> > first by calling JVM_handle_xxx_signal(), we still could coexist with it.
>
> Did you see this comment:
>
>
> https://bugs.openjdk.java.net/browse/JDK-4361067?focusedCommentId=12425956&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12425956
>
> This is tied to AllowUserSignalHandlers so we'd have to go through the
> deprecation process to make any changes in this area.
>
>
Excellent point. Thanks for digging that up. Would love to know who wrote
this code + comment.

(Note that I believe this comment uses the term "signal chaining" to
describe a general concept, not the solution implemented in hotspot today
via the UseSignalChaining + libjsig).

Looked at this and a cursory glance through github sources shows that this
flag is used quite a lot, and I think it is useful too (I remember Florian
Weimers question about it here:
https://mail.openjdk.java.net/pipermail/discuss/2019-April/005046.html -
and this is exactly the answer, this would be the alternative).

But man, this raises so many questions. I see that AllowUserSignalHandlers
had been implemented by just refusing to install the central hotspot signal
handler. But it's not honored for the installation of the SR handler, nor
for anything which gets installed via os::signal(). So we have bitrot right
there already. Then, it never can have worked on AIX since we have a day
zero bug in our port. And so on...


> > But now we have signal chaining [6], which achieves the same by
> preloading
> > the libjsig library. Which some consider to be ewww [7] :-), but still
> > seems to me like the official solution to that problem. Using signal
> > chaining there would be no need to manually call JVM_handle_xxx_signal()
> > from outside since the interposed sigaction() in libjsig would take care
> of
> > all this stuff automatically.
>
> Aren't the two mechanisms complementary in that they work in opposite
> ways? Signal chaining keeps the VM in control and allows it to call
> application handlers.  AllowUserSignalHandlers keeps the app in control
> and requires it to call VM handlers.
>

I don't believe so. I do not have the means to check it, but would not be
surprised if signal chaining was actually the later invention.

We have three mechanisms:
A) AllowUserSignalHandlers, which just refuses to install signal handlers
(thereby effectively disabling UseSignalChaining), but user handler needs
to call our handler
B) UseSignalChaining, which handles the case where we come after the user
handler - we install our handlers, but remember the user handler and later
invoke it
C) libjsig interposition, which handles the case where the user handler
gets installed over our handler - libjsig prevents this and we end up with
the same signal handler chain as in (B)

(B) and (C) (together termed "signal chaining" now) are a complete
replacement for (A). (A) is somewhat simpler, especially with the
interposition stuff, and gives the user handler more control, since it can
decide to handle signals before we get to see them. Whether or not that's
wise is another thing.

Very probably (A) should not be used together with (C) or (B).


> > My question is:
> > - if JVM_handle_xxx_signal() is (had been?) an official interface, should
> > there not be some official documentation and regression tests? Was
> there? I
> > could not find anything.
> > - if it is not an official interface, would it be okay to lay it to rest?
> >    - Pro: it is made obsolete by signal chaining, and removing it would
> > reduce complexity of signal handling somewhat
> >    - Con: applications may exist out there which use that interface, and
> I'd
> > hate to break them. We give customers enough reasons to cling to old JDK
> > versions as it is.
> >       Also, arguably, this interface is useful. Not everyone likes
> > preloading libjsig, and the signal chaining mechanism is also a whole lot
> > more fragile.
> >
> > However, if we let it live on, should we not document and test it?
>
> It is not well documented that is for sure.
>
> Not sure about testing ... I tend to see this more a "best effort"
> mechanism. If someone reports it stops working, or doesn't work, then
> we'll make a best effort to fix it.
>

If it is "best effort", can I just stub them out and let them return 0
always then?
:-) Just kidding. This is the same argument as in "int random()  { return
0; } is technically valid".

But seriously, tests would give me some measure of safety while working
with this code, as well as preventing bitrot or accidental removal. Just
look at the people queuing up to change or remove those handlers - see e.g.
https://github.com/openjdk/jdk/pull/636.


> > I am really interested in the history of this. Was this just a solution
> for
> > a single customer?
>
> Not sure of specific details but it was for hosting the VM in native
> applications that already did their own signal management.
>
> Cheers,
> David
>
>
Thanks for the infos!

..Thomas


> >
> > Thanks, Thomas
> >
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8255711
> > [2]
> >
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-October/043145.html
> > [3]
> >
> https://github.com/openjdk/jdk/blob/64feeab70af61a52ffe4c64df87a33c16754de18/src/hotspot/os/posix/signals_posix.cpp#L411
> > [4] https://bugs.openjdk.java.net/browse/JDK-4864136
> > [5] https://bugs.openjdk.java.net/browse/JDK-4408646
> > [6]
> >
> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
> > [7]
> https://mail.openjdk.java.net/pipermail/discuss/2019-April/005042.html
> >
>

From david.holmes at oracle.com  Tue Nov  3 08:55:52 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Nov 2020 18:55:52 +1000
Subject: SIgnal chaining, JVM_handle_(linux|bsd|aix)_signal, and backward
 compatibility
In-Reply-To: <CAA-vtUzX+mMvW16s6GK8=DYuHYQNCKA9JH=RmkXh6w=9AoCXJg@mail.gmail.com>
References: <CAA-vtUx9126nA-MHA6+WjOLmGr=g7CTnOQE5vuM9Gjy8LQdSyA@mail.gmail.com>
 <5175268c-c559-cf98-869e-eb6bd25397e7@oracle.com>
 <CAA-vtUzX+mMvW16s6GK8=DYuHYQNCKA9JH=RmkXh6w=9AoCXJg@mail.gmail.com>
Message-ID: <9ab8da13-2c7a-78b9-24fb-9fb4f7bbbb93@oracle.com>

On 3/11/2020 3:42 pm, Thomas St?fe wrote:
> Hi David,
> 
> On Tue, Nov 3, 2020 at 4:27 AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Thomas,
> 
>     On 2/11/2020 5:40 pm, Thomas St?fe wrote:
>      > Hi,
>      >
>      > While working on some signal handler fixes and cleanups ([1]), I
>     noticed
>      > that we export JVM_handle_(linux|bsd)_signal() on all POSIX
>     platforms.
>      >
>      > I wondered why we do this. See also my first question at
>     runtime-dev [2] -
>      > the initial reaction was "probably no reason anymore".
>      >
>      > But then, I see a carefully crafted comment in [3]:
>      >
>      > <quote>
>      > // This routine may be used by user applications as a "hook" to catch
>      > signals.
>      > // The user-defined signal handler must pass unrecognized signals
>     to this
>      > // routine
>      > ...
>      > </quote>
>      >
>      > and I also found some bug reports [4], [5], from 2001 and 2004:
>      > JDK-4864136 : "JVM_handle_linux_signal is private in 1.4.2-beta"
>      > JDK-4408646 : "JVM_handle_solaris_signal must be a global function"
>      >
>      > So, to me this looks like JVM_handle_xxx_signals() was an
>     official, or at
>      > least deliberate, interface for foreign code to interact with our
>     signal
>      > handling. Specifically, this reads like a third party could
>     install its
>      > signal handlers over ours, and as long as it queried our signal
>     handler
>      > first by calling JVM_handle_xxx_signal(), we still could coexist
>     with it.
> 
>     Did you see this comment:
> 
>     https://bugs.openjdk.java.net/browse/JDK-4361067?focusedCommentId=12425956&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12425956
> 
>     This is tied to AllowUserSignalHandlers so we'd have to go through the
>     deprecation process to make any changes in this area.
> 
> 
> Excellent point. Thanks for digging that up. Would love to know who 
> wrote this code?+ comment.
> 
> (Note that I believe this comment uses the term "signal chaining" to 
> describe a general concept, not the solution implemented in hotspot 
> today via the UseSignalChaining + libjsig).

Right.


> Looked at this and a cursory glance through github sources shows that 
> this flag is used quite a lot, and I think it is useful too (I remember 
> Florian Weimers question about it here: 
> https://mail.openjdk.java.net/pipermail/discuss/2019-April/005046.html - 
> and this is exactly the answer, this would be the alternative).
> 
> But man, this raises so many questions. I see that 
> AllowUserSignalHandlers had been implemented by just refusing to install 
> the central hotspot signal handler. But it's not honored for the 
> installation of the SR handler, nor for anything which gets installed 
> via os::signal(). So we have bitrot right there already. Then, it never 
> can have worked on AIX since we have a day zero bug in our port. And so 
> on...

I wouldn't classify it like that. Hotspot commandeers very specific 
signals for internal purposes eg SEGV. If an application has its own 
custom SEGV handling then you need to coordinate between them. In 
contrast SR_signum is by default a user-defined signal and if that use 
conflicts with an app then it can redefine SR_signum. os::signal is for 
application defined signal handlers so again not specifically related to 
internal hotspot uses. There are a number of different aspects to signal 
handling. I think AllowUserSignalHandlers is fundamentally for things 
like SEGV handling.

>      > But now we have signal chaining [6], which achieves the same by
>     preloading
>      > the libjsig library. Which some consider to be ewww [7] :-), but
>     still
>      > seems to me like the official solution to that problem. Using signal
>      > chaining there would be no need to manually call
>     JVM_handle_xxx_signal()
>      > from outside since the interposed sigaction() in libjsig would
>     take care of
>      > all this stuff automatically.
> 
>     Aren't the two mechanisms complementary in that they work in opposite
>     ways? Signal chaining keeps the VM in control and allows it to call
>     application handlers.? AllowUserSignalHandlers keeps the app in control
>     and requires it to call VM handlers.
> 
> 
> I don't believe so. I do not have the means to check it, but would not 
> be surprised if signal chaining was actually the later invention.

Yes later but the two still operate in opposite ways.

> We have three mechanisms:
> A) AllowUserSignalHandlers, which just refuses to install signal 
> handlers (thereby effectively disabling UseSignalChaining), but user 
> handler needs to call our handler

Yes this puts the application in charge and they have to know what 
signals the VM wants to know about and call our handlers.

> B) UseSignalChaining, which handles the case where we come after the 
> user handler - we install our handlers, but remember the user handler 
> and later invoke it
> C) libjsig interposition, which handles the case where the user handler 
> gets installed over our handler - libjsig prevents this and we end up 
> with the same signal handler chain as in (B)
> 
> (B) and (C) (together termed "signal chaining" now) are a complete 
> replacement for (A). (A) is somewhat simpler, especially with the 
> interposition stuff, and gives the user handler more control, since it 
> can decide to handle signals before we get to see them. Whether or not 
> that's wise is another thing.
> 
> Very probably (A) should not be used together with (C) or (B).

(A) puts the host app in charge.

(B) and (C) should be used together to let the application handlers take 
a subserviant role to the hotspot handlers. The JVM is in charge.

If you had an existing application that performed signal management and 
then wanted to also embed a JVM you want to use (A), not have to rewrite 
your application so that (B)+(C) work. But in addition if you also allow 
native code that might have its own signal handling requirements then 
that part may require signal-chaining to work as well - so these 
mechanisms are not mutually exclusive.

> 
>      > My question is:
>      > - if JVM_handle_xxx_signal() is (had been?) an official
>     interface, should
>      > there not be some official documentation and regression tests?
>     Was there? I
>      > could not find anything.
>      > - if it is not an official interface, would it be okay to lay it
>     to rest?
>      >? ? - Pro: it is made obsolete by signal chaining, and removing it
>     would
>      > reduce complexity of signal handling somewhat
>      >? ? - Con: applications may exist out there which use that
>     interface, and I'd
>      > hate to break them. We give customers enough reasons to cling to
>     old JDK
>      > versions as it is.
>      >? ? ? ?Also, arguably, this interface is useful. Not everyone likes
>      > preloading libjsig, and the signal chaining mechanism is also a
>     whole lot
>      > more fragile.
>      >
>      > However, if we let it live on, should we not document and test it?
> 
>     It is not well documented that is for sure.
> 
>     Not sure about testing ... I tend to see this more a "best effort"
>     mechanism. If someone reports it stops working, or doesn't work, then
>     we'll make a best effort to fix it.
> 
> 
> If it is "best effort", can I just stub them out and let them return 0 
> always then?
> :-) Just kidding. This is the same argument as in "int random()? { 
> return 0; } is technically valid".
> 
> But seriously, tests would give me some measure of safety while working 
> with this code, as well as preventing bitrot or accidental removal. Just 
> look at the people queuing up to change or remove those handlers - see 
> e.g. https://github.com/openjdk/jdk/pull/636.

8253742 is supposed to be about cleanup/consolidation not removal!

Yes tests would do what you say. But writing applications that exercise 
these different signal management aspects would be rather complicated 
and always potentially incomplete. How would you write such a test? A 
customer launcher that acts as a hosting app which sets 
-XX:-AllowUserSignalHandlers and then installs its own handler that 
calls the JVM handler would not exactly prove anything. To see if it was 
working correctly you'd need to run all the regular tests under this 
hosting application.

Cheers,
David
-----

> 
>      > I am really interested in the history of this. Was this just a
>     solution for
>      > a single customer?
> 
>     Not sure of specific details but it was for hosting the VM in native
>     applications that already did their own signal management.
> 
>     Cheers,
>     David
> 
> 
> Thanks for the infos!
> 
> ..Thomas
> 
>      >
>      > Thanks, Thomas
>      >
>      >
>      > [1] https://bugs.openjdk.java.net/browse/JDK-8255711
>      > [2]
>      >
>     https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-October/043145.html
>      > [3]
>      >
>     https://github.com/openjdk/jdk/blob/64feeab70af61a52ffe4c64df87a33c16754de18/src/hotspot/os/posix/signals_posix.cpp#L411
>      > [4] https://bugs.openjdk.java.net/browse/JDK-4864136
>      > [5] https://bugs.openjdk.java.net/browse/JDK-4408646
>      > [6]
>      >
>     https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
>      > [7]
>     https://mail.openjdk.java.net/pipermail/discuss/2019-April/005042.html
>      >
> 

From thomas.stuefe at gmail.com  Tue Nov  3 09:05:37 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 3 Nov 2020 10:05:37 +0100
Subject: SIgnal chaining, JVM_handle_(linux|bsd|aix)_signal,
 and backward compatibility
In-Reply-To: <9ab8da13-2c7a-78b9-24fb-9fb4f7bbbb93@oracle.com>
References: <CAA-vtUx9126nA-MHA6+WjOLmGr=g7CTnOQE5vuM9Gjy8LQdSyA@mail.gmail.com>
 <5175268c-c559-cf98-869e-eb6bd25397e7@oracle.com>
 <CAA-vtUzX+mMvW16s6GK8=DYuHYQNCKA9JH=RmkXh6w=9AoCXJg@mail.gmail.com>
 <9ab8da13-2c7a-78b9-24fb-9fb4f7bbbb93@oracle.com>
Message-ID: <CAA-vtUw=GtUaqr=dzuAy1HzJ0O+-83FdXo2bsuSZz6rSgNDLKA@mail.gmail.com>

On Tue, Nov 3, 2020 at 9:56 AM David Holmes <david.holmes at oracle.com> wrote:

> On 3/11/2020 3:42 pm, Thomas St?fe wrote:
> > Hi David,
> >
> > On Tue, Nov 3, 2020 at 4:27 AM David Holmes <david.holmes at oracle.com
> > <mailto:david.holmes at oracle.com>> wrote:
> >
> >     Hi Thomas,
> >
> >     On 2/11/2020 5:40 pm, Thomas St?fe wrote:
> >      > Hi,
> >      >
> >      > While working on some signal handler fixes and cleanups ([1]), I
> >     noticed
> >      > that we export JVM_handle_(linux|bsd)_signal() on all POSIX
> >     platforms.
> >      >
> >      > I wondered why we do this. See also my first question at
> >     runtime-dev [2] -
> >      > the initial reaction was "probably no reason anymore".
> >      >
> >      > But then, I see a carefully crafted comment in [3]:
> >      >
> >      > <quote>
> >      > // This routine may be used by user applications as a "hook" to
> catch
> >      > signals.
> >      > // The user-defined signal handler must pass unrecognized signals
> >     to this
> >      > // routine
> >      > ...
> >      > </quote>
> >      >
> >      > and I also found some bug reports [4], [5], from 2001 and 2004:
> >      > JDK-4864136 : "JVM_handle_linux_signal is private in 1.4.2-beta"
> >      > JDK-4408646 : "JVM_handle_solaris_signal must be a global
> function"
> >      >
> >      > So, to me this looks like JVM_handle_xxx_signals() was an
> >     official, or at
> >      > least deliberate, interface for foreign code to interact with our
> >     signal
> >      > handling. Specifically, this reads like a third party could
> >     install its
> >      > signal handlers over ours, and as long as it queried our signal
> >     handler
> >      > first by calling JVM_handle_xxx_signal(), we still could coexist
> >     with it.
> >
> >     Did you see this comment:
> >
> >
> https://bugs.openjdk.java.net/browse/JDK-4361067?focusedCommentId=12425956&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12425956
> >
> >     This is tied to AllowUserSignalHandlers so we'd have to go through
> the
> >     deprecation process to make any changes in this area.
> >
> >
> > Excellent point. Thanks for digging that up. Would love to know who
> > wrote this code + comment.
> >
> > (Note that I believe this comment uses the term "signal chaining" to
> > describe a general concept, not the solution implemented in hotspot
> > today via the UseSignalChaining + libjsig).
>
> Right.
>
>
> > Looked at this and a cursory glance through github sources shows that
> > this flag is used quite a lot, and I think it is useful too (I remember
> > Florian Weimers question about it here:
> > https://mail.openjdk.java.net/pipermail/discuss/2019-April/005046.html
> -
> > and this is exactly the answer, this would be the alternative).
> >
> > But man, this raises so many questions. I see that
> > AllowUserSignalHandlers had been implemented by just refusing to install
> > the central hotspot signal handler. But it's not honored for the
> > installation of the SR handler, nor for anything which gets installed
> > via os::signal(). So we have bitrot right there already. Then, it never
> > can have worked on AIX since we have a day zero bug in our port. And so
> > on...
>
> I wouldn't classify it like that. Hotspot commandeers very specific
> signals for internal purposes eg SEGV. If an application has its own
> custom SEGV handling then you need to coordinate between them. In
> contrast SR_signum is by default a user-defined signal and if that use
> conflicts with an app then it can redefine SR_signum. os::signal is for
> application defined signal handlers so again not specifically related to
> internal hotspot uses. There are a number of different aspects to signal
> handling. I think AllowUserSignalHandlers is fundamentally for things
> like SEGV handling.
>

Good point.


>
> >      > But now we have signal chaining [6], which achieves the same by
> >     preloading
> >      > the libjsig library. Which some consider to be ewww [7] :-), but
> >     still
> >      > seems to me like the official solution to that problem. Using
> signal
> >      > chaining there would be no need to manually call
> >     JVM_handle_xxx_signal()
> >      > from outside since the interposed sigaction() in libjsig would
> >     take care of
> >      > all this stuff automatically.
> >
> >     Aren't the two mechanisms complementary in that they work in opposite
> >     ways? Signal chaining keeps the VM in control and allows it to call
> >     application handlers.  AllowUserSignalHandlers keeps the app in
> control
> >     and requires it to call VM handlers.
> >
> >
> > I don't believe so. I do not have the means to check it, but would not
> > be surprised if signal chaining was actually the later invention.
>
> Yes later but the two still operate in opposite ways.
>
> > We have three mechanisms:
> > A) AllowUserSignalHandlers, which just refuses to install signal
> > handlers (thereby effectively disabling UseSignalChaining), but user
> > handler needs to call our handler
>
> Yes this puts the application in charge and they have to know what
> signals the VM wants to know about and call our handlers.
>
> > B) UseSignalChaining, which handles the case where we come after the
> > user handler - we install our handlers, but remember the user handler
> > and later invoke it
> > C) libjsig interposition, which handles the case where the user handler
> > gets installed over our handler - libjsig prevents this and we end up
> > with the same signal handler chain as in (B)
> >
> > (B) and (C) (together termed "signal chaining" now) are a complete
> > replacement for (A). (A) is somewhat simpler, especially with the
> > interposition stuff, and gives the user handler more control, since it
> > can decide to handle signals before we get to see them. Whether or not
> > that's wise is another thing.
> >
> > Very probably (A) should not be used together with (C) or (B).
>
> (A) puts the host app in charge.
>
> (B) and (C) should be used together to let the application handlers take
> a subserviant role to the hotspot handlers. The JVM is in charge.
>
> If you had an existing application that performed signal management and
> then wanted to also embed a JVM you want to use (A), not have to rewrite
> your application so that (B)+(C) work. But in addition if you also allow
> native code that might have its own signal handling requirements then
> that part may require signal-chaining to work as well - so these
> mechanisms are not mutually exclusive.
>
>
Yes, well explained. I realize that we actually mean the same thing. So, I
will definitely not remove that flag nor the exports.


> >
> >      > My question is:
> >      > - if JVM_handle_xxx_signal() is (had been?) an official
> >     interface, should
> >      > there not be some official documentation and regression tests?
> >     Was there? I
> >      > could not find anything.
> >      > - if it is not an official interface, would it be okay to lay it
> >     to rest?
> >      >    - Pro: it is made obsolete by signal chaining, and removing it
> >     would
> >      > reduce complexity of signal handling somewhat
> >      >    - Con: applications may exist out there which use that
> >     interface, and I'd
> >      > hate to break them. We give customers enough reasons to cling to
> >     old JDK
> >      > versions as it is.
> >      >       Also, arguably, this interface is useful. Not everyone likes
> >      > preloading libjsig, and the signal chaining mechanism is also a
> >     whole lot
> >      > more fragile.
> >      >
> >      > However, if we let it live on, should we not document and test it?
> >
> >     It is not well documented that is for sure.
> >
> >     Not sure about testing ... I tend to see this more a "best effort"
> >     mechanism. If someone reports it stops working, or doesn't work, then
> >     we'll make a best effort to fix it.
> >
> >
> > If it is "best effort", can I just stub them out and let them return 0
> > always then?
> > :-) Just kidding. This is the same argument as in "int random()  {
> > return 0; } is technically valid".
> >
> > But seriously, tests would give me some measure of safety while working
> > with this code, as well as preventing bitrot or accidental removal. Just
> > look at the people queuing up to change or remove those handlers - see
> > e.g. https://github.com/openjdk/jdk/pull/636.
>
> 8253742 is supposed to be about cleanup/consolidation not removal!
>
>
He does not really remove them, just rename them, but the effect would have
been the same.
But there was a lot of confusion surrounding JVM_handle_xxx_signal. Since
documentation is almost non-existent, and there are no tests, how could we
know.


> Yes tests would do what you say. But writing applications that exercise
> these different signal management aspects would be rather complicated
> and always potentially incomplete. How would you write such a test? A
> customer launcher that acts as a hosting app which sets
> -XX:-AllowUserSignalHandlers and then installs its own handler that
> calls the JVM handler would not exactly prove anything. To see if it was
> working correctly you'd need to run all the regular tests under this
> hosting application.
>

It is difficult, yes. But some basic tests could be to
- test that this symbol is exported (could be a simple nm call)
- maybe, just call that thing with abort_if_unrecognized = false and some
fake infos which look like an unrelated SEGV the hotspot should ignore.
That could be done in a gtest in-vm.

I'll see if I can cook up something in the course of JDK-8255711.

Cheers, Thomas


> Cheers,
> David
> -----
>
> >
> >      > I am really interested in the history of this. Was this just a
> >     solution for
> >      > a single customer?
> >
> >     Not sure of specific details but it was for hosting the VM in native
> >     applications that already did their own signal management.
> >
> >     Cheers,
> >     David
> >
> >
> > Thanks for the infos!
> >
> > ..Thomas
> >
> >      >
> >      > Thanks, Thomas
> >      >
> >      >
> >      > [1] https://bugs.openjdk.java.net/browse/JDK-8255711
> >      > [2]
> >      >
> >
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-October/043145.html
> >      > [3]
> >      >
> >
> https://github.com/openjdk/jdk/blob/64feeab70af61a52ffe4c64df87a33c16754de18/src/hotspot/os/posix/signals_posix.cpp#L411
> >      > [4] https://bugs.openjdk.java.net/browse/JDK-4864136
> >      > [5] https://bugs.openjdk.java.net/browse/JDK-4408646
> >      > [6]
> >      >
> >
> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
> >      > [7]
> >
> https://mail.openjdk.java.net/pipermail/discuss/2019-April/005042.html
> >      >
> >
>

From mark.reinhold at oracle.com  Wed Nov  4 00:20:22 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 03 Nov 2020 16:20:22 -0800
Subject: JEP proposed to target JDK 16: 392: Packaging Tool
In-Reply-To: <20201023221525.F3CB83C6F76@eggemoggin.niobe.net>
References: <20201023221525.F3CB83C6F76@eggemoggin.niobe.net>
Message-ID: <20201103162022.440325030@eggemoggin.niobe.net>

2020/10/23 15:15:25 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 16:
> 
>   392: Packaging Tool
>        https://openjdk.java.net/jeps/392
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Friday, 30 October, or if they?re raised and
> then satisfactorily answered, then per the JEP 2.0 process proposal [2]
> I?ll target this JEP to JDK 16.

Hearing no objections, I?ve targeted this JEP to JDK 16.

- Mark

From mark.reinhold at oracle.com  Wed Nov  4 00:21:07 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 03 Nov 2020 16:21:07 -0800
Subject: JEP proposed to target JDK 16: 393: Foreign-Memory Access API
 (Third Incubator)
In-Reply-To: <20201026231409.733593C72FD@eggemoggin.niobe.net>
References: <20201026231409.733593C72FD@eggemoggin.niobe.net>
Message-ID: <20201103162107.994460672@eggemoggin.niobe.net>

2020/10/26 16:14:09 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 16:
> 
>   393: Foreign-Memory Access API (Third Incubator)
>        https://openjdk.java.net/jeps/393
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Monday, 2 November, or if they?re raised and
> then satisfactorily answered, then per the JEP 2.0 process proposal [2]
> I?ll target this JEP to JDK 16.

Hearing no objections, I?ve targeted this JEP to JDK 16.

- Mark

From mark.reinhold at oracle.com  Wed Nov  4 00:21:31 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 03 Nov 2020 16:21:31 -0800
Subject: JEP proposed to target JDK 16: 394: Pattern Matching for
 instanceof
In-Reply-To: <20201027225159.4BA4A3C7583@eggemoggin.niobe.net>
References: <20201027225159.4BA4A3C7583@eggemoggin.niobe.net>
Message-ID: <20201103162131.844073866@eggemoggin.niobe.net>

2020/10/27 15:51:59 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 16:
> 
>   394: Pattern Matching for instanceof
>        https://openjdk.java.net/jeps/394
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Tuesday, 3 November, or if they?re raised
> and then satisfactorily answered, then per the JEP 2.0 process proposal
> [2] I?ll target this JEP to JDK 16.

Hearing no objections, I?ve targeted this JEP to JDK 16.

- Mark

From thihup at gmail.com  Wed Nov  4 11:39:09 2020
From: thihup at gmail.com (Thiago Henrique Hupner)
Date: Wed, 4 Nov 2020 08:39:09 -0300
Subject: Multi Module Executable JARs
Message-ID: <CAENv9VHKOeQdZOecpYaNvxtJ23Y0a1iRrcqebmCMEZLaPToCpg@mail.gmail.com>

Hello!
Apologies in advance if this isn't the correct mailing list to post this
question.
Is there any other discussion about the Multi Module Executable JARs [1]?

Thanks
Thiago

[1]
http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleExecutableJARs

From dalibor.topic at oracle.com  Thu Nov  5 14:33:36 2020
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Thu, 5 Nov 2020 15:33:36 +0100
Subject: Multi Module Executable JARs
In-Reply-To: <CAENv9VHKOeQdZOecpYaNvxtJ23Y0a1iRrcqebmCMEZLaPToCpg@mail.gmail.com>
References: <CAENv9VHKOeQdZOecpYaNvxtJ23Y0a1iRrcqebmCMEZLaPToCpg@mail.gmail.com>
Message-ID: <69e73fd8-a033-232a-59e4-66a1980fa7bb@oracle.com>

Hi,

the best place to ask questions about the module system is jigsaw-dev:

https://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev

cheers,
dalibor topic

On 04.11.2020 12:39, Thiago Henrique Hupner wrote:
> Hello!
> Apologies in advance if this isn't the correct mailing list to post this
> question.
> Is there any other discussion about the Multi Module Executable JARs [1]?
> 
> Thanks
> Thiago
> 
> [1]
> http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleExecutableJARs
> 

-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>, Video: dalibor.topic at oracle.com
<sip:dalibor.topic at oracle.com>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From sean.coffey at oracle.com  Fri Nov  6 17:48:00 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 6 Nov 2020 17:48:00 +0000
Subject: CFV: New JDK Committer: Kiran Ravikumar
Message-ID: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>

I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.

Kiran has been working primarily in the core-libs areas of the JDK. He 
has contributed a range of fixes to the JDK Project [0].

Votes are due by 18:00 GMT on Nov 20th 2020.

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

For Lazy Consensus voting instructions, see [2].

regards,
Sean.

[0] 
https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
[1] https://openjdk.java.net/census
[2] https://openjdk.java.net/projects/#committer-vote


From sean.coffey at oracle.com  Fri Nov  6 17:50:24 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 6 Nov 2020 17:50:24 +0000
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <2fdfcb23-822a-ea67-0adb-09454c1b2054@oracle.com>

Vote: yes

regards,
Sean.

On 06/11/2020 17:48, Se?n Coffey wrote:
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
>
> Kiran has been working primarily in the core-libs areas of the JDK. He 
> has contributed a range of fixes to the JDK Project [0].
>
> Votes are due by 18:00 GMT on Nov 20th 2020.
>
> Only current JDK Project Committers [1] are eligible to vote on this 
> nomination.? Votes must be cast in the open by replying to this 
> mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> regards,
> Sean.
>
> [0] 
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
>

From aleksej.efimov at oracle.com  Fri Nov  6 17:58:02 2020
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Fri, 6 Nov 2020 17:58:02 +0000
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <bdf990c2-6961-0e8b-5ed1-4129876a3390@oracle.com>

Vote: yes

On 06/11/2020 17:48, Se?n Coffey wrote:
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
>
> Kiran has been working primarily in the core-libs areas of the JDK. He 
> has contributed a range of fixes to the JDK Project [0].
>
> Votes are due by 18:00 GMT on Nov 20th 2020.
>
> Only current JDK Project Committers [1] are eligible to vote on this 
> nomination.? Votes must be cast in the open by replying to this 
> mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> regards,
> Sean.
>
> [0] 
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
>


From harold.seigel at oracle.com  Fri Nov  6 18:04:47 2020
From: harold.seigel at oracle.com (Harold Seigel)
Date: Fri, 6 Nov 2020 13:04:47 -0500
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <dede1ec3-ac49-143d-10cb-87d9d6d1eb64@oracle.com>

Vote: yes

Harold

On 11/6/2020 12:48 PM, Se?n Coffey wrote:
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
>
> Kiran has been working primarily in the core-libs areas of the JDK. He 
> has contributed a range of fixes to the JDK Project [0].
>
> Votes are due by 18:00 GMT on Nov 20th 2020.
>
> Only current JDK Project Committers [1] are eligible to vote on this 
> nomination.? Votes must be cast in the open by replying to this 
> mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> regards,
> Sean.
>
> [0] 
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
>

From lois.foltan at oracle.com  Fri Nov  6 18:20:21 2020
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 6 Nov 2020 13:20:21 -0500
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <dc6c59a2-4da0-9be7-8b8e-46bb81013bc3@oracle.com>

Vote: yes

Lois

On 11/6/2020 12:48 PM, Se?n Coffey wrote:
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
>
> Kiran has been working primarily in the core-libs areas of the JDK. He 
> has contributed a range of fixes to the JDK Project [0].
>
> Votes are due by 18:00 GMT on Nov 20th 2020.
>
> Only current JDK Project Committers [1] are eligible to vote on this 
> nomination.? Votes must be cast in the open by replying to this 
> mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> regards,
> Sean.
>
> [0] 
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
>


From sgehwolf at redhat.com  Fri Nov  6 18:21:05 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 06 Nov 2020 19:21:05 +0100
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <8765039a3b211df600223a19c918ebc3959bf2dc.camel@redhat.com>

Vote: yes

On Fri, 2020-11-06 at 17:48 +0000, Se?n Coffey wrote:
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> 
> Kiran has been working primarily in the core-libs areas of the JDK. He 
> has contributed a range of fixes to the JDK Project [0].
> 
> Votes are due by 18:00 GMT on Nov 20th 2020.
> 
> Only current JDK Project Committers [1] are eligible to vote on this 
> nomination.  Votes must be cast in the open by replying to this mailing 
> list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> regards,
> Sean.
> 
> [0] 
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> 


From stuart.marks at oracle.com  Fri Nov  6 18:37:09 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 6 Nov 2020 10:37:09 -0800
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <f2da4178-c9c0-5941-02b3-e5f43781823c@oracle.com>

Vote: yes

On 11/6/20 9:48 AM, Se?n Coffey wrote:
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> 
> Kiran has been working primarily in the core-libs areas of the JDK. He has 
> contributed a range of fixes to the JDK Project [0].
> 
> Votes are due by 18:00 GMT on Nov 20th 2020.
> 
> Only current JDK Project Committers [1] are eligible to vote on this nomination.  
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> regards,
> Sean.
> 
> [0] https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> 

From brian.burkhalter at oracle.com  Fri Nov  6 18:39:36 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 6 Nov 2020 10:39:36 -0800
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <ED1A023F-329D-4550-B662-7A9347D2AC0A@oracle.com>

Vote: yes

> On Nov 6, 2020, at 9:48 AM, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> 
> Kiran has been working primarily in the core-libs areas of the JDK. He has contributed a range of fixes to the JDK Project [0].
> 
> Votes are due by 18:00 GMT on Nov 20th 2020.
> 
> Only current JDK Project Committers [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> regards,
> Sean.
> 
> [0] https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> 


From goetz.lindenmaier at sap.com  Fri Nov  6 18:41:26 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 6 Nov 2020 18:41:26 +0000
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <AM4PR0202MB29640AC35895BD653C14D452ECED0@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Vote: yes

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Se?n Coffey
> Sent: Friday, November 6, 2020 6:48 PM
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: CFV: New JDK Committer: Kiran Ravikumar
> 
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> 
> Kiran has been working primarily in the core-libs areas of the JDK. He
> has contributed a range of fixes to the JDK Project [0].
> 
> Votes are due by 18:00 GMT on Nov 20th 2020.
> 
> Only current JDK Project Committers [1] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying to this mailing
> list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> regards,
> Sean.
> 
> [0]
> https://github.com/openjdk/jdk/search?p=1&q=author-
> name%3AKiran&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote


From naoto.sato at oracle.com  Fri Nov  6 18:43:57 2020
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 6 Nov 2020 10:43:57 -0800
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <3eda96ca-768f-7e72-c99e-20358ff4a61d@oracle.com>

Vote: yes

Naoto

On 11/6/20 9:48 AM, Se?n Coffey wrote:
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> 
> Kiran has been working primarily in the core-libs areas of the JDK. He 
> has contributed a range of fixes to the JDK Project [0].
> 
> Votes are due by 18:00 GMT on Nov 20th 2020.
> 
> Only current JDK Project Committers [1] are eligible to vote on this 
> nomination.? Votes must be cast in the open by replying to this mailing 
> list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> regards,
> Sean.
> 
> [0] 
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits 
> 
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> 

From Roger.Riggs at oracle.com  Fri Nov  6 23:02:55 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 6 Nov 2020 18:02:55 -0500
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <71ec91a5-8839-12c3-cf54-449ac14c41fc@oracle.com>

Vote: yes

On 11/6/20 12:48 PM, Se?n Coffey wrote:
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer. 


From hk.mine.2018 at gmail.com  Sat Nov  7 02:25:40 2020
From: hk.mine.2018 at gmail.com (Hk Mine)
Date: Sat, 7 Nov 2020 07:55:40 +0530
Subject: jdk-dev Digest, Vol 38, Issue 7
In-Reply-To: <mailman.4485.1604687982.28028.jdk-dev@openjdk.java.net>
References: <mailman.4485.1604687982.28028.jdk-dev@openjdk.java.net>
Message-ID: <CAF+W_w0nfseb5pFeXHzyKAg6Jk2ocLRAtdzEo3nWirALwA+=MA@mail.gmail.com>

Vote: Yes

On Sat, Nov 7, 2020 at 12:12 AM <jdk-dev-request at openjdk.java.net> wrote:

> Send jdk-dev mailing list submissions to
>         jdk-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.openjdk.java.net/mailman/listinfo/jdk-dev
> or, via email, send a message with subject or body 'help' to
>         jdk-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
>         jdk-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of jdk-dev digest..."
>
>
> Today's Topics:
>
>    1. CFV: New JDK Committer: Kiran Ravikumar (Se?n Coffey)
>    2. Re: CFV: New JDK Committer: Kiran Ravikumar (Se?n Coffey)
>    3. Re: CFV: New JDK Committer: Kiran Ravikumar (Aleks Efimov)
>    4. Re: CFV: New JDK Committer: Kiran Ravikumar (Harold Seigel)
>    5. Re: CFV: New JDK Committer: Kiran Ravikumar (Lois Foltan)
>    6. Re: CFV: New JDK Committer: Kiran Ravikumar (Severin Gehwolf)
>    7. Re: CFV: New JDK Committer: Kiran Ravikumar (Stuart Marks)
>    8. Re: CFV: New JDK Committer: Kiran Ravikumar (Brian Burkhalter)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 6 Nov 2020 17:48:00 +0000
> From: Se?n Coffey <sean.coffey at oracle.com>
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: CFV: New JDK Committer: Kiran Ravikumar
> Message-ID: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
>
> Kiran has been working primarily in the core-libs areas of the JDK. He
> has contributed a range of fixes to the JDK Project [0].
>
> Votes are due by 18:00 GMT on Nov 20th 2020.
>
> Only current JDK Project Committers [1] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [2].
>
> regards,
> Sean.
>
> [0]
>
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 6 Nov 2020 17:50:24 +0000
> From: Se?n Coffey <sean.coffey at oracle.com>
> To: jdk-dev at openjdk.java.net
> Subject: Re: CFV: New JDK Committer: Kiran Ravikumar
> Message-ID: <2fdfcb23-822a-ea67-0adb-09454c1b2054 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Vote: yes
>
> regards,
> Sean.
>
> On 06/11/2020 17:48, Se?n Coffey wrote:
> > I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> >
> > Kiran has been working primarily in the core-libs areas of the JDK. He
> > has contributed a range of fixes to the JDK Project [0].
> >
> > Votes are due by 18:00 GMT on Nov 20th 2020.
> >
> > Only current JDK Project Committers [1] are eligible to vote on this
> > nomination.? Votes must be cast in the open by replying to this
> > mailing list.
> >
> > For Lazy Consensus voting instructions, see [2].
> >
> > regards,
> > Sean.
> >
> > [0]
> >
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> > [1] https://openjdk.java.net/census
> > [2] https://openjdk.java.net/projects/#committer-vote
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 6 Nov 2020 17:58:02 +0000
> From: Aleks Efimov <aleksej.efimov at oracle.com>
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Cc: Se?n Coffey <sean.coffey at oracle.com>
> Subject: Re: CFV: New JDK Committer: Kiran Ravikumar
> Message-ID: <bdf990c2-6961-0e8b-5ed1-4129876a3390 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Vote: yes
>
> On 06/11/2020 17:48, Se?n Coffey wrote:
> > I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> >
> > Kiran has been working primarily in the core-libs areas of the JDK. He
> > has contributed a range of fixes to the JDK Project [0].
> >
> > Votes are due by 18:00 GMT on Nov 20th 2020.
> >
> > Only current JDK Project Committers [1] are eligible to vote on this
> > nomination.? Votes must be cast in the open by replying to this
> > mailing list.
> >
> > For Lazy Consensus voting instructions, see [2].
> >
> > regards,
> > Sean.
> >
> > [0]
> >
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> > [1] https://openjdk.java.net/census
> > [2] https://openjdk.java.net/projects/#committer-vote
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 6 Nov 2020 13:04:47 -0500
> From: Harold Seigel <harold.seigel at oracle.com>
> To: jdk-dev at openjdk.java.net
> Subject: Re: CFV: New JDK Committer: Kiran Ravikumar
> Message-ID: <dede1ec3-ac49-143d-10cb-87d9d6d1eb64 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Vote: yes
>
> Harold
>
> On 11/6/2020 12:48 PM, Se?n Coffey wrote:
> > I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> >
> > Kiran has been working primarily in the core-libs areas of the JDK. He
> > has contributed a range of fixes to the JDK Project [0].
> >
> > Votes are due by 18:00 GMT on Nov 20th 2020.
> >
> > Only current JDK Project Committers [1] are eligible to vote on this
> > nomination.? Votes must be cast in the open by replying to this
> > mailing list.
> >
> > For Lazy Consensus voting instructions, see [2].
> >
> > regards,
> > Sean.
> >
> > [0]
> >
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> > [1] https://openjdk.java.net/census
> > [2] https://openjdk.java.net/projects/#committer-vote
> >
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 6 Nov 2020 13:20:21 -0500
> From: Lois Foltan <lois.foltan at oracle.com>
> To: Se?n Coffey <sean.coffey at oracle.com>, jdk-dev
>         <jdk-dev at openjdk.java.net>
> Subject: Re: CFV: New JDK Committer: Kiran Ravikumar
> Message-ID: <dc6c59a2-4da0-9be7-8b8e-46bb81013bc3 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Vote: yes
>
> Lois
>
> On 11/6/2020 12:48 PM, Se?n Coffey wrote:
> > I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> >
> > Kiran has been working primarily in the core-libs areas of the JDK. He
> > has contributed a range of fixes to the JDK Project [0].
> >
> > Votes are due by 18:00 GMT on Nov 20th 2020.
> >
> > Only current JDK Project Committers [1] are eligible to vote on this
> > nomination.? Votes must be cast in the open by replying to this
> > mailing list.
> >
> > For Lazy Consensus voting instructions, see [2].
> >
> > regards,
> > Sean.
> >
> > [0]
> >
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> > [1] https://openjdk.java.net/census
> > [2] https://openjdk.java.net/projects/#committer-vote
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 06 Nov 2020 19:21:05 +0100
> From: Severin Gehwolf <sgehwolf at redhat.com>
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: Re: CFV: New JDK Committer: Kiran Ravikumar
> Message-ID:
>         <8765039a3b211df600223a19c918ebc3959bf2dc.camel at redhat.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Vote: yes
>
> On Fri, 2020-11-06 at 17:48 +0000, Se?n Coffey wrote:
> > I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> >
> > Kiran has been working primarily in the core-libs areas of the JDK. He
> > has contributed a range of fixes to the JDK Project [0].
> >
> > Votes are due by 18:00 GMT on Nov 20th 2020.
> >
> > Only current JDK Project Committers [1] are eligible to vote on this
> > nomination.  Votes must be cast in the open by replying to this mailing
> > list.
> >
> > For Lazy Consensus voting instructions, see [2].
> >
> > regards,
> > Sean.
> >
> > [0]
> >
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> > [1] https://openjdk.java.net/census
> > [2] https://openjdk.java.net/projects/#committer-vote
> >
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 6 Nov 2020 10:37:09 -0800
> From: Stuart Marks <stuart.marks at oracle.com>
> To: Se?n Coffey <sean.coffey at oracle.com>
> Cc: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: Re: CFV: New JDK Committer: Kiran Ravikumar
> Message-ID: <f2da4178-c9c0-5941-02b3-e5f43781823c at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Vote: yes
>
> On 11/6/20 9:48 AM, Se?n Coffey wrote:
> > I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> >
> > Kiran has been working primarily in the core-libs areas of the JDK. He
> has
> > contributed a range of fixes to the JDK Project [0].
> >
> > Votes are due by 18:00 GMT on Nov 20th 2020.
> >
> > Only current JDK Project Committers [1] are eligible to vote on this
> nomination.
> > Votes must be cast in the open by replying to this mailing list.
> >
> > For Lazy Consensus voting instructions, see [2].
> >
> > regards,
> > Sean.
> >
> > [0]
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> > [1] https://openjdk.java.net/census
> > [2] https://openjdk.java.net/projects/#committer-vote
> >
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 6 Nov 2020 10:39:36 -0800
> From: Brian Burkhalter <brian.burkhalter at oracle.com>
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: Re: CFV: New JDK Committer: Kiran Ravikumar
> Message-ID: <ED1A023F-329D-4550-B662-7A9347D2AC0A at oracle.com>
> Content-Type: text/plain;       charset=utf-8
>
> Vote: yes
>
> > On Nov 6, 2020, at 9:48 AM, Se?n Coffey <sean.coffey at oracle.com> wrote:
> >
> > I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> >
> > Kiran has been working primarily in the core-libs areas of the JDK. He
> has contributed a range of fixes to the JDK Project [0].
> >
> > Votes are due by 18:00 GMT on Nov 20th 2020.
> >
> > Only current JDK Project Committers [1] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying to this mailing
> list.
> >
> > For Lazy Consensus voting instructions, see [2].
> >
> > regards,
> > Sean.
> >
> > [0]
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> > [1] https://openjdk.java.net/census
> > [2] https://openjdk.java.net/projects/#committer-vote
> >
>
>
>
> End of jdk-dev Digest, Vol 38, Issue 7
> **************************************
>

From christoph.langer at sap.com  Sat Nov  7 06:09:31 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sat, 7 Nov 2020 06:09:31 +0000
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <AM4PR02MB31383E30AC2478CD7F8039BA8AEC0@AM4PR02MB3138.eurprd02.prod.outlook.com>

Vote: yes

/Christoph

> -----Original Message-----
> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Se?n Coffey
> Sent: Freitag, 6. November 2020 18:48
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: CFV: New JDK Committer: Kiran Ravikumar
> 
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> 
> Kiran has been working primarily in the core-libs areas of the JDK. He
> has contributed a range of fixes to the JDK Project [0].
> 
> Votes are due by 18:00 GMT on Nov 20th 2020.
> 
> Only current JDK Project Committers [1] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying to this mailing
> list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> regards,
> Sean.
> 
> [0]
> https://github.com/openjdk/jdk/search?p=1&q=author-
> name%3AKiran&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote


From chris.hegarty at oracle.com  Sun Nov  8 20:27:01 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sun, 8 Nov 2020 20:27:01 +0000
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <1A59E33C-3EB0-4DD5-9A54-75A0D0E3440D@oracle.com>


> On 6 Nov 2020, at 17:48, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.

Vote: YES

-Chris.

From goetz.lindenmaier at sap.com  Mon Nov  9 09:32:11 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 9 Nov 2020 09:32:11 +0000
Subject: CFV: New JDK Reviewer: Richard Reingruber
Message-ID: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi,

I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.

Richard is a long-time member of the Java VM Team at SAP and has
contributed over 30 changes to the JDK project[1].

Recently, he has concentrated on JVMTI and compiler optimizations,
improving performance when JVMTI capabilities are required. He
identified and fixed a row of issues with JVMTI. [2]
He has built up a deep knowledge of the various synchronization
mechanisms in the VM and reviewed a row of complex changes
in this area[3].

Before, he has worked on platform ports for SAPs internal JVM.
Among many other, the s390 C1 compiler and template interpreter
in OpenJDK were originally ported by him.
He has worked on improving CMS and did a lot of work on
G1. He implemented the SAP Profiler Tool for G1.

Richard is a very pertinacious engineer solving any problem
that gets into his hands and will be an enrichment for the
OpenJDK as reviewer.



Votes are due by 18:00 GMT on Nov 30th 2020.



Only current JDK Project Reviewers [4] are eligible to vote on this

nomination.  Votes must be cast in the open by replying to this mailing

list.



For Lazy Consensus voting instructions, see [5].


Best regards,
  Goetz.



[1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits

[2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2

8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken

https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92

[3] https://github.com/openjdk/jdk/search?q=rrich&type=commits

[4] https://openjdk.java.net/census

[5] https://openjdk.java.net/projects/#committer-vote


From shade at redhat.com  Mon Nov  9 09:36:15 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 9 Nov 2020 10:36:15 +0100
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <4b8b0a21-dbca-8c6e-243a-e81de78a60b9@redhat.com>

Vote: yes

On 11/9/20 10:32 AM, Lindenmaier, Goetz wrote:
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
-- 
Thanks,
-Aleksey


From martin.doerr at sap.com  Mon Nov  9 09:46:14 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 9 Nov 2020 09:46:14 +0000
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3057F593D4DF4DE8EB4913579AEA0@AM4PR02MB3057.eurprd02.prod.outlook.com>

Vote: yes

Best regards,
Martin


> -----Original Message-----
> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Lindenmaier,
> Goetz
> Sent: Montag, 9. November 2020 10:32
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: CFV: New JDK Reviewer: Richard Reingruber
> 
> Hi,
> 
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
> 
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
> 
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
> 
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
> 
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
> 
> 
> 
> Votes are due by 18:00 GMT on Nov 30th 2020.
> 
> 
> 
> Only current JDK Project Reviewers [4] are eligible to vote on this
> 
> nomination.  Votes must be cast in the open by replying to this mailing
> 
> list.
> 
> 
> 
> For Lazy Consensus voting instructions, see [5].
> 
> 
> Best regards,
>   Goetz.
> 
> 
> 
> [1] https://github.com/openjdk/jdk/search?q=author-
> name%3A%22Richard+Reingruber%22&type=commits
> 
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence
> of JVMTI Agents
> 
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe2
> 33f8764c2
> 
> 8230677: Should disable Escape Analysis if JVMTI capability
> can_get_owned_monitor_info was taken
> 
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b5474124
> 3c98adcc92
> 
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
> 
> [4] https://openjdk.java.net/census
> 
> [5] https://openjdk.java.net/projects/#committer-vote


From goetz.lindenmaier at sap.com  Mon Nov  9 09:54:27 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 9 Nov 2020 09:54:27 +0000
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0202MB29640231D9794AEBDC967691ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Vote: yes

Best regards,
  Goetz.

-----Original Message-----
From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Lindenmaier, Goetz
Sent: Montag, 9. November 2020 10:32
To: jdk-dev <jdk-dev at openjdk.java.net>
Subject: [CAUTION] CFV: New JDK Reviewer: Richard Reingruber

Hi,

I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.

Richard is a long-time member of the Java VM Team at SAP and has
contributed over 30 changes to the JDK project[1].

Recently, he has concentrated on JVMTI and compiler optimizations,
improving performance when JVMTI capabilities are required. He
identified and fixed a row of issues with JVMTI. [2]
He has built up a deep knowledge of the various synchronization
mechanisms in the VM and reviewed a row of complex changes
in this area[3].

Before, he has worked on platform ports for SAPs internal JVM.
Among many other, the s390 C1 compiler and template interpreter
in OpenJDK were originally ported by him.
He has worked on improving CMS and did a lot of work on
G1. He implemented the SAP Profiler Tool for G1.

Richard is a very pertinacious engineer solving any problem
that gets into his hands and will be an enrichment for the
OpenJDK as reviewer.



Votes are due by 18:00 GMT on Nov 30th 2020.



Only current JDK Project Reviewers [4] are eligible to vote on this

nomination.  Votes must be cast in the open by replying to this mailing

list.



For Lazy Consensus voting instructions, see [5].


Best regards,
  Goetz.



[1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits

[2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2

8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken

https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92

[3] https://github.com/openjdk/jdk/search?q=rrich&type=commits

[4] https://openjdk.java.net/census

[5] https://openjdk.java.net/projects/#committer-vote


From dmitry.markov at oracle.com  Mon Nov  9 10:06:45 2020
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 9 Nov 2020 10:06:45 +0000
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <9FF1F2EA-9B1E-45D9-8849-15CCE25B37C2@oracle.com>

Vote: Yes

Regards,
Dmitry

> On 6 Nov 2020, at 17:48, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
> 
> Kiran has been working primarily in the core-libs areas of the JDK. He has contributed a range of fixes to the JDK Project [0].
> 
> Votes are due by 18:00 GMT on Nov 20th 2020.
> 
> Only current JDK Project Committers [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> regards,
> Sean.
> 
> [0] https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> 


From thomas.stuefe at gmail.com  Mon Nov  9 10:17:39 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 9 Nov 2020 11:17:39 +0100
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUy=vR1PuFsTOzGW-URWCmye0CAMVtOkhWKcHqE0DzYFKg@mail.gmail.com>

Vote: yes.

On Mon, Nov 9, 2020 at 10:33 AM Lindenmaier, Goetz <
goetz.lindenmaier at sap.com> wrote:

> Hi,
>
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
>
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
>
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
>
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
>
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
>
>
>
> Votes are due by 18:00 GMT on Nov 30th 2020.
>
>
>
> Only current JDK Project Reviewers [4] are eligible to vote on this
>
> nomination.  Votes must be cast in the open by replying to this mailing
>
> list.
>
>
>
> For Lazy Consensus voting instructions, see [5].
>
>
> Best regards,
>   Goetz.
>
>
>
> [1]
> https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
>
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence
> of JVMTI Agents
>
>
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
>
> 8230677: Should disable Escape Analysis if JVMTI capability
> can_get_owned_monitor_info was taken
>
>
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
>
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
>
> [4] https://openjdk.java.net/census
>
> [5] https://openjdk.java.net/projects/#committer-vote
>
>

From erik.osterlund at oracle.com  Mon Nov  9 10:26:39 2020
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 9 Nov 2020 11:26:39 +0100
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <1402e465-1f27-0580-9661-152afcbdd1ff@oracle.com>

Vote: yes

/Erik

On 2020-11-09 10:32, Lindenmaier, Goetz wrote:
> Hi,
>
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
>
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
>
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
>
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
>
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
>
>
>
> Votes are due by 18:00 GMT on Nov 30th 2020.
>
>
>
> Only current JDK Project Reviewers [4] are eligible to vote on this
>
> nomination.  Votes must be cast in the open by replying to this mailing
>
> list.
>
>
>
> For Lazy Consensus voting instructions, see [5].
>
>
> Best regards,
>    Goetz.
>
>
>
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
>
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
>
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
>
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
>
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
>
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
>
> [4] https://openjdk.java.net/census
>
> [5] https://openjdk.java.net/projects/#committer-vote
>


From vladimir.x.ivanov at oracle.com  Mon Nov  9 10:30:08 2020
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 9 Nov 2020 13:30:08 +0300
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <d070170c-7790-eaa1-f287-b951e298595c@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

On 09.11.2020 12:32, Lindenmaier, Goetz wrote:
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.

From dean.long at oracle.com  Mon Nov  9 11:57:33 2020
From: dean.long at oracle.com (Dean Long)
Date: Mon, 9 Nov 2020 03:57:33 -0800
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <3d944920-ee59-13a1-f545-d0098890a7ff@oracle.com>

Vote: yes

dl

On 11/9/20 1:32 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
>
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
>
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
>
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
>
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
>
>
>
> Votes are due by 18:00 GMT on Nov 30th 2020.
>
>
>
> Only current JDK Project Reviewers [4] are eligible to vote on this
>
> nomination.  Votes must be cast in the open by replying to this mailing
>
> list.
>
>
>
> For Lazy Consensus voting instructions, see [5].
>
>
> Best regards,
>    Goetz.
>
>
>
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
>
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
>
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
>
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
>
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
>
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
>
> [4] https://openjdk.java.net/census
>
> [5] https://openjdk.java.net/projects/#committer-vote
>


From coleen.phillimore at oracle.com  Mon Nov  9 12:29:17 2020
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 9 Nov 2020 07:29:17 -0500
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <61a1213d-7f97-32a4-8eb7-6501a5452daf@oracle.com>

Vote: yes

On 11/9/20 4:32 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
>
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
>
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
>
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
>
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
>
>
>
> Votes are due by 18:00 GMT on Nov 30th 2020.
>
>
>
> Only current JDK Project Reviewers [4] are eligible to vote on this
>
> nomination.  Votes must be cast in the open by replying to this mailing
>
> list.
>
>
>
> For Lazy Consensus voting instructions, see [5].
>
>
> Best regards,
>    Goetz.
>
>
>
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
>
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
>
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
>
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
>
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
>
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
>
> [4] https://openjdk.java.net/census
>
> [5] https://openjdk.java.net/projects/#committer-vote
>


From zgu at redhat.com  Mon Nov  9 12:57:25 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 9 Nov 2020 07:57:25 -0500
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <7d922016-20c6-3ed4-d6b3-9a094c818c61@redhat.com>

Vote: yes

-Zhengyu

On 11/9/20 4:32 AM, Lindenmaier, Goetz wrote:
> Hi,
> 
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
> 
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
> 
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
> 
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
> 
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
> 
> 
> 
> Votes are due by 18:00 GMT on Nov 30th 2020.
> 
> 
> 
> Only current JDK Project Reviewers [4] are eligible to vote on this
> 
> nomination.  Votes must be cast in the open by replying to this mailing
> 
> list.
> 
> 
> 
> For Lazy Consensus voting instructions, see [5].
> 
> 
> Best regards,
>    Goetz.
> 
> 
> 
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
> 
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
> 
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
> 
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
> 
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
> 
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
> 
> [4] https://openjdk.java.net/census
> 
> [5] https://openjdk.java.net/projects/#committer-vote
> 


From harold.seigel at oracle.com  Mon Nov  9 13:36:39 2020
From: harold.seigel at oracle.com (Harold Seigel)
Date: Mon, 9 Nov 2020 08:36:39 -0500
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <9183ebf6-3318-7fae-a4af-8912c77e20d7@oracle.com>

Vote: Yes

Harold

On 11/9/2020 4:32 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
>
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
>
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
>
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
>
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
>
>
>
> Votes are due by 18:00 GMT on Nov 30th 2020.
>
>
>
> Only current JDK Project Reviewers [4] are eligible to vote on this
>
> nomination.  Votes must be cast in the open by replying to this mailing
>
> list.
>
>
>
> For Lazy Consensus voting instructions, see [5].
>
>
> Best regards,
>    Goetz.
>
>
>
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
>
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
>
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
>
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
>
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
>
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
>
> [4] https://openjdk.java.net/census
>
> [5] https://openjdk.java.net/projects/#committer-vote
>

From daniel.daugherty at oracle.com  Mon Nov  9 15:07:02 2020
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 9 Nov 2020 10:07:02 -0500
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <621e8c25-d4a5-a20e-2d07-e964951d3124@oracle.com>

Vote: yes

Dan

P.S.
Good choice for word of the day: pertinacious

On 11/9/20 4:32 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
>
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
>
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
>
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
>
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
>
>
>
> Votes are due by 18:00 GMT on Nov 30th 2020.
>
>
>
> Only current JDK Project Reviewers [4] are eligible to vote on this
>
> nomination.  Votes must be cast in the open by replying to this mailing
>
> list.
>
>
>
> For Lazy Consensus voting instructions, see [5].
>
>
> Best regards,
>    Goetz.
>
>
>
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
>
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
>
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
>
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
>
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
>
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
>
> [4] https://openjdk.java.net/census
>
> [5] https://openjdk.java.net/projects/#committer-vote
>


From zhaixiang at loongson.cn  Mon Nov  9 15:48:45 2020
From: zhaixiang at loongson.cn (Leslie Zhai)
Date: Mon, 9 Nov 2020 23:48:45 +0800
Subject: [RFC] Introduce BreakAtCompileId
Message-ID: <a64ef255-4a68-f594-ddec-a448b4c6d9bd@loongson.cn>

Hi,

OptoBreakpoint is very useful for debugging C2 compiler when porting 
some cpu for jdk8u. It is able to `b breakpoint` for breaking at the 
prolog about for example Compile_id = 2. But when fixed several bugs for 
C2, it needs to press `c` times and times again for reaching the proper 
Compile_id.

I `grep` Opto related options.? But there is no such one to break at the 
precise Compile_id.? Please teach me if there was :)

So here comes BreakAtCompileId. It is able to break at the precise 
Compile_id which you want to debug.


gdb -ex=r --args $JAVA -Xcomp -XX:+PrintCompilation 
-XX:BreakAtCompileId=430? -version


(gdb) b breakpoint
Breakpoint 1 at 0x7ffff633b0d0: breakpoint. (133 locations)

 ?? 6333? 433?????? 3 java.util.ImmutableCollections$List12::get (35 
bytes)?? made not entrant

Thread 2 "java" hit Breakpoint 1, 0x00007ffff711f410 in os::breakpoint() 
() at /home/zhaixiang/projects
452???????? if (pslash != NULL) {
(gdb) si
0x00007fffe01b46d1 in ?? ()
(gdb) x/22i $pc-44
 ?? 0x7fffe01b46a5:????? shl??? $0x3,%edx
 ?? 0x7fffe01b46a8:????? movabs $0x800000000,%r11
 ?? 0x7fffe01b46b2:????? add??? %r11,%r10
 ?? 0x7fffe01b46b5:????? cmp??? %r10,%rax
 ?? 0x7fffe01b46b8:????? jne??? 0x7fffd87cf920
 ?? 0x7fffe01b46be:????? nop
 ?? 0x7fffe01b46bf:????? nop
 ?? 0x7fffe01b46c0:????? mov??? %eax,-0x16000(%rsp)
 ?? 0x7fffe01b46c7:????? push?? %rbp
 ?? 0x7fffe01b46c8:????? sub??? $0x10,%rsp
 ?? 0x7fffe01b46cc:????? callq? 0x7ffff711f410 <_ZN2os10breakpointEv>
=> 0x7fffe01b46d1:????? mov??? 0xc(%rsi),%r11d
 ?? 0x7fffe01b46d5:????? mov??? 0x10(%rsi),%r10d
 ?? 0x7fffe01b46d9:????? cmp??? %r11d,%r10d
 ?? 0x7fffe01b46dc:????? je???? 0x7fffe01b46f6
 ?? 0x7fffe01b46de:????? mov??? $0x1,%eax
 ?? 0x7fffe01b46e3:????? add??? $0x10,%rsp
 ?? 0x7fffe01b46e7:????? pop??? %rbp
 ?? 0x7fffe01b46e8:????? cmp??? 0x128(%r15),%rsp
 ?? 0x7fffe01b46ef:????? ja???? 0x7fffe01b46fa
 ?? 0x7fffe01b46f5:????? retq
 ?? 0x7fffe01b46f6:????? xor??? %eax,%eax
(gdb) i r
rax??????????? 0x7fffe01b46c0????? 140736953272000
rbx??????????? 0x8004699e8???????? 34364365288
rcx??????????? 0x1???????????????? 1
rdx??????????? 0x7fffc5068980????? 140736498928000
rsi??????????? 0x62a020b40???????? 26474580800
rdi??????????? 0x1???????????????? 1
rbp??????????? 0x7ffff5a668d0????? 0x7ffff5a668d0
rsp??????????? 0x7ffff5a66290????? 0x7ffff5a66290
r8???????????? 0x80008eeb0???????? 34360323760
r9???????????? 0x7ffb4cf60???????? 34354810720
r10??????????? 0x800012488???????? 34359813256
r11??????????? 0x800000000???????? 34359738368
r12??????????? 0x0???????????????? 0
r13??????????? 0x7292dae5????????? 1922226917
r14??????????? 0x62a020818???????? 26474579992
r15??????????? 0x7ffff00271e0????? 140737220080096
rip??????????? 0x7fffe01b46d1????? 0x7fffe01b46d1
eflags???????? 0x206?????????????? [ PF IF ]
cs???????????? 0x33??????????????? 51
ss???????????? 0x2b??????????????? 43
ds???????????? 0x0???????????????? 0
es???????????? 0x0???????????????? 0
fs???????????? 0x0???????????????? 0
gs???????????? 0x0???????????????? 0


Thanks,
Leslie Zhai


From matthias.baesken at sap.com  Mon Nov  9 16:00:38 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 9 Nov 2020 16:00:38 +0000
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <3d944920-ee59-13a1-f545-d0098890a7ff@oracle.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <3d944920-ee59-13a1-f545-d0098890a7ff@oracle.com>
Message-ID: <AM0PR02MB54120B8E3C69D4D0317AD73C93EA0@AM0PR02MB5412.eurprd02.prod.outlook.com>


Vote: yes


Best regards, Matthias

On 11/9/20 1:32 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
>
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
>
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
>
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
>
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
>
>
>
> Votes are due by 18:00 GMT on Nov 30th 2020.
>
>
>
> Only current JDK Project Reviewers [4] are eligible to vote on this
>
> nomination.  Votes must be cast in the open by replying to this mailing
>
> list.
>
>
>
> For Lazy Consensus voting instructions, see [5].
>
>
> Best regards,
>    Goetz.
>
>
>
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
>
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
>
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
>
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
>
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
>
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
>
> [4] https://openjdk.java.net/census
>
> [5] https://openjdk.java.net/projects/#committer-vote
>


From vladimir.kozlov at oracle.com  Mon Nov  9 16:41:16 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 9 Nov 2020 08:41:16 -0800
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <0D4ADAA7-C9B5-4354-B7D9-7DE69DD4DD21@oracle.com>

Vote: yes 

Thanks
Vladimir K

> On Nov 9, 2020, at 1:32 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> ?Hi,
> 
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
> 
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
> 
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
> 
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
> 
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
> 
> 
> 
> Votes are due by 18:00 GMT on Nov 30th 2020.
> 
> 
> 
> Only current JDK Project Reviewers [4] are eligible to vote on this
> 
> nomination.  Votes must be cast in the open by replying to this mailing
> 
> list.
> 
> 
> 
> For Lazy Consensus voting instructions, see [5].
> 
> 
> Best regards,
>  Goetz.
> 
> 
> 
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
> 
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
> 
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
> 
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
> 
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
> 
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
> 
> [4] https://openjdk.java.net/census
> 
> [5] https://openjdk.java.net/projects/#committer-vote
> 


From lois.foltan at oracle.com  Mon Nov  9 16:51:14 2020
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 9 Nov 2020 11:51:14 -0500
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <7aa63913-e32c-dc44-6a6f-c94f2faa7a34@oracle.com>

Vote: yes

Lois

On 11/9/2020 4:32 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
>
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
>
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
>
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
>
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
>
>
>
> Votes are due by 18:00 GMT on Nov 30th 2020.
>
>
>
> Only current JDK Project Reviewers [4] are eligible to vote on this
>
> nomination.  Votes must be cast in the open by replying to this mailing
>
> list.
>
>
>
> For Lazy Consensus voting instructions, see [5].
>
>
> Best regards,
>    Goetz.
>
>
>
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
>
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
>
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
>
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
>
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
>
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
>
> [4] https://openjdk.java.net/census
>
> [5] https://openjdk.java.net/projects/#committer-vote
>


From daniel.fuchs at oracle.com  Mon Nov  9 19:01:51 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 9 Nov 2020 19:01:51 +0000
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <eff5d7c5-ce5b-b91d-0cc9-587c9c763246@oracle.com>

Vote: Yes

On 06/11/2020 17:48, Se?n Coffey wrote:
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.

From david.holmes at oracle.com  Mon Nov  9 22:10:02 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Nov 2020 08:10:02 +1000
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <8127a445-0e4d-faed-4cd4-d979b6a5e711@oracle.com>

Vote: yes

David

On 9/11/2020 7:32 pm, Lindenmaier, Goetz wrote:
> Hi,
> 
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
> 
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
> 
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
> 
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
> 
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
> 
> 
> 
> Votes are due by 18:00 GMT on Nov 30th 2020.
> 
> 
> 
> Only current JDK Project Reviewers [4] are eligible to vote on this
> 
> nomination.  Votes must be cast in the open by replying to this mailing
> 
> list.
> 
> 
> 
> For Lazy Consensus voting instructions, see [5].
> 
> 
> Best regards,
>    Goetz.
> 
> 
> 
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
> 
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
> 
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
> 
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
> 
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
> 
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
> 
> [4] https://openjdk.java.net/census
> 
> [5] https://openjdk.java.net/projects/#committer-vote
> 

From mikael.vidstedt at oracle.com  Mon Nov  9 22:24:57 2020
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 9 Nov 2020 14:24:57 -0800
Subject: [RFC] Introduce BreakAtCompileId
In-Reply-To: <a64ef255-4a68-f594-ddec-a448b4c6d9bd@loongson.cn>
References: <a64ef255-4a68-f594-ddec-a448b4c6d9bd@loongson.cn>
Message-ID: <F2B188E9-D4B9-4260-946F-FA33006CE224@oracle.com>


Please take this to hotspot-dev-compiler if you want to continue the discussion.


FWIW ?continue? does take an argument, would that work for your use case?

(gdb) help continue
Continue program being debugged, after signal or breakpoint.
Usage: continue [N]
If proceeding from breakpoint, a number N may be used as an argument,
which means to set the ignore count of that breakpoint to N - 1 (so that
the breakpoint won't break until the Nth time it is reached).

If non-stop mode is enabled, continue only the current thread,
otherwise all the threads in the program are continued.  To
continue all stopped threads in non-stop mode, use the -a option.
Specifying -a and an ignore count simultaneously is an error.


Cheers,
Mikael


> On Nov 9, 2020, at 7:48 AM, Leslie Zhai <zhaixiang at loongson.cn> wrote:
> 
> Hi,
> 
> OptoBreakpoint is very useful for debugging C2 compiler when porting some cpu for jdk8u. It is able to `b breakpoint` for breaking at the prolog about for example Compile_id = 2. But when fixed several bugs for C2, it needs to press `c` times and times again for reaching the proper Compile_id.
> 
> I `grep` Opto related options.  But there is no such one to break at the precise Compile_id.  Please teach me if there was :)
> 
> So here comes BreakAtCompileId. It is able to break at the precise Compile_id which you want to debug.
> 
> 
> gdb -ex=r --args $JAVA -Xcomp -XX:+PrintCompilation -XX:BreakAtCompileId=430  -version
> 
> 
> (gdb) b breakpoint
> Breakpoint 1 at 0x7ffff633b0d0: breakpoint. (133 locations)
> 
>    6333  433       3 java.util.ImmutableCollections$List12::get (35 bytes)   made not entrant
> 
> Thread 2 "java" hit Breakpoint 1, 0x00007ffff711f410 in os::breakpoint() () at /home/zhaixiang/projects
> 452         if (pslash != NULL) {
> (gdb) si
> 0x00007fffe01b46d1 in ?? ()
> (gdb) x/22i $pc-44
>    0x7fffe01b46a5:      shl    $0x3,%edx
>    0x7fffe01b46a8:      movabs $0x800000000,%r11
>    0x7fffe01b46b2:      add    %r11,%r10
>    0x7fffe01b46b5:      cmp    %r10,%rax
>    0x7fffe01b46b8:      jne    0x7fffd87cf920
>    0x7fffe01b46be:      nop
>    0x7fffe01b46bf:      nop
>    0x7fffe01b46c0:      mov    %eax,-0x16000(%rsp)
>    0x7fffe01b46c7:      push   %rbp
>    0x7fffe01b46c8:      sub    $0x10,%rsp
>    0x7fffe01b46cc:      callq  0x7ffff711f410 <_ZN2os10breakpointEv>
> => 0x7fffe01b46d1:      mov    0xc(%rsi),%r11d
>    0x7fffe01b46d5:      mov    0x10(%rsi),%r10d
>    0x7fffe01b46d9:      cmp    %r11d,%r10d
>    0x7fffe01b46dc:      je     0x7fffe01b46f6
>    0x7fffe01b46de:      mov    $0x1,%eax
>    0x7fffe01b46e3:      add    $0x10,%rsp
>    0x7fffe01b46e7:      pop    %rbp
>    0x7fffe01b46e8:      cmp    0x128(%r15),%rsp
>    0x7fffe01b46ef:      ja     0x7fffe01b46fa
>    0x7fffe01b46f5:      retq
>    0x7fffe01b46f6:      xor    %eax,%eax
> (gdb) i r
> rax            0x7fffe01b46c0      140736953272000
> rbx            0x8004699e8         34364365288
> rcx            0x1                 1
> rdx            0x7fffc5068980      140736498928000
> rsi            0x62a020b40         26474580800
> rdi            0x1                 1
> rbp            0x7ffff5a668d0      0x7ffff5a668d0
> rsp            0x7ffff5a66290      0x7ffff5a66290
> r8             0x80008eeb0         34360323760
> r9             0x7ffb4cf60         34354810720
> r10            0x800012488         34359813256
> r11            0x800000000         34359738368
> r12            0x0                 0
> r13            0x7292dae5          1922226917
> r14            0x62a020818         26474579992
> r15            0x7ffff00271e0      140737220080096
> rip            0x7fffe01b46d1      0x7fffe01b46d1
> eflags         0x206               [ PF IF ]
> cs             0x33                51
> ss             0x2b                43
> ds             0x0                 0
> es             0x0                 0
> fs             0x0                 0
> gs             0x0                 0
> 
> 
> Thanks,
> Leslie Zhai
> 


From christoph.langer at sap.com  Tue Nov 10 07:45:25 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 10 Nov 2020 07:45:25 +0000
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3138AACA3F9AC7F082C87D898AE90@AM4PR02MB3138.eurprd02.prod.outlook.com>

Vote:yes

Cheers
Christoph

> -----Original Message-----
> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Lindenmaier,
> Goetz
> Sent: Montag, 9. November 2020 10:32
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: [CAUTION] CFV: New JDK Reviewer: Richard Reingruber
> 
> Hi,
> 
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
> 
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
> 
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
> 
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
> 
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
> 
> 
> 
> Votes are due by 18:00 GMT on Nov 30th 2020.
> 
> 
> 
> Only current JDK Project Reviewers [4] are eligible to vote on this
> 
> nomination.  Votes must be cast in the open by replying to this mailing
> 
> list.
> 
> 
> 
> For Lazy Consensus voting instructions, see [5].
> 
> 
> Best regards,
>   Goetz.
> 
> 
> 
> [1] https://github.com/openjdk/jdk/search?q=author-
> name%3A%22Richard+Reingruber%22&type=commits
> 
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence
> of JVMTI Agents
> 
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe2
> 33f8764c2
> 
> 8230677: Should disable Escape Analysis if JVMTI capability
> can_get_owned_monitor_info was taken
> 
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b5474124
> 3c98adcc92
> 
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
> 
> [4] https://openjdk.java.net/census
> 
> [5] https://openjdk.java.net/projects/#committer-vote


From abdul.kolarkunnu at oracle.com  Tue Nov 10 07:51:25 2020
From: abdul.kolarkunnu at oracle.com (abdul.kolarkunnu at oracle.com)
Date: Tue, 10 Nov 2020 13:21:25 +0530
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <db319667-07ef-d793-7581-52844fdee8a1@oracle.com>

Vote: yes

-Muneer

On 06/11/20 11:18 pm, Se?n Coffey wrote:
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer.
>
> Kiran has been working primarily in the core-libs areas of the JDK. He 
> has contributed a range of fixes to the JDK Project [0].
>
> Votes are due by 18:00 GMT on Nov 20th 2020.
>
> Only current JDK Project Committers [1] are eligible to vote on this 
> nomination.? Votes must be cast in the open by replying to this 
> mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> regards,
> Sean.
>
> [0] 
> https://github.com/openjdk/jdk/search?p=1&q=author-name%3AKiran&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
>

From tobias.hartmann at oracle.com  Tue Nov 10 12:57:49 2020
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 10 Nov 2020 13:57:49 +0100
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <c7d6741e-fd97-6f49-ef7c-17eab13e1f79@oracle.com>

Vote: yes

Best regards,
Tobias

On 09.11.20 10:32, Lindenmaier, Goetz wrote:
> Hi,
> 
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
> 
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
> 
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
> 
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
> 
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
> 
> 
> 
> Votes are due by 18:00 GMT on Nov 30th 2020.
> 
> 
> 
> Only current JDK Project Reviewers [4] are eligible to vote on this
> 
> nomination.  Votes must be cast in the open by replying to this mailing
> 
> list.
> 
> 
> 
> For Lazy Consensus voting instructions, see [5].
> 
> 
> Best regards,
>   Goetz.
> 
> 
> 
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
> 
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
> 
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
> 
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
> 
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
> 
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
> 
> [4] https://openjdk.java.net/census
> 
> [5] https://openjdk.java.net/projects/#committer-vote
> 

From alexey.ivanov at oracle.com  Tue Nov 10 14:41:52 2020
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 10 Nov 2020 14:41:52 +0000
Subject: CFV: New JDK Committer: Kiran Ravikumar
In-Reply-To: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
References: <a1faa4d9-fc30-41b9-6383-08d6468e8a6c@oracle.com>
Message-ID: <a6c97f56-1f43-8eeb-5935-a59c81a0123c@oracle.com>

Vote: yes

On 06/11/2020 17:48, Se?n Coffey wrote:
> I hereby nominate Kiran Ravikumar (kravikumar) to JDK Project Committer. 
-- 
Regards,
Alexey

From hohensee at amazon.com  Tue Nov 10 16:32:16 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 10 Nov 2020 16:32:16 +0000
Subject: CFV: New JDK Reviewer: Richard Reingruber
Message-ID: <82700E2D-0BD4-4F40-AEE1-490B4A93FE1F@amazon.com>

Vote: yes

?On 11/9/20, 6:58 AM, "jdk-dev on behalf of Lindenmaier, Goetz" <jdk-dev-retn at openjdk.java.net on behalf of goetz.lindenmaier at sap.com> wrote:

    Hi,

    I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.

    Richard is a long-time member of the Java VM Team at SAP and has
    contributed over 30 changes to the JDK project[1].

    Recently, he has concentrated on JVMTI and compiler optimizations,
    improving performance when JVMTI capabilities are required. He
    identified and fixed a row of issues with JVMTI. [2]
    He has built up a deep knowledge of the various synchronization
    mechanisms in the VM and reviewed a row of complex changes
    in this area[3].

    Before, he has worked on platform ports for SAPs internal JVM.
    Among many other, the s390 C1 compiler and template interpreter
    in OpenJDK were originally ported by him.
    He has worked on improving CMS and did a lot of work on
    G1. He implemented the SAP Profiler Tool for G1.

    Richard is a very pertinacious engineer solving any problem
    that gets into his hands and will be an enrichment for the
    OpenJDK as reviewer.



    Votes are due by 18:00 GMT on Nov 30th 2020.



    Only current JDK Project Reviewers [4] are eligible to vote on this

    nomination.  Votes must be cast in the open by replying to this mailing

    list.



    For Lazy Consensus voting instructions, see [5].


    Best regards,
      Goetz.



    [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits

    [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

    https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2

    8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken

    https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92

    [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits

    [4] https://openjdk.java.net/census

    [5] https://openjdk.java.net/projects/#committer-vote



From mark.reinhold at oracle.com  Thu Nov 12 22:30:20 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 12 Nov 2020 14:30:20 -0800 (PST)
Subject: JEP proposed to target JDK 16: 389: Foreign Linker API (Incubator)
Message-ID: <20201112223020.68F513C9C9A@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 16:

  389: Foreign Linker API (Incubator)
       https://openjdk.java.net/jeps/389

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Thursday, 19 November, or if they?re raised
and then satisfactorily answered, then per the JEP 2.0 process proposal
[2] I?ll target this JEP to JDK 16.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From v.dijk.bas at gmail.com  Sun Nov 15 21:37:54 2020
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Sun, 15 Nov 2020 22:37:54 +0100
Subject: hg.openjdk.java.net down
Message-ID: <CADLz5wX+43Hk2E2tFFCn_rYTXxGDB0g1DPBMA8Oe-zQW6t71kA@mail.gmail.com>

Hi,

hg.openjdk.java.net is returning a 502 "Bad Gateway" error.

Maybe hgweb.fcgi dumped core and went into maintenance mode again like what
happened in March[1]. Could it be restarted please?

Regards,

Bas

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/004159.html

From v.dijk.bas at gmail.com  Sun Nov 15 23:07:36 2020
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Mon, 16 Nov 2020 00:07:36 +0100
Subject: hg.openjdk.java.net down
In-Reply-To: <3d2e4a06-2e55-9bf8-241e-c5f0bcaf390c@oracle.com>
References: <CADLz5wX+43Hk2E2tFFCn_rYTXxGDB0g1DPBMA8Oe-zQW6t71kA@mail.gmail.com>
 <3d2e4a06-2e55-9bf8-241e-c5f0bcaf390c@oracle.com>
Message-ID: <CADLz5wXpXu2gv4hDiQnngpzmbURUpS6tAL=u0OGUMiZMKGJNDg@mail.gmail.com>

Thank you Tim!

On Sun, 15 Nov 2020 at 23:46, Tim Bell <tim.bell at oracle.com> wrote:

> Hello
>
> > hg.openjdk.java.net <http://hg.openjdk.java.net> is returning a 502
> "Bad
> > Gateway" error.
>
> I restarted hgweb.fcgi.
>
>    http://hg.openjdk.java.net looks better now.
>
> Please let us know at ops at openjdk.java.net if you have any further
> difficulties.
>
> Tim Bell
>

From tim.bell at oracle.com  Sun Nov 15 22:44:28 2020
From: tim.bell at oracle.com (Tim Bell)
Date: Sun, 15 Nov 2020 14:44:28 -0800
Subject: hg.openjdk.java.net down
In-Reply-To: <CADLz5wX+43Hk2E2tFFCn_rYTXxGDB0g1DPBMA8Oe-zQW6t71kA@mail.gmail.com>
References: <CADLz5wX+43Hk2E2tFFCn_rYTXxGDB0g1DPBMA8Oe-zQW6t71kA@mail.gmail.com>
Message-ID: <3d2e4a06-2e55-9bf8-241e-c5f0bcaf390c@oracle.com>

Hello

> hg.openjdk.java.net <http://hg.openjdk.java.net> is returning a 502 "Bad 
> Gateway" error.

I restarted hgweb.fcgi.

   http://hg.openjdk.java.net looks better now.

Please let us know at ops at openjdk.java.net if you have any further 
difficulties.

Tim Bell

From sgehwolf at redhat.com  Mon Nov 16 08:55:01 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 16 Nov 2020 09:55:01 +0100
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <26ec76598d0f581b38419a3b4f25ce030267777c.camel@redhat.com>

Vote: yes

On Mon, 2020-11-09 at 09:32 +0000, Lindenmaier, Goetz wrote:
> Hi,
> 
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
> 
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
> 
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
> 
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
> 
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
> 
> 
> 
> Votes are due by 18:00 GMT on Nov 30th 2020.
> 
> 
> 
> Only current JDK Project Reviewers [4] are eligible to vote on this
> 
> nomination.  Votes must be cast in the open by replying to this mailing
> 
> list.
> 
> 
> 
> For Lazy Consensus voting instructions, see [5].
> 
> 
> Best regards,
>   Goetz.
> 
> 
> 
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
> 
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
> 
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
> 
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
> 
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
> 
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
> 
> [4] https://openjdk.java.net/census
> 
> [5] https://openjdk.java.net/projects/#committer-vote
> 


From volker.simonis at gmail.com  Tue Nov 17 18:49:12 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 17 Nov 2020 19:49:12 +0100
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <CA+3eh12uqBAXPJGcvvz1E6NUqeRo+iFLwyYNkf7g2ag2P-9Ytg@mail.gmail.com>

Vote: yes

PS: well deserved :)

On Mon, Nov 9, 2020 at 10:34 AM Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
>
> Hi,
>
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
>
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
>
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
>
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
>
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
>
>
>
> Votes are due by 18:00 GMT on Nov 30th 2020.
>
>
>
> Only current JDK Project Reviewers [4] are eligible to vote on this
>
> nomination.  Votes must be cast in the open by replying to this mailing
>
> list.
>
>
>
> For Lazy Consensus voting instructions, see [5].
>
>
> Best regards,
>   Goetz.
>
>
>
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
>
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
>
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
>
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
>
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
>
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
>
> [4] https://openjdk.java.net/census
>
> [5] https://openjdk.java.net/projects/#committer-vote
>

From nils.eliasson at oracle.com  Wed Nov 18 09:59:07 2020
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Wed, 18 Nov 2020 10:59:07 +0100
Subject: [RFC] Introduce BreakAtCompileId
In-Reply-To: <a64ef255-4a68-f594-ddec-a448b4c6d9bd@loongson.cn>
References: <a64ef255-4a68-f594-ddec-a448b4c6d9bd@loongson.cn>
Message-ID: <fac66e21-d95f-afb7-3be0-6264358c1748@oracle.com>

Hi,

There are already some flags that control this.

 From globals.hpp:

develop(intx, CIBreakAtOSR, -1,
 ????????? "The id of osr compilation to break at")

 ? develop(intx, CIBreakAt, -1,
 ????????? "The id of compilation to break at")


Best regards,
Nils Eliasson

On 2020-11-09 16:48, Leslie Zhai wrote:
> Hi,
>
> OptoBreakpoint is very useful for debugging C2 compiler when porting 
> some cpu for jdk8u. It is able to `b breakpoint` for breaking at the 
> prolog about for example Compile_id = 2. But when fixed several bugs 
> for C2, it needs to press `c` times and times again for reaching the 
> proper Compile_id.
>
> I `grep` Opto related options.? But there is no such one to break at 
> the precise Compile_id.? Please teach me if there was :)
>
> So here comes BreakAtCompileId. It is able to break at the precise 
> Compile_id which you want to debug.
>
>
> gdb -ex=r --args $JAVA -Xcomp -XX:+PrintCompilation 
> -XX:BreakAtCompileId=430? -version
>
>
> (gdb) b breakpoint
> Breakpoint 1 at 0x7ffff633b0d0: breakpoint. (133 locations)
>
> ?? 6333? 433?????? 3 java.util.ImmutableCollections$List12::get (35 
> bytes)?? made not entrant
>
> Thread 2 "java" hit Breakpoint 1, 0x00007ffff711f410 in 
> os::breakpoint() () at /home/zhaixiang/projects
> 452???????? if (pslash != NULL) {
> (gdb) si
> 0x00007fffe01b46d1 in ?? ()
> (gdb) x/22i $pc-44
> ?? 0x7fffe01b46a5:????? shl??? $0x3,%edx
> ?? 0x7fffe01b46a8:????? movabs $0x800000000,%r11
> ?? 0x7fffe01b46b2:????? add??? %r11,%r10
> ?? 0x7fffe01b46b5:????? cmp??? %r10,%rax
> ?? 0x7fffe01b46b8:????? jne??? 0x7fffd87cf920
> ?? 0x7fffe01b46be:????? nop
> ?? 0x7fffe01b46bf:????? nop
> ?? 0x7fffe01b46c0:????? mov??? %eax,-0x16000(%rsp)
> ?? 0x7fffe01b46c7:????? push?? %rbp
> ?? 0x7fffe01b46c8:????? sub??? $0x10,%rsp
> ?? 0x7fffe01b46cc:????? callq? 0x7ffff711f410 <_ZN2os10breakpointEv>
> => 0x7fffe01b46d1:????? mov??? 0xc(%rsi),%r11d
> ?? 0x7fffe01b46d5:????? mov??? 0x10(%rsi),%r10d
> ?? 0x7fffe01b46d9:????? cmp??? %r11d,%r10d
> ?? 0x7fffe01b46dc:????? je???? 0x7fffe01b46f6
> ?? 0x7fffe01b46de:????? mov??? $0x1,%eax
> ?? 0x7fffe01b46e3:????? add??? $0x10,%rsp
> ?? 0x7fffe01b46e7:????? pop??? %rbp
> ?? 0x7fffe01b46e8:????? cmp??? 0x128(%r15),%rsp
> ?? 0x7fffe01b46ef:????? ja???? 0x7fffe01b46fa
> ?? 0x7fffe01b46f5:????? retq
> ?? 0x7fffe01b46f6:????? xor??? %eax,%eax
> (gdb) i r
> rax??????????? 0x7fffe01b46c0????? 140736953272000
> rbx??????????? 0x8004699e8???????? 34364365288
> rcx??????????? 0x1???????????????? 1
> rdx??????????? 0x7fffc5068980????? 140736498928000
> rsi??????????? 0x62a020b40???????? 26474580800
> rdi??????????? 0x1???????????????? 1
> rbp??????????? 0x7ffff5a668d0????? 0x7ffff5a668d0
> rsp??????????? 0x7ffff5a66290????? 0x7ffff5a66290
> r8???????????? 0x80008eeb0???????? 34360323760
> r9???????????? 0x7ffb4cf60???????? 34354810720
> r10??????????? 0x800012488???????? 34359813256
> r11??????????? 0x800000000???????? 34359738368
> r12??????????? 0x0???????????????? 0
> r13??????????? 0x7292dae5????????? 1922226917
> r14??????????? 0x62a020818???????? 26474579992
> r15??????????? 0x7ffff00271e0????? 140737220080096
> rip??????????? 0x7fffe01b46d1????? 0x7fffe01b46d1
> eflags???????? 0x206?????????????? [ PF IF ]
> cs???????????? 0x33??????????????? 51
> ss???????????? 0x2b??????????????? 43
> ds???????????? 0x0???????????????? 0
> es???????????? 0x0???????????????? 0
> fs???????????? 0x0???????????????? 0
> gs???????????? 0x0???????????????? 0
>
>
> Thanks,
> Leslie Zhai
>


From christian.hagedorn at oracle.com  Wed Nov 18 12:48:06 2020
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Wed, 18 Nov 2020 13:48:06 +0100
Subject: CFV: New JDK Reviewer: Richard Reingruber
In-Reply-To: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29644E5B68B2485517D4D3D7ECEA0@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <bb8540fe-766b-c842-ea0c-7daa9740d64b@oracle.com>

Vote: yes

Best regards,
Christian

On 09.11.20 10:32, Lindenmaier, Goetz wrote:
> Hi,
> 
> I hereby nominate Richard Reingruber (rrich) to JDK Project Reviewer.
> 
> Richard is a long-time member of the Java VM Team at SAP and has
> contributed over 30 changes to the JDK project[1].
> 
> Recently, he has concentrated on JVMTI and compiler optimizations,
> improving performance when JVMTI capabilities are required. He
> identified and fixed a row of issues with JVMTI. [2]
> He has built up a deep knowledge of the various synchronization
> mechanisms in the VM and reviewed a row of complex changes
> in this area[3].
> 
> Before, he has worked on platform ports for SAPs internal JVM.
> Among many other, the s390 C1 compiler and template interpreter
> in OpenJDK were originally ported by him.
> He has worked on improving CMS and did a lot of work on
> G1. He implemented the SAP Profiler Tool for G1.
> 
> Richard is a very pertinacious engineer solving any problem
> that gets into his hands and will be an enrichment for the
> OpenJDK as reviewer.
> 
> 
> 
> Votes are due by 18:00 GMT on Nov 30th 2020.
> 
> 
> 
> Only current JDK Project Reviewers [4] are eligible to vote on this
> 
> nomination.  Votes must be cast in the open by replying to this mailing
> 
> list.
> 
> 
> 
> For Lazy Consensus voting instructions, see [5].
> 
> 
> Best regards,
>    Goetz.
> 
> 
> 
> [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Richard+Reingruber%22&type=commits
> 
> [2] 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
> 
> https://github.com/openjdk/jdk/commit/40f847e2fb5af957f1b416d2fe11fe233f8764c2
> 
> 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
> 
> https://github.com/openjdk/jdk/commit/a683592254d27d8f78da42b54741243c98adcc92
> 
> [3] https://github.com/openjdk/jdk/search?q=rrich&type=commits
> 
> [4] https://openjdk.java.net/census
> 
> [5] https://openjdk.java.net/projects/#committer-vote
> 

From joe.darcy at oracle.com  Thu Nov 19 21:13:56 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 19 Nov 2020 13:13:56 -0800
Subject: Reminder: JDK 16 rampdown 1 starts in three weeks, allow sufficient
 review time for CSRs
Message-ID: <4d0265b6-7eef-453c-575b-a6f5a4c53c56@oracle.com>

Hello,

A reminder that per the JDK 16 schedule

 ??? http://openjdk.java.net/projects/jdk/16/

rampdown 1 starts in three weeks, on Dec. 10, 2020. Please factor in 
sufficient time for CSR review for any remaining changes intended to be 
integrated by that milestone. The nominal CSR review latency per phase 
is one week; requests are often reviewed in less time, but more time may 
be needed for large requests or when many requests come in a short period.

Thanks,

-Joe


From mark.reinhold at oracle.com  Thu Nov 19 21:45:53 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 19 Nov 2020 13:45:53 -0800 (PST)
Subject: JEP proposed to target JDK 16: 396: Strongly Encapsulate JDK
 Internals by Default
Message-ID: <20201119214553.8F1E33CAAF2@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 16:

  396: Strongly Encapsulate JDK Internals by Default
       https://openjdk.java.net/jeps/396

  Summary: Strongly encapsulate all internal elements of the JDK by
  default, except for critical internal APIs such as sun.misc.Unsafe.
  Allow end users to choose the relaxed strong encapsulation that has
  been the default since JDK?9.

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Thursday, 26 November, or if they?re raised
and then satisfactorily answered, then per the JEP 2.0 process proposal
[2] I?ll target this JEP to JDK 16.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From thomas.stuefe at gmail.com  Fri Nov 20 16:22:15 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 20 Nov 2020 17:22:15 +0100
Subject: Why is java -version implemented in Java?
Message-ID: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>

Hi,

java -version seems to be called by scripts very frequently to get the java
version. Folks complain about the time that takes.

I always wondered, why is this implemented in java? Which requires the
whole jvm machinery to start up just to print the version information.

VersionProps.java seems not to be very complex; that information could have
been baked into the launcher, or the hotspot.

Or is using 'java -version' as a simple VM test just too convenient?

Thanks, Thomas

From Alan.Bateman at oracle.com  Fri Nov 20 18:08:07 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Nov 2020 18:08:07 +0000
Subject: Why is java -version implemented in Java?
In-Reply-To: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
Message-ID: <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>

On 20/11/2020 16:22, Thomas St?fe wrote:
> Hi,
>
> java -version seems to be called by scripts very frequently to get the java
> version. Folks complain about the time that takes.
>
> I always wondered, why is this implemented in java? Which requires the
> whole jvm machinery to start up just to print the version information.
>
> VersionProps.java seems not to be very complex; that information could have
> been baked into the launcher, or the hotspot.
>
> Or is using 'java -version' as a simple VM test just too convenient?
>
The alternative to scripts running `java -version` is to examine the 
`release` file in the top-level directory. Could the scripts that you've 
encountered be changed to look at that instead?

-Alan

From mark.reinhold at oracle.com  Fri Nov 20 18:17:14 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 20 Nov 2020 10:17:14 -0800
Subject: JEP proposed to target JDK 16: 389: Foreign Linker API (Incubator)
In-Reply-To: <20201112223020.68F513C9C9A@eggemoggin.niobe.net>
References: <20201112223020.68F513C9C9A@eggemoggin.niobe.net>
Message-ID: <20201120101714.58852395@eggemoggin.niobe.net>

2020/11/12 14:30:20 -0800, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 16:
> 
>   389: Foreign Linker API (Incubator)
>        https://openjdk.java.net/jeps/389
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Thursday, 19 November, or if they?re raised
> and then satisfactorily answered, then per the JEP 2.0 process proposal
> [2] I?ll target this JEP to JDK 16.

Hearing no objections, I?ve targeted this JEP to JDK 16.

- Mark

From volker.simonis at gmail.com  Fri Nov 20 18:38:06 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 20 Nov 2020 19:38:06 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
Message-ID: <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>

On Fri, Nov 20, 2020 at 7:08 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 20/11/2020 16:22, Thomas St?fe wrote:
> > Hi,
> >
> > java -version seems to be called by scripts very frequently to get the java
> > version. Folks complain about the time that takes.
> >
> > I always wondered, why is this implemented in java? Which requires the
> > whole jvm machinery to start up just to print the version information.
> >
> > VersionProps.java seems not to be very complex; that information could have
> > been baked into the launcher, or the hotspot.
> >
> > Or is using 'java -version' as a simple VM test just too convenient?
> >
> The alternative to scripts running `java -version` is to examine the
> `release` file in the top-level directory. Could the scripts that you've
> encountered be changed to look at that instead?

That's an alternative but not the answer to the question :)

I'm also not sure how "common" or "standard the "release" file is? I
know at least two popular distributions which don't have that file
while "-version" seems to be a documented and supported option.

I think there's probably a lot of history and legacy around "-version"
and it's implementation. It actually prints "many" versions, e.g. the
VM version, the class library version, etc.  Most of the "-version"
output is also exported as system properties and as such only
"generated" at runtime.

Maybe one solution could be to implement a short-cut into OpenJDK's
standard launcher to use the information from the "release" file if
that is present? That should be pretty safe as the times when you
could simple swap the VM in a JDK release are long gone :)

>
> -Alan

From thomas.stuefe at gmail.com  Fri Nov 20 19:44:50 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 20 Nov 2020 20:44:50 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
 <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
Message-ID: <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>

On Fri, Nov 20, 2020 at 7:39 PM Volker Simonis <volker.simonis at gmail.com>
wrote:

> On Fri, Nov 20, 2020 at 7:08 PM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
> >
> > On 20/11/2020 16:22, Thomas St?fe wrote:
> > > Hi,
> > >
> > > java -version seems to be called by scripts very frequently to get the
> java
> > > version. Folks complain about the time that takes.
> > >
> > > I always wondered, why is this implemented in java? Which requires the
> > > whole jvm machinery to start up just to print the version information.
> > >
> > > VersionProps.java seems not to be very complex; that information could
> have
> > > been baked into the launcher, or the hotspot.
> > >
> > > Or is using 'java -version' as a simple VM test just too convenient?
> > >
> > The alternative to scripts running `java -version` is to examine the
> > `release` file in the top-level directory. Could the scripts that you've
> > encountered be changed to look at that instead?
>
> That's an alternative but not the answer to the question :)
>
>
Yes, I was hoping for some background information about why we do it
this way.

I know about the "release" file, but this does not seem like an obvious
solution. I see this file mentioned as a way to quickly get the java
release info, but it seems so strange and non-obvious. I feel bad that
users have to even do that.

Also, to me, that file does not seem to correspond clearly with the
-version information.


> I'm also not sure how "common" or "standard the "release" file is? I
> know at least two popular distributions which don't have that file
> while "-version" seems to be a documented and supported option.
>
> I think there's probably a lot of history and legacy around "-version"
> and it's implementation. It actually prints "many" versions, e.g. the
> VM version, the class library version, etc.  Most of the "-version"
> output is also exported as system properties and as such only
> "generated" at runtime.
>
> Maybe one solution could be to implement a short-cut into OpenJDK's
> standard launcher to use the information from the "release" file if
> that is present? That should be pretty safe as the times when you
> could simple swap the VM in a JDK release are long gone :)
>
>
An even simpler way could be just to bake the release information as
strings into the java launcher and print those. No need to even open and
parse that file. j.l.VersionProps.java gets generated from a template, a
C-file with strings could be generated the same way.

But I am sure it's not that easy and I overlook something. Hence my
question.

Cheers, Thomas

From sean.coffey at oracle.com  Fri Nov 20 20:11:50 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 20 Nov 2020 20:11:50 +0000
Subject: Result: New JDK Committer : Kiran Ravikumar
Message-ID: <5785b076-f52b-ea57-9c3d-3f7654b72b3a@oracle.com>

Voting for Kiran Ravikumar [1] is now closed.

Yes: 16
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

regards,
Sean.

[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2020-November/004897.html


From david.holmes at oracle.com  Fri Nov 20 22:44:46 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 21 Nov 2020 08:44:46 +1000
Subject: Why is java -version implemented in Java?
In-Reply-To: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
Message-ID: <4383a30a-d658-b735-307a-d4bb334c9cf4@oracle.com>

Hi Thomas,

On 21/11/2020 2:22 am, Thomas St?fe wrote:
> Hi,
> 
> java -version seems to be called by scripts very frequently to get the java
> version. Folks complain about the time that takes.
> 
> I always wondered, why is this implemented in java? Which requires the
> whole jvm machinery to start up just to print the version information.

Some of that version information pertains to the JVM configuration which 
is affected by the runtime flags passed to it e.g.

Java HotSpot(TM) 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)

"Server", "mixed mode" and "sharing" are all dynamic.

There is static build information built into the libjvm binary that is 
accessed via -Xinternalversion:

Java HotSpot(TM) 64-Bit Server VM (14+36-1461) for linux-amd64 JRE 
(14+36-1461), built on Feb  6 2020 19:11:22 by "mach5one" with gcc 8.3.0

And of course there is a lot of history here - in particular hotspot 
express meant you needed to show distinct JDK and VM version information.

> VersionProps.java seems not to be very complex; that information could have
> been baked into the launcher, or the hotspot.
> 
> Or is using 'java -version' as a simple VM test just too convenient?

That is certainly useful! :)

Cheers,
David

> Thanks, Thomas
> 

From mbien42 at gmail.com  Fri Nov 20 22:46:38 2020
From: mbien42 at gmail.com (Michael Bien)
Date: Fri, 20 Nov 2020 23:46:38 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
 <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
 <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
Message-ID: <ad370a6f-6480-4dfe-1b58-33758bd46304@gmail.com>

On 20.11.20 20:44, Thomas St?fe wrote:
> On Fri, Nov 20, 2020 at 7:39 PM Volker Simonis <volker.simonis at gmail.com>
> wrote:
>
>> On Fri, Nov 20, 2020 at 7:08 PM Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>> On 20/11/2020 16:22, Thomas St?fe wrote:
>>>> Hi,
>>>>
>>>> java -version seems to be called by scripts very frequently to get the
>> java
>>>> version. Folks complain about the time that takes.
>>>>
>>>> I always wondered, why is this implemented in java? Which requires the
>>>> whole jvm machinery to start up just to print the version information.
>>>>
>>>> VersionProps.java seems not to be very complex; that information could
>> have
>>>> been baked into the launcher, or the hotspot.
>>>>
>>>> Or is using 'java -version' as a simple VM test just too convenient?
>>>>
>>> The alternative to scripts running `java -version` is to examine the
>>> `release` file in the top-level directory. Could the scripts that you've
>>> encountered be changed to look at that instead?
>> That's an alternative but not the answer to the question :)
>>
>>
> Yes, I was hoping for some background information about why we do it
> this way.
>
> I know about the "release" file, but this does not seem like an obvious
> solution. I see this file mentioned as a way to quickly get the java
> release info, but it seems so strange and non-obvious. I feel bad that
> users have to even do that.
>
> Also, to me, that file does not seem to correspond clearly with the
> -version information.
>
>
>> I'm also not sure how "common" or "standard the "release" file is? I
>> know at least two popular distributions which don't have that file
>> while "-version" seems to be a documented and supported option.
>>
>> I think there's probably a lot of history and legacy around "-version"
>> and it's implementation. It actually prints "many" versions, e.g. the
>> VM version, the class library version, etc.  Most of the "-version"
>> output is also exported as system properties and as such only
>> "generated" at runtime.
>>
>> Maybe one solution could be to implement a short-cut into OpenJDK's
>> standard launcher to use the information from the "release" file if
>> that is present? That should be pretty safe as the times when you
>> could simple swap the VM in a JDK release are long gone :)
>>
>>
> An even simpler way could be just to bake the release information as
> strings into the java launcher and print those. No need to even open and
> parse that file. j.l.VersionProps.java gets generated from a template, a
> C-file with strings could be generated the same way.
>
> But I am sure it's not that easy and I overlook something. Hence my
> question.

java -version does more than just printing static version Strings. It 
prints if class data sharing is active and which mode the JIT is in 
(mixed mode by default).

jdk-15.0.1_oracle/bin/java -version
openjdk version "15.0.1" 2020-10-20
OpenJDK Runtime Environment (build 15.0.1+9-18)
OpenJDK 64-Bit Server VM (build 15.0.1+9-18, mixed mode, sharing)


I am (ab)using it sometimes to test JDK features when i forget which 
distribution has what enabled.

java -Xshare:on -version

is going to fail if CDS is not properly set up.


java -XX:+UseShenandoahGC -version

is going to fail if its an Oracle JDK

...


I just wanted to mention this because i might not be the only one using 
-version as --dry-run equivalent.

best regards,

michael


>
> Cheers, Thomas



From Alan.Bateman at oracle.com  Sat Nov 21 08:20:28 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 21 Nov 2020 08:20:28 +0000
Subject: Why is java -version implemented in Java?
In-Reply-To: <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
 <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
 <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
Message-ID: <96cac743-3d69-4303-2906-b9e260d935a1@oracle.com>

On 20/11/2020 19:44, Thomas St?fe wrote:
> :
>
> I know about the "release" file, but this does not seem like an 
> obvious solution. I see this file mentioned as a way to quickly get 
> the java release info, but it seems so strange and non-obvious. I feel 
> bad that users have to even do that.
>

The release file was added (I think JDK 7) to allow humans and scripts 
easily identify the run-time image. Running `java -version` is not an 
option in many cases, esp. when there is a possibility that the image is 
for a different platform or architecture. I remember there were issues 
some scripts (and one IDE in particular) that was peeking into jvm.dll 
to get vendor information. More recently, the release file was extended 
via JEP 220 so that scripts could easily identify the modules used to 
build that image. So I think it is very useful, even if it's not exactly 
what you want here.

-Alan

From thomas.stuefe at gmail.com  Sun Nov 22 05:57:03 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sun, 22 Nov 2020 06:57:03 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <ad370a6f-6480-4dfe-1b58-33758bd46304@gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
 <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
 <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
 <ad370a6f-6480-4dfe-1b58-33758bd46304@gmail.com>
Message-ID: <CAA-vtUxzJTCOh9h712zQbZvxs0qAEXQHg-74r4ELtefhgHty-g@mail.gmail.com>

Thanks Michael, that's an important point.

So when I half-jokingly wrote that "-version" is used as a cheap first-line
VM test I was not wrong, and not only OpenJDK developers do that. People
seem to rely on "-version" parsing arguments and initializing the JVM.
Which also would prevent us from modifying command line options to save
initialization time, e.g. adding -Xint.

Pity. I guess we could run JVM initialization and still cut out the actual
invocation of VersionProps.java and just print all those infos from native
code within the hotspot. But I'm not sure how much this would actually save.

Cheers, Thomas


On Fri, Nov 20, 2020 at 11:50 PM Michael Bien <mbien42 at gmail.com> wrote:

> On 20.11.20 20:44, Thomas St?fe wrote:
> > On Fri, Nov 20, 2020 at 7:39 PM Volker Simonis <volker.simonis at gmail.com
> >
> > wrote:
> >
> >> On Fri, Nov 20, 2020 at 7:08 PM Alan Bateman <Alan.Bateman at oracle.com>
> >> wrote:
> >>> On 20/11/2020 16:22, Thomas St?fe wrote:
> >>>> Hi,
> >>>>
> >>>> java -version seems to be called by scripts very frequently to get the
> >> java
> >>>> version. Folks complain about the time that takes.
> >>>>
> >>>> I always wondered, why is this implemented in java? Which requires the
> >>>> whole jvm machinery to start up just to print the version information.
> >>>>
> >>>> VersionProps.java seems not to be very complex; that information could
> >> have
> >>>> been baked into the launcher, or the hotspot.
> >>>>
> >>>> Or is using 'java -version' as a simple VM test just too convenient?
> >>>>
> >>> The alternative to scripts running `java -version` is to examine the
> >>> `release` file in the top-level directory. Could the scripts that
> you've
> >>> encountered be changed to look at that instead?
> >> That's an alternative but not the answer to the question :)
> >>
> >>
> > Yes, I was hoping for some background information about why we do it
> > this way.
> >
> > I know about the "release" file, but this does not seem like an obvious
> > solution. I see this file mentioned as a way to quickly get the java
> > release info, but it seems so strange and non-obvious. I feel bad that
> > users have to even do that.
> >
> > Also, to me, that file does not seem to correspond clearly with the
> > -version information.
> >
> >
> >> I'm also not sure how "common" or "standard the "release" file is? I
> >> know at least two popular distributions which don't have that file
> >> while "-version" seems to be a documented and supported option.
> >>
> >> I think there's probably a lot of history and legacy around "-version"
> >> and it's implementation. It actually prints "many" versions, e.g. the
> >> VM version, the class library version, etc.  Most of the "-version"
> >> output is also exported as system properties and as such only
> >> "generated" at runtime.
> >>
> >> Maybe one solution could be to implement a short-cut into OpenJDK's
> >> standard launcher to use the information from the "release" file if
> >> that is present? That should be pretty safe as the times when you
> >> could simple swap the VM in a JDK release are long gone :)
> >>
> >>
> > An even simpler way could be just to bake the release information as
> > strings into the java launcher and print those. No need to even open and
> > parse that file. j.l.VersionProps.java gets generated from a template, a
> > C-file with strings could be generated the same way.
> >
> > But I am sure it's not that easy and I overlook something. Hence my
> > question.
>
> java -version does more than just printing static version Strings. It
> prints if class data sharing is active and which mode the JIT is in
> (mixed mode by default).
>
> jdk-15.0.1_oracle/bin/java -version
> openjdk version "15.0.1" 2020-10-20
> OpenJDK Runtime Environment (build 15.0.1+9-18)
> OpenJDK 64-Bit Server VM (build 15.0.1+9-18, mixed mode, sharing)
>
>
> I am (ab)using it sometimes to test JDK features when i forget which
> distribution has what enabled.
>
> java -Xshare:on -version
>
> is going to fail if CDS is not properly set up.
>
>
> java -XX:+UseShenandoahGC -version
>
> is going to fail if its an Oracle JDK
>
> ...
>
>
> I just wanted to mention this because i might not be the only one using
> -version as --dry-run equivalent.
>
> best regards,
>
> michael
>
>
> >
> > Cheers, Thomas
>
>
>

From sormuras at gmail.com  Sun Nov 22 06:07:45 2020
From: sormuras at gmail.com (Christian Stein)
Date: Sun, 22 Nov 2020 07:07:45 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <CAA-vtUxzJTCOh9h712zQbZvxs0qAEXQHg-74r4ELtefhgHty-g@mail.gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
 <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
 <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
 <ad370a6f-6480-4dfe-1b58-33758bd46304@gmail.com>
 <CAA-vtUxzJTCOh9h712zQbZvxs0qAEXQHg-74r4ELtefhgHty-g@mail.gmail.com>
Message-ID: <CAJi8+g6Su3x8WdXoWU64t6QCpaF+iHjDW2aiJex6VjnR1P4y9w@mail.gmail.com>

On Sun, Nov 22, 2020 at 6:59 AM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> [...]
> Pity. I guess we could run JVM initialization and still cut out the actual
> invocation of VersionProps.java and just print all those infos from native
> code within the hotspot. But I'm not sure how much this would actually
> save.
>

What about introducing new java launcher options (named "--version-short",
"--version-long", ..., "--print-version-in-jep223-[short|long]-format")
that don't need an initialized VM?

From thomas.stuefe at gmail.com  Sun Nov 22 06:33:06 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sun, 22 Nov 2020 07:33:06 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <CAJi8+g6Su3x8WdXoWU64t6QCpaF+iHjDW2aiJex6VjnR1P4y9w@mail.gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
 <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
 <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
 <ad370a6f-6480-4dfe-1b58-33758bd46304@gmail.com>
 <CAA-vtUxzJTCOh9h712zQbZvxs0qAEXQHg-74r4ELtefhgHty-g@mail.gmail.com>
 <CAJi8+g6Su3x8WdXoWU64t6QCpaF+iHjDW2aiJex6VjnR1P4y9w@mail.gmail.com>
Message-ID: <CAA-vtUwzZHipM+ECz6X2s2W5x6TXCEuGObQ3EZ5u_Cegf=m-LQ@mail.gmail.com>

That exists already, as mentioned by David in this Thread:

-Xinternalversion

I am not sure atm if this is supported by all JDKs but at least the
Oracle-provided OpenJDK and our SapMachine support that. But it is listed
under the "-X" options:

```
java -X
...
    -Xinternalversion
                     displays more detailed JVM version information than
the
                     -version option
```

so any downstream vendor who does not modify arguments.cpp should have it.

(Whether the text "more detailed JVM information" is fully accurate I am
not sure since we miss the information a JVM initialization would give us)

This does not need any JVM initialization. It is printed right at argument
parsing and then the VM stops.

The problem with option is that this seems to be as equally unknown as the
release file.

Cheers, Thomas


On Sun, Nov 22, 2020 at 7:08 AM Christian Stein <sormuras at gmail.com> wrote:

> On Sun, Nov 22, 2020 at 6:59 AM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
> > [...]
> > Pity. I guess we could run JVM initialization and still cut out the
> actual
> > invocation of VersionProps.java and just print all those infos from
> native
> > code within the hotspot. But I'm not sure how much this would actually
> > save.
> >
>
> What about introducing new java launcher options (named "--version-short",
> "--version-long", ..., "--print-version-in-jep223-[short|long]-format")
> that don't need an initialized VM?
>

From thomas.stuefe at gmail.com  Sun Nov 22 06:35:22 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sun, 22 Nov 2020 07:35:22 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <96cac743-3d69-4303-2906-b9e260d935a1@oracle.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
 <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
 <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
 <96cac743-3d69-4303-2906-b9e260d935a1@oracle.com>
Message-ID: <CAA-vtUzQNS7PVreQXh8+Ek6SpaJU1=0q3DJHqLt3bB565sW3Aw@mail.gmail.com>

Hi Alan and David,

thanks for the additional information. I think now that the fact that
-version initializes the VM and runs a little java program is a fact that
is misused all over the place to do sanity checks.

Pity that the release file does not seem to be standardized. As for adding
a new option which is faster, as David mentioned, that already exists in
the (not well known) -XinternalVersion.

Thanks, Thomas



On Sat, Nov 21, 2020 at 9:20 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 20/11/2020 19:44, Thomas St?fe wrote:
>
> :
>
> I know about the "release" file, but this does not seem like an obvious
> solution. I see this file mentioned as a way to quickly get the java
> release info, but it seems so strange and non-obvious. I feel bad that
> users have to even do that.
>
>
> The release file was added (I think JDK 7) to allow humans and scripts
> easily identify the run-time image. Running `java -version` is not an
> option in many cases, esp. when there is a possibility that the image is
> for a different platform or architecture. I remember there were issues some
> scripts (and one IDE in particular) that was peeking into jvm.dll to get
> vendor information. More recently, the release file was extended via JEP
> 220 so that scripts could easily identify the modules used to build that
> image. So I think it is very useful, even if it's not exactly what you want
> here.
>
> -Alan
>

From magnus.ihse.bursie at oracle.com  Mon Nov 23 12:52:58 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 23 Nov 2020 13:52:58 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
 <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
 <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
Message-ID: <4ea27d7c-a1ba-bdb5-8e20-46b7f2c3d971@oracle.com>

On 2020-11-20 20:44, Thomas St?fe wrote:
> On Fri, Nov 20, 2020 at 7:39 PM Volker Simonis <volker.simonis at gmail.com>
> wrote:
>
>> On Fri, Nov 20, 2020 at 7:08 PM Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>> On 20/11/2020 16:22, Thomas St?fe wrote:
>>>> Hi,
>>>>
>>>> java -version seems to be called by scripts very frequently to get the
>> java
>>>> version. Folks complain about the time that takes.
>>>>
>>>> I always wondered, why is this implemented in java? Which requires the
>>>> whole jvm machinery to start up just to print the version information.
>>>>
>>>> VersionProps.java seems not to be very complex; that information could
>> have
>>>> been baked into the launcher, or the hotspot.
>>>>
>>>> Or is using 'java -version' as a simple VM test just too convenient?
>>>>
>>> The alternative to scripts running `java -version` is to examine the
>>> `release` file in the top-level directory. Could the scripts that you've
>>> encountered be changed to look at that instead?
>> That's an alternative but not the answer to the question :)
>>
>>
> Yes, I was hoping for some background information about why we do it
> this way.
>
> I know about the "release" file, but this does not seem like an obvious
> solution. I see this file mentioned as a way to quickly get the java
> release info, but it seems so strange and non-obvious. I feel bad that
> users have to even do that.
>
> Also, to me, that file does not seem to correspond clearly with the
> -version information.
>
>
>> I'm also not sure how "common" or "standard the "release" file is? I
>> know at least two popular distributions which don't have that file
>> while "-version" seems to be a documented and supported option.
>>
>> I think there's probably a lot of history and legacy around "-version"
>> and it's implementation. It actually prints "many" versions, e.g. the
>> VM version, the class library version, etc.  Most of the "-version"
>> output is also exported as system properties and as such only
>> "generated" at runtime.
>>
>> Maybe one solution could be to implement a short-cut into OpenJDK's
>> standard launcher to use the information from the "release" file if
>> that is present? That should be pretty safe as the times when you
>> could simple swap the VM in a JDK release are long gone :)
>>
>>
> An even simpler way could be just to bake the release information as
> strings into the java launcher and print those. No need to even open and
> parse that file. j.l.VersionProps.java gets generated from a template, a
> C-file with strings could be generated the same way.
>
> But I am sure it's not that easy and I overlook something. Hence my
> question.
Just to clarify: that would not be hard to do.

 From a build point of view, there is much to be done about how versions 
are handled. The default behavior unfortunately is to create "ad hoc" 
version strings for developer builds, which needs to be updated in 
source code, causing build changes to propagate throughout the chain for 
even the simplest changes.

I think a much better solution would be to not hard-code version 
information in any native binary, shared library or class file, but 
instead read it from a text file. If the release file does not match 
what java -version prints, then perhaps an additional line (or lines) 
should be added to the release file, with this content. That would also 
allow tooling to read the file and get the *exact* same output as java 
-version should have provided.

And, of course, a change in version string would not require a full rebuild.

With that said, I think the sad fact, as you've seem to have concluded, 
is that people are expecting java -version to start up a VM, and we 
can't really do anything about that.

One thought I have, and I don't know if that is good or bad, is that the 
new, GNU-style long-option java --version that was introduced not too 
long ago is not as likely to have this legacy of expecting VM startup. 
It might be possible to redefine it to just print the version to stdout 
and just exit. But that also means that java -version and java --version 
behaves differently, and I don't know if that really is a good idea.

/Magnus
>
> Cheers, Thomas


From thomas.stuefe at gmail.com  Mon Nov 23 12:59:34 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 23 Nov 2020 13:59:34 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <4ea27d7c-a1ba-bdb5-8e20-46b7f2c3d971@oracle.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
 <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
 <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
 <4ea27d7c-a1ba-bdb5-8e20-46b7f2c3d971@oracle.com>
Message-ID: <CAA-vtUxz-TBLdWVtx579qBGAW+H-XrrOmJ7FnZSkqWH+ZZuwtQ@mail.gmail.com>

>
>
>
> One thought I have, and I don't know if that is good or bad, is that the
> new, GNU-style long-option java --version that was introduced not too
> long ago is not as likely to have this legacy of expecting VM startup.
> It might be possible to redefine it to just print the version to stdout
> and just exit. But that also means that java -version and java --version
> behaves differently, and I don't know if that really is a good idea.
>
>
I like the idea of repurposing --version. It could be short-wired to
-Xinternalversion. "--version" certainly is snappier and easier to remember
:)

..Thomas

/Magnus
> >
> > Cheers, Thomas
>
>

From neugens at redhat.com  Mon Nov 23 13:26:18 2020
From: neugens at redhat.com (Mario Torre)
Date: Mon, 23 Nov 2020 14:26:18 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <CAA-vtUxz-TBLdWVtx579qBGAW+H-XrrOmJ7FnZSkqWH+ZZuwtQ@mail.gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
 <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
 <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
 <4ea27d7c-a1ba-bdb5-8e20-46b7f2c3d971@oracle.com>
 <CAA-vtUxz-TBLdWVtx579qBGAW+H-XrrOmJ7FnZSkqWH+ZZuwtQ@mail.gmail.com>
Message-ID: <CAJwKKma7nFW0LA-NUr4fpK5qoPmZhe2Uw6C5BjB9Fjv8iaO-Vg@mail.gmail.com>

 Mon, Nov 23, 2020 at 2:02 PM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> >
> >
> >
> > One thought I have, and I don't know if that is good or bad, is that the
> > new, GNU-style long-option java --version that was introduced not too
> > long ago is not as likely to have this legacy of expecting VM startup.
> > It might be possible to redefine it to just print the version to stdout
> > and just exit. But that also means that java -version and java --version
> > behaves differently, and I don't know if that really is a good idea.
> >
> >
> I like the idea of repurposing --version. It could be short-wired to
> -Xinternalversion. "--version" certainly is snappier and easier to remember
> :)

I think think it's a good idea to have --version and -version behave
differently, it would be too easy to make a typo.

Cheers,
Mario


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From neugens at redhat.com  Mon Nov 23 13:28:11 2020
From: neugens at redhat.com (Mario Torre)
Date: Mon, 23 Nov 2020 14:28:11 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <CAJwKKma7nFW0LA-NUr4fpK5qoPmZhe2Uw6C5BjB9Fjv8iaO-Vg@mail.gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
 <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
 <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
 <4ea27d7c-a1ba-bdb5-8e20-46b7f2c3d971@oracle.com>
 <CAA-vtUxz-TBLdWVtx579qBGAW+H-XrrOmJ7FnZSkqWH+ZZuwtQ@mail.gmail.com>
 <CAJwKKma7nFW0LA-NUr4fpK5qoPmZhe2Uw6C5BjB9Fjv8iaO-Vg@mail.gmail.com>
Message-ID: <CAJwKKmY94+G9HmJMNy42h4FgP0t47OtcNguqiohep8a+O0qp+A@mail.gmail.com>

On Mon, Nov 23, 2020 at 2:26 PM Mario Torre <neugens at redhat.com> wrote:
>
>  Mon, Nov 23, 2020 at 2:02 PM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> >
> > >
> > >
> > >
> > > One thought I have, and I don't know if that is good or bad, is that the
> > > new, GNU-style long-option java --version that was introduced not too
> > > long ago is not as likely to have this legacy of expecting VM startup.
> > > It might be possible to redefine it to just print the version to stdout
> > > and just exit. But that also means that java -version and java --version
> > > behaves differently, and I don't know if that really is a good idea.
> > >
> > >
> > I like the idea of repurposing --version. It could be short-wired to
> > -Xinternalversion. "--version" certainly is snappier and easier to remember
> > :)
>
> I think think it's a good idea to have --version and -version behave
> differently, it would be too easy to make a typo.

whops, typo, I meant: I don't think it's a good idea :)

Cheers,
Mario
-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From hohensee at amazon.com  Mon Nov 23 19:24:17 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 23 Nov 2020 19:24:17 +0000
Subject: hg.openjdk.java/net is down
Message-ID: <A75AE788-7061-44C4-8CF5-EE0812E08A71@amazon.com>

Same issue as on Nov 15th, 502 ?Bad Gateway?.

Thanks,
Paul


From tim.bell at oracle.com  Mon Nov 23 20:12:41 2020
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 23 Nov 2020 12:12:41 -0800
Subject: hg.openjdk.java/net is down
In-Reply-To: <A75AE788-7061-44C4-8CF5-EE0812E08A71@amazon.com>
References: <A75AE788-7061-44C4-8CF5-EE0812E08A71@amazon.com>
Message-ID: <d9a0e63d-6cd5-496d-bc3a-820905247714@oracle.com>

Hi Paul:

> Same issue as on Nov 15^th , 502 ?Bad Gateway?.

https://hg.openjdk.java.net/ is back online.

I restarted hgweb.fcgi

Tim

From hohensee at amazon.com  Mon Nov 23 20:25:08 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 23 Nov 2020 20:25:08 +0000
Subject: hg.openjdk.java/net is down
Message-ID: <071BA566-2474-450B-B455-45A80FC2FBDA@amazon.com>

That worked. Thanks for the quick fix, Tim!

Paul

?On 11/23/20, 12:16 PM, "Tim Bell" <tim.bell at oracle.com> wrote:

    Hi Paul:

    > Same issue as on Nov 15^th , 502 ?Bad Gateway?.

    https://hg.openjdk.java.net/ is back online.

    I restarted hgweb.fcgi

    Tim


From mbien42 at gmail.com  Tue Nov 24 02:27:45 2020
From: mbien42 at gmail.com (Michael Bien)
Date: Tue, 24 Nov 2020 03:27:45 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <CAA-vtUxzJTCOh9h712zQbZvxs0qAEXQHg-74r4ELtefhgHty-g@mail.gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <8b9685dc-51ba-f7c4-a281-05c438aaf848@oracle.com>
 <CA+3eh10Pc2C11qgmpi0nZMv3Nicy+cMxhRaCWEyeWmnJHOjH=g@mail.gmail.com>
 <CAA-vtUzJqJTjK8Yqj4QbcJRL5b_jMvsn7bSsE60Ui2d_jck+DA@mail.gmail.com>
 <ad370a6f-6480-4dfe-1b58-33758bd46304@gmail.com>
 <CAA-vtUxzJTCOh9h712zQbZvxs0qAEXQHg-74r4ELtefhgHty-g@mail.gmail.com>
Message-ID: <089fd379-ae45-7d65-e0cc-e5857e2116a8@gmail.com>

'java --dry-run' will currently print the help (and exit with 1) if no 
jar/mainclass/etc has been provided. Maybe this could be omitted to make 
it script friendlier. That might be the reason why i have seen 'java 
-Xshare:on -version' in scripts before, instead of 'java -Xshare:on 
--dry-run' which is more descriptive.

i don't think -v is taken yet. This might be the way out to add a fast 
path, while -version (and --version) would remain unchanged for printing 
instance specific settings (sharing, mixed mode, etc) additionally to 
the version.

(just an idea)

best regards,
michael

On 22.11.20 06:57, Thomas St?fe wrote:
> Thanks Michael, that's an important point.
>
> So when I half-jokingly wrote that "-version" is used as a cheap 
> first-line VM test I was not wrong, and not only OpenJDK developers do 
> that. People seem to rely on "-version" parsing arguments and 
> initializing the JVM. Which also would prevent us from modifying 
> command line options to save initialization time, e.g. adding -Xint.
>
> Pity. I guess we could run JVM initialization and still cut out the 
> actual invocation of VersionProps.java and just print all those infos 
> from native code within the hotspot. But I'm not sure how much this 
> would actually save.
>
> Cheers, Thomas
>
>
> On Fri, Nov 20, 2020 at 11:50 PM Michael Bien <mbien42 at gmail.com 
> <mailto:mbien42 at gmail.com>> wrote:
>
>     On 20.11.20 20:44, Thomas St?fe wrote:
>     > On Fri, Nov 20, 2020 at 7:39 PM Volker Simonis
>     <volker.simonis at gmail.com <mailto:volker.simonis at gmail.com>>
>     > wrote:
>     >
>     >> On Fri, Nov 20, 2020 at 7:08 PM Alan Bateman
>     <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>
>     >> wrote:
>     >>> On 20/11/2020 16:22, Thomas St?fe wrote:
>     >>>> Hi,
>     >>>>
>     >>>> java -version seems to be called by scripts very frequently
>     to get the
>     >> java
>     >>>> version. Folks complain about the time that takes.
>     >>>>
>     >>>> I always wondered, why is this implemented in java? Which
>     requires the
>     >>>> whole jvm machinery to start up just to print the version
>     information.
>     >>>>
>     >>>> VersionProps.java seems not to be very complex; that
>     information could
>     >> have
>     >>>> been baked into the launcher, or the hotspot.
>     >>>>
>     >>>> Or is using 'java -version' as a simple VM test just too
>     convenient?
>     >>>>
>     >>> The alternative to scripts running `java -version` is to
>     examine the
>     >>> `release` file in the top-level directory. Could the scripts
>     that you've
>     >>> encountered be changed to look at that instead?
>     >> That's an alternative but not the answer to the question :)
>     >>
>     >>
>     > Yes, I was hoping for some background information about why we do it
>     > this way.
>     >
>     > I know about the "release" file, but this does not seem like an
>     obvious
>     > solution. I see this file mentioned as a way to quickly get the java
>     > release info, but it seems so strange and non-obvious. I feel
>     bad that
>     > users have to even do that.
>     >
>     > Also, to me, that file does not seem to correspond clearly with the
>     > -version information.
>     >
>     >
>     >> I'm also not sure how "common" or "standard the "release" file
>     is? I
>     >> know at least two popular distributions which don't have that file
>     >> while "-version" seems to be a documented and supported option.
>     >>
>     >> I think there's probably a lot of history and legacy around
>     "-version"
>     >> and it's implementation. It actually prints "many" versions,
>     e.g. the
>     >> VM version, the class library version, etc.? Most of the "-version"
>     >> output is also exported as system properties and as such only
>     >> "generated" at runtime.
>     >>
>     >> Maybe one solution could be to implement a short-cut into OpenJDK's
>     >> standard launcher to use the information from the "release" file if
>     >> that is present? That should be pretty safe as the times when you
>     >> could simple swap the VM in a JDK release are long gone :)
>     >>
>     >>
>     > An even simpler way could be just to bake the release information as
>     > strings into the java launcher and print those. No need to even
>     open and
>     > parse that file. j.l.VersionProps.java gets generated from a
>     template, a
>     > C-file with strings could be generated the same way.
>     >
>     > But I am sure it's not that easy and I overlook something. Hence my
>     > question.
>
>     java -version does more than just printing static version Strings. It
>     prints if class data sharing is active and which mode the JIT is in
>     (mixed mode by default).
>
>     jdk-15.0.1_oracle/bin/java -version
>     openjdk version "15.0.1" 2020-10-20
>     OpenJDK Runtime Environment (build 15.0.1+9-18)
>     OpenJDK 64-Bit Server VM (build 15.0.1+9-18, mixed mode, sharing)
>
>
>     I am (ab)using it sometimes to test JDK features when i forget which
>     distribution has what enabled.
>
>     java -Xshare:on -version
>
>     is going to fail if CDS is not properly set up.
>
>
>     java -XX:+UseShenandoahGC -version
>
>     is going to fail if its an Oracle JDK
>
>     ...
>
>
>     I just wanted to mention this because i might not be the only one
>     using
>     -version as --dry-run equivalent.
>
>     best regards,
>
>     michael
>
>
>     >
>     > Cheers, Thomas
>
>


From sgehwolf at redhat.com  Tue Nov 24 13:18:59 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 24 Nov 2020 14:18:59 +0100
Subject: CFV: New JDK Committer: Andrew Leonard
Message-ID: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>

Hi,

I hereby nominate Andrew Leonard (aleonard) to JDK Project Committer.

Andrew has been working primarily on the core-libs and build
components, on a range of fixes mainly discovered by his involvement
with Eclipse OpenJ9 and AdoptOpenJDK, and contributing them upstream to
OpenJDK.

Andrew has 12 contributions: [0] and has also been involved in aiding 7
backports for jdk8u/11u: [3] [4]

Votes are due by 15:00 GM on Dec 8 2020

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

For Lazy Consensus voting instructions, see [2].

Thanks,
Severin

[0] https://github.com/openjdk/jdk/search?q=author-name%3A%22Andrew+Leonard%22&type=commits
[1] https://openjdk.java.net/census
[2] https://openjdk.java.net/projects/#committer-vote
[3] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk//log?revcount=2000&rev=(author(%22aleonard%22)+or+desc(%22andrew_m_leonard at uk.ibm.com%22))+and+not+merge()
[4] https://hg.openjdk.java.net/jdk-updates/jdk11u/log?revcount=2000&rev=(author(%22aleonard%22)+or+desc(%22andrew_m_leonard at uk.ibm.com%22))+and+not+merge()


From adinn at redhat.com  Tue Nov 24 16:29:40 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 24 Nov 2020 16:29:40 +0000
Subject: CFV: New JDK Committer: Andrew Leonard
In-Reply-To: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
References: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
Message-ID: <5cb7637e-4776-3806-5292-9f2b499b94ba@redhat.com>

Vote: yes

On 24/11/2020 13:18, Severin Gehwolf wrote:
> Hi,
> 
> I hereby nominate Andrew Leonard (aleonard) to JDK Project Committer.
> 
> Andrew has been working primarily on the core-libs and build
> components, on a range of fixes mainly discovered by his involvement
> with Eclipse OpenJ9 and AdoptOpenJDK, and contributing them upstream to
> OpenJDK.
> 
> Andrew has 12 contributions: [0] and has also been involved in aiding 7
> backports for jdk8u/11u: [3] [4]
> 
> Votes are due by 15:00 GM on Dec 8 2020
> 
> Only current JDK Project Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Thanks,
> Severin
> 
> [0] https://github.com/openjdk/jdk/search?q=author-name%3A%22Andrew+Leonard%22&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> [3] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk//log?revcount=2000&rev=(author(%22aleonard%22)+or+desc(%22andrew_m_leonard at uk.ibm.com%22))+and+not+merge()
> [4] https://hg.openjdk.java.net/jdk-updates/jdk11u/log?revcount=2000&rev=(author(%22aleonard%22)+or+desc(%22andrew_m_leonard at uk.ibm.com%22))+and+not+merge()
> 

-- 
regards,


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


From goetz.lindenmaier at sap.com  Tue Nov 24 16:38:54 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 24 Nov 2020 16:38:54 +0000
Subject: CFV: New JDK Committer: Andrew Leonard
In-Reply-To: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
References: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
Message-ID: <AM4PR0202MB2964FE58C3E7C20AE9250344ECFB0@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Vote: yes

Best, Goetz

> -----Original Message-----
> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Severin
> Gehwolf
> Sent: Tuesday, November 24, 2020 2:19 PM
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: CFV: New JDK Committer: Andrew Leonard
> 
> Hi,
> 
> I hereby nominate Andrew Leonard (aleonard) to JDK Project Committer.
> 
> Andrew has been working primarily on the core-libs and build
> components, on a range of fixes mainly discovered by his involvement
> with Eclipse OpenJ9 and AdoptOpenJDK, and contributing them upstream to
> OpenJDK.
> 
> Andrew has 12 contributions: [0] and has also been involved in aiding 7
> backports for jdk8u/11u: [3] [4]
> 
> Votes are due by 15:00 GM on Dec 8 2020
> 
> Only current JDK Project Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Thanks,
> Severin
> 
> [0] https://github.com/openjdk/jdk/search?q=author-
> name%3A%22Andrew+Leonard%22&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk8u/jdk8u/jdk//log?revcount=2000&rev=(auth
> or(%22aleonard%22)+or+desc(%22andrew_m_leonard at uk.ibm.com%22))+a
> nd+not+merge()
> [4] https://hg.openjdk.java.net/jdk-
> updates/jdk11u/log?revcount=2000&rev=(author(%22aleonard%22)+or+desc
> (%22andrew_m_leonard at uk.ibm.com%22))+and+not+merge()


From sgehwolf at redhat.com  Tue Nov 24 16:44:12 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 24 Nov 2020 17:44:12 +0100
Subject: CFV: New JDK Committer: Andrew Leonard
In-Reply-To: <5cb7637e-4776-3806-5292-9f2b499b94ba@redhat.com>
References: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
 <5cb7637e-4776-3806-5292-9f2b499b94ba@redhat.com>
Message-ID: <a1e4877c93cf5280cd1d688cc01009fd7aa886ef.camel@redhat.com>

Vote: yes

> On 24/11/2020 13:18, Severin Gehwolf wrote:
> 
> I hereby nominate Andrew Leonard (aleonard) to JDK Project Committer.


From mark.reinhold at oracle.com  Tue Nov 24 23:04:34 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 24 Nov 2020 15:04:34 -0800 (PST)
Subject: JEP proposed to target JDK 16: 397: Sealed Classes (Second Preview)
Message-ID: <20201124230434.B5CA83CB481@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 16:

  397: Sealed Classes (Second Preview)
       https://openjdk.java.net/jeps/397

  Summary: Enhance the Java programming language with sealed classes and
  interfaces. Sealed classes and interfaces restrict which other classes
  or interfaces may extend or implement them.

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Tuesday, 1 December, or if they?re raised
and then satisfactorily answered, then per the JEP 2.0 process proposal
[2] I?ll target this JEP to JDK 16.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From girijaarumugam13 at gmail.com  Thu Nov 26 06:40:34 2020
From: girijaarumugam13 at gmail.com (girija arumugam)
Date: Thu, 26 Nov 2020 12:10:34 +0530
Subject: Channel to NIC card
Message-ID: <CAFNpXPAs6M+5YCYws1Yb0Gs=Jvb6M8bizXrTEkox-_qkv+bd3w@mail.gmail.com>

Team,
    Can anyone please explain the flow from nio channel native read and
write flow ?
              - The system call involved.
              - The list of configurable system variables involved

Regards,
Girija.

From magnus.ihse.bursie at oracle.com  Thu Nov 26 08:49:29 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 26 Nov 2020 09:49:29 +0100
Subject: CFV: New JDK Committer: Andrew Leonard
In-Reply-To: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
References: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
Message-ID: <c386669a-9ef7-523d-204c-1a7362061c32@oracle.com>

Vote:? yes

/Magnus

On 2020-11-24 14:18, Severin Gehwolf wrote:
> Hi,
>
> I hereby nominate Andrew Leonard (aleonard) to JDK Project Committer.
>
> Andrew has been working primarily on the core-libs and build
> components, on a range of fixes mainly discovered by his involvement
> with Eclipse OpenJ9 and AdoptOpenJDK, and contributing them upstream to
> OpenJDK.
>
> Andrew has 12 contributions: [0] and has also been involved in aiding 7
> backports for jdk8u/11u: [3] [4]
>
> Votes are due by 15:00 GM on Dec 8 2020
>
> Only current JDK Project Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> Severin
>
> [0] https://github.com/openjdk/jdk/search?q=author-name%3A%22Andrew+Leonard%22&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> [3] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk//log?revcount=2000&rev=(author(%22aleonard%22)+or+desc(%22andrew_m_leonard at uk.ibm.com%22))+and+not+merge()
> [4] https://hg.openjdk.java.net/jdk-updates/jdk11u/log?revcount=2000&rev=(author(%22aleonard%22)+or+desc(%22andrew_m_leonard at uk.ibm.com%22))+and+not+merge()
>


From neugens.limasoftware at gmail.com  Thu Nov 26 08:52:16 2020
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 26 Nov 2020 09:52:16 +0100
Subject: CFV: New JDK Committer: Andrew Leonard
In-Reply-To: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
References: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
Message-ID: <CAGUMyaTMn_0eO63nU9MGHjRF=qa0m=AL1dMzQOnfQHMMJYm7zA@mail.gmail.com>

Vote: yes

Cheers,
Mario

On Tue 24. Nov 2020 at 14:21, Severin Gehwolf <sgehwolf at redhat.com> wrote:

> Hi,
>
> I hereby nominate Andrew Leonard (aleonard) to JDK Project Committer.
>
> Andrew has been working primarily on the core-libs and build
> components, on a range of fixes mainly discovered by his involvement
> with Eclipse OpenJ9 and AdoptOpenJDK, and contributing them upstream to
> OpenJDK.
>
> Andrew has 12 contributions: [0] and has also been involved in aiding 7
> backports for jdk8u/11u: [3] [4]
>
> Votes are due by 15:00 GM on Dec 8 2020
>
> Only current JDK Project Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> Severin
>
> [0]
> https://github.com/openjdk/jdk/search?q=author-name%3A%22Andrew+Leonard%22&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk8u/jdk8u/jdk//log?revcount=2000&rev=(author(%22aleonard%22)+or+desc(%22andrew_m_leonard at uk.ibm.com%22))+and+not+merge()
> [4]
> https://hg.openjdk.java.net/jdk-updates/jdk11u/log?revcount=2000&rev=(author(%22aleonard%22)+or+desc(%22andrew_m_leonard at uk.ibm.com%22))+and+not+merge()
>
> --
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From christoph.langer at sap.com  Sun Nov 29 19:10:08 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sun, 29 Nov 2020 19:10:08 +0000
Subject: CFV: New JDK Committer: Andrew Leonard
In-Reply-To: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
References: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
Message-ID: <AM4PR02MB31387A2A8F14A7997CE9CF808AF60@AM4PR02MB3138.eurprd02.prod.outlook.com>

Vote:yes

/Christoph

> -----Original Message-----
> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Severin
> Gehwolf
> Sent: Dienstag, 24. November 2020 14:19
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: CFV: New JDK Committer: Andrew Leonard
> 
> Hi,
> 
> I hereby nominate Andrew Leonard (aleonard) to JDK Project Committer.
> 
> Andrew has been working primarily on the core-libs and build
> components, on a range of fixes mainly discovered by his involvement
> with Eclipse OpenJ9 and AdoptOpenJDK, and contributing them upstream to
> OpenJDK.
> 
> Andrew has 12 contributions: [0] and has also been involved in aiding 7
> backports for jdk8u/11u: [3] [4]
> 
> Votes are due by 15:00 GM on Dec 8 2020
> 
> Only current JDK Project Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Thanks,
> Severin
> 
> [0] https://github.com/openjdk/jdk/search?q=author-
> name%3A%22Andrew+Leonard%22&type=commits
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> [3]
> https://hg.openjdk.java.net/jdk8u/jdk8u/jdk//log?revcount=2000&rev=(aut
> hor(%22aleonard%22)+or+desc(%22andrew_m_leonard at uk.ibm.com%22))
> +and+not+merge()
> [4] https://hg.openjdk.java.net/jdk-
> updates/jdk11u/log?revcount=2000&rev=(author(%22aleonard%22)+or+des
> c(%22andrew_m_leonard at uk.ibm.com%22))+and+not+merge()


From Roger.Riggs at oracle.com  Mon Nov 30 15:53:21 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 30 Nov 2020 10:53:21 -0500
Subject: CFV: New JDK Committer: Andrew Leonard
In-Reply-To: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
References: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
Message-ID: <32a4f489-f9e1-4600-28a3-cd08b483f525@oracle.com>

Vote: yes

On 11/24/20 8:18 AM, Severin Gehwolf wrote:
> I hereby nominate Andrew Leonard (aleonard) to JDK Project Committer.


From mark.reinhold at oracle.com  Mon Nov 30 22:42:27 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 30 Nov 2020 14:42:27 -0800 (PST)
Subject: JEP proposed to target JDK 16: 390: Warnings for Value-Based Classes
Message-ID: <20201130224227.399613CBEA5@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 16:

  390: Warnings for Value-Based Classes
       https://openjdk.java.net/jeps/390

  Summary: Designate the primitive wrapper classes as value-based and
  deprecate their constructors for removal, prompting new deprecation
  warnings.  Provide warnings about improper attempts to synchronize on
  instances of any value-based classes in the Java Platform.

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Monday, 7 December, or if they?re raised and
then satisfactorily answered, then per the JEP 2.0 process proposal [2]
I?ll target this JEP to JDK 16.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Mon Nov 30 22:51:13 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 30 Nov 2020 14:51:13 -0800
Subject: JEP proposed to target JDK 16: 396: Strongly Encapsulate JDK
 Internals by Default
In-Reply-To: <20201119214553.8F1E33CAAF2@eggemoggin.niobe.net>
References: <20201119214553.8F1E33CAAF2@eggemoggin.niobe.net>
Message-ID: <20201130145113.221259229@eggemoggin.niobe.net>

2020/11/19 13:45:53 -0800, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 16:
> 
>   396: Strongly Encapsulate JDK Internals by Default
>        https://openjdk.java.net/jeps/396
> 
>   Summary: Strongly encapsulate all internal elements of the JDK by
>   default, except for critical internal APIs such as sun.misc.Unsafe.
>   Allow end users to choose the relaxed strong encapsulation that has
>   been the default since JDK9.
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Thursday, 26 November, or if they?re raised
> and then satisfactorily answered, then per the JEP 2.0 process proposal
> [2] I?ll target this JEP to JDK 16.

Hearing no objection, I?ve targeted this JEP to JDK 16.

- Mark