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: References: <092b320b-3230-cb69-99d3-1d7777723578@redhat.com> <648fc2bf-34d0-2796-dd79-9e498536b23b@redhat.com> <806cff0e-a48f-9a31-c384-caa83c423e8b@redhat.com> <2062698c-838b-ad17-0d35-acfc7706878d@oracle.com> <3d963255-2006-de03-4b81-87a3dd64ef72@redhat.com> <45c4ea7f-3137-76ae-d20a-df35922f4266@redhat.com> <592C120A.1080908@oracle.com> <561661eb-b463-726a-1d32-84ef5f32af13@oracle.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 wrote: >> >> >> 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 >>> 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> <806cff0e-a48f-9a31-c384-caa83c423e8b@redhat.com> <2062698c-838b-ad17-0d35-acfc7706878d@oracle.com> <3d963255-2006-de03-4b81-87a3dd64ef72@redhat.com> <45c4ea7f-3137-76ae-d20a-df35922f4266@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. 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> <806cff0e-a48f-9a31-c384-caa83c423e8b@redhat.com> <2062698c-838b-ad17-0d35-acfc7706878d@oracle.com> <3d963255-2006-de03-4b81-87a3dd64ef72@redhat.com> <45c4ea7f-3137-76ae-d20a-df35922f4266@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> <806cff0e-a48f-9a31-c384-caa83c423e8b@redhat.com> <2062698c-838b-ad17-0d35-acfc7706878d@oracle.com> <3d963255-2006-de03-4b81-87a3dd64ef72@redhat.com> <45c4ea7f-3137-76ae-d20a-df35922f4266@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: 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. 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: 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. 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: References: Message-ID: <2c38a40e-663d-a274-201c-098e14611752@Oracle.com> Hi, For InteliJ, the /common/bin/idea.sh will generate a project for all modules. For Netbeans, there are a series of projects in /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: References: 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: <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. 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: References: Message-ID: 2017-06-05 18:30 GMT+02:00 Andrew Haley : > 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: References: 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 : >> 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: <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: <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com> <9e79837b-c60b-8dff-1aa6-6ee3646a5eb7@oracle.com> Message-ID: On Wed, Jun 7, 2017 at 2:34 PM, Robbin Ehn 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: References: <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com> <9e79837b-c60b-8dff-1aa6-6ee3646a5eb7@oracle.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 > 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 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 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: <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com> <9e79837b-c60b-8dff-1aa6-6ee3646a5eb7@oracle.com> <8215ad5d-f2d0-45ed-9ee8-5a59b1a2b8aa@oracle.com> Message-ID: 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 > > 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 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 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: <19d2b78d-0fba-05f8-462d-a31723bad80a@redhat.com> <9e79837b-c60b-8dff-1aa6-6ee3646a5eb7@oracle.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 > >> 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: 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 [2] 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/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 "jdb input stream closed prematurely" 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: References: 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 > [2] 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/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 "jdb input stream closed prematurely" > 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: References: 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 > [2] 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/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 "jdb input stream closed prematurely" > 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: References: 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 > [2] 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/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 "jdb input stream closed prematurely" > 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: <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 >> [2] 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/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"jdb input stream closed prematurely" >> 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: References: Message-ID: 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: References: 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: References: 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: References: Message-ID: 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: References: Message-ID: 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. 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: References: Message-ID: <76564EC2-31E0-4E4E-ADFD-1C291F210958@tagtraum.com> > On Jun 13, 2017, at 11:05, Andrew Haley 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. 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: References: 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: 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: References: 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 > [2] 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/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 "jdb input stream closed prematurely" > 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: 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: Vote: yes On Thu, Jun 22, 2017 at 9: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 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: References: Message-ID: Vote: yes On Thu, Jun 8, 2017 at 9:25 PM, 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 > [2] 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/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 "jdb input stream closed prematurely" > 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: Vote: yes On Tue, Jun 20, 2017 at 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 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: References: 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 > [2] 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/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 "jdb input stream closed prematurely" > 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: 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 -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +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 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: 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: References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com> Message-ID: Vote: yes -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. 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: 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 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: References: <455d2f95-6557-b21f-4602-5092c6a06653@oracle.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 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: References: Message-ID: Vote: yes Best regards, Vladimir Ivanov > On Thu, Jun 8, 2017 at 9:25 PM, 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: 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 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 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. 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: 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: 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: 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: <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: 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: 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 : > 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: References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com> Message-ID: 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 : >> 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: References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com> Message-ID: 2017-06-22 18:44 GMT+02:00 Daniel D. Daugherty : > 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: References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.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: 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: References: <25836b83-d4e7-1448-0514-6aeea542d736@oracle.com> <1498123576.2831.17.camel@oracle.com> <08245428-292B-447B-B23B-5BA9C7E03AE9@oracle.com> Message-ID: 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 >>> 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: Vote: yes On Fri, Jun 23, 2017 at 3:52 PM, Philip Race 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: > > 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: 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: 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 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: 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: 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: References: Message-ID: 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: References: Message-ID: 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 wrote on 2017/06/27 17:40:06: > From: Se?n Coffey > To: Kazunori Ogata , 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: 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: 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