Re: RFR(M) 8213348: jdk.internal.vm.compiler.management service providers missing in module descriptor

Thanks Mandy. dl On 11/8/18 1:02 PM, Mandy Chung wrote: On 11/8/18 12:37 PM, dean.l...@oracle.com wrote: On 11/8/18 11:49 AM, Mandy Chung wrote: This is strange.  upgrade module path precedes the application module path in the search path.  I would not expect --module-path would help.

Re: RFR(M) 8213348: jdk.internal.vm.compiler.management service providers missing in module descriptor

I get this without --module-path:   Fatal Error: Unable to find package java.lang in classpath or bootclasspath I guess before, when it was using the unnamed module, that it was picking up these system classes from the jdk10 bootjdk, which doesn't seem ideal. It works without

Re: RFR(M) 8213348: jdk.internal.vm.compiler.management service providers missing in module descriptor

Thanks Erik. dl On 11/8/18 9:02 AM, Erik Joelsson wrote: Hello, The build changes look ok as long as Jon and Mandy are happy with how javac is invoked. /Erik On 2018-11-07 19:56, dean.l...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8213348

RFR(M) 8213348: jdk.internal.vm.compiler.management service providers missing in module descriptor

https://bugs.openjdk.java.net/browse/JDK-8213348 https://bugs.openjdk.java.net/browse/JDK-8211781 http://cr.openjdk.java.net/~dlong/8213348/webrev/ Added new make/gensrc/Gensrc-jdk.internal.vm.compiler.management.gmk to create module-info.java.extra for jdk.internal.vm.compiler.management.  I

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Thanks Roger. dl On 11/5/18 2:00 PM, Roger Riggs wrote: Hi Dean, Looks ok, I have no better suggestion. Roger On 11/05/2018 01:51 PM, dean.l...@oracle.com wrote: Hi Roger.  Thanks for looking at this. On 11/5/18 7:21 AM, Roger Riggs wrote: Hi Dean, typo AccessController line788:

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Fixed.  Thanks. dl On 11/5/18 8:00 AM, Sean Mullan wrote: 726 * The VM recoginizes this method as special, so any changes to the s/recoginizes/recognizes/ --Sean On 11/3/18 4:00 PM, dean.l...@oracle.com wrote: I made a pass at improving the comments based on feedback I've received.  I

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Thanks Alan. dl On 11/4/18 1:03 AM, Alan Bateman wrote: On 03/11/2018 20:00, dean.l...@oracle.com wrote: I made a pass at improving the comments based on feedback I've received.  I updated webrev.4 in place, along with an incremental diff: I looked through the updated webrev.4, mostly

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Thanks Alan. dl On 11/4/18 1:03 AM, Alan Bateman wrote: On 03/11/2018 20:00, dean.l...@oracle.com wrote: I made a pass at improving the comments based on feedback I've received.  I updated webrev.4 in place, along with an incremental diff: I looked through the updated webrev.4, mostly

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

I made a pass at improving the comments based on feedback I've received.  I updated webrev.4 in place, along with an incremental diff: http://cr.openjdk.java.net/~dlong/8212605/webrev.4.update/ dl On 10/31/18 9:39 PM, Bernd Eckenfels wrote: I find the tail call optimization comment in

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

I made a pass at improving the comments based on feedback I've received.  I updated webrev.4 in place, along with an incremental diff: http://cr.openjdk.java.net/~dlong/8212605/webrev.4.update/ dl On 10/31/18 9:39 PM, Bernd Eckenfels wrote: I find the tail call optimization comment in

Re: RFR 8203174: [Graal] JDI tests fail with Unexpected exception: com.sun.jdi.ObjectCollectedException

I don't think suspending compiler threads is safe, especially if compiles are blocking/synchronous. dl On 11/2/18 4:29 PM, Daniil Titov wrote: Please review the change that fixes several tests failing with com.sun.jdi.ObjectCollectedException when running with Graal. There main problem here

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Thanks Mandy.  I also appreciate you noticing (off-list) that I can remove the extra space in "Class " in several places.  I have updated webrev.4 in place. dl On 11/2/18 1:55 PM, Mandy Chung wrote: Hi Dean, I reviewed webrev.4 version.  It looks good.  Happy to see moving the doPrivileged

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Thanks Mandy.  I also appreciate you noticing (off-list) that I can remove the extra space in "Class " in several places.  I have updated webrev.4 in place. dl On 11/2/18 1:55 PM, Mandy Chung wrote: Hi Dean, I reviewed webrev.4 version.  It looks good.  Happy to see moving the doPrivileged

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 11/1/18 12:39 PM, Sean Mullan wrote: I also replaced getCallerPD with the faster getProtectionDomain and removed a stale comment about impliesCreateAccessControlContext being called by the VM. It should be safe to remove now, but I left it in to minimize changes. I would just remove it,

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 11/1/18 12:39 PM, Sean Mullan wrote: I also replaced getCallerPD with the faster getProtectionDomain and removed a stale comment about impliesCreateAccessControlContext being called by the VM. It should be safe to remove now, but I left it in to minimize changes. I would just remove it,

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 11/1/18 1:45 PM, Mandy Chung wrote: On 11/1/18 1:18 AM, Vladimir Ivanov wrote: I think it's a good idea, but I believe it would require a CSR request. Do you mind if I file a separate issue for jdk.internal.vm.annotation.Hidden? Sure. Most of the annotations in

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 11/1/18 1:45 PM, Mandy Chung wrote: On 11/1/18 1:18 AM, Vladimir Ivanov wrote: I think it's a good idea, but I believe it would require a CSR request. Do you mind if I file a separate issue for jdk.internal.vm.annotation.Hidden? Sure. Most of the annotations in

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 11/1/18 9:48 AM, Sean Mullan wrote: On 11/1/18 1:29 AM, dean.l...@oracle.com wrote: On 10/31/18 9:39 PM, Bernd Eckenfels wrote: http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html In checkContext should the

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 11/1/18 9:48 AM, Sean Mullan wrote: On 11/1/18 1:29 AM, dean.l...@oracle.com wrote: On 10/31/18 9:39 PM, Bernd Eckenfels wrote: http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html In checkContext should the

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 11/1/18 10:01 AM, Sean Mullan wrote: Some of the copyrights need to be updated to 2018. Fixed. All else looks good to me as I had reviewed an earlier version of this before. We have talked about doing this for a while now, so I am finally glad we and are able to pretty much eliminate

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 11/1/18 10:01 AM, Sean Mullan wrote: Some of the copyrights need to be updated to 2018. Fixed. All else looks good to me as I had reviewed an earlier version of this before. We have talked about doing this for a while now, so I am finally glad we and are able to pretty much eliminate

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Hi Peter.  Thanks for the input.  I don't know about DomainCombiner, but perhaps someone else on this list does. dl On 10/31/18 6:15 PM, Peter wrote: Hello Dean & David, Interesting reading.   Is DomainCombiner still being considered for deprecation? Our code makes heavy use of

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Hi Bernd, On 10/31/18 9:39 PM, Bernd Eckenfels wrote: http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html In checkContext should the security manager be null checked first instead of last to optimize for the typical

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Hi Bernd, On 10/31/18 9:39 PM, Bernd Eckenfels wrote: http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html In checkContext should the security manager be null checked first instead of last to optimize for the typical

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

I think it's a good idea, but I believe it would require a CSR request.  Do you mind if I file a separate issue for jdk.internal.vm.annotation.Hidden? dl On 10/31/18 6:11 PM, Vladimir Ivanov wrote: Dean, src/java.base/share/classes/java/security/AccessController.java: +    /** + *

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

I think it's a good idea, but I believe it would require a CSR request.  Do you mind if I file a separate issue for jdk.internal.vm.annotation.Hidden? dl On 10/31/18 6:11 PM, Vladimir Ivanov wrote: Dean, src/java.base/share/classes/java/security/AccessController.java: +    /** + *

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Thanks Ioi. dl On 10/31/18 6:01 PM, Ioi Lam wrote: On 10/31/18 5:13 PM, dean.l...@oracle.com wrote: On 10/31/18 4:06 PM, David Holmes wrote: Hi Dean, Looking only at the hotspot changes. The removal of the DoPrivileged and related privileged_stack code seems okay. I have a few related

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Thanks David. dl On 10/31/18 5:54 PM, David Holmes wrote: Hi Dean, On 1/11/2018 10:13 AM, dean.l...@oracle.com wrote: On 10/31/18 4:06 PM, David Holmes wrote: Hi Dean, Looking only at the hotspot changes. The removal of the DoPrivileged and related privileged_stack code seems okay. I have

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Thanks Ioi. dl On 10/31/18 6:01 PM, Ioi Lam wrote: On 10/31/18 5:13 PM, dean.l...@oracle.com wrote: On 10/31/18 4:06 PM, David Holmes wrote: Hi Dean, Looking only at the hotspot changes. The removal of the DoPrivileged and related privileged_stack code seems okay. I have a few related

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Thanks David. dl On 10/31/18 5:54 PM, David Holmes wrote: Hi Dean, On 1/11/2018 10:13 AM, dean.l...@oracle.com wrote: On 10/31/18 4:06 PM, David Holmes wrote: Hi Dean, Looking only at the hotspot changes. The removal of the DoPrivileged and related privileged_stack code seems okay. I have

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 10/31/18 4:06 PM, David Holmes wrote: Hi Dean, Looking only at the hotspot changes. The removal of the DoPrivileged and related privileged_stack code seems okay. I have a few related comments: src/hotspot/share/classfile/systemDictionary.hpp You added the java_security_AccessController

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

On 10/31/18 4:06 PM, David Holmes wrote: Hi Dean, Looking only at the hotspot changes. The removal of the DoPrivileged and related privileged_stack code seems okay. I have a few related comments: src/hotspot/share/classfile/systemDictionary.hpp You added the java_security_AccessController

RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

https://bugs.openjdk.java.net/browse/JDK-8212605 http://cr.openjdk.java.net/~dlong/8212605/webrev.1 This change implements AccessController.doPrivileged in Java.  This gives a performance improvement while also being useful to Project Loom by removing the Java --> native --> Java transition. 

RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

https://bugs.openjdk.java.net/browse/JDK-8212605 http://cr.openjdk.java.net/~dlong/8212605/webrev.1 This change implements AccessController.doPrivileged in Java.  This gives a performance improvement while also being useful to Project Loom by removing the Java --> native --> Java transition. 

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/23/18 11:04 PM, Mandy Chung wrote: On 10/23/18 10:34 PM, David Holmes wrote: On 24/10/2018 8:30 AM, dean.l...@oracle.com wrote: On 10/23/18 2:51 PM, David Holmes wrote: Hi Dean, On 24/10/2018 4:05 AM, dean.l...@oracle.com wrote: On 10/23/18 9:46 AM, dean.l...@oracle.com wrote: On

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/23/18 2:51 PM, David Holmes wrote: Hi Dean, On 24/10/2018 4:05 AM, dean.l...@oracle.com wrote: On 10/23/18 9:46 AM, dean.l...@oracle.com wrote: On 10/22/18 3:31 PM, David Holmes wrote: Sorry Dean I'm concerned about a thread termination bottleneck with this. A simple microbenchmark

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/23/18 9:46 AM, dean.l...@oracle.com wrote: On 10/22/18 3:31 PM, David Holmes wrote: Sorry Dean I'm concerned about a thread termination bottleneck with this. A simple microbenchmark that creates 500,000 threads that have to run and terminate, shows a 15+% slowdown on my Linux box. I

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/22/18 3:31 PM, David Holmes wrote: Sorry Dean I'm concerned about a thread termination bottleneck with this. A simple microbenchmark that creates 500,000 threads that have to run and terminate, shows a 15+% slowdown on my Linux box. I tried to find some kind of real benchmarks that

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/18/18 6:12 PM, Mandy Chung wrote: On 10/18/18 12:27 AM, David Holmes wrote: Hi Dean, On 18/10/2018 2:06 PM, dean.l...@oracle.com wrote: You're right, I missed that.  I think the right thing to do is call current_thread_exiting while holding the Threads_lock. Then we can get rid of

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/17/18 7:07 PM, David Holmes wrote: Hi Dean, This still seems racy to me. We increment all counts under the Threads_lock but we still decrement without the Threads_lock. So we can lose updates to the perfCounters.  117   _total_threads_count->inc();  118  

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

Thanks, Mandy! dl On 10/17/18 6:35 PM, Mandy Chung wrote: On 10/17/18 3:18 PM, dean.l...@oracle.com wrote: New webrevs, full and incremental: http://cr.openjdk.java.net/~dlong/8021335/webrev.6/ http://cr.openjdk.java.net/~dlong/8021335/webrev.6.diff/ I like it better without all the

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

Thanks JC! dl On 10/17/18 5:06 PM, JC Beyler wrote: Hi Dean, The new webrev looks much better :) LGTM (not a reviewer though :-)). Thanks, Jc On Wed, Oct 17, 2018 at 3:19 PM > wrote: On 10/17/18 2:38 PM, Mandy Chung wrote: On 10/17/18 2:13 PM,

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/17/18 2:38 PM, Mandy Chung wrote: On 10/17/18 2:13 PM, dean.l...@oracle.com wrote: On 10/17/18 1:41 PM, Mandy Chung wrote: On 10/16/18 7:33 PM, David Holmes wrote: Hi Dean, Thanks for tackling this. I'm still struggling to fully grasp why we need both the PerfCounters and the

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/17/18 1:41 PM, Mandy Chung wrote: On 10/16/18 7:33 PM, David Holmes wrote: Hi Dean, Thanks for tackling this. I'm still struggling to fully grasp why we need both the PerfCounters and the regular counters. I get that we have to decrement the live counts before ensure_join() has

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/16/18 7:33 PM, David Holmes wrote: Hi Dean, Thanks for tackling this. I'm still struggling to fully grasp why we need both the PerfCounters and the regular counters. I get that we have to decrement the live counts before ensure_join() has allowed Thread.join() to return, to ensure

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

New webrev: http://cr.openjdk.java.net/~dlong/8021335/webrev.4/ dl On 10/16/18 11:59 AM, dean.l...@oracle.com wrote: On 10/16/18 10:28 AM, JC Beyler wrote: Hi Dean, I noticed a typo here : "are atomically" is in the comment but should no longer be there I believe; the sentence probably

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/16/18 10:28 AM, JC Beyler wrote: Hi Dean, I noticed a typo here : "are atomically" is in the comment but should no longer be there I believe; the sentence probably should be: // These 2 counters are like the above thread counts, but are Fixed! Any way we could move this test into a

RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

https://bugs.openjdk.java.net/browse/JDK-8021335 http://cr.openjdk.java.net/~dlong/8021335/webrev.3/ This change attempts to fix an old and intermittent problem with ThreadMXBean thread counts. Changes have 3 main parts: 1. Make sure hidden threads don't affect counts (even when exiting) 2.

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

On 10/5/18 6:34 AM, Alan Bateman wrote: On 05/10/2018 13:59, Sean Mullan wrote: On 10/5/18 6:40 AM, Alan Bateman wrote: The only issue I see is the statement "The class is loaded by the system class loader ..." as it's actually the built-in application class loader. Is the "built-in

Re: RFR: (S) 8210512: [Testbug] vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects

+1 for this change +1 for learning new things :-) dl On 9/10/18 4:16 PM, serguei.spit...@oracle.com wrote: I also tried to learn from your email exchange with Dean L. Thanks, Serguei On 9/10/18 15:59, David Holmes wrote: Thanks for the reviews Serguei and JC. On 11/09/2018 8:10 AM, JC

Re: RFR (S) 8210512: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects

On 9/10/18 1:40 AM, David Holmes wrote: Hi Dean, On 10/09/2018 5:31 PM, dean.l...@oracle.com wrote: Hi David.  If a class references its own fields or methods, and that code is executed by the interpreter, then we should expect that constant pool entry to be resolved, shouldn't we? Yes

Re: RFR (S) 8210512: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects

Hi David.  If a class references its own fields or methods, and that code is executed by the interpreter, then we should expect that constant pool entry to be resolved, shouldn't we?  Likewise the compiler will treat it as resolved.  If we treat is as unresolved, we run into the case where we

Re: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout

OK thanks. dl On 11/6/17 10:56 AM, Chris Plummer wrote: Hi Dean, It looks like ciEnv::jvmti_state_changed() is used to support the JVMTI AddCapabilities() interface, which I believe typically a JVMTI agent uses to setup the available capabilities when the agent is first loaded (although

Re: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout

I'm not an expert in this area of code, but I'm wondering about Vladimir's comment about ciEnv::jvmti_state_changed() in the bug report.  With your fix, maybe we don't need to check ciEnv::jvmti_state_changed() (which doesn't seem to be enough by itself) and throw away the compiled result.  We

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

Actually, the assert inside getChar/putChar shouldn't affect inlining, because C1 and C2 will use the intrinsic instead, so I'd like to use webrev.2 as is, so I don't have to re-run all the tests. dl On 3/30/17 11:24 AM, dean.l...@oracle.com wrote: I would like to go with the webrev.2

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

I would like to go with the webrev.2 version, with asserts removed. All the reviewers have said they are OK with that version, and it allows more complete testing than the minimal version. dl On 3/23/17 12:03 PM, dean.l...@oracle.com wrote: On 3/23/17 11:25 AM, dean.l...@oracle.com wrote:

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

On 3/23/17 11:25 AM, dean.l...@oracle.com wrote: On 3/22/17 1:49 PM, Vladimir Ivanov wrote: Also, it looks like the changes I made to ASB.appendChars(char[] s, int off, int end) are not needed. Agree. Vladimir, don't you need to replace checkIndex with checkOffset in indexOf and

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

On 3/22/17 1:49 PM, Vladimir Ivanov wrote: Also, it looks like the changes I made to ASB.appendChars(char[] s, int off, int end) are not needed. Agree. Vladimir, don't you need to replace checkIndex with checkOffset in indexOf and lastIndexOf, so that we allow count == length? Yes, my

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

Also, it looks like the changes I made to ASB.appendChars(char[] s, int off, int end) are not needed. dl On 3/22/17 11:01 AM, dean.l...@oracle.com wrote: Vladimir, don't you need to replace checkIndex with checkOffset in indexOf and lastIndexOf, so that we allow count == length? dl On

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

Vladimir, don't you need to replace checkIndex with checkOffset in indexOf and lastIndexOf, so that we allow count == length? dl On 3/22/17 8:35 AM, Vladimir Ivanov wrote: So are we convinced that the proposed changes will never lead to a crash due to a missing or incorrect bounds check, due

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

On 3/21/17 5:02 PM, David Holmes wrote: I haven't been looking at the details of this but have been watching from afar. As per my comments in the bug report (now public) I'm quite concerned about the thread-non-safety issue here ... On 22/03/2017 4:47 AM, dean.l...@oracle.com wrote: On

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

On 3/21/17 9:37 AM, Vladimir Ivanov wrote: and webrev.2 with it removed: http://cr.openjdk.java.net/~dlong/8158168/webrev.2/ Thanks, Dean. I started with webrev.2 and tried to minimize the changes. I ended up with the following version:

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

On 3/20/17 11:10 PM, Xueming Shen wrote: Hi Dean, Thanks for doing this. Though as I suggested last time personally I prefer to make minimum change to simply seal those holes in ASB at this late stage of JDK9. I'm fine with the webrev.2 and it looks better and reasonable to pull all UTF16

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

I posted two new versions, webrev.1 keeping the Trusted inner class: http://cr.openjdk.java.net/~dlong/8158168/webrev.1/ and webrev.2 with it removed: http://cr.openjdk.java.net/~dlong/8158168/webrev.2/ dl On 3/17/17 5:58 AM, Vladimir Ivanov wrote: I have the same concern. Can we fix the

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

On 3/17/17 5:58 AM, Vladimir Ivanov wrote: I have the same concern. Can we fix the immediate problem in 9 and integrate verification logic in 10? OK, Tobias is suggesting having verification logic only inside the intrinsics. Are you suggesting removing that as well? Yes and put them

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

On 3/16/17 2:52 AM, Tobias Hartmann wrote: As a safety net, I added asserts around the intrinsic calls, and a try/catch that so any out of bounds exception turns into an assert error as well. So the assert and try/catch are only necessary to catch invalid offsets passed to the C1 intrinsic,

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

On 3/15/17 6:19 PM, David Holmes wrote: src/share/vm/classfile/javaClasses.hpp Given the the only call to java_lang_String::set_debug_intrinsics is within an ifdef, shouldn't the declaration and definition of the method also be guarded the same way? OK I'll change it. dl

Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient

On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote: On 2/23/16 5:56 AM, Thomas Stüfe wrote: Hi Cheleswer, On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu wrote: Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8146683 .

Re: PING Re: RFR: 8078521: AARCH64: Add AArch64 SA support

I added hotspot-...@openjdk.java.net again. It looks reasonable to me, but I'm not a Reviewer. dl On 5/6/2015 7:36 AM, Andrew Haley wrote: On 04/29/2015 08:42 AM, Andrew Haley wrote: http://cr.openjdk.java.net/~aph/8078521-2/ Any news on this? It shouldn't be controversial at this point.

Re: RFR: 8072740: move closed jvm.cfg files out of open repo

://bugs.openjdk.java.net/browse/JDK-8072740 webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/ Simple fix, contributed by Dean Long, that allows the jvm.cfg file to be located in the closed location. The arm and ppc jvm.cfg files can then be moved to that closed location. Thanks, David

Re: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS

On 3/13/2015 5:08 PM, David Holmes wrote: Hi Erik, On 14/03/2015 12:08 AM, Erik Joelsson wrote: Hello, While working on the new Hotspot makefiles in build-infra I noticed this problem. When introducing devkits for Solaris, we rely on the variables EXTRA_CFLAGS, EXTRA_CXXFLAGS and

Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows)

, there is no blocking on the part of the AttachListener thread, WaitForSingleObject() return immediately decrementing the current count. Thanks Markus -Original Message- From: Dean Long Sent: den 3 mars 2015 02:32 To: Markus Gronlund; serviceability-dev@openjdk.java.net; hotspot-runtime

Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows)

Couldn't you instead treat it like a monitor? Then it's OK if only the first notify wakes up the blocked thread, as long as that thread only blocks when the queue is empty. In other words, when it wakes up, it should process all the items in the queue before blocking again. dl On 3/2/2015

Re: RFR: JDK-8072904: building jdk9 with jdk9 boot jdk can cause failure or incorrect results

Looks good to me too. dl On 2/11/2015 12:11 PM, David Holmes wrote: On 11/02/2015 9:35 PM, Erik Joelsson wrote: Hello, New webrev: http://cr.openjdk.java.net/~erikj/8072904/webrev.hotspot.02/ On 2015-02-11 10:53, David Holmes wrote: Hi Erik, On 11/02/2015 7:23 PM, Erik Joelsson wrote:

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

On 2/14/2015 12:07 AM, Andrew Haley wrote: On 02/13/2015 10:52 PM, Dean Long wrote: My understanding is that whether or not aarch64 allows unaligned accesses is based on a system setting, so this change is too simplistic. Disabling unaligned access would be a really perverse thing to do

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

My understanding is that whether or not aarch64 allows unaligned accesses is based on a system setting, so this change is too simplistic. I would prefer that this was controlled with something more flexible, like sun.cpu.unaligned. dl On 2/13/2015 5:38 AM, Andrew Haley wrote:

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

UseUnalignedLoadStores which is set to true depending on which version of CPU VM runs. The CPU version is determined based on CPUID instruction results. Does AARCH64 has something similar? Regards, Vladimir On 2/13/15 3:41 PM, Dean Long wrote: On 2/13/2015 3:04 PM, chris...@zoulas.com wrote

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

On 2/13/2015 3:04 PM, chris...@zoulas.com wrote: On Feb 13, 2:52pm, dean.l...@oracle.com (Dean Long) wrote: -- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer | My understanding is that whether or not aarch64 allows unaligned=20 | accesses is based on a | system

Re: Request for approval: Backport of 8069030

Ping. Is there a different alias I should sent this to? dl On 2/9/2015 1:16 PM, Dean Long wrote: I would like to backport 8069030 to 8u60: https://bugs.openjdk.java.net/browse/JDK-8069030 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5960a65b0f54 The patch applied cleanly. dl

Re: Request for approval: Backport of 8069030

Thanks David. dl On 2/11/2015 3:33 PM, David Holmes wrote: I have no issue with this backport. David On 12/02/2015 7:00 AM, Dean Long wrote: Ping. Is there a different alias I should sent this to? dl On 2/9/2015 1:16 PM, Dean Long wrote: I would like to backport 8069030 to 8u60

Request for approval: Backport of 8069030

I would like to backport 8069030 to 8u60: https://bugs.openjdk.java.net/browse/JDK-8069030 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5960a65b0f54 The patch applied cleanly. dl

Request for approval: Backport of 8031064(XS)

I would like to backport 8031064 to 8u60: https://bugs.openjdk.java.net/browse/JDK-8031064 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/72904af52714 It has been baking in jdk9 for over a week, and the patch applied cleanly except for the copyright year. dl

Re: RFR(XS) 8069030: support new PTRACE_GETREGSET

Thanks David and Staffan for the reviews. dl On 2/2/2015 5:07 PM, David Holmes wrote: Looks good. Thanks, David On 3/02/2015 8:46 AM, Dean Long wrote: Ping. I'm still waiting for a second review on this. thanks, dl On 1/28/2015 5:15 PM, Dean Long wrote: Adding serviceability-dev

Re: Request for approval: Backport of 8031064(XS)

Thanks David. dl On 2/2/2015 5:19 PM, David Holmes wrote: On 3/02/2015 9:26 AM, Dean Long wrote: I would like to backport 8031064 to 8u60: https://bugs.openjdk.java.net/browse/JDK-8031064 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/72904af52714 It has been baking in jdk9 for over

Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

David and Dmitry, thanks for the reviews! dl On 1/22/2015 11:41 PM, David Holmes wrote: On 23/01/2015 5:36 PM, Dean Long wrote: On 1/22/2015 11:01 PM, David Holmes wrote: On 23/01/2015 4:01 AM, Dean Long wrote: On 1/22/2015 2:19 AM, David Holmes wrote: On 22/01/2015 8:39 AM, Dean Long

Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

On 1/22/2015 2:19 AM, David Holmes wrote: On 22/01/2015 8:39 AM, Dean Long wrote: Thanks Dmitry. The updated webrev is here: http://cr.openjdk.java.net/~dlong/8031064/webrev.3/ This looks weird: + VMDEF_PAT = ^_ZTV + VMDEF_PAT := ^gHotSpotVM|$(VMDEF_PAT) + VMDEF_PAT

Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

Done: https://bugs.openjdk.java.net/browse/JDK-8071436 dl On 1/22/2015 10:45 PM, Dmitry Samersoff wrote: Dean, Can we make cleaning up the other platforms a separate RFE? I think yes. So please file the RFE. -Dmitry On 2015-01-22 21:01, Dean Long wrote: On 1/22/2015 2:19 AM, David

Re: [aarch64-port-dev ] AARCH64: RFR (XS) 8068927: AARCH64: better handling of aarch64- triples (was RFR: AARCH64: Top-level JDK changes)

On 1/15/2015 5:41 AM, Magnus Ihse Bursie wrote: On 2015-01-15 00:34, Dean Long wrote: Can I get a review for this? https://bugs.openjdk.java.net/browse/JDK-8068927 http://cr.openjdk.java.net/~dlong/8068927/webrev/ Looks good to me. (However, I'm not a formal reviewer for the aarch64-port

Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

On 1/14/2015 11:01 PM, David Holmes wrote: On 15/01/2015 4:40 PM, Dean Long wrote: On 1/14/2015 10:31 PM, David Holmes wrote: Hi Dean, Code reviews don't go to jdk9-dev. Build-infra is not relevant to this either. You only need hotspot-dev for a hotspot build issue (though build-dev might

Re: RFR: AARCH64: Top-level JDK changes

On 1/14/2015 5:27 AM, Magnus Ihse Bursie wrote: On 2015-01-13 09:32, Dean Long wrote: On 1/12/2015 3:49 AM, Magnus Ihse Bursie wrote: On 2015-01-12 05:31, Dean Long wrote: I found a small problem with the new config.sub wrapper. It works with the bash shell but not with the dash shell

AARCH64: RFR (XS) 8068927: AARCH64: better handling of aarch64- triples (was RFR: AARCH64: Top-level JDK changes)

Can I get a review for this? https://bugs.openjdk.java.net/browse/JDK-8068927 http://cr.openjdk.java.net/~dlong/8068927/webrev/ thanks, dl On 1/13/2015 10:56 AM, Dean Long wrote: On 1/13/2015 1:08 AM, Andrew Haley wrote: On 13/01/15 08:44, Dean Long wrote: I came up with a simpler version

Re: RFR: AARCH64: Top-level JDK changes

On 1/13/2015 1:08 AM, Andrew Haley wrote: On 13/01/15 08:44, Dean Long wrote: I came up with a simpler version, where I replace aarch64- with arm-, run autoconf-config.sub, then replace arm- back to aarch64-. Thanks. That sounds good to me. Andrew. Here's the patch. If it looks good, I

Re: RFR: AARCH64: Top-level JDK changes

On 1/12/2015 3:49 AM, Magnus Ihse Bursie wrote: On 2015-01-12 05:31, Dean Long wrote: I found a small problem with the new config.sub wrapper. It works with the bash shell but not with the dash shell. The problem seems to be with this line: result=`. $DIR/autoconf-config.sub $sub_args

Re: RFR: AARCH64: Top-level JDK changes

On 1/12/2015 2:25 AM, Andrew Haley wrote: On 12/01/15 04:31, Dean Long wrote: I found a small problem with the new config.sub wrapper. It works with the bash shell but not with the dash shell. The problem seems to be with this line: result=`. $DIR/autoconf-config.sub $sub_args $@` dash

Re: RFR: AARCH64: Top-level JDK changes

I found a small problem with the new config.sub wrapper. It works with the bash shell but not with the dash shell. The problem seems to be with this line: result=`. $DIR/autoconf-config.sub $sub_args $@` dash doesn't seem to support args passed with ., so $sub_args $@ are ignored. dl

Re: RFR: AARCH64: 8064357: Top-level JDK changes

One minor comment: do we want to preserve the history in the new config.sub, or check it in as a new file? dl On 11/21/2014 10:03 AM, Magnus Ihse Bursie wrote: On 2014-11-21 18:02, Andrew Haley wrote: On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote: 1) Comment in config.sub identifies it

Re: RFR: AARCH64: 8064357: Top-level JDK changes

under common/autoconf/build-aux changeset: 423:e1830598f0b7 parent: 417:42f275168fa5 user:ohair date:Tue Apr 10 08:18:28 2012 -0700 summary: 7074397: Build infrastructure changes (makefile re-write) Thanks, Vladimir On 11/21/14 11:31 AM, Dean Long wrote: One minor

Re: RFR: AARCH64: 8064357: Top-level JDK changes

-configure.sh M common/autoconf/jdk-options.m4 M common/autoconf/platform.m4 A common/autoconf/build-aux/autoconf-config.sub R common/autoconf/build-aux/config.sub And webrev shows config.sub diffs vs original one and not as new file. Vladimir On 11/21/14 12:28 PM, Dean Long wrote: I was thinking

Re: RFR: AARCH64: Top-level JDK changes

On 11/17/2014 4:59 PM, Christian Thalinger wrote: On Nov 17, 2014, at 4:11 AM, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2014-11-14 21:44, Dean Long wrote: The distribution exception is there exactly since anyone should be able to distribute the files with their configure

Re: RFR: AARCH64: Top-level JDK changes

On 11/14/2014 12:39 AM, Magnus Ihse Bursie wrote: 13 nov 2014 kl. 19:33 skrev Christian Thalinger christian.thalin...@oracle.com: On Nov 13, 2014, at 6:09 AM, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2014-11-10 11:32, Volker Simonis wrote: On Mon, Nov 10, 2014 at 10:42

<    1   2   3   4   >