Re: Remove unused import proposal: in JdpController.java

I've done my fair share of import cleanup, but friction is high enough that it should be done in bulk. If you can succeed in loading jdk sources into intellij, then you can get intellij to find all the unused imports for you, e.g. in the jdk core libraries. On Wed, Feb 21, 2018 at 7:29 AM, Andrew

Re: Thread Native ID Access

On Wed, Feb 21, 2018 at 2:40 PM, Jeremy Manson wrote: > > 1) Should the ID be a long? The Hotspot thread dump prints it out as > 0x%x, which is an unsigned hexadecimal integer. The type hiding behind it > is platform-dependent, though: a pid_t on Linux, an unsigned long on > Windows, a thread_t

Re: RFR 8199467 Compilation Errors in libinstrument Reentrancy.c with VS2017

On Wed, Mar 21, 2018 at 12:13 PM, Roger Riggs wrote: > > -void * test = (void *) 0x; > +void * test = (void *) 0xul; > Martin's 15th law: Never use "l" in a numeric constant unless the constant is 0xCafeBabel, so 0xUL

Re: RFR : JDK-8071367 - JMX: Remove SNMP support

On Wed, Mar 7, 2018 at 11:27 PM, Amit Sapre wrote: > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8071367 > Is there a reason this bug is not visible?

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

I can't find any documentation for what JNIEXPORT and friends actually do. People including myself have been cargo-culting JNIEXPORT and JNICALL for decades. Why aren't they in the JNI spec? --- It's fishy that the attribute externally_visible (which seems very interesting!) is ARM specific. #

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

On Wed, Mar 28, 2018 at 3:14 PM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > On 2018-03-28 23:53, Martin Buchholz wrote: > > I can't find any documentation for what JNIEXPORT and friends actually do. > People including myself have been cargo-culting JN

Re: inspect a thread’s stack

Access to stacktraces with locals is demoed in this test http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/java/lang/StackWalker/LocalsAndOperands.java but the functionality does not seem to be available (yet!) via a public API.

RFR: 8201327: Make Sensor deeply immutably thread safe

Another little cleanup to make Google's race detector happy. 8201327: Make Sensor deeply immutably thread safe http://cr.openjdk.java.net/~martin/webrevs/jdk/Sensor-init/ https://bugs.openjdk.java.net/browse/JDK-8201327

Re: RFR: 8201327: Make Sensor deeply immutably thread safe

On Mon, Apr 9, 2018 at 1:25 PM, Chris Hegarty wrote: > > > On 9 Apr 2018, at 20:31, Alan Bateman wrote: > > > >> On 09/04/2018 18:54, Martin Buchholz wrote: > >> Another little cleanup to make Google's race detector happy. > >> > >> 820

Re: RFR: 8201327: Make Sensor deeply immutably thread safe

On Mon, Apr 9, 2018 at 7:13 PM, Martin Buchholz wrote: > > > On Mon, Apr 9, 2018 at 1:25 PM, Chris Hegarty > wrote: > >> >> > except maybe the "initially false" and "initially 0" comments as they >> are just documenting the default v

Re: RFR (S): 8202650: Enforce group for attach listener file

http://man7.org/linux/man-pages/man2/chmod.2.html *S_ISGID *(02000) set-group-ID (set process effective group ID on execve(2) ; mandatory locking, as described in fcntl(2)

Re: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp

Some of us have lobbied to make openjdk source C++11, but it's not yet. If you're brave, you can try to change that flag to -std=gnu++11 On Thu, Sep 27, 2018 at 2:33 PM, JC Beyler wrote: > Hi all, > > Sorry to come back to this so late in the game, but somehow when I synced my > hg clone (or the

Re:

Whenever I change only whitespace, I run a variant of hg diff -wbB to more easily see that it's truly only whitespace that has changed. On Fri, Oct 19, 2018 at 1:47 PM, JC Beyler wrote: > Hi all, > > Here is the first of three webrevs to remove spaces around (); I also > removed any space afte

Re: [PATCH] JDK-8025886: Replace [[ and == bash extensions in tests

I would not try to remove all bash-isms from openjdk. Instead I would find instances of /bin/sh that need to be changed to /bin/bash. (Ubuntu's use of /bin/sh -> /bin/dash is technically correct, but caused much suffering https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463 )

Re: RFR (L) 8215161: Remove spaces in assignments for vmTestbase/[a-j]

The bug title says Add spaces but the description says Remove spaces On Mon, Dec 10, 2018 at 1:04 PM JC Beyler wrote: > Hi all, > > Could I get a review that adds a space around comparisons for the > vmTestbase? This is the first of two webrevs to handle this. > > Webrev: http://cr.openjdk.java.

Re: [PATCH] JDK-8025886: Replace [[ and == bash extensions in tests

what to do. I haven't also found any existent JBS ticket > for such /bin/sh => /bin/bash a replacement. > > So any advise in this case would be appreciated! > > Regards, > Sergei > > On Mon, 10 Dec 2018 at 18:32, Martin Buchholz wrote: > >> I w

Re: RFR (L) 8215161: Remove spaces in assignments for vmTestbase/[a-j]

On Mon, Dec 10, 2018 at 1:28 PM JC Beyler wrote: > > I know, Claes noticed it too and I modified the title in the bug and the > webrevs but the RFR is out. > You should modify the bug Description to agree with the bug title.

Re: RFR (L) 8215161: Remove spaces in assignments for vmTestbase/[a-j]

Looks good to me. Make sure to "test" using hg diff -wbB On Mon, Dec 10, 2018 at 1:04 PM JC Beyler wrote: > Hi all, > > Could I get a review that adds a space around comparisons for the > vmTestbase? This is the first of two webrevs to handle this. > > Webrev: http://cr.openjdk.java.net/~jcbeyl

Re: RFR (L) 8215161: Normalize spaces for vmTestbase/[a-j]

Looks good to me. On Mon, Dec 10, 2018 at 1:49 PM JC Beyler wrote: > Hi all, > > Let's try this again; my apologies for the spam. > > Could I get a review that normalizes spaces around comparisons and the > ternary operator? This is the first of two webrevs to handle this. > > Webrev: http://cr.

Re: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo

I don't think feature changes should be mixed with maintenance. Code janitor is the most honourable profession, and it would be awesome for a code janitor to convert the entire jdk to {@code but feature contributors should not be asked to do so. On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung wrote

Re: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo

ut I >>> will also understand if you don’t want to. >>> >>> >>> (My general preference in my own code is to separate feature changes and >>> cleanup changes, just so that the history is more comprehensible, but I can >>> certainly understand tha

Re: Question about os::getenv()

Why doesn't hotspot use plain C getenv ? On Wed, Mar 4, 2015 at 12:14 PM, Jeremy Manson wrote: > Hey folks, > > We had a request internally to make it so that JAVA_TOOL_OPTIONS could > accept something longer than 1024 characters. See: > > Arguments::parse_options_environment_variable(const cha

Re: Question about os::getenv()

Sad Martin wonders why he still bothers, when all the software out there is so broken... Is it really true that on the latest Windows, C getenv is simply not available? I'd be OK with it returning NULL unconditionally...

Re: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure

It's traditional (at least on Unix) to put the message after a ": " not within parens. http://pubs.opengroup.org/onlinepubs/009695399/functions/perror.html 374 if (sb.st_uid != uid) { 375 msg = "file is not owned by the current user"; 376 } else if (sb.st_g

Re: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure

On Tue, Mar 10, 2015 at 10:53 AM, Jaroslav Bachorik < jaroslav.bacho...@oracle.com> wrote: > > This just got me thinking - would including [sb.st_uid, uid] and > [sb.st_gid, gid] in the error message be of any additional benefit? > Yes. How much do you want to improve the quality of error messag

Re: Question about os::getenv()

The story of getenv and friends is very sad. getenv is (very suprisingly!) under a cloud http://austingroupbugs.net/view.php?id=188 and the hotspot copy-to-buffer variant of the windows api returns a boolean instead of a length, not allowing the caller to respond with a properly resized buffer. An

Re: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure

Staffan > > On 10 mar 2015, at 19:07, Martin Buchholz wrote: > > > > On Tue, Mar 10, 2015 at 10:53 AM, Jaroslav Bachorik < > jaroslav.bacho...@oracle.com> wrote: > >> >> This just got me thinking - would including [sb.st_uid, uid] and >> [sb.st_gid,

Re: RFR: 8074812 More specific error message when the .java_pid well-known file is not secure

Looks good to me! On Thu, Mar 12, 2015 at 12:18 AM, Staffan Larsen wrote: > > On 11 mar 2015, at 20:37, Martin Buchholz wrote: > > Producing good error messages is such hard work! > > > Aye. And so often forgotten. > > > Instead of 0%3o, use 0%03o > > Since

Re: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently

Tests that sleep can almost always be better written some other way. In this case, I would prefer busy-waiting with timeout until the expected condition becomes true. Here's some code from jsr166 tck tests: /** * Spin-waits until sync.isQueued(t) becomes true. */ void waitForQue

Re: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently

On Thu, Apr 30, 2015 at 11:27 AM, Jaroslav Bachorik < jaroslav.bacho...@oracle.com> wrote: > On 30.4.2015 19:18, Martin Buchholz wrote: > >> Tests that sleep can almost always be better written some other way. >> In this case, I would prefer busy-waiting with timeo

Re: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently

worry that mbean.getThreadCount() is hard to test since the "system" may spin up and shut down utility threads at any time. On Wed, May 13, 2015 at 4:46 AM, Jaroslav Bachorik < jaroslav.bacho...@oracle.com> wrote: > On 1.5.2015 21:55, Martin Buchholz wrote: > >> >

Re: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently

r API rather difficult to test robustly, especially if you are only testing against the spec. On Wed, May 13, 2015 at 11:07 AM, Jaroslav Bachorik < jaroslav.bacho...@oracle.com> wrote: > On 13.5.2015 19:40, Martin Buchholz wrote: > >> toString()should never return null, I think. &

Re: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently

:11 AM, Jaroslav Bachorik < jaroslav.bacho...@oracle.com> wrote: > On 13.5.2015 21:14, Martin Buchholz wrote: > >> >> >> It's common for users to introduce parallelism in classloaders or >> jar-loaders (we do this at google) which may cause arbitrary

Re: RFR: 8080538 hprof does not work well with multiple agents on non-Solaris platforms

Pushed to jdk9 dev. On Mon, May 18, 2015 at 1:13 AM, Staffan Larsen wrote: > This looks good, but given that hprof is going away [1] I’m not sure it’s > worth the time to fix it. Anyway, I’m ok with the fix. > > Thanks, > /Staffan > > [1] https://bugs.openjdk.java.net/browse/JDK-8046661 > > > On

Re: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently

On Sat, May 16, 2015 at 2:18 AM, Jaroslav Bachorik < jaroslav.bacho...@oracle.com> wrote: > On 15.5.2015 22:59, Martin Buchholz wrote: > >> >> Consider creating a private thread group just for the test and >> restricting the count assertions to just threads in that

Re: os::current_thread_id on Linux

It would be nice if even internal hotspot APIs had clear specs. All we have now is: // thread id on Linux/64bit is 64bit, on Windows and Solaris, it's 32bit static intx current_thread_id(); pthread_self() is documented as being an opaque value that cannot necessarily be stored in a native int

Re: RFR: JDK-8134458 Make sun/tools/jps tests non-concurrent with other tests

But it is a workaround that only reduces flakiness, right? If two jtreg invocations are on the same machine running concurrently, we still have a risk of failure? On Tue, Aug 25, 2015 at 4:26 PM, Staffan Larsen wrote: > A new test (tools/launcher/ArgFileSyntax.java) was recently added. One of >

Re: RFR: JDK-8134458 Make sun/tools/jps tests non-concurrent with other tests

Looks ... OK! On Tue, Aug 25, 2015 at 9:32 PM, Staffan Larsen wrote: > > On 25 aug 2015, at 19:53, Martin Buchholz wrote: > > But it is a workaround that only reduces flakiness, right? If two jtreg > invocations are on the same machine running concurrently, we still have a &g

Re: RFR 8135188: RunFinalizationTest.java Exception java.lang.Error: Test failure: Object was not finalized

Hi Jaroslav, we all keep writing finalization code like this... welcome to the club! I think it would be better : - never use currentTimeMillis to measure elapsed time; use nanoTime instead - why use complex Phaser when simple CountDownLatch will do? I just concidentally wrote this code, which

Re: RFR 8135188: RunFinalizationTest.java Exception java.lang.Error: Test failure: Object was not finalized

On Thu, Oct 8, 2015 at 11:51 PM, Jaroslav Bachorik < jaroslav.bacho...@oracle.com> wrote: > On 8.10.2015 18:56, Martin Buchholz wrote: > >> >>I think it would be better : >> - never use currentTimeMillis to measure elapsed time; use nanoTime >> instea

Re: RFR 8135188: RunFinalizationTest.java Exception java.lang.Error: Test failure: Object was not finalized

85 long targetTime = System.nanoTime()+ TIMEOUT; 86 while (System.nanoTime()< targetTime) { This code violates the rules for usage of nanoTime https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#nanoTime--

Re: RFR 8135188: RunFinalizationTest.java Exception java.lang.Error: Test failure: Object was not finalized

If it ever happens that an object with a non-trivial finalizer is optimized away, that would be a serious JDK bug, so I would remove the constructor code for MyObject (what are you protecting against?). See my sample code in previous msg. WeakReference ref = new WeakReference(new Object() {

Re: RFR 8135188: RunFinalizationTest.java Exception java.lang.Error: Test failure: Object was not finalized

Is the code below expected to be running in the thread created by System.runFinalization()? If so, check for that, i.e. that the thread name is as you expect. 61 } else { 62 /* 63 * A 'non-finalizer' thread in this context means that we 64

Re: RFR 8135188: RunFinalizationTest.java Exception java.lang.Error: Test failure: Object was not finalized

On Thu, Oct 8, 2015 at 11:51 PM, Jaroslav Bachorik < jaroslav.bacho...@oracle.com> wrote: > On 8.10.2015 18:56, Martin Buchholz wrote: > >> Hi Jaroslav, >> >> we all keep writing finalization code like this... welcome to the club! >> >>I

Re: RFR 8135188: RunFinalizationTest.java Exception java.lang.Error: Test failure: Object was not finalized

blockFinalizerThread looks buggy to me. 103 private static void blockFinalizerThread() throws InterruptedException { 104 System.out.println("trying to block the finalizer thread"); 105 o1 = new MyObject(); 106 o1 = null; 107 System.gc(); 108 System

Re: RFR 8135188: RunFinalizationTest.java Exception java.lang.Error: Test failure: Object was not finalized

Looks good, but cant-stop-nitpicking Martin feels compelled to point out the typo here: 71 // his instance will be used to perform the GC.run_finalization test On Tue, Oct 13, 2015 at 11:47 PM, Jaroslav Bachorik < jaroslav.bacho...@oracle.com> wrote: > On 13.10.2015 20:1

Re: RFR: 8141591 : javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently

The traditional way is to have all the worker tasks count down a latch when they're started and have the master thread wait on that before proceeding. You can use test.timeout.factor to do a scaled timed wait. On Mon, Nov 9, 2015 at 8:03 AM, Jaroslav Bachorik < jaroslav.bacho...@oracle.com> wrote

Re: RFR: 8143121: javax/management/remote/mandatory/loading/MethodResultTest.java fails intermittently

3 seconds sounds like an awfully long time between retries. I'd guess that 10ms would be sufficient most of the time for other threads to get around to doing something, and 100ms for other Java processes. On Mon, Nov 23, 2015 at 7:00 AM, Alexander Kulyakhtin < alexander.kulyakh...@oracle.com> wro

Re: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

You should include core-libs-dev (and perhaps hotspot-runtime-dev) in this thread. You're changing core library code. On Wed, Jan 13, 2016 at 2:25 AM, cheleswer sahu wrote: > Hi, > > Please review the code changes for > "https://bugs.openjdk.java.net/browse/JDK-8130425";. > > Problem summary: Wh

Re: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

The process grim reaper ends up being the first point of failure since it tries not to waste the user's memory and it's in a core library, but in principle it's not special. I think a more general workaround would be to add a hotspot flag that would add a memory safety zone to all threads. If it'

Re: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

Historical note - I never liked having a reaper thread for each subprocess, but no other reliable implementation is known. Given the potential for many reaper threads, I at least wanted to keep the memory waste low. On Wed, Jan 13, 2016 at 2:25 AM, cheleswer sahu wrote: > + Th

Re: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

t; // Use a modest stack size, unless requested otherwise: > long stackSize = Boolean.getBoolean("processReaperUseDefaultStackSize") ? 0 > : 32768; > > > Someone from core-libs needs to chime on what the appropriate namespace for > such a property would be. > > Dav

Re: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts.

Apologies for taking over here ... This test is maintained externally in JSR166 CVS. We prefer a version that works well with both old and new outputs. I suggest instead "(?m)^ *[0-9]+: +([0-9]+) +[0-9]+ +\\Q"+className+"\\E(?:$| )"; Does that work with latest serviceability changes? On Fri, A

Re: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts.

a.net/~hseigel/bug_8155727.1/ > > Thanks, Harold > > > On 4/29/2016 3:19 PM, Martin Buchholz wrote: >> >> Apologies for taking over here ... This test is maintained externally >> in JSR166 CVS. We prefer a version that works well with both old and >> new outputs. I

Re: [PATCH] 6822627: NPE at ReferenceTypeImpl.constantPool

The lack of volatile or synchronization, plus the use of multiple mutable fields, suggests that a deeper fix is necessary to be truly correct. For comparison, much of the similar code implementing reflection has been changed to use volatile. But that's a big job, for the serviceability team. On

Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

This changes fdlibm, which has historically been untouched. Don't commit without Joe Darcy's approval. On Wed, Dec 7, 2016 at 7:26 AM, Lindenmaier, Goetz < goetz.lindenma...@sap.com> wrote: > Hi Dmitry, > > yes, new_jvmpath is consistent with the other variables. > I also merged the ifs in SDE.c

Re: RFR(S): 8068613: Wrong number of objects pending finalization start

Y'all should import GcFinalization for use as a testing utility. http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java On Tue, Jan 13, 2015 at 4:55 AM, Mattias Tobiasson < mattias.tobias...@oracle.com> wrote: > Hi, > Could I please

Re: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo

I'm not a serviceability engineer, but I reviewed this change and it seems fine to me. Can someone from Oracle please shepherd through CCC? On Mon, Feb 9, 2015 at 4:51 PM, Jeremy Manson wrote: > Thanks for taking a look, Staffan. Sorry about the delay. I've gone > ahead and made a test: > > h

Re: 8007142: Add utility classes for writing better multiprocess tests in jtreg

I don't have time for a detailed review, but I have some high-level comments. A lot of this is good functionality that should be provided in the jdk proper, notably getting process ids and manipulating process output (a higher level interface to ProcessBuilder). See the test ProcessBuilder/Basic

Re: 8007142: Add utility classes for writing better multiprocess tests in jtreg

[ email address fail: jdk-core-libs-dev_ww_...@oracle.com] On Wed, Jan 30, 2013 at 12:36 PM, Martin Buchholz wrote: > I don't have time for a detailed review, but I have some high-level > comments. > > A lot of this is good functionality that should be provided in the jdk &g

Re: 8008662: Add @jdk.Supported to JDK-specific/supported API

On Thu, Feb 21, 2013 at 6:16 PM, Joe Darcy wrote: > > However, the com.sun.* subpackages are a mix of APIs that are supported as > described above as well as APIs that are not supported. I was under the impression that the general rule was that all of com.sun.* fell under the "jdk supported" um

Re: 8008662: Add @jdk.Supported to JDK-specific/supported API

Hi Joe, On Fri, Feb 22, 2013 at 11:19 AM, Joe Darcy wrote: > > Should third-party vendor extensions that are "supported" for public use > by the third-party use jdk.Supported? > > > No; as I envision it, the jdk.Supported annotation is only meant to convey > supported-ness in the JDK of parts o

Re: Need reviewer: jmap -permstat

ass metadata >>in PermGen which "jmap -permstat" misses. >> >> In a small test, the "jmap -permstat" command reports only about >> 50-60% of the permgen memory usage (compared to the actual usage of >> permgen based on what the "jmap&qu

Re: Need reviewer: jmap -permstat

On Wed, Jul 30, 2008 at 11:34 AM, Daniel D. Daugherty <[EMAIL PROTECTED]> wrote: > Hey Martin, > > > Martin Buchholz wrote: > > On Tue, Jul 29, 2008 at 3:51 PM, Daniel D. Daugherty > <[EMAIL PROTECTED]> wrote: > > > This patch should be do

Invalid JCK test case gcpl00104.c

Executive summary: Invalid test case; please file a JCK bug and add to the JCK exclude list. Whiile running the JCK, we had random crashes due to memory corruption in the JCK test JCK-runtime-6b/tests/vm/jvmti/GetConstantPool/gcpl001/gcpl00104/gcpl00104.c The test suffers from multiple memory cor

Re: Invalid JCK test case gcpl00104.c

Thanks! Martin On Tue, Nov 11, 2008 at 12:02, Yuri Gaevsky <[EMAIL PROTECTED]> wrote: > Hi, Martin. > > Several months ago we excluded this test from JCK6b due to reasons you've > described. > > Thanks, > -Yuri > > Martin Buchholz wrote: >> >> E

Re: JVMTI OOM handling when arrays / objects are too large

ows an > exception if it doesn't see "PASS" in the output. > > Jeremy > > On Sun, Jun 7, 2009 at 12:31 PM, Tim Bell wrote: > > Hi Jeremy > >> > >> Martin Buchholz tells me that three things have to happen to get a patch > >> in: > &

Re: JVMTI OOM handling when arrays / objects are too large

st and fix - file one (or two?) "real" bugs or implement bugtraq-bugzilla-bridge very soon. It's non-traditional to have fixes cross the hotspot/jdk barrier, but this was the easiest way to write a test case. Martin On Mon, Jun 8, 2009 at 11:41, Martin Buchholz wrote: > The

Re: JVMTI OOM handling when arrays / objects are too large

from the jdk repo before committing changes to MASTER. Martin On Sat, Jun 13, 2009 at 10:18, Tim Bell wrote: > Martin Buchholz wrote: > >> I've called my own bluff and implemented a test case for this >> http://cr.openjdk.java.net/~martin/jvmti-oom/<http://cr.openjdk.java.ne

Re: JVMTI OOM handling when arrays / objects are too large

27;m not sure that is the right thing to do. Even assuming > it is the right thing to do, this may impact some tests as it now generates > additional JVMTI events. > > David Holmes > > Martin Buchholz said the following on 06/15/09 05:37: > >> I've polished th

Re: JVMTI OOM handling when arrays / objects are too large

The resolution of this is still uncertain. We have one approval I think, but all of the maintainers have expressed reluctance at making this change. I continue to agree with Jeremy and be in favor of making this change, but it's no big deal either way. Perhaps Alan's opinion is authoritative, since

Re: JVMTI OOM handling when arrays / objects are too large

Alright, I have a new simple version of the hotspot part of the jvmti-oom fix that should make Alan happy. ...Except for the usual problem that the code is screaming for a bit of refactoring, and it's not quite clear what file and function name it should be refactored to. I'll do the easy refacto

Re: JVMTI OOM handling when arrays / objects are too large

On Sun, Jun 28, 2009 at 09:18, Alan Bateman wrote: > > I meant to ask, but did you consider adding a test in the hotspot > repository rather than updating the ProcessBuilder test in the jdk > repository? I realize its a bit of extra work to do this. > Obviously the test "belongs" in the hotspot

Re: JVMTI OOM handling when arrays / objects are too large

Thanks, Martin > > > And as Alan suggested, as I'm not an official runtime member these days, > someone from runtime should also "rubber stamp" this. > > Thanks, > David > > Martin Buchholz said the following on 06/28/09 09:58: > >> Alrigh

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

On Tue, Sep 1, 2009 at 01:29, Ulf Zibis wrote: > Martin, > > I like how you have enhanced javadoc for Character class. > > Some coments: > - You more like uppercased hex literals, so we are 2. :-) I like consistency more than I like either uppercase or lowercase. > > - you have mixed value an

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

On Wed, Sep 2, 2009 at 01:07, Ulf Zibis wrote: > Am 02.09.2009 05:21, Martin Buchholz schrieb: > > > > On Tue, Sep 1, 2009 at 01:29, Ulf Zibis wrote: > > > {...@code is now the preferred way. I tried to modify the methods I changed, > but didn't try to chang

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

On Wed, Sep 2, 2009 at 09:40, David M. Lloyd wrote: > On 09/02/2009 11:27 AM, Martin Buchholz wrote: > >> On Wed, Sep 2, 2009 at 01:07, Ulf Zibis > ulf.zi...@gmx.de>> wrote: >>Am 02.09.2009 05:21, Martin Buchholz schrieb: >> >>>On Tue, Sep 1, 200

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

On Wed, Sep 2, 2009 at 12:46, Ulf Zibis wrote: > Am 02.09.2009 19:11, David M. Lloyd schrieb: >> >> On 09/02/2009 12:03 PM, Martin Buchholz wrote: >>> >>> On Wed, Sep 2, 2009 at 09:40, David M. Lloyd >> <mailto:david.ll...@redhat.com>> wrote: >&g

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

On Wed, Sep 2, 2009 at 14:58, Ulf Zibis wrote: > Am 02.09.2009 22:29, Martin Buchholz schrieb: > Doesn't {...@code "t\u005Cu0131tle"} work too ? I think so. This would make it easier to globally replace with {...@code. Here's a bit of Emacs Lisp to get yo

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

Thu, Sep 3, 2009 at 06:22, Ulf Zibis wrote: > > > Am 02.09.2009 22:29, Martin Buchholz schrieb: >> >> On Wed, Sep 2, 2009 at 12:46, Ulf Zibis wrote: >> >>> >>> Am 02.09.2009 19:11, David M. Lloyd schrieb: >>> >>>> >>>> On 0

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

On Thu, Sep 3, 2009 at 12:51, Ulf Zibis wrote: > Am 03.09.2009 20:10, Martin Buchholz schrieb: > I like to finish the Character class and file the changes via patch on > https://bugs.openjdk.java.net. So I would be happy If you could answer my > question, if replacing all occurrenc

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

On Thu, Sep 3, 2009 at 18:37, Ulf Zibis wrote: > Am 04.09.2009 00:15, Martin Buchholz schrieb: > In Character class you have inserted a typo: '\u007f'" at method > valueOf(char) (the additional " ) When you say "you", I assume you are using the "roya

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

Joe, here's a fix for the stray double quote. I've used {...@code with \u005C with the hope of making Ulf happy. As usual, we'll need bug filed, etc... diff --git a/src/share/classes/java/lang/Character.java b/src/share/classes/java/lang/Character.java --- a/src/share/classes/java/lang/Character

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

On Fri, Sep 4, 2009 at 02:14, Ulf Zibis wrote: > Oops sorry, I only recognized javadoc update from 1.6.0_14 to 1.7.0 b70, Do you know about "hg blame" ?

Re: Review request for 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to java.net.ConnectException

On Fri, Sep 4, 2009 at 12:26, Andrew John Hughes wrote: > If the Windows build is Cygwin based, it should even be usable there > -- albeit very slowly if my memories of Cygwin-based configure are > anything to go by. Speed is one problem. A bigger problem is that the JDK is not (yet) a Cygwin ap

Don't check gids of files against primary gid of java process

Hi serviceability/ptrace/attach team, This is a bug report with fix. This involves changes to both hotspot and jdk repos, and to platform-specific code that is completely untested, which makes it particularly difficult to integrate, so I'm hoping a serviceability engineer at Sun will take over th

Re: Need reviewers, jdk7 testing changes

On Mon, Dec 7, 2009 at 13:43, Tim Bell wrote: >>    java/util/Collection/MOAT.java > > It is a shame we have to exclude Martin's MOAT.java (Mother Of All Tests) > The comment shows the test failing on Solaris 10 x86, but you exclude > it on generic-all You cannot exclude the Mother Of All Tests.

Re: Need reviewers, jdk7 testing changes

On Mon, Dec 7, 2009 at 23:30, Martin Buchholz wrote: > You cannot exclude the Mother Of All Tests. > This is non-negotiable. More seriously... It's very difficult to manage creeping failures in regression tests. In theory, the process is supposed to prevent regression test failure

Re: Need reviewers, jdk7 testing changes

On Tue, Dec 8, 2009 at 16:42, Kelly O'Hair wrote: >> In theory, the process is supposed to prevent >> regression test failures from ever creeping in - that's the whole point. >> When they do (inevitably) creep in, >> they are supposed to be aggressively targeted. >> A gatekeeper demonstrates the

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

Xueming, I believe you still owe me a review and bug filed for http://cr.openjdk.java.net/~martin/webrevs/openjdk7/javadoc-unicode-escapes/ Martin On Wed, Sep 2, 2009 at 13:29, Martin Buchholz wrote: > On Wed, Sep 2, 2009 at 12:46, Ulf Zibis wrote: >> Am 02.09.2009 19:11, David

Re: hg: jdk7/tl/jdk: 6860431: Character.isSurrogate(char ch)

On Wed, Mar 24, 2010 at 10:22, Xueming Shen wrote: > > CR 6937842 Created, P4 java/classes_lang Unreadable \u in javadoc Thanks. > The change fine. But maybe it would be better to "escape" the \u20ac as > well, instead of > simply deleting them. Not a big deal. I prefer to leave them out, b

Re: Code Review for WeakReference leak in the Logging API (6942989)

On Fri, Jun 11, 2010 at 14:46, Daniel D. Daugherty wrote: > Jeremy, > > I'm definitely interested in learning about your approach to this issue. Here's the patch against openjdk6 by Jeremy. http://cr.openjdk.java.net/~martin/WeakLogger-jeremymanson.patch (It would take a bit of merging to port to

Re: [PATCH] JDK-8025886: Replace [[ and == bash extensions in tests

affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > > Regards, > Sergei > > On Mon, 10 Dec 2018 at 22:27, Martin Buchholz wrote: > >> I don't know if there's an official policy on how ultra-portable

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

Maybe you just need to ask gcc to use a more modern -std=... It might reasonably be defaulting to gnu89 https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu On Thu, May 16, 2019 at 3:25 PM David Holmes wrote: > On 16/05/2019 11:41 pm, A

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

On Thu, May 16, 2019 at 4:05 PM David Holmes wrote: > On 17/05/2019 8:57 am, Martin Buchholz wrote: > > Maybe you just need to ask gcc to use a more modern -std=... > > It might reasonably be defaulting to gnu89 > > > https://stackoverflow.com/questions/14737104/what-i

Re: RFR: jsr166 integration 2019-09

We now have a fix-up integration that removes all the previously excluded tests from their exclude lists. https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166 refresh https://cr.openjdk.java.net/~

Re: RFR: jsr166 integration 2019-09

Holmes wrote: > > Hi Martin, > > > > That all seems fine to me. > > > > Thanks, > > David > > > > On 24/09/2019 3:43 am, Martin Buchholz wrote: > >> We now have a fix-up integration that removes all the previously > >> excluded tests

Re: RFR: jsr166 integration 2019-09

On Mon, Sep 23, 2019 at 11:08 PM David Holmes wrote: > Except when I run it through our test system ReservedStackTest is still > failing :( > > I tested it initially when Fred proposed it and that went fine. It also > passes for me locally on Linux. > I committed the changes other than for @Rese

Re: RFR (XS): 8232182: RedefineNestmateAttr/TestNestmateAttr.java failes due to ObjectCollectedException

A slightly cleaner way to do this is probably via try { ... } finally { reachabilityFence(topLevelHostA); } instead of a static field On Mon, Oct 14, 2019 at 12:15 AM David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8232182 > webrev: http://cr.openjdk.java.net/~dholmes/82321

Re: RFR: JDK-8229829: java/lang/management/ThreadMXBean/Locks.java fails with java.lang.RuntimeException: Thread WaitingThread is at WAITING state but is expected to be in Thread.State = WAITING

Looks good to me. On Wed, May 13, 2020 at 5:55 PM Alex Menkov wrote: > > Hi all, > > Please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8229829 > webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/Locks_waiting/webrev/ > > The fix adds handling for WAITING (and for consistency

  1   2   >