Re: RFR: 8172842 Invoke lldb with --batch from failure handler

Thanks Erik! > On 16 Jan 2017, at 11:48, Erik Joelsson wrote: > > Looks good to me. > > /Erik > > > On 2017-01-16 09:24, Staffan Larsen wrote: >> When the failure handler invokes lldb to create a core it looks something >> like this: >> >> l

Re: RFR: 8172842 Invoke lldb with --batch from failure handler

Thanks Dmitry! > On 16 Jan 2017, at 09:43, Dmitry Samersoff > wrote: > > Staffan, > > Looks OK to me. > > -Dmitry > > > On 2017-01-16 11:24, Staffan Larsen wrote: >> When the failure handler invokes lldb to create a core it looks something >&

RFR: 8172842 Invoke lldb with --batch from failure handler

When the failure handler invokes lldb to create a core it looks something like this: lldb -o 'attach %p' -o 'process save-core core.%p' -o 'detach' -o 'quit' However if the attach command fails, the rest of the commands - including 'quit' - are not being run. This means the lldb process is hu

Re: RFR: 8172709 Upgrade to jtreg 4.2 b05

> On 12 Jan 2017, at 12:51, Alan Bateman wrote: > > > > On 12/01/2017 10:43, Staffan Larsen wrote: >> jtreg 4.2 b05 was recently promoted with some important fixes. Please review >> the change below to upgrade jdk9-dev to the new version. I have run >> jdk-

RFR: 8172709 Upgrade to jtreg 4.2 b05

jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. Thanks, /Staffan diff --git a/common/co

Re: RFR: 8171366 macOS: Do not run failure handler commands that require Developer mode access

Thanks! > On 16 Dec 2016, at 19:45, Igor Ignatyev wrote: > > Looks good to me. > > Thanks, > — Igor > >> On Dec 16, 2016, at 5:10 PM, Staffan Larsen >> wrote: >> >> Good point. New webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.01/

Re: RFR: 8171366 macOS: Do not run failure handler commands that require Developer mode access

rwise I think this looks ok. > > /Erik > > > On 2016-12-16 14:45, Staffan Larsen wrote: >> The failure handler (test/failure_handler) runs a number of commands when it >> detects a timeout in one of the tests. On OS X some of these commands >> require "Develo

RFR: 8171366 macOS: Do not run failure handler commands that require Developer mode access

The failure handler (test/failure_handler) runs a number of commands when it detects a timeout in one of the tests. On OS X some of these commands require "Developer mode" (like getting a core file). If "Developer mode" is not enabled, the tools will open a modal dialog. This is problematic when

Re: RFR: JDK-8170392: JDK-8031567 broke builds from source bundles

Looks better to me! /Staffan > On 28 Nov 2016, at 13:52, Erik Joelsson wrote: > > Thanks, but unfortunately, the build breaks again later. Updated webrev in > place. > > /Erik > > > On 2016-11-28 13:49, Staffan Larsen wrote: >> Looks good to me! >> &

Re: RFR: JDK-8170392: JDK-8031567 broke builds from source bundles

Looks good to me! Thanks, /Staffan > On 28 Nov 2016, at 13:41, Erik Joelsson wrote: > > In JDK-8031567, the format for storing source revision information for use in > builds from source bundles changed. The behavior when building without either > mercurial or the stored revision information

Re: RFR(S): 8168483 Remove jtreg timeout handler timeout

Thank David! > On 22 Oct 2016, at 02:24, David Holmes wrote: > > Looks fine. > > Thanks, > David > > On 21/10/2016 11:24 PM, Staffan Larsen wrote: >> When we run jtreg in the hotspot, jdk and nashorn folders we run it with the >> timeout handler found unde

Re: RFR(S): 8168483 Remove jtreg timeout handler timeout

Thanks Tim! > On 22 Oct 2016, at 05:21, Tim Bell wrote: > > Looks good to me as well. > > Tim > > On 10/21/16 17:24, David Holmes wrote: >> Looks fine. >> >> Thanks, >> David >> >> On 21/10/2016 11:24 PM, Staffan Larsen wrote: >>

RFR(S): 8168483 Remove jtreg timeout handler timeout

When we run jtreg in the hotspot, jdk and nashorn folders we run it with the timeout handler found under test/failure_handler. This handler is sometimes very slow (since it creates core files of hung processes). The handler is also very good at handling its own timeouts. The default implementa

Re: RFR: 8168414 Various timeouthandler fixes

> On 21 Oct 2016, at 06:10, David Holmes wrote: > > On 20/10/2016 11:44 PM, Staffan Larsen wrote: >> >>> On 20 Oct 2016, at 15:41, David Holmes wrote: >>> >>> On 20/10/2016 11:27 PM, Staffan Larsen wrote: >>>> When looking for s

Re: RFR(s): 8168409 Update list of tools run by the jtreg timeouthandler

off > wrote: > > Staffan, > > Could you add > jhsdb jstack --mixed --pid > to get mixed stack trace when it possible? > > -Dmitry > > On 2016-10-20 14:42, Staffan Larsen wrote: >> Please review this small update to the list of tools that the jtreg &g

Re: RFR(s): 8168409 Update list of tools run by the jtreg timeouthandler

Thanks Marcus for all three reviews! > On 20 Oct 2016, at 15:50, Marcus Larsson wrote: > > Hi, > > >> On 10/20/2016 01:42 PM, Staffan Larsen wrote: >> Please review this small update to the list of tools that the jtreg >> timeouthandler runs when a timeou

Re: RFR: 8168414 Various timeouthandler fixes

> On 20 Oct 2016, at 15:41, David Holmes wrote: > > On 20/10/2016 11:27 PM, Staffan Larsen wrote: >> When looking for some timeout handler problems I found a few things that >> should be fixed: >> >> * Strange use of Thread.currentThread().interrupt() &

RFR: 8168414 Various timeouthandler fixes

When looking for some timeout handler problems I found a few things that should be fixed: * Strange use of Thread.currentThread().interrupt() * Add logging for timeouts * Milliseconds sometimes printed as microseconds or nanoseconds * Should use destroyForcibly() to terminate processes * No

RFR(XS): 8168412 Reduce buffering in jtreg timeouthandler

Hi, Please review this small patch to the jtreg timeouthandler to remove some buffering. We create PrintWriters in a couple of places and this patch adds the second parameter to the constructor to enable automatic flushing of the PrintWriter. webrev: http://cr.openjdk.java.net/~sla/8168412/web

RFR(s): 8168409 Update list of tools run by the jtreg timeouthandler

Please review this small update to the list of tools that the jtreg timeouthandler runs when a timeout is hit. This change removes all calls to the old SA-tools and instead uses Diagnostic Commands to gather the same information. The possible drawback is that Diagnostic Commands do not work on

Re: RFR (XS): 8167354: Missing jtreg output when run using langtools makefiles

.txt as the extension, instead of > something more conventional, like .log? > > -- Jon > > On 10/10/2016 04:35 AM, Marcus Larsson wrote: >> Thanks Staffan! >> >> >> On 10/10/2016 01:30 PM, Staffan Larsen wrote: >>> Looks good! >>> >&g

Re: RFR (XS): 8167354: Missing jtreg output when run using langtools makefiles

Looks good! Thanks, /Staffan > On 10 Oct 2016, at 12:46, Marcus Larsson wrote: > > Hi, > > Please review the following small patch to make the output from jtreg for > langtools testing through make to be saved in output.txt, just like in other > repos. > > Webrev: > http://cr.openjdk.java.n

Re: Query on developing OpenJDK with IntelliJ

See if this email thread helps you out: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-April/004136.html http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004173.html /Staffan > On 10 sep. 2016, at 17:11, Jonathan Bluett-Duncan > wrote: > > Hi all, > > I have a question regardin

Re: RFR: 8157605 Can't set both CONCURRENCY and EXTRA_JTREG_OPTIONS when running tests

Thanks! > On 24 maj 2016, at 11:58, Erik Joelsson wrote: > > Looks good. > > /Erik > > On 2016-05-23 20:14, Staffan Larsen wrote: >> This does not work: >> >> $ cd test >> $ make jtreg_tests CONCURRENCY=10 EXTRA_JTREG_OPTIONS=-k:\!headf

Re: RFR: 8157605 Can't set both CONCURRENCY and EXTRA_JTREG_OPTIONS when running tests

> On 24 maj 2016, at 04:04, Jonathan Gibbons > wrote: > > It seems anomalous that langtools is missing, but perhaps that's a different > problem. Langtools is already doing things this way. That was the only place things worked! > > -- Jon > > On 05/23/201

Re: RFR: 8157605 Can't set both CONCURRENCY and EXTRA_JTREG_OPTIONS when running tests

Thanks Tim! > On 24 maj 2016, at 03:46, Tim Bell wrote: > > Staffan: > >> This does not work: >> >> $ cd test >> $ make jtreg_tests CONCURRENCY=10 EXTRA_JTREG_OPTIONS=-k:\!headful >> >> I can specify either CONCURRENCY or EXTRA_JTREG_OPTIONS, but not both. >> >> Please review the fix below:

RFR: 8157605 Can't set both CONCURRENCY and EXTRA_JTREG_OPTIONS when running tests

This does not work: $ cd test $ make jtreg_tests CONCURRENCY=10 EXTRA_JTREG_OPTIONS=-k:\!headful I can specify either CONCURRENCY or EXTRA_JTREG_OPTIONS, but not both. Please review the fix below: bug: https://bugs.openjdk.java.net/browse/JDK-8157605

Re: RFR: JDK-8156658 Common way to run jtreg tests

be. I didn’t want to change existing behavior in this patch. Which >> one do you prefer? > > The code from jdk/test/Makefile (jaxp uses the same code). > > -Dmitry > > > On 2016-05-10 16:06, Staffan Larsen wrote: >> >>> On 10 maj 2016, at 14:46, Dmitry Samersof

Re: RFR: JDK-8156658 Common way to run jtreg tests

_PLATFORM_BUILD_ROOT = $(ABS_OUTPUTDIR) > 91 ABS_TEST_OUTPUT_DIR := > $(ABS_PLATFORM_BUILD_ROOT)/testoutput/$(UNIQUE_DIR) > > -Dmitry > > On 2016-05-10 15:21, Staffan Larsen wrote: >> For test automation purposes we want a way to run jtreg tests for the >> different c

Re: RFR: JDK-8156658 Common way to run jtreg tests

Thanks Erik! > On 10 maj 2016, at 14:39, Erik Joelsson wrote: > > Looks good to me. > > /Erik > > On 2016-05-10 14:21, Staffan Larsen wrote: >> For test automation purposes we want a way to run jtreg tests for the >> different components (jdk, langtools, jax

RFR: JDK-8156658 Common way to run jtreg tests

For test automation purposes we want a way to run jtreg tests for the different components (jdk, langtools, jaxp, hotspot, nashorn) in a unified way from the command line. We also want each component to be able to define how jtreg is invoked (problemlists, concurrency, agentvm, ...). There is a

Re: RFR:

> On 13 jan. 2016, at 16:11, Erik Helin wrote: > > On 2016-01-13, Staffan Larsen wrote: >> Looks good! > > Thanks! > > On 2016-01-13, Staffan Larsen wrote: >> (Although /build//testoutput/hotspot/ could be even better?) > > Doesn't really matter to

Re: RFR:

Looks good! (Although /build//testoutput/hotspot/ could be even better?) Thanks, /Staffan > On 13 jan. 2016, at 15:01, Erik Helin wrote: > > Hi all, > > this patch changes the output directory for hotspot's jtreg tests when > run via the top-level Makefile targets such as > `make test-hotspo

Re: Running native code test

Why is it a problem having executables and libraries in the same directory? It was a design choice we made to make things simpler. /Staffan > On 3 dec. 2015, at 18:13, Carsten Varming wrote: > > Dear David, > > I think I finally understand what is going on now. :) > > The command "make build

Re: RFR 8043138: Attach API should not require jvmstat rmi protocol

> On 24 nov. 2015, at 17:03, Jaroslav Bachorik > wrote: > > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8043138 > Webrevs: > * top level: http://cr.openjdk.java.net/~jbachorik/8043138/webrev.00/top > * jdk: http://cr.openjdk.java.net/~jbachorik/8043

Re: RFR: JDK-8142336: Convert the SA agent build to modular build-infra makefiles

Looks good! Thanks, /Staffan > On 17 nov. 2015, at 10:47, Erik Joelsson wrote: > > Hello, > > I realized that there already was a mechanism for controlling the inclusion > of SA from configure. Unfortunately, this variable is not picked up by any > makefile currently. I changed the explicit

Re: CLANG special case

When we upgraded to clang 6.3, I verified that the problem still existed. See: https://bugs.openjdk.java.net/browse/JDK-8077364 which has pointers to the two tests that fail without the workaround. /Staffan > On 6 okt 2015, at 17:38, Phil Race

Re: RFR: 8076470 - JEP 240: Remove the JVM TI hprof Agent

Thanks Erik! > On 10 aug 2015, at 12:52, Erik Joelsson wrote: > > Looks good to me. > > /Erik > > On 2015-08-07 08:57, Staffan Larsen wrote: >> Please review the following changes to remove the hprof JVMTI agent. There >> are changes in three different repo

Re: RFR: 8076470 - JEP 240: Remove the JVM TI hprof Agent

> On 9 aug 2015, at 05:13, Mandy Chung wrote: > > >> On Aug 6, 2015, at 11:57 PM, Staffan Larsen >> wrote: >> >> Please review the following changes to remove the hprof JVMTI agent. There >> are changes in three different repositories. All tests

Re: RFR: 8076470 - JEP 240: Remove the JVM TI hprof Agent

some of the demos (mtrace, minst, etc). But they statically link the code so the lib is no longer needed. /Staffan > > Thanks, > Serguei > > > On 8/6/15 11:57 PM, Staffan Larsen wrote: >> Please review the following changes to remove the hprof JVMTI agent. There >&g

RFR: 8076470 - JEP 240: Remove the JVM TI hprof Agent

Please review the following changes to remove the hprof JVMTI agent. There are changes in three different repositories. All tests that used the hprof agent has been removed in previous changesets. Note: This does not remove the ability of the Hotspot VM to output heap dumps in the hprof format

Re: need to build a DLL for an openjdk test

> On 4 jun 2015, at 04:33, Pete Brunet wrote: > > > On 6/3/15 8:43 PM, Pete Brunet wrote: >> Cross posting to build-dev for possible insight regarding Jon's last >> paragraph below. >> >> On 6/3/15 8:13 PM, Jonathan Gibbons wrote: >>> On 06/03/2015 04:27 PM, Pete Brunet wrote: Hi, As part

Re: need to build a DLL for an openjdk test

> On 4 jun 2015, at 07:10, David Holmes wrote: > > Peter, > > On 4/06/2015 11:43 AM, Pete Brunet wrote: >> Cross posting to build-dev for possible insight regarding Jon's last >> paragraph below. > > See jdk/make/test/JtregNative.gmk and other references to test-image. There are example tests

Re: RFR: libdt_socket: Build failed with VS2013 SP4

Looks good! Thanks, /Staffan > On 25 maj 2015, at 12:17, Erik Joelsson wrote: > > Hello, > > In Visual Studio 2013 SP4, MS decided to deprecate gethostbyname in favor of > getaddrinfo(). We now have two different libraries using this function. In > JDK-8077422 I added a workaround for libhpr

Re: Issues with dtrace enabled in OpenJdk 9

reference to `__dtrace_hotspot___class__loaded' > compileBroker.o: In function > `CompileBroker::invoke_compiler_on_method(CompileTask*)': > /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/compiler/compileBroker.cpp:1927: > undefined reference to `__dtrace_hotspot___method__compile__

Re: Issues with dtrace enabled in OpenJdk 9

Note that SDT and dtrace4linux are different things. As far as I know, no one has tried dtrace4linux with Hotspot so you are in uncharted territories. SDT should work (if installed). Oracle Linux also has an implementation of Dtrace that I think is different from dtrace4linux. This is also untes

RFR: 8079360 AttachProviderImpl could not be instantiated

This is another library that needs to be compiled with -DPSAPI_VERSION=1 due to the recent Windows compiler upgrade. I have also fixed a better error message that prints the underlaying exception if something like this happens again. webrev: http://cr.openjdk.java.net/~sla/8079360/webrev.00/

Re: RFR: 8079345: After 8079248 fixed JDK still fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found"

> On 6 maj 2015, at 11:46, Magnus Ihse Bursie > wrote: > > On 2015-05-06 11:39, Erik Joelsson wrote: >> This one looks better. Sorry for not spotting the problem in the previous >> review. >> >> /Erik >> >> On 2015-05-06 11:24, Staffan Lar

RFR: 8079345: After 8079248 fixed JDK still fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found"

My fix for 8079248 was broken, so here is a new attempt. I intend to push this directly to jdk9/hs since that is where 8079248 was pushed. bug: https://bugs.openjdk.java.net/browse/JDK-8079345#comment-13638237 webrev: http://cr.openjdk.java.net/~sla/8079345/webrev.00

Re: RFR: JDK-8077422: hprof agent: Build failed with VS2013 Update 4

Looks good! Thanks, /Staffan > On 4 maj 2015, at 15:46, Erik Joelsson wrote: > > Hello, > > This bug has been marked as won't fix since the code it affects is going to > be removed. However, until that removal happens, we can't build using VS2013 > SP4. I'm in the process of updating the com

Re: RFR: JDK-8079248 JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found"

Thanks for the reviews - the fix is now in the JPRT queue. /Staffan > On 4 maj 2015, at 11:11, Erik Joelsson wrote: > > > On 2015-05-04 10:25, Staffan Larsen wrote: >>> On 4 maj 2015, at 09:54, Magnus Ihse Bursie >>> wrote: >>> >>&g

Re: RFR: JDK-8079248 JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found"

all versions of Windows (there is no “legacy version”). What differs is that it is linked against different names in different libs for different versions of Windows. So from a source code perspective there is no difference, but from a build perspective there is. /Staffan > > /Magnus &

Re: RFR: JDK-8079248 JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found"

hanks, > David > > On 4/05/2015 4:52 PM, Staffan Larsen wrote: >> This is a P1 bug that surfaced when changes from jdk9/dev and jdk9/hs-rt met >> in jdk9/hs. In this case the windows compiler upgrades in jdk9/dev met >> changes in jdk9/hs-rt that moved a call to GetPr

RFR: JDK-8079248 JDK fails with "jdk\\bin\\management_ext.dll: The specified procedure could not be found"

This is a P1 bug that surfaced when changes from jdk9/dev and jdk9/hs-rt met in jdk9/hs. In this case the windows compiler upgrades in jdk9/dev met changes in jdk9/hs-rt that moved a call to GetProcessMemoryInfo from management.dll to management_ext.dll. With the compiler upgrades PSAPI_VERSION=

Re: RFR: JDK-8074016 Add convenient way of adding custom test targets to hotspot's test makefile

Looks good! Thanks, /Staffan > On 27 apr 2015, at 12:25, Ingemar Aberg wrote: > > Please review this small fix to hotspot's test makefile > > The file hotspot/test/Makefile provides '-include $(ALT_MAKE)/Makefile' close > to the top (before most variables are set). > Move that line to after t

RFR: 8066757 Can't build 'images' with --disable-zip-debug-info on OS X after jigsaw m2 merge

Please review this fix for using --disable-zip-debug-info when compiling the images target. OS X stores symbol information in a .dylib file inside a .dSYM directory and that file should not be stripped, so this patch prunes the tree at the .dSYM directory. bug: https://bugs.openjdk.java.net/br

RFR: 8076473 Remove the jhat code and update makefiles

Please review this change to remove the jhat tool. I will not push this change until the tests have been removed (see a different review thread). JEP: https://bugs.openjdk.java.net/browse/JDK-8059039 bug: https://bugs.openjdk.java.net/browse/JD

RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk 9

Please review these small changes to support an addition of closed code to the java.instrument module. webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ Thanks, /Staffan

Re: RFR

Looks good! Thanks, /Staffan > On 7 apr 2015, at 17:15, Erik Joelsson wrote: > > Hello, > > When upgrading the toolchain to VS2013, management.dll stopped working on > certain Windows hosts. I've identified this to be related to the call to > GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1

RFR: JDK-8075056 Remove Version.java.template from jconsole

The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime. bug: https://bugs.openjdk.java.net/browse/JDK-8075056 webrev: http

Re: RFR: 8058470 [jconsole] VM Summary Tab is blank for JDK9's jconsole.

copy the properties files instead of cleaning them, especially if > there are no or few comments in them. > > /Erik > > On 2015-03-04 20:21, Staffan Larsen wrote: >> The problem is that the makefiles do "cleanup" of the resource files, >> accidentally deletin

RFR: 8058470 [jconsole] VM Summary Tab is blank for JDK9's jconsole.

The problem is that the makefiles do "cleanup" of the resource files, accidentally deleting half of some strings. In this case GC_INFO=Name = ''{0}'', Collections = {1,choice,-1#Unavailable|0#{1,number,integer}}, Total time spent = {2} becomes GC_INFO=Name \= ''{0}'', Collections \= {1,choi

Re: RFR: JDK-8072842 Add support for building native JTReg tests

As far as I can tell (I’m not a makefile expert) this looks good. Thanks, /Staffan > On 25 feb 2015, at 12:21, Magnus Ihse Bursie > wrote: > > On 2015-02-11 13:08, Staffan Larsen wrote: >> >>>>>>>> Okay so if I just cd into hotspot/test and use the M

Re: RFR: JDK-8072842 Add support for building native JTReg tests

> On 11 feb 2015, at 12:15, David Holmes wrote: > > On 11/02/2015 8:36 PM, Staffan Larsen wrote: >> >>> On 11 feb 2015, at 09:39, David Holmes wrote: >>> >>> On 11/02/2015 6:34 PM, Staffan Larsen wrote: >>>> >>>>> On 1

Re: RFR: JDK-8072842 Add support for building native JTReg tests

> On 11 feb 2015, at 09:39, David Holmes wrote: > > On 11/02/2015 6:34 PM, Staffan Larsen wrote: >> >>> On 11 feb 2015, at 09:27, Magnus Ihse Bursie >>> mailto:magnus.ihse.bur...@oracle.com>> >>> wrote: >>> >>> On 2015-02-11

Re: RFR: JDK-8072842 Add support for building native JTReg tests

> On 11 feb 2015, at 09:27, Magnus Ihse Bursie > wrote: > > On 2015-02-11 09:23, David Holmes wrote: >> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote: >>> On 2015-02-11 02:35, David Holmes wrote: Hi Magnus, On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote: > Here is an add

Re: RFR: JDK-8072842 Add support for building native JTReg tests

> On 10 feb 2015, at 15:23, Magnus Ihse Bursie > wrote: > > Here is an addition to the build system, that will compile native libraries > and executables and make them available for JTReg tests written in Java. > > This patch is the result of the work (in serial, most

Re: RFR: JDK-8067479: verify-modules fails in bootcycle build

SA changes look ok - the IA64 stuff isn’t needed as we don’t support it and will remove it. /Staffan > On 19 jan 2015, at 09:29, Erik Joelsson wrote: > > Hello, > > Any chance someone from serviceability could take a look at this? > > /Erik > > On 2015-01-12 03:45, David Holmes wrote: >> Hi

Re: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT

> On 5 dec 2014, at 10:22, David Holmes wrote: > > On 5/12/2014 6:11 PM, Staffan Larsen wrote: >> Running with longer timeouts on fast machines makes the testing less >> responsive (if a test is on its way to timeout it takes longer for us to >> detect it). Ideall

Re: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when run using JPRT

Running with longer timeouts on fast machines makes the testing less responsive (if a test is on its way to timeout it takes longer for us to detect it). Ideally the timeout factor should be tuned according to the machine type we are running on. I’m not sure that is possible, though? > On 5 dec

Re: build warnings

These are warnings in the java.desktop module. I don’t know what the appropriate email list is for java.desktop discussions, but perhaps bringing it up there would be the right thing to do? /Staffan > On 2 dec 2014, at 22:59, Jonathan Gibbons wrote: > > Build folk, > > The build has always g

Re: Building openjdk 8 on Mac OS X

From which exact branch is the code cloned? I know there were some issues with #includes in MacosxDebuggerLocal.m, but they should have been cleaned up in jdk8u-dev by now /Staffan > On 6 nov 2014, at 12:45, Manas Thakur wrote: > > Thanks for the reply Magnus. Here are the error logs that get

Re: RFR JDK-8061610 (XXS): "make test" broken for hotspot test targets

This one looks like it has already been pushed by Erik. /Staffan On 21 okt 2014, at 13:50, David Simms wrote: > Gidday, > > Standing at the top of the JDK running "make test TEST=hotspot_all" is > broken, there's a minor typo in "test/Main.gmk" using "JDK_OUTPUT_DIR" > instead of "JDK_OUTPUT

Re: Review request: 8055230: Rename attach provider implementation class

There are some differences in the AttachProvideImpl files. Most notably the windows version is very different. Linux, Bsd and Aix are the same. The Solaris version has a minor difference in the “public String type()” implementation. The Linux, Bsd, Aix and Solaris versions could probably be uni

Re: Review request: 8055230: Rename attach provider implementation class

Ahh. The simplicity! Looks good! Thanks, /Staffan On 26 aug 2014, at 06:29, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ > > This patch renames the class name of attach provider implementation class > to be the same for all platforms. This simplif

Re: RFRF: 8043936 Drop HPROF as demo, keep as HPROF agent shipped with JDK

On 25 aug 2014, at 16:15, Alan Bateman wrote: > On 25/08/2014 14:35, Staffan Larsen wrote: >> Please review the following change to remove hprof as part of the demo >> package. Instead, the source code has been moved to the jdk.hprof.agent >> module. >> >> b

Re: RFR: JDK-8043981 Remove the JPDA demo

On 25 aug 2014, at 15:59, Alan Bateman wrote: > On 25/08/2014 14:48, Staffan Larsen wrote: >> Please review this change to remove the legacy JPDA demos. These demos are >> quite dated at this point and the included instructions are incomplete. In >> addition the exampl

RFR: JDK-8043981 Remove the JPDA demo

Please review this change to remove the legacy JPDA demos. These demos are quite dated at this point and the included instructions are incomplete. In addition the example/demo JPDA code does not fit well into the new modular structure because the source code is used for both jdb and for the demo

RFRF: 8043936 Drop HPROF as demo, keep as HPROF agent shipped with JDK

Please review the following change to remove hprof as part of the demo package. Instead, the source code has been moved to the jdk.hprof.agent module. bug: https://bugs.openjdk.java.net/browse/JDK-8043936 webrev: http://cr.openjdk.java.net/~sla/8043936/webrev.00/ Thanks, /Staffan

Re: RFR: JDK-8055352: AIX hprof should include its own copy of dladdr in porting_aix.c

I have just sent out a review request for JDK-8043936: "Drop HPROF as demo, keep as HPROF agent shipped with JDK”. That change removes hprof completely from the demos which makes the change below obsolete. So if my change is accepted, the change below is no longer needed. Thanks, /Staffan On

Re: Update compiler workarounds for Clang 6.0

I have filed https://bugs.openjdk.java.net/browse/JDK-8048298 to track this. It includes a patch to workaround it. /Staffan > On 22 aug 2014, at 12:16, Alexander Scherbatiy > wrote: > > > Hi, > > I got the following message during building the JDK 9 on Mac OS X 10.10 > Yosemity: >

Re: RFR (XS): 8042804: Support invoking Hotspot tests from top level

Looks good! Thanks, /Staffan On 9 maj 2014, at 23:32, Mikael Vidstedt wrote: > > All, > > Can I please get a review or two of the below change, which makes it possible > to invoke/run the hotspot tests from the top level test/Makefile too - much > like the jdk, langtools etc. tests. The imp

Re: Proposal: jtreg tests with native components

On 1 maj 2014, at 07:45, David Holmes wrote: > On 30/04/2014 9:39 PM, Staffan Larsen wrote: >> >> On 30 apr 2014, at 11:39, David Holmes wrote: >> >>> Hi Staffan, >>> >>> On 25/04/2014 10:02 PM, Staffan Larsen wrote: >>>> T

Re: Proposal: jtreg tests with native components

On 30 apr 2014, at 11:39, David Holmes wrote: > Hi Staffan, > > On 25/04/2014 10:02 PM, Staffan Larsen wrote: >> There are a couple of jtreg tests today that depend on native components >> (either JNI libraries or executables). These are handled in one of two ways: >&

Re: Proposal: jtreg tests with native components

On 28 apr 2014, at 20:05, Jonathan Gibbons wrote: > On 04/28/2014 10:57 AM, Staffan Larsen wrote: >> Good point. I’ve been calling the target that build the test “build-tests” >> which I’m not particularly fond of. “test-bundle” on the other hand seems to >> imply an act

Re: Proposal: jtreg tests with native components

reasonable change? Thanks, /Staffan On 25 apr 2014, at 14:02, Staffan Larsen wrote: > There are a couple of jtreg tests today that depend on native components > (either JNI libraries or executables). These are handled in one of two ways: > > 1) The binaries are pre-compiled and chec

Re: Proposal: jtreg tests with native components

On 28 apr 2014, at 19:31, Jonathan Gibbons wrote: > On 04/28/2014 01:08 AM, Staffan Larsen wrote: >> If you prefer to not use the makefile to run tests, you would have to do two >> step: first compile native tests (using the makefiles) and then run jtreg >> manually. Y

Re: Proposal: jtreg tests with native components

r/linker flags (don't think we have tests like this today though). > > Thanks for working on this :) > > Thanks, > Christian > > -Original Message- > From: jtreg-dev [mailto:jtreg-dev-boun...@openjdk.java.net] On Behalf Of > Staffan Larsen > Sent: Friday,

Re: Proposal: jtreg tests with native components

- what sort of hierarchy do the libraries end up in. >> >> I am also concerned for the developer experience. One of the >> characteristics of the jtreg design has always been that it is >> dev-friendly, meaning it is easy and fast for developers to edit a test and >> re

Re: Proposal: jtreg tests with native components

g where the compiled tests are. This does complicate things, no doubt about that. It’s hard to make it completely transparent and this is the best that I’ve been able to come up with. Other ideas are more than welcome. Thanks, /Staffan > > -- Jon > > > On 04/25/2014 05:02

Proposal: jtreg tests with native components

There are a couple of jtreg tests today that depend on native components (either JNI libraries or executables). These are handled in one of two ways: 1) The binaries are pre-compiled and checked into the repository (often inside jar files). 2) The test will try to invoke a compiler (gcc, cl, …)

Re: RFR: 8041151: More concurrent hgforest.

I ran the patch on OS X and it worked there too. Thanks! You mention “status code from subprocesses” which got me thinking of a problem I frequently run into when I have some uncommitted changes in one of the repos: ... .: searching for changes

Re: RFR [9] : get_source.sh should be more friendly to MQ

On 11 apr 2014, at 17:19, Jonathan Gibbons wrote: > Is it common to use mq in all repos of a forest? For me it is very common to be working on a fix that spans multiple repos (up to 5 different repos at times). So, yes. I like this fix, but I would be very annoyed if all my patches were appli

Re: -Wformat-nonliteral

Building with clang? https://bugs.openjdk.java.net/browse/JDK-8037816 https://bugs.openjdk.java.net/browse/JDK-8019470 /Staffan On 28 mar 2014, at 14:28, Jim Laskey (Oracle) wrote: > /Projects/jdk9-dev/hotspot/src/share/vm/utilities/debug.cpp:105:19: error: > format string is not a string l

Re: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries

Thanks Alan! On 20 mar 2014, at 19:15, Alan Bateman wrote: > On 20/03/2014 12:11, Staffan Larsen wrote: >> : >> Yes, that one was a bit messy. I cleaned it up and added some comments. Also >> remove the SCCS workarounds. >> >> http://cr.openjdk.java.net/~sla/

Re: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries

On 20 mar 2014, at 11:25, Alan Bateman wrote: > On 20/03/2014 09:13, Staffan Larsen wrote: >> >> Thanks! >> >> Still need someone to look at the actual code changes. >> >> > In webrev.01 then jdk/make/lib/ServiceabilityLibraries.gm

Re: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries

Thanks! Still need someone to look at the actual code changes. /Staffan On 20 mar 2014, at 09:49, Magnus Ihse Bursie wrote: > On 2014-03-19 17:47, Erik Joelsson wrote: >> Build part looks good! > > Build part looks good to me to. > > /Magnus >

Re: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries

On 19 mar 2014, at 17:47, Erik Joelsson wrote: > Build part looks good! Thanks. > > Don't forget to push the closed generated configure. I would have forgotten… /Staffan > > /Erik > > On 2014-03-19 15:20, Staffan Larsen wrote: >> Erik, Magnus, >>

Re: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries

o, instead of making the conditional on > OS, it should be on the new variable TOOLCHAIN_TYPE. Perhaps the variable > name should contain the word CFLAGS somewhere to make it more obvious what it > applies to. > > /Erik > > On 2014-03-19 13:30, Staffan Larsen wrote: >>

RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries

The serviceability libraries (as defined by jdk/make/lib/ServiceabilityLibraries.gmk) should be compiled with "warnings as errors". To enable this all current warnings need to be fixed. The background for this is that we recently had a bug that could have easily been avoided if we had paid att

  1   2   >