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

[Staffan Larsen]

Thanks Erik!

> On 16 Jan 2017, at 11:48, Erik Joelsson <erik.joels...@oracle.com> 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:
>> 
>> 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 hung.
>> 
>> Adding '--batch' to the command line overcomes this problem.
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> diff --git a/test/failure_handler/src/share/conf/mac.properties 
>> b/test/failure_handler/src/share/conf/mac.properties
>> --- a/test/failure_handler/src/share/conf/mac.properties
>> +++ b/test/failure_handler/src/share/conf/mac.properties
>> @@ -64,7 +64,7 @@
>>  native.core.app=bash
>>  native.core.delimiter=\0
>>  native.core.args=-c\0gcore -o ./core.%p %p || \
>> -  (DevToolsSecurity --status | grep -q enabled && lldb -o 'attach %p' -o 
>> 'process save-core core.%p' -o 'detach' -o 'quit')
>> +  (DevToolsSecurity --status | grep -q enabled && lldb --batch -o 'attach 
>> %p' -o 'process save-core core.%p' -o 'detach' -o 'quit')
>>  native.core.params.timeout=360
>>  
>> 
>>  # environment info to gather
>> 
> 

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

[Staffan Larsen]

Thanks Dmitry!

> On 16 Jan 2017, at 09:43, Dmitry Samersoff <dmitry.samers...@oracle.com> 
> 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 
>> 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 hung. 
>> 
>> Adding '--batch' to the command line overcomes this problem. 
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> diff --git a/test/failure_handler/src/share/conf/mac.properties 
>> b/test/failure_handler/src/share/conf/mac.properties
>> --- a/test/failure_handler/src/share/conf/mac.properties
>> +++ b/test/failure_handler/src/share/conf/mac.properties
>> @@ -64,7 +64,7 @@
>> native.core.app=bash
>> native.core.delimiter=\0
>> native.core.args=-c\0gcore -o ./core.%p %p || \
>> -  (DevToolsSecurity --status | grep -q enabled && lldb -o 'attach %p' -o 
>> 'process save-core core.%p' -o 'detach' -o 'quit')
>> +  (DevToolsSecurity --status | grep -q enabled && lldb --batch -o 'attach 
>> %p' -o 'process save-core core.%p' -o 'detach' -o 'quit')
>> native.core.params.timeout=360
>> 
>> # environment info to gather
>> 
> 
> 
> -- 
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

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

[Staffan Larsen]

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 hung. 

Adding '--batch' to the command line overcomes this problem. 

Thanks,
/Staffan


diff --git a/test/failure_handler/src/share/conf/mac.properties 
b/test/failure_handler/src/share/conf/mac.properties
--- a/test/failure_handler/src/share/conf/mac.properties
+++ b/test/failure_handler/src/share/conf/mac.properties
@@ -64,7 +64,7 @@
 native.core.app=bash
 native.core.delimiter=\0
 native.core.args=-c\0gcore -o ./core.%p %p || \
-  (DevToolsSecurity --status | grep -q enabled && lldb -o 'attach %p' -o 
'process save-core core.%p' -o 'detach' -o 'quit')
+  (DevToolsSecurity --status | grep -q enabled && lldb --batch -o 'attach %p' 
-o 'process save-core core.%p' -o 'detach' -o 'quit')
 native.core.params.timeout=360
 

 # environment info to gather

Re: RFR: 8172709 Upgrade to jtreg 4.2 b05

[Staffan Larsen]

> On 12 Jan 2017, at 12:51, Alan Bateman <alan.bate...@oracle.com> 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-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/conf/jib-profiles.js b/common/conf/jib-profiles.js
>> --- a/common/conf/jib-profiles.js
>> +++ b/common/conf/jib-profiles.js
>> @@ -870,7 +870,7 @@
>>  jtreg: {
>>  server: "javare",
>>  revision: "4.2",
>> -build_number: "b04",
>> +build_number: "b05",
>>  checksum_file: "MD5_VALUES",
>>  file: "jtreg_bin-4.2.zip",
>>  environment_name: "JT_HOME",
> This looks okay for infrastructure that uses this file but don't you need to 
> bump the requiredVersion in each test root to force its usage in other 
> contexts?

I don’t know if there are any tests that rely on functionality in 4.2 b05. If 
there are, we need to bump requireVersion, yes. I only know that the 
infrastructure needs 4.2 b05.

/Staffan

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

[Staffan Larsen]

Thanks!

> On 16 Dec 2016, at 19:45, Igor Ignatyev <igor.ignat...@oracle.com> wrote:
> 
> Looks good to me.
> 
> Thanks,
> — Igor
> 
>> On Dec 16, 2016, at 5:10 PM, Staffan Larsen <staffan.lar...@oracle.com> 
>> wrote:
>> 
>> Good point. New webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.01/ 
>> <http://cr.openjdk.java.net/~sla/8171366/webrev.01/>
>> 
>> Thanks!
>> 
>>> On 16 Dec 2016, at 15:05, Erik Joelsson <erik.joels...@oracle.com> wrote:
>>> 
>>> I would recommend using the -q flag to grep instead of piping to /dev/null. 
>>> Otherwise 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 "Developer mode" (like getting a core file). If "Developer mode" 
>>>> is not enabled, the tools will open a modal dialog. This is problematic 
>>>> when running automated test. The dialog will also prevent other tests from 
>>>> completing.
>>>> 
>>>> This patch changes the Failure handler to check if "Developer mode" is 
>>>> enabled before running commands that require it. It also includes the 
>>>> output of "DevToolsSecurity —status” which is used to check for “Developer 
>>>> mode”.
>>>> 
>>>> Please review the webrev below,
>>>> /Staffan
>>>> 
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8171366
>>>> webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.00/
>>> 
>> 
> 

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

[Staffan Larsen]

Good point. New webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.01/ 
<http://cr.openjdk.java.net/~sla/8171366/webrev.01/>

Thanks!

> On 16 Dec 2016, at 15:05, Erik Joelsson <erik.joels...@oracle.com> wrote:
> 
> I would recommend using the -q flag to grep instead of piping to /dev/null. 
> Otherwise 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 "Developer mode" (like getting a core file). If "Developer mode" is 
>> not enabled, the tools will open a modal dialog. This is problematic when 
>> running automated test. The dialog will also prevent other tests from 
>> completing.
>> 
>> This patch changes the Failure handler to check if "Developer mode" is 
>> enabled before running commands that require it. It also includes the output 
>> of "DevToolsSecurity —status” which is used to check for “Developer mode”.
>> 
>> Please review the webrev below,
>> /Staffan
>> 
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8171366
>> webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.00/
> 

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

[Staffan Larsen]

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 running 
automated test. The dialog will also prevent other tests from completing. 

This patch changes the Failure handler to check if "Developer mode" is enabled 
before running commands that require it. It also includes the output of 
"DevToolsSecurity —status” which is used to check for “Developer mode”.

Please review the webrev below,
/Staffan


bug: https://bugs.openjdk.java.net/browse/JDK-8171366
webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.00/

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

[Staffan Larsen]

Looks better to me!

/Staffan

> On 28 Nov 2016, at 13:52, Erik Joelsson <erik.joels...@oracle.com> 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!
>> 
>> Thanks,
>> /Staffan
>> 
>>> On 28 Nov 2016, at 13:41, Erik Joelsson <erik.joels...@oracle.com> 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 also changed. We used 
>>> to silently ignore the lack of source revision information, but now the 
>>> build fails.
>>> 
>>> Since it's not an uncommon use case in our Oracle internal infrastructure 
>>> (JPRT, Mach 5) to have builds without either mercurial or stored revision 
>>> information, this needs to be downgraded this to at most a warning.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170392
>>> 
>>> Webrev: http://cr.openjdk.java.net/~erikj/8170392/webrev.01/
>>> 
>>> /Erik
>>> 
> 

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

[Staffan Larsen]

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 also changed. We used to 
> silently ignore the lack of source revision information, but now the build 
> fails.
> 
> Since it's not an uncommon use case in our Oracle internal infrastructure 
> (JPRT, Mach 5) to have builds without either mercurial or stored revision 
> information, this needs to be downgraded this to at most a warning.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170392
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8170392/webrev.01/
> 
> /Erik
> 

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

[Staffan Larsen]

Thank David!

> On 22 Oct 2016, at 02:24, David Holmes <david.hol...@oracle.com> 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 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 implementation in jtreg tries to interrupt() a timeout handler 
>> after 300 seconds. This is not enough time for test/failure_handler. Rather 
>> than increasing the timeout, we should disable it when running with 
>> test/failure_handler and let it handle any timeouts itself.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8168483/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8168483 
>> <https://bugs.openjdk.java.net/browse/JDK-8168483>
>> 
>> /Staffan
>> 

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

[Staffan Larsen]

Thanks Tim!

> On 22 Oct 2016, at 05:21, Tim Bell <tim.b...@oracle.com> 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:
>>> 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 implementation in jtreg tries to interrupt() a timeout
>>> handler after 300 seconds. This is not enough time for
>>> test/failure_handler. Rather than increasing the timeout, we should
>>> disable it when running with test/failure_handler and let it handle
>>> any timeouts itself.
>>> 
>>> webrev: http://cr.openjdk.java.net/~sla/8168483/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8168483
>>> <https://bugs.openjdk.java.net/browse/JDK-8168483>
>>> 
>>> /Staffan
>>> 
> 

RFR(S): 8168483 Remove jtreg timeout handler timeout

[Staffan Larsen]

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 implementation in jtreg tries to interrupt() a timeout handler 
after 300 seconds. This is not enough time for test/failure_handler. Rather 
than increasing the timeout, we should disable it when running with 
test/failure_handler and let it handle any timeouts itself.

webrev: http://cr.openjdk.java.net/~sla/8168483/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8168483 


/Staffan

Re: RFR: 8168414 Various timeouthandler fixes

[Staffan Larsen]

> On 21 Oct 2016, at 06:10, David Holmes <david.hol...@oracle.com> wrote:
> 
> On 20/10/2016 11:44 PM, Staffan Larsen wrote:
>> 
>>> On 20 Oct 2016, at 15:41, David Holmes <david.hol...@oracle.com> 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()
>>> 
>>> That isn't "strange" it is an idiomatic usage - if you can't propagate the 
>>> InterruptedException to show your caller you have been interrupted then you 
>>> re-assert the interrupt state.
>> 
>> OK, then. In this case it is less “strange” than “wrong”. The cases where 
>> this is done should not propagate the interrupt state - it only serves to 
>> throw unexpected exceptions higher up in the call-chain.
> 
> If code higher up the call chain can not handle being interrupted and 
> interrupt is being used within the program to signal cancellation, then it is 
> the higher up code that has a problem. As I said the existing code is an 
> idiomatic approach to dealing with cancellation requests.

jtreg uses interrupt() to try to signal to the timeout handler that it has 
exceeded its timeout (-timeoutHandlerTimeout). This is the default way for 
jtreg to cancel timeout handlers. There are a couple of issues with this. 
First, interrupt() does not work well as a way to cancel I/O work (which is 
what the timeout handler is doing most of the time). Second, this particular 
timeout handler does a very good job of handling timeouts on its own. I will 
soon send out a patch to remove jtreg’s timeout when running with our timeout 
handler, but even with that patch there are cases when jtreg calls interrupt() 
on the timeout handler. In those cases we just want to ignore that and keep on 
doing our work, taking the liberty of saying that we know better than jtreg. 

/Staffan




> 
> Cheers,
> David
> 
>>> 
>>> Cheers,
>>> David
>>> 
>>>> * Add logging for timeouts
>>>> * Milliseconds sometimes printed as microseconds or nanoseconds
>>>> * Should use destroyForcibly() to terminate processes
>>>> * No need to sleep in the last iteration when running a command multiple 
>>>> times
>>>> * Disable timeout handling timeouts since we do that ourselves
>>>> 
>>>> I didn’t want to file individual bugs for all of these, so I have lumped 
>>>> them together in one bug.
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8168414 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8168414>webrev: 
>>>> http://cr.openjdk.java.net/~sla/8168414/webrev.00 
>>>> <http://cr.openjdk.java.net/~sla/8168414/webrev.00>
>>>> 
>>>> Thanks,
>>>> /Staffan

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

[Staffan Larsen]

Dmitry,

I would like to avoid running SA-based tools in the timeout handler since on 
macOS they pop up dialogs asking for permission to attach to the process. This 
is problematic in our testing infrastructure. Instead, I hope we can run jhsdb 
on the core file that is generated.

I tried doing this automatically in the timeout handler, but could not find a 
simple way to do it. jhsdb requires the path to the executable and the timeout 
handler does not know this. Perhaps a future enhancement to the timeout handler 
could fix this.

/Staffan

> On 20 Oct 2016, at 22:12, Dmitry Samersoff <dmitry.samers...@oracle.com> 
> 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 
>> 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 processes where the JVM is completely hung, but in that case we can 
>> fallback to running the SA-tools on the core file that is also generated.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8168409/webrev.00 
>> <http://cr.openjdk.java.net/~sla/8168409/webrev.00>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8168409 
>> <https://bugs.openjdk.java.net/browse/JDK-8168409>
>> 
>> Thanks,
>> /Staffan
>> 
> 
> 
> -- 
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

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

[Staffan Larsen]

Thanks Marcus for all three reviews!

> On 20 Oct 2016, at 15:50, Marcus Larsson <marcus.lars...@oracle.com> 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 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 processes where the JVM is completely hung, but in that case we can 
>> fallback to running the SA-tools on the core file that is also generated.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8168409/webrev.00 
>> <http://cr.openjdk.java.net/~sla/8168409/webrev.00>
> 
> Looks good to me.
> 
> Thanks,
> Marcus
> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8168409 
>> <https://bugs.openjdk.java.net/browse/JDK-8168409>
>> 
>> Thanks,
>> /Staffan
> 

Re: RFR: 8168414 Various timeouthandler fixes

[Staffan Larsen]

> On 20 Oct 2016, at 15:41, David Holmes <david.hol...@oracle.com> 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()
> 
> That isn't "strange" it is an idiomatic usage - if you can't propagate the 
> InterruptedException to show your caller you have been interrupted then you 
> re-assert the interrupt state.

OK, then. In this case it is less “strange” than “wrong”. The cases where this 
is done should not propagate the interrupt state - it only serves to throw 
unexpected exceptions higher up in the call-chain.

> 
> Cheers,
> David
> 
>> * Add logging for timeouts
>> * Milliseconds sometimes printed as microseconds or nanoseconds
>> * Should use destroyForcibly() to terminate processes
>> * No need to sleep in the last iteration when running a command multiple 
>> times
>> * Disable timeout handling timeouts since we do that ourselves
>> 
>> I didn’t want to file individual bugs for all of these, so I have lumped 
>> them together in one bug.
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8168414 
>> <https://bugs.openjdk.java.net/browse/JDK-8168414>webrev: 
>> http://cr.openjdk.java.net/~sla/8168414/webrev.00 
>> <http://cr.openjdk.java.net/~sla/8168414/webrev.00>
>> 
>> Thanks,
>> /Staffan
>> 

RFR: 8168414 Various timeouthandler fixes

[Staffan Larsen]

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 need to sleep in the last iteration when running a command multiple times 
* Disable timeout handling timeouts since we do that ourselves 

I didn’t want to file individual bugs for all of these, so I have lumped them 
together in one bug.

bug: https://bugs.openjdk.java.net/browse/JDK-8168414 
webrev: 
http://cr.openjdk.java.net/~sla/8168414/webrev.00 


Thanks,
/Staffan

RFR(XS): 8168412 Reduce buffering in jtreg timeouthandler

[Staffan Larsen]

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/webrev.00 

bug: https://bugs.openjdk.java.net/browse/JDK-8168412 


Thanks,
/Staffan

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

[Staffan Larsen]

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 
processes where the JVM is completely hung, but in that case we can fallback to 
running the SA-tools on the core file that is also generated.

webrev: http://cr.openjdk.java.net/~sla/8168409/webrev.00 

bug: https://bugs.openjdk.java.net/browse/JDK-8168409 


Thanks,
/Staffan

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

[Staffan Larsen]

The reason is to use the same name as is currently used in the jdk, hotspot, 
nashorn and jaxp makefiles. Having a common name makes it much easier for 
outside tools to find the file.

> On 10 Oct 2016, at 19:31, Jonathan Gibbons <jonathan.gibb...@oracle.com> 
> wrote:
> 
> Is there a compelling reason to use .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!
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>>> On 10 Oct 2016, at 12:46, Marcus Larsson <marcus.lars...@oracle.com> 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.net/~mlarsson/8167354/webrev.00
>>>> 
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8167354
>>>> 
>>>> Thanks,
>>>> Marcus
>> 
> 

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

[Staffan Larsen]

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.net/~mlarsson/8167354/webrev.00
> 
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8167354
> 
> Thanks,
> Marcus

Re: Query on developing OpenJDK with IntelliJ

[Staffan Larsen]

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 regarding setting up a particular aspect of my
> development environment for OpenJDK, and I wonder if this is the right
> mailing list for me to post such questions.
> 
> When I open my local clone of the JDK 9 codebase as a project in IntelliJ
> Ultimate 2016.2, there are a number of places where IntelliJ gets confused
> and shows red squiggles underneath lines of code that exist in JDK 9 but
> not JDK 8. I think this is happening for a couple of reasons.
> 
>   1. My IntelliJ project is currently setup to use my machine's installed
>   JDK 8 distribution as it's Java SDK (as it should be, to the best of my
>   knowledge).
>   2. When my IntelliJ encounters java.* classes, it refers to the java.*
>   classes in my installed JDK 8 rather than those in my JDK 9 project.
> 
> I want to "tell" IntelliJ to use the JDK 9 java.* classes in my project,
> rather than those in my installed JDK 8, so that these red squiggles are
> eliminated, and I wonder if anyone here has come across a solution for
> doing so.
> 
> If my query is not appropriate for this list, would you kindly let me know
> which list I should contact instead?
> 
> Kind regards,
> Jonathan

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

[Staffan Larsen]

Thanks!

> On 24 maj 2016, at 11:58, Erik Joelsson <erik.joels...@oracle.com> 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:\!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 
>> <https://bugs.openjdk.java.net/browse/JDK-8157605>
>> webrev: http://cr.openjdk.java.net/~sla/8157605/webrev.00/ 
>> <http://cr.openjdk.java.net/~sla/8157605/webrev.00/>
>> 
>> Thanks,
>> /Staffan
> 

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

[Staffan Larsen]

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:
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8157605 
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8157605/webrev.00/ 
>> 
> 
> Looks good to me.
> 
> Tim
> 

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

[Staffan Larsen]

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 

webrev: http://cr.openjdk.java.net/~sla/8157605/webrev.00/ 


Thanks,
/Staffan

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

[Staffan Larsen]

Updated webrev with those changes to the hotspot makefile: 
http://cr.openjdk.java.net/~sla/8156658/webrev.04/ 
<http://cr.openjdk.java.net/~sla/8156658/webrev.04/>

Thanks,
/Staffan

> On 10 maj 2016, at 15:50, Dmitry Samersoff <dmitry.samers...@oracle.com> 
> wrote:
> 
> Staffan,
> 
>> Maybe. 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 Samersoff <dmitry.samers...@oracle.com> 
>>> wrote:
>>> 
>>> Staffan,
>>> 
>>> Long awaited changes, thank you for doing it.
>>> 
>>> Is it possible to use the same code for hotspot/test/Makefile:128 and
>>> jdk/test/Makefile:84
>> 
>> Maybe. I didn’t want to change existing behavior in this patch. Which one do 
>> you prefer? 
>> 
>>> 
>>> 84   ifdef ALT_OUTPUTDIR
>>> 85 ABS_OUTPUTDIR = $(shell $(CD) $(ALT_OUTPUTDIR) && $(PWD))
>>> 86   else
>>> 87 ABS_OUTPUTDIR = $(shell $(CD) $(TEST_ROOT)/.. && $(PWD))
>>> 88   endif
>>> 89
>>> 90   ABS_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 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 already some support for running jtreg tests from the /test 
>>>> folder, but it is not general enough since it isn't possible to pick 
>>>> individual tests or specific test groups. It is also not possible to 
>>>> direct the output to a common location. 
>>>> 
>>>> The proposed solution is to be able to run jtreg tests using make from 
>>>> within the /test folder like this: 
>>>> 
>>>> $ make JT_JAVA= JT_HOME= PRODUCT_HOME=>>> path> \
>>>>   TESTDIRS=../ TEST_SELECTION=>>> test or jtreg group> \
>>>>   TEST_OUTPUT_DIR= jtreg_tests 
>>>> 
>>>> This will run the specified tests and collect output in 
>>>> TEST_OUTPUT_DIR/jtreg. EXTRA_JTREG_OPTIONS is also supported to add 
>>>> additional options to the jtreg command line. 
>>>> 
>>>> No existing behavior should be changed.
>>>> 
>>>> webrev: http://cr.openjdk.java.net/~sla/8156658/webrev.03/ 
>>>> <http://cr.openjdk.java.net/~sla/8156658/webrev.03/>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156658 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8156658>
>>>> 
>>>> Thanks,
>>>> /Staffan
>>>> 
>>> 
>>> 
>>> -- 
>>> Dmitry Samersoff
>>> Oracle Java development team, Saint Petersburg, Russia
>>> * I would love to change the world, but they won't give me the sources.
>> 
> 
> 
> -- 
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

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

[Staffan Larsen]

> On 10 maj 2016, at 14:46, Dmitry Samersoff <dmitry.samers...@oracle.com> 
> wrote:
> 
> Staffan,
> 
> Long awaited changes, thank you for doing it.
> 
> Is it possible to use the same code for hotspot/test/Makefile:128 and
> jdk/test/Makefile:84

Maybe. I didn’t want to change existing behavior in this patch. Which one do 
you prefer? 

> 
>  84   ifdef ALT_OUTPUTDIR
>  85 ABS_OUTPUTDIR = $(shell $(CD) $(ALT_OUTPUTDIR) && $(PWD))
>  86   else
>  87 ABS_OUTPUTDIR = $(shell $(CD) $(TEST_ROOT)/.. && $(PWD))
>  88   endif
>  89
>  90   ABS_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 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 
>> already some support for running jtreg tests from the /test folder, but 
>> it is not general enough since it isn't possible to pick individual tests or 
>> specific test groups. It is also not possible to direct the output to a 
>> common location. 
>> 
>> The proposed solution is to be able to run jtreg tests using make from 
>> within the /test folder like this: 
>> 
>>  $ make JT_JAVA= JT_HOME= PRODUCT_HOME=> path> \
>>TESTDIRS=../ TEST_SELECTION=> test or jtreg group> \
>>TEST_OUTPUT_DIR= jtreg_tests 
>> 
>> This will run the specified tests and collect output in 
>> TEST_OUTPUT_DIR/jtreg. EXTRA_JTREG_OPTIONS is also supported to add 
>> additional options to the jtreg command line. 
>> 
>> No existing behavior should be changed.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8156658/webrev.03/ 
>> <http://cr.openjdk.java.net/~sla/8156658/webrev.03/>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8156658 
>> <https://bugs.openjdk.java.net/browse/JDK-8156658>
>> 
>> Thanks,
>> /Staffan
>> 
> 
> 
> -- 
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

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

[Staffan Larsen]

Thanks Erik!

> On 10 maj 2016, at 14:39, Erik Joelsson <erik.joels...@oracle.com> 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, 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 
>> already some support for running jtreg tests from the /test folder, but 
>> it is not general enough since it isn't possible to pick individual tests or 
>> specific test groups. It is also not possible to direct the output to a 
>> common location.
>> 
>> The proposed solution is to be able to run jtreg tests using make from 
>> within the /test folder like this:
>> 
>>   $ make JT_JAVA= JT_HOME= PRODUCT_HOME=> path> \
>> TESTDIRS=../ TEST_SELECTION=> test or jtreg group> \
>> TEST_OUTPUT_DIR= jtreg_tests
>> 
>> This will run the specified tests and collect output in 
>> TEST_OUTPUT_DIR/jtreg. EXTRA_JTREG_OPTIONS is also supported to add 
>> additional options to the jtreg command line.
>> 
>> No existing behavior should be changed.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8156658/webrev.03/ 
>> <http://cr.openjdk.java.net/~sla/8156658/webrev.03/>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8156658 
>> <https://bugs.openjdk.java.net/browse/JDK-8156658>
>> 
>> Thanks,
>> /Staffan
> 

RFR: JDK-8156658 Common way to run jtreg tests

[Staffan Larsen]

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 already some 
support for running jtreg tests from the /test folder, but it is not 
general enough since it isn't possible to pick individual tests or specific 
test groups. It is also not possible to direct the output to a common location. 

The proposed solution is to be able to run jtreg tests using make from within 
the /test folder like this: 

  $ make JT_JAVA= JT_HOME= PRODUCT_HOME= \
TESTDIRS=../ TEST_SELECTION= \
TEST_OUTPUT_DIR= jtreg_tests 

This will run the specified tests and collect output in TEST_OUTPUT_DIR/jtreg. 
EXTRA_JTREG_OPTIONS is also supported to add additional options to the jtreg 
command line. 

No existing behavior should be changed.

webrev: http://cr.openjdk.java.net/~sla/8156658/webrev.03/ 

bug: https://bugs.openjdk.java.net/browse/JDK-8156658 


Thanks,
/Staffan

Re: RFR:

[Staffan Larsen]

> On 13 jan. 2016, at 16:11, Erik Helin <erik.he...@oracle.com> 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 me, I'm fine with either hotspot/testoutput or
> testoutput/hotspot. Anyone else have a preference?

I don’t have a strong preference - feel free to commit the patch as is.

/Staffan

> 
> Thanks,
> Erik
> 
>> Thanks,
>> /Staffan
>> 
>> 
>>> On 13 jan. 2016, at 15:01, Erik Helin <erik.he...@oracle.com> 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-hotspot-jtreg`.
>>> 
>>> The current directory is
>>> /build//hotspot/linux-x64/testoutput
>>> (on an x86-64 machine running Linux). There is no need to place the
>>> "testoutput" directory in a directory which name is based on OS and arch,
>>> that is already done by the current configuration. Therefore, we can
>>> instead place the "testoutput" directory in
>>> /build//hotspot/, which is a more reasonable location
>>> for the output from hotspot's tests.
>>> 
>>> Enhancement:
>>> https://bugs.openjdk.java.net/browse/JDK-8146985
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev
>>> 
>>> Testing:
>>> - Running `make test-hotspot-jtreg` locally
>>> - JPRT (the patch does not affect JPRT since JPRT does not use
>>> ALT_OUTPUTDIR)
>>> 
>>> Thanks,
>>> Erik
>> 

Re: RFR:

[Staffan Larsen]

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-hotspot-jtreg`.
> 
> The current directory is
> /build//hotspot/linux-x64/testoutput
> (on an x86-64 machine running Linux). There is no need to place the
> "testoutput" directory in a directory which name is based on OS and arch,
> that is already done by the current configuration. Therefore, we can
> instead place the "testoutput" directory in
> /build//hotspot/, which is a more reasonable location
> for the output from hotspot's tests.
> 
> Enhancement:
> https://bugs.openjdk.java.net/browse/JDK-8146985
> 
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev
> 
> Testing:
> - Running `make test-hotspot-jtreg` locally
> - JPRT (the patch does not affect JPRT since JPRT does not use
>  ALT_OUTPUTDIR)
> 
> Thanks,
> Erik

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

[Staffan Larsen]

> 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/8043138/webrev.00/jdk
> 
> This patch splits up the jdk.jvmstat module to jdk.jvmstat and 
> jdk.jvmstat.rmi to make the basic jvmstat functionality available without 
> requiring dependencies on RMI.
> 
> The split is pretty straightforward - all the RMI dependent implementation is 
> moved to the new module as well as 'jstatd' implementation.
> 
> The change requires changes in the makefile (for merging META-INF/services 
> resources from jdk.jvmstat and jdk.jvmstat.rmi) and therefore I am posting 
> this request also to the build-dev mailing list.

Can you explain what the makefile is doing? Why do we need to merge these files?

> 
> 
> Thanks,
> 
> -JB-

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

[Staffan Larsen]

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 checks for aix-ppc and zero to 
> instead use the variable INCLUDE_SA which configure sets up based on at least 
> these conditions.
> 
> I also removed another lingering special case instance of the 
> jdk.hotspot.agent module in Main.gmk.
> 
> New webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.03/
> 
> /Erik
> 
> On 2015-11-13 11:39, Erik Joelsson wrote:
>> Widening the distribution in the hopes of finding another reviewer.
>> 
>> I've fixed the formatting in hotspot/make/bsd/makefiles/defs.make locally. 
>> Merge tool error.
>> 
>> /Erik
>> 
>> On 2015-11-11 17:43, Magnus Ihse Bursie wrote:
>>> On 2015-11-11 10:31, Erik Joelsson wrote:
 New webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.02/
 
 Fixed the issues listed below. Reverted the faulty attempt at fixing a 
 warning. Did a more thorough attempt at clearing out all references to SA 
 in the old makefiles.
>>> 
>>> Looks great. There was a few lines in hotspot/make/bsd/makefiles/defs.make 
>>> where you seem to have accidentally broken the indentation. Apart from this 
>>> it looks good. If you just restore the indentation I'm okay (you don't need 
>>> to respin the webrev for that).
>>> 
>>> /Magnus
>>> 
 
 /Erik
 
 On 2015-11-10 14:49, Magnus Ihse Bursie wrote:
> On 2015-11-10 11:39, Magnus Ihse Bursie wrote:
>> On 2015-11-09 19:33, Erik Joelsson wrote:
>>> Hello,
>>> 
>>> As a stepping stone in the hotspot makefile conversion, I have broken 
>>> out the serviceability agent separately and converted it into proper 
>>> modular build-infra makefiles. Doing this conversion separately has 
>>> some value on its own by reducing the special cases currently needed 
>>> for building the jdk.hotspot.agent module.
>>> 
>>> The current SA java build compiles with the boot jdk javac with 
>>> -source/-target JDK N-1. The proposed change instead builds SA with the 
>>> interim-langtools javac for JDK N, like all the rest of the JDK classes.
>>> 
>>> There is already a bug filed for reorganizing the source of the SA 
>>> agent to conform to the Jigsaw style modular source layout: 
>>> JDK-8067194, so I have left the source in its current location.
>>> 
>>> The native compilation and linking has been changed to base the flags 
>>> used on what configure sets up for the other JDK libraries. This has 
>>> caused some changes in flag usage. From what I can tell, nothing 
>>> important is different however. I have run the relevant jtreg tests on 
>>> all OSes to verify that it still works. Some of the differences include:
>>> 
>>> * Linux: "-Xlinker z -Xlinker defs" was added to LDFLAGS, which causes 
>>> link failure unless "-ldl" was also added to LIBS.
>>> * Solaris: More warnings activated through "+w" caused need for 
>>> disabling some warnings. I fixed one warning instance which was trivial 
>>> (int->size_t), but couldn't figure out the rest. I will file a followup 
>>> bug for fixing those if this patch is accepted.
>>> 
>>> I tried to mimic the current behavior of excluding SA on linux-ppc and 
>>> zero that Volker added a while back. Now it's excluded on the module 
>>> level instead so that jdk.hotspot.agent isn't even built in that case. 
>>> It would be good if this could be tested.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142336
>>> Webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.01/
>> 
>> A few remarks:
>> 
>> * Could you please document the new DISABLED_WARNINGS_CXX and 
>> DISABLED_WARNINGS_C in the function header?
>> 
>> * I believe the use of {} here was to signify a set. When only jsig 
>> remains, it just looks strange:
>> -# SYMFLAG is used by {jsig,saproc}.make
>> +# SYMFLAG is used by {jsig}.make
>> 
>> * The logic of setting up "--hash-style=both" is already done in 
>> configure for LDFLAGS_JDKLIB, so you do not need to repeat it, if you 
>> include the LDFLAGS_JDKLIB variable.
> 
> Also, SA_WINDOWS_LDFLAGS is read but never defined.
> 
> /Magnus
 
>>> 
>> 
> 

Re: CLANG special case

[Staffan Larsen]

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  wrote:
> 
> Ideally hotspot would review this, not build.
> so it would be helpful if hotspot found an engineer to own the bug :-
> https://bugs.openjdk.java.net/browse/JDK-8138820
> So far as I know this is not tracked under any other bug id.
> 
> -phil.
> 
> On 10/06/2015 05:30 AM, Jim Laskey (Oracle) wrote:
>> I’ve updated to El Capitan and, of course, builds fail, and, of course, I 
>> modify hotspot/make/bsd/makefiles/gcc.make one more time and…   I think this 
>> conditional clause should be removed at the very least (commenting to 
>> indicate needs investigation), or someone should research and see which 
>> version of clang fixes the issues associate with the patch.  Since it’s 
>> likely that no one has the cycles, please remove the condition.
>> 
>> Cheers,
>> 
>> — Jim
>> 
>> 
>> 
>> diff -r a02911828e48 make/bsd/makefiles/gcc.make
>> --- a/make/bsd/makefiles/gcc.makeWed Sep 30 07:41:36 2015 -0700
>> +++ b/make/bsd/makefiles/gcc.makeTue Oct 06 09:22:50 2015 -0300
>> @@ -313,21 +313,13 @@
>># Work around some compiler bugs.
>>  ifeq ($(USE_CLANG), true)
>> -  # Clang <= 6.1
>> -  ifeq ($(shell expr \
>> -  $(CC_VER_MAJOR) \< 6 \| \
>> -  \( $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 \) \
>> -), 1)
>> -OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT)
>> -OPT_CFLAGS/unsafe.o += -O1
>> -  else
>> -$(error "Update compiler workarounds for Clang 
>> $(CC_VER_MAJOR).$(CC_VER_MINOR)")
>> -  endif
>> +  OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT)
>> +  OPT_CFLAGS/unsafe.o += -O1
>>  else
>># 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation.
>>ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 3), 1)
>>  OPT_CFLAGS/mulnode.o += $(OPT_CFLAGS/NOOPT)
>> -  endif
>> +  endif
>>  endif
>># Flags for generating make dependency flags.
>> 
> 

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

[Staffan Larsen]

 On 9 aug 2015, at 05:13, Mandy Chung mandy.ch...@oracle.com wrote:
 
 
 On Aug 6, 2015, at 11:57 PM, Staffan Larsen staffan.lar...@oracle.com 
 wrote:
 
 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.
 
 bug: https://bugs.openjdk.java.net/browse/JDK-8046661 
 https://bugs.openjdk.java.net/browse/JDK-8046661
 
 top-level changes: http://cr.openjdk.java.net/~sla/8076470/root/webrev.00/ 
 http://cr.openjdk.java.net/~sla/8076470/root/webrev.00/
 jdk changes: http://cr.openjdk.java.net/~sla/8076470/jdk/webrev.00/ 
 http://cr.openjdk.java.net/~sla/8076470/jdk/webrev.00/
 hotspot changes: http://cr.openjdk.java.net/~sla/8076470/hotspot/webrev.00/ 
 http://cr.openjdk.java.net/~sla/8076470/hotspot/webrev.00/
 
 
 This patch looks fine to me.  

Thanks!

 A minor comment:
 
 src/java.base/share/classes/sun/launcher/resources/launcher.properties - 
 should this resource file be updated not to reference -agentlib:prof?
 
 I assume you have a JBS issue tracking the launcher man page and other 
 documentation to be updated accordingly.

I added this to the docs task for the JEP.

Thanks,
/Staffan

 
 Mandy
 

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

[Staffan Larsen]

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.

bug: https://bugs.openjdk.java.net/browse/JDK-8046661 
https://bugs.openjdk.java.net/browse/JDK-8046661

top-level changes: http://cr.openjdk.java.net/~sla/8076470/root/webrev.00/ 
http://cr.openjdk.java.net/~sla/8076470/root/webrev.00/
jdk changes: http://cr.openjdk.java.net/~sla/8076470/jdk/webrev.00/ 
http://cr.openjdk.java.net/~sla/8076470/jdk/webrev.00/
hotspot changes: http://cr.openjdk.java.net/~sla/8076470/hotspot/webrev.00/ 
http://cr.openjdk.java.net/~sla/8076470/hotspot/webrev.00/

Thanks,
/Staffan

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

[Staffan Larsen]

 On 7 aug 2015, at 11:24, serguei.spit...@oracle.com wrote:
 
 Hi Staffan,
 
 Looks good.

Thanks!

 
 I'm re-posting the same question in this review:
   Q1: Should the folder jdk/src/demo/share/jvmti/java_crw_demo also be 
 removed?

No, it is used by 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 
 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.
 
 bug: https://bugs.openjdk.java.net/browse/JDK-8046661 
 https://bugs.openjdk.java.net/browse/JDK-8046661
 
 top-level changes: http://cr.openjdk.java.net/~sla/8076470/root/webrev.00/ 
 http://cr.openjdk.java.net/%7Esla/8076470/root/webrev.00/
 jdk changes: http://cr.openjdk.java.net/~sla/8076470/jdk/webrev.00/ 
 http://cr.openjdk.java.net/%7Esla/8076470/jdk/webrev.00/
 hotspot changes: http://cr.openjdk.java.net/~sla/8076470/hotspot/webrev.00/ 
 http://cr.openjdk.java.net/%7Esla/8076470/hotspot/webrev.00/
 
 Thanks,
 /Staffan
 
 
 
 

Re: need to build a DLL for an openjdk test

[Staffan Larsen]

 On 4 jun 2015, at 04:33, Pete Brunet peter.bru...@oracle.com 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 of my test I need to build a simple DLL and then load it
 from my test class.  Can jtreg build the DLL or will I need to create it
 and include it in my test directory?  -Pete
 jtreg cannot directly compile native code.  In theory, you could do it
 in a shell script, but that immediately becomes a rats nest of which
 platform, and where do I find the compilers?
 Is there a way to only run the test if running on Win?  The DLL will be
 used as part of a test of a platform independent feature.  Would only
 running on Win be acceptable?  Is where to I find the compilers still
 an issue in a Win only case?

Yes - most test machines don’t have compilers on them. All compilation has to 
be done as part of the build.

 
 If you are talking about native code and tests in OpenJDK
 repositories, then it is not acceptable to stash binaries in OpenJDK
 repositories.  But, there is an infrastructure in place for an OpenJDK
 build to build native libraries to be made available to test code.
 Perhaps someone else on this list can explain how that works.
 
 -- Jon
 

Re: need to build a DLL for an openjdk test

[Staffan Larsen]

 On 4 jun 2015, at 07:10, David Holmes david.hol...@oracle.com 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 in jdk/test/native_sanity - take a look at those.

/Staffan

 
 David
 
 On 6/3/15 8:13 PM, Jonathan Gibbons wrote:
 
 On 06/03/2015 04:27 PM, Pete Brunet wrote:
 Hi, As part of my test I need to build a simple DLL and then load it
 from my test class.  Can jtreg build the DLL or will I need to create it
 and include it in my test directory?  -Pete
 
 jtreg cannot directly compile native code.  In theory, you could do it
 in a shell script, but that immediately becomes a rats nest of which
 platform, and where do I find the compilers?
 
 If you are talking about native code and tests in OpenJDK
 repositories, then it is not acceptable to stash binaries in OpenJDK
 repositories.  But, there is an infrastructure in place for an OpenJDK
 build to build native libraries to be made available to test code.
 Perhaps someone else on this list can explain how that works.
 
 -- Jon
 

Re: RFR: libdt_socket: Build failed with VS2013 SP4

[Staffan Larsen]

Looks good!

Thanks,
/Staffan

 On 25 maj 2015, at 12:17, Erik Joelsson erik.joels...@oracle.com 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 libhprof. Now we also have the problem 
 in libdt_socket. This time I've opted to add the preprocessor macro to the 
 general CFLAGS for all jdk libraries in configure. I will create a followup 
 bug for fixing the usage of deprecated functions.
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8080983
 
 Patch:
 diff -r 9d388c0d9872 common/autoconf/flags.m4
 --- a/common/autoconf/flags.m4
 +++ b/common/autoconf/flags.m4
 @@ -559,6 +559,7 @@
 -Zi -MD -Zc:wchar_t- -W3 -wd4800 \
 -DWIN32_LEAN_AND_MEAN \
 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE \
 +   -D_WINSOCK_DEPRECATED_NO_WARNINGS \
 -DWIN32 -DIAL
 if test x$OPENJDK_TARGET_CPU = xx86_64; then
   COMMON_CCXXFLAGS_JDK=$COMMON_CCXXFLAGS_JDK -D_AMD64_ -Damd64
 diff -r 9d388c0d9872 common/autoconf/generated-configure.sh
 --- a/common/autoconf/generated-configure.sh
 +++ b/common/autoconf/generated-configure.sh
 @@ -4366,7 +4366,7 @@
 #CUSTOM_AUTOCONF_INCLUDE
 
 # Do not change or remove the following line, it is needed for consistency 
 checks:
 
 
 Also removing the old fix from JDK-8077422 as it is no longer needed:
 diff -r 8f8d35d97f82 make/lib/Lib-jdk.hprof.agent.gmk
 --- a/make/lib/Lib-jdk.hprof.agent.gmk
 +++ b/make/lib/Lib-jdk.hprof.agent.gmk
 @@ -49,7 +49,6 @@
 CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \
 $(BUILD_LIBHPROF_CFLAGS), \
 CFLAGS_debug := -DHPROF_LOGGING, \
 -CFLAGS_windows := -D_WINSOCK_DEPRECATED_NO_WARNINGS, \
 MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \
 LDFLAGS := $(LDFLAGS_JDKLIB) \
 $(call SET_SHARED_LIBRARY_ORIGIN), \
 
 /Erik

Re: Issues with dtrace enabled in OpenJdk 9

[Staffan Larsen]

The SDT support is maintained by the IcedTea folks. Perhaps asking on their 
email list [1] would get you closer, or on the hotspot-dev list.

/Staffan

[1] http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev

 On 12 maj 2015, at 10:21, Mahesh Pujari pujarimahesh_ku...@yahoo.com wrote:
 
 I think I have mixed up things, like thinking SDT and dtrace4linux as same, 
 but there are not as pointed out by Staffan.
 
 So first I build jdk9 with not having SDT headers i.e. not having 
 systemtap-dev. Build was success as expected.
 
 Next I did a build having SDT headers in path (i.e. I having installed 
 systemtap and systemtap-dev), as pointed out by David, dtrace will be enabled 
 by default, it seems its working as expected, i.e. dtrace was enabled but the 
 build failed with below error.
 
 In file included from 
 /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/utilities/dtrace.hpp:49:0,
  from 
 /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/utilities/hashtable.inline.hpp:31,
  from 
 /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/classfile/systemDictionary.hpp:35,
  from 
 /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciEnv.hpp:30,
  from 
 /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciUtilities.hpp:28,
  from 
 /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciNullObject.hpp:30,
  from 
 /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciConstant.hpp:29,
  from 
 /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/ci/ciArray.hpp:29,
  from 
 /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/precompiled/precompiled.hpp:33:
 ../generated/dtracefiles/hotspot.h:14:5: error: _DTRACE_VERSION is not 
 defined [-Werror=undef]
 
 To fix this, I re-configured with 
 --with-extra-cflags=-D_DTRACE_VERSION=true and did make all LOG=info, now 
 compilation are success but linking failed (lot of them), few of the logs as 
 below
 
 Compiling /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/runtime/vm_version.cpp
 Linking vm...
 classLoadingService.o: In function 
 `ClassLoadingService::notify_class_unloaded(InstanceKlass*)':
 /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119:
  undefined reference to `__dtrace_hotspot___class__unloaded'
 classLoadingService.o: In function 
 `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)':
 /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144:
  undefined 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__begin'
 
 
 Do I need to install some other libraries, what am I missing here.
 
 thanks and regards,
 Mahesh Pujari
 
 
 
 On Monday, May 11, 2015 5:08 PM, Staffan Larsen staffan.lar...@oracle.com 
 wrote:
 
 
 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 untested.
 
 /Staffan
 
 
 
  On 11 maj 2015, at 13:21, David Holmes david.hol...@oracle.com 
  mailto:david.hol...@oracle.com wrote:
  
  On 11/05/2015 8:51 PM, Mahesh Pujari wrote:
  Thanks for replying back Erik.
  I ran as you stated i.e. using make DTRACE_ENABLED=true but then I 
  realized that the configure that I was running would do the same i.e. by 
  having CFLAGS=-DDTRACE_ENABLED=1.
  
  No it isn't the same. The linux/makefiles/dtrace.make looks for 
  DTRACE_ENABLED and will define additional targets if it is set, as well as 
  setting -DDTRACE_ENABLED. If you just set the define then you miss other 
  things.
  
  But that aside you don't set DTRACE_ENABLED either. dtrace will be enabled 
  if the SDT header file is found. If you just do a build without trying to 
  force dtrace on what does the log show?
  
  David
  -
  
  When I make (using your approach and passing enable in configure), I end 
  up with lots and lots of undefined reference to errors during make, 
  seems I am missing something, below are some error from build.logs.
  classLoadingService.o: In function 
  `ClassLoadingService::notify_class_unloaded(InstanceKlass*)':
  /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:119:
   undefined reference to `__dtrace_hotspot___class__unloaded'
  classLoadingService.o: In function 
  `ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)':
  /mnt/ubuntu/dev/jdk9/hotspot/src/share/vm/services/classLoadingService.cpp:144:
   undefined 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

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

[Staffan Larsen]

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 
http://cr.openjdk.java.net/~sla/8079345/webrev.00

Thanks,
/Staffan

RFR: 8079360 AttachProviderImpl could not be instantiated

[Staffan Larsen]

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/ 
http://cr.openjdk.java.net/~sla/8079360/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8079360 
https://bugs.openjdk.java.net/browse/JDK-8079360

Thanks,
/Staffan

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

[Staffan Larsen]

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=1 is needed when 
compiling the library calling GetProcessMemoryInfo. This fix simply moves that 
patch from make/lib/Lib-java.management.gmk to make/lib/Lib-jdk.management.gmk. 
The patch was introduced in JDK-8076557.

I will push the change below directly to jdk9/hs.

Thanks,
/Staffan


diff --git a/make/lib/Lib-java.management.gmk b/make/lib/Lib-java.management.gmk
--- a/make/lib/Lib-java.management.gmk
+++ b/make/lib/Lib-java.management.gmk
@@ -38,11 +38,6 @@
 $(LIBJAVA_HEADER_FLAGS) \
 #

-# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
-# a binary that is compatible with windows versions older than 7/2008R2.
-# See MSDN documentation for GetProcessMemoryInfo for more information.
-BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
-
 LIBMANAGEMENT_OPTIMIZATION := HIGH
 ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), )
   ifeq ($(ENABLE_DEBUG_SYMBOLS), true)
diff --git a/make/lib/Lib-jdk.management.gmk b/make/lib/Lib-jdk.management.gmk
--- a/make/lib/Lib-jdk.management.gmk
+++ b/make/lib/Lib-jdk.management.gmk
@@ -39,6 +39,11 @@
 $(LIBJAVA_HEADER_FLAGS) \
 #

+# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
+# a binary that is compatible with windows versions older than 7/2008R2.
+# See MSDN documentation for GetProcessMemoryInfo for more information.
+BUILD_LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1
+
 LIBMANAGEMENT_EXT_OPTIMIZATION := HIGH
 ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), )
   ifeq ($(ENABLE_DEBUG_SYMBOLS), true)

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

[Staffan Larsen]

 On 4 maj 2015, at 09:27, David Holmes david.hol...@oracle.com wrote:
 
 Hi Staffan,
 
 Seems fine as a spot fix but I'm wondering if this shouldn't be a common 
 option for all the dlls now we are building with VS2013?

I’ll let the build team comment on that.

/Staffan

 
 Thanks,
 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 GetProcessMemoryInfo from 
 management.dll to management_ext.dll. With the compiler upgrades 
 PSAPI_VERSION=1 is needed when compiling the library calling 
 GetProcessMemoryInfo. This fix simply moves that patch from 
 make/lib/Lib-java.management.gmk to make/lib/Lib-jdk.management.gmk. The 
 patch was introduced in JDK-8076557.
 
 I will push the change below directly to jdk9/hs.
 
 Thanks,
 /Staffan
 
 
 diff --git a/make/lib/Lib-java.management.gmk 
 b/make/lib/Lib-java.management.gmk
 --- a/make/lib/Lib-java.management.gmk
 +++ b/make/lib/Lib-java.management.gmk
 @@ -38,11 +38,6 @@
  $(LIBJAVA_HEADER_FLAGS) \
  #
 
 -# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
 -# a binary that is compatible with windows versions older than 7/2008R2.
 -# See MSDN documentation for GetProcessMemoryInfo for more information.
 -BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
 -
  LIBMANAGEMENT_OPTIMIZATION := HIGH
  ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), )
ifeq ($(ENABLE_DEBUG_SYMBOLS), true)
 diff --git a/make/lib/Lib-jdk.management.gmk 
 b/make/lib/Lib-jdk.management.gmk
 --- a/make/lib/Lib-jdk.management.gmk
 +++ b/make/lib/Lib-jdk.management.gmk
 @@ -39,6 +39,11 @@
  $(LIBJAVA_HEADER_FLAGS) \
  #
 
 +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
 +# a binary that is compatible with windows versions older than 7/2008R2.
 +# See MSDN documentation for GetProcessMemoryInfo for more information.
 +BUILD_LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1
 +
  LIBMANAGEMENT_EXT_OPTIMIZATION := HIGH
  ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), )
ifeq ($(ENABLE_DEBUG_SYMBOLS), true)
 

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

[Staffan Larsen]

Thanks for the reviews - the fix is now in the JPRT queue.

/Staffan

 On 4 maj 2015, at 11:11, Erik Joelsson erik.joels...@oracle.com wrote:
 
 
 On 2015-05-04 10:25, Staffan Larsen wrote:
 On 4 maj 2015, at 09:54, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com 
 wrote:
 
 
 4 maj 2015 kl. 09:27 skrev David Holmes david.hol...@oracle.com:
 
 Hi Staffan,
 
 Seems fine as a spot fix but I'm wondering if this shouldn't be a common 
 option for all the dlls now we are building with VS2013?
 Or maybe as a define in the source code before the include section for the 
 specific source code that needs a legacy version of GetProcessMemoryInfo? 
 That seems more prudent to me.
 In this case the function is called the same and works the same in 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.
 I think the placement suggested here is fine. It could be moved to configure 
 for global application, but I doubt it will ever be needed. As soon as we 
 drop support for Windows versions older than 7, we can remove this option.
 
 /Erik
 /Staffan
 
 /Magnus
 
 Thanks,
 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 GetProcessMemoryInfo from 
 management.dll to management_ext.dll. With the compiler upgrades 
 PSAPI_VERSION=1 is needed when compiling the library calling 
 GetProcessMemoryInfo. This fix simply moves that patch from 
 make/lib/Lib-java.management.gmk to make/lib/Lib-jdk.management.gmk. The 
 patch was introduced in JDK-8076557.
 
 I will push the change below directly to jdk9/hs.
 
 Thanks,
 /Staffan
 
 
 diff --git a/make/lib/Lib-java.management.gmk 
 b/make/lib/Lib-java.management.gmk
 --- a/make/lib/Lib-java.management.gmk
 +++ b/make/lib/Lib-java.management.gmk
 @@ -38,11 +38,6 @@
 $(LIBJAVA_HEADER_FLAGS) \
 #
 
 -# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
 -# a binary that is compatible with windows versions older than 7/2008R2.
 -# See MSDN documentation for GetProcessMemoryInfo for more information.
 -BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
 -
 LIBMANAGEMENT_OPTIMIZATION := HIGH
 ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), )
   ifeq ($(ENABLE_DEBUG_SYMBOLS), true)
 diff --git a/make/lib/Lib-jdk.management.gmk 
 b/make/lib/Lib-jdk.management.gmk
 --- a/make/lib/Lib-jdk.management.gmk
 +++ b/make/lib/Lib-jdk.management.gmk
 @@ -39,6 +39,11 @@
 $(LIBJAVA_HEADER_FLAGS) \
 #
 
 +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
 +# a binary that is compatible with windows versions older than 7/2008R2.
 +# See MSDN documentation for GetProcessMemoryInfo for more information.
 +BUILD_LIBMANAGEMENT_EXT_CFLAGS += -DPSAPI_VERSION=1
 +
 LIBMANAGEMENT_EXT_OPTIMIZATION := HIGH
 ifneq ($(findstring $(OPENJDK_TARGET_OS), solaris linux), )
   ifeq ($(ENABLE_DEBUG_SYMBOLS), true)

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

[Staffan Larsen]

Looks good!

Thanks,
/Staffan

 On 4 maj 2015, at 15:46, Erik Joelsson erik.joels...@oracle.com 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 compilers used internally at Oracle 
 to that specific version and to be able to continue that work, I need this to 
 be buildable now. For this reason I propose Peter Brunet's suggested solution 
 to the problem, just adding a C macro definition that makes it compile. I 
 slightly adjusted his initial proposal.
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8077422
 Patch:
 diff -r 83ff0dedf9e1 make/lib/Lib-jdk.hprof.agent.gmk
 --- a/make/lib/Lib-jdk.hprof.agent.gmk
 +++ b/make/lib/Lib-jdk.hprof.agent.gmk
 @@ -31,7 +31,7 @@
 
 BUILD_LIBHPROF_CFLAGS := $(addprefix -I, $(BUILD_LIBHPROF_SRC)) \
 -I$(JDK_TOPDIR)/src/demo/share/jvmti/java_crw_demo
 
 BUILD_LIBHPROF_LDFLAGS :=
 
 LIBHPROF_OPTIMIZATION := HIGHEST
 @@ -49,6 +49,7 @@
 CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \
 $(BUILD_LIBHPROF_CFLAGS), \
 CFLAGS_debug := -DHPROF_LOGGING, \
 +CFLAGS_windows := -D_WINSOCK_DEPRECATED_NO_WARNINGS, \
 MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \
 LDFLAGS := $(LDFLAGS_JDKLIB) \
 $(call SET_SHARED_LIBRARY_ORIGIN), \
 
 /Erik
 
 On 2015-04-23 00:02, Pete Brunet wrote:
 This hack to jdk/make/lib/Lib-jdk.hprof.agent.gmk works for now:
 
  LANG := C, \
  OPTIMIZATION := $(LIBHPROF_OPTIMIZATION), \
  CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \
 +-D_WINSOCK_DEPRECATED_NO_WARNINGS \
  $(BUILD_LIBHPROF_CFLAGS), \
  CFLAGS_debug := -DHPROF_LOGGING, \
  MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \
 
 Pete
 
 On 4/22/15 4:12 PM, Pete Brunet wrote:
 p.s. I also had done a make reconfigure and make clean.  I'll try make
 clean and reconfigure from bash.
 
 On 4/22/15 4:06 PM, Pete Brunet wrote:
 I was able to build 9 OK then I switched from VS2010 to VS2013 and now
 get the following.  I tried hg tpull -u but that didn't help.
 
 Is there something I need to do besides installing VS Pro 2013 with
 Update 4?
 
 $ make images 21 | tee make-64.log
 Building target 'images' in configuration
 'windows-x86_64-normal-server-release'
 
 c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
 : error C2220: warning treated as error - no 'object' file generated
 c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
 : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
 instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated
 API warnings
 c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see
 declaration of 'gethostbyname'
 Lib-jdk.hprof.agent.gmk:44: recipe for target
 '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h
 prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: ***
 [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj]
 Error 2
 make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed
 make[2]: *** [jdk.hprof.agent-libs] Error 1
 make[2]: *** Waiting for unfinished jobs
 /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255:
 recipe for target 'main' failed
 make[1]: *** [main] Error 1
 /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171:
 recipe for target 'images' failed
 make: *** [images] Error 2
 

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

[Staffan Larsen]

Looks good!

Thanks,
/Staffan

 On 27 apr 2015, at 12:25, Ingemar Aberg ingemar.ab...@oracle.com 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 the variables are defined so they are available to 
 the custom makefile.
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8074016
 
 Webrev: http://cr.openjdk.java.net/~sla/iaberg/8074016/webrev.00/
 
 /Ingemar

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

[Staffan Larsen]

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/browse/JDK-8066757
webrev: http://cr.openjdk.java.net/~sla/8066757/webrev.00 
http://cr.openjdk.java.net/~sla/8066757/webrev.00

Thanks,
/Staffan

RFR: 8076473 Remove the jhat code and update makefiles

[Staffan Larsen]

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 
https://bugs.openjdk.java.net/browse/JDK-8059039 
bug: https://bugs.openjdk.java.net/browse/JDK-8076473 
https://bugs.openjdk.java.net/browse/JDK-8076473

webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ 
http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/
webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ 
http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/

Thanks,
/Staffan

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

[Staffan Larsen]

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/ 
http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/

Thanks,
/Staffan

Re: RFR

[Staffan Larsen]

Looks good!

Thanks,
/Staffan

 On 7 apr 2015, at 17:15, Erik Joelsson erik.joels...@oracle.com 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 to CFLAGS, the problem goes 
 away.
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8076557
 Patch inline:
 
 diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk
 --- a/make/lib/Lib-java.management.gmk  Tue Apr 07 10:33:08 2015 +0100
 +++ b/make/lib/Lib-java.management.gmk  Tue Apr 07 17:11:29 2015 +0200
 @@ -38,6 +38,11 @@
 $(LIBJAVA_HEADER_FLAGS) \
 #
 
 +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
 +# a binary that is compatible with windows versions older than 7/2008R2.
 +# See MSDN documentation for GetProcessMemoryInfo for more information.
 +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
 +
 BUILD_LIBMANAGEMENT_EXCLUDES :=
 
 ifneq ($(OPENJDK_TARGET_OS), solaris)
 
 
 /Erik

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

[Staffan Larsen]

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://cr.openjdk.java.net/~sla/8075056/webrev.00/ 
http://cr.openjdk.java.net/~sla/8075056/webrev.00/

Thanks,
/Staffan

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

[Staffan Larsen]

Your expression looks good to me (and I verified that it solved the jconsole 
bug). I will push that.

Thanks,
/Staffan

 On 5 mar 2015, at 10:05, Erik Joelsson erik.joels...@oracle.com wrote:
 
 Hello,
 
 The specification for the properties file format says that a comment is a 
 line that has either a ! or # as the first non whitespace character. Greping 
 around in the source shows we have several instances if comments tarting a 
 few spaces in. I don't think we are using ! for comments anywhere though. 
 Using this expression seems to do the trick for me:
 
 's/^[ ]*#.*/#/g'
 
 Note that the contents of the [] is one space and a literal tab as \t is not 
 portable to all versions of sed that we use.
 
 The cleaning mechanism is hard to make really safe without semantic parsing. 
 Have you considered using the CompileProperties option instead? For most of 
 the resource bundles in the jdk, we convert the properties into java src. As 
 I understand it, resource bundles work seamlessly as classes or properties 
 files. I assume this is done for runtime performance. You could also choose 
 to just 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 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,choice,-1#
 
 The below diff fixes the problem. I added an extra ^ before the # so that 
 only # at the beginning of the line are treated as comments. I don’t know if 
 this has other implications, though? Should # anywhere on the line be 
 treated as the beginning of a comment? In that case we need to handle the 
 jconsole resource file specially.
 
 Thanks,
 /Staffan
 
 
 diff --git a/make/common/JavaCompilation.gmk 
 b/make/common/JavaCompilation.gmk
 --- a/make/common/JavaCompilation.gmk
 +++ b/make/common/JavaCompilation.gmk
 @@ -393,7 +393,7 @@
 $(MKDIR) -p $$(@D)
 export LC_ALL=C ; ( $(CAT) $$  $(ECHO)  ) \
 | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \
 - -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \
 + -e 's/\([^\\]\)!/\1\\!/g' -e 's/^#.*/#/g' \
 | $(SED) -f $(SRC_ROOT)/make/common/support/unicode2x.sed \
 | $(SED) -e '/^#/d' -e '/^/d' \
 -e :a -e '/\\/N; s/\\\n//; ta' \
 

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

[Staffan Larsen]

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,choice,-1# 

The below diff fixes the problem. I added an extra ^ before the # so that only 
# at the beginning of the line are treated as comments. I don’t know if this 
has other implications, though? Should # anywhere on the line be treated as the 
beginning of a comment? In that case we need to handle the jconsole resource 
file specially.

Thanks,
/Staffan


diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk 
--- a/make/common/JavaCompilation.gmk 
+++ b/make/common/JavaCompilation.gmk 
@@ -393,7 +393,7 @@ 
$(MKDIR) -p $$(@D) 
export LC_ALL=C ; ( $(CAT) $$  $(ECHO)  ) \ 
| $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \ 
- -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \ 
+ -e 's/\([^\\]\)!/\1\\!/g' -e 's/^#.*/#/g' \ 
| $(SED) -f $(SRC_ROOT)/make/common/support/unicode2x.sed \ 
| $(SED) -e '/^#/d' -e '/^/d' \ 
-e :a -e '/\\/N; s/\\\n//; ta' \ 

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

[Staffan Larsen]

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 magnus.ihse.bur...@oracle.com 
 wrote:
 
 On 2015-02-11 13:08, Staffan Larsen wrote:
 
 Okay so if I just cd into hotspot/test and use the Makefile to try
 and run some jtreg tests it looks to me that it will define an
 invalid -nativepath
 
 I'm not sure if that is a supported use case. David or Staffan will
 have to answer to that. I have not tested that, only the whole
 forest approach.
 
 I’ve never done that. I’m always running all make commands from the top
 level. Is there a problem with that?
 
 I must confess I also haven't done that - though I often run jtreg 
 directly from there. Other hotspot engineers may use it. If nothing else 
 it would be a way to test out what you expect JPRT to be running.
 
 But perhaps we just don't add the -nativepath component if TESTNATIVE_DIR 
 remains unset?
 
 Not adding -nativepath or adding it with an empty path will lead to the 
 same errors I think: tests that need native code will fail. So it does not 
 really matter.
 
 If you add it with an invalid path (won't be empty as the variable is only 
 a prefix) then tests that don't need native code may also fail. Though I 
 don't know how jtreg responds to a non-existent nativepath.
 
 You are right. Jtreg validates the that the path is a directory. So better 
 not to specify it.
 
 Ok. I have updated the webrev, so the -nativepath: argument is only specified 
 if we indeed have been given a valid path to the native libraries.
 
 The only changes between this and the previous webrev is in 
 hotspot/test/Makefile and jdk/test/Makefile.
 
 http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.02
  
 http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.02
 
 /Magnus

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

[Staffan Larsen]

 On 11 feb 2015, at 09:39, David Holmes david.hol...@oracle.com wrote:
 
 On 11/02/2015 6:34 PM, Staffan Larsen wrote:
 
 On 11 feb 2015, at 09:27, Magnus Ihse Bursie
 magnus.ihse.bur...@oracle.com mailto:magnus.ihse.bur...@oracle.com
 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 addition to the build system, that will compile native
 libraries and executables and make them available for JTReg tests
 written in Java.
 
 Sorry I'm missing the basics here: when does this compilation take
 place? As part of a normal build? Where will the build artifacts go?
 
 This is the first application of the new test-image/product-images
 separation we discussed previously. :)
 
 These tests are built as part of the test-image target. (Actually,
 they are built by individual rules like build-test-jdk-jtreg-native, and
 the relevant parts are put into the test image by
 test-image-jdk-jtreg-native, which test-image depends on.)
 
 Okay so if I just cd into hotspot/test and use the Makefile to try
 and run some jtreg tests it looks to me that it will define an
 invalid -nativepath
 
 I'm not sure if that is a supported use case. David or Staffan will
 have to answer to that. I have not tested that, only the whole
 forest approach.
 
 I’ve never done that. I’m always running all make commands from the top
 level. Is there a problem with that?
 
 I must confess I also haven't done that - though I often run jtreg directly 
 from there. Other hotspot engineers may use it. If nothing else it would be a 
 way to test out what you expect JPRT to be running.
 
 But perhaps we just don't add the -nativepath component if TESTNATIVE_DIR 
 remains unset?

Not adding -nativepath or adding it with an empty path will lead to the same 
errors I think: tests that need native code will fail. So it does not really 
matter.

/Staffan

 
 Cheers,
 David
 
 /Staffan
 
 
 /Magnus
 

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

[Staffan Larsen]

 On 11 feb 2015, at 09:27, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com 
 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 addition to the build system, that will compile native
 libraries and executables and make them available for JTReg tests
 written in Java.
 
 Sorry I'm missing the basics here: when does this compilation take
 place? As part of a normal build? Where will the build artifacts go?
 
 This is the first application of the new test-image/product-images
 separation we discussed previously. :)
 
 These tests are built as part of the test-image target. (Actually,
 they are built by individual rules like build-test-jdk-jtreg-native, and
 the relevant parts are put into the test image by
 test-image-jdk-jtreg-native, which test-image depends on.)
 
 Okay so if I just cd into hotspot/test and use the Makefile to try and run 
 some jtreg tests it looks to me that it will define an invalid -nativepath
 
 I'm not sure if that is a supported use case. David or Staffan will have to 
 answer to that. I have not tested that, only the whole forest approach.

I’ve never done that. I’m always running all make commands from the top level. 
Is there a problem with that?

/Staffan

 
 /Magnus

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

[Staffan Larsen]

 On 11 feb 2015, at 12:15, David Holmes david.hol...@oracle.com wrote:
 
 On 11/02/2015 8:36 PM, Staffan Larsen wrote:
 
 On 11 feb 2015, at 09:39, David Holmes david.hol...@oracle.com wrote:
 
 On 11/02/2015 6:34 PM, Staffan Larsen wrote:
 
 On 11 feb 2015, at 09:27, Magnus Ihse Bursie
 magnus.ihse.bur...@oracle.com mailto:magnus.ihse.bur...@oracle.com
 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 addition to the build system, that will compile native
 libraries and executables and make them available for JTReg tests
 written in Java.
 
 Sorry I'm missing the basics here: when does this compilation take
 place? As part of a normal build? Where will the build artifacts go?
 
 This is the first application of the new test-image/product-images
 separation we discussed previously. :)
 
 These tests are built as part of the test-image target. (Actually,
 they are built by individual rules like build-test-jdk-jtreg-native, and
 the relevant parts are put into the test image by
 test-image-jdk-jtreg-native, which test-image depends on.)
 
 Okay so if I just cd into hotspot/test and use the Makefile to try
 and run some jtreg tests it looks to me that it will define an
 invalid -nativepath
 
 I'm not sure if that is a supported use case. David or Staffan will
 have to answer to that. I have not tested that, only the whole
 forest approach.
 
 I’ve never done that. I’m always running all make commands from the top
 level. Is there a problem with that?
 
 I must confess I also haven't done that - though I often run jtreg directly 
 from there. Other hotspot engineers may use it. If nothing else it would be 
 a way to test out what you expect JPRT to be running.
 
 But perhaps we just don't add the -nativepath component if TESTNATIVE_DIR 
 remains unset?
 
 Not adding -nativepath or adding it with an empty path will lead to the same 
 errors I think: tests that need native code will fail. So it does not really 
 matter.
 
 If you add it with an invalid path (won't be empty as the variable is only a 
 prefix) then tests that don't need native code may also fail. Though I don't 
 know how jtreg responds to a non-existent nativepath.

You are right. Jtreg validates the that the path is a directory. So better not 
to specify it.

/Staffan

 
 David
 
 /Staffan
 
 
 Cheers,
 David
 
 /Staffan
 
 
 /Magnus

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

[Staffan Larsen]

 On 10 feb 2015, at 15:23, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com 
 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, mostly) of Staffan Larsen, 
 David Simms and me. (And possible more that I don't know about.)
 
 In it current form, the patch only provides the framework on which to attach 
 real tests. To prove the concept, some initial dummy tests are present. These 
 are supposed to be removed as soon as real tests starts to propagate into the 
 jdk and hotspot jtreg test suites.
 
 The behavior is based on the following design: For directories with native 
 jtreg compilation enabled, the build system searches for native files 
 prefixed with either lib or exe, and compiles a free-standing library or 
 an executable, respectively, for each such file. Since all compiled files are 
 placed in a single directory (this is currently a requirement from the jtreg 
 native support), there is the additional requirement that all files have 
 unique names.
 
 My personal opinion is that a better long-term approach is to compile all 
 tests into a single library, if possible. (I realize some tests need to be 
 separate to test library loading, etc.) For that to work, however, JTReg 
 needs to be changed. The build framework in the patch is designed in such a 
 way that it will be easy to add compilation to a common library in the 
 future, if that restriction is lifted from JTReg.

To clarify: The restriction in jtreg is that all tests are loaded in separate 
class loaders (when running in samevm mode). A native library can only be 
loaded in one class loader at a time. So if two tests tries to load the same 
library we get errors. It would be possible to change this if samevm mode is 
removed from jtreg.

/Staffan

 
 This patch also lays the foundation for building additional tests, not only 
 native jtreg tests, by the build system in the future. For instance, it 
 codifies the suggested correspondence between make targets, intermediate test 
 output and test image final build results. With the on-going test co-location 
 project, we expect a stream of tests to be added to the build system in the 
 future, and we hope this project can serve as an example of a suitable way of 
 integration.
 
 The patch modifies hotspot code, but it's mostly due to the addition of the 
 new dummy tests. My preference would be to integrate this patch via jdk9-dev, 
 since it modifies the build system most of all, but I'm open for discussion.
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8072842
 WebRev: 
 http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01
 
 /Magnus

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

[Staffan Larsen]

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 erik.joels...@oracle.com wrote:
 
 Hello,
 
 Any chance someone from serviceability could take a look at this?
 
 /Erik
 
 On 2015-01-12 03:45, David Holmes wrote:
 Hi Erik,
 
 On 10/01/2015 12:34 AM, Erik Joelsson wrote:
 Hello,
 
 Please review this patch which fixes the verify-modules target when
 running bootcycle build, and also reenables verify-modules when running
 make images.
 
 There were two problems:
 
 * The bootcycle build configuration was broken so that both the normal
 and the bootcycle build used the same HOTSPOT_DIST directory. The
 consequence of this was that verify-modules worked when run on its own,
 but not if bootcycle-images had been run before. This is fixed in
 bootcycle-spec.gmk.in.
 
 * Since javac in JDK 9 no longer emits classes for implicitly compiled
 sources, certain classes in sa-jdi.jar were not compiled during the
 bootcycle build. I fixed this by adding the missing classes to sa.files.
 Not having the classes there might have been intentional (in at least
 some cases), but since they were compiled anyway, I felt it safer to
 just add them to the list to fix this issue. If these classes shouldn't
 be included, then they need to be properly removed in a followup fix.
 
 SA is owned by serviceability - cc'd. Changes seem okay as a solution to 
 immediate problem, but I don't think anyone expects the IA64 stuff to still 
 be needed. It is on the todo list to eradicate IA64 IIRC.
 
 Looks like there is limited awareness of the need to keep sa.files up to 
 date. :(
 
 Thanks,
 David
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8067479
 Webrev: http://cr.openjdk.java.net/~erikj/8067479/webrev.01/
 
 Since this is changing hotspot, I assume it will need to go in through a
 hotspot forest. Which one?
 
 /Erik
 

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

[Staffan Larsen]

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 2014, at 00:52, David Holmes david.hol...@oracle.com wrote:
 
 Hi Chris,
 
 Sorry I mis-directed you to send this one to build-dev, as it is a hotspot 
 test/Makefile fix it should be reviewed by hotspot-dev now cc'd.
 
 Fix looks good to me.
 
 Thanks,
 David
 
 On 5/12/2014 6:37 AM, Chris Plummer wrote:
 Please review the following fix to address JPRT timeout issues when
 using -rtests to run hotspot JTReg tests on slow devices. The same logic
 has been in place for jdk/test/Makefile for a while now, so I just
 copied from there to hotspot/test/Makefile.
 
 https://bugs.openjdk.java.net/browse/JDK-8066508
 http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
 
 thanks,
 
 Chris
 

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

[Staffan Larsen]

 On 5 dec 2014, at 10:22, David Holmes david.hol...@oracle.com 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). Ideally the timeout factor should be tuned according to the 
 machine type we are running on. I’m not sure that is possible, though?
 
 We don't have that level of control unfortunately.

Too bad.

/Staffan

 
 David
 
 On 5 dec 2014, at 00:52, David Holmes david.hol...@oracle.com wrote:
 
 Hi Chris,
 
 Sorry I mis-directed you to send this one to build-dev, as it is a hotspot 
 test/Makefile fix it should be reviewed by hotspot-dev now cc'd.
 
 Fix looks good to me.
 
 Thanks,
 David
 
 On 5/12/2014 6:37 AM, Chris Plummer wrote:
 Please review the following fix to address JPRT timeout issues when
 using -rtests to run hotspot JTReg tests on slow devices. The same logic
 has been in place for jdk/test/Makefile for a while now, so I just
 copied from there to hotspot/test/Makefile.
 
 https://bugs.openjdk.java.net/browse/JDK-8066508
 http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
 
 thanks,
 
 Chris
 
 

Re: build warnings

[Staffan Larsen]

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 jonathan.gibb...@oracle.com wrote:
 
 Build folk,
 
 The build has always generated warnings (sigh!) but right now, the warnings 
 look scarier than usual.
 
 In particular, when the build terminates, I get a couple of screenfuls of 
 messages like this:
 
 /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:
  In function ‘SplashScreenThread’:
 /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9:
  warning: ignoring return value of ‘pipe’, declared with attribute 
 warn_unused_result [-Wunused-result]
 pipe(splash-controlpipe);
 ^
 /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:
  In function ‘initFormat’:
 /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34:
  warning: ‘numBits’ may be used uninitialized in this function 
 [-Wmaybe-uninitialized]
 format-shift[i] = shift + numBits - i * 8 - 8;
  ^
 
 What would it take to have some sort of campaign to reduce build warnings 
 like these?  We've made good progress on lint and doclint warnings for Java 
 code and doc comments; what does it take to start on native code warnings?
 
 -- Jon

Re: Building openjdk 8 on Mac OS X

[Staffan Larsen]

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 manasthaku...@gmail.com wrote:
 
 Thanks for the reply Magnus. Here are the error logs that get generated:
 
 Compiling 
 /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp
 Making signal interposition lib...
 couldn't understand kern.osversion `14.0.0'
 warning: (x86_64) 
 /var/folders/16/5m_yzyd961b3l31crzg2hsl4gp/T//ccEmbC6U.o unable to open 
 object file
 warning: no debug symbols in executable (-arch x86_64)
 Making SA debugger back-end...
 couldn't understand kern.osversion `14.0.0'
 In file included from 
 /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:55,
 from 
 /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12,
 from 
 /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80,
 from 
 /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
 /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:262:
  error: expected ‘,’ or ‘}’ before ‘__attribute__’
 /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:414:
  error: expected ‘,’ or ‘}’ before ‘__attribute__’
 In file included from 
 /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:119,
 from 
 /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
 /System/Library/Frameworks/Foundation.framework/Headers/NSUserActivity.h:55: 
 error: expected a property attribute before ‘weak’
 Compiling 
 /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/runtime/vm_version.cpp
 In file included from 
 /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:171,
 from 
 /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
 /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16:
  error: expected ‘,’ or ‘}’ before ‘__attribute__’
 make[8]: *** [libsaproc.dylib] Error 1
 make[8]: *** Waiting for unfinished jobs
 make[7]: *** [the_vm] Error 2
 make[6]: *** [product] Error 2
 make[5]: *** [generic_build2] Error 2
 make[4]: *** [product] Error 2
 make[3]: *** [all_product_universal] Error 2
 make[2]: *** [universal_product] Error 2
 make[1]: *** 
 [/Users/manas/Desktop/Software/openjdk/sources/openjdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
  Error 2
 make: *** [hotspot-only] Error 2
 
 Can you suggest me some workaround(s)?
 
 - Manas

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

[Staffan Larsen]

This one looks like it has already been pushed by Erik.

/Staffan

On 21 okt 2014, at 13:50, David Simms david.si...@oracle.com 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_OUTPUTDIR.
 
 Bug here: https://bugs.openjdk.java.net/browse/JDK-8061610
 Patch here: http://cr.openjdk.java.net/~dsimms/8061610/
 
 Testing: JDK JPRT and local make test
 
 Cheers
 /Mr. Simms

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

[Staffan Larsen]

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 unified.

/Staffan

On 26 aug 2014, at 12:40, Daniel Fuchs daniel.fu...@oracle.com wrote:

 Hi Mandy,
 
 I'm seeing some small differences in the various VirtualMachineImpl.java
 files, but if I'm not mistaken, all the new AttachProviderImpl.java look
 all the same. I wonder if the patch could be further simplified by
 moving AttachProviderImpl.java to jdk.attach/share/classes (unless
 there's a reason to keep all the different copies)...
 
 best regards,
 
 -- daniel
 
 On 8/26/14 6:29 AM, 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 simplifies the build logic and
 removes the need for generating the service config file at build time.
 
 The files renamed are
unix/classes/sun/tools/attach/${OS}VirtualMachine.java
  - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
unix/classes/sun/tools/attach/${OS}AttachProvider.java
  - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
 
${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java
  - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
${OS}/classes/sun/tools/attach/${OS}AttachProvider.java
  - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
 
 and also corresponding native files.
 
 Mandy
 
 
 

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

[Staffan Larsen]

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 21 aug 2014, at 13:02, Erik Joelsson erik.joels...@oracle.com wrote:

 Hello,
 
 Please review this minor fix for hprof demo on aix. When reorganizing the 
 source code for modules, we put a copy of src/aix/porting/porting_aix.* in 
 each of the two locations using it. One of them was the hprof demo. This 
 patch removes the now unused extra source dir declaration for hprof.
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8055352
 Patch inline:
 
 diff -r b8f27b54cc51 make/CompileDemos.gmk
 --- a/make/CompileDemos.gmk
 +++ b/make/CompileDemos.gmk
 @@ -315,17 +315,8 @@
 $(eval $(call SetupJVMTIDemo,heapTracker, agent_util java_crw_demo))
 $(eval $(call SetupJVMTIDemo,heapViewer, agent_util))
 
 -# On AIX, hprof requires 'dladdr' from src/aix/porting/porting_aix.cpp
 -BUILD_LIBHPROF_AIX_EXTRA_SRC :=
 -BUILD_LIBHPROF_AIX_EXTRA_CFLAGS :=
 -ifeq ($(OPENJDK_TARGET_OS), aix)
 -  BUILD_LIBHPROF_AIX_EXTRA_SRC += $(JDK_TOPDIR)/src/aix/porting
 -  BUILD_LIBHPROF_AIX_EXTRA_CFLAGS += -I$(JDK_TOPDIR)/src/aix/porting
 -endif
 -
 -$(eval $(call SetupJVMTIDemo,hprof, java_crw_demo, \
 -$(BUILD_LIBHPROF_AIX_EXTRA_CFLAGS), C, \
 --ldl, ws2_32.lib winmm.lib, -lsocket -lnsl, -lpthread, 
 $(BUILD_LIBHPROF_AIX_EXTRA_SRC)))
 +$(eval $(call SetupJVMTIDemo,hprof, java_crw_demo,, \
 +C, -ldl, ws2_32.lib winmm.lib, -lsocket -lnsl, -lpthread))
 
 $(eval $(call SetupJVMTIDemo,minst, agent_util java_crw_demo))
 $(eval $(call SetupJVMTIDemo,mtrace, agent_util java_crw_demo))
 
 /Erik

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

[Staffan Larsen]

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

RFR: JDK-8043981 Remove the JPDA demo

[Staffan Larsen]

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.

bug: https://bugs.openjdk.java.net/browse/JDK-8043981
webrev: http://cr.openjdk.java.net/~sla/8043981/webrev.00/

Thanks,
/Staffan

Re: RFR: JDK-8043981 Remove the JPDA demo

[Staffan Larsen]

On 25 aug 2014, at 15:59, Alan Bateman alan.bate...@oracle.com 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 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.
 
 bug: https://bugs.openjdk.java.net/browse/JDK-8043981
 webrev: http://cr.openjdk.java.net/~sla/8043981/webrev.00/
 
 Good to see this going away, it also addresses one of Magnus' recent comments 
 here about jpda/src.zip being built from sources in two locations (a 
 consequence of the code being used for two things).
 
 The changes looks okay to me. A passing comment is that the move of Expr.jj 
 is a reminder that we have generated code checked-in but that has been the 
 case for a long time.

Thanks Alan.

Yes, Ideally we should run JavaCC during the build on Expr.jj, but that adds a 
dependency and execution time for something that is very rarely changed.

/Staffan

 
 -Alan.
 

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

[Staffan Larsen]

On 25 aug 2014, at 16:15, Alan Bateman alan.bate...@oracle.com 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.
 
 bug: https://bugs.openjdk.java.net/browse/JDK-8043936
 webrev: http://cr.openjdk.java.net/~sla/8043936/webrev.00/
 
 The move of the source code to native/libhprof looks good.
 
 Having the README and manual in the same directory is probably okay as it has 
 always lived in the same directory as the source code. One thing is check is 
 the contents of manual.html as there is at least one place where it 
 references the directory demo/jvmti/hprof.

Good point. I have removed the section about Source Code in the latest version 
since all OpenJDK source code can be found at the same place:

http://cr.openjdk.java.net/~sla/8043936/webrev.01/

I plan to push this version tomorrow unless someone shouts ;)

Thanks,
/Staffan

 
 I assume Erik or Magnus will check the make changes, I don't see any issues.
 
 -Alan
 

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

[Staffan Larsen]

Ahh. The simplicity!

Looks good!

Thanks,
/Staffan

On 26 aug 2014, at 06:29, Mandy Chung mandy.ch...@oracle.com 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 simplifies the build logic and
 removes the need for generating the service config file at build time.
 
 The files renamed are
   unix/classes/sun/tools/attach/${OS}VirtualMachine.java
 - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
   unix/classes/sun/tools/attach/${OS}AttachProvider.java
 - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
 
   ${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java
 - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
   ${OS}/classes/sun/tools/attach/${OS}AttachProvider.java
 - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
 
 and also corresponding native files.
 
 Mandy
 
 

Re: Update compiler workarounds for Clang 6.0

[Staffan Larsen]

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 
 alexandr.scherba...@oracle.com wrote:
 
 
 Hi,
 
 I got the following message during building the JDK 9 on Mac OS X 10.10 
 Yosemity:
 
 Compiling 32 properties into resource bundles
 /Users/alexsch/openjdk/jdk9-modules/hotspot/make/bsd/makefiles/gcc.make:329: 
 *** Update compiler workarounds for Clang 6.0.  Stop.
 
 
 The installed gcc is:
 -
  gcc --version
 Configured with: --prefix=/Library/Developer/CommandLineTools/usr 
 --with-gxx-include-dir=/usr/include/c++/4.2.1
 Apple LLVM version 6.0 (clang-600.0.38) (based on LLVM 3.5svn)
 Target: x86_64-apple-darwin14.0.0
 Thread model: posix
 -
 
 I also needs to remove the -Werror flag because the compiler gives some 
 warnings that are treated as errors.
 
 Thanks,
 Alexandr.
 

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

[Staffan Larsen]

Looks good!

Thanks,
/Staffan

On 9 maj 2014, at 23:32, Mikael Vidstedt mikael.vidst...@oracle.com 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 implementation does this by simply 
 delegating to the hotspot/test/Makefile - again, much like the jdk, langtools 
 logic does.
 
 * Bug:
 
 https://bugs.openjdk.java.net/browse/JDK-8042804
 
 * Webrevs
 
 top: http://cr.openjdk.java.net/~mikael/webrevs/8042804/webrev.00/top/
 hotspot: 
 http://cr.openjdk.java.net/~mikael/webrevs/8042804/webrev.00/hotspot/webrev/
 
 Thanks,
 Mikael
 

Re: Proposal: jtreg tests with native components

[Staffan Larsen]

On 1 maj 2014, at 07:45, David Holmes david.hol...@oracle.com wrote:

 On 30/04/2014 9:39 PM, Staffan Larsen wrote:
 
 On 30 apr 2014, at 11:39, David Holmes david.hol...@oracle.com 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:
 
 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, …) when the test is 
 being run.
 
 Neither of these are very good solutions. #1 makes it hard to run the 
 setup the test for all platforms and requires binaries in the source 
 control system. #2 is hit-and-miss: the correct compiler may or may not be 
 installed on the test machine, and the approach requires platform specific 
 logic to be maintained.
 
 #2 is far from perfect but ...
 
 I would like to propose that these native components are instead compiled 
 when the product is built by the same makefile logic as the product. At 
 product build time we know we have access to the (correct) compilers and 
 we have excellent support in the makefiles for building on all platforms.
 
 If we build the native test components together with the product, we also 
 have to take care of distributing the result together with the product 
 when we do testing across a larger number of machines. We will also need a 
 way to tell the jtreg tests where these pre-built binaries are located.
 
 don't under estimate the complexity involved in building then 
 distributing the test binaries.
 
 I don’t. It will be complicated, but I’m sure we can do it.
 
 The question is whether it is worth it relative to the size of the problem.

I think we will see a large influx of these kinds of tests, especially in the 
hotspot repo.

 
 
 You will still need to maintain platform specific logic as you won't 
 necessarily be able to use the CFLAGS etc that the main build process uses.
 
 Can you explain more? Why can’t I use CFLAGS as it is?
 
 You _may_ be able to, you may not. I know we already had issues where the 
 CFLAGS as being used for the JDK sources also got applied to building the 
 code-generator utility programs and that didn't work correctly. Here's sample 
 CFLAGS from a JDK build
 
 CFLAGS_JDKLIB:=  -W -Wall -Wno-unused -Wno-parentheses   -pipe  
 -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer  
 -D_LITTLE_ENDIAN -DLINUX -DNDEBUG -DARCH='i586' -Di586 
 -DRELEASE='$(RELEASE)' 
 -I/export/users/dh198349/ejdk8u-dev/build/b13/linux-i586-ea/jdk/include 
 -I/export/users/dh198349/ejdk8u-dev/build/b13/linux-i586-ea/jdk/include/linux 
   -I/export/users/dh198349/jdk8u-dev/jdk/src/share/javavm/export 
 -I/export/users/dh198349/jdk8u-dev/jdk/src/solaris/javavm/export 
 -I/export/users/dh198349/jdk8u-dev/jdk/src/share/native/common   
 -I/export/users/dh198349/jdk8u-dev/jdk/src/solaris/native/common -m32  
 -fno-strict-aliasing -fPIC
 
 Does that make sense for compiling a test? Does it depend on whether we are 
 building a native library or a native executable?

I think they make sense, at least initially. If not, we can tune them, but that 
tuning” will be in one central location and not spread out in a lot of shell 
scripts. I also plan to allow individual tests to override the flags if 
necessary (for example to link with X11). 

For executables there is CFLAGS_JDKEXE. 

Thanks,
/Staffan

 
 
 Also talk to SQE as I'm pretty sure there is an existing project to look at 
 how to better handle this, at least for the internal test suites.
 
 I have talked to SQE. I don’t know of any other projects to handle this.
 
 :) It wasn't SQE, it was your project as referenced in a few bug reports last 
 August/September.
 
 David
 
 
 /Staffan
 
 
 
 David
 -
 
 I suggest that at the end of a distributed build run, the pre-built test 
 binaries are packaged in a zip or tar file (just like the product bits) 
 and stored next to the product bundles. When we run distributed tests, we 
 need to pick up the product bundle and the test bundle before the testing 
 is started.
 
 To tell the tests where the native code is, I would like to add a flag to 
 jtreg to point out the path to the binaries. This should cause jtreg to 
 set java.library.path before invoking a test and also set a test.* 
 property which can be used by test to find it’s native components.
 
 This kind of setup would make it easier to add and maintain tests that 
 have a native component. I think this will be especially important as more 
 tests are written using jtreg in the hotspot repository.
 
 Thoughts on this? Is the general approach ok? There are lots of details to 
 be figured out, but at this stage I would like to hear feedback on the 
 idea as such.
 
 Thanks,
 /Staffan
 
 

Re: Proposal: jtreg tests with native components

[Staffan Larsen]

On 30 apr 2014, at 11:39, David Holmes david.hol...@oracle.com 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:
 
 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, …) when the test is 
 being run.
 
 Neither of these are very good solutions. #1 makes it hard to run the setup 
 the test for all platforms and requires binaries in the source control 
 system. #2 is hit-and-miss: the correct compiler may or may not be installed 
 on the test machine, and the approach requires platform specific logic to be 
 maintained.
 
 #2 is far from perfect but ...
 
 I would like to propose that these native components are instead compiled 
 when the product is built by the same makefile logic as the product. At 
 product build time we know we have access to the (correct) compilers and we 
 have excellent support in the makefiles for building on all platforms.
 
 If we build the native test components together with the product, we also 
 have to take care of distributing the result together with the product when 
 we do testing across a larger number of machines. We will also need a way to 
 tell the jtreg tests where these pre-built binaries are located.
 
 don't under estimate the complexity involved in building then distributing 
 the test binaries.

I don’t. It will be complicated, but I’m sure we can do it.

 
 You will still need to maintain platform specific logic as you won't 
 necessarily be able to use the CFLAGS etc that the main build process uses.

Can you explain more? Why can’t I use CFLAGS as it is?

 
 Also talk to SQE as I'm pretty sure there is an existing project to look at 
 how to better handle this, at least for the internal test suites.

I have talked to SQE. I don’t know of any other projects to handle this.

/Staffan


 
 David
 -
 
 I suggest that at the end of a distributed build run, the pre-built test 
 binaries are packaged in a zip or tar file (just like the product bits) and 
 stored next to the product bundles. When we run distributed tests, we need 
 to pick up the product bundle and the test bundle before the testing is 
 started.
 
 To tell the tests where the native code is, I would like to add a flag to 
 jtreg to point out the path to the binaries. This should cause jtreg to set 
 java.library.path before invoking a test and also set a test.* property 
 which can be used by test to find it’s native components.
 
 This kind of setup would make it easier to add and maintain tests that have 
 a native component. I think this will be especially important as more tests 
 are written using jtreg in the hotspot repository.
 
 Thoughts on this? Is the general approach ok? There are lots of details to 
 be figured out, but at this stage I would like to hear feedback on the idea 
 as such.
 
 Thanks,
 /Staffan
 

Re: Proposal: jtreg tests with native components

[Staffan Larsen]

On 25 apr 2014, at 17:31, Jonathan Gibbons jonathan.gibb...@oracle.com wrote:

 I'll quibble over the phrase the same makefile logic.
 
 I think it is OK to use the same Makefile infrastructure (e.g. the 
 configure.sh mechanism) and the same top level Makefile, but at some level 
 this is going to need to be distinct Makefile logic specific to compiling the 
 code for the tests.

Yes, of course there will be specific makefile logic to compile the code for 
the tests. What I intended to say was that we can to a significant degree 
leverage the work that has already been done with the “other” makefiles. For 
example, there is configure step that sets up all of the environment, there are 
utility functions that can be used (SetupNativeCompilation in this case) and so 
on. It just makes sense to compile the tests in the same way.

 I agree with the general concept of pre-building binaries, but it would be 
 good to see the next level of detail:

Agree that there are lots of details that need answers. I have started to 
develop a proof-of-concept and I can share some of the choices I’ve made below.

 -- where is the source code for the native code of the tests

I choose to put the native source code in the same directory next to the Java 
test code. That makes it easy to see both the Java and native code at the same 
time.

I wanted to make it easy to add a new native library and have it compiled, so 
by default the makefiles picks up any C source files and compiles them into 
libraries, one library per file. By default, the libraries will be named 
according to the name of the C file, so a file called libMyTest.c will be 
compiled into libMyTest.so (or MyTest.dll). This is to make simple things 
simple.

However, if you need to do something more complicated, you can add a makefile 
to the directory and that file will be invoked instead. It then has the full 
power to compile the native code as it sees fit.

 -- is it one library per test, or what

I think we can leave that up to the test. According to the above, there can be 
any number of C files in a test folder and they will all be compiled. A test 
can then load (System.loadLibrary()) on or more of these at runtime.

 -- what sort of hierarchy do the libraries end up in.

In my implementation I choose to make this as simple as possible and had all 
libraries end up in the same output folder. I realize this will create problems 
if two libraries have the same name. We can avoid this by having a naming 
convention for test libraries that minimizes conflicts. We can also add 
makefile logic to detect problems at compile-time. 

Because I use the existing makefile framework, the output folder is specific to 
the makefile configuration you currently use. I my implementation I have used 
$JDK_OUTPUTDIR/test/native which translates to something like 
build/macosx-x86_64-normal-server-release/jdk/test/native/.

Having a single output folder makes it easy to setup the correct 
java.library.path for a test: they all use the same path.

 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 rerun it.For myself, I 
 don't work on native code, or on repos containing native code, so I'd be 
 interested to hear how this will impact developers working on tests, and on 
 those folk that simply want to run the tests.

Yes, this is indeed the largest problem to solve here and I want to keep the 
feature of simple edit-rerun cycles. On the other hand, I don’t want to 
complicate jtreg so that it has know anything about how to compile native code 
or invoke makefiles. I have instead chosen to use the makefile “test” target as 
the way to run tests and make sure native tests are recompiled. In this case, 
if you edit a native test you would run “make test” (possibly with some more 
arguments) and that would compile the test libraries (and the product) and then 
call jtreg. Because there is no way (that I can think of at least) for jtreg to 
know where the compiled test libraries are located, the invokation of jtreg 
will have to include that path as an argument to jtreg.

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. You would then have to tell jtreg 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 AM, 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 checked into the repository (often 
 inside jar files).
 2) The test

Re: Proposal: jtreg tests with native components

[Staffan Larsen]

On 25 apr 2014, at 18:09, Martin Buchholz marti...@google.com wrote:

 I don't see a good solution.  Conceptually, the tests are built/executed
 independently of the jdk they are testing.  But it would be crazy to have a
 separate configure/make infrastructure for each native test.  If you build
 the test native bits together with the jdk, you would have to be careful
 not to copy those bits into real deployed jdks.

That is why I was proposing a separate bundle for the tests. One zip with the 
product bits. One zip with the pre-compiled tests.

 Here's an idea: you can ask a jdk how it was configured/built and reuse
 that to build tests.  There's prior art, e.g. emacs remembers how it was
 configured (but that's not enough to let you build compatible test
 binaries).

That still has the problem that most tests machines are not setup to build 
things. On linux it may be reasonable to assume that gcc is installed, but what 
version? On windows, there are no compilers by default. What if a machine is 
used for testing several different versions of the JDK using many different 
compilers? How do we find the correct one? It may not be installed in the same 
location as on the build machine.

These were all problems that I tried to attack by compiling the tests when the 
product is built. At that point we have the configuration set up.

Thanks,
/Staffan


 
 system-configuration-options is a variable defined in `C source code'.
 Its value is
  '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu' '--prefix=/usr'
 '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
 '--localstatedir=/var/lib' '--infodir=/usr/share/info'
 '--mandir=/usr/share/man' '--with-pop=yes'
 '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.3/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.3/leim'
 '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
 '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars'
 'build_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g'
 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
 
 Documentation:
 String containing the configuration options Emacs was built with.
 
 
 
 On Fri, Apr 25, 2014 at 8:31 AM, Jonathan Gibbons 
 jonathan.gibb...@oracle.com wrote:
 
 I'll quibble over the phrase the same makefile logic.
 
 I think it is OK to use the same Makefile infrastructure (e.g. the
 configure.sh mechanism) and the same top level Makefile, but at some level
 this is going to need to be distinct Makefile logic specific to compiling
 the code for the tests.
 
 I agree with the general concept of pre-building binaries, but it would be
 good to see the next level of detail:
 
 -- where is the source code for the native code of the tests
 -- is it one library per test, or what
 -- 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
 rerun it.For myself, I don't work on native code, or on repos
 containing native code, so I'd be interested to hear how this will impact
 developers working on tests, and on those folk that simply want to run the
 tests.
 
 -- Jon
 
 
 
 On 04/25/2014 05:02 AM, 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 checked into the repository (often
 inside jar files).
 2) The test will try to invoke a compiler (gcc, cl, …) when the test is
 being run.
 
 Neither of these are very good solutions. #1 makes it hard to run the
 setup the test for all platforms and requires binaries in the source
 control system. #2 is hit-and-miss: the correct compiler may or may not be
 installed on the test machine, and the approach requires platform specific
 logic to be maintained.
 
 I would like to propose that these native components are instead compiled
 when the product is built by the same makefile logic as the product. At
 product build time we know we have access to the (correct) compilers and we
 have excellent support in the makefiles for building on all platforms.
 
 If we build the native test components together with the product, we also
 have to take care of distributing the result together with the product when
 we do testing across a larger number of machines. We will also need a way
 to tell the jtreg tests where these pre-built binaries are located.
 
 I suggest that at the end of a distributed build run, the pre-built test
 binaries are packaged in a zip or tar file (just like the product bits) and
 stored next to the product bundles. When we run distributed tests, we need
 to pick up the product bundle and the test bundle before the testing is
 started.
 
 To tell the tests where the native code is, I would like to add

Re: Proposal: jtreg tests with native components

[Staffan Larsen]

On 28 apr 2014, at 19:31, Jonathan Gibbons jonathan.gibb...@oracle.com 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. You would then have to tell jtreg where the compiled tests are.
 
 There should be a separate test-bundle target so you can go make 
 test-bundle without running the tests.

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 actual bundling (zipping, tarring) of the files (and maybe that was 
what you were referring to?). The makesfiles today do not have logic for 
creating these bundles, even for the product. The closest you get for the 
product is “images” which will create an exploded bundle (what it looks like 
before you tar/zip it). This is also what I do for build-tests”. Still would 
like a better name.

/Staffan

Re: Proposal: jtreg tests with native components

[Staffan Larsen]

The change in jtreg that I would like to see is the addition of a flag to 
specify the path of the test binaries. I’m thinking something like 
“-natives:path”. This would do two things:

- Set the java.library.path when invoking tests. This is needed for 
System.loadLibrary() to work.
- Set a test.natives property. This is needed in the cases where the test 
binary is not a library, but a program. In this case the test will want to 
launch that program and needs the path to the program.

Both of these would be set to path above. Jtreg should check that the path 
exists.

Does that sound like a reasonable change?

Thanks,
/Staffan


On 25 apr 2014, at 14:02, Staffan Larsen staffan.lar...@oracle.com 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 checked into the repository (often 
 inside jar files).
 2) The test will try to invoke a compiler (gcc, cl, …) when the test is being 
 run.
 
 Neither of these are very good solutions. #1 makes it hard to run the setup 
 the test for all platforms and requires binaries in the source control 
 system. #2 is hit-and-miss: the correct compiler may or may not be installed 
 on the test machine, and the approach requires platform specific logic to be 
 maintained.
 
 I would like to propose that these native components are instead compiled 
 when the product is built by the same makefile logic as the product. At 
 product build time we know we have access to the (correct) compilers and we 
 have excellent support in the makefiles for building on all platforms.
 
 If we build the native test components together with the product, we also 
 have to take care of distributing the result together with the product when 
 we do testing across a larger number of machines. We will also need a way to 
 tell the jtreg tests where these pre-built binaries are located.
 
 I suggest that at the end of a distributed build run, the pre-built test 
 binaries are packaged in a zip or tar file (just like the product bits) and 
 stored next to the product bundles. When we run distributed tests, we need to 
 pick up the product bundle and the test bundle before the testing is started.
 
 To tell the tests where the native code is, I would like to add a flag to 
 jtreg to point out the path to the binaries. This should cause jtreg to set 
 java.library.path before invoking a test and also set a test.* property which 
 can be used by test to find it’s native components.
 
 This kind of setup would make it easier to add and maintain tests that have a 
 native component. I think this will be especially important as more tests are 
 written using jtreg in the hotspot repository.
 
 Thoughts on this? Is the general approach ok? There are lots of details to be 
 figured out, but at this stage I would like to hear feedback on the idea as 
 such.
 
 Thanks,
 /Staffan
 

Re: Proposal: jtreg tests with native components

[Staffan Larsen]

On 28 apr 2014, at 20:05, Jonathan Gibbons jonathan.gibb...@oracle.com 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 actual bundling (zipping, tarring) of the files (and maybe that was 
 what you were referring to?). The makesfiles today do not have logic for 
 creating these bundles, even for the product. The closest you get for the 
 product is “images” which will create an exploded bundle (what it looks like 
 before you tar/zip it). This is also what I do for build-tests”. Still 
 would like a better name.
 
 /Staffan
 
 As long as there is a way of making the artifacts to be used by the tests 
 that is enough for those folk that want to run jtreg directly.

Absolutely!

 
 -- Jon

Proposal: jtreg tests with native components

[Staffan Larsen]

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, …) when the test is being 
run.

Neither of these are very good solutions. #1 makes it hard to run the setup the 
test for all platforms and requires binaries in the source control system. #2 
is hit-and-miss: the correct compiler may or may not be installed on the test 
machine, and the approach requires platform specific logic to be maintained.

I would like to propose that these native components are instead compiled when 
the product is built by the same makefile logic as the product. At product 
build time we know we have access to the (correct) compilers and we have 
excellent support in the makefiles for building on all platforms.

If we build the native test components together with the product, we also have 
to take care of distributing the result together with the product when we do 
testing across a larger number of machines. We will also need a way to tell the 
jtreg tests where these pre-built binaries are located.

I suggest that at the end of a distributed build run, the pre-built test 
binaries are packaged in a zip or tar file (just like the product bits) and 
stored next to the product bundles. When we run distributed tests, we need to 
pick up the product bundle and the test bundle before the testing is started.

To tell the tests where the native code is, I would like to add a flag to jtreg 
to point out the path to the binaries. This should cause jtreg to set 
java.library.path before invoking a test and also set a test.* property which 
can be used by test to find it’s native components.

This kind of setup would make it easier to add and maintain tests that have a 
native component. I think this will be especially important as more tests are 
written using jtreg in the hotspot repository.

Thoughts on this? Is the general approach ok? There are lots of details to be 
figured out, but at this stage I would like to hear feedback on the idea as 
such.

Thanks,
/Staffan

Re: RFR: 8041151: More concurrent hgforest.

[Staffan Larsen]

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
.:   adding changesets
.:   adding manifests
.:   adding file changes
.:   added 1 changesets with 2 changes to 2 files (+1 heads)
.:   not updating: not a linear update
.:   (merge or update --check to force update)
...

This output is frequently lost to me in all the other output, would it be 
possible to catch these errors and somehow highlight the failure at the end of 
the run? I guess I could go spelunking in the code to find out, but I’m too 
lazy and prefer to bother someone else. :)

Thanks,
/Staffan

On 19 apr 2014, at 01:21, Mike Duigou mike.dui...@oracle.com wrote:

 Hello all;
 
 This is an improvement to hgforest to increase it's concurrency behaviour. 
 Currently hgforest.sh limits the rate at which it starts new sub-processes 
 because it wants to limit the number of concurrent tasks. The naive approach 
 it takes can cause unnecessary delays. For sequences of operations that are 
 entirely local the overhead of waiting is significant. The revised 
 implementation uses fifos for completion notification on capable platforms or 
 compares started task count to completed task count in a shorter sleep loop.
 
 The intention is to use the enhanced concurrency to allow for a fancier 
 get_source.sh that can handle rebasing for mq patches. This involves running 
 a half dozen commands through hgforest. With my current in-development 
 get_source.sh script changes these hgforest changes provide a 10X speedup. 
 (4s vs 40s)
 
 The changeset also incorporates a build-dev suggested improvement to extra 
 base repo url handling and other minor fixes (status code from subprocesses).
 
 JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041151
 WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041151/0/webrev/
 
 I've so far tested it on successfully on Linux (Ubuntu 13.10) Solaris (10u9) 
 and Cygwin x64
 
 Cheers,
 
 Mike
 

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

[Staffan Larsen]

On 11 apr 2014, at 17:19, Jonathan Gibbons jonathan.gibb...@oracle.com 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 applied 
(not just those that were applied before get_source.sh ran). I frequently have 
lots of patches in the queue that I don’t want to have applied.

Thanks,
/Staffan



 
 I've never used mq that way; it would only have occurred to me to use mq in 
 the repo I'm interested in -- in my case, langtools. But then, I admit I tend 
 not to clone forests more than necessary.   configure.sh 
 --with-override-repo-name is your friend ;-)
 
 -- Jon
 
 
 On 04/11/2014 08:19 AM, Chris Hegarty wrote:
 On 11/04/14 15:59, Michael McMahon wrote:
 That's very useful Chris. I wonder is it okay to assume that all patches
 must be pushed back again after the update?
 
 Would it be feasible to remember which (if any) patches had been popped
 first, and only push the same ones again?
 
 That would require a much more involved set of changes in hgforest, but 
 could be doable. All you need to know is queue tip, 'hg qtop', of each repo, 
 qpush back to it.
 
 -Chris.
 
 
 Michael
 
 On 11/04/14 15:58, Chris Hegarty wrote:
 Anyone using MQ for their daily development will know about this,
 forgetting to qpop before sync'ing up. It would be nice it get_source
 would pop and push patches ( only if you are using MQ ) automatically.
 If you do not have patch repos, then there is no change.
 
 diff --git a/get_source.sh b/get_source.sh
 --- a/get_source.sh
 +++ b/get_source.sh
 @@ -28,6 +28,21 @@
 # Get clones of all nested repositories
 sh ./common/bin/hgforest.sh clone $@ || exit 1
 
 +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
 + ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2/dev/null`
 +
 +# Pop all patches, if any, before updating
 +if [ ${patchdirs}  !=  ] ; then
 +  echo Found queue repository, qpop.
 +  sh ./common/bin/hgforest.sh qpop -a || exit 1
 +fi
 +
 # Update all existing repositories to the latest sources
 -sh ./common/bin/hgforest.sh pull -u
 +sh ./common/bin/hgforest.sh pull -u || exit 1
 
 +# Push all patches, if any, after updating
 +if [ ${patchdirs} !=  ] ; then
 +  echo Found queue repository, qpush.
 +  sh ./common/bin/hgforest.sh qpush -a
 +fi
 +
 
 -Chris.
 
 

Re: -Wformat-nonliteral

[Staffan Larsen]

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) james.las...@oracle.com wrote:

 /Projects/jdk9-dev/hotspot/src/share/vm/utilities/debug.cpp:105:19: error: 
 format string is not a string literal [-Werror,-Wformat-nonliteral]
vfprintf(err, format, ap);
  ^~
 
 
 Try to build jdk9-dev tip I ran into this.  Wassup?
 
 -- Jim
 

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

[Staffan Larsen]

Thanks!

Still need someone to look at the actual code changes.


/Staffan

On 20 mar 2014, at 09:49, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com 
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

[Staffan Larsen]

On 20 mar 2014, at 11:25, Alan Bateman alan.bate...@oracle.com 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.gmk and 
 src/solaris/native/sun/management/MacosxOperatingSystem.c are showing up as 
 new files, I can't tell why that is.

I had some trouble creating reviews for multiple repos now that webrev -f” 
does not work. The review at 
http://cr.openjdk.java.net/~sla/8037825/webrev.01/jdk/ is the good one.

 The code changes mostly look good to me. The only change that isn't very 
 clear (I had to stare at it for a few minutes) in log_messages.c where it's 
 now two calls to strftime. It might be useful to include a comment to explain 
 this, also maybe reduce the line length to make it easier for future 
 side-by-side reviews.

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/8037825/webrev.02/


Thanks,
/Staffan

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

[Staffan Larsen]

Thanks Alan!

On 20 mar 2014, at 19:15, Alan Bateman alan.bate...@oracle.com 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/8037825/webrev.02/
 
 
 It's looks okay and thanks for adding a comment.
 
 -Alan

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

[Staffan Larsen]

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 attention to the warnings.

webrev: http://cr.openjdk.java.net/~sla/8037825/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8037825

Thanks,
/Staffan


Here is a list of warnings that I have fixed:

linux-i586

jdk/src/share/back/eventHandler.c: In function 
'eventHandler_createPermanentInternal':
jdk/src/share/back/eventHandler.c:1685: error: cast from pointer to integer of 
different size
jdk/src/share/back/eventHandler.c: In function 
'eventHandler_createInternalThreadOnly':
jdk/src/share/back/eventHandler.c:1694: error: cast from pointer to integer of 
different size

jdk/src/share/back/inStream.c: In function 'inStream_readLong':
jdk/src/share/back/inStream.c:147: error: integer constant is too large for 
'long' type


macosx

jdk/src/share/back/SDE.c:51:1: warning: true redefined
jdk/src/share/back/SDE.c:52:1: warning: false redefined

jdk/src/share/back/log_messages.c: In function ‘get_time_stamp’:
jdk/src/share/back/log_messages.c:69: warning: format not a string literal, 
argument types not checked
jdk/src/share/back/log_messages.c: In function ‘log_message_end’:
jdk/src/share/back/log_messages.c:174: warning: cast from pointer to integer of 
different size

jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c: In function 
'Java_sun_management_OperatingSystemImpl_getProcessCpuLoad0':
jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c:136: warning: 
implicit declaration of function 'JVM_ActiveProcessorCount'


windows

jdk/src/share/back/error_messages.c(328) : warning C4996: '_sleep': This 
function or variable has been superceded by newer library or operating system 
functionality. Consider using Sleep instead. See online help for details.

jdk/src/windows/back/linker_md.c(62) : warning C4013: 'free' undefined; 
assuming extern returning int

jdk/src/share/instrument/PathCharsValidator.c(49) : warning C4267: 
'initializing' : conversion from 'size_t' to 'int', possible loss of data
jdk/src/share/instrument/PathCharsValidator.c(62) : warning C4267: 
'initializing' : conversion from 'size_t' to 'int', possible loss of data
jdk/src/share/instrument/PathCharsValidator.c(179) : warning C4267: '=' : 
conversion from 'size_t' to 'int', possible loss of data


solaris-x64

jdk/src/share/back/inStream.c, line 147: constant promoted to unsigned long long

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

[Staffan Larsen]

Erik, Magnus,

Thanks for the quick looks. Here is an updated version that adds the new 
variable to flags.m4 instead.

http://cr.openjdk.java.net/~sla/8037825/webrev.01/root/
http://cr.openjdk.java.net/~sla/8037825/webrev.01/jdk/

Thanks,
/Staffan

On 19 mar 2014, at 14:03, Erik Joelsson erik.joels...@oracle.com wrote:

 Hello,
 
 Nice work! Removing warnings and enforcing them is definitely something we 
 like.
 
 For the makefile change, ideally the new variable WARNINGS_ARE_ERRORS should 
 be set in configure. I would suggest flags.m4, in 
 FLAGS_SETUP_COMPILER_FLAGS_MISC. Also, 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:
 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 attention to the warnings.
 
 webrev: http://cr.openjdk.java.net/~sla/8037825/webrev.00/
 bug: https://bugs.openjdk.java.net/browse/JDK-8037825
 
 Thanks,
 /Staffan
 
 
 Here is a list of warnings that I have fixed:
 
 linux-i586
 
 jdk/src/share/back/eventHandler.c: In function 
 'eventHandler_createPermanentInternal':
 jdk/src/share/back/eventHandler.c:1685: error: cast from pointer to integer 
 of different size
 jdk/src/share/back/eventHandler.c: In function 
 'eventHandler_createInternalThreadOnly':
 jdk/src/share/back/eventHandler.c:1694: error: cast from pointer to integer 
 of different size
 
 jdk/src/share/back/inStream.c: In function 'inStream_readLong':
 jdk/src/share/back/inStream.c:147: error: integer constant is too large for 
 'long' type
 
 
 macosx
 
 jdk/src/share/back/SDE.c:51:1: warning: true redefined
 jdk/src/share/back/SDE.c:52:1: warning: false redefined
 
 jdk/src/share/back/log_messages.c: In function ‘get_time_stamp’:
 jdk/src/share/back/log_messages.c:69: warning: format not a string literal, 
 argument types not checked
 jdk/src/share/back/log_messages.c: In function ‘log_message_end’:
 jdk/src/share/back/log_messages.c:174: warning: cast from pointer to integer 
 of different size
 
 jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c: In function 
 'Java_sun_management_OperatingSystemImpl_getProcessCpuLoad0':
 jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c:136: warning: 
 implicit declaration of function 'JVM_ActiveProcessorCount'
 
 
 windows
 
 jdk/src/share/back/error_messages.c(328) : warning C4996: '_sleep': This 
 function or variable has been superceded by newer library or operating 
 system functionality. Consider using Sleep instead. See online help for 
 details.
 
 jdk/src/windows/back/linker_md.c(62) : warning C4013: 'free' undefined; 
 assuming extern returning int
 
 jdk/src/share/instrument/PathCharsValidator.c(49) : warning C4267: 
 'initializing' : conversion from 'size_t' to 'int', possible loss of data
 jdk/src/share/instrument/PathCharsValidator.c(62) : warning C4267: 
 'initializing' : conversion from 'size_t' to 'int', possible loss of data
 jdk/src/share/instrument/PathCharsValidator.c(179) : warning C4267: '=' : 
 conversion from 'size_t' to 'int', possible loss of data
 
 
 solaris-x64
 
 jdk/src/share/back/inStream.c, line 147: constant promoted to unsigned long 
 long
 

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

[Staffan Larsen]

On 19 mar 2014, at 17:47, Erik Joelsson erik.joels...@oracle.com 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,
 
 Thanks for the quick looks. Here is an updated version that adds the new 
 variable to flags.m4 instead.
 
 http://cr.openjdk.java.net/~sla/8037825/webrev.01/root/
 http://cr.openjdk.java.net/~sla/8037825/webrev.01/jdk/
 
 Thanks,
 /Staffan
 
 On 19 mar 2014, at 14:03, Erik Joelsson erik.joels...@oracle.com wrote:
 
 Hello,
 
 Nice work! Removing warnings and enforcing them is definitely something we 
 like.
 
 For the makefile change, ideally the new variable WARNINGS_ARE_ERRORS 
 should be set in configure. I would suggest flags.m4, in 
 FLAGS_SETUP_COMPILER_FLAGS_MISC. Also, 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:
 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 attention to the warnings.
 
 webrev: http://cr.openjdk.java.net/~sla/8037825/webrev.00/
 bug: https://bugs.openjdk.java.net/browse/JDK-8037825
 
 Thanks,
 /Staffan
 
 
 Here is a list of warnings that I have fixed:
 
 linux-i586
 
 jdk/src/share/back/eventHandler.c: In function 
 'eventHandler_createPermanentInternal':
 jdk/src/share/back/eventHandler.c:1685: error: cast from pointer to 
 integer of different size
 jdk/src/share/back/eventHandler.c: In function 
 'eventHandler_createInternalThreadOnly':
 jdk/src/share/back/eventHandler.c:1694: error: cast from pointer to 
 integer of different size
 
 jdk/src/share/back/inStream.c: In function 'inStream_readLong':
 jdk/src/share/back/inStream.c:147: error: integer constant is too large 
 for 'long' type
 
 
 macosx
 
 jdk/src/share/back/SDE.c:51:1: warning: true redefined
 jdk/src/share/back/SDE.c:52:1: warning: false redefined
 
 jdk/src/share/back/log_messages.c: In function ‘get_time_stamp’:
 jdk/src/share/back/log_messages.c:69: warning: format not a string 
 literal, argument types not checked
 jdk/src/share/back/log_messages.c: In function ‘log_message_end’:
 jdk/src/share/back/log_messages.c:174: warning: cast from pointer to 
 integer of different size
 
 jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c: In function 
 'Java_sun_management_OperatingSystemImpl_getProcessCpuLoad0':
 jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c:136: 
 warning: implicit declaration of function 'JVM_ActiveProcessorCount'
 
 
 windows
 
 jdk/src/share/back/error_messages.c(328) : warning C4996: '_sleep': This 
 function or variable has been superceded by newer library or operating 
 system functionality. Consider using Sleep instead. See online help for 
 details.
 
 jdk/src/windows/back/linker_md.c(62) : warning C4013: 'free' undefined; 
 assuming extern returning int
 
 jdk/src/share/instrument/PathCharsValidator.c(49) : warning C4267: 
 'initializing' : conversion from 'size_t' to 'int', possible loss of data
 jdk/src/share/instrument/PathCharsValidator.c(62) : warning C4267: 
 'initializing' : conversion from 'size_t' to 'int', possible loss of data
 jdk/src/share/instrument/PathCharsValidator.c(179) : warning C4267: '=' : 
 conversion from 'size_t' to 'int', possible loss of data
 
 
 solaris-x64
 
 jdk/src/share/back/inStream.c, line 147: constant promoted to unsigned 
 long long
 

Re: RFR(XS): JDK-8034176 Update mapfile for libjfr

[Staffan Larsen]

Resending (email to build-dev bounced since I used the wrong sender address).

On 11 feb 2014, at 11:18, staf...@larsen.se wrote:

 Please review this small fix for libjfr/mapfile-vers.
 
 Thanks,
 /Staffan
 
 diff --git a/make/mapfiles/libjfr/mapfile-vers 
 b/make/mapfiles/libjfr/mapfile-vers
 --- a/make/mapfiles/libjfr/mapfile-vers
 +++ b/make/mapfiles/libjfr/mapfile-vers
 @@ -34,6 +34,7 @@
   Java_oracle_jrockit_jfr_VMJFR_getPeriod;
   Java_oracle_jrockit_jfr_VMJFR_descriptors;
   Java_oracle_jrockit_jfr_VMJFR_redefineClass0;
 +  Java_oracle_jrockit_jfr_VMJFR_retransformClasses0;
   JNI_OnLoad;
   local:
   *;

Re: RFR: JDK-8031580: bootcycle-images crashes with Unrecognized VM option 'PermSize=32m'

[Staffan Larsen]

Looks good!

Thanks,
/Staffan

On 13 jan 2014, at 16:55, Erik Joelsson erik.joels...@oracle.com wrote:

 Please review this simple fix, removing two obsolete parameters from the boot 
 jdk command line.
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8031580
 Webrev: http://cr.openjdk.java.net/~erikj/8031580/webrev.root.01/
 
 /Erik

Re: [8] WXP fixes to avoid warning when compiling SA files

[Staffan Larsen]

Francis,

To be honest (and because I’m lazy), it’s a bit more work to push this to jdk7u 
than I am willing to spend. There isn’t a lot of activity in jdk7u any more and 
you shouldn’t expect much to be changed there. Most of the activity now is in 
jdk9.

Thanks,
/Staffan

On 21 dec 2013, at 18:09, Francis ANDRE francis.andre.kampb...@orange.fr 
wrote:

 Staffan
 
 By the way, I am working on the jdk7u... Could you also take in charge the 
 backport to the jdk7u?
 
 Francis
 
 Le 09/12/2013 13:25, Staffan Larsen a écrit :
 This change looks good to me.
 
 I have created https://bugs.openjdk.java.net/browse/JDK-8029798 for this 
 change, and I can sponsor it. There are currently no open repos for 
 low-priority hotspot changes so I will have to wait before pushing the 
 change.
 
 /Staffan
 
 
 On 7 dec 2013, at 18:25, Francis ANDRE francis.andre.kampb...@orange.fr 
 wrote:
 
 Hi
 
 Compiling SA files leads to warning because of old or invalid options as 
 below
 
 set INCLUDE=C:\Program Files\Microsoft Visual Studio 
 10.0\VC\INCLUDE;C:\Program Files\Microsoft 
 SDKs\Windows\v7.0A\include;C:\Program Files\Microsoft Visual Studio 
 10.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v7.0A\include
 C:\progra~1\micros~2.0\vc\bin\cl.exe @C:\cygwin\tmp\nmE2.tmp
 clÿ: Ligne de commande warning D9035ÿ: l'option 'GZ' est d‚conseill‚e et 
 sera supprim‚e dans une version ult‚rieure
 clÿ: Ligne de commande warning D9036ÿ: utilisez 'RTC1' … la place de 'GZ'
 clÿ: Ligne de commande warning D9035ÿ: l'option 'o' est d‚conseill‚e et 
 sera supprim‚e dans une version ult‚rieure
 clÿ: Ligne de commande warning D9002ÿ: option '-YX' inconnue ignor‚e
 clÿ: Ligne de commande warning D9030ÿ: '/Gm' incompatible avec le 
 multitraitementÿ; commutateur /MP ignor‚
 sadis.c
 
 
 Here the diff
 
 diff --git a/make/windows/makefiles/sa.make b/make/windows/makefiles/sa.make
 --- a/make/windows/makefiles/sa.make
 +++ b/make/windows/makefiles/sa.make
 @@ -94,7 +94,7 @@
 SA_LD_FLAGS = bufferoverflowU.lib
 !endif
 !else
 -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D 
 WIN32 -D _WINDOWS -D _DEBUG -D _CONSOLE -D _MBCS -YX
 -FD -GZ -c
 +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D WIN32 
 -D _WINDOWS -D _DEBUG -D _CONSOLE -D _MBCS -FD -RT
 C1 -c
 !if $(ENABLE_FULL_DEBUG_SYMBOLS) == 1
 SA_CFLAGS = $(SA_CFLAGS) -ZI
 !endif
 
 
 

Re: RR(S) 8030941: Darwin mapfile-vers doesn't work for other BSD

[Staffan Larsen]

Looks good!

Thanks,
/Staffan

On 21 dec 2013, at 17:34, Dmitry Samersoff dmitry.samers...@oracle.com wrote:

 Hi Everybody,
 
 I'd debug out last blocker for clear build of hotspot on FreeBSD.
 
 Darwin's mapfile-vers couldn't be used for FreeBSD (and probably other
 BSDs) so changed makefiles to use generic one if we are not on Darwin.
 
 http://cr.openjdk.java.net/~dsamersoff/JDK-8030941/webrev.01/
 
 PS:
 
 As mapfile-vers is essentially the same for all platforms except Darwin
 it might make sense to create a separate directory and put it to a
 single place.
 
 -- 
 Dmitry Samersoff
 Oracle Java development team, Saint Petersburg, Russia
 * I would love to change the world, but they won't give me the sources.

Re: [8] WXP fixes to avoid warning when compiling SA files

[Staffan Larsen]

This change looks good to me.

I have created https://bugs.openjdk.java.net/browse/JDK-8029798 for this 
change, and I can sponsor it. There are currently no open repos for 
low-priority hotspot changes so I will have to wait before pushing the change.

/Staffan


On 7 dec 2013, at 18:25, Francis ANDRE francis.andre.kampb...@orange.fr wrote:

 Hi
 
 Compiling SA files leads to warning because of old or invalid options as below
 
 set INCLUDE=C:\Program Files\Microsoft Visual Studio 
 10.0\VC\INCLUDE;C:\Program Files\Microsoft 
 SDKs\Windows\v7.0A\include;C:\Program Files\Microsoft Visual Studio 
 10.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v7.0A\include
 C:\progra~1\micros~2.0\vc\bin\cl.exe @C:\cygwin\tmp\nmE2.tmp
 clÿ: Ligne de commande warning D9035ÿ: l'option 'GZ' est d‚conseill‚e et sera 
 supprim‚e dans une version ult‚rieure
 clÿ: Ligne de commande warning D9036ÿ: utilisez 'RTC1' … la place de 'GZ'
 clÿ: Ligne de commande warning D9035ÿ: l'option 'o' est d‚conseill‚e et sera 
 supprim‚e dans une version ult‚rieure
 clÿ: Ligne de commande warning D9002ÿ: option '-YX' inconnue ignor‚e
 clÿ: Ligne de commande warning D9030ÿ: '/Gm' incompatible avec le 
 multitraitementÿ; commutateur /MP ignor‚
 sadis.c
 
 
 Here the diff
 
 diff --git a/make/windows/makefiles/sa.make b/make/windows/makefiles/sa.make
 --- a/make/windows/makefiles/sa.make
 +++ b/make/windows/makefiles/sa.make
 @@ -94,7 +94,7 @@
 SA_LD_FLAGS = bufferoverflowU.lib
 !endif
 !else
 -SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D WIN32 
 -D _WINDOWS -D _DEBUG -D _CONSOLE -D _MBCS -YX
 -FD -GZ -c
 +SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 $(GX_OPTION) -Od -D WIN32 -D 
 _WINDOWS -D _DEBUG -D _CONSOLE -D _MBCS -FD -RT
 C1 -c
 !if $(ENABLE_FULL_DEBUG_SYMBOLS) == 1
 SA_CFLAGS = $(SA_CFLAGS) -ZI
 !endif
 

Re: DIZ files

[Staffan Larsen]

Run configure with --disable-zip-debug-info to skip the zipping and leave the 
files as they are.

/Staffan

On 5 dec 2013, at 06:15, Jeremy Manson jeremyman...@google.com wrote:

 These are zip files containing debug info for the relevant library.  Very
 useful for profiling / debugging.
 
 Jeremy
 
 
 On Wed, Dec 4, 2013 at 6:55 PM, Pete Brunet peter.bru...@oracle.com wrote:
 
 For each DLL built I also see a DIZ file.  What are those?  -Pete
 

Re: Le roi est mort, vive le roi!

[Staffan Larsen]

I wasn’t implying that it would go away, merely that it is a second class 
citizen compared to the makefiles.

/Staffan

On 26 nov 2013, at 20:29, Erik Gahlin erik.gah...@oracle.com wrote:

 I know 5-10 Hotspot developers who uses Visual Studio (me included) so I hope 
 it's not something that is going away.
 
 Erik
 
 Staffan Larsen skrev 2013-11-26 20:10:
 I am in full agreement with you that an IDE is a very powerful tool and I 
 much prefer to work in an IDE than outside one. However, I do not do my 
 day-to-day work on Windows (anymore - I used to). I don’t know how 
 developers on Windows manage their work.
 
 /Staffan
 
 On 26 nov 2013, at 18:34, Francis ANDRE francis.andre.kampb...@orange.fr 
 wrote:
 
 Hi Staffan
 Le 25/11/2013 08:53, Staffan Larsen a écrit :
 
 The top level make produces a full jdk here: 
 Z:\JDK\jdk8\build\windows-x86-normal-server-release\images\j2sdk-image
 The hotspot make produces a full jdk here : 
 Z:\JDK\jdk8\hotspot\build\windows\jdk-windows-i586
 The hotspot create.bat produces a JVM here: 
 Z:\JDK\jdk8\hotspot\build\vs-i486\compiler1
 
 create.bat has only one parameter: the bootstrap jdk and thus does not 
 take into account the configure-based top-level files. Moreover when 
 using an official public jdk7 release as the jdk1.7.0_45 as the bootstrap 
 jdk of jdk8, the produced jvm.vxproj does not work as the changeset 
 associated with the JDK 8016019 are not back ported to the jdk1.7.0_45 
 release. So I am wondering what specific parameters hotspot developers 
 are using to test their changes under WXP/W7 for the jdk8 hotspot?
 The visual studio projects are not the official way to build hotspot. They 
 are provided as a nice-to-have feature that developers on windows 
 maintain. The official way to build on all platforms is to use the 
 makefiles.
 Staffan, while the official way to build on all platforms is to use the 
 makefiles, it does not make sense when talking about debugging, testing and 
 developing a major, large, multi layered C++ application like hotspot.
 
 To make it short, VisualStudio C++ is to c++ what Netbeans or Eclipse are 
 for Java, a mandatory  powerful IDE for developping large and complex 
 application. Can you image to code, develop, debug, test a multi-threaded 
 java application fo 250 kilo lines without Netbeans, just with vi, 
 makefiles and some additional tools... I do not think so... So, it is the 
 same for hotspot on WXP/W7!
 
 Thus, if as I understand well, WXP/W7/ X86/X64 are strategic platfoms for 
 Oracle in providing a fully certified and supported Java environment, then 
 the nice-to-have feature is not at level of the mission. The generation of 
 the jvm.vxproj cannot be a second level citizen but should be as good as 
 the generation of the jdk, fully maintained and integrated as new features, 
 way fo building the new build system and so on are added, modified or 
 deleted
 
 Francis
 
 /Staffan
 
 
 
 Francis
 David
 -
 
 Francis
 the jdk8 build system, but what is the old one?
 
 Francis
 
 Le 18/11/2013 19:02, Magnus Ihse Bursie a écrit :
 So, finally it has happened. The old build system is now removed.
 The patch was just submitted to the tl forest, from where it will
 move to master in a few days.
 
 If you have personal scripts that are using hard-coded makefile
 references, you might need to update them.
 
 Thanks to everyone who helped this major project become reality:
 Fredrik, Erik, Kelly, Tim, Jonas, ...
 
 /Magnus
 

Re: Le roi est mort, vive le roi!

[Staffan Larsen]

I am in full agreement with you that an IDE is a very powerful tool and I much 
prefer to work in an IDE than outside one. However, I do not do my day-to-day 
work on Windows (anymore - I used to). I don’t know how developers on Windows 
manage their work.

/Staffan

On 26 nov 2013, at 18:34, Francis ANDRE francis.andre.kampb...@orange.fr 
wrote:

 Hi Staffan
 Le 25/11/2013 08:53, Staffan Larsen a écrit :
 
 
 The top level make produces a full jdk here: 
 Z:\JDK\jdk8\build\windows-x86-normal-server-release\images\j2sdk-image
 The hotspot make produces a full jdk here : 
 Z:\JDK\jdk8\hotspot\build\windows\jdk-windows-i586
 The hotspot create.bat produces a JVM here: 
 Z:\JDK\jdk8\hotspot\build\vs-i486\compiler1
 
 create.bat has only one parameter: the bootstrap jdk and thus does not take 
 into account the configure-based top-level files. Moreover when using an 
 official public jdk7 release as the jdk1.7.0_45 as the bootstrap jdk of 
 jdk8, the produced jvm.vxproj does not work as the changeset associated 
 with the JDK 8016019 are not back ported to the jdk1.7.0_45 release. So I 
 am wondering what specific parameters hotspot developers are using to test 
 their changes under WXP/W7 for the jdk8 hotspot?
 
 The visual studio projects are not the official way to build hotspot. They 
 are provided as a nice-to-have feature that developers on windows maintain. 
 The official way to build on all platforms is to use the makefiles.
 Staffan, while the official way to build on all platforms is to use the 
 makefiles, it does not make sense when talking about debugging, testing and 
 developing a major, large, multi layered C++ application like hotspot.
 
 To make it short, VisualStudio C++ is to c++ what Netbeans or Eclipse are for 
 Java, a mandatory  powerful IDE for developping large and complex 
 application. Can you image to code, develop, debug, test a multi-threaded 
 java application fo 250 kilo lines without Netbeans, just with vi, makefiles 
 and some additional tools... I do not think so... So, it is the same for 
 hotspot on WXP/W7!
 
 Thus, if as I understand well, WXP/W7/ X86/X64 are strategic platfoms for 
 Oracle in providing a fully certified and supported Java environment, then 
 the nice-to-have feature is not at level of the mission. The generation of 
 the jvm.vxproj cannot be a second level citizen but should be as good as the 
 generation of the jdk, fully maintained and integrated as new features, way 
 fo building the new build system and so on are added, modified or 
 deleted
 
 Francis
 
 
 /Staffan
 
 
 
 Francis
 
 David
 -
 
 
 Francis
 
 the jdk8 build system, but what is the old one?
 
 Francis
 
 Le 18/11/2013 19:02, Magnus Ihse Bursie a écrit :
 So, finally it has happened. The old build system is now removed.
 The patch was just submitted to the tl forest, from where it will
 move to master in a few days.
 
 If you have personal scripts that are using hard-coded makefile
 references, you might need to update them.
 
 Thanks to everyone who helped this major project become reality:
 Fredrik, Erik, Kelly, Tim, Jonas, ...
 
 /Magnus