From aph at redhat.com  Sat Jun  3 08:27:13 2017
From: aph at redhat.com (Andrew Haley)
Date: Sat, 3 Jun 2017 09:27:13 +0100
Subject: RFR: 8181085: Race condition in method resolution may produce
 spurious NullPointerException
In-Reply-To: <CA+3eh13RKPTzMgiMkgfRu=7exaWRfaLeztmyT0okDjO2_i0Rmg@mail.gmail.com>
References: <092b320b-3230-cb69-99d3-1d7777723578@redhat.com>
 <648fc2bf-34d0-2796-dd79-9e498536b23b@redhat.com>
 <CAAsuuZdp15mQ1hX9tzfVdCMdwbu1CbsPZa4wacck=tcfvhvr0w@mail.gmail.com>
 <f0c66175-c9b4-d3ab-0baa-c91342b8290e@oracle.com>
 <806cff0e-a48f-9a31-c384-caa83c423e8b@redhat.com>
 <2062698c-838b-ad17-0d35-acfc7706878d@oracle.com>
 <3d963255-2006-de03-4b81-87a3dd64ef72@redhat.com>
 <CAAsuuZdh2drtOay+0pdVvqBGqT26GewT4zdgbnXDHo49Y+YWcA@mail.gmail.com>
 <CAAsuuZf9ZA3w6KXqMDmZuM_QcxQ8bCS6tEHOBiC+=rvRYsStMA@mail.gmail.com>
 <CA+3eh11cZoDMOf9k5ZpBfP1aCWYKwVrOAd62eETCmD-GmECVyA@mail.gmail.com>
 <45c4ea7f-3137-76ae-d20a-df35922f4266@redhat.com>
 <CA+3eh11Lpd3i3_DRPd4OTEcisSASz3H9qRepprfmD-jE85GVeA@mail.gmail.com>
 <edc92d8d-2847-838b-d351-b2e292bf3236@redhat.com>
 <592C120A.1080908@oracle.com>
 <CA+3eh10=cgrQ8VkT9HHYjn0aNieQ8tBrh0VmNX0OMs4wU=kwWw@mail.gmail.com>
 <561661eb-b463-726a-1d32-84ef5f32af13@oracle.com>
 <CA+3eh13RKPTzMgiMkgfRu=7exaWRfaLeztmyT0okDjO2_i0Rmg@mail.gmail.com>
Message-ID: <886577e7-bcc7-e01f-4973-164f9603ae44@redhat.com>

On 30/05/17 16:40, Volker Simonis wrote:
> On Mon, May 29, 2017 at 10:55 PM, David Holmes <david.holmes at oracle.com> wrote:
>> <trimming>
>>
>> On 30/05/2017 3:02 AM, Volker Simonis wrote:
>>>
>>> Sorry for constantly "spamming" this thread with another problem (i.e.
>>> JDK-8129440 [2]) but I still think that it is related and important.
>>> In its current state, the way how "load_heap_oop()" and its
>>> application works is broken. And this is not because of a problem in
>>> OrderAccess, but because of missing compiler barriers:
>>>
>>> static inline oop       load_heap_oop(oop* p)       { return *p; }
>>> ...
>>> template <class T>
>>> inline void G1RootRegionScanClosure::do_oop_nv(T* p) {
>>>    // 1. load 'heap_oop' from 'p'
>>>    T heap_oop = oopDesc::load_heap_oop(p);
>>>    if (!oopDesc::is_null(heap_oop)) {
>>>      // 2. Compiler reloads 'heap_oop' from 'p' which may now be null!
>>>      oop obj = oopDesc::decode_heap_oop_not_null(heap_oop);
>>
>>
>> Do you mean that the compiler has not stashed heap_oop somewhere
>> and re-executes oopDesc::load_heap_oop(p) again? That would be
>> quite nasty I think in general as it breaks any logic that wants to
>> read a non-local variable once to get it into a local and reuse
>> that knowing that it won't change even if the real variable does!

Note that such racy code is undefined behaviour in C++11 (and IMO
before that as well, but there wasn't anything portable you could
do about it.)

> Yes, that's exactly what I mean and that's exactly what we've observed
> on AIX with xlc. Notice that the compiler is free to do such
> transformations if the load is not from a volatile field. That's why
> we've opened the bug and fixed out internal version. But we still
> think this fix needs to go into OpenJDK as well.

Given that the code above is now explicitly UB in C++ (and probably C
too, but I haven't looked) it'll have to be changed eventually to

  atomic_load_explicit(&p, memory_order_relaxed);

This approach has some advantages from the point of view of code
quality, too.  The compiler can do a better job if it knows what's
going on.  Maybe it would be worth a #ifdef C++11 set of OrderAccess
functions.

Andrew.

From aph at redhat.com  Sat Jun  3 09:00:51 2017
From: aph at redhat.com (Andrew Haley)
Date: Sat, 3 Jun 2017 10:00:51 +0100
Subject: RFR: 8181085: Race condition in method resolution may produce
 spurious NullPointerException
In-Reply-To: <592D5030.2020904@oracle.com>
References: <092b320b-3230-cb69-99d3-1d7777723578@redhat.com>
 <88a3d832-9875-8a3a-529c-a3a3dfe295de@redhat.com>
 <69ad2e6a-74fb-e0bb-07df-3b25c143f81d@redhat.com>
 <648fc2bf-34d0-2796-dd79-9e498536b23b@redhat.com>
 <CAAsuuZdp15mQ1hX9tzfVdCMdwbu1CbsPZa4wacck=tcfvhvr0w@mail.gmail.com>
 <f0c66175-c9b4-d3ab-0baa-c91342b8290e@oracle.com>
 <806cff0e-a48f-9a31-c384-caa83c423e8b@redhat.com>
 <2062698c-838b-ad17-0d35-acfc7706878d@oracle.com>
 <3d963255-2006-de03-4b81-87a3dd64ef72@redhat.com>
 <CAAsuuZdh2drtOay+0pdVvqBGqT26GewT4zdgbnXDHo49Y+YWcA@mail.gmail.com>
 <CAAsuuZf9ZA3w6KXqMDmZuM_QcxQ8bCS6tEHOBiC+=rvRYsStMA@mail.gmail.com>
 <CA+3eh11cZoDMOf9k5ZpBfP1aCWYKwVrOAd62eETCmD-GmECVyA@mail.gmail.com>
 <45c4ea7f-3137-76ae-d20a-df35922f4266@redhat.com>
 <CA+3eh11Lpd3i3_DRPd4OTEcisSASz3H9qRepprfmD-jE85GVeA@mail.gmail.com>
 <edc92d8d-2847-838b-d351-b2e292bf3236@redhat.com>
 <592C120A.1080908@oracle.com>
 <6e340bdf-da1a-5a6b-6db4-8d040cdf0b54@redhat.com>
 <592D5030.2020904@oracle.com>
Message-ID: <7694fe2e-d118-d748-7c97-83018c72b37f@redhat.com>

On 30/05/17 11:57, Erik ?sterlund wrote:

> The issue is not whether an algorithm depends on IRIW or not. The
> issue is that we have to explicitly reason about IRIW to prove that
> it works.  The lack of IRIW violates seq_cst and by extension
> linearization points that rely in seq_cst, and by extension
> algorithms that rely on linearization points. By breaking the very
> building blocks that were used to reason about algorithms and their
> correctness, we rely on chance for it to work...

I've been thinking about this some more, and one thing you said has
been baffling me.  I don't think that I have come across anywhere in
HotSpot that uses seq_cst internally, and I don't think there is even
any support for it in OrderAccess.  The only thing that I know of
where we actually need seq.cst is in the C++ interpreter and JNI's
support for volatile fields, and there we simulate seq.cst by using
release_fence; store; full fence.  But we could do that with the
seq.cst C++11 functions instead.

Of course I have a motive for digging into this: I'm the lead of the
AArch64-port project.  That processor (uniquely?) has real support for
seq.cst, and it'd be nice to use it without throwing a full fence at
every volatile store.

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

From erik.osterlund at oracle.com  Mon Jun  5 11:52:02 2017
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 5 Jun 2017 13:52:02 +0200
Subject: RFR: 8181085: Race condition in method resolution may produce
 spurious NullPointerException
In-Reply-To: <7694fe2e-d118-d748-7c97-83018c72b37f@redhat.com>
References: <092b320b-3230-cb69-99d3-1d7777723578@redhat.com>
 <69ad2e6a-74fb-e0bb-07df-3b25c143f81d@redhat.com>
 <648fc2bf-34d0-2796-dd79-9e498536b23b@redhat.com>
 <CAAsuuZdp15mQ1hX9tzfVdCMdwbu1CbsPZa4wacck=tcfvhvr0w@mail.gmail.com>
 <f0c66175-c9b4-d3ab-0baa-c91342b8290e@oracle.com>
 <806cff0e-a48f-9a31-c384-caa83c423e8b@redhat.com>
 <2062698c-838b-ad17-0d35-acfc7706878d@oracle.com>
 <3d963255-2006-de03-4b81-87a3dd64ef72@redhat.com>
 <CAAsuuZdh2drtOay+0pdVvqBGqT26GewT4zdgbnXDHo49Y+YWcA@mail.gmail.com>
 <CAAsuuZf9ZA3w6KXqMDmZuM_QcxQ8bCS6tEHOBiC+=rvRYsStMA@mail.gmail.com>
 <CA+3eh11cZoDMOf9k5ZpBfP1aCWYKwVrOAd62eETCmD-GmECVyA@mail.gmail.com>
 <45c4ea7f-3137-76ae-d20a-df35922f4266@redhat.com>
 <CA+3eh11Lpd3i3_DRPd4OTEcisSASz3H9qRepprfmD-jE85GVeA@mail.gmail.com>
 <edc92d8d-2847-838b-d351-b2e292bf3236@redhat.com>
 <592C120A.1080908@oracle.com>
 <6e340bdf-da1a-5a6b-6db4-8d040cdf0b54@redhat.com>
 <592D5030.2020904@oracle.com>
 <7694fe2e-d118-d748-7c97-83018c72b37f@redhat.com>
Message-ID: <593545E2.20406@oracle.com>

Hi Andrew,

On 2017-06-03 11:00, Andrew Haley wrote:
> On 30/05/17 11:57, Erik ?sterlund wrote:
>
>> The issue is not whether an algorithm depends on IRIW or not. The
>> issue is that we have to explicitly reason about IRIW to prove that
>> it works.  The lack of IRIW violates seq_cst and by extension
>> linearization points that rely in seq_cst, and by extension
>> algorithms that rely on linearization points. By breaking the very
>> building blocks that were used to reason about algorithms and their
>> correctness, we rely on chance for it to work...
> I've been thinking about this some more, and one thing you said has
> been baffling me.  I don't think that I have come across anywhere in
> HotSpot that uses seq_cst internally, and I don't think there is even
> any support for it in OrderAccess.  The only thing that I know of
> where we actually need seq.cst is in the C++ interpreter and JNI's
> support for volatile fields, and there we simulate seq.cst by using
> release_fence; store; full fence.

Yes, I miss sequential consistency in hotspot too. In fact, my mouse pad 
has "sequential consistency <3" printed on it. :) For atomic operations 
such as CAS, we do use what we refer to as conservative memory ordering, 
which appears to be closely related to SC.

Other than that, the main idea with SC is on an abstract level to have 
(at least) the guarantees of the weaker acquire/release as well as the 
effect of a full fence between any pair of SC accesses so that they can 
agree upon some total ordering of SC accesses (let's not dig too far 
into details and interactions between SC and acquire/release on the same 
atomic objects just yet). In hotspot, rather than having such semantics, 
we have instead elected to accomplish that either with interleaved 
OrderAccess::fence() calls where this is required. In the cases you 
mentioned, the fence is guarded with if statements checking whether 
"support_IRIW_for_not_multiple_copy_atomic_cpu" is set to control the 
convention of where the fence is placed.

I believe and hope that if we would have had an SC memory ordering, it 
would have been used more.

> But we could do that with the
> seq.cst C++11 functions instead.

Or build our own SC bindings. In fact, my new Access API does come with 
sequential consistency as one memory ordering constraint. Hopefully that 
will not be shot down...

The benefit of rolling our own SC mappings is that we control the ABI 
and conventions. Some immediate benefits are:

1) It is compliant with our dynamically generated code interacting with 
our runtime. For example, the most popular bindings for SC on 
non-multiple copy atomic CPUs seems to be either what is commonly 
referred to as "leading sync" or "trailing sync" conventions where a 
full fence is placed either before or after every SC access to ensure 
every two SC accesses would be interleaved with a full fence. Both the 
leading sync and trailing sync conventions were proven correct [1]. But 
subsequently, the proof was proven wrong and it turns out that the 
trailing sync bindings are not always safe as it may violate e.g. IRIW 
when weaker acquire accesses are combined with SC accesses on the same 
locations [2]. Yet the currently recommended ARMv7 bindings appear to be 
trailing sync [3], because it has been determined to be faster. 
Recently, both trailing sync and leading sync bindings have been 
proposed that correct the currently known flaws of C++11 seq_cst [4]. 
These bindings are not necessarily compliant with lock-free races 
between our runtime and our dynamically generated code.

2) The trailing sync and leading sync conventions used by C++11 
compilers are not ABI compliant. And there is no real way for us to know 
if a leading sync or trailing sync convention is used by the C++ 
compiler without full on selling our souls to uncontracted compiler 
internals. Any subsequent compiler upgrade might break the shady 
contract we thought we had with our dynamically generated code. This is 
a fundamental issue with relying on C++11 atomics.

3) We can be compliant with our own JMM and not have to think about the 
interactions and differences between our JMM and the evolving C++11 
memory model when we write synchronized code.

4) Rather than having trailing sync on some architectures and leading 
sync on others leading to observably different behaviour when combined 
with dynamically generated code, I would ideally like to have the same 
conventions on all machines so that any such behavioural difference for 
generated code looks the same on all platforms. This is not the case for 
C++11 atomics. Currently recommended bindings use leading sync for PPC 
and trailing sync for ARMv7 [3]. And they will behave slightly differently.

5) The ARM manuals talk about "visibility" of stores as parts of its 
contract - a property that is too specific to fit into the C++11 memory 
model, yet might be useful for a JVM that needs to interact with 
dynamically generated code. In particular, if some ARMv8 stlr 
instruction guarantees "visibility" (which I think can be better thought 
of as not reordering with any subsequent accesses in program order as a 
memory model should preferably talk about constraints between memory 
access orderings), then this is equivalent to always having a trailing 
fence() on SC stores, and hence unlike e.g. a C++11 leading sync SC 
store binding for PPC. I would argue we do want this stronger property 
as our current generated code occasionally depends on that.

6) We can decide upon what properties we think are important 
independently of which direction C++ decides to go. They can e.g. decide 
to buy weaker consistency for a failing CAS in the name of micro 
optimization, and we can elect not to buy that bag of problems.

Hope you bought my car sales man pitch.

> Of course I have a motive for digging into this: I'm the lead of the
> AArch64-port project.  That processor (uniquely?) has real support for
> seq.cst, and it'd be nice to use it without throwing a full fence at
> every volatile store.

I understand your motivation. At least I think we both want some kind of 
SC semantics in hotspot in one shape or another. :)

Thanks,
/Erik

[1] "Clarifying and Compiling C/C++ Concurrency: from C++11 to POWER", 
M. Betty et. al., POPL'12
[2] "Counterexamples and Proof Loophole for the C/C++ to POWER and ARMv7 
Trailing-Sync Compiler Mappings", Y. A. Manerka, 2016
[3] https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
[4] "Repairing sequential consistency in C/C++ 11", O. Lahav, PLDI'17

From aph at redhat.com  Mon Jun  5 15:07:15 2017
From: aph at redhat.com (Andrew Haley)
Date: Mon, 5 Jun 2017 16:07:15 +0100
Subject: RFR: 8181085: Race condition in method resolution may produce
 spurious NullPointerException
In-Reply-To: <593545E2.20406@oracle.com>
References: <092b320b-3230-cb69-99d3-1d7777723578@redhat.com>
 <69ad2e6a-74fb-e0bb-07df-3b25c143f81d@redhat.com>
 <648fc2bf-34d0-2796-dd79-9e498536b23b@redhat.com>
 <CAAsuuZdp15mQ1hX9tzfVdCMdwbu1CbsPZa4wacck=tcfvhvr0w@mail.gmail.com>
 <f0c66175-c9b4-d3ab-0baa-c91342b8290e@oracle.com>
 <806cff0e-a48f-9a31-c384-caa83c423e8b@redhat.com>
 <2062698c-838b-ad17-0d35-acfc7706878d@oracle.com>
 <3d963255-2006-de03-4b81-87a3dd64ef72@redhat.com>
 <CAAsuuZdh2drtOay+0pdVvqBGqT26GewT4zdgbnXDHo49Y+YWcA@mail.gmail.com>
 <CAAsuuZf9ZA3w6KXqMDmZuM_QcxQ8bCS6tEHOBiC+=rvRYsStMA@mail.gmail.com>
 <CA+3eh11cZoDMOf9k5ZpBfP1aCWYKwVrOAd62eETCmD-GmECVyA@mail.gmail.com>
 <45c4ea7f-3137-76ae-d20a-df35922f4266@redhat.com>
 <CA+3eh11Lpd3i3_DRPd4OTEcisSASz3H9qRepprfmD-jE85GVeA@mail.gmail.com>
 <edc92d8d-2847-838b-d351-b2e292bf3236@redhat.com>
 <592C120A.1080908@oracle.com>
 <6e340bdf-da1a-5a6b-6db4-8d040cdf0b54@redhat.com>
 <592D5030.2020904@oracle.com>
 <7694fe2e-d118-d748-7c97-83018c72b37f@redhat.com> <593545E2.20406@oracle.com>
Message-ID: <bbd54376-338c-4972-c38a-69ac80423bb2@redhat.com>

On 05/06/17 12:52, Erik ?sterlund wrote:
> Hi Andrew,
>
> On 2017-06-03 11:00, Andrew Haley wrote:
>> On 30/05/17 11:57, Erik ?sterlund wrote:
>>
>>> The issue is not whether an algorithm depends on IRIW or not. The
>>> issue is that we have to explicitly reason about IRIW to prove that
>>> it works.  The lack of IRIW violates seq_cst and by extension
>>> linearization points that rely in seq_cst, and by extension
>>> algorithms that rely on linearization points. By breaking the very
>>> building blocks that were used to reason about algorithms and their
>>> correctness, we rely on chance for it to work...
>>
>> I've been thinking about this some more, and one thing you said has
>> been baffling me.  I don't think that I have come across anywhere in
>> HotSpot that uses seq_cst internally, and I don't think there is even
>> any support for it in OrderAccess.  The only thing that I know of
>> where we actually need seq.cst is in the C++ interpreter and JNI's
>> support for volatile fields, and there we simulate seq.cst by using
>> release_fence; store; full fence.
>
> Yes, I miss sequential consistency in hotspot too. In fact, my mouse pad
> has "sequential consistency <3" printed on it. :) For atomic operations
> such as CAS, we do use what we refer to as conservative memory ordering,
> which appears to be closely related to SC.
>
> Other than that, the main idea with SC is on an abstract level to have
> (at least) the guarantees of the weaker acquire/release as well as the
> effect of a full fence between any pair of SC accesses so that they can
> agree upon some total ordering of SC accesses (let's not dig too far
> into details and interactions between SC and acquire/release on the same
> atomic objects just yet). In hotspot, rather than having such semantics,
> we have instead elected to accomplish that either with interleaved
> OrderAccess::fence() calls where this is required. In the cases you
> mentioned, the fence is guarded with if statements checking whether
> "support_IRIW_for_not_multiple_copy_atomic_cpu" is set to control the
> convention of where the fence is placed.
>
> I believe and hope that if we would have had an SC memory ordering, it
> would have been used more.
>
>> But we could do that with the
>> seq.cst C++11 functions instead.
> Or build our own SC bindings.

True: I'd like us to be able to define what we need on a per-CPU basis
rather than defining things in the shared code, so that we really can
use the appropriate instructions everywhere, and every target does
what we need as well as it can.

In particular, ARM listened to our pleas about sequential consistency
and gave us what we asked for in v8, and I'd like to take advantage of
the results.

> In fact, my new Access API does come with sequential consistency as
> one memory ordering constraint. Hopefully that will not be shot
> down...

I don't believe that we should use SC where acq/rel is sufficient: the
efficiency hit on some hardware is not nice.

> The benefit of rolling our own SC mappings is that we control the ABI
> and conventions. Some immediate benefits are:
>
> 1) It is compliant with our dynamically generated code interacting with
> our runtime. For example, the most popular bindings for SC on
> non-multiple copy atomic CPUs seems to be either what is commonly
> referred to as "leading sync" or "trailing sync" conventions where a
> full fence is placed either before or after every SC access to ensure
> every two SC accesses would be interleaved with a full fence. Both the
> leading sync and trailing sync conventions were proven correct [1]. But
> subsequently, the proof was proven wrong and it turns out that the
> trailing sync bindings are not always safe as it may violate e.g. IRIW
> when weaker acquire accesses are combined with SC accesses on the same
> locations [2].

That doesn't surprise me.

> Yet the currently recommended ARMv7 bindings appear to be trailing
> sync [3], because it has been determined to be faster.  Recently,
> both trailing sync and leading sync bindings have been proposed that
> correct the currently known flaws of C++11 seq_cst [4].  These
> bindings are not necessarily compliant with lock-free races between
> our runtime and our dynamically generated code.
>
> 2) The trailing sync and leading sync conventions used by C++11
> compilers are not ABI compliant.

I don't understand what you mean by this.

> And there is no real way for us to know if a leading sync or
> trailing sync convention is used by the C++ compiler without full on
> selling our souls to uncontracted compiler internals. Any subsequent
> compiler upgrade might break the shady contract we thought we had
> with our dynamically generated code. This is a fundamental issue
> with relying on C++11 atomics.

OK.  But where we do know, we should be able to oveeride it in the
CPU-dependent code.

> 3) We can be compliant with our own JMM and not have to think about the
> interactions and differences between our JMM and the evolving C++11
> memory model when we write synchronized code.

Kinda sorta, but in the longer term we will really need to be able to
interwork with C++ code that uses atomics.

> 4) Rather than having trailing sync on some architectures and leading
> sync on others leading to observably different behaviour when combined
> with dynamically generated code, I would ideally like to have the same
> conventions on all machines so that any such behavioural difference for
> generated code looks the same on all platforms. This is not the case for
> C++11 atomics.

And I really would like this *not* to happen.  A honking great full
fence after every volatile store is not my idea of a good time.

> Currently recommended bindings use leading sync for PPC and trailing
> sync for ARMv7 [3]. And they will behave slightly differently.
>
> 5) The ARM manuals talk about "visibility" of stores as parts of its
> contract - a property that is too specific to fit into the C++11
> memory model, yet might be useful for a JVM that needs to interact
> with dynamically generated code. In particular, if some ARMv8 stlr
> instruction guarantees "visibility" (which I think can be better
> thought of as not reordering with any subsequent accesses in program
> order as a memory model should preferably talk about constraints
> between memory access orderings), then this is equivalent to always
> having a trailing fence() on SC stores,

But consider this:

volatile x, y

Thread 1      Thread 2

x = 1         y = 1
r1 = y        r1 = x

On the ARMv8 memory model, we can't do this as

mov r0, #1         mov r0, #1
stlr r0, [x]       stlr r0, [y]
ldr r1, [y]        ldr r1, [y]
dmb                dmb

In this case, clearly the DMB instructions have no effect.  In order
to get SC we need to match the STLR with LDAR.  STLR is not equivalent
to always having a trailing fence, but we can recover SC by using a
DMB before the load.

> and hence unlike e.g. a C++11 leading sync SC store binding for
> PPC. I would argue we do want this stronger property as our current
> generated code occasionally depends on that.
>
> 6) We can decide upon what properties we think are important
> independently of which direction C++ decides to go. They can e.g. decide
> to buy weaker consistency for a failing CAS in the name of micro
> optimization, and we can elect not to buy that bag of problems.

They already did.  And rightly so, IMO.

> Hope you bought my car sales man pitch.
>
>> Of course I have a motive for digging into this: I'm the lead of the
>> AArch64-port project.  That processor (uniquely?) has real support for
>> seq.cst, and it'd be nice to use it without throwing a full fence at
>> every volatile store.
>
> I understand your motivation. At least I think we both want some kind of
> SC semantics in hotspot in one shape or another. :)

Indeed, but not everywhere: much of the time acq/rel will do.

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

From aph at redhat.com  Mon Jun  5 16:30:45 2017
From: aph at redhat.com (Andrew Haley)
Date: Mon, 5 Jun 2017 17:30:45 +0100
Subject: Using an IDE to work on the Java library
Message-ID: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>

Sorry for what must seem like a newbie question...

I've done almost all of my work on HotSpot, and have very little
experience trying to use an IDE to work on the Java library.  Eclipse
is fine when working on libraries outdie the JDK itself, but seems to
want to look inside src.zip for its sources when debugging.  It would
be really nice to be able to see (and edit) the real Java source files
in jdk/java.base/.

I suppose there must be some way to create a Project for an IDE, so
that debugging the standard library is easy.  Is there some advice
around somewhere?  What do people do?

Thanks,

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

From Roger.Riggs at Oracle.com  Mon Jun  5 16:50:17 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 5 Jun 2017 12:50:17 -0400
Subject: Using an IDE to work on the Java library
In-Reply-To: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
Message-ID: <2c38a40e-663d-a274-201c-098e14611752@Oracle.com>

Hi,

For InteliJ, the <top>/common/bin/idea.sh will generate a project for 
all modules.

For Netbeans, there are a series of projects in <top>/jdk/make/netbeans.

fyi, Roger


On 6/5/2017 12:30 PM, Andrew Haley wrote:
> Sorry for what must seem like a newbie question...
>
> I've done almost all of my work on HotSpot, and have very little
> experience trying to use an IDE to work on the Java library.  Eclipse
> is fine when working on libraries outdie the JDK itself, but seems to
> want to look inside src.zip for its sources when debugging.  It would
> be really nice to be able to see (and edit) the real Java source files
> in jdk/java.base/.
>
> I suppose there must be some way to create a Project for an IDE, so
> that debugging the standard library is easy.  Is there some advice
> around somewhere?  What do people do?
>
> Thanks,
>


From adinn at redhat.com  Mon Jun  5 16:51:59 2017
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 5 Jun 2017 17:51:59 +0100
Subject: Using an IDE to work on the Java library
In-Reply-To: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
Message-ID: <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com>

On 05/06/17 17:30, Andrew Haley wrote:
> Sorry for what must seem like a newbie question...
> 
> I've done almost all of my work on HotSpot, and have very little
> experience trying to use an IDE to work on the Java library.  Eclipse
> is fine when working on libraries outdie the JDK itself, but seems to
> want to look inside src.zip for its sources when debugging.  It would
> be really nice to be able to see (and edit) the real Java source files
> in jdk/java.base/.
> 
> I suppose there must be some way to create a Project for an IDE, so
> that debugging the standard library is easy.  Is there some advice
> around somewhere?  What do people do?

I use IntelliJ Idea. The latest releases cope quite happily with jdk9/10.

In the project settings you can set up a JDK you build from scratch as a
project JDK and the sources located in the build image (in src.zip) will
be picked up automatically by Idea.

In order to see sources not in src.zip you need to add the jdk source
tree to the project's main module as a source root (do this from the
"open module settings" or "project structure" dialogs). Likewise, if you
want the jdk.vm.ci sources for graal from the hotspot tree. So, for the
latter case, I add jdk9/jdk/hotspot/src/jdk.internal.vm.ci as a source
root. (Alternatively you can add it to an extra module that then gets
inherited by the project module(s)).

You then have to tag the relevant module subdirs in these added trees as
src directories to bring the desired source files into play. For example
for the jdk.vm.ci sources root I tag share/classes/jdk.v.ci.code/src etc
as source dirs. Once again this is done from the "open module settings"
dialog.

Note that you can configure the module settings for app modules (or for
any common extra module you add and then make them inherit) so that
these extra  sources are picked up prior to any sources or (what you
don't want) class files obtained from the project JDK.

regards,


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

From aph at redhat.com  Mon Jun  5 17:02:36 2017
From: aph at redhat.com (Andrew Haley)
Date: Mon, 5 Jun 2017 18:02:36 +0100
Subject: Using an IDE to work on the Java library
In-Reply-To: <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
 <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com>
Message-ID: <9a20d213-ca11-aa2b-9a99-01c93b8c9391@redhat.com>

Excellent, thank you both.

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

From neugens.limasoftware at gmail.com  Mon Jun  5 17:22:21 2017
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Mon, 5 Jun 2017 19:22:21 +0200
Subject: Using an IDE to work on the Java library
In-Reply-To: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
Message-ID: <CAGUMyaQpa2ay=0+5g55V1C_Zv350G_07x=WKkM7msw3yuk5oTg@mail.gmail.com>

2017-06-05 18:30 GMT+02:00 Andrew Haley <aph at redhat.com>:
> Sorry for what must seem like a newbie question...
>
> I've done almost all of my work on HotSpot, and have very little
> experience trying to use an IDE to work on the Java library.  Eclipse
> is fine when working on libraries outdie the JDK itself, but seems to
> want to look inside src.zip for its sources when debugging.  It would
> be really nice to be able to see (and edit) the real Java source files
> in jdk/java.base/.
>
> I suppose there must be some way to create a Project for an IDE, so
> that debugging the standard library is easy.  Is there some advice
> around somewhere?  What do people do?

I generally use a bit more manual approach but works better for me
because I know exactly where everything is and I don't have to trust
the IDEs. I basically just create a project with existing sources and
import various directories with the sources into the IDEs, basically
each directory that starts with "classes", this works for me in
IntelliJ, Eclipse and Netbeans, if you add the JVM you just compiled
they will follow its sources and you can make changes, and even
compare with another JDK. I found for this kind of work Netbeans to
work best and Eclipse second best, Netbeans seems to understand when
your application goes into the native code and debugging continues
into that (if you have the C code open as a separate project too),
without any special trick, I did write a quick guide some time ago
although you know all this stuff already:

https://neugens.wordpress.com/2015/02/26/debugging-the-jdk-with-gdb/

This guide is useful for command line gdb but you can attach with
Eclipse (and NetBeans!) too, although when it goes into native land
I'm sure you prefer the gdb console! :)

Cheers,
Mario
-- 
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 jonathan.gibbons at oracle.com  Mon Jun  5 17:32:37 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 Jun 2017 10:32:37 -0700
Subject: Using an IDE to work on the Java library
In-Reply-To: <CAGUMyaQpa2ay=0+5g55V1C_Zv350G_07x=WKkM7msw3yuk5oTg@mail.gmail.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
 <CAGUMyaQpa2ay=0+5g55V1C_Zv350G_07x=WKkM7msw3yuk5oTg@mail.gmail.com>
Message-ID: <593595B5.9060709@oracle.com>

While the d-i-y approach works as far as it goes, the JDK support for
IDE projects typically has direct support for running jtreg tests in the
repos.

-- Jon

On 06/05/2017 10:22 AM, Mario Torre wrote:
> 2017-06-05 18:30 GMT+02:00 Andrew Haley <aph at redhat.com>:
>> Sorry for what must seem like a newbie question...
>>
>> I've done almost all of my work on HotSpot, and have very little
>> experience trying to use an IDE to work on the Java library.  Eclipse
>> is fine when working on libraries outdie the JDK itself, but seems to
>> want to look inside src.zip for its sources when debugging.  It would
>> be really nice to be able to see (and edit) the real Java source files
>> in jdk/java.base/.
>>
>> I suppose there must be some way to create a Project for an IDE, so
>> that debugging the standard library is easy.  Is there some advice
>> around somewhere?  What do people do?
> I generally use a bit more manual approach but works better for me
> because I know exactly where everything is and I don't have to trust
> the IDEs. I basically just create a project with existing sources and
> import various directories with the sources into the IDEs, basically
> each directory that starts with "classes", this works for me in
> IntelliJ, Eclipse and Netbeans, if you add the JVM you just compiled
> they will follow its sources and you can make changes, and even
> compare with another JDK. I found for this kind of work Netbeans to
> work best and Eclipse second best, Netbeans seems to understand when
> your application goes into the native code and debugging continues
> into that (if you have the C code open as a separate project too),
> without any special trick, I did write a quick guide some time ago
> although you know all this stuff already:
>
> https://neugens.wordpress.com/2015/02/26/debugging-the-jdk-with-gdb/
>
> This guide is useful for command line gdb but you can attach with
> Eclipse (and NetBeans!) too, although when it goes into native land
> I'm sure you prefer the gdb console! :)
>
> Cheers,
> Mario


From robbin.ehn at oracle.com  Wed Jun  7 12:34:25 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 7 Jun 2017 14:34:25 +0200
Subject: Using an IDE to work on the Java library
In-Reply-To: <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
 <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com>
Message-ID: <9e79837b-c60b-8dff-1aa6-6ee3646a5eb7@oracle.com>

On 2017-06-05 18:51, Andrew Dinn wrote:
> On 05/06/17 17:30, Andrew Haley wrote:
>> Sorry for what must seem like a newbie question...
>>
>> I've done almost all of my work on HotSpot, and have very little
>> experience trying to use an IDE to work on the Java library.  Eclipse
>> is fine when working on libraries outdie the JDK itself, but seems to
>> want to look inside src.zip for its sources when debugging.  It would
>> be really nice to be able to see (and edit) the real Java source files
>> in jdk/java.base/.
>>
>> I suppose there must be some way to create a Project for an IDE, so
>> that debugging the standard library is easy.  Is there some advice
>> around somewhere?  What do people do?
>
> I use IntelliJ Idea. The latest releases cope quite happily with jdk9/10.

If you are a vim guy, I can recommend IntelliJ with the vim plugin.

/Robbin

>
> In the project settings you can set up a JDK you build from scratch as a
> project JDK and the sources located in the build image (in src.zip) will
> be picked up automatically by Idea.
>
> In order to see sources not in src.zip you need to add the jdk source
> tree to the project's main module as a source root (do this from the
> "open module settings" or "project structure" dialogs). Likewise, if you
> want the jdk.vm.ci sources for graal from the hotspot tree. So, for the
> latter case, I add jdk9/jdk/hotspot/src/jdk.internal.vm.ci as a source
> root. (Alternatively you can add it to an extra module that then gets
> inherited by the project module(s)).
>
> You then have to tag the relevant module subdirs in these added trees as
> src directories to bring the desired source files into play. For example
> for the jdk.vm.ci sources root I tag share/classes/jdk.v.ci.code/src etc
> as source dirs. Once again this is done from the "open module settings"
> dialog.
>
> Note that you can configure the module settings for app modules (or for
> any common extra module you add and then make them inherit) so that
> these extra  sources are picked up prior to any sources or (what you
> don't want) class files obtained from the project JDK.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>

From thomas.stuefe at gmail.com  Wed Jun  7 17:25:01 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 7 Jun 2017 19:25:01 +0200
Subject: Using an IDE to work on the Java library
In-Reply-To: <9e79837b-c60b-8dff-1aa6-6ee3646a5eb7@oracle.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
 <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com>
 <9e79837b-c60b-8dff-1aa6-6ee3646a5eb7@oracle.com>
Message-ID: <CAA-vtUxr6W3f74-Pu-NQq8ZNBdBdRzL80JffbKfmLg2-H-=Cvg@mail.gmail.com>

On Wed, Jun 7, 2017 at 2:34 PM, Robbin Ehn <robbin.ehn at oracle.com> wrote:

> On 2017-06-05 18:51, Andrew Dinn wrote:
>
>> On 05/06/17 17:30, Andrew Haley wrote:
>>
>>> Sorry for what must seem like a newbie question...
>>>
>>> I've done almost all of my work on HotSpot, and have very little
>>> experience trying to use an IDE to work on the Java library.  Eclipse
>>> is fine when working on libraries outdie the JDK itself, but seems to
>>> want to look inside src.zip for its sources when debugging.  It would
>>> be really nice to be able to see (and edit) the real Java source files
>>> in jdk/java.base/.
>>>
>>> I suppose there must be some way to create a Project for an IDE, so
>>> that debugging the standard library is easy.  Is there some advice
>>> around somewhere?  What do people do?
>>>
>>
>> I use IntelliJ Idea. The latest releases cope quite happily with jdk9/10.
>>
>
> If you are a vim guy, I can recommend IntelliJ with the vim plugin.
>
>
Does working on the OpenJDK sources require the full version or do you use
the Community Edition?

..Thomas

  /Robbin



> In the project settings you can set up a JDK you build from scratch as a
> project JDK and the sources located in the build image (in src.zip) will
> be picked up automatically by Idea.
>
> In order to see sources not in src.zip you need to add the jdk source
> tree to the project's main module as a source root (do this from the
> "open module settings" or "project structure" dialogs). Likewise, if you
> want the jdk.vm.ci sources for graal from the hotspot tree. So, for the
> latter case, I add jdk9/jdk/hotspot/src/jdk.internal.vm.ci as a source
> root. (Alternatively you can add it to an extra module that then gets
> inherited by the project module(s)).
>
> You then have to tag the relevant module subdirs in these added trees as
> src directories to bring the desired source files into play. For example
> for the jdk.vm.ci sources root I tag share/classes/jdk.v.ci.code/src etc
> as source dirs. Once again this is done from the "open module settings"
> dialog.
>
> Note that you can configure the module settings for app modules (or for
> any common extra module you add and then make them inherit) so that
> these extra  sources are picked up prior to any sources or (what you
> don't want) class files obtained from the project JDK.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>
>

From robbin.ehn at oracle.com  Wed Jun  7 20:31:54 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 7 Jun 2017 22:31:54 +0200
Subject: Using an IDE to work on the Java library
In-Reply-To: <CAA-vtUxr6W3f74-Pu-NQq8ZNBdBdRzL80JffbKfmLg2-H-=Cvg@mail.gmail.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
 <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com>
 <9e79837b-c60b-8dff-1aa6-6ee3646a5eb7@oracle.com>
 <CAA-vtUxr6W3f74-Pu-NQq8ZNBdBdRzL80JffbKfmLg2-H-=Cvg@mail.gmail.com>
Message-ID: <8215ad5d-f2d0-45ed-9ee8-5a59b1a2b8aa@oracle.com>

On 06/07/2017 07:25 PM, Thomas St?fe wrote:
> 
> 
> On Wed, Jun 7, 2017 at 2:34 PM, Robbin Ehn <robbin.ehn at oracle.com <mailto:robbin.ehn at oracle.com>> wrote:
> 
>     On 2017-06-05 18:51, Andrew Dinn wrote:
> 
>         On 05/06/17 17:30, Andrew Haley wrote:
> 
>             Sorry for what must seem like a newbie question...
> 
>             I've done almost all of my work on HotSpot, and have very little
>             experience trying to use an IDE to work on the Java library.  Eclipse
>             is fine when working on libraries outdie the JDK itself, but seems to
>             want to look inside src.zip for its sources when debugging.  It would
>             be really nice to be able to see (and edit) the real Java source files
>             in jdk/java.base/.
> 
>             I suppose there must be some way to create a Project for an IDE, so
>             that debugging the standard library is easy.  Is there some advice
>             around somewhere?  What do people do?
> 
> 
>         I use IntelliJ Idea. The latest releases cope quite happily with jdk9/10.
> 
> 
>     If you are a vim guy, I can recommend IntelliJ with the vim plugin.
> 
> Does working on the OpenJDK sources require the full version or do you use the Community Edition?

I have only tried full version, so I can't say.

/Robbin

> 
> ..Thomas
> 
> /Robbin
> 
> 
> 
>     In the project settings you can set up a JDK you build from scratch as a
>     project JDK and the sources located in the build image (in src.zip) will
>     be picked up automatically by Idea.
> 
>     In order to see sources not in src.zip you need to add the jdk source
>     tree to the project's main module as a source root (do this from the
>     "open module settings" or "project structure" dialogs). Likewise, if you
>     want the jdk.vm.ci <http://jdk.vm.ci> sources for graal from the hotspot tree. So, for the
>     latter case, I add jdk9/jdk/hotspot/src/jdk.internal.vm.ci <http://jdk.internal.vm.ci> as a source
>     root. (Alternatively you can add it to an extra module that then gets
>     inherited by the project module(s)).
> 
>     You then have to tag the relevant module subdirs in these added trees as
>     src directories to bring the desired source files into play. For example
>     for the jdk.vm.ci <http://jdk.vm.ci> sources root I tag share/classes/jdk.v.ci.code/src etc
>     as source dirs. Once again this is done from the "open module settings"
>     dialog.
> 
>     Note that you can configure the module settings for app modules (or for
>     any common extra module you add and then make them inherit) so that
>     these extra  sources are picked up prior to any sources or (what you
>     don't want) class files obtained from the project JDK.
> 
>     regards,
> 
> 
>     Andrew Dinn
>     -----------
>     Senior Principal Software Engineer
>     Red Hat UK Ltd
>     Registered in England and Wales under Company Registration No. 03798903
>     Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 
> 

From roger.riggs at oracle.com  Wed Jun  7 20:34:12 2017
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 7 Jun 2017 16:34:12 -0400
Subject: Using an IDE to work on the Java library
In-Reply-To: <8215ad5d-f2d0-45ed-9ee8-5a59b1a2b8aa@oracle.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
 <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com>
 <9e79837b-c60b-8dff-1aa6-6ee3646a5eb7@oracle.com>
 <CAA-vtUxr6W3f74-Pu-NQq8ZNBdBdRzL80JffbKfmLg2-H-=Cvg@mail.gmail.com>
 <8215ad5d-f2d0-45ed-9ee8-5a59b1a2b8aa@oracle.com>
Message-ID: <a0da3461-ffcc-4556-7b43-ace563313ffc@oracle.com>

The community edition works fine for me; though not as feature rich as 
the full version.

Roger


On 6/7/17 4:31 PM, Robbin Ehn wrote:
> On 06/07/2017 07:25 PM, Thomas St?fe wrote:
>>
>>
>> On Wed, Jun 7, 2017 at 2:34 PM, Robbin Ehn <robbin.ehn at oracle.com 
>> <mailto:robbin.ehn at oracle.com>> wrote:
>>
>>     On 2017-06-05 18:51, Andrew Dinn wrote:
>>
>>         On 05/06/17 17:30, Andrew Haley wrote:
>>
>>             Sorry for what must seem like a newbie question...
>>
>>             I've done almost all of my work on HotSpot, and have very 
>> little
>>             experience trying to use an IDE to work on the Java 
>> library.  Eclipse
>>             is fine when working on libraries outdie the JDK itself, 
>> but seems to
>>             want to look inside src.zip for its sources when 
>> debugging.  It would
>>             be really nice to be able to see (and edit) the real Java 
>> source files
>>             in jdk/java.base/.
>>
>>             I suppose there must be some way to create a Project for 
>> an IDE, so
>>             that debugging the standard library is easy.  Is there 
>> some advice
>>             around somewhere?  What do people do?
>>
>>
>>         I use IntelliJ Idea. The latest releases cope quite happily 
>> with jdk9/10.
>>
>>
>>     If you are a vim guy, I can recommend IntelliJ with the vim plugin.
>>
>> Does working on the OpenJDK sources require the full version or do 
>> you use the Community Edition?
>
> I have only tried full version, so I can't say.
>
> /Robbin
>
>>
>> ..Thomas
>>
>> /Robbin
>>
>>
>>
>>     In the project settings you can set up a JDK you build from 
>> scratch as a
>>     project JDK and the sources located in the build image (in 
>> src.zip) will
>>     be picked up automatically by Idea.
>>
>>     In order to see sources not in src.zip you need to add the jdk 
>> source
>>     tree to the project's main module as a source root (do this from the
>>     "open module settings" or "project structure" dialogs). Likewise, 
>> if you
>>     want the jdk.vm.ci <http://jdk.vm.ci> sources for graal from the 
>> hotspot tree. So, for the
>>     latter case, I add jdk9/jdk/hotspot/src/jdk.internal.vm.ci 
>> <http://jdk.internal.vm.ci> as a source
>>     root. (Alternatively you can add it to an extra module that then 
>> gets
>>     inherited by the project module(s)).
>>
>>     You then have to tag the relevant module subdirs in these added 
>> trees as
>>     src directories to bring the desired source files into play. For 
>> example
>>     for the jdk.vm.ci <http://jdk.vm.ci> sources root I tag 
>> share/classes/jdk.v.ci.code/src etc
>>     as source dirs. Once again this is done from the "open module 
>> settings"
>>     dialog.
>>
>>     Note that you can configure the module settings for app modules 
>> (or for
>>     any common extra module you add and then make them inherit) so that
>>     these extra  sources are picked up prior to any sources or (what you
>>     don't want) class files obtained from the project JDK.
>>
>>     regards,
>>
>>
>>     Andrew Dinn
>>     -----------
>>     Senior Principal Software Engineer
>>     Red Hat UK Ltd
>>     Registered in England and Wales under Company Registration No. 
>> 03798903
>>     Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric 
>> Shander
>>
>>


From mvala at redhat.com  Thu Jun  8 08:39:42 2017
From: mvala at redhat.com (Michal Vala)
Date: Thu, 8 Jun 2017 10:39:42 +0200
Subject: Using an IDE to work on the Java library
In-Reply-To: <8215ad5d-f2d0-45ed-9ee8-5a59b1a2b8aa@oracle.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
 <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com>
 <9e79837b-c60b-8dff-1aa6-6ee3646a5eb7@oracle.com>
 <CAA-vtUxr6W3f74-Pu-NQq8ZNBdBdRzL80JffbKfmLg2-H-=Cvg@mail.gmail.com>
 <8215ad5d-f2d0-45ed-9ee8-5a59b1a2b8aa@oracle.com>
Message-ID: <7f5aa14e-a7b5-f7f5-a66f-a9edd32b4f2f@redhat.com>



On 06/07/2017 10:31 PM, Robbin Ehn wrote:
> On 06/07/2017 07:25 PM, Thomas St?fe wrote:
>>
>>
>> On Wed, Jun 7, 2017 at 2:34 PM, Robbin Ehn <robbin.ehn at oracle.com 
>>
>> Does working on the OpenJDK sources require the full version or do you use the 
>> Community Edition?
> 
> I have only tried full version, so I can't say.

Full version has more features but most of them are focused on EE devs. Things 
like support for databases, frameworks, frontend (HTML, javascript, css) etc.
IMO there should be no difference in Community version for pure java development.

-- 
Michal Vala
OpenJDK QE
Red Hat Czech

From jesper.wilhelmsson at oracle.com  Thu Jun  8 19:25:15 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 8 Jun 2017 21:25:15 +0200
Subject: CFV: New JDK 10 Committer: Sharath Ballal
Message-ID: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>

I hereby nominate Sharath Ballal (sballal) to JDK 10 Committer.

Sharath is part of the Monitoring and Management team and has contributed 17 changesets to JDK 10.

Votes are due by June 22, 2017.

Only current JDK 10 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,
/Jesper

[1] http://openjdk.java.net/census <http://openjdk.java.net/census>
[2] http://openjdk.java.net/bylaws#lazy-consensus <http://openjdk.java.net/bylaws#lazy-consensus>
[3] List of changes:

(1) 6760477: Update SA to include stack traces in the heap dump
http://hg.openjdk.java.net/jdk9/hs/./rev/8589c969babc
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/4056535f52f5
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c2084773d623

(2) 8030750: SA: Alternate hashing not implemented
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378 <http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378>
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/f8b62710e186

(3) 8168397: sun/tools/jhsdb/HeapDumpTest.java timesout on MacOS X on non images build
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/71457eaca096

(4) 8160376: DebuggerException: Can't attach symbolicator to the process
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/7a5fa747419d
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ad402ced3a63

(5) 8166657: Remove exports com.sun.tools.jdi to jdk.hotspot.agent
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/9d4a52d62493

(6) 8164943: sun/tools/jhsdb/HeapDumpTest failed with Can't find library: /test/lib/share/classes
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/03e9322dc0a5

(7) 8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout.
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/659f01da7ec0
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b50061da090e

(8) 8160817: Add jsadebugd functionality to jhsdb
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/ecc9399771ac
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a2812668bf38

(9) 8158050: Remove SA-JDI
http://hg.openjdk.java.net/jdk9/hs/./rev/106f2f8b0ec9
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/02651d14d282
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2e21095f80c6

(10) 8154144: Tests in com/sun/jdi fails intermittently with &quot;jdb input stream closed prematurely&quot;
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/73608cd4f89a

(11) 8147456: Parsing of argument for -agentpath can write outside of allocated memory
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/b58e7a5634e8
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/7fbe91178ff9

(12) 6659240: Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/e260a6ff2110

(13) 7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1d8d01c86279

(14) 7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3784c8f92b5b

(15) 8165537: runtime/SharedArchiveFile/SASymbolTableTest.java fails with NullPointerException
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/776d89e316b6

(16) 8165114: stale reference to hotspot test Test8028623.java
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c54ebf67ef13

(17) 8163269: Testcase missed in push for JDK-8160817
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/37ce5a8e59cc


From rahul.v.raghavan at oracle.com  Fri Jun  9 09:09:13 2017
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Fri, 9 Jun 2017 02:09:13 -0700 (PDT)
Subject: CFV: New JDK 10 Committer: Sharath Ballal
In-Reply-To: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
References: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
Message-ID: <35c2489a-1f71-4c2b-9b9a-aebe11e03227@default>

Vote: yes

Thanks,
Rahul

> -----Original Message-----
> From: Jesper Wilhelmsson
> Sent: Friday, June 09, 2017 12:55 AM
> To: jdk10-dev at openjdk.java.net
> Subject: CFV: New JDK 10 Committer: Sharath Ballal
> 
> I hereby nominate Sharath Ballal (sballal) to JDK 10 Committer.
> 
> Sharath is part of the Monitoring and Management team and has contributed 17 changesets to JDK 10.
> 
> Votes are due by June 22, 2017.
> 
> Only current JDK 10 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,
> /Jesper
> 
> [1] http://openjdk.java.net/census <http://openjdk.java.net/census>
> [2] http://openjdk.java.net/bylaws#lazy-consensus <http://openjdk.java.net/bylaws#lazy-consensus>
> [3] List of changes:
> 
> (1) 6760477: Update SA to include stack traces in the heap dump
> http://hg.openjdk.java.net/jdk9/hs/./rev/8589c969babc
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/4056535f52f5
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c2084773d623
> 
> (2) 8030750: SA: Alternate hashing not implemented
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378 <http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378>
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/f8b62710e186
> 
> (3) 8168397: sun/tools/jhsdb/HeapDumpTest.java timesout on MacOS X on non images build
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/71457eaca096
> 
> (4) 8160376: DebuggerException: Can't attach symbolicator to the process
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/7a5fa747419d
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ad402ced3a63
> 
> (5) 8166657: Remove exports com.sun.tools.jdi to jdk.hotspot.agent
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/9d4a52d62493
> 
> (6) 8164943: sun/tools/jhsdb/HeapDumpTest failed with Can't find library: /test/lib/share/classes
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/03e9322dc0a5
> 
> (7) 8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout.
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/659f01da7ec0
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b50061da090e
> 
> (8) 8160817: Add jsadebugd functionality to jhsdb
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/ecc9399771ac
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a2812668bf38
> 
> (9) 8158050: Remove SA-JDI
> http://hg.openjdk.java.net/jdk9/hs/./rev/106f2f8b0ec9
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/02651d14d282
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2e21095f80c6
> 
> (10) 8154144: Tests in com/sun/jdi fails intermittently with &quot;jdb input stream closed prematurely&quot;
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/73608cd4f89a
> 
> (11) 8147456: Parsing of argument for -agentpath can write outside of allocated memory
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/b58e7a5634e8
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/7fbe91178ff9
> 
> (12) 6659240: Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/e260a6ff2110
> 
> (13) 7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1d8d01c86279
> 
> (14) 7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3784c8f92b5b
> 
> (15) 8165537: runtime/SharedArchiveFile/SASymbolTableTest.java fails with NullPointerException
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/776d89e316b6
> 
> (16) 8165114: stale reference to hotspot test Test8028623.java
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c54ebf67ef13
> 
> (17) 8163269: Testcase missed in push for JDK-8160817
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/37ce5a8e59cc
> 

From harsha.wardhana.b at oracle.com  Fri Jun  9 12:39:19 2017
From: harsha.wardhana.b at oracle.com (Harsha Wardhana B)
Date: Fri, 9 Jun 2017 18:09:19 +0530
Subject: CFV: New JDK 10 Committer: Sharath Ballal
In-Reply-To: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
References: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
Message-ID: <0ee9088e-895b-4149-57d2-0f6adb2f4863@oracle.com>

Vote: yes

-Harsha


On Friday 09 June 2017 12:55 AM, jesper.wilhelmsson at oracle.com wrote:
> I hereby nominate Sharath Ballal (sballal) to JDK 10 Committer.
>
> Sharath is part of the Monitoring and Management team and has contributed 17 changesets to JDK 10.
>
> Votes are due by June 22, 2017.
>
> Only current JDK 10 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,
> /Jesper
>
> [1] http://openjdk.java.net/census <http://openjdk.java.net/census>
> [2] http://openjdk.java.net/bylaws#lazy-consensus <http://openjdk.java.net/bylaws#lazy-consensus>
> [3] List of changes:
>
> (1) 6760477: Update SA to include stack traces in the heap dump
> http://hg.openjdk.java.net/jdk9/hs/./rev/8589c969babc
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/4056535f52f5
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c2084773d623
>
> (2) 8030750: SA: Alternate hashing not implemented
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378 <http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378>
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/f8b62710e186
>
> (3) 8168397: sun/tools/jhsdb/HeapDumpTest.java timesout on MacOS X on non images build
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/71457eaca096
>
> (4) 8160376: DebuggerException: Can't attach symbolicator to the process
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/7a5fa747419d
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ad402ced3a63
>
> (5) 8166657: Remove exports com.sun.tools.jdi to jdk.hotspot.agent
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/9d4a52d62493
>
> (6) 8164943: sun/tools/jhsdb/HeapDumpTest failed with Can't find library: /test/lib/share/classes
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/03e9322dc0a5
>
> (7) 8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout.
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/659f01da7ec0
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b50061da090e
>
> (8) 8160817: Add jsadebugd functionality to jhsdb
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/ecc9399771ac
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a2812668bf38
>
> (9) 8158050: Remove SA-JDI
> http://hg.openjdk.java.net/jdk9/hs/./rev/106f2f8b0ec9
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/02651d14d282
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2e21095f80c6
>
> (10) 8154144: Tests in com/sun/jdi fails intermittently with &quot;jdb input stream closed prematurely&quot;
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/73608cd4f89a
>
> (11) 8147456: Parsing of argument for -agentpath can write outside of allocated memory
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/b58e7a5634e8
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/7fbe91178ff9
>
> (12) 6659240: Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/e260a6ff2110
>
> (13) 7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1d8d01c86279
>
> (14) 7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3784c8f92b5b
>
> (15) 8165537: runtime/SharedArchiveFile/SASymbolTableTest.java fails with NullPointerException
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/776d89e316b6
>
> (16) 8165114: stale reference to hotspot test Test8028623.java
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c54ebf67ef13
>
> (17) 8163269: Testcase missed in push for JDK-8160817
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/37ce5a8e59cc
>


From jesper.wilhelmsson at oracle.com  Fri Jun  9 12:44:18 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Fri, 9 Jun 2017 14:44:18 +0200
Subject: CFV: New JDK 10 Committer: Sharath Ballal
In-Reply-To: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
References: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
Message-ID: <99375600-2A21-4B18-A894-E4C0894BD6A1@oracle.com>

Vote: Yes
/Jesper

> On 8 Jun 2017, at 21:25, jesper.wilhelmsson at oracle.com wrote:
> 
> I hereby nominate Sharath Ballal (sballal) to JDK 10 Committer.
> 
> Sharath is part of the Monitoring and Management team and has contributed 17 changesets to JDK 10.
> 
> Votes are due by June 22, 2017.
> 
> Only current JDK 10 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,
> /Jesper
> 
> [1] http://openjdk.java.net/census <http://openjdk.java.net/census>
> [2] http://openjdk.java.net/bylaws#lazy-consensus <http://openjdk.java.net/bylaws#lazy-consensus>
> [3] List of changes:
> 
> (1) 6760477: Update SA to include stack traces in the heap dump
> http://hg.openjdk.java.net/jdk9/hs/./rev/8589c969babc
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/4056535f52f5
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c2084773d623
> 
> (2) 8030750: SA: Alternate hashing not implemented
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378 <http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378>
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/f8b62710e186
> 
> (3) 8168397: sun/tools/jhsdb/HeapDumpTest.java timesout on MacOS X on non images build
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/71457eaca096
> 
> (4) 8160376: DebuggerException: Can't attach symbolicator to the process
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/7a5fa747419d
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ad402ced3a63
> 
> (5) 8166657: Remove exports com.sun.tools.jdi to jdk.hotspot.agent
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/9d4a52d62493
> 
> (6) 8164943: sun/tools/jhsdb/HeapDumpTest failed with Can't find library: /test/lib/share/classes
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/03e9322dc0a5
> 
> (7) 8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout.
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/659f01da7ec0
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b50061da090e
> 
> (8) 8160817: Add jsadebugd functionality to jhsdb
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/ecc9399771ac
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a2812668bf38
> 
> (9) 8158050: Remove SA-JDI
> http://hg.openjdk.java.net/jdk9/hs/./rev/106f2f8b0ec9
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/02651d14d282
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2e21095f80c6
> 
> (10) 8154144: Tests in com/sun/jdi fails intermittently with &quot;jdb input stream closed prematurely&quot;
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/73608cd4f89a
> 
> (11) 8147456: Parsing of argument for -agentpath can write outside of allocated memory
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/b58e7a5634e8
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/7fbe91178ff9
> 
> (12) 6659240: Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/e260a6ff2110
> 
> (13) 7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1d8d01c86279
> 
> (14) 7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3784c8f92b5b
> 
> (15) 8165537: runtime/SharedArchiveFile/SASymbolTableTest.java fails with NullPointerException
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/776d89e316b6
> 
> (16) 8165114: stale reference to hotspot test Test8028623.java
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c54ebf67ef13
> 
> (17) 8163269: Testcase missed in push for JDK-8160817
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/37ce5a8e59cc
> 


From sundararajan.athijegannathan at oracle.com  Fri Jun  9 12:52:25 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 09 Jun 2017 18:22:25 +0530
Subject: CFV: New JDK 10 Committer: Sharath Ballal
In-Reply-To: <99375600-2A21-4B18-A894-E4C0894BD6A1@oracle.com>
References: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
 <99375600-2A21-4B18-A894-E4C0894BD6A1@oracle.com>
Message-ID: <593A9A09.5080901@oracle.com>

Vote: Yes

-Sundar

On 09/06/17, 6:14 PM, jesper.wilhelmsson at oracle.com wrote:
> Vote: Yes
> /Jesper
>
>> On 8 Jun 2017, at 21:25, jesper.wilhelmsson at oracle.com wrote:
>>
>> I hereby nominate Sharath Ballal (sballal) to JDK 10 Committer.
>>
>> Sharath is part of the Monitoring and Management team and has contributed 17 changesets to JDK 10.
>>
>> Votes are due by June 22, 2017.
>>
>> Only current JDK 10 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,
>> /Jesper
>>
>> [1] http://openjdk.java.net/census<http://openjdk.java.net/census>
>> [2] http://openjdk.java.net/bylaws#lazy-consensus<http://openjdk.java.net/bylaws#lazy-consensus>
>> [3] List of changes:
>>
>> (1) 6760477: Update SA to include stack traces in the heap dump
>> http://hg.openjdk.java.net/jdk9/hs/./rev/8589c969babc
>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/4056535f52f5
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c2084773d623
>>
>> (2) 8030750: SA: Alternate hashing not implemented
>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378<http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378>
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/f8b62710e186
>>
>> (3) 8168397: sun/tools/jhsdb/HeapDumpTest.java timesout on MacOS X on non images build
>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/71457eaca096
>>
>> (4) 8160376: DebuggerException: Can't attach symbolicator to the process
>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/7a5fa747419d
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ad402ced3a63
>>
>> (5) 8166657: Remove exports com.sun.tools.jdi to jdk.hotspot.agent
>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/9d4a52d62493
>>
>> (6) 8164943: sun/tools/jhsdb/HeapDumpTest failed with Can't find library: /test/lib/share/classes
>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/03e9322dc0a5
>>
>> (7) 8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout.
>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/659f01da7ec0
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b50061da090e
>>
>> (8) 8160817: Add jsadebugd functionality to jhsdb
>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/ecc9399771ac
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a2812668bf38
>>
>> (9) 8158050: Remove SA-JDI
>> http://hg.openjdk.java.net/jdk9/hs/./rev/106f2f8b0ec9
>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/02651d14d282
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2e21095f80c6
>>
>> (10) 8154144: Tests in com/sun/jdi fails intermittently with&quot;jdb input stream closed prematurely&quot;
>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/73608cd4f89a
>>
>> (11) 8147456: Parsing of argument for -agentpath can write outside of allocated memory
>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/b58e7a5634e8
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/7fbe91178ff9
>>
>> (12) 6659240: Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory
>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/e260a6ff2110
>>
>> (13) 7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1d8d01c86279
>>
>> (14) 7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3784c8f92b5b
>>
>> (15) 8165537: runtime/SharedArchiveFile/SASymbolTableTest.java fails with NullPointerException
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/776d89e316b6
>>
>> (16) 8165114: stale reference to hotspot test Test8028623.java
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c54ebf67ef13
>>
>> (17) 8163269: Testcase missed in push for JDK-8160817
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/37ce5a8e59cc
>>

From vladimir.x.ivanov at oracle.com  Fri Jun  9 12:56:55 2017
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 9 Jun 2017 15:56:55 +0300
Subject: CFV: New JDK 10 Committer: Sharath Ballal
In-Reply-To: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
References: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
Message-ID: <eea40df6-f812-108e-c72f-1f4aaa77e97f@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

On 6/8/17 10:25 PM, jesper.wilhelmsson at oracle.com wrote:
> I hereby nominate Sharath Ballal (sballal) to JDK 10 Committer.

From jini.george at oracle.com  Fri Jun  9 14:00:57 2017
From: jini.george at oracle.com (Jini George)
Date: Fri, 9 Jun 2017 19:30:57 +0530
Subject: CFV: New JDK 10 Committer: Sharath Ballal
In-Reply-To: <eea40df6-f812-108e-c72f-1f4aaa77e97f@oracle.com>
References: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
 <eea40df6-f812-108e-c72f-1f4aaa77e97f@oracle.com>
Message-ID: <9a9fc9f1-8d13-fd16-7353-45a0621ad6f5@oracle.com>

Vote: yes

- jini.

On 6/9/2017 6:26 PM, Vladimir Ivanov wrote:
> Vote: yes
>
> Best regards,
> Vladimir Ivanov
>
> On 6/8/17 10:25 PM, jesper.wilhelmsson at oracle.com wrote:
>> I hereby nominate Sharath Ballal (sballal) to JDK 10 Committer.


From jamsheed.c.m at oracle.com  Fri Jun  9 15:08:57 2017
From: jamsheed.c.m at oracle.com (Jamsheed C m)
Date: Fri, 9 Jun 2017 20:38:57 +0530
Subject: CFV: New JDK 10 Committer: Sharath Ballal
In-Reply-To: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
References: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
Message-ID: <4aac8655-a4ae-c2ee-fa23-710adb153231@oracle.com>

Vote: Yes

Best Regards,
Jamsheed

From bradford.wetmore at oracle.com  Tue Jun 13 02:06:45 2017
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 12 Jun 2017 19:06:45 -0700
Subject: Using an IDE to work on the Java library
In-Reply-To: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
Message-ID: <dab30794-b7df-7b39-4f40-99ede217a1f9@oracle.com>

Hi Andrew (and others),

On 6/5/2017 9:30 AM, Andrew Haley wrote:
> Sorry for what must seem like a newbie question...

Great question, as I *MUCH* prefer an IDE to System.out.println().  ;)

> ...deleted... > I suppose there must be some way to create a Project for an IDE, so
> that debugging the standard library is easy.  Is there some advice
> around somewhere?  What do people do?

Ok, I'll throw out my approach, which works well for me.

Note:  I personally haven't looked at the included netbeans projects 
recently as they didn't work years ago, and I have a solution that works 
for me now.

--begin---
Here's something that might help with JDK 9 library development.  I've 
been able to get development builds of Netbeans 9 running to debug my 
JDK 9 libraries, and while there are still some sharp edges (and dull 
ones), it's been nice having a real debugger that understands modules. 
(JDK 8.2 can also be used with more setup, but it doesn't understand 
modules.)

I thought I'd share my process, since some folks have asked.  Please 
understand, I'm not a Netbeans power user, I'm just sharing what has 
worked for me in hopes this might save you some time.

1.  Build a current JDK

     % hg clone http://hg.openjdk.java.net/jdk9/dev
     % cd dev
     % bash ./get_source.sh     # add closed source if possible/desired.
     % bash configure --enable-debug -- \
           --with-default-make-target=exploded-image ...other options...
           (--with-output-sync=recurse is a good idea)
     % cd build/*-normal-server-fastdebug/
     % make LOG=debug

2.  Download the "OS Independent Zip" JDK 9 build of NetBeans.

     http://netbeans.org
         Download
         Development
         Platform:  OS Independent Zip
         Download

I had problems with the Windows Netbeans 9 build and missing Netbeans 
classes [1], that's why I'm suggesting the OS Independent Zip.

     % unzip netbeans-trunk-nightly-*-javase.zip

If you are using windows, you'll need to make the .exe/.dll bits executable:

     % cd netbeans*
     % find . -type f -name '*.exe' -exec chmod +x {} \;
     % find . -type f -name '*.dll' -exec chmod +x {} \;

Be sure to have a JDK 8 build for the jdkhome.  If NB can't find a JDK 8 
in your path, you can hardcode it in etc/netbeans.conf:

     netbeans_jdkhome="d:\java\bootdirs\jdk1.8.0_112"

3.  Start NetBeans.

     % bin/netbeans       # Solaris/Linux/MacOS/etc.
or
     % bin/netbeans64.exe     # Windows

4.  Install Jan Lahoda's (Oracle JDK/Netbeans) "JDK Project for 
NetBeans" plugin.  Also "JTReg Support" if you are using JTReg.

     . In Tools->Plugins menu go to Settings
     . Click Add button
     . In the URL paste:

 
http://lahoda.info/hudson/job/nb-jdk-project/lastSuccessfulBuild/artifact/build/updates/updates.xml

     . In Available plugins click ?Check for Newest? to refresh the list.
     . Select both ?JDK Project for NetBeans? and "JTReg Support"
     . Press "Install" button and follow the Wizard steps.

Restart NB 9.

5.  Add your JDK 9 exploded build as a Java Platform

     .  Tools->Java Platforms->Add Platform
     .  Select "Java Standard Edition", Next
     .  /export/home/me/build/*-normal-server-fastdebug/jdk
     .  Pick a platform name.  Do not add sources, they will be
        found by the JDK Project (above).
        (gensrc/shared/platform/closed)
     .  Finish

6.  Navigate and open to the Java modules you'll be using.  e.g.

     jdk/src/java.base
     jdk/src/jdk.crypto.cryptoki

The very first time you open the module, it will take a couple minutes 
to scan through everything (source/binary/etc).  Restarts are faster 
after things are cached.

7.  Next, depending on whether you'll debug a standalone app or a JTREG 
test from the test directories:

7a.  Standalone:  create a test project app as normal, then select the 
JDK 9 platform.

     .  Right click on project, select Properties.
     .  Choose libraries, select the platform you just created.

7b.  JTREG:  In the module you opened (above), navigate to the jdk test 
directory.  e.g.

     ${jdkRoot}/jdk/test

NOTE WELL:  The JTReg plugin understands the JTReg directives, however 
(currently) debugging a JTReg test will trigger a remake of the 
entire(!) JDK platform.  On my Windows machine, an incremental make 
takes about three minutes before the test is compiled and the Green 
Debug bar is displayed.  Turn this behavior off by unselecting the 
OpenJDK Property "Build before running tests."

It will take a while to scan through the test directories 
(source/binary/etc).  Restarts are faster as things are cached.

8.  Set a break point in your app and start debugging.  You should be 
able to "Step In (F7)" to the JDK library code.

9.  If you make any changes (think/edit/compile) to your JDK code, I 
suggest stopping the debugger, then use a separate window to do the 
make.  For a simple rebuild of the classes in java/security + 
sun/security, I do:

     # cwd:  build/*-normal-server-fastdebug

     % make LOG=debug \
         JDK_FILTER=java/security,sun/security \
         java.base-java-only     # or java.base-only

Netbeans will notice any changes and reload as needed.  Then restart the 
debugger.

I would like to make a wiki page with this info at some point, so if you 
have any comments, let me know.

Good luck,

Brad

[1]  https://netbeans.org/bugzilla/show_bug.cgi?id=268055
---end---



From aph at redhat.com  Tue Jun 13 09:05:36 2017
From: aph at redhat.com (Andrew Haley)
Date: Tue, 13 Jun 2017 10:05:36 +0100
Subject: Using an IDE to work on the Java library
In-Reply-To: <dab30794-b7df-7b39-4f40-99ede217a1f9@oracle.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
 <dab30794-b7df-7b39-4f40-99ede217a1f9@oracle.com>
Message-ID: <c4529c49-3d0e-0edb-0d27-2a9ff30b8144@redhat.com>

On 13/06/17 03:06, Bradford Wetmore wrote:
> I would like to make a wiki page with this info at some point, so if you 
> have any comments, let me know.

Oh yeah, that would be very cool.

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

From hs at tagtraum.com  Tue Jun 13 09:19:13 2017
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 13 Jun 2017 11:19:13 +0200
Subject: Using an IDE to work on the Java library
In-Reply-To: <c4529c49-3d0e-0edb-0d27-2a9ff30b8144@redhat.com>
References: <f52e1606-af8b-b66b-51d0-b8deb6ba40a8@redhat.com>
 <dab30794-b7df-7b39-4f40-99ede217a1f9@oracle.com>
 <c4529c49-3d0e-0edb-0d27-2a9ff30b8144@redhat.com>
Message-ID: <76564EC2-31E0-4E4E-ADFD-1C291F210958@tagtraum.com>


> On Jun 13, 2017, at 11:05, Andrew Haley <aph at redhat.com> wrote:
> 
> On 13/06/17 03:06, Bradford Wetmore wrote:
>> I would like to make a wiki page with this info at some point, so if you 
>> have any comments, let me know.
> 
> Oh yeah, that would be very cool.

+1

Perhaps also add a link to it to the main README?
Reducing the pain for the occasional tinkerer might help getting more community contributions.

-hendrik

From aph at redhat.com  Tue Jun 13 13:02:15 2017
From: aph at redhat.com (Andrew Haley)
Date: Tue, 13 Jun 2017 14:02:15 +0100
Subject: CFV: New JDK 10 Reviewer: Andrew Dinn
In-Reply-To: <177a88db-ad04-21da-2fb9-3b9564e3863f@redhat.com>
References: <177a88db-ad04-21da-2fb9-3b9564e3863f@redhat.com>
Message-ID: <8b10e24c-e97c-b991-820b-535e13d2f3d8@redhat.com>

Voting for Andrew Dinn [0] is now closed.

Yes: 20
Veto: 0
Abstain: 0

According to the Bylaws definition of Three-Vote Consensus [1], this is
sufficient to approve the nomination.

[0] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-May/000196.html
[1] http://openjdk.java.net/bylaws#three-vote-consensus

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

From serguei.spitsyn at oracle.com  Wed Jun 14 00:44:52 2017
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 13 Jun 2017 17:44:52 -0700
Subject: CFV: New JDK 10 Committer: Sharath Ballal
In-Reply-To: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
References: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
Message-ID: <5dad123f-4773-01d1-fd4b-eb13d49822f3@oracle.com>

Vote: yes

From mark.reinhold at oracle.com  Thu Jun 15 16:20:42 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 15 Jun 2017 09:20:42 -0700
Subject: JEP proposed to target JDK 10  (2017/4/18)
In-Reply-To: <20170418141426.928357691@eggemoggin.niobe.net>
References: <20170418141426.928357691@eggemoggin.niobe.net>
Message-ID: <20170615092042.987979299@eggemoggin.niobe.net>

2017/4/18 14:14:26 -0700, mark.reinhold at oracle.com:
> The following JEP has been placed into the "Proposed to Target"
> state by its owner after discussion and review:
> 
>   296: Consolidate the JDK Forest into a Single Repository
>        http://openjdk.java.net/jeps/296
> 
> Feedback on this proposal is welcome, as are reasoned objections.
> If no such objections are raised by 23:00 UTC next Tuesday, 25
> April, or if they're raised and then satisfactorily answered,
> then per the JEP 2.0 process proposal [1] I'll target this JEP
> to JDK 10.

Hearing no objections, I've targeted this JEP to JDK 10.

- Mark

From sean.coffey at oracle.com  Tue Jun 20 20:39:20 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 20 Jun 2017 21:39:20 +0100
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
Message-ID: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>

I hereby nominate Dmitry Markov (dmarkov) to JDK 10 Reviewer.

Dmitry Markov is an engineer in the Oracle JDK sustaining team. He has 
contributed several changes to the JDK 10 Project [3].

Votes are due by 22:00 GMT, 4th July 2017.

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

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

regards,
Sean.

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#reviewer-vote
[3] 
http://hg.openjdk.java.net/jdk10/jdk10/jdk/log?revcount=100&rev=%28keyword%28%22dmitry.markov%40oracle.com%22%29+or+author%28dmarkov%29%29

From vladimir.kozlov at oracle.com  Tue Jun 20 21:33:26 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 20 Jun 2017 14:33:26 -0700
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
In-Reply-To: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
Message-ID: <82f7a02b-eb95-9dd8-2ab2-a0ee3c3d169d@oracle.com>

Vote: yes

On 6/20/17 1:39 PM, Se?n Coffey wrote:
> I hereby nominate Dmitry Markov (dmarkov) to JDK 10 Reviewer.
> 
> Dmitry Markov is an engineer in the Oracle JDK sustaining team. He has contributed several changes to the JDK 10 Project [3].
> 
> Votes are due by 22:00 GMT, 4th July 2017.
> 
> Only current JDK 10 Reviewers [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [2].
> 
> regards,
> Sean.
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] http://hg.openjdk.java.net/jdk10/jdk10/jdk/log?revcount=100&rev=%28keyword%28%22dmitry.markov%40oracle.com%22%29+or+author%28dmarkov%29%29

From serguei.spitsyn at oracle.com  Wed Jun 21 07:50:38 2017
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 21 Jun 2017 00:50:38 -0700
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
In-Reply-To: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
Message-ID: <45482f4a-ded6-a3a5-444c-94bbf7260c64@oracle.com>

Vote: yes

From sean.coffey at oracle.com  Wed Jun 21 07:58:18 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 21 Jun 2017 08:58:18 +0100
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
In-Reply-To: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
Message-ID: <7e6c040d-045a-75d6-7fe7-45b91ad52766@oracle.com>

Vote: yes

regards,
Sean.

On 20/06/2017 21:39, Se?n Coffey wrote:
> I hereby nominate Dmitry Markov (dmarkov) to JDK 10 Reviewer.
>
> Dmitry Markov is an engineer in the Oracle JDK sustaining team. He has 
> contributed several changes to the JDK 10 Project [3].
>
> Votes are due by 22:00 GMT, 4th July 2017.
>
> Only current JDK 10 Reviewers [1] are eligible to vote on this 
> nomination.  Votes must be cast in the open by replying to this 
> mailing list.
>
> For Three-Vote Consensus voting instructions, see [2].
>
> regards,
> Sean.
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/log?revcount=100&rev=%28keyword%28%22dmitry.markov%40oracle.com%22%29+or+author%28dmarkov%29%29


From claes.redestad at oracle.com  Wed Jun 21 09:51:03 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 21 Jun 2017 11:51:03 +0200
Subject: Native tests in the JDK?!
Message-ID: <6acadcb5-bc60-7e55-23f6-26270dc4e939@oracle.com>

Hi jdk10-dev,

8181147 added build infrastructure support to test native code in the 
JDK core libraries, with a test specifically exercising String 
encoding/decoding methods in libjava.

During review on core-libs-dev and build-dev the issue was raised that 
this might surprise some users (and test systems) with some variant of 
"Error: Use -nativepath to specify the location of native code", since 
jtreg will expect you to build a test library and add it using -nativepath.

Consider this a late notification that this is something you might 
unexpectedly run into.

Making it harder to test locally isn't nice, but thankfully there's new, 
helpful support in the jdk10 makefiles to do all the required test setup 
and build automatically (tips many hats at Magnus Ihse-Bursie), which 
makes adapting to this (and any future additions) a breeze:

$ make run-test TEST=jdk/test/java/lang

Alternatively, if one has to run jtreg directly and can't be bothered 
with any of this - because reasons - one may add the flag -k:!native to 
exclude any and all native tests.

Thanks/Sorry!

/Claes

From sergey.bylokhov at oracle.com  Wed Jun 21 12:50:52 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Jun 2017 05:50:52 -0700 (PDT)
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
Message-ID: <bf526191-54e3-4dbd-9d07-725b5d07c924@default>

Vote: yes

----- sean.coffey at oracle.com wrote:

> I hereby nominate Dmitry Markov (dmarkov) to JDK 10 Reviewer.
> 
> Dmitry Markov is an engineer in the Oracle JDK sustaining team. He has
> 
> contributed several changes to the JDK 10 Project [3].
> 
> Votes are due by 22:00 GMT, 4th July 2017.
> 
> Only current JDK 10 Reviewers [1] are eligible to vote on this 
> nomination.  Votes must be cast in the open by replying to this
> mailing 
> list.
> 
> For Three-Vote Consensus voting instructions, see [2].
> 
> regards,
> Sean.
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/log?revcount=100&rev=%28keyword%28%22dmitry.markov%40oracle.com%22%29+or+author%28dmarkov%29%29

From zoltan.majo at oracle.com  Wed Jun 21 13:19:35 2017
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Wed, 21 Jun 2017 15:19:35 +0200
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
In-Reply-To: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
Message-ID: <77ab222f-1bee-b843-faaf-b22c1c64a80e@oracle.com>

Vote: yes.

Best regards,


Zoltan


On 06/20/2017 10:39 PM, Se?n Coffey wrote:
> I hereby nominate Dmitry Markov (dmarkov) to JDK 10 Reviewer.
>
> Dmitry Markov is an engineer in the Oracle JDK sustaining team. He has 
> contributed several changes to the JDK 10 Project [3].
>
> Votes are due by 22:00 GMT, 4th July 2017.
>
> Only current JDK 10 Reviewers [1] are eligible to vote on this 
> nomination.  Votes must be cast in the open by replying to this 
> mailing list.
>
> For Three-Vote Consensus voting instructions, see [2].
>
> regards,
> Sean.
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] 
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/log?revcount=100&rev=%28keyword%28%22dmitry.markov%40oracle.com%22%29+or+author%28dmarkov%29%29


From daniel.fuchs at oracle.com  Wed Jun 21 14:29:28 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 21 Jun 2017 15:29:28 +0100
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
In-Reply-To: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
Message-ID: <0e7ed829-685e-3add-78c5-615be6d4b2f4@oracle.com>

Vote: yes

-- daniel

On 20/06/2017 21:39, Se?n Coffey wrote:
> I hereby nominate Dmitry Markov (dmarkov) to JDK 10 Reviewer.


From roger.riggs at oracle.com  Wed Jun 21 14:31:53 2017
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 21 Jun 2017 10:31:53 -0400
Subject: CFV: New JDK 10 Committer: Sharath Ballal
In-Reply-To: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
References: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
Message-ID: <89e70f38-88da-4988-399a-501e99f8430c@oracle.com>

Vote: yes

On 6/8/17 3:25 PM, jesper.wilhelmsson at oracle.com wrote:
> I hereby nominate Sharath Ballal (sballal) to JDK 10 Committer.
>
> Sharath is part of the Monitoring and Management team and has contributed 17 changesets to JDK 10.
>
> Votes are due by June 22, 2017.
>
> Only current JDK 10 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,
> /Jesper
>
> [1] http://openjdk.java.net/census <http://openjdk.java.net/census>
> [2] http://openjdk.java.net/bylaws#lazy-consensus <http://openjdk.java.net/bylaws#lazy-consensus>
> [3] List of changes:
>
> (1) 6760477: Update SA to include stack traces in the heap dump
> http://hg.openjdk.java.net/jdk9/hs/./rev/8589c969babc
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/4056535f52f5
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c2084773d623
>
> (2) 8030750: SA: Alternate hashing not implemented
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378 <http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378>
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/f8b62710e186
>
> (3) 8168397: sun/tools/jhsdb/HeapDumpTest.java timesout on MacOS X on non images build
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/71457eaca096
>
> (4) 8160376: DebuggerException: Can't attach symbolicator to the process
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/7a5fa747419d
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ad402ced3a63
>
> (5) 8166657: Remove exports com.sun.tools.jdi to jdk.hotspot.agent
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/9d4a52d62493
>
> (6) 8164943: sun/tools/jhsdb/HeapDumpTest failed with Can't find library: /test/lib/share/classes
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/03e9322dc0a5
>
> (7) 8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout.
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/659f01da7ec0
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b50061da090e
>
> (8) 8160817: Add jsadebugd functionality to jhsdb
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/ecc9399771ac
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a2812668bf38
>
> (9) 8158050: Remove SA-JDI
> http://hg.openjdk.java.net/jdk9/hs/./rev/106f2f8b0ec9
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/02651d14d282
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2e21095f80c6
>
> (10) 8154144: Tests in com/sun/jdi fails intermittently with &quot;jdb input stream closed prematurely&quot;
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/73608cd4f89a
>
> (11) 8147456: Parsing of argument for -agentpath can write outside of allocated memory
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/b58e7a5634e8
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/7fbe91178ff9
>
> (12) 6659240: Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/e260a6ff2110
>
> (13) 7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1d8d01c86279
>
> (14) 7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3784c8f92b5b
>
> (15) 8165537: runtime/SharedArchiveFile/SASymbolTableTest.java fails with NullPointerException
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/776d89e316b6
>
> (16) 8165114: stale reference to hotspot test Test8028623.java
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c54ebf67ef13
>
> (17) 8163269: Testcase missed in push for JDK-8160817
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/37ce5a8e59cc
>


From stefan.karlsson at oracle.com  Thu Jun 22 07:51:11 2017
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 22 Jun 2017 09:51:11 +0200
Subject: =?UTF-8?Q?Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlund?=
Message-ID: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>

I hereby nominate Erik ?sterlund to JDK 10 Committer.

Erik is a member of the Garbage Collection team in Oracle. He likes to 
rewrite  and fix bugs in the OrderAccess and Atomics layers, loves 
template metaprogramming, and is currently working on creating a GC 
Barrier Interface as a part of JEP 304 - Garbage-Collector Interface [3][4]

Votes are due by 2017-07-06T09:50+02:00.

Only current JDK 10 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].

Stefan Karlsson

Contributions:
  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing 
attribution)
  http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6


[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote
[3] http://openjdk.java.net/jeps/304
[4] 
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html

From adinn at redhat.com  Thu Jun 22 07:55:01 2017
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 22 Jun 2017 08:55:01 +0100
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <8ef73e4d-8af3-cf0a-5698-40c2fe5ebc0a@redhat.com>

Vote: yes

On 22/06/17 08:51, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>
> Erik is a member of the Garbage Collection team in Oracle. He likes to
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves
> template metaprogramming, and is currently working on creating a GC
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface
> [3][4]
>
> Votes are due by 2017-07-06T09:50+02:00.
>
> Only current JDK 10 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].
>
> Stefan Karlsson
>
> Contributions:
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing
> attribution)
>  http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4]
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html
>

-- 
regards,


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


From stefan.karlsson at oracle.com  Thu Jun 22 07:57:10 2017
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 22 Jun 2017 09:57:10 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <dd7c6a87-d774-4988-6a32-b6b78a27f4d2@oracle.com>

Vote: yes

StefanK

On 2017-06-22 09:51, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
> 
> Erik is a member of the Garbage Collection team in Oracle. He likes to 
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves 
> template metaprogramming, and is currently working on creating a GC 
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface [3][4]
> 
> Votes are due by 2017-07-06T09:50+02:00.
> 
> Only current JDK 10 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].
> 
> Stefan Karlsson
> 
> Contributions:
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing 
> attribution)
>   http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
> 
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4] 
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html 
> 

From mikael.gerdin at oracle.com  Thu Jun 22 08:00:54 2017
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 22 Jun 2017 10:00:54 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <93eda32a-c1a9-a0f8-dd28-2ade3c538e94@oracle.com>

Vote: yes

/Mikael

On 2017-06-22 09:51, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
> 
> Erik is a member of the Garbage Collection team in Oracle. He likes to 
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves 
> template metaprogramming, and is currently working on creating a GC 
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface [3][4]
> 
> Votes are due by 2017-07-06T09:50+02:00.
> 
> Only current JDK 10 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].
> 
> Stefan Karlsson
> 
> Contributions:
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing 
> attribution)
>   http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
> 
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4] 
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html 
> 

From christoph.langer at sap.com  Thu Jun 22 08:27:16 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 22 Jun 2017 08:27:16 +0000
Subject: =?utf-8?B?UkU6IFN1YmplY3Q6IENGVjogTmV3IEpESyAxMCBDb21taXR0ZXI6IEVyaWsg?=
 =?utf-8?B?w5ZzdGVybHVuZA==?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <32e1287936494b918435eff3dc7e0ec9@sap.com>

Vote:yes

Best regards
Christoph

> -----Original Message-----
> From: jdk10-dev [mailto:jdk10-dev-bounces at openjdk.java.net] On Behalf
> Of Stefan Karlsson
> Sent: Donnerstag, 22. Juni 2017 09:51
> To: jdk10-dev at openjdk.java.net
> Subject: Subject: CFV: New JDK 10 Committer: Erik ?sterlund
> 
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
> 
> Erik is a member of the Garbage Collection team in Oracle. He likes to
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves
> template metaprogramming, and is currently working on creating a GC
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface [3][4]
> 
> Votes are due by 2017-07-06T09:50+02:00.
> 
> Only current JDK 10 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].
> 
> Stefan Karlsson
> 
> Contributions:
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing
> attribution)
>   http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
> 
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4]
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-
> April/019741.html

From volker.simonis at gmail.com  Thu Jun 22 08:30:45 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 22 Jun 2017 10:30:45 +0200
Subject: =?UTF-8?Q?Re=3A_Subject=3A_CFV=3A_New_JDK_10_Committer=3A_Erik_=C3=96sterl?=
 =?UTF-8?Q?und?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <CA+3eh11hwutxt7zgfAweh-oXs4m1xR+_vKJfa7-b33G5oxeuFQ@mail.gmail.com>

Vote: yes


On Thu, Jun 22, 2017 at 9:51 AM, Stefan Karlsson
<stefan.karlsson at oracle.com> wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>
> Erik is a member of the Garbage Collection team in Oracle. He likes to
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves template
> metaprogramming, and is currently working on creating a GC Barrier Interface
> as a part of JEP 304 - Garbage-Collector Interface [3][4]
>
> Votes are due by 2017-07-06T09:50+02:00.
>
> Only current JDK 10 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].
>
> Stefan Karlsson
>
> Contributions:
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing
> attribution)
>  http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4]
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html

From stefan.karlsson at oracle.com  Thu Jun 22 08:46:39 2017
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 22 Jun 2017 10:46:39 +0200
Subject: RFR: 818269: Remove gcTrace.hpp include from referenceProcessor.hpp
Message-ID: <30ae52d3-67da-bda4-b25c-e9ed0cb079ee@oracle.com>

Hi all,

Please review this trivial change to remove an include of gcTrace.hpp in 
referenceProcessor.hpp, and changes needed to get the code to compile 
after that.

http://cr.openjdk.java.net/~stefank/8182696/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8182696

I was prototyping ways to get more type safe time durations in HotSpot 
and found that whenever I changed my header file, that almost all 
HotSpot cpp files were recompiled. I tracked it down to come from the 
unused include of gcTrace.hpp in referenceProcessor.hpp.

We could probably also try to figure out why changes 
referenceProcessor.hpp triggers recompiles of the entire source code, 
but I'd like to leave that exercise for another day.

Thanks,
StefanK

From erik.helin at oracle.com  Thu Jun 22 08:46:50 2017
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 22 Jun 2017 10:46:50 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <13bbff13-cd33-a203-ac74-11fa642f9543@oracle.com>

Vote: yes

Thanks,
Erik

On 06/22/2017 09:51 AM, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
> 
> Erik is a member of the Garbage Collection team in Oracle. He likes to
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves
> template metaprogramming, and is currently working on creating a GC
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface [3][4]
> 
> Votes are due by 2017-07-06T09:50+02:00.
> 
> Only current JDK 10 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].
> 
> Stefan Karlsson
> 
> Contributions:
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing
> attribution)
>  http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
> 
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4]
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html
> 

From volker.simonis at gmail.com  Thu Jun 22 09:13:06 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 22 Jun 2017 11:13:06 +0200
Subject: CFV: New JDK 10 Committer: Sharath Ballal
In-Reply-To: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
References: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
Message-ID: <CA+3eh10ha9vxSU+JQRbV3VW33--MZ_6g_ZLpiogaoRHRecHmvQ@mail.gmail.com>

Vote: yes


On Thu, Jun 8, 2017 at 9:25 PM,  <jesper.wilhelmsson at oracle.com> wrote:
> I hereby nominate Sharath Ballal (sballal) to JDK 10 Committer.
>
> Sharath is part of the Monitoring and Management team and has contributed 17 changesets to JDK 10.
>
> Votes are due by June 22, 2017.
>
> Only current JDK 10 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,
> /Jesper
>
> [1] http://openjdk.java.net/census <http://openjdk.java.net/census>
> [2] http://openjdk.java.net/bylaws#lazy-consensus <http://openjdk.java.net/bylaws#lazy-consensus>
> [3] List of changes:
>
> (1) 6760477: Update SA to include stack traces in the heap dump
> http://hg.openjdk.java.net/jdk9/hs/./rev/8589c969babc
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/4056535f52f5
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c2084773d623
>
> (2) 8030750: SA: Alternate hashing not implemented
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378 <http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378>
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/f8b62710e186
>
> (3) 8168397: sun/tools/jhsdb/HeapDumpTest.java timesout on MacOS X on non images build
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/71457eaca096
>
> (4) 8160376: DebuggerException: Can't attach symbolicator to the process
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/7a5fa747419d
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ad402ced3a63
>
> (5) 8166657: Remove exports com.sun.tools.jdi to jdk.hotspot.agent
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/9d4a52d62493
>
> (6) 8164943: sun/tools/jhsdb/HeapDumpTest failed with Can't find library: /test/lib/share/classes
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/03e9322dc0a5
>
> (7) 8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout.
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/659f01da7ec0
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b50061da090e
>
> (8) 8160817: Add jsadebugd functionality to jhsdb
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/ecc9399771ac
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a2812668bf38
>
> (9) 8158050: Remove SA-JDI
> http://hg.openjdk.java.net/jdk9/hs/./rev/106f2f8b0ec9
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/02651d14d282
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2e21095f80c6
>
> (10) 8154144: Tests in com/sun/jdi fails intermittently with &quot;jdb input stream closed prematurely&quot;
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/73608cd4f89a
>
> (11) 8147456: Parsing of argument for -agentpath can write outside of allocated memory
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/b58e7a5634e8
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/7fbe91178ff9
>
> (12) 6659240: Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/e260a6ff2110
>
> (13) 7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1d8d01c86279
>
> (14) 7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3784c8f92b5b
>
> (15) 8165537: runtime/SharedArchiveFile/SASymbolTableTest.java fails with NullPointerException
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/776d89e316b6
>
> (16) 8165114: stale reference to hotspot test Test8028623.java
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c54ebf67ef13
>
> (17) 8163269: Testcase missed in push for JDK-8160817
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/37ce5a8e59cc
>

From volker.simonis at gmail.com  Thu Jun 22 09:14:26 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 22 Jun 2017 11:14:26 +0200
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
In-Reply-To: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
Message-ID: <CA+3eh12uRwyH5DPP1pumbaPZqxxhFRTmNyHu6hgC+9nKsQTV3A@mail.gmail.com>

Vote: yes


On Tue, Jun 20, 2017 at 10:39 PM, Se?n Coffey <sean.coffey at oracle.com> wrote:
> I hereby nominate Dmitry Markov (dmarkov) to JDK 10 Reviewer.
>
> Dmitry Markov is an engineer in the Oracle JDK sustaining team. He has
> contributed several changes to the JDK 10 Project [3].
>
> Votes are due by 22:00 GMT, 4th July 2017.
>
> Only current JDK 10 Reviewers [1] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [2].
>
> regards,
> Sean.
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3]
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/log?revcount=100&rev=%28keyword%28%22dmitry.markov%40oracle.com%22%29+or+author%28dmarkov%29%29

From nishit.jain at oracle.com  Thu Jun 22 09:25:40 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Thu, 22 Jun 2017 14:55:40 +0530
Subject: CFV: New JDK 10 Committer: Sharath Ballal
In-Reply-To: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
References: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
Message-ID: <9ea2d8f2-43b8-28fa-b7f0-fecc6ecdd928@oracle.com>

Vote: Yes

Regards,
Nishit Jain
On 09-06-2017 00:55, jesper.wilhelmsson at oracle.com wrote:
> I hereby nominate Sharath Ballal (sballal) to JDK 10 Committer.
>
> Sharath is part of the Monitoring and Management team and has contributed 17 changesets to JDK 10.
>
> Votes are due by June 22, 2017.
>
> Only current JDK 10 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,
> /Jesper
>
> [1] http://openjdk.java.net/census <http://openjdk.java.net/census>
> [2] http://openjdk.java.net/bylaws#lazy-consensus <http://openjdk.java.net/bylaws#lazy-consensus>
> [3] List of changes:
>
> (1) 6760477: Update SA to include stack traces in the heap dump
> http://hg.openjdk.java.net/jdk9/hs/./rev/8589c969babc
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/4056535f52f5
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c2084773d623
>
> (2) 8030750: SA: Alternate hashing not implemented
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378 <http://hg.openjdk.java.net/jdk9/hs/jdk/rev/051c8291f378>
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/f8b62710e186
>
> (3) 8168397: sun/tools/jhsdb/HeapDumpTest.java timesout on MacOS X on non images build
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/71457eaca096
>
> (4) 8160376: DebuggerException: Can't attach symbolicator to the process
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/7a5fa747419d
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ad402ced3a63
>
> (5) 8166657: Remove exports com.sun.tools.jdi to jdk.hotspot.agent
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/9d4a52d62493
>
> (6) 8164943: sun/tools/jhsdb/HeapDumpTest failed with Can't find library: /test/lib/share/classes
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/03e9322dc0a5
>
> (7) 8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout.
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/659f01da7ec0
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b50061da090e
>
> (8) 8160817: Add jsadebugd functionality to jhsdb
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/ecc9399771ac
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a2812668bf38
>
> (9) 8158050: Remove SA-JDI
> http://hg.openjdk.java.net/jdk9/hs/./rev/106f2f8b0ec9
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/02651d14d282
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2e21095f80c6
>
> (10) 8154144: Tests in com/sun/jdi fails intermittently with &quot;jdb input stream closed prematurely&quot;
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/73608cd4f89a
>
> (11) 8147456: Parsing of argument for -agentpath can write outside of allocated memory
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/b58e7a5634e8
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/7fbe91178ff9
>
> (12) 6659240: Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/e260a6ff2110
>
> (13) 7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1d8d01c86279
>
> (14) 7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3784c8f92b5b
>
> (15) 8165537: runtime/SharedArchiveFile/SASymbolTableTest.java fails with NullPointerException
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/776d89e316b6
>
> (16) 8165114: stale reference to hotspot test Test8028623.java
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c54ebf67ef13
>
> (17) 8163269: Testcase missed in push for JDK-8160817
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/37ce5a8e59cc
>


From thomas.schatzl at oracle.com  Thu Jun 22 09:26:16 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 22 Jun 2017 11:26:16 +0200
Subject: Subject: CFV: New JDK 10 Committer: Erik
 =?ISO-8859-1?Q?=D6sterlund?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <1498123576.2831.17.camel@oracle.com>

Vote: veto

Justification:

I looked through the changes and I do not believe they meet the
(informal?) goal of having eight significant commits.

Here is an overview of the contents of these changes. Feel free to
correct me.

trivial:
http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86 (add
volatile +?fix compilation)
http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746 (add
volatile +?fix compilation)
http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b (add
volatile +?fix compilation)
http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (remove
obsolete code)

borderline:
http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a?(fix
compilation)
http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0?(add
volatile + fix compilation, this one is a bit larger than the others)

significant:
http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd (build
changes)
http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6 (build changes)
http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419

I counted the build changes as significant because I feel unable to
judge them. That sums up to, including the ones I considered
borderline, as six significant commits.

I do know Erik, and I know that he is trustworthy to be committer, and
I know that he has lots of good changes about to be committed, but in
addition to this understanding some formal requirements must be met (or
at least very close to) at the time of nomination.

This is, in my view not the case here at this time.

We have in the past also been pretty strict about getting the Committer
role, and I think it would devalue every others' hard work to attain
that goal. I also, just a few months ago, privately looked through
commits of somebody else as trustworthy in the same situation, and I
asked him to come back after another two commits. I would like to ask
the same in this case.

Thanks,
? Thomas


On Thu, 2017-06-22 at 09:51 +0200, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
> 
> Erik is a member of the Garbage Collection team in Oracle. He likes
> to?
> rewrite??and fix bugs in the OrderAccess and Atomics layers, loves?
> template metaprogramming, and is currently working on creating a GC?
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface
> [3][4]
> 
> Votes are due by 2017-07-06T09:50+02:00.
> 
> Only current JDK 10 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].
> 
> Stefan Karlsson
> 
> Contributions:
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc
> (missing?
> attribution)
> ? http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
> 
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4]?
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/0197
> 41.html

From tobias.hartmann at oracle.com  Thu Jun 22 09:27:43 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 22 Jun 2017 11:27:43 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <cb6dc3ae-af0c-ad3b-0728-6167fc22caf4@oracle.com>

Vote: yes

Best regards,
Tobias

On 22.06.2017 09:51, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
> 
> Erik is a member of the Garbage Collection team in Oracle. He likes to rewrite  and fix bugs in the OrderAccess and Atomics layers, loves template metaprogramming, and is currently working on creating a GC Barrier Interface as a part of JEP 304 - Garbage-Collector Interface [3][4]
> 
> Votes are due by 2017-07-06T09:50+02:00.
> 
> Only current JDK 10 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].
> 
> Stefan Karlsson
> 
> Contributions:
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing attribution)
>  http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
> 
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html

From erik.joelsson at oracle.com  Thu Jun 22 09:37:06 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 22 Jun 2017 11:37:06 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <54bdf775-ae60-32ff-3187-b08e9ea8067f@oracle.com>

Vote: yes

/Erik


On 2017-06-22 09:51, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>
> Erik is a member of the Garbage Collection team in Oracle. He likes to 
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves 
> template metaprogramming, and is currently working on creating a GC 
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface 
> [3][4]
>
> Votes are due by 2017-07-06T09:50+02:00.
>
> Only current JDK 10 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].
>
> Stefan Karlsson
>
> Contributions:
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing 
> attribution)
>  http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4] 
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html


From dalibor.topic at oracle.com  Thu Jun 22 10:24:47 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Thu, 22 Jun 2017 12:24:47 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <2577e258-4164-e71c-b2c7-96c034837f0b@oracle.com>

Vote: Yes.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From sgehwolf at redhat.com  Thu Jun 22 10:33:15 2017
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 22 Jun 2017 12:33:15 +0200
Subject: Subject: CFV: New JDK 10 Committer: Erik
 =?ISO-8859-1?Q?=D6sterlund?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <1498127595.3921.11.camel@redhat.com>

Vote: yes.

On Thu, 2017-06-22 at 09:51 +0200, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
> 
> Erik is a member of the Garbage Collection team in Oracle. He likes to?
> rewrite??and fix bugs in the OrderAccess and Atomics layers, loves?
> template metaprogramming, and is currently working on creating a GC?
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface [3][4]
> 
> Votes are due by 2017-07-06T09:50+02:00.
> 
> Only current JDK 10 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].
> 
> Stefan Karlsson
> 
> Contributions:
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
> ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
> > ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing?
> attribution)
> ? http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
> 
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4]?
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html


From claes.redestad at oracle.com  Thu Jun 22 12:04:25 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 22 Jun 2017 14:04:25 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <1498123576.2831.17.camel@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
Message-ID: <4ea34c57-378b-402c-3d1e-eeade3cb8e65@oracle.com>



On 2017-06-22 11:26, Thomas Schatzl wrote:
> Vote: veto
>

Thanks for sending a clear message that there's no place for pragmatism 
in our organization! /s

/Claes

From serguei.spitsyn at oracle.com  Thu Jun 22 12:06:10 2017
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 22 Jun 2017 05:06:10 -0700
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <e92f5561-26e2-3d4a-7ed3-37eb4049e71c@oracle.com>

Vote: yes

From claes.redestad at oracle.com  Thu Jun 22 12:06:57 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 22 Jun 2017 14:06:57 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <0100a293-a37b-5446-834b-bc23b3c237d9@oracle.com>

Vote: yes

/Claes

On 2017-06-22 09:51, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>
> Erik is a member of the Garbage Collection team in Oracle. He likes to 
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves 
> template metaprogramming, and is currently working on creating a GC 
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface 
> [3][4]
>
> Votes are due by 2017-07-06T09:50+02:00.
>
> Only current JDK 10 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].
>
> Stefan Karlsson
>
> Contributions:
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing 
> attribution)
>  http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4] 
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html


From aph at redhat.com  Thu Jun 22 12:09:23 2017
From: aph at redhat.com (Andrew Haley)
Date: Thu, 22 Jun 2017 13:09:23 +0100
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <e92f5561-26e2-3d4a-7ed3-37eb4049e71c@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <e92f5561-26e2-3d4a-7ed3-37eb4049e71c@oracle.com>
Message-ID: <cd7af969-676c-dd27-8ee8-8a301f39f1a3@redhat.com>

Vote: yes

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

From vladimir.x.ivanov at oracle.com  Thu Jun 22 12:11:17 2017
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 22 Jun 2017 15:11:17 +0300
Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlund?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <b36d9dc4-b417-1095-926a-b3ffaf9a48d9@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

On 6/22/17 10:51 AM, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.


From jesper.wilhelmsson at oracle.com  Thu Jun 22 12:11:22 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 22 Jun 2017 14:11:22 +0200
Subject: =?utf-8?Q?Re=3A_Subject=3A_CFV=3A_New_JDK_10_Committer=3A_Erik_?=
 =?utf-8?Q?=C3=96sterlund?=
In-Reply-To: <1498123576.2831.17.camel@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
Message-ID: <08245428-292B-447B-B23B-5BA9C7E03AE9@oracle.com>

Vote: veto

As much as I would like to see Erik becoming a Committer asap I must agree with Thomas that this vote was slightly premature considering that we have rejected several similar nominations in the past.
/Jesper


> On 22 Jun 2017, at 11:26, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Vote: veto
> 
> Justification:
> 
> I looked through the changes and I do not believe they meet the
> (informal?) goal of having eight significant commits.
> 
> Here is an overview of the contents of these changes. Feel free to
> correct me.
> 
> trivial:
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86 (add
> volatile + fix compilation)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746 (add
> volatile + fix compilation)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b (add
> volatile + fix compilation)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (remove
> obsolete code)
> 
> borderline:
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a (fix
> compilation)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0 (add
> volatile + fix compilation, this one is a bit larger than the others)
> 
> significant:
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd (build
> changes)
> http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6 (build changes)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
> 
> I counted the build changes as significant because I feel unable to
> judge them. That sums up to, including the ones I considered
> borderline, as six significant commits.
> 
> I do know Erik, and I know that he is trustworthy to be committer, and
> I know that he has lots of good changes about to be committed, but in
> addition to this understanding some formal requirements must be met (or
> at least very close to) at the time of nomination.
> 
> This is, in my view not the case here at this time.
> 
> We have in the past also been pretty strict about getting the Committer
> role, and I think it would devalue every others' hard work to attain
> that goal. I also, just a few months ago, privately looked through
> commits of somebody else as trustworthy in the same situation, and I
> asked him to come back after another two commits. I would like to ask
> the same in this case.
> 
> Thanks,
>   Thomas
> 
> 
> On Thu, 2017-06-22 at 09:51 +0200, Stefan Karlsson wrote:
>> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>> 
>> Erik is a member of the Garbage Collection team in Oracle. He likes
>> to 
>> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves 
>> template metaprogramming, and is currently working on creating a GC 
>> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface
>> [3][4]
>> 
>> Votes are due by 2017-07-06T09:50+02:00.
>> 
>> Only current JDK 10 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].
>> 
>> Stefan Karlsson
>> 
>> Contributions:
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc
>> (missing 
>> attribution)
>>   http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>> 
>> 
>> [1] http://openjdk.java.net/census
>> [2] http://openjdk.java.net/projects/#committer-vote
>> [3] http://openjdk.java.net/jeps/304
>> [4] 
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/0197
>> 41.html


From vladimir.x.ivanov at oracle.com  Thu Jun 22 12:11:58 2017
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 22 Jun 2017 15:11:58 +0300
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
In-Reply-To: <CA+3eh12uRwyH5DPP1pumbaPZqxxhFRTmNyHu6hgC+9nKsQTV3A@mail.gmail.com>
References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
 <CA+3eh12uRwyH5DPP1pumbaPZqxxhFRTmNyHu6hgC+9nKsQTV3A@mail.gmail.com>
Message-ID: <52e95f69-34ab-edee-ac0a-58969afb7857@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

> On Tue, Jun 20, 2017 at 10:39 PM, Se?n Coffey <sean.coffey at oracle.com> wrote:
>> I hereby nominate Dmitry Markov (dmarkov) to JDK 10 Reviewer.

From vladimir.x.ivanov at oracle.com  Thu Jun 22 12:12:25 2017
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 22 Jun 2017 15:12:25 +0300
Subject: CFV: New JDK 10 Committer: Sharath Ballal
In-Reply-To: <CA+3eh10ha9vxSU+JQRbV3VW33--MZ_6g_ZLpiogaoRHRecHmvQ@mail.gmail.com>
References: <B1EFC796-BB1B-4200-99E2-3AF38B9B8F8B@oracle.com>
 <CA+3eh10ha9vxSU+JQRbV3VW33--MZ_6g_ZLpiogaoRHRecHmvQ@mail.gmail.com>
Message-ID: <ee6a329a-4bdc-751f-6c1e-b3f6d2b1a80a@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

> On Thu, Jun 8, 2017 at 9:25 PM,  <jesper.wilhelmsson at oracle.com> wrote:
>> I hereby nominate Sharath Ballal (sballal) to JDK 10 Committer.

From thomas.schatzl at oracle.com  Thu Jun 22 12:13:06 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 22 Jun 2017 14:13:06 +0200
Subject: Subject: CFV: New JDK 10 Committer: Erik
 =?ISO-8859-1?Q?=D6sterlund?=
In-Reply-To: <4ea34c57-378b-402c-3d1e-eeade3cb8e65@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
 <4ea34c57-378b-402c-3d1e-eeade3cb8e65@oracle.com>
Message-ID: <1498133586.2831.96.camel@oracle.com>

Hi,

On Thu, 2017-06-22 at 14:04 +0200, Claes Redestad wrote:
>?
> On 2017-06-22 11:26, Thomas Schatzl wrote:
> >?
> > Vote: veto
> >?
> Thanks for sending a clear message that there's no place for
> pragmatism in our organization! /s

? these are OpenJDK rules, not company rules afaik.

Let's change the rules then.

Thanks,
? Thomas


From claes.redestad at oracle.com  Thu Jun 22 12:24:32 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 22 Jun 2017 14:24:32 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <1498133586.2831.96.camel@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
 <4ea34c57-378b-402c-3d1e-eeade3cb8e65@oracle.com>
 <1498133586.2831.96.camel@oracle.com>
Message-ID: <4f411e7e-b608-f35d-bb87-70ebe4cd3128@oracle.com>

There are no strict definition of what constitutes significant
change, leaving it open for interpretation.  There are plenty of
Committers who've been happily accepted after doing a handful
of test fixes, but seemingly not everyone is measured with the
same ruler.

No rule change needed, but a social shift is long overdue.

/Claes

On 2017-06-22 14:13, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2017-06-22 at 14:04 +0200, Claes Redestad wrote:
>>   
>> On 2017-06-22 11:26, Thomas Schatzl wrote:
>>>   
>>> Vote: veto
>>>   
>> Thanks for sending a clear message that there's no place for
>> pragmatism in our organization! /s
>    these are OpenJDK rules, not company rules afaik.
>
> Let's change the rules then.
>
> Thanks,
>    Thomas
>


From coleen.phillimore at oracle.com  Thu Jun 22 12:44:29 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 22 Jun 2017 08:44:29 -0400
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <08245428-292B-447B-B23B-5BA9C7E03AE9@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
 <08245428-292B-447B-B23B-5BA9C7E03AE9@oracle.com>
Message-ID: <ed4ec588-36a5-78b4-c6f5-e1f03687e165@oracle.com>

Vote: no

I agree with Thomas and Jesper.  That and last week I did a commit_count 
for Erik and was really disappointed that there weren't enough commits, 
so was surprised to see this nomination.  Going through the open review 
process 8 times is part of the process.

I think the process says 8 significant commits but if 7 are minor and 
one is super-significant, I believe in the average that's enough.  Erik 
has some very significant commits coming.   We should wait.

Coleen

On 6/22/17 8:11 AM, jesper.wilhelmsson at oracle.com wrote:
> Vote: veto
>
> As much as I would like to see Erik becoming a Committer asap I must agree with Thomas that this vote was slightly premature considering that we have rejected several similar nominations in the past.
> /Jesper
>
>
>> On 22 Jun 2017, at 11:26, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>>
>> Vote: veto
>>
>> Justification:
>>
>> I looked through the changes and I do not believe they meet the
>> (informal?) goal of having eight significant commits.
>>
>> Here is an overview of the contents of these changes. Feel free to
>> correct me.
>>
>> trivial:
>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86 (add
>> volatile + fix compilation)
>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746 (add
>> volatile + fix compilation)
>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b (add
>> volatile + fix compilation)
>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (remove
>> obsolete code)
>>
>> borderline:
>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a (fix
>> compilation)
>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0 (add
>> volatile + fix compilation, this one is a bit larger than the others)
>>
>> significant:
>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd (build
>> changes)
>> http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6 (build changes)
>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>>
>> I counted the build changes as significant because I feel unable to
>> judge them. That sums up to, including the ones I considered
>> borderline, as six significant commits.
>>
>> I do know Erik, and I know that he is trustworthy to be committer, and
>> I know that he has lots of good changes about to be committed, but in
>> addition to this understanding some formal requirements must be met (or
>> at least very close to) at the time of nomination.
>>
>> This is, in my view not the case here at this time.
>>
>> We have in the past also been pretty strict about getting the Committer
>> role, and I think it would devalue every others' hard work to attain
>> that goal. I also, just a few months ago, privately looked through
>> commits of somebody else as trustworthy in the same situation, and I
>> asked him to come back after another two commits. I would like to ask
>> the same in this case.
>>
>> Thanks,
>>    Thomas
>>
>>
>> On Thu, 2017-06-22 at 09:51 +0200, Stefan Karlsson wrote:
>>> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>>>
>>> Erik is a member of the Garbage Collection team in Oracle. He likes
>>> to
>>> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves
>>> template metaprogramming, and is currently working on creating a GC
>>> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface
>>> [3][4]
>>>
>>> Votes are due by 2017-07-06T09:50+02:00.
>>>
>>> Only current JDK 10 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].
>>>
>>> Stefan Karlsson
>>>
>>> Contributions:
>>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc
>>> (missing
>>> attribution)
>>>    http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>>>
>>>
>>> [1] http://openjdk.java.net/census
>>> [2] http://openjdk.java.net/projects/#committer-vote
>>> [3] http://openjdk.java.net/jeps/304
>>> [4]
>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/0197
>>> 41.html


From jesper.wilhelmsson at oracle.com  Thu Jun 22 12:45:54 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 22 Jun 2017 14:45:54 +0200
Subject: =?utf-8?Q?Re=3A_Subject=3A_CFV=3A_New_JDK_10_Committer=3A_Erik_?=
 =?utf-8?Q?=C3=96sterlund?=
In-Reply-To: <4f411e7e-b608-f35d-bb87-70ebe4cd3128@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
 <4ea34c57-378b-402c-3d1e-eeade3cb8e65@oracle.com>
 <1498133586.2831.96.camel@oracle.com>
 <4f411e7e-b608-f35d-bb87-70ebe4cd3128@oracle.com>
Message-ID: <0076BDE6-5F67-4DC6-8CE7-15D73943434F@oracle.com>


> On 22 Jun 2017, at 14:24, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> There are no strict definition of what constitutes significant
> change, leaving it open for interpretation.  There are plenty of
> Committers who've been happily accepted after doing a handful
> of test fixes, but seemingly not everyone is measured with the
> same ruler.

I think we have been fairly consistent in our definition of a significant fix even though I can't say that I have reviewed every single CFV.

A test fix can be as complex as any other fix. I think you are wrong in categorising these as trivial without any deeper reflexion. We have several tests that have a very complex nature and fixing races or weird memory leaks etc in these is just as significant as fixing VM bugs.

> No rule change needed, but a social shift is long overdue.

I'm not sure what you mean by social shift. Do you mean that we should lower the bar for what a significant change is? Or do you mean that we should let our friends slip by because we know that they are good developers?

I agree that the rules could be changed to make it easier to become a Committer. Personally I would like to merge Author and Committer and say that anyone that has proven an interest in contributing to the OpenJDK by submitting a few patches could become what we today call Committer. But the rules are in place as is and we should follow them in the same way as we would if the vote was about someone that we didn't know.

/Jesper

> /Claes
> 
> On 2017-06-22 14:13, Thomas Schatzl wrote:
>> Hi,
>> 
>> On Thu, 2017-06-22 at 14:04 +0200, Claes Redestad wrote:
>>>  On 2017-06-22 11:26, Thomas Schatzl wrote:
>>>>  Vote: veto
>>>>  
>>> Thanks for sending a clear message that there's no place for
>>> pragmatism in our organization! /s
>>   these are OpenJDK rules, not company rules afaik.
>> 
>> Let's change the rules then.
>> 
>> Thanks,
>>   Thomas
>> 
> 


From aph at redhat.com  Thu Jun 22 12:46:07 2017
From: aph at redhat.com (Andrew Haley)
Date: Thu, 22 Jun 2017 13:46:07 +0100
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <1498123576.2831.17.camel@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
Message-ID: <27f09bee-3d85-5d9b-4dbe-11260bbe5bea@redhat.com>

On 22/06/17 10:26, Thomas Schatzl wrote:

> I do know Erik, and I know that he is trustworthy to be committer, and
> I know that he has lots of good changes about to be committed, but in
> addition to this understanding some formal requirements must be met (or
> at least very close to) at the time of nomination.
> 
> This is, in my view not the case here at this time.
> 
> We have in the past also been pretty strict about getting the Committer
> role, and I think it would devalue every others' hard work to attain
> that goal. I also, just a few months ago, privately looked through
> commits of somebody else as trustworthy in the same situation, and I
> asked him to come back after another two commits. I would like to ask
> the same in this case.

So, we know that Erik is entirely suitable for this role, and you do
not disagree, but you insist on following the rules because they are
the rules and they've been strictly followed in the past.

I have to wonder whether the rules are there to serve us or we are here
to serve the rules.

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

From roman at kennke.org  Thu Jun 22 12:49:20 2017
From: roman at kennke.org (Roman Kennke)
Date: Thu, 22 Jun 2017 14:49:20 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <4f411e7e-b608-f35d-bb87-70ebe4cd3128@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
 <4ea34c57-378b-402c-3d1e-eeade3cb8e65@oracle.com>
 <1498133586.2831.96.camel@oracle.com>
 <4f411e7e-b608-f35d-bb87-70ebe4cd3128@oracle.com>
Message-ID: <b007b0dd-84bb-d27f-d27c-69f9e02ee74b@kennke.org>

As far as I understand it, the rules have been designed to give some
confidence that the author is expected to take some responsibilty to the
stuff he's doing plus provide some basic confidence that the author is
competent to handle OpenJDK dev work.

I don't really have an overview of Erik's track record. I do work with
him on GC interface stuff though, and I am currently looking at some of
his work that is not in OpenJDK yet, which is a pretty large change, and
all I can say is that this gives me the confidences I have mentioned above.

I'm all for less bureaucrazy and more pragmatism and am hereby voting: yes

But I don't see it as a bad idea to wait until his above mentioned big
GC interface stuff is in JDK10 if that gives other people involved more
confidence.


Cheers, Roman

> There are no strict definition of what constitutes significant
> change, leaving it open for interpretation.  There are plenty of
> Committers who've been happily accepted after doing a handful
> of test fixes, but seemingly not everyone is measured with the
> same ruler.
>
> No rule change needed, but a social shift is long overdue.
>
> /Claes
>
> On 2017-06-22 14:13, Thomas Schatzl wrote:
>> Hi,
>>
>> On Thu, 2017-06-22 at 14:04 +0200, Claes Redestad wrote:
>>>   On 2017-06-22 11:26, Thomas Schatzl wrote:
>>>>   Vote: veto
>>>>   
>>> Thanks for sending a clear message that there's no place for
>>> pragmatism in our organization! /s
>>    these are OpenJDK rules, not company rules afaik.
>>
>> Let's change the rules then.
>>
>> Thanks,
>>    Thomas
>>
>
>


From claes.redestad at oracle.com  Thu Jun 22 13:36:09 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 22 Jun 2017 15:36:09 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <0076BDE6-5F67-4DC6-8CE7-15D73943434F@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
 <4ea34c57-378b-402c-3d1e-eeade3cb8e65@oracle.com>
 <1498133586.2831.96.camel@oracle.com>
 <4f411e7e-b608-f35d-bb87-70ebe4cd3128@oracle.com>
 <0076BDE6-5F67-4DC6-8CE7-15D73943434F@oracle.com>
Message-ID: <ee2fe4b1-860d-ec94-be17-358af604b73b@oracle.com>



On 2017-06-22 14:45, jesper.wilhelmsson at oracle.com wrote:
>> No rule change needed, but a social shift is long overdue.
> I'm not sure what you mean by social shift. Do you mean that we should lower the bar for what a significant change is? Or do you mean that we should let our friends slip by because we know that they are good developers?

I think your bar for what's considered a significant change is generally 
way too high, yes, especially for a Committer rule.

Does it fix a failing test, a failing build, or adjust the behavior of 
the product in some measurable way? -> Significant. Shouldn't matter if 
it's just adding a volatile qualifier.

Fixing typos, adding a test to Problem list -> Not significant

> I agree that the rules could be changed to make it easier to become a Committer. Personally I would like to merge Author and Committer and say that anyone that has proven an interest in contributing to the OpenJDK by submitting a few patches could become what we today call Committer. But the rules are in place as is and we should follow them in the same way as we would if the vote was about someone that we didn't know.

I agree that the rules are to be followed, I just don't agree with the 
justification that any of the changes Erik has done so far are 
insignificant and should motivate a veto.

I fully agree that the rules should be changed, mostly to take out the 
wording of "significant" from the rules (instead explicitly enumerate 
what types of changes are not to be counted), but merging the Author and 
Committer roles would also be welcome.

/Claes

From roman at kennke.org  Thu Jun 22 14:01:30 2017
From: roman at kennke.org (Roman Kennke)
Date: Thu, 22 Jun 2017 16:01:30 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <ee2fe4b1-860d-ec94-be17-358af604b73b@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
 <4ea34c57-378b-402c-3d1e-eeade3cb8e65@oracle.com>
 <1498133586.2831.96.camel@oracle.com>
 <4f411e7e-b608-f35d-bb87-70ebe4cd3128@oracle.com>
 <0076BDE6-5F67-4DC6-8CE7-15D73943434F@oracle.com>
 <ee2fe4b1-860d-ec94-be17-358af604b73b@oracle.com>
Message-ID: <5df88cf0-00bc-1f5c-c455-66078e217d71@kennke.org>

Am 22.06.2017 um 15:36 schrieb Claes Redestad:
>
>
> On 2017-06-22 14:45, jesper.wilhelmsson at oracle.com wrote:
>>> No rule change needed, but a social shift is long overdue.
>> I'm not sure what you mean by social shift. Do you mean that we
>> should lower the bar for what a significant change is? Or do you mean
>> that we should let our friends slip by because we know that they are
>> good developers?
>
> I think your bar for what's considered a significant change is
> generally way too high, yes, especially for a Committer rule.

I agree with that.
Another way to look at it is to ask 'have we ever run into problems
because the barrier of entry is too low?' I'm thinking the sort of
problem where some random guy commits a fix or two, then disappears and
leaves others with a trail of bugs. I am not aware that something like
this ever happened to OpenJDK. On the other hand: 'did we ever get
problems because the barrier to entry is too high?' Probably. We it not
for the army of paid developers, OpenJDK would most likely look pretty
poor as an open source project. And I *can* remember a bunch of
occasions were competent volunteers with great patches almost fell to
the wayside because of all the bureaucrazy involved.
> I fully agree that the rules should be changed, mostly to take out the
> wording of "significant" from the rules (instead explicitly enumerate
> what types of changes are not to be counted), but merging the Author
> and Committer roles would also be welcome.
It would be very useful to spell out the purpose of the rules. What do
we want to achieve by having those rules? This would probably help to
not get caught up and waste time in arguments about strictly following
the rules, but do something useful for OpenJDK instead.

Roman


From stefan.karlsson at oracle.com  Thu Jun 22 08:59:32 2017
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 22 Jun 2017 10:59:32 +0200
Subject: RFR: 818269: Remove gcTrace.hpp include from
 referenceProcessor.hpp
In-Reply-To: <30ae52d3-67da-bda4-b25c-e9ed0cb079ee@oracle.com>
References: <30ae52d3-67da-bda4-b25c-e9ed0cb079ee@oracle.com>
Message-ID: <cb7f2700-b9bc-ad3e-e93e-6e07759e46bf@oracle.com>

This mail was supposed to go to hotspot-gc-dev (To:ed) not to jdk10-dev 
(BCC:ed).

Thanks,
StefanK

On 2017-06-22 10:46, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this trivial change to remove an include of gcTrace.hpp in 
> referenceProcessor.hpp, and changes needed to get the code to compile 
> after that.
> 
> http://cr.openjdk.java.net/~stefank/8182696/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8182696
> 
> I was prototyping ways to get more type safe time durations in HotSpot 
> and found that whenever I changed my header file, that almost all 
> HotSpot cpp files were recompiled. I tracked it down to come from the 
> unused include of gcTrace.hpp in referenceProcessor.hpp.
> 
> We could probably also try to figure out why changes 
> referenceProcessor.hpp triggers recompiles of the entire source code, 
> but I'd like to leave that exercise for another day.
> 
> Thanks,
> StefanK

From vladimir.kozlov at oracle.com  Thu Jun 22 16:19:24 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 22 Jun 2017 09:19:24 -0700
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <93442431-697c-bb7e-e3cd-b60a9f4d46b2@oracle.com>

Vote: yes

On 6/22/17 12:51 AM, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
> 
> Erik is a member of the Garbage Collection team in Oracle. He likes to rewrite  and fix bugs in the OrderAccess and 
> Atomics layers, loves template metaprogramming, and is currently working on creating a GC Barrier Interface as a part of 
> JEP 304 - Garbage-Collector Interface [3][4]
> 
> Votes are due by 2017-07-06T09:50+02:00.
> 
> Only current JDK 10 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].
> 
> Stefan Karlsson
> 
> Contributions:
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing attribution)
>   http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
> 
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html

From neugens.limasoftware at gmail.com  Thu Jun 22 16:36:21 2017
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 22 Jun 2017 18:36:21 +0200
Subject: =?UTF-8?Q?Re=3A_Subject=3A_CFV=3A_New_JDK_10_Committer=3A_Erik_=C3=96sterl?=
 =?UTF-8?Q?und?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <CAGUMyaSwawFaMGPwQR+L=mm4Y=BLsYf0tL42pAnvxnXvvWFqgA@mail.gmail.com>

Vote: Yes

To put that on the record, I agree with Roman and Andrew Haley and the
Veto was a surprise, I can understand a No vote, but Veto is rather
strong, and doesn't really seem to serve the OpenJDK community well,
particularly considering that all that was asked was to have a few
more contribution coming in and we all know this is about to happen
anyway. Perhaps the proposal was premature, but considering the amount
of changes necessary for the GC interface to happen, I considered it
expected and reasonable.

Cheers,
Mario

2017-06-22 9:51 GMT+02:00 Stefan Karlsson <stefan.karlsson at oracle.com>:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>
> Erik is a member of the Garbage Collection team in Oracle. He likes to
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves template
> metaprogramming, and is currently working on creating a GC Barrier Interface
> as a part of JEP 304 - Garbage-Collector Interface [3][4]
>
> Votes are due by 2017-07-06T09:50+02:00.
>
> Only current JDK 10 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].
>
> Stefan Karlsson
>
> Contributions:
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing
> attribution)
>  http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4]
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html



-- 
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 daniel.daugherty at oracle.com  Thu Jun 22 16:44:41 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 22 Jun 2017 10:44:41 -0600
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <CAGUMyaSwawFaMGPwQR+L=mm4Y=BLsYf0tL42pAnvxnXvvWFqgA@mail.gmail.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <CAGUMyaSwawFaMGPwQR+L=mm4Y=BLsYf0tL42pAnvxnXvvWFqgA@mail.gmail.com>
Message-ID: <b5c99c4a-041c-74c4-b751-e2434f50020e@oracle.com>

Point of order:

http://openjdk.java.net/projects/#committer-vote

The valid votes are "Yes", "Veto" or "Abstain" for this kind of vote.
There is no specification for a "No" vote.

Dan


On 6/22/17 10:36 AM, Mario Torre wrote:
> Vote: Yes
>
> To put that on the record, I agree with Roman and Andrew Haley and the
> Veto was a surprise, I can understand a No vote, but Veto is rather
> strong, and doesn't really seem to serve the OpenJDK community well,
> particularly considering that all that was asked was to have a few
> more contribution coming in and we all know this is about to happen
> anyway. Perhaps the proposal was premature, but considering the amount
> of changes necessary for the GC interface to happen, I considered it
> expected and reasonable.
>
> Cheers,
> Mario
>
> 2017-06-22 9:51 GMT+02:00 Stefan Karlsson <stefan.karlsson at oracle.com>:
>> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>>
>> Erik is a member of the Garbage Collection team in Oracle. He likes to
>> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves template
>> metaprogramming, and is currently working on creating a GC Barrier Interface
>> as a part of JEP 304 - Garbage-Collector Interface [3][4]
>>
>> Votes are due by 2017-07-06T09:50+02:00.
>>
>> Only current JDK 10 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].
>>
>> Stefan Karlsson
>>
>> Contributions:
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>>   http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing
>> attribution)
>>   http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>>
>>
>> [1] http://openjdk.java.net/census
>> [2] http://openjdk.java.net/projects/#committer-vote
>> [3] http://openjdk.java.net/jeps/304
>> [4]
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html
>
>


From neugens.limasoftware at gmail.com  Thu Jun 22 16:56:38 2017
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 22 Jun 2017 18:56:38 +0200
Subject: =?UTF-8?Q?Re=3A_Subject=3A_CFV=3A_New_JDK_10_Committer=3A_Erik_=C3=96sterl?=
 =?UTF-8?Q?und?=
In-Reply-To: <b5c99c4a-041c-74c4-b751-e2434f50020e@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <CAGUMyaSwawFaMGPwQR+L=mm4Y=BLsYf0tL42pAnvxnXvvWFqgA@mail.gmail.com>
 <b5c99c4a-041c-74c4-b751-e2434f50020e@oracle.com>
Message-ID: <CAGUMyaQqA4b3ZvbONiQJn86KXds2MmhpmjJRGo=2=Emsc4qhnQ@mail.gmail.com>

2017-06-22 18:44 GMT+02:00 Daniel D. Daugherty <daniel.daugherty at oracle.com>:
> Point of order:
>
> http://openjdk.java.net/projects/#committer-vote
>
> The valid votes are "Yes", "Veto" or "Abstain" for this kind of vote.
> There is no specification for a "No" vote.

You are totally right, I was convinced we had a No vote option too,
but of course that's not the case. Nevertheless, what has been said is still
valid, the two veto seem to be cast just as a matter of principle, and
I don't see a strong argument supporting either one.

Cheers,
Mario
-- 
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 Alan.Bateman at oracle.com  Thu Jun 22 17:00:32 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 22 Jun 2017 18:00:32 +0100
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <CAGUMyaSwawFaMGPwQR+L=mm4Y=BLsYf0tL42pAnvxnXvvWFqgA@mail.gmail.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <CAGUMyaSwawFaMGPwQR+L=mm4Y=BLsYf0tL42pAnvxnXvvWFqgA@mail.gmail.com>
Message-ID: <30a133e7-abd7-c76d-813b-8aed589f398f@oracle.com>

On 22/06/2017 17:36, Mario Torre wrote:
> Vote: Yes
>
> To put that on the record, I agree with Roman and Andrew Haley and the
> Veto was a surprise, I can understand a No vote, but Veto is rather
> strong,
I don't think "No" is an option as it's Lazy Consensus with possible 
votes being Yes, Veto, or Abstain. The vetos need to be withdraw or 
re-casted to Yes or Abstain for this vote to carry.

Some of the comments have pointed out that Erik has more significant 
changes in the works and maybe it would be better to re-nominate in a 
few weeks once they are in jdk10/jdk10. More significant changes means a 
larger track record to point to and makes it much easier to vote.

-Alan.

From mark.reinhold at oracle.com  Thu Jun 22 17:02:41 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 22 Jun 2017 19:02:41 +0200
Subject: Subject: CFV: New JDK 10 Committer: Erik =?utf-8?Q?=C3=96ster?=
 =?utf-8?Q?lund?=
In-Reply-To: <1498123576.2831.17.camel@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
Message-ID: <20170622190241.436347510@eggemoggin.niobe.net>

2017/6/22 11:26:16 +0200, thomas.schatzl at oracle.com:
> Vote: veto
> 
> Justification:
> 
> I looked through the changes and I do not believe they meet the
> (informal?) goal of having eight significant commits.
> 
> ...
> 
> I do know Erik, and I know that he is trustworthy to be committer, and
> I know that he has lots of good changes about to be committed, but in
> addition to this understanding some formal requirements must be met (or
> at least very close to) at the time of nomination.
> 
> This is, in my view not the case here at this time.

The "eight significant contributions" threshold is not a hard-and-fast
rule -- it's just a rough guideline, as stated [1].

The key question to answer when someone is nominated to a Committer role
is: Do you trust them to use their push access in a responsible fashion?

If someone has contributed eight significant changesets then chances are
pretty good that they've learned how things work, what to watch out for,
and when to ask for help, and so they can be trusted with push access.

If someone hasn't yet contributed eight significant changesets then that
doesn't mean that they're not qualified to be a Committer.  If they've
demonstrated in other ways that they have the requisite knowledge,
skills, and judgement then a smaller number of contributions should not
be a barrier.

Speaking for myself, I've seen enough of Erik's work that I think he can
be trusted, so I'm going to vote "yes".

- Mark


[1] http://openjdk.java.net/projects/#project-committer

From mark.reinhold at oracle.com  Thu Jun 22 17:03:00 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 22 Jun 2017 19:03:00 +0200
Subject: Subject: CFV: New JDK 10 Committer: Erik =?utf-8?Q?=C3=96ster?=
 =?utf-8?Q?lund?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <20170622190300.355560948@eggemoggin.niobe.net>

Vote: yes

- Mark

From sangheon.kim at oracle.com  Thu Jun 22 17:12:43 2017
From: sangheon.kim at oracle.com (sangheon)
Date: Thu, 22 Jun 2017 10:12:43 -0700
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <c3c7edf3-3614-f390-e43f-452478db0f2d@oracle.com>

Vote: Yes

Thanks,
Sangheon


On 06/22/2017 12:51 AM, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>
> Erik is a member of the Garbage Collection team in Oracle. He likes to 
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves 
> template metaprogramming, and is currently working on creating a GC 
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface 
> [3][4]
>
> Votes are due by 2017-07-06T09:50+02:00.
>
> Only current JDK 10 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].
>
> Stefan Karlsson
>
> Contributions:
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing 
> attribution)
>  http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4] 
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html


From coleen.phillimore at oracle.com  Thu Jun 22 17:14:44 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 22 Jun 2017 13:14:44 -0400
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <ed4ec588-36a5-78b4-c6f5-e1f03687e165@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
 <08245428-292B-447B-B23B-5BA9C7E03AE9@oracle.com>
 <ed4ec588-36a5-78b4-c6f5-e1f03687e165@oracle.com>
Message-ID: <b8b7c1ce-a6f8-e3d1-fbdb-b9a36cfa49a9@oracle.com>

Vote: Abstain

On 6/22/17 8:44 AM, coleen.phillimore at oracle.com wrote:
> Vote: no
>
> I agree with Thomas and Jesper.  That and last week I did a 
> commit_count for Erik and was really disappointed that there weren't 
> enough commits, so was surprised to see this nomination. Going through 
> the open review process 8 times is part of the process.
>
> I think the process says 8 significant commits but if 7 are minor and 
> one is super-significant, I believe in the average that's enough.  
> Erik has some very significant commits coming.   We should wait.
>
> Coleen
>
> On 6/22/17 8:11 AM, jesper.wilhelmsson at oracle.com wrote:
>> Vote: veto
>>
>> As much as I would like to see Erik becoming a Committer asap I must 
>> agree with Thomas that this vote was slightly premature considering 
>> that we have rejected several similar nominations in the past.
>> /Jesper
>>
>>
>>> On 22 Jun 2017, at 11:26, Thomas Schatzl <thomas.schatzl at oracle.com> 
>>> wrote:
>>>
>>> Vote: veto
>>>
>>> Justification:
>>>
>>> I looked through the changes and I do not believe they meet the
>>> (informal?) goal of having eight significant commits.
>>>
>>> Here is an overview of the contents of these changes. Feel free to
>>> correct me.
>>>
>>> trivial:
>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86 (add
>>> volatile + fix compilation)
>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746 (add
>>> volatile + fix compilation)
>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b (add
>>> volatile + fix compilation)
>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (remove
>>> obsolete code)
>>>
>>> borderline:
>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a (fix
>>> compilation)
>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0 (add
>>> volatile + fix compilation, this one is a bit larger than the others)
>>>
>>> significant:
>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd (build
>>> changes)
>>> http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6 (build changes)
>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>>>
>>> I counted the build changes as significant because I feel unable to
>>> judge them. That sums up to, including the ones I considered
>>> borderline, as six significant commits.
>>>
>>> I do know Erik, and I know that he is trustworthy to be committer, and
>>> I know that he has lots of good changes about to be committed, but in
>>> addition to this understanding some formal requirements must be met (or
>>> at least very close to) at the time of nomination.
>>>
>>> This is, in my view not the case here at this time.
>>>
>>> We have in the past also been pretty strict about getting the Committer
>>> role, and I think it would devalue every others' hard work to attain
>>> that goal. I also, just a few months ago, privately looked through
>>> commits of somebody else as trustworthy in the same situation, and I
>>> asked him to come back after another two commits. I would like to ask
>>> the same in this case.
>>>
>>> Thanks,
>>>    Thomas
>>>
>>>
>>> On Thu, 2017-06-22 at 09:51 +0200, Stefan Karlsson wrote:
>>>> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>>>>
>>>> Erik is a member of the Garbage Collection team in Oracle. He likes
>>>> to
>>>> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves
>>>> template metaprogramming, and is currently working on creating a GC
>>>> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface
>>>> [3][4]
>>>>
>>>> Votes are due by 2017-07-06T09:50+02:00.
>>>>
>>>> Only current JDK 10 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].
>>>>
>>>> Stefan Karlsson
>>>>
>>>> Contributions:
>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc
>>>> (missing
>>>> attribution)
>>>>    http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>>>>
>>>>
>>>> [1] http://openjdk.java.net/census
>>>> [2] http://openjdk.java.net/projects/#committer-vote
>>>> [3] http://openjdk.java.net/jeps/304
>>>> [4]
>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/0197
>>>> 41.html
>


From paul.sandoz at oracle.com  Thu Jun 22 17:17:18 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 22 Jun 2017 10:17:18 -0700
Subject: =?utf-8?Q?Re=3A_Subject=3A_CFV=3A_New_JDK_10_Committer=3A_Erik_?=
 =?utf-8?Q?=C3=96sterlund?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <98596840-43D0-4BD3-A516-DF87DEF24F09@oracle.com>

Vote: yes

Paul.

From daniel.daugherty at oracle.com  Thu Jun 22 17:18:38 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 22 Jun 2017 11:18:38 -0600
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <1498123576.2831.17.camel@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
Message-ID: <4165dc43-3411-98fc-b25c-de4b6331312b@oracle.com>

On 6/22/17 3:26 AM, Thomas Schatzl wrote:
> Vote: veto
>
> Justification:
>
> I looked through the changes and I do not believe they meet the
> (informal?) goal of having eight significant commits.
>
> Here is an overview of the contents of these changes. Feel free to
> correct me.
>
> trivial:
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86 (add
> volatile + fix compilation)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746 (add
> volatile + fix compilation)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b (add
> volatile + fix compilation)

The above three changesets are specifically described as being split
off from http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
below because the fix for:

8033552: Fix missing missing volatile specifiers in CAS operations in GC 
code

had gotten too large.

Personally, I would not flag appropriately researched additions of 
"volatile"
as either trivial or borderline, but I would count all four changesets 
together
as one.

I'm not going to argue about what "significant" means. That's like arguing
religion and we're not going to get anywhere with that. The fact of the
matter is that OpenJDK (and not Oracle) requires 8 significant changesets
for some unspecified definition of "significant". Thomas has legitimately
raised a "veto" because the list of changesets does not match his definition
of "significant". I have to respect Thomas' opinion as an OpenJDK 
(R)eviewer.

If I had taken the time to read each changeset and counted them, I would
count the changesets only slightly differently and I wouldn't reach the
magic 8. However, I don't typically do that unless I have some past
experience with the person that makes me nervous about the person
being granted the role of Committer.

Full disclosure: I also know Erik and am working with him on a project. I
believe he meets what I'm looking for in a Committer and even a Reviewer.
Please notice the difference between "Reviewer" and "(R)eviewer"; I use
the parenthesized version when I'm talking about the OpenJDK role...
More than once, I have had Erik provide articulate reasons and carefully
written rationale for why some piece of code I was working on was wrong.
He's not afraid to step forward and offer an opinion. He's not afraid to
be wrong and has no problem with evolving his opinion as things change.

Yes, I would have issued:

Vote: yes

because I wouldn't have taken the time to go check the changesets if I
had not seen Thomas' veto, but I cannot and will not fault the folks that
voted "veto".

Yes, Erik has some very significant work coming to a repo near you!
He'll easily cross the "magic 8" administrative barrier and I'm enjoying
being part of that process.

I hope that Erik realizes that all this discussion is not about his work;
it is about OpenJDK processes and the indisputable fact that those processes
are applied by humans in the typical human fashion: inconsistently in the
general case.

Dan


> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (remove
> obsolete code)
>
> borderline:
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a (fix
> compilation)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0 (add
> volatile + fix compilation, this one is a bit larger than the others)
>
> significant:
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd (build
> changes)
> http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6 (build changes)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>
> I counted the build changes as significant because I feel unable to
> judge them. That sums up to, including the ones I considered
> borderline, as six significant commits.
>
> I do know Erik, and I know that he is trustworthy to be committer, and
> I know that he has lots of good changes about to be committed, but in
> addition to this understanding some formal requirements must be met (or
> at least very close to) at the time of nomination.
>
> This is, in my view not the case here at this time.
>
> We have in the past also been pretty strict about getting the Committer
> role, and I think it would devalue every others' hard work to attain
> that goal. I also, just a few months ago, privately looked through
> commits of somebody else as trustworthy in the same situation, and I
> asked him to come back after another two commits. I would like to ask
> the same in this case.
>
> Thanks,
>    Thomas
>
>
> On Thu, 2017-06-22 at 09:51 +0200, Stefan Karlsson wrote:
>> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>>
>> Erik is a member of the Garbage Collection team in Oracle. He likes
>> to
>> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves
>> template metaprogramming, and is currently working on creating a GC
>> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface
>> [3][4]
>>
>> Votes are due by 2017-07-06T09:50+02:00.
>>
>> Only current JDK 10 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].
>>
>> Stefan Karlsson
>>
>> Contributions:
>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>>    http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc
>> (missing
>> attribution)
>>    http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>>
>>
>> [1] http://openjdk.java.net/census
>> [2] http://openjdk.java.net/projects/#committer-vote
>> [3] http://openjdk.java.net/jeps/304
>> [4]
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/0197
>> 41.html


From james.graham at oracle.com  Thu Jun 22 19:44:04 2017
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 22 Jun 2017 12:44:04 -0700
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <20170622190241.436347510@eggemoggin.niobe.net>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
 <20170622190241.436347510@eggemoggin.niobe.net>
Message-ID: <8d634542-ee5b-488f-57ec-46c76b7f4ab8@oracle.com>

Vote: abstain

I am abstaining because I just wanted to comment on the process here, but I don't know anything about Erik's contributions.

On 6/22/17 10:02 AM, mark.reinhold at oracle.com wrote:
> The key question to answer when someone is nominated to a Committer role
> is: Do you trust them to use their push access in a responsible fashion?

This is the key distinction here.

The only real consideration here is "are they aware of the process and do they follow it".

Since all contributions must be peer reviewed before they go in, all we really need is for them to understand how to get 
those reviews and to understand and honor that they need them before they can do the push.  Honesty and familiarity with 
the process is the most key here.  We could have someone who has no deep understanding of the code, but all they really 
want to do is fix docs and as long as they've gone through the review process 8 or so times to fix their typos, they are 
pretty much good to go on doing their own pushes at that point - once they get their required reviews on each subsequent 
fix.

The expectation is not that they'll fix 10 typos with reviews, then we grant them Committer status and they can push on 
their own and suddenly they rewrite the world and push it without any reviews.  This vote just says "do we think this 
person can be trusted to follow the process (and are they familiar with the process)?".

Reviewer status is where we want them to have a deep understanding so that they don't look at a fundamental change to 
the locking states and inter-module communication paths and say "Approved" because they didn't spot any typos and the 
patch compiles without warnings.

Committer should be relaxed to "went through the review process N times and understands it" and Reviewer should involve 
"significance"...

> Speaking for myself, I've seen enough of Erik's work that I think he can
> be trusted, so I'm going to vote "yes".

Trust in following the process is really the only important thing here, no?  It isn't so much the content of the work, 
as it is their understanding of the review process.

Possibly "trust in understanding their own limitations" might be important too.  But, since they are still subject to 
reviews, even that isn't really necessary as long as they'll defer to reviewers who tell them that they've exceeded 
their limitations...

			...jim

From huizhe.wang at oracle.com  Thu Jun 22 21:33:55 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 22 Jun 2017 14:33:55 -0700
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
In-Reply-To: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
Message-ID: <6c6a1d9e-c63b-11d6-52a8-56b6700b456d@oracle.com>

Vote: yes

-Joe (java.net id: joehw)

On 6/20/2017 1:39 PM, Se?n Coffey wrote:
> I hereby nominate Dmitry Markov (dmarkov) to JDK 10 Reviewer. 


From christoph.langer at sap.com  Fri Jun 23 06:00:39 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 23 Jun 2017 06:00:39 +0000
Subject: New JDK 10 Reviewer: Dmitry Markov
In-Reply-To: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
Message-ID: <2f0bb5984ead428db573b6827c6aea8d@sap.com>

Vote: yes

Best regards
Christoph

> -----Original Message-----
> From: jdk10-dev [mailto:jdk10-dev-bounces at openjdk.java.net] On Behalf
> Of Se?n Coffey
> Sent: Dienstag, 20. Juni 2017 22:39
> To: jdk10-dev at openjdk.java.net
> Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
> 
> I hereby nominate Dmitry Markov (dmarkov) to JDK 10 Reviewer.
> 
> Dmitry Markov is an engineer in the Oracle JDK sustaining team. He has
> contributed several changes to the JDK 10 Project [3].
> 
> Votes are due by 22:00 GMT, 4th July 2017.
> 
> Only current JDK 10 Reviewers [1] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying to this mailing
> list.
> 
> For Three-Vote Consensus voting instructions, see [2].
> 
> regards,
> Sean.
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3]
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/log?revcount=100&rev=%28key
> word%28%22dmitry.markov%40oracle.com%22%29+or+author%28dmarkov
> %29%29

From philip.race at oracle.com  Fri Jun 23 13:52:54 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 23 Jun 2017 06:52:54 -0700
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
In-Reply-To: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
Message-ID: <594D1D36.6070509@oracle.com>

Vote: yes


From serguei.spitsyn at oracle.com  Sat Jun 24 01:44:06 2017
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 23 Jun 2017 18:44:06 -0700
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
In-Reply-To: <6c6a1d9e-c63b-11d6-52a8-56b6700b456d@oracle.com>
References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
 <6c6a1d9e-c63b-11d6-52a8-56b6700b456d@oracle.com>
Message-ID: <04574db0-f81b-14d3-c16a-760d95bb64fd@oracle.com>

Vote: yes

From thomas.stuefe at gmail.com  Sat Jun 24 04:44:20 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 24 Jun 2017 06:44:20 +0200
Subject: CFV: New JDK 10 Reviewer: Dmitry Markov
In-Reply-To: <594D1D36.6070509@oracle.com>
References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.com>
 <594D1D36.6070509@oracle.com>
Message-ID: <CAA-vtUwsBXLJnU33AwLV=yuDutwDC+coq5+SP1Oe1+ZJge0cYw@mail.gmail.com>

Vote: yes

On Fri, Jun 23, 2017 at 3:52 PM, Philip Race <philip.race at oracle.com> wrote:

> Vote: yes
>
>

From thomas.schatzl at oracle.com  Sun Jun 25 21:06:12 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Sun, 25 Jun 2017 23:06:12 +0200
Subject: Subject: CFV: New JDK 10 Committer: Erik
 =?ISO-8859-1?Q?=D6sterlund?=
In-Reply-To: <1498123576.2831.17.camel@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
Message-ID: <1498424772.2812.26.camel@oracle.com>

Vote: abstain

After some consideration over the weekend of the input from here I
change my vote. The world changes, and so should the rules as
necessary.

The "abstain" is more about that I would have preferred fixing the
rules first so that we would not be in this situation.

Erik, welcome. ;)

Thanks,
? Thomas


On Thu, 2017-06-22 at 11:26 +0200, Thomas Schatzl wrote:
> Vote: veto
> 
> Justification:
> 
> I looked through the changes and I do not believe they meet the
> (informal?) goal of having eight significant commits.
> 
> Here is an overview of the contents of these changes. Feel free to
> correct me.
> 
> trivial:
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86 (add
> volatile +?fix compilation)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746 (add
> volatile +?fix compilation)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b (add
> volatile +?fix compilation)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (remove
> obsolete code)
> 
> borderline:
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a?(fix
> compilation)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0?(add
> volatile + fix compilation, this one is a bit larger than the others)
> 
> significant:
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd (build
> changes)
> http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6 (build changes)
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
> 
> I counted the build changes as significant because I feel unable to
> judge them. That sums up to, including the ones I considered
> borderline, as six significant commits.
> 
> I do know Erik, and I know that he is trustworthy to be committer,
> and
> I know that he has lots of good changes about to be committed, but in
> addition to this understanding some formal requirements must be met
> (or
> at least very close to) at the time of nomination.
> 
> This is, in my view not the case here at this time.
> 
> We have in the past also been pretty strict about getting the
> Committer
> role, and I think it would devalue every others' hard work to attain
> that goal. I also, just a few months ago, privately looked through
> commits of somebody else as trustworthy in the same situation, and I
> asked him to come back after another two commits. I would like to ask
> the same in this case.
> 
> Thanks,
> ? Thomas
> 
> 
> On Thu, 2017-06-22 at 09:51 +0200, Stefan Karlsson wrote:
> > 
> > I hereby nominate Erik ?sterlund to JDK 10 Committer.
> > 
> > Erik is a member of the Garbage Collection team in Oracle. He likes
> > to?
> > rewrite??and fix bugs in the OrderAccess and Atomics layers, loves?
> > template metaprogramming, and is currently working on creating a
> > GC?
> > Barrier Interface as a part of JEP 304 - Garbage-Collector
> > Interface
> > [3][4]
> > 
> > Votes are due by 2017-07-06T09:50+02:00.
> > 
> > Only current JDK 10 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].
> > 
> > Stefan Karlsson
> > 
> > Contributions:
> > ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
> > ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
> > ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
> > ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
> > ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
> > ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
> > ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
> > ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
> > ? http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc
> > (missing?
> > attribution)
> > ? http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
> > 
> > 
> > [1] http://openjdk.java.net/census
> > [2] http://openjdk.java.net/projects/#committer-vote
> > [3] http://openjdk.java.net/jeps/304
> > [4]?
> > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/01
> > 97
> > 41.html

From jesper.wilhelmsson at oracle.com  Sun Jun 25 23:11:39 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Mon, 26 Jun 2017 01:11:39 +0200
Subject: =?utf-8?Q?Re=3A_Subject=3A_CFV=3A_New_JDK_10_Committer=3A_Erik_?=
 =?utf-8?Q?=C3=96sterlund?=
In-Reply-To: <20170622190241.436347510@eggemoggin.niobe.net>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
 <20170622190241.436347510@eggemoggin.niobe.net>
Message-ID: <00CB4C82-B8C6-452A-BAC4-0AF40BD5BD29@oracle.com>


> On 22 Jun 2017, at 19:02, mark.reinhold at oracle.com wrote:
> 
> 2017/6/22 11:26:16 +0200, thomas.schatzl at oracle.com:
>> Vote: veto
>> 
>> Justification:
>> 
>> I looked through the changes and I do not believe they meet the
>> (informal?) goal of having eight significant commits.
>> 
>> ...
>> 
>> I do know Erik, and I know that he is trustworthy to be committer, and
>> I know that he has lots of good changes about to be committed, but in
>> addition to this understanding some formal requirements must be met (or
>> at least very close to) at the time of nomination.
>> 
>> This is, in my view not the case here at this time.
> 
> The "eight significant contributions" threshold is not a hard-and-fast
> rule -- it's just a rough guideline, as stated [1].
> 
> The key question to answer when someone is nominated to a Committer role
> is: Do you trust them to use their push access in a responsible fashion?

If this is the key question then this question should be stated in the rules and the eight commits part should be removed.

> If someone has contributed eight significant changesets then chances are
> pretty good that they've learned how things work, what to watch out for,
> and when to ask for help, and so they can be trusted with push access.

The number of changesets pushed by someone says nothing about what the person has learned about how to work with the codebase and / or the infrastructure around it. We have seen several cases where developers has worked in sandboxes developing large new features and doing a large number of commits in that sandbox. These developers have learned the all they need to know to become Reviewers before they contribute their first change to the OpenJDK. Once the new feature is pushed they get one single commit to show for all that work. We have also seen developers that has contributed 10+ small patches in a limited area of the source base. They have never done a single "hg commit" but have simply sent a diff to someone who is to shepherd the change. These developers will have 10+ changes but should probably not be considered for a Committer role.

> If someone hasn't yet contributed eight significant changesets then that
> doesn't mean that they're not qualified to be a Committer.  If they've
> demonstrated in other ways that they have the requisite knowledge,
> skills, and judgement then a smaller number of contributions should not
> be a barrier.

There is nothing in the current text that supports that kind of translation from complex work to lower number of commits.

I propose to replace the old text:

"As a rough guide, a Contributor should make at least eight significant contributions to that Project before being nominated."

With something like:

"A Contributor who is trusted to use their push access in a responsible fashion and who has shown through previous work in the Project to understand the workflow and infrastructure required to work in the Project can be nominated."

When the text on the OpenJDK page [1] has been changed to something similar to this I'll be happy to change my vote to Yes.

Thanks,
/Jesper


> 
> Speaking for myself, I've seen enough of Erik's work that I think he can
> be trusted, so I'm going to vote "yes".
> 
> - Mark
> 
> 
> [1] http://openjdk.java.net/projects/#project-committer


From neugens.limasoftware at gmail.com  Sun Jun 25 23:48:54 2017
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Sun, 25 Jun 2017 23:48:54 +0000
Subject: =?UTF-8?Q?Re=3A_Subject=3A_CFV=3A_New_JDK_10_Committer=3A_Erik_=C3=96sterl?=
 =?UTF-8?Q?und?=
In-Reply-To: <00CB4C82-B8C6-452A-BAC4-0AF40BD5BD29@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
 <20170622190241.436347510@eggemoggin.niobe.net>
 <00CB4C82-B8C6-452A-BAC4-0AF40BD5BD29@oracle.com>
Message-ID: <CAGUMyaS-UxvAWTVCV_n1fYBAkNGvM_NMiQT+MS6DHNLX1JnXeg@mail.gmail.com>

>
> I propose to replace the old text:
>
> "As a rough guide, a Contributor should make at least eight significant
> contributions to that Project before being nominated."
>
> With something like:
>
> "A Contributor who is trusted to use their push access in a responsible
> fashion and who has shown through previous work in the Project to
> understand the workflow and infrastructure required to work in the Project
> can be nominated."
>
> When the text on the OpenJDK page [1] has been changed to something
> similar to this I'll be happy to change my vote to Yes.


I believe that "As a rough guide" is already to be taken to mean that it's
not a strict rule and best judgment applies, and we had various discussions
at FOSDEM about this topic and this was always the message given, and makes
sense!

Nevertheless, I second that change, it makes the guidelines clear and the
point explicit.

Cheers,
Mario

From per.liden at oracle.com  Mon Jun 26 06:32:00 2017
From: per.liden at oracle.com (Per Liden)
Date: Mon, 26 Jun 2017 08:32:00 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <aace7f51-75be-9f3a-b6f4-cd7772cf2679@oracle.com>

Vote: yes

/Per

On 2017-06-22 09:51, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>
> Erik is a member of the Garbage Collection team in Oracle. He likes to
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves
> template metaprogramming, and is currently working on creating a GC
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface [3][4]
>
> Votes are due by 2017-07-06T09:50+02:00.
>
> Only current JDK 10 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].
>
> Stefan Karlsson
>
> Contributions:
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing
> attribution)
>  http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4]
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html
>

From jesper.wilhelmsson at oracle.com  Mon Jun 26 13:25:56 2017
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 26 Jun 2017 15:25:56 +0200
Subject: Result: CFV: New JDK 10 Committer: Sharath Ballal
Message-ID: <B4F8AD9F-6A42-4E8F-B72C-C0A3609D6EB1@oracle.com>

Voting for Sharath Ballal [1] is now closed.

Yes: 11
Veto: 0
Abstain: 0

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

Thanks,
/Jesper

[1] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-June/000283.html <http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-June/000283.html>


From OGATAK at jp.ibm.com  Tue Jun 27 05:12:44 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Tue, 27 Jun 2017 14:12:44 +0900
Subject: RFR: 8179527: Ineffective use of volatile hurts performance of
 Charset.atBugLevel()
Message-ID: <OF2AAD04AE.D1E25224-ON4925814C.001B6E1D-4925814C.001CA256@notes.na.collabserv.com>

Hi all, please review a change for JDK-8182743.

Bug report: https://bugs.openjdk.java.net/browse/JDK-8182743
Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/

This change removes a "volatile" qualifier of a static variable used by 
Charset.atBugLevel() because it does not improve thread-safety of the code 
and it hurts performance on PPC (and should be the same in ARM, too). 
Removing the "volatile" improved performance by 26% in a POWER8 machine 
using following micro benchmark:

------
import java.io.*;
import java.nio.ByteBuffer;
import java.nio.charset.Charset;
import java.util.ArrayList;

class ConvertTest {
    static String str;

    public static void main(String[] args) {
        byte buf[] = { 0x41 };
        Charset fromCharset = Charset.forName("iso-8859-1");

        long start = System.currentTimeMillis();

        for(long i = 0; i < 100000000; i++)
            str = new String(buf, 0, 1, fromCharset);

        long end = System.currentTimeMillis();

        System.out.println("Elapsed: "+(end-start)+" ms");
    }
}
------


Regards,
Ogata


From robbin.ehn at oracle.com  Tue Jun 27 08:02:03 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 27 Jun 2017 10:02:03 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <c604f03a-01cb-2a6f-e9de-b33742d1f1e0@oracle.com>

Vote: yes

/Robbin

From sean.coffey at oracle.com  Tue Jun 27 08:40:06 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 27 Jun 2017 09:40:06 +0100
Subject: RFR: 8179527: Ineffective use of volatile hurts performance of
 Charset.atBugLevel()
In-Reply-To: <OF2AAD04AE.D1E25224-ON4925814C.001B6E1D-4925814C.001CA256@notes.na.collabserv.com>
References: <OF2AAD04AE.D1E25224-ON4925814C.001B6E1D-4925814C.001CA256@notes.na.collabserv.com>
Message-ID: <f1c98b2c-12c5-ed79-cd2f-546f3f5dc4ca@oracle.com>

This should be reviewed on nio-dev. Please drop jdk10-dev on reply.

The atBugLevel(String) method seems to be more for legacy use from JDK 
1.4/1.5 family. Maybe it's time to drop its use?  We'd need to check if 
the VM.isBooted() call is still necessary.

regards,
Sean.

On 27/06/2017 06:12, Kazunori Ogata wrote:
> Hi all, please review a change for JDK-8182743.
>
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8182743
> Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/
>
> This change removes a "volatile" qualifier of a static variable used by
> Charset.atBugLevel() because it does not improve thread-safety of the code
> and it hurts performance on PPC (and should be the same in ARM, too).
> Removing the "volatile" improved performance by 26% in a POWER8 machine
> using following micro benchmark:
>
> ------
> import java.io.*;
> import java.nio.ByteBuffer;
> import java.nio.charset.Charset;
> import java.util.ArrayList;
>
> class ConvertTest {
>      static String str;
>
>      public static void main(String[] args) {
>          byte buf[] = { 0x41 };
>          Charset fromCharset = Charset.forName("iso-8859-1");
>
>          long start = System.currentTimeMillis();
>
>          for(long i = 0; i < 100000000; i++)
>              str = new String(buf, 0, 1, fromCharset);
>
>          long end = System.currentTimeMillis();
>
>          System.out.println("Elapsed: "+(end-start)+" ms");
>      }
> }
> ------
>
>
> Regards,
> Ogata
>


From OGATAK at jp.ibm.com  Tue Jun 27 08:48:54 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Tue, 27 Jun 2017 17:48:54 +0900
Subject: RFR: 8179527: Ineffective use of volatile hurts performance of
 Charset.atBugLevel()
In-Reply-To: <f1c98b2c-12c5-ed79-cd2f-546f3f5dc4ca@oracle.com>
References: <OF2AAD04AE.D1E25224-ON4925814C.001B6E1D-4925814C.001CA256@notes.na.collabserv.com>
 <f1c98b2c-12c5-ed79-cd2f-546f3f5dc4ca@oracle.com>
Message-ID: <OF9D3C971C.41318BD3-ON4925814C.00303A2A-4925814C.00306CD9@notes.na.collabserv.com>

Hi Sean,

Thank you for your suggestion.

Langer, Christoph has gave me the same comment and redirected the RFR to 
core-libs-dev and nio-dev.  Sorry for not telling it here jdk10-dev 
earlier.


Regards,
Ogata


Se?n Coffey <sean.coffey at oracle.com> wrote on 2017/06/27 17:40:06:

> From: Se?n Coffey <sean.coffey at oracle.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>, 
ppc-aix-port-dev at openjdk.java.net,
> nio-dev at openjdk.java.net
> Cc: jdk10-dev at openjdk.java.net
> Date: 2017/06/27 17:40
> Subject: Re: RFR: 8179527: Ineffective use of volatile hurts performance 

> of Charset.atBugLevel()
> 
> This should be reviewed on nio-dev. Please drop jdk10-dev on reply.
> 
> The atBugLevel(String) method seems to be more for legacy use from JDK 
> 1.4/1.5 family. Maybe it's time to drop its use?  We'd need to check if 
> the VM.isBooted() call is still necessary.
> 
> regards,
> Sean.
> 
> On 27/06/2017 06:12, Kazunori Ogata wrote:
> > Hi all, please review a change for JDK-8182743.
> >
> > Bug report: https://bugs.openjdk.java.net/browse/JDK-8182743
> > Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/
> >
> > This change removes a "volatile" qualifier of a static variable used 
by
> > Charset.atBugLevel() because it does not improve thread-safety of the 
code
> > and it hurts performance on PPC (and should be the same in ARM, too).
> > Removing the "volatile" improved performance by 26% in a POWER8 
machine
> > using following micro benchmark:
> >
> > ------
> > import java.io.*;
> > import java.nio.ByteBuffer;
> > import java.nio.charset.Charset;
> > import java.util.ArrayList;
> >
> > class ConvertTest {
> >      static String str;
> >
> >      public static void main(String[] args) {
> >          byte buf[] = { 0x41 };
> >          Charset fromCharset = Charset.forName("iso-8859-1");
> >
> >          long start = System.currentTimeMillis();
> >
> >          for(long i = 0; i < 100000000; i++)
> >              str = new String(buf, 0, 1, fromCharset);
> >
> >          long end = System.currentTimeMillis();
> >
> >          System.out.println("Elapsed: "+(end-start)+" ms");
> >      }
> > }
> > ------
> >
> >
> > Regards,
> > Ogata
> >
> 



From stefan.johansson at oracle.com  Tue Jun 27 12:28:18 2017
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 27 Jun 2017 14:28:18 +0200
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <ad1f3535-27e2-34a6-bdff-098ae36303ff@oracle.com>

Vote: yes

On 2017-06-22 09:51, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>
> Erik is a member of the Garbage Collection team in Oracle. He likes to 
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves 
> template metaprogramming, and is currently working on creating a GC 
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface 
> [3][4]
>
> Votes are due by 2017-07-06T09:50+02:00.
>
> Only current JDK 10 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].
>
> Stefan Karlsson
>
> Contributions:
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing 
> attribution)
>  http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4] 
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html


From zgu at redhat.com  Tue Jun 27 12:33:12 2017
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 27 Jun 2017 08:33:12 -0400
Subject: =?UTF-8?Q?Re:_Subject:_CFV:_New_JDK_10_Committer:_Erik_=c3=96sterlu?=
 =?UTF-8?Q?nd?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <868c039e-2b0c-da09-56dc-1a07ac554073@redhat.com>

Vote: yes

-Zhengyu

On 06/22/2017 03:51 AM, Stefan Karlsson wrote:
> I hereby nominate Erik ?sterlund to JDK 10 Committer.
>
> Erik is a member of the Garbage Collection team in Oracle. He likes to
> rewrite  and fix bugs in the OrderAccess and Atomics layers, loves
> template metaprogramming, and is currently working on creating a GC
> Barrier Interface as a part of JEP 304 - Garbage-Collector Interface [3][4]
>
> Votes are due by 2017-07-06T09:50+02:00.
>
> Only current JDK 10 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].
>
> Stefan Karlsson
>
> Contributions:
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bb5c32e2d31a
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5793813a17dd
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/f1ad14991f86
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/c2ecbb9ee746
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8fcdd3cc8da0
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/4d009502987b
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/8a4e011d99be
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/5398ffa1a419
>  http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/bbf76069d7fc (missing
> attribution)
>  http://hg.openjdk.java.net/jdk10/hs/rev/55bf5464b0e6
>
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> [3] http://openjdk.java.net/jeps/304
> [4]
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2017-April/019741.html
>

From jesper.wilhelmsson at oracle.com  Tue Jun 27 18:59:05 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 27 Jun 2017 20:59:05 +0200
Subject: =?utf-8?Q?Re=3A_Subject=3A_CFV=3A_New_JDK_10_Committer=3A_Erik_?=
 =?utf-8?Q?=C3=96sterlund?=
In-Reply-To: <00CB4C82-B8C6-452A-BAC4-0AF40BD5BD29@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
 <1498123576.2831.17.camel@oracle.com>
 <20170622190241.436347510@eggemoggin.niobe.net>
 <00CB4C82-B8C6-452A-BAC4-0AF40BD5BD29@oracle.com>
Message-ID: <4FE0B025-BF25-40D1-8662-8632AAA53357@oracle.com>


> "A Contributor who is trusted to use their push access in a responsible fashion and who has shown through previous work in the Project to understand the workflow and infrastructure required to work in the Project can be nominated."

It's clear to me that a large part of the community thinks that the description above is more appropriate and already votes based on this (or a similar) interpretation of the bylaws. Since a review of the bylaws and the clarifications of it will take more time than what is left of this voting period (and I don't want to hold Erik's nomination hostage) I'll simply go by the definition above and change my vote.

Vote: Yes.

/Jesper


From kushaldeveloper at gmail.com  Tue Jun 27 19:17:52 2017
From: kushaldeveloper at gmail.com (Kus)
Date: Tue, 27 Jun 2017 15:17:52 -0400
Subject: =?UTF-8?Q?Re=3A_Subject=3A_CFV=3A_New_JDK_1?=
 =?UTF-8?Q?0_Committer=3A_Erik_=C3=96sterlund?=
In-Reply-To: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com>
Message-ID: <E9F40AD8-1A8C-4B43-92B4-FF733F6046D8@gmail.com>

Can't vote but just wanted to say congratulations and welcome! 

Sincerely, 

From jesper.wilhelmsson at oracle.com  Tue Jun 27 20:40:27 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 27 Jun 2017 22:40:27 +0200
Subject: Duplicate bug ID blocking integration
Message-ID: <67D6F51C-5D71-48CF-AD74-B3DD5ED2F5EF@oracle.com>

Hi,

Another change has been pushed to both JDK 9 and JDK 10 using different changesets with the same bug id. The fix from 9 has been automatically forwardported to 10, and since the JDK 10 fix was pushed to 10/hs we are now blocked from integrating 10/10 changes to 10/hs.

The last time this happened it was suggested that removing the duplicate id check might be a better option than to whitelist the change. What is the timeline for removing the duplicate id check?

Thanks,
/Jesper


From joe.darcy at oracle.com  Tue Jun 27 21:20:14 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 27 Jun 2017 14:20:14 -0700
Subject: Duplicate bug ID blocking integration
In-Reply-To: <67D6F51C-5D71-48CF-AD74-B3DD5ED2F5EF@oracle.com>
References: <67D6F51C-5D71-48CF-AD74-B3DD5ED2F5EF@oracle.com>
Message-ID: <5952CC0E.6010904@oracle.com>

Per previous discussions [1], the unique bug id check is planned to be 
disabled when the repository consolidation occurs (update on that 
project coming soon).

I see no harm in disabling the duplicate bug id check in JDK 10 a bit 
earlier, say right now.

Cheers,

-Joe

[1] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-April/000152.html

On 6/27/2017 1:40 PM, jesper.wilhelmsson at oracle.com wrote:
> Hi,
>
> Another change has been pushed to both JDK 9 and JDK 10 using different changesets with the same bug id. The fix from 9 has been automatically forwardported to 10, and since the JDK 10 fix was pushed to 10/hs we are now blocked from integrating 10/10 changes to 10/hs.
>
> The last time this happened it was suggested that removing the duplicate id check might be a better option than to whitelist the change. What is the timeline for removing the duplicate id check?
>
> Thanks,
> /Jesper
>


From joe.darcy at oracle.com  Tue Jun 27 23:23:37 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 27 Jun 2017 16:23:37 -0700
Subject: Update on JDK 10 repo consolidation;
 consolidation planned for September 2017
Message-ID: <5952E8F9.7010405@oracle.com>

Hello,

With JEP 296: "Consolidate the JDK Forest into a Single Repository," now 
targeted to JDK 10, I wanted to give an update on the planned timing of 
the consolidation.

We are looking to perform the consolidation in September of this year. 
Doing the consolidation at that time will allow essentially all of the 
expected JDK 9 [2] fixes to get into 10 through forward porting from Hg 
syncs [3]. Key personnel for the project will also be available at this 
time.

A rough outline of the subtasks of the consolidation:

All outstanding changes from JDK 9 and from child integration forests 
(hs and client), will need to get integrated into JDK 10 master. The 
particular JDK 9 build to be used as the last source of changes for JDK 
10 will be communicated when that is known. After that point, any fixes 
to go into both JDK 9 and JDK 10 will need to be pushed separately.

An integration of the state of JDK 10 after collecting the fixes above 
will be done and tagged. The child forests will be marked read-only.

The JDK 10 sandbox will also be marked read-only and users of the forest 
will be advised to migrate their patches out. Likewise for project 
forests that are children of JDK 10.

The JDK 10 master forest will be marked as read-only and the 
consolidation conversion process run on a copy. A new master forest with 
a new name will be created and published. Another JDK 10 integration 
will be performed on the new master post-consolidation. While the 
contents of the sources at a file-level are expected to be the same 
before and after the consolidation, the build system will be different 
and the file locations altered.

The old integration forests and sandbox will be deleted and new 
consolidated versions created.

Boundary systems will be adjusted to work with the consolidated layout.

After that point, the new consolidated repository will be open again for 
business. During the consolidation process, I'd expect a nontrivial 
period of time where JDK 10 master was unavailable to accept changes, 
say two weeks. The integration forests will also be unavailable for a 
somewhat longer period of time starting from their last integration to 
master until the new master is created and open.

More details on the plan will be developed as the consolidation gets closer.

Comments?

Thanks,

-Joe

[1] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-June/000296.html

[2] http://openjdk.java.net/projects/jdk9/

[3] 
http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-February/000054.html

From mark.reinhold at oracle.com  Wed Jun 28 14:58:47 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 28 Jun 2017 07:58:47 -0700
Subject: Duplicate bug ID blocking integration
In-Reply-To: <5952CC0E.6010904@oracle.com>
References: <67D6F51C-5D71-48CF-AD74-B3DD5ED2F5EF@oracle.com>
 <5952CC0E.6010904@oracle.com>
Message-ID: <20170628075847.242910807@eggemoggin.niobe.net>

2017/6/27 14:20:14 -0700, joe.darcy at oracle.com:
> Per previous discussions [1], the unique bug id check is planned to be 
> disabled when the repository consolidation occurs (update on that 
> project coming soon).
> 
> I see no harm in disabling the duplicate bug id check in JDK 10 a bit 
> earlier, say right now.

Agreed.  Configuration change in progress, stay tuned ...

- Mark

From iris.clark at oracle.com  Wed Jun 28 17:21:25 2017
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 28 Jun 2017 10:21:25 -0700 (PDT)
Subject: RFR 8183142:  Add bugids=dup to .jcheck/conf files for JDK 10
Message-ID: <17b705ac-5d44-44dc-93f5-2861b31bc6f6@default>

Hi, Mark.

 

Please review your requested changes to add "bugids=dup" to .jcheck/conf.

 

    https://bugs.openjdk.java.net/browse/JDK-8183142

 

Thanks,

Iris

 

$ hg tdiff

[/w/iclark/10/jdk10]:

diff -r 2b621c408db2 .jcheck/conf

--- a/.jcheck/conf      Tue Jun 27 08:43:15 2017 -0700

+++ b/.jcheck/conf      Wed Jun 28 10:03:28 2017 -0700

@@ -1,1 +1,2 @@

project=jdk10

+bugids=dup

 

[/w/iclark/10/jdk10/corba]:

diff -r 994baad957b1 .jcheck/conf

--- a/.jcheck/conf      Sat Jun 24 02:59:27 2017 +0000

+++ b/.jcheck/conf      Wed Jun 28 10:03:29 2017 -0700

@@ -1,1 +1,2 @@

project=jdk10

+bugids=dup

 

[/w/iclark/10/jdk10/hotspot]:

diff -r 2fedf1a1a198 .jcheck/conf

--- a/.jcheck/conf      Tue Jun 27 08:43:58 2017 -0700

+++ b/.jcheck/conf      Wed Jun 28 10:03:32 2017 -0700

@@ -1,1 +1,2 @@

project=jdk10

+bugids=dup

 

[/w/iclark/10/jdk10/jaxp]:

diff -r 3271b384a644 .jcheck/conf

--- a/.jcheck/conf      Sat Jun 24 02:59:17 2017 +0000

+++ b/.jcheck/conf      Wed Jun 28 10:03:32 2017 -0700

@@ -1,1 +1,2 @@

project=jdk10

+bugids=dup

 

[/w/iclark/10/jdk10/jaxws]:

diff -r ab96cd045656 .jcheck/conf

--- a/.jcheck/conf      Sat Jun 24 02:59:30 2017 +0000

+++ b/.jcheck/conf      Wed Jun 28 10:03:35 2017 -0700

@@ -1,1 +1,2 @@

project=jdk10

+bugids=dup

 

[/w/iclark/10/jdk10/jdk]:

diff -r 2a6422d32050 .jcheck/conf

--- a/.jcheck/conf      Tue Jun 27 08:43:35 2017 -0700

+++ b/.jcheck/conf      Wed Jun 28 10:03:38 2017 -0700

@@ -1,1 +1,2 @@

project=jdk10

+bugids=dup

 

[/w/iclark/10/jdk10/langtools]:

diff -r c342fff3c5f7 .jcheck/conf

--- a/.jcheck/conf      Tue Jun 27 15:30:21 2017 +0530

+++ b/.jcheck/conf      Wed Jun 28 10:03:39 2017 -0700

@@ -1,1 +1,2 @@

project=jdk10

+bugids=dup

 

[/w/iclark/10/jdk10/nashorn]:

diff -r fc3af109dace .jcheck/conf

--- a/.jcheck/conf      Sat Jun 24 02:59:26 2017 +0000

+++ b/.jcheck/conf      Wed Jun 28 10:03:40 2017 -0700

@@ -1,1 +1,2 @@

project=jdk10

+bugids=dup

 

From mark.reinhold at oracle.com  Wed Jun 28 18:23:10 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 28 Jun 2017 11:23:10 -0700
Subject: RFR 8183142:  Add bugids=dup to .jcheck/conf files for JDK 10
In-Reply-To: <17b705ac-5d44-44dc-93f5-2861b31bc6f6@default>
References: <17b705ac-5d44-44dc-93f5-2861b31bc6f6@default>
Message-ID: <20170628112310.16744350@eggemoggin.niobe.net>

2017/6/28 10:21:25 -0700, iris.clark at oracle.com:
> Please review your requested changes to add "bugids=dup" to .jcheck/conf.
> 
>     https://bugs.openjdk.java.net/browse/JDK-8183142

These look good (modulo the extraneous blank lines) -- thanks!

- Mark

From iris.clark at oracle.com  Wed Jun 28 18:47:40 2017
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 28 Jun 2017 11:47:40 -0700 (PDT)
Subject: RFR 8183142:  Add bugids=dup to .jcheck/conf files for JDK 10
In-Reply-To: <20170628112310.16744350@eggemoggin.niobe.net>
References: <17b705ac-5d44-44dc-93f5-2861b31bc6f6@default>
 <20170628112310.16744350@eggemoggin.niobe.net>
Message-ID: <965a14eb-c739-4d1d-a2ae-a4092cfdd203@default>

Hi, Mark.

>> Please review your requested changes to add "bugids=dup" to .jcheck/conf.
>> 
>>     https://bugs.openjdk.java.net/browse/JDK-8183142
>
> These look good (modulo the extraneous blank lines) -- thanks!

Sorry for doubling the size of the message.  

Pushed.  I think we're set.

Thanks,
Iris