Re: [APPCDS] JDK-8236847: JDK built on machine with 4K pages refused to start on machine with 64k pages

[Dmitry Samersoff]

Ioi,

> Dmitry, are you running with -Xshare:on? If you use -Xshare:off (which
> is the default), when the CDS archive cannot be mapped, the JVM will
> continue execution.

I use default parameters for java. i.e. ever simple

java -version

refuses to start with the message below.

> Are you having problems running with the jtreg test cases? I can think
> of a way to fix this, so that CDS can continue to work under this
> circumstance, but I want to understand your scenarios more.

Typical scenario is:
   We have AArch64 Jenkins build server with 4k pages that automatically

  - builds JDK
  - deploy it to a large server with 64k pages
  - run set of tests
  (regression and performance, not all of them are jtreg one)

-Dmitry




On 09.01.20 20:02, Ioi Lam wrote:
> 
> 
> On 1/9/20 12:47 AM, David Holmes wrote:
>> On 9/01/2020 6:29 pm, Dmitry Samersoff wrote:
>>> Hello Ioi,
>>>
>>> *Story*
>>>
>>> If you build JDK-14 with the changes for
>>>
>>>    JDK-8231610 Relocate the CDS archive if it cannot be mapped
>>>    to the requested address
>>>
>>> on a machine with 4k pages (typical Jenkins machine) then move the
>>> bundle to a huge server with 64k pages, it refuses to start with
>>>
>>> [0.015s][error][cds] Unable to map CDS archive --
>>> os::vm_allocation_granularity() expected: 4096 actual: 65536
>>>
>>> *Question*
>>>
>>> I'm not sure if just removing an assert is the correct fix. What would
>>> you recommend?
>>
>> I thought that failing to map the archive was a non-fatal error that
>> just results in falling back to not using CDS. Even in a debug build
>> this should not be an assertion unless perhaps the user has explicitly
>> requested CDS to be enabled.
>>
> Dmitry, are you running with -Xshare:on? If you use -Xshare:off (which
> is the default), when the CDS archive cannot be mapped, the JVM will
> continue execution.
> 
> Are you having problems running with the jtreg test cases? I can think
> of a way to fix this, so that CDS can continue to work under this
> circumstance, but I want to understand your scenarios more.
> 
> Thanks
> - Ioi
> 
>>> Also @build-dev - is it possible to add configure option to disable
>>> AppCDS archive generation?
>>
>> Already there I think: --disable-cds-archive
>>
>> Cheers,
>> David
>> -
>>
>>
>>>
>>> -Dmitry\S
>>>
>>>
>>>
> 

[APPCDS] JDK-8236847: JDK built on machine with 4K pages refused to start on machine with 64k pages

[Dmitry Samersoff]

Hello Ioi,

*Story*

If you build JDK-14 with the changes for

  JDK-8231610 Relocate the CDS archive if it cannot be mapped
  to the requested address

on a machine with 4k pages (typical Jenkins machine) then move the
bundle to a huge server with 64k pages, it refuses to start with

[0.015s][error][cds] Unable to map CDS archive --
os::vm_allocation_granularity() expected: 4096 actual: 65536

*Question*

I'm not sure if just removing an assert is the correct fix. What would
you recommend?

Also @build-dev - is it possible to add configure option to disable
AppCDS archive generation?


-Dmitry\S

Re: RFR(S): 8231612: 100% cpu on arm32 in Service Thread

[Dmitry Samersoff]

Aleksei,

Looks good to me.

-Dmitry


On 11.12.19 15:53, Aleksei Voitylov wrote:
> Kim,
> 
> You are right. Here is an updated webrev:
> 
> http://cr.openjdk.java.net/~avoitylov/webrev.8231612.05/
> 
> -Aleksei
> 
> On 11/12/2019 03:03, Kim Barrett wrote:
>>> On Dec 10, 2019, at 9:05 AM, Aleksei Voitylov 
>>>  wrote:
>>>
>>> Kim,
>>>
>>> thank you for the suggestions. Here is an updated webrev:
>>>
>>> http://cr.openjdk.java.net/~avoitylov/webrev.8231612.04/
>>>
>>> The assembly generated with inline functions is equivalent to that with
>>> the macros, and the testing passed as well.
>> This is mostly good.
>>
>> However, the new function names don't follow usual HotSpot style,
>> which is lower case with underscore word separators.  (Yes, there
>> are *many* counterexamples.)
>>
>> Also, the minimal parenthesizing in SetByteInInt requires one to think
>> about operator precedence order more than I would like.  What's there
>> is correct, but would be easier to read as
>>
>>  855   return (n & ~(0xff << bitsIdx)) | (b << bitsIdx);
>>
>> (We have some functions in globalDefinitions.hpp to supposedly help
>> with these kinds of calculations, but the supported types are often
>> wrong (as here), and there are missing operations (again, as here).)
>>
> 

Re: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029

[Dmitry Samersoff]

Andrew,

My $0.2

It might be better to refactor
switch(tag) in c1_LIRGenerator_aarch64.cpp
to usual case/break form, rather than have multiple returns.

i.e.

switch (tag) {
 583 case floatTag: // fall trough
 584 case doubleTag:
   do_ArithmeticOp_FPU(x);
   break;
 585 case longTag:
   do_ArithmeticOp_Long(x);
   break;
 586 case intTag:
   do_ArithmeticOp_Int(x);
   break;
 587 default:
   ShouldNotReachHere();
 588   }

return;

-Dmitry


On 27.09.2018 11:53, Andrew Haley wrote:
> On 09/27/2018 09:30 AM, Aleksey Shipilev wrote:
>> On 09/27/2018 10:21 AM, Andrew Haley wrote:
>>> On 09/27/2018 08:22 AM, Aleksey Shipilev wrote:
>>>> Otherwise looks good and trivial.
>>>
>>> No, it is neither good nor trivial:some of those should be 
>>> ShouldNotReachHere().
>>> I'll post a webrev later.
>>
>> Okay, let's see it.
>>
>> I was mostly concerned with having the same control flow as before,
>> did I miss some change that is actually non-trivial?
> 
> That's not my point: we should not put break statements in places we
> don't expect to reach. It's misleading for the reader. Code changes
> to "shut up" the compiler have do be done with great care and
> knowledge of what the code does.
> 
>> On the second read, this change in c1_LIRAssembler_aarch64.cpp looks
>> suspicious, as it elevates ShouldNotReachHere to default case,
>> rather than letting default thing fall-through?
>>
>>  break;
>> +  default:
>>  ShouldNotReachHere();
>>}
> 
> I think that one is actually OK.
> 
> http://cr.openjdk.java.net/~aph/8211207/
> 
> follows the pattern of the x86 port.
> 


-- 
Dmitry Samersoff
http://devnull.samersoff.net
* There will come soft rains ...

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

[Dmitry Samersoff]

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.

Re: Compile error with jdk9-dev latest HEAD - missing com.sun.tools.jdi - on Mac OS X 10.12.1

[Dmitry Samersoff]

Martijn,

Could I ask you to clone fresh sources?

SA-JDI classes was removed in Aug see - JDK-8158050

-Dmitry

On 2016-12-06 16:44, Martijn Verburg wrote:
> Hi all,
> 
> Just ran make clean image this morning and got:
> 
> ...
> ...
> === Output from failing command(s) repeated here ===
> * For target jdk_modules_jdk.hotspot.agent__the.jdk.hotspot.agent_batch:
> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9-dev/hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/jdi/SACoreAttachingConnector.java:43:
> error: package com.sun.tools.jdi does not exist
> public
> SACoreAttachingConnector(com.sun.tools.jdi.VirtualMachineManagerService
> ignored) {
>  ^
> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9-dev/hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/jdi/SADebugServerAttachingConnector.java:42:
> error: package com.sun.tools.jdi does not exist
> public
> SADebugServerAttachingConnector(com.sun.tools.jdi.VirtualMachineManagerService
> ignored) {
> ^
> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9-dev/hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/jdi/SAPIDAttachingConnector.java:41:
> error: package com.sun.tools.jdi does not exist
> public
> SAPIDAttachingConnector(com.sun.tools.jdi.VirtualMachineManagerService
> ignored) {
> ^
> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9-dev/hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java:265:
> error: package com.sun.tools.jdi does not exist
> 
> ((com.sun.tools.jdi.VirtualMachineManagerImpl)mgr).addVirtualMachine(this);
>^
>... (rest of output omitted)
> 
> Before I dig further, has anyone else run across this?
> 
> Cheers,
> Martijn
> 


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

[Dmitry Samersoff]

Staffan,

Thank you for the explanation.

The fix looks good for me.

-Dmitry

On 2016-10-21 10:49, Staffan Larsen wrote:
> 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.
> 


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

[Dmitry Samersoff]

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 8144278 [TESTBUG] hotspot/runtime/StackGuardPages/testme.sh should use native library build support

[Dmitry Samersoff]

Gerald,

> Does this code snippet address your concerns with how “javaclassopt”
> is created?

Yes.

PS: I used to return 7 to easy distinguish startup (env, command line
etc) parameters error from other kind of errors. It's where exit(7)
comes from in this test.
  So it might be better to use exit(1) if (retval < 0)

-Dmitry

On 2016-06-02 19:25, Gerald Thornbrugh wrote:
> Hi Dmitry,
> 
> I will discuss the disabling of optimization with Erik Joelsson and get
> back to you.
> 
> Does this code snippet address your concerns with how “javaclassopt” is
> created?
> 
>   int retval;
>   static char javaclassopt[4096];
>   char *javaclasspath = NULL;
>   char *javaclasspathopt = NULL;
> 
>   printf("Test started with pid: %ld\n", (long) getpid());
> 
>   /* set the java class path so the DoOverflow class can be found */
>   javaclasspath = getenv("CLASSPATH");
> 
>   retval = snprintf(javaclassopt, sizeof(javaclassopt),
> "-Djava.class.path=%s",
>   javaclasspath);
> 
>   if (retval < 0) {
> fprintf(stderr, "Test ERROR. Problem creating javaclasspath\n");
> exit(7);
>   }
>   if (retval >= sizeof(javaclassopt)) {
> fprintf(stderr, "Test ERROR. CLASSPATH is too long\n");
> exit(7);
>   }
> 
> I will make the change you suggested for the usage() function.
> 
> Thanks,
> 
> Gerald
>> On Jun 2, 2016, at 9:54 AM, Dmitry Samersoff
>> <dmitry.samers...@oracle.com <mailto:dmitry.samers...@oracle.com>> wrote:
>>
>> Gerald,
>>
>> exeinvoke.c
>>
>> 127:
>>  I think we should compile entire test (and probably all other tests)
>> with disabled optimization (e.g. -g -O0) to simplify debugging if the
>> test crash.
>>
>>
>> 239:
>>   Please declare a static variable:
>>
>>static char javaclassopt[4096];
>>
>>  then use
>>
>>   snprintf(javaclassopt, sizeof(javaclassopt),
>>   "-Djava.class.path=%s", javaclasspath);
>>
>>  and check it's return value.
>>
>>
>> 295: Please change usage() to return value 7 rather than call exit and
>> change this line to
>>
>>  return usage();
>>
>> to avoid unreachable statements.
>>
>> -Dmitry
>>
>> On 2016-06-02 18:28, Gerald Thornbrugh wrote:
>>> Hi Everyone,
>>>
>>> Please review my changes to address JDK-8144278.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144278
>>>
>>> JDK Webrev: http://cr.openjdk.java.net/~gthornbr/8144278/jdk-webrev.00/
>>> <http://cr.openjdk.java.net/%7Egthornbr/8144278/jdk-webrev.00/>
>>>
>>> Hotspot Webrev:
>>> http://cr.openjdk.java.net/~gthornbr/8144278/hotspot-webrev.00/
>>> <http://cr.openjdk.java.net/%7Egthornbr/8144278/hotspot-webrev.00/>
>>>
>>>
>>> The fix makes changes to two areas.
>>>
>>> The JDK changes where needed to add a path to the libjvm.so library when
>>> linking test executables.
>>> These changes where provide by Erik Joelsson.
>>>
>>> The Hotspot changes addressed the following issues:
>>>
>>> The StackGuardPages test directory needed to be added to the list of
>>> native executable tests.
>>>
>>> The libjvm.so and libpthread.so libraries needed to be added to the
>>> LDFLAGS definition for the
>>> "invoke" test executable.
>>>
>>> The StackGuardPages/testme.sh script needed to specify that
>>> DoOverflow.java must be complied,
>>> specify the new location of the "invoke" test executable and remove all
>>> portions of the script that
>>> compiled and linked DoOverflow.java and invoke.c.
>>>
>>> The native test source file "invoke.c" needed to be renamed
>>> "exeinvoke.c" so the build system will
>>> automatically build it.
>>>
>>> The native test source file exeinvoke.c needed to be changed to compile
>>> without warnings, pass the
>>> path of the DoOverflow.class file to the function which starts the JVM
>>> and keep the linux gcc compiler
>>> optimizer from in-lining the do_overflow() function which caused it not
>>> to get called.
>>>
>>> Please let me know if you have any questions or concerns.
>>>
>>> Thanks,
>>>
>>> Gerald
>>>
>>
> 

Re: RFR 8144278 [TESTBUG] hotspot/runtime/StackGuardPages/testme.sh should use native library build support

[Dmitry Samersoff]

Gerald,

exeinvoke.c

127:
  I think we should compile entire test (and probably all other tests)
with disabled optimization (e.g. -g -O0) to simplify debugging if the
test crash.


239:
   Please declare a static variable:

static char javaclassopt[4096];

  then use

   snprintf(javaclassopt, sizeof(javaclassopt),
   "-Djava.class.path=%s", javaclasspath);

  and check it's return value.


295: Please change usage() to return value 7 rather than call exit and
 change this line to

  return usage();

 to avoid unreachable statements.

-Dmitry

On 2016-06-02 18:28, Gerald Thornbrugh wrote:
> Hi Everyone,
> 
> Please review my changes to address JDK-8144278.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144278
> 
> JDK Webrev: http://cr.openjdk.java.net/~gthornbr/8144278/jdk-webrev.00/
> 
> 
> Hotspot Webrev:
> http://cr.openjdk.java.net/~gthornbr/8144278/hotspot-webrev.00/
> 
> 
> 
> The fix makes changes to two areas.
> 
> The JDK changes where needed to add a path to the libjvm.so library when
> linking test executables.
> These changes where provide by Erik Joelsson.
> 
> The Hotspot changes addressed the following issues:
> 
> The StackGuardPages test directory needed to be added to the list of
> native executable tests.
> 
> The libjvm.so and libpthread.so libraries needed to be added to the
> LDFLAGS definition for the
> "invoke" test executable.
> 
> The StackGuardPages/testme.sh script needed to specify that
> DoOverflow.java must be complied,
> specify the new location of the "invoke" test executable and remove all
> portions of the script that
> compiled and linked DoOverflow.java and invoke.c.
> 
> The native test source file "invoke.c" needed to be renamed
> "exeinvoke.c" so the build system will
> automatically build it.
> 
> The native test source file exeinvoke.c needed to be changed to compile
> without warnings, pass the
> path of the DoOverflow.class file to the function which starts the JVM
> and keep the linux gcc compiler
> optimizer from in-lining the do_overflow() function which caused it not
> to get called.
> 
> Please let me know if you have any questions or concerns.
> 
> Thanks,
> 
> Gerald
> 

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

[Dmitry Samersoff]

Staffan,

Looks good for me.

-Dmitry


On 2016-05-10 17:22, Staffan Larsen wrote:
> Updated webrev with those changes to the hotspot
> makefile: http://cr.openjdk.java.net/~sla/8156658/webrev.04/
> 
> Thanks,
> /Staffan
> 
>> On 10 maj 2016, at 15:50, Dmitry Samersoff
>> <dmitry.samers...@oracle.com <mailto: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 <mailto: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=>>>> product path> \
>>>>>   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/
>>>>> <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.
> 


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

[Dmitry Samersoff]

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

[Dmitry Samersoff]

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

  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-8150723: HSDB toolbar icons are missing.

[Dmitry Samersoff]

Yasumasa,

Looks good for me!

-Dmitry


On 2016-02-29 16:26, Yasumasa Suenaga wrote:
> Hi Dmitry, Erik,
> 
> I've uploaded new webrev:
> 
>   hotspot:  
> http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.02/hotspot/
>   makefile: http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.02/make/
> 
> 
>> Could you move gif files to correct location and remove custom makefile
>> logic?
> 
> I moved classes/images/toolbarButtonGraphics to classes/toolbarButtonGraphics 
> .
> Could you review it?
> 
>> I'll sponsor the push then.
> 
> Thanks!
> 
> 
> Yasumasa
> 
> 
> On 2016/02/29 17:52, Dmitry Samersoff wrote:
>> Yasumasa,
>>
>> I think it's better to have a complete fix rather than yet another
>> workaround.
>>
>> Could you move gif files to correct location and remove custom makefile
>> logic?
>>
>> I'll sponsor the push then.
>>
>> -Dmitry
>>
>> On 2016-02-27 06:44, Yasumasa Suenaga wrote:
>>> Hi Erik,
>>>
>>> Thanks!
>>> I've uploaded new webrev. Could you review it?
>>>http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.01/
>>>
>>>> However, the real fix is to move the gifs out of the images dir so that
>>>> they have the correct subdir relative to the classes dir in both the
>>>> source and the output. Then we can remove this whole SetupCopyFiles
>>>> construct and just add .gif to jdk.hotspot.agent_COPY.
>>>
>>> Comments in CompileJavaModules.gmk are as below:
>>> 
>>>### Copy gif files
>>># Special handling to copy gif files in images/toolbarButtonGraphics \
>>>#   -> classes/toolbarButtonGraphics.
>>># These can't be handled by COPY to SetupJavaCompilation since they chop 
>>> off
>>># one directory level.
>>> 
>>>
>>> According to them, I guess that our fix makes expected behavior.
>>> If we should fix as you say, I think that we work for it in another issue.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2016/02/27 1:59, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> Actually you only need this:
>>>>
>>>> erik at pilot:/localhome/hg/jdk9-dev$ hg diff
>>>> diff -r c7be2a78c31b make/CompileJavaModules.gmk
>>>> --- a/make/CompileJavaModules.gmk
>>>> +++ b/make/CompileJavaModules.gmk
>>>> @@ -381,7 +381,7 @@
>>>>   DEST := $(JDK_OUTPUTDIR)/modules/$(MODULE), \
>>>>   FILES := $(wildcard
>>>> $(HOTSPOT_TOPDIR)/src/jdk.hotspot.agent/share/classes/images/*/*/*.gif), \
>>>>   ))
>>>> -  jdk.hotspot.agent: $(COPY_SA_IMAGES)
>>>> +  jdk.hotspot.agent_COPY_EXTRA += $(COPY_SA_IMAGES)
>>>> endif
>>>>
>>>> 
>>>> 
>>>>
>>>> However, the real fix is to move the gifs out of the images dir so that
>>>> they have the correct subdir relative to the classes dir in both the
>>>> source and the output. Then we can remove this whole SetupCopyFiles
>>>> construct and just add .gif to jdk.hotspot.agent_COPY.
>>>>
>>>> /Erik
>>>>
>>>> On 2016-02-26 04:28, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>> HSDB toolbar icons 
>>>>> (hotspot/src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics)
>>>>> are missing in appmodules.jimage .
>>>>> They should be contained to appmodules.jimage .
>>>>>
>>>>> I've uploaded a webrev:
>>>>>  http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.00/
>>>>>
>>>>> Could you review it?
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>
>>>>
>>
>>


-- 
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-8150723: HSDB toolbar icons are missing.

[Dmitry Samersoff]

Yasumasa,

I think it's better to have a complete fix rather than yet another
workaround.

Could you move gif files to correct location and remove custom makefile
logic?

I'll sponsor the push then.

-Dmitry

On 2016-02-27 06:44, Yasumasa Suenaga wrote:
> Hi Erik,
> 
> Thanks!
> I've uploaded new webrev. Could you review it?
>   http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.01/
> 
>> However, the real fix is to move the gifs out of the images dir so that
>> they have the correct subdir relative to the classes dir in both the
>> source and the output. Then we can remove this whole SetupCopyFiles
>> construct and just add .gif to jdk.hotspot.agent_COPY.
> 
> Comments in CompileJavaModules.gmk are as below:
> 
>   ### Copy gif files
>   # Special handling to copy gif files in images/toolbarButtonGraphics \
>   #   -> classes/toolbarButtonGraphics.
>   # These can't be handled by COPY to SetupJavaCompilation since they chop off
>   # one directory level.
> 
> 
> According to them, I guess that our fix makes expected behavior.
> If we should fix as you say, I think that we work for it in another issue.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/02/27 1:59, Erik Joelsson wrote:
>> Hello,
>>
>> Actually you only need this:
>>
>> erik at pilot:/localhome/hg/jdk9-dev$ hg diff
>> diff -r c7be2a78c31b make/CompileJavaModules.gmk
>> --- a/make/CompileJavaModules.gmk
>> +++ b/make/CompileJavaModules.gmk
>> @@ -381,7 +381,7 @@
>>  DEST := $(JDK_OUTPUTDIR)/modules/$(MODULE), \
>>  FILES := $(wildcard
>> $(HOTSPOT_TOPDIR)/src/jdk.hotspot.agent/share/classes/images/*/*/*.gif), \
>>  ))
>> -  jdk.hotspot.agent: $(COPY_SA_IMAGES)
>> +  jdk.hotspot.agent_COPY_EXTRA += $(COPY_SA_IMAGES)
>>endif
>>
>>
>> 
>>
>> However, the real fix is to move the gifs out of the images dir so that
>> they have the correct subdir relative to the classes dir in both the
>> source and the output. Then we can remove this whole SetupCopyFiles
>> construct and just add .gif to jdk.hotspot.agent_COPY.
>>
>> /Erik
>>
>> On 2016-02-26 04:28, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> HSDB toolbar icons 
>>> (hotspot/src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics)
>>> are missing in appmodules.jimage .
>>> They should be contained to appmodules.jimage .
>>>
>>> I've uploaded a webrev:
>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.00/
>>>
>>> Could you review it?
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>
>>


-- 
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(L): JDK-8067194 Restructure hotspot/agent/src to conform the modular source layout

[Dmitry Samersoff]

Thank you!


On 2015-12-22 18:39, Jaroslav Bachorik wrote:
> Hi,
> 
> looks good, modulo the problems you are mentioning (docs will need
> update to refer to correct locations; the same might be true for the
> textual output from scripts). I believe the tests are still passing.
> 
> Supposing the remaining problems are covered by CR you can consider this
> reviewed.
> 
> 
> Regards,
> 
> -JB-
> 
> On 21.12.2015 22:50, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please, review the changes:
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067194/webrevs.02/
>>
>> The problem:
>>
>>Serviceability agent source should follow source layout
>>convention for modular jdk.
>>
>> The solution:
>>
>>Move SA sources under src/jdk.hotspot.agent
>>
>>Move native code under jdk.hotspot.agent/{OS}/native/libsaproc
>>
>> Problems left:
>>* I'll file a CR for each of problem and fix it later.
>>
>>1. Custom gif copy routine left unchanged.
>>
>>2. The name of SA under windows left unchanged it's sawindbg.dll
>>
>>3. doc, scripts, test directories moved to a new location
>>   as is. It's content about to be evaluated.
>>
>> -Dmitry
>>
> 


-- 
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(L): JDK-8067194 Restructure hotspot/agent/src to conform the modular source layout

[Dmitry Samersoff]

Everybody,

Please, review the changes:

http://cr.openjdk.java.net/~dsamersoff/JDK-8067194/webrevs.02/

The problem:

  Serviceability agent source should follow source layout
  convention for modular jdk.

The solution:

  Move SA sources under src/jdk.hotspot.agent

  Move native code under jdk.hotspot.agent/{OS}/native/libsaproc

Problems left:
  * I'll file a CR for each of problem and fix it later.

  1. Custom gif copy routine left unchanged.

  2. The name of SA under windows left unchanged it's sawindbg.dll

  3. doc, scripts, test directories moved to a new location
 as is. It's content about to be evaluated.

-Dmitry

-- 
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(XS): JDK-8114853 variable tracking size limit exceeded in vmStructs.cpp

[Dmitry Samersoff]

Everybody,

I'd followed common opinion and turn off tracking of variable assignment
for vmStructs file only.

Updated webrev is here:

http://cr.openjdk.java.net/~dsamersoff/JDK-8114853/webrev.02/

-Dmitry

On 2015-11-19 14:58, Dmitry Samersoff wrote:
> Everybody,
> 
> Please review:
> 
> http://cr.openjdk.java.net/~dsamersoff/JDK-8114853/webrev.01/
> 
> Story:
> 
> VTA fails on huge VMStructs::init() so this method is being compiled twice.
> 
> VTA[1] allows compiler to emit DWARF-3 debugging information for local
> variable ever if this variable is optimized out at the cost of
> compilation time and compiler memory consumption.
> 
> So I decided to turn it off for entire hotspot build to reduce memory
> footprint/increase compilation speed.
> 
> 1. https://gcc.gnu.org/wiki/Var_Tracking_Assignments
> 
> -Dmitry
> 


-- 
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-8142336: Convert the SA agent build to modular build-infra makefiles

[Dmitry Samersoff]

Erik,

Looks good for me!

-Dmitry

On 2015-11-17 12: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
>>>>
>>>
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.

RFR(XS): JDK-8114853 variable tracking size limit exceeded in vmStructs.cpp

[Dmitry Samersoff]

Everybody,

Please review:

http://cr.openjdk.java.net/~dsamersoff/JDK-8114853/webrev.01/

Story:

VTA fails on huge VMStructs::init() so this method is being compiled twice.

VTA[1] allows compiler to emit DWARF-3 debugging information for local
variable ever if this variable is optimized out at the cost of
compilation time and compiler memory consumption.

So I decided to turn it off for entire hotspot build to reduce memory
footprint/increase compilation speed.

1. https://gcc.gnu.org/wiki/Var_Tracking_Assignments

-Dmitry

-- 
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: Can't find specified CC

[Dmitry Samersoff]

Frider,

I use command below to cross-compile JDK:

_cross_prefix="aarch64-unknown-linux-gnu"

  configure_params="${configure_params} \
--openjdk-target=${_cross_prefix}"

export CC=${_cross_prefix}-gcc
export CXX=${_cross_prefix}-g++
export LD=${_cross_prefix}-ld
export OBJCOPY=${_cross_prefix}-objcopy
export STRIP=${_cross_prefix}-strip

eval sh ./configure ${configure_params}

-Dmitry

On 2015-11-19 16:13, Frieder Berthold wrote:
> Hello to all,
> 
> I want to build the openJDK with a musl cross-compiler.
> For that reason I configure the project with CC=/absolut/path/to/my/compiler
> Configure then says that it can't find a working C Compiler.
> Using strace on the configure command I can see that it tries to open the
> specified path appended to some default paths (e.g
> /usr/local/sbin//absolut/path/to/my/compiler or
> /usr/bin//absolut/path/to/my/compiler)
> My solution right now is a symlink to my compiler in one of those paths,
> but this doesn't feel right.
> Is there a more correct way of doing it?
> 
> Frieder
> 


-- 
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-8142336: Convert the SA agent build to modular build-infra makefiles

[Dmitry Samersoff]

Erik,

Could you please file a new CR for warnings and assign it to me?

-Dmitry

On 2015-11-11 12: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.
> 
> /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
> 


-- 
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-8142336: Convert the SA agent build to modular build-infra makefiles

[Dmitry Samersoff]

Erik,

saproc.cpp:

222 static size_t alt_root_len = -1;

Could you revert this change?

size_t is always positive so it brake logic at ll. 227 and 249

-Dmitry


On 2015-11-09 21:33, Erik Joelsson wrote:
> Closed part of this review.
> 
> Bug: Bug: https://bugs.openjdk.java.net/browse/JDK-8142336
> Webrev with both open and closed changes:
> http://javaweb.us.oracle.com/~ejoelsso/webrev/8142336/webrev.closed.01/
> 
> /Erik


-- 
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 8140481: NoClassDefFoundError thrown by ManagementFactory.getPlatformMBeanServer

[Dmitry Samersoff]

Jaroslav,

Looks good for me  (not a reviewer).

-Dmitry

On 2015-11-02 11:08, Jaroslav Bachorik wrote:
> Please, review the following build change
> 
> Issue : https://bugs.openjdk.java.net/browse/JDK-8140481
> Webrev: http://cr.openjdk.java.net/~jbachorik/8140481/webrev.00
> 
> Currently, the 'jdk.management' module is not a part of the JRE image
> even though it should be. This patch adds 'jdk.management' to
> PROVIDER_MODULES where it belongs.
> 
> Thanks,
> 
> -JB-


-- 
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: 8076470 - JEP 240: Remove the JVM TI hprof Agent

[Dmitry Samersoff]

Serguei,
   Q1: Should the folder jdk/src/demo/share/jvmti/java_crw_demo also be
 removed?

Yes. See

https://bugs.openjdk.java.net/browse/JDK-8041639

-Dmitry

On 2015-08-07 12:24, serguei.spit...@oracle.com wrote:
 Hi Staffan,

 Looks good.

 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?

 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

 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






-- 
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: 8079360 AttachProviderImpl could not be instantiated

[Dmitry Samersoff]

Staffan,

Looks good for me.

-Dmitry

On 2015-05-06 21:51, Staffan Larsen wrote:
 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/
 bug: https://bugs.openjdk.java.net/browse/JDK-8079360
 
 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: Windows build failure in JDK8 with --disable-zip-debug-info

[Dmitry Samersoff]

Volker,

What version of *make* do you use in both cases?

-Dmitry

On 2015-03-12 17:34, Volker Simonis wrote:
 Hi,
 
 I understand that I'm a little late to the game but I just run into
 this problem myself:)
 
 The funny thing is that this problem doesn't occur with MinGW/MSYS but
 just with Cygwin and I can't understand why?
 
 We have a little special setup here at SAP: we do the Windows builds
 with MinGW/MSYS and by default we always build with
 --disable-zip-debug-info. So until now we had no problems.
 
 Now I started to migrate our build to Cygwin (but still with
 --disable-zip-debug-info) and run into the problem.
 
 I think the origin of the dependency on the .map (and .pdb) files is
 clear - it is set right in SetupNativeCompilation if we don't want to
 zip the debug information (i.e. --disable-zip-debug-info):
 
 ifeq ($(ZIP_DEBUGINFO_FILES), true)
   ...
 else
   ifeq ($(OPENJDK_TARGET_OS), windows)
 $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \
 $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb
 
 But we also have the following pattern rule in SetupNativeCompilation
 which should copy the .map and .pdb from OBJECT_DIR to OUTPUT_DIR:
 
 ifneq ($$($1_OUTPUT_DIR),$$($1_OBJECT_DIR))
   $$($1_OUTPUT_DIR)/% : $$($1_OBJECT_DIR)/%
   $(CP) $$ $$@
 endif
 
 This rule works perfectly with MinGW/MSYS but it doesn't get triggered
 with Cygwin. And that's the reason why we get the error *** No rule
 to make target 
 `/cygdrive/c/jprt/T/P1/031627.daholme/s/build/windows-x86-normal-clientANDserver-release/jdk/bin/verify.map'
 which says that it can not make the .map file in the OUTPUT_DIR. But
 notice that the .map file is there in the OBJECT_DIR directory (i.e.
 ../objs/libverify/verify.map), but make under Cygwin somehow doesn't
 recognize that there's a rule to copy it over to the OUTPUT_DIR
 directory.
 
 I tried the workaround proposed by Magnus' but unfortunately it
 doesn't work. I think that's because the problem is not that the .map
 files are not created - the problem is that they are not copied over
 to the OUTPUT_DIR.
 
 So here's what really helped:
 
   ifeq ($(OPENJDK_TARGET_OS), windows)
 $1 += $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map \
 $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb
 
 $$($1_OUTPUT_DIR)/$$($1_LIBRARY).map :
 $$($1_OBJECT_DIR)/$$($1_LIBRARY).map
   echo Copying .map from OBJECT_DIR to OUTPUT_DIR
   $(CP) $$ $$@
 $$($1_OUTPUT_DIR)/$$($1_LIBRARY).pdb :
 $$($1_OBJECT_DIR)/$$($1_LIBRARY).pdb
echo Copying .pdb from OBJECT_DIR to OUTPUT_DIR
$(CP) $$ $$@
 
 And you need the same fix for the PROGRAM build part:
 
   ifeq ($(OPENJDK_TARGET_OS), windows)
 $1 += $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map \
 $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb
 
 $$($1_OUTPUT_DIR)/$$($1_PROGRAM).map :
 $$($1_OBJECT_DIR)/$$($1_PROGRAM).map
echo Copying .map from OBJECT_DIR to OUTPUT_DIR
$(CP) $$ $$@
 $$($1_OUTPUT_DIR)/$$($1_PROGRAM).pdb :
 $$($1_OBJECT_DIR)/$$($1_PROGRAM).pdb
echo Copying .pdb from OBJECT_DIR to OUTPUT_DIR
$(CP) $$ $$@
 
 So for me this works now and I will change our internal build accordingly.
 
 I don't know if there's any interest of bringing this to jdk8u. I just
 though I'll let you know:)
 
 It would also be interesting if somebody has some explanation for why
 the pattern rule for copying the .map files works under MinGW/MSYS but
 not under Cygwin.
 
 Regards,
 Volker
 
 On Wed, Nov 5, 2014 at 2:00 PM, David Holmes david.hol...@oracle.com wrote:
 On 5/11/2014 10:27 PM, Magnus Ihse Bursie wrote:

 On 2014-11-05 13:25, Magnus Ihse Bursie wrote:

 I even have a vague memory of a fix along these lines in jdk9. If
 that's correct, it's probably due for backporting. I'll see if I can
 locate it.


 https://bugs.openjdk.java.net/browse/JDK-8025936

 It might be some work backporting it though, the comments in the bug
 says it needed to be substantially rewritten due to changes in JDK9.


 Thanks Magnus. Seems this is unlikely to be fixed then - which means I can't
 test what I'm working on for the case where we don't zip the debuginfo files
 :(

 David

 /Magnus


-- 
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: Use of /usr/ccs/bin on Solaris

[Dmitry Samersoff]

Martin,

if we *append* /usr/ccs/bin to the path we are in risk that configure
picks GNU tool instead of solaris one.

if we *prepend* /usr/ccs/bin to the path we lost an ability to override
/usr/ccs/bin tool with user-supplied one.

So both solutions above looks bad for me.

And yes, this all is mostly about *nm*

-Dmitry


On 2015-03-09 20:03, Martin Buchholz wrote:
 I support Magnus' strategy.
 
 Slightly unrelated, /usr/ccs/bin is a very old directory, and ISTR that
 it was slowly going away.
 
 On SunOS 5.10 I see a cornucopia of nm's muddying the waters:
 /usr/ccs/bin/sparcv9/nm
 /usr/ccs/bin/nm
 /usr/xpg4/bin/nm
 /usr/sfw/sparc-sun-solaris2.10/bin/nm
 
 
 On Fri, Mar 6, 2015 at 10:09 PM, Magnus Ihse Bursie
 magnus.ihse.bur...@oracle.com mailto:magnus.ihse.bur...@oracle.com
 wrote:
 
 
  6 mar 2015 kl. 20:17 skrev Dmitry Samersoff
 dmitry.samers...@oracle.com mailto:dmitry.samers...@oracle.com:
 
  Magnus,
 
  You can add a generic warning:
 
  if configure fails finding some tools and it's solaris
  then
   warn about /usr/ccs/bin that should be in a path
  end
 
 This is exactly what I said would be technically hard to do. Much
 harder than what's justified for this issue.
 
 
  I'm against of altering PATH any way (appending or prepending anything)
  because it might lead to the situation where wrong tool is picked and
  it's hard to debug.
 
 I think we might just be misunderstanding each other here. Configure
 will not (and in fact cannot) alter the user's PATH in his/her
 environment.
 
 We do use the PATH as one way - but not the only way - to find tools
 needed to be able to build. One of the design goals of the configure
 script is if the tool exist on the system, we should find it. This
 is to minimize the amount of configuration needed by the user.
 
 If you are worried that configure should find a tool that would
 work, but not be the exact version that you wanted, then you will
 have to point it out for configure, using eg. --with-devkit,
 --with-bootjdk, SED=, GREP= etc.
 
 So looking in /usr/ccs/bin instead of failing, is just like the rest
 of the processing configure does.
 
 /Magnus
 
 
  -Dmitry
 
 
 
  On 2015-03-06 17:50, Magnus Ihse Bursie wrote:
  On 2015-03-04 22:03, Martin Buchholz wrote:
  I agree that configure should not mess with user's PATH and should
  auto-find programs in /usr/ccs/bin only as a last resort.
 
  It would be reasonable, when configure fails on Solaris, to notice
  that the
  user does not have /usr/ccs/bin on PATH and suggest appending.
 
  I have opened https://bugs.openjdk.java.net/browse/JDK-8074557.
 
  Adding a warning to failed configure on Solaris due to missing build
  tools that presumably resides in /usr/ccs/bin seems like quite a
 lot of
  work.
 
  I suggest the following:
  Instead of prepending, append /usr/ccs/bin, so any binaries in the
  user's specified PATH are picked first. This will allow a
 properly set
  PATH to function, but it will still provide the best effort
 approach
  of configure to look in well-known locations for tools.
 
  Does that seem like an acceptable solution?
 
  /Magnus
 
 
  --
  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: Use of /usr/ccs/bin on Solaris

[Dmitry Samersoff]

Magnus,

On 2015-03-07 09:09, Magnus Ihse Bursie wrote:
 
 6 mar 2015 kl. 20:17 skrev Dmitry Samersoff dmitry.samers...@oracle.com:

 Magnus,

 You can add a generic warning:

 if configure fails finding some tools and it's solaris
 then
  warn about /usr/ccs/bin that should be in a path
 end
 
 This is exactly what I said would be technically hard to do. Much harder than 
 what's justified for this issue. 

What about

if configure fails for any reason and it's solaris
then
  warn about /usr/ccs/bin that should be in a path
end

or ever

if /usr/ccs/bin is not in the path and it's solaris
then
  warn about /usr/ccs/bin that should be in a path
end


 I'm against of altering PATH any way (appending or prepending anything)
 because it might lead to the situation where wrong tool is picked and
 it's hard to debug.
 
 I think we might just be misunderstanding each other here. Configure will not 
 (and in fact cannot) alter the user's PATH in his/her environment. 
 
 We do use the PATH as one way - but not the only way - to find tools needed 
 to be able to build. One of the design goals of the configure script is if 
 the tool exist on the system, we should find it. This is to minimize the 
 amount of configuration needed by the user. 
 
 If you are worried that configure should find a tool that would work, but not 
 be the exact version that you wanted, then you will have to point it out for 
 configure, using eg. --with-devkit, --with-bootjdk, SED=, GREP= etc. 
 
 So looking in /usr/ccs/bin instead of failing, is just like the rest of the 
 processing configure does.

If configure picks (e.g.) wrong *nm* it can cause a fail when linker
attempts to apply version script and at this stage it is not obvious
what is going wrong.

So I still against of altering user PATH.

-Dmitry


 
 /Magnus
 

 -Dmitry



 On 2015-03-06 17:50, Magnus Ihse Bursie wrote:
 On 2015-03-04 22:03, Martin Buchholz wrote:
 I agree that configure should not mess with user's PATH and should
 auto-find programs in /usr/ccs/bin only as a last resort.

 It would be reasonable, when configure fails on Solaris, to notice
 that the
 user does not have /usr/ccs/bin on PATH and suggest appending.

 I have opened https://bugs.openjdk.java.net/browse/JDK-8074557.

 Adding a warning to failed configure on Solaris due to missing build
 tools that presumably resides in /usr/ccs/bin seems like quite a lot of
 work.

 I suggest the following:
 Instead of prepending, append /usr/ccs/bin, so any binaries in the
 user's specified PATH are picked first. This will allow a properly set
 PATH to function, but it will still provide the best effort approach
 of configure to look in well-known locations for tools.

 Does that seem like an acceptable solution?

 /Magnus


 -- 
 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: Use of /usr/ccs/bin on Solaris

[Dmitry Samersoff]

Magnus,

You can add a generic warning:

if configure fails finding some tools and it's solaris
then
  warn about /usr/ccs/bin that should be in a path
end

I'm against of altering PATH any way (appending or prepending anything)
because it might lead to the situation where wrong tool is picked and
it's hard to debug.

-Dmitry



On 2015-03-06 17:50, Magnus Ihse Bursie wrote:
 On 2015-03-04 22:03, Martin Buchholz wrote:
 I agree that configure should not mess with user's PATH and should
 auto-find programs in /usr/ccs/bin only as a last resort.

 It would be reasonable, when configure fails on Solaris, to notice
 that the
 user does not have /usr/ccs/bin on PATH and suggest appending.
 
 I have opened https://bugs.openjdk.java.net/browse/JDK-8074557.
 
 Adding a warning to failed configure on Solaris due to missing build
 tools that presumably resides in /usr/ccs/bin seems like quite a lot of
 work.
 
 I suggest the following:
 Instead of prepending, append /usr/ccs/bin, so any binaries in the
 user's specified PATH are picked first. This will allow a properly set
 PATH to function, but it will still provide the best effort approach
 of configure to look in well-known locations for tools.
 
 Does that seem like an acceptable solution?
 
 /Magnus


-- 
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 (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

[Dmitry Samersoff]

Dean,

Looks good for me. (not a reviewer)

Thank you for fixing it.

-Dmitry

On 2015-01-22 01:39, Dean Long wrote:
 Thanks Dmitry.  The updated webrev is here:
 
 http://cr.openjdk.java.net/~dlong/8031064/webrev.3/
 
 dl
 
 On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
 Dean,

 vm.make  ll. 247

 1. *.o should be  $(Obj_Files)

 2.

 $(NM) --defined-only *.o | sort -k3 -u |
   awk '/$(VMDEF_PAT)/{ print \t $$3 ; }'

 should give you the same result with less efforts

 -Dmitry

 On 2015-01-21 07:59, Dean Long wrote:
 Here's version 2, which does everything in vm.make and doesn't do
 anything that is shell-specific:

 http://cr.openjdk.java.net/~dlong/8031064//webrev.2/

 thanks,

 dl

 


-- 
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 (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

[Dmitry Samersoff]

Dean,

 Can we make cleaning up the other platforms
 a separate RFE?

I think yes. So please file the RFE.

-Dmitry


On 2015-01-22 21:01, Dean Long wrote:
 On 1/22/2015 2:19 AM, David Holmes wrote:
 On 22/01/2015 8:39 AM, Dean Long wrote:
 Thanks Dmitry.  The updated webrev is here:

  http://cr.openjdk.java.net/~dlong/8031064/webrev.3/

 This looks weird:

 + VMDEF_PAT  = ^_ZTV
 + VMDEF_PAT := ^gHotSpotVM|$(VMDEF_PAT)
 + VMDEF_PAT := ^UseSharedSpaces$$|$(VMDEF_PAT)
 + VMDEF_PAT := ^_ZN9Arguments17SharedArchivePathE$$|$(VMDEF_PAT)

 but I can sort of see why you wanted to do it that way.

 
 Do you have a suggestion for a less-weird-looking way to do it?
 
 I assume you have verified the results are identical?

 
 Yes.
 
 I would be good to see this applied uniformly across all platforms as
 well (except windows).

 
 I suppose, but isn't linux the only platform where we might be
 cross-compiling?  I'm not setup to
 build for aix, bsd, or solaris, and if I build in JPRT, I'm not sure it
 will save the vm.def or mapfile to
 make a comparison against.  Can we make cleaning up the other platforms
 a separate RFE?
 
 dl
 
 Thanks,
 David

 dl

 On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
 Dean,

 vm.make  ll. 247

 1. *.o should be  $(Obj_Files)

 2.

 $(NM) --defined-only *.o | sort -k3 -u |
   awk '/$(VMDEF_PAT)/{ print \t $$3 ; }'

 should give you the same result with less efforts

 -Dmitry

 On 2015-01-21 07:59, Dean Long wrote:
 Here's version 2, which does everything in vm.make and doesn't do
 anything that is shell-specific:

 http://cr.openjdk.java.net/~dlong/8031064//webrev.2/

 thanks,

 dl


 


-- 
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 (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

[Dmitry Samersoff]

Dean,

vm.make  ll. 247

1. *.o should be  $(Obj_Files)

2.

$(NM) --defined-only *.o | sort -k3 -u |
 awk '/$(VMDEF_PAT)/{ print \t $$3 ; }'

should give you the same result with less efforts

-Dmitry

On 2015-01-21 07:59, Dean Long wrote:
 Here's version 2, which does everything in vm.make and doesn't do
 anything that is shell-specific:
 
 http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
 
 thanks,
 
 dl


-- 
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(XS): 8066589: Make importing sa-jdi.jar optional on its existance

[Dmitry Samersoff]

Volker,

I'm OK with your fix.

-Dmitry

On 2014-12-09 20:42, Volker Simonis wrote:
 That's fine, but we currently can not build on AIX because of this
 issue and I don't want to stay without builds until the mentioned bugs
 are fixed (especially when the fix for the issue is so simple and
 non-intrusive for other platforms).
 
 Regards,
 Volker
 
 On Tue, Dec 9, 2014 at 6:23 PM, Dmitry Samersoff
 dmitry.samers...@oracle.com wrote:
 Volker,

 Please notice, there is work-in-progress to cease out any dependencies
 to jdk.hotspot.agent from other modules.


 Please, see:

 https://bugs.openjdk.java.net/browse/JDK-8059038
 https://bugs.openjdk.java.net/browse/JDK-8059035

 -Dmitry


 On 2014-12-09 20:12, Volker Simonis wrote:
 On Fri, Dec 5, 2014 at 10:11 AM, Erik Joelsson erik.joels...@oracle.com 
 wrote:
 Hello Volker,

 Are these the only conditions for when sa-jdi.jar is not built? If so, then
 I suppose this is fine.

 Yes. But with my proposed solution any new platform may easily add
 itself to the list of platforms which don't have the SA-agent.


 The old Import.gmk would only copy sa-jdi.jar if it existed, and I think we
 can keep that behavior, so just an existence check on sa-jdi.jar is good
 enough in Import.gmk. In Gensrc-jdk.jdi.gmk, checking if
 $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services exists 
 should
 be fine with me. We lose a bit of error checking in the build doing it that
 way as we won't fail if that file is missing for other reasons.


 I don't quite understand. If a platform doesn't support the SA-agent
 there's no need for any error checking. This fix doesn't change the
 behaviour on any other platform except for aix-ppc64 and ZERO. Any
 other platforms which don't support the SA just add themselves to the
 lisst in the if-statement without affecting the other platforms.



 Note that this hacking of the service provider files is a temporary hack
 until service providers are properly handled in the modular world, so no
 need for fancy solutions.

 OK fine. I've added one more tiny fix which was needed to build on
 AIX. It's in an if-def AIX anyway, so it won't impact other platforms.
 It just fixes the location of the static version of libjli:

 http://cr.openjdk.java.net/~simonis/webrevs/8066589.v2/

 OK to push now?

 Thanks,
 Volker


 /Erik


 On 2014-12-04 18:49, Volker Simonis wrote:

 Hi,

 could you please review this tiny change which fixes the build on
 platforms which don't built the SA agent after the recent modualrity
 integrations:

 http://cr.openjdk.java.net/~simonis/webrevs/8066589
 https://bugs.openjdk.java.net/browse/JDK-8066589

 I've tested that the fix works on AIX but I havn't had a chance to build
 Zero.

 @Xerxes: maybe you could check if my suggested fix also solves your
 build problems. I'm also no sure if the ifneq ($(JVM_VARIANT_ZERO),
 true) clause also catches the ZEROSHARK case (altough I think it
 should). If not we would need yet another ifneq
 ($(JVM_VARIANT_ZEROSHARK), true)

 Thanks,
 Volker




 --
 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(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005

[Dmitry Samersoff]

Dan,

The fix looks good for me.

-Dmitry


On 2014-11-15 00:30, Daniel D. Daugherty wrote:
 I presume I don't need to sent out another webrev...
 
 I have to change my mind on this because this fix needs to be
 backported to JDK8u-hs-dev.
 
 Here's the updated JDK9 webrev:
 
 http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/
 
 And here's the JDK8u-hs-dev backport:
 
 http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/
 
 Because of improvements to the JDK9 makefiles, a bunch of the
 anchor text has changed. The best way to sanity check the backport
 is to download the two patch files and look at them in your favorite
 diff tool:
 
 http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/hotspot.patch
 
 http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/8033602_for_jdk8u_hs_dev.patch
 
 
 I need just one sanity check on the backport...
 
 Thanks, in advance, for any comments, questions or suggestions.
 
 Dan
 
 
 On 11/13/14 11:18 AM, Daniel D. Daugherty wrote:
 Magnus,

 Thanks for the review!

 Replies embedded below...

 On 11/13/14 7:44 AM, Magnus Ihse Bursie wrote:
 On 2014-11-11 01:00, Daniel D. Daugherty wrote:
 Greetings,

 I have a Solaris Full Debug Symbols (FDS) fix ready for review.
 Yes, it is a small fix, but it is in Makefiles so feel free to
 run screaming from the room... :-)  On the plus side the fix does
 delete two work around source files (Coleen would say that's a
 Good Thing (TM)!)

 ... but you're only deleting the make files?

 Good catch! Looks like when I resurrected this fix from my JDK8
 queue I missed a couple of deletes.


 src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and
 src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c
 could be deleted as well, right?

 Yes, these should be deleted and I'll do that in this fix.
 Since these are two deletes of files that can no longer be
 built anyway, I presume I don't need to sent out another
 webrev...



 Good idea for the fix, anyway. I opened
 https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a
 similar solution in configure.

 Sounds good to me.

 Dan



 /Magnus
 
 
 
 On 11/10/14 5:00 PM, Daniel D. Daugherty wrote:
 Greetings,

 I have a Solaris Full Debug Symbols (FDS) fix ready for review.
 Yes, it is a small fix, but it is in Makefiles so feel free to
 run screaming from the room... :-)  On the plus side the fix does
 delete two work around source files (Coleen would say that's a
 Good Thing (TM)!)

 The fix is to detect the version of GNU objcopy that is being
 used on the machine and only enable Full Debug Symbols when that
 version is 2.21.1 or newer. If you don't have the right version,
 then the build drops back to pre-FDS build configs with a message
 like this:

 WARNING: /usr/sfw/bin/gobjcopy --version info:
 WARNING: GNU objcopy 2.15
 WARNING: an objcopy version of 2.21.1 or newer is needed to create
 valid .debuginfo files.
 WARNING: ignoring above objcopy command.
 WARNING: patch 149063-01 or newer contains the correct Solaris 10
 SPARC version.
 WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86
 version.
 WARNING: Solaris 11 Update 1 contains the correct version.
 INFO: no objcopy cmd found so cannot create .debuginfo files.
 INFO: ENABLE_FULL_DEBUG_SYMBOLS=0

 This work is being tracked by the following bug IDs:

 JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC
 https://bugs.openjdk.java.net/browse/JDK-8033602

 JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on
 Solaris X86
 https://bugs.openjdk.java.net/browse/JDK-8034005

 Here is the webrev URL:

 http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/

 Testing:

 - JPRT test jobs to verify that the current JPRT Solaris hosts
   are happy
 - local builds on my Solaris 10 X86 machine to verify that the
   wrong version of GNU objcopy is caught

 Thanks, in advance, for any comments, questions or suggestions.

 Dan


-- 
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) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005

[Dmitry Samersoff]

Dan,

1. defs.make:

It might be better to join obcopy version check and condition at ll.190

otherwise the user will have a wrong version warning and then misleading
message no objcopy cmd found

2. Did you consider moving objcopy detection to configure?


-Dmitry


On 2014-11-11 03:00, Daniel D. Daugherty wrote:
 Greetings,
 
 I have a Solaris Full Debug Symbols (FDS) fix ready for review.
 Yes, it is a small fix, but it is in Makefiles so feel free to
 run screaming from the room... :-)  On the plus side the fix does
 delete two work around source files (Coleen would say that's a
 Good Thing (TM)!)
 
 The fix is to detect the version of GNU objcopy that is being
 used on the machine and only enable Full Debug Symbols when that
 version is 2.21.1 or newer. If you don't have the right version,
 then the build drops back to pre-FDS build configs with a message
 like this:
 
 WARNING: /usr/sfw/bin/gobjcopy --version info:
 WARNING: GNU objcopy 2.15
 WARNING: an objcopy version of 2.21.1 or newer is needed to create valid
 .debuginfo files.
 WARNING: ignoring above objcopy command.
 WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC
 version.
 WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86
 version.
 WARNING: Solaris 11 Update 1 contains the correct version.
 INFO: no objcopy cmd found so cannot create .debuginfo files.
 INFO: ENABLE_FULL_DEBUG_SYMBOLS=0
 
 This work is being tracked by the following bug IDs:
 
 JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC
 https://bugs.openjdk.java.net/browse/JDK-8033602
 
 JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on
 Solaris X86
 https://bugs.openjdk.java.net/browse/JDK-8034005
 
 Here is the webrev URL:
 
 http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/
 
 Testing:
 
 - JPRT test jobs to verify that the current JPRT Solaris hosts
   are happy
 - local builds on my Solaris 10 X86 machine to verify that the
   wrong version of GNU objcopy is caught
 
 Thanks, in advance, for any comments, questions or suggestions.
 
 Dan


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.

Re: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005

[Dmitry Samersoff]

Dan,

Thank you for the explanation.

The fix looks good for me.

-Dmitry

On 2014-11-11 18:40, Daniel D. Daugherty wrote:
 Dmitry,
 
 Thanks for the quick review!
 
 Replies embedded below...
 
 
 On 11/11/14 1:35 AM, Dmitry Samersoff wrote:
 Dan,

 1. defs.make:

 It might be better to join obcopy version check and condition at ll.190
 
 I looked at that... The seemingly natural place to put the version check
 is actually in the else branch on line 194... However, if the version
 check is bad, then you have to make a second check for a reset OBJCOPY
 value (along with indenting all the code another level or two).
 
 It just looked ugly... it seemed better to keep the version check
 separate from the other logic.
 
 
 otherwise the user will have a wrong version warning and then misleading
 message no objcopy cmd found
 
 However, part of that wrong version warning is this line:
 
 WARNING: ignoring above objcopy command.
 
 so in reality that no objcopy cmd found is just confirming
 that we are indeed ignoring the objcopy cmd that we found...
 
 
 2. Did you consider moving objcopy detection to configure?
 
 No because this fix has to be backported to JDK8u and JDK7 since
 we support FDS in those releases...
 
 Of course, the build-infra team is always welcome to use a new
 bug to evolve this code for JDK9 and newer.
 
 Again, thanks for the review!
 
 Dan
 
 


 -Dmitry


 On 2014-11-11 03:00, Daniel D. Daugherty wrote:
 Greetings,

 I have a Solaris Full Debug Symbols (FDS) fix ready for review.
 Yes, it is a small fix, but it is in Makefiles so feel free to
 run screaming from the room... :-)  On the plus side the fix does
 delete two work around source files (Coleen would say that's a
 Good Thing (TM)!)

 The fix is to detect the version of GNU objcopy that is being
 used on the machine and only enable Full Debug Symbols when that
 version is 2.21.1 or newer. If you don't have the right version,
 then the build drops back to pre-FDS build configs with a message
 like this:

 WARNING: /usr/sfw/bin/gobjcopy --version info:
 WARNING: GNU objcopy 2.15
 WARNING: an objcopy version of 2.21.1 or newer is needed to create valid
 .debuginfo files.
 WARNING: ignoring above objcopy command.
 WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC
 version.
 WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86
 version.
 WARNING: Solaris 11 Update 1 contains the correct version.
 INFO: no objcopy cmd found so cannot create .debuginfo files.
 INFO: ENABLE_FULL_DEBUG_SYMBOLS=0

 This work is being tracked by the following bug IDs:

  JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC
  https://bugs.openjdk.java.net/browse/JDK-8033602

  JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on
 Solaris X86
  https://bugs.openjdk.java.net/browse/JDK-8034005

 Here is the webrev URL:

 http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/

 Testing:

 - JPRT test jobs to verify that the current JPRT Solaris hosts
are happy
 - local builds on my Solaris 10 X86 machine to verify that the
wrong version of GNU objcopy is caught

 Thanks, in advance, for any comments, questions or suggestions.

 Dan

 


-- 
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: Symbols in libjvm.so

[Dmitry Samersoff]

Bharadwaj,

Just FYI, the problem is tracked under JDK-8034065

-Dmitry

[1]
https://bugs.openjdk.java.net/browse/JDK-8034065


On 2014-09-06 05:46, S. Bharadwaj Yadavalli wrote:
 Thanks for the pointers, Gary and John.
 
 Bharadwaj
 
 
 On 09/05/2014 05:56 PM, John Rose wrote:
 That topic comes up every so often.  This conversation on hotspot-dev
 in Ferbruary is probably relevant:

 http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012631.html


 On Sep 5, 2014, at 1:14 PM, S. Bharadwaj Yadavalli
 bharadwaj.yadava...@oracle.com wrote:
 ...


-- 
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 (XS) 8033946 - Hotspot build should ignore ide folder

[Dmitry Samersoff]

Gerard,

we already have ./jdk/make/netbeans, ./langtools/make/netbeans and I
think it's a good pattern to follow. You can create hotspot/make/xcode
and don't change the makefile.

Also with upcoming switch to full forest build you may consider to
create ide folder at top level and move per ws projects to it.

Nevertheless, if you decide to go ahead with makefile changes, it
requires some find machinery. Something like

$(FIND) -L $(HOTSPOT_TOPDIR) -name .hg -prune -o \( -name ide -a
-type d \) -prune -o -print

current patch filter out all files and directories containing char
sequence ide e.g. side, accidental etc.

-Dmitry


On 2014-09-04 20:45, Gerard Ziemski wrote:
 hi all,
 
 Please review a very small fix that makes hotspot build ignore ide
 folder, which is where local users can store their own favorite IDE
 projects.
 
 For those interested, I have an Xcode project for JDK8 and JDK9 that I
 am personally actively supporting and using, which is hosted at
 https://orahub.oraclecorp.com/gerard.ziemski/xcode that is meant to be
 put in jdk/hotspot/ide folder.
 
 
 Summary of fix:
 
 Exclude ide folder from the makefile that searches for hotspot src
 files, or otherwise make bails out complaining that it does not know how
 to handle Xcode project files.
 
 
 Testing:
 
 Passes local build on Mac OS X
 
 
 References:
 
 bug: https://bugs.openjdk.java.net/browse/JDK-8033946
 
 webrev: http://cr.openjdk.java.net/~gziemski/8033946_rev0/
 
 
 Thank you!
 
 


-- 
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: OpenJDK9 - build errors on Linux/Ubuntu 12.04

[Dmitry Samersoff]

*  |  **Blog
 http://neomatrix369.wordpress.com**  |  *LJC Associate  LJC Advocate
 (@adoptopenjdk  @adoptajsr programs)
 *Meet-a-Project - *MutabilityDetector
 https://github.com/MutabilityDetector*  |  **Bitbucket
 https://bitbucket.org/neomatrix369* * |  **Github
 https://github.com/neomatrix369* * |  **LinkedIn
 http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b*
 *Come to Devoxx UK 2014:* http://www.devoxx.co.uk/

 *Don't chase success, rather aim for Excellence, and success will come
 chasing after you!*





-- 
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: Proposal: jtreg tests with native components

[Dmitry Samersoff]

Staffan,

Couple of tests require both Java and native code, so compiling it's all
into the single directory might be a problem. Some test used to access
additional data in TESTSRC so we have to copy it as well.

One of possible solution is to allow the tests to support two
independent steps - build and run.

on build side - run all tests with build parameter, tests that don't
have build step will just do nothing and continue work as today. Then
bundle entire test tree.

on test side - run all tests with the run parameters. Test that have
build step have to copy all required files from build output directory
to work directory.

JDK configuration options could be provided through include file for
make/shell or property file.

It allows the test to achieve whatever build and test behavior it
requires and allows us to move to right direction, without breaking
existing things.

-Dmitry

On 2014-04-25 16:02, Staffan Larsen wrote:
 There are a couple of jtreg tests today that depend on native components 
 (either JNI libraries or executables). These are handled in one of two ways:
 
 1) The binaries are pre-compiled and 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
 


-- 
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: copy folders instead of sequential hg clones

[Dmitry Samersoff]

Peter,

After local clone your .hg/hgrc file contains

[paths]
default = your location

instead of http://hg.openjdk.java.net/jdk9/hs-rt

You have to fix it to do update/push. And it's the only thing you have
to fix.

-Dmitry

On 2014-04-14 20:13, Pete Brunet wrote:
 
 On 4/12/14 4:32 AM, Dmitry Samersoff wrote:
 Peter,

 It's perfectly fine to just copy entire forest.

 Local clone is faster than copy, but you have to restore .hg/hgrc
 afterward if you plan to do the push from this workspace.
 Hi Dimitri, I tried local clone first and that was the first thing I
 noticed so I was concerned there might be other problems and decided to
 cp my directory instead.  Is the .hg/hgrc the only file I'd need to copy
 after local cloning?

 My typical workflow:

 1. The script mirrors hs-rt and dev to dedicated machine every night. It
 is always a full clone from scratch.

 3. Starting a new CR, I create a directory with CR number, file called
 comments with ojdk push message and copy nightly workspace to it.

 4. When fix is ready, I create a webrev against local ws (webrev -N) and
 put it to cr.openjdk.java.net using sshfs or special script.

 5. After all reviews, I go to one of shared server, clone fresh
 workspace, apply patch form webrev to it and submit a commit job.
 Thanks for that.

 -Dmitry


 On 2014-04-12 05:12, Pete Brunet wrote:
 Hi Jon, I am on VPN from Austin.  It has always taken forever.  And
 downloading programs from the internet when on VPN takes forever.  I
 started looking into this a while back and I don't know if this is the
 issue but I found that the DNS servers are in Europe when I am on VPN. 
 Right now as reported by ipconfig /all my Cisco AnyConnect DNS servers are:

 144.20.190.70 in Madrid
 192.135.82.132 in Amsterdam

 Pete

 On 4/11/14 7:07 PM, Jonathan Gibbons wrote:
 To me, this message raises the questions of why does it take
 forever? and, how long should it take?

 I see a wide range of expectations. Some folk can clone fast, and
 assume that everyone else can as well.  And then there's reports like
 this, that it takes forever.

 I'm all in favor of doing whatever it takes to speed up the workflow,
 but where is the threshold between yeah, it really does take this
 long and if it takes this long, something must be broken?

 -- Jon


 On 04/11/2014 04:26 PM, Pete Brunet wrote:
 Since it takes forever to clone on my Win machine, in the case where I
 want to work on several bugs, is it OK to instead clone the first
 directory and then cp -ar that to n additional directories?  -Pete

 


-- 
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: copy folders instead of sequential hg clones

[Dmitry Samersoff]

Peter,

It's perfectly fine to just copy entire forest.

Local clone is faster than copy, but you have to restore .hg/hgrc
afterward if you plan to do the push from this workspace.

My typical workflow:

1. The script mirrors hs-rt and dev to dedicated machine every night. It
is always a full clone from scratch.

3. Starting a new CR, I create a directory with CR number, file called
comments with ojdk push message and copy nightly workspace to it.

4. When fix is ready, I create a webrev against local ws (webrev -N) and
put it to cr.openjdk.java.net using sshfs or special script.

5. After all reviews, I go to one of shared server, clone fresh
workspace, apply patch form webrev to it and submit a commit job.

-Dmitry


On 2014-04-12 05:12, Pete Brunet wrote:
 Hi Jon, I am on VPN from Austin.  It has always taken forever.  And
 downloading programs from the internet when on VPN takes forever.  I
 started looking into this a while back and I don't know if this is the
 issue but I found that the DNS servers are in Europe when I am on VPN. 
 Right now as reported by ipconfig /all my Cisco AnyConnect DNS servers are:
 
 144.20.190.70 in Madrid
 192.135.82.132 in Amsterdam
 
 Pete
 
 On 4/11/14 7:07 PM, Jonathan Gibbons wrote:
 To me, this message raises the questions of why does it take
 forever? and, how long should it take?

 I see a wide range of expectations. Some folk can clone fast, and
 assume that everyone else can as well.  And then there's reports like
 this, that it takes forever.

 I'm all in favor of doing whatever it takes to speed up the workflow,
 but where is the threshold between yeah, it really does take this
 long and if it takes this long, something must be broken?

 -- Jon


 On 04/11/2014 04:26 PM, Pete Brunet wrote:
 Since it takes forever to clone on my Win machine, in the case where I
 want to work on several bugs, is it OK to instead clone the first
 directory and then cp -ar that to n additional directories?  -Pete

 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.

Re: JDK-8036003: Add variable not to separate debug information.

[Dmitry Samersoff]

Magnus,

Not, we are not doing it now.

But we should consider doing it in a future and therefore keep it in
mind when designing option to choose debug symbol mode.

-Dmitry

On 2014-03-24 15:18, Magnus Ihse Bursie wrote:
 On 2014-03-21 10:36, Dmitry Samersoff wrote:

 (c) Compression mode:

 1. none
 2. per-section compression, SHF_GNU_COMPRESSED [1]
 3. zip entire file

 
 Is 2 something we're doing? I couldn't find any references to it in the
 code. Or is it something we're planning to do?
 
 /Magnus


-- 
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: JDK-8036003: Add variable not to separate debug information.

[Dmitry Samersoff]

David,

In practice, we don't have to much to keep internally.

There are no reason to copy out some of .debug_* sections but keep other
ones.

So we have a matrix:

(a) Strip mode:

1. full
2. keep symbols
3. keep symbols and .debug_*


(b) Copy mode:

1. Copy all to ext file
2. Copy none to ext file


(c) Compression mode:

1. none
2. per-section compression, SHF_GNU_COMPRESSED [1]
3. zip entire file

Where
  *a2 + b2 + c2* have perfect sense,
  *a1 + b1 + c3* have no sense etc.


-Dmitry


Refs:
1.
https://sourceware.org/bugzilla/show_bug.cgi?id=11819
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01780.html


-Dmitry

On 2014-03-21 12:57, David Holmes wrote:
 On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote:

 I don't think this quite works as there are other variations not
 captured here. Rather than zipped it should just be external.
 Whether the debuginfo files are zipped or not is then an additional
 build time option. Additionally we still have to be able to control
 the degree of stripping that is carried out. It doesn't make sense to
 me to try and enumerate all possible combinations as top-level
 configure options.

 Further, as Dan was saying, this doesn't capture the overlap between
 internal and external because we still leave some symbols internal
 even when creating the debuginfo file.

 So I don't think this proposed categorization works. We still have
 three aspects:
 - generating symbols into the object files
 - stripping symbols from the final binaries
 - saving symbols into an external form

 Each of which can potentally be varied (of course if you don't
 generate symbols in the obj files stripping and saving are non issues).

 But they are not independent on each other!

 Unless you generate debug symbols, you can't strip them, nor save them
 elsewhere. So generating debug symbols (your item #1) is a prerequisite
 for the rest of your items.
 
 Yes I just said that. :)
 
 And while, technically, you can save symbols externally, and at the same
 time keep them in the binary, that does not make sense. So, in a
 practical sense, you are going to do #2 if you are going to do #3.
 
 But you can vary what is kept internally independent of what is made
 external.
 
 And you can't zip external symbols unless you create a non-zipped
 version. And if you zip them, it does not make sense to keep the
 non-zipped version.
 
 zip vs non-zip is just an issue of disk space. It is not a fundamental
 configuration choice, just a variation on how external symbols are
 packaged.
 
 And yes, we do not strip all debug information when creating external
 debug info. But there seems to be no real use case (not even for
 IcedTea, as it turned out) to want a completely stripped binary, I don't
 think that's worth discussing much. That's just part of how the external
 debuginfo scheme works.
 
 Umm we fully strip all our binaries in embedded.
 
 Can you give a more concrete example of the variations of your aspects
 that you think my suggested solution would not capture?
 
 I think I already have. There aren't tree simple choices here, there are
 three aspects, each of which could have different variants.
 
 If I could draw a flow chart easily I would but basically if you
 generate debug symbols you can then select what symbols are kept
 internally (the strip policy) and what are put externally (objcopy
 options), then for the external symbol file you can choose zipped or
 unzipped.
 
 Multiple inter-connected choices, not just three (or four if you add
 zipped)
 
 David
 
 /Magnus


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.

Re: JDK-8036003: Add variable not to separate debug information.

[Dmitry Samersoff]

David,

My point was that we don't need in fine grained selection of elf
sections on strip - three options are enough.

 Why does full strip + copy-all + zip make no sense? It is exactly what
 we do with embedded builds. (Naturally you have to copy before you
 strip)

Sorry! it should be: full strip + copy-none + zip

-Dmitry

On 2014-03-21 15:13, David Holmes wrote:
 On 21/03/2014 7:36 PM, Dmitry Samersoff wrote:
 David,

 In practice, we don't have to much to keep internally.

 There are no reason to copy out some of .debug_* sections but keep other
 ones.
 
 I'm not familiar with exactly what the different strip options do but
 the point is this is covered by the strip-policy.
 
 So we have a matrix:

 (a) Strip mode:

 1. full
 2. keep symbols
 3. keep symbols and .debug_*


 (b) Copy mode:

 1. Copy all to ext file
 2. Copy none to ext file


 (c) Compression mode:

 1. none
 2. per-section compression, SHF_GNU_COMPRESSED [1]
 3. zip entire file

 Where
*a2 + b2 + c2* have perfect sense,
 
 So now your compression mode may apply to either the external file or
 the original? That's even more permutations.
 
*a1 + b1 + c3* have no sense etc.
 
 Why does full strip + copy-all + zip make no sense? It is exactly what
 we do with embedded builds. (Naturally you have to copy before you strip)
 
 David
 -
 

 -Dmitry


 Refs:
 1.
 https://sourceware.org/bugzilla/show_bug.cgi?id=11819
 http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01780.html


 -Dmitry

 On 2014-03-21 12:57, David Holmes wrote:
 On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote:

 I don't think this quite works as there are other variations not
 captured here. Rather than zipped it should just be external.
 Whether the debuginfo files are zipped or not is then an additional
 build time option. Additionally we still have to be able to control
 the degree of stripping th
 *Subject:* Fwd: Re: Compute sizes of classes loat is carried out. It doesn't 
 make sense to
 me to try and enumerate all possible combinations as top-level
 configure options.

 Further, as Dan was saying, this doesn't capture the overlap between
 internal and external because we still leave some symbols internal
 even when creating the debuginfo file.

 So I don't think this proposed categorization works. We still have
 three aspects:
 - generating symbols into the object files
 - stripping symbols from the final binaries
 - saving symbols into an external form

 Each of which can potentally be varied (of course if you don't
 generate symbols in the obj files stripping and saving are non
 issues).

 But they are not independent on each other!

 Unless you generate debug symbols, you can't strip them, nor save them
 elsewhere. So generating debug symbols (your item #1) is a prerequisite
 for the rest of your items.

 Yes I just said that. :)

 And while, technically, you can save symbols externally, and at the
 same
 time keep them in the binary, that does not make sense. So, in a
 practical sense, you are going to do #2 if you are going to do #3.

 But you can vary what is kept internally independent of what is made
 external.

 And you can't zip external symbols unless you create a non-zipped
 version. And if you zip them, it does not make sense to keep the
 non-zipped version.

 zip vs non-zip is just an issue of disk space. It is not a fundamental
 configuration choice, just a variation on how external symbols are
 packaged.

 And yes, we do not strip all debug information when creating external
 debug info. But there seems to be no real use case (not even for
 IcedTea, as it turned out) to want a completely stripped binary, I
 don't
 think that's worth discussing much. That's just part of how the
 external
 debuginfo scheme works.

 Umm we fully strip all our binaries in embedded.

 Can you give a more concrete example of the variations of your
 aspects
 that you think my suggested solution would not capture?

 I think I already have. There aren't tree simple choices here, there are
 three aspects, each of which could have different variants.

 If I could draw a flow chart easily I would but basically if you
 generate debug symbols you can then select what symbols are kept
 internally (the strip policy) and what are put externally (objcopy
 options), then for the external symbol file you can choose zipped or
 unzipped.

 Multiple inter-connected choices, not just three (or four if you add
 zipped)

 David

 /Magnus




-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.

Re: build warnings

[Dmitry Samersoff]

Michael,

I'm totally agree with you (and had sent to build-dev approx the same
letter about two weeks ago).

On my opinion we should turn off unused parameter warning, at least for
product build.

-Dmitry


On 2014-02-07 14:02, Michael McMahon wrote:
 Just wondering is there a plan to deal with build warnings on Linux?
 
 I was experimenting with macros that could be used to deal with the
 -Wunused-parameter
 warning, but there are over 3700 occurrences and frankly it's not a very
 useful
 warning in the context of JNI formal function parameters at least. Some
 more useful
 warnings are getting lost in the noise.
 
 - Michael.
 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.

Re: RFR: JDK-8027584 disable ccache by default

[Dmitry Samersoff]

Magnus,

Glad to see ccache turned off by default but I'm second to David.

Please, keep --disable-ccache flag

-Dmitry

On 2014-01-29 13:03, David Holmes wrote:
 Hi Magnus,
 
 I don't object to ccache being off by default but I would like the
 --disable-ccache flag to remain otherwise I will have to edit a bunch of
 build scripts and will need different versions for 9 vs 8. So please
 maintain backward compatibility here.
 
 Aside: it would make most sense to me for there to be both --enable-x
 and --disable-x flags regardless of what the default might be.
 
 Thanks,
 David
 
 On 29/01/2014 9:31 AM, Magnus Ihse Bursie wrote:
 Bug: https://bugs.openjdk.java.net/browse/JDK-8027584

 While ccache can be used to speed up recompilations, there are also
 several issues with ccache. Old versions does not work correctly for the
 jdk (we try to detect that). It does not work well on other platforms
 than Linux; on Windows it does not work at all. Nevertheless is ccache
 enabled on Windows if it is installed, which it apparently tends to be
 with Cygwin nowadays, requiring the use of --disable-ccache to avoid
 compilation failure.

 In many circumstances ccache also does not provide any performance
 benefit. For instance, new compilations gets a performance hit. Only
 recompilations benefits.

 It is better to turn this upside down. This patch makes ccache disabled
 by default, on all platforms. If you want ccache and are sure you are in
 a situation that benefits from it, then you can enable it. It also
 removes the output in configure hinting that ccache should be used.

 WebRev:
 http://cr.openjdk.java.net/~ihse/JDK-8027584-disable-ccache-by-default/webrev.01



 /Magnus


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.

Re: (Urgent) RFR JDK-8033115 Bad merge between 8027584 and 8031759

[Dmitry Samersoff]

Looks good to me.


On 2014-01-29 15:13, Magnus Ihse Bursie wrote:
 Bug: https://bugs.openjdk.java.net/browse/JDK-8033115
 
 Due to a bad merge between 8027584 and 8031759, configure fails.
 
 The merge auto-applied, so I didn't think there would be any problems.
 But there was a missing S, causing configure to always fail. :-(
 
 Here's the patch:
 
 --- a/common/autoconf/build-performance.m4
 +++ b/common/autoconf/build-performance.m4
 @@ -172,7 +172,7 @@
  if test x$TOOLS_DIR != x; then
PATH=$TOOLS_DIR:$PATH
  fi
 -BASIC_REQUIRE_PROG(CCACHE, ccache)
 +BASIC_REQUIRE_PROGS(CCACHE, ccache)
  CCACHE_STATUS=enabled
  PATH=$OLD_PATH
elif test x$enable_ccache = xno; then
 
 
 /Magnus
 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

What is the reason for -Wunused-parameter for product build

[Dmitry Samersoff]

Hi Everyone,

What is the reason of enabling  -Wunused-parameter in product build?

It creates lots of noise (especially compiling java2d code).

It might be better to keep it on for fastdebug build but turn it off for
product.

-Dmitry

-- 
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: RR(S) 8030941: Darwin mapfile-vers doesn't work for other BSD

[Dmitry Samersoff]

David,

Thank you!

-Dmitry

On 2014-01-07 09:28, David Holmes wrote:
 Hi Dmitry,
 
 I didn't see any reviews of this ...
 
 On 22/12/2013 2:34 AM, Dmitry Samersoff 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/
 
 Seems okay to me.
 
 
 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.
 
 There have been some differences between platforms in the past but we
 may have cleaned all of those up now. Darwin/osx was the only build that
 complained about non-existent symbols listed in the map file.
 
 David


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

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

[Dmitry Samersoff]

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: RFR: 8030350: Enable additional compiler warnings for GCC

[Dmitry Samersoff]

Mike,

1. I'm not sure -Wformat-security has any value for us - it checks for case
  printf(string) with no extra arguments,
as it can cause buffer overrun if string comes from untrusted source.

2. It's possible to shorten command line by -Wformat=2 it implies

-Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k.

3. Send me link to webrev - I'll test it on freebsd.

-Dmitry


On 2013-12-18 09:41, Mike Duigou wrote:
 I have no objection to making the same improvements there but have no way to 
 test the result. I will update the changeset and re-request review with the 
 caveat that the BSD changes have not been tested.
 
 Mike
 
 
 On Dec 17 2013, at 18:31 , Christian Thalinger 
 christian.thalin...@oracle.com wrote:
 
 What about BSD?

 On Dec 17, 2013, at 4:08 PM, Mike Duigou mike.dui...@oracle.com wrote:

 Hello all;

 This is a change which enables additional compiler warnings for native 
 compilation when using GCC. The (-Wformat -Wformat-security) options are 
 supported by GCC 3.0.4 (the earliest version I checked, c. February 2002) 
 and later so we shouldn't see issues with incompatibility.- Wextra appears 
 to have been added in GCC 3.4.X line (c. 2004) so it should also be 
 reasonably well adopted and replaces -W.

 The core of the change is to add :

 -Wextra -Wno-unused-parameter -Wformat -Wformat-security 

 for general C and CC++ compilations. For HotSpot C++ compiles a slightly 
 less aggressive set is used:

 -Wformat -Wformat-security 

 is used. 

 Webrev here:

 http://cr.openjdk.java.net/~mduigou/JDK-8030350/0/webrev/

 For the curious, yes, the additional checks do generate additional 
 warnings. ;-)

 This change is targeted at the JDK 9 repos but could be backported to JDK 8 
 fairly easily/safely.

 Mike


 


-- 
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: 8026062 : (s) webrev.ksh: fix bug title web scraping, remove teamware, sac, open bug and wxfile support

[Dmitry Samersoff]

Mike,

Looks good for me

(not a reviewer)

-Dmitry



On 2013-10-17 02:31, Mike Duigou wrote:
 Reminder: 
 
 http://cr.openjdk.java.net/~mduigou/JDK-8026062/2
 
 needs final review.
 
 Mike
 
 On Oct 14 2013, at 11:56 , Mike Duigou mike.dui...@oracle.com wrote:
 

 On Oct 11 2013, at 18:03 , Weijun Wang wrote:

 The webrev shows quot; inside the Bug id header entry.

 I have fixed this. It was being double escaped. ie. amp;quot;

 Updated webrev:

 http://cr.openjdk.java.net/~mduigou/JDK-8026062/2



 Also, the following headers look a little suspicious:

  Compare against: ssh://hg.openjdk.java.net/jdk8/tl-gate
  Compare against version: -2

 I usually compare with -2 when -1 is an mq patch and I also have -N. But 
 the compare against line seems to show you are comparing to -2 of the 
 remote repo. That would include the last changeset.

 This is because I have 

 [mq]secret = True

 in my .hgrc file. (secret prevents me from accidentally committing mq 
 patches to a non-jcheck repo). It may look a little unfamiliar but it is not 
 a consequence of my webrev changes.


 It's so cool reviewing webrev itself without looking at the actual code 
 changes. :)

 Thank you for the review!

 Mike


 Thanks
 Max

 On 10/12/13 8:22 AM, Mike Duigou wrote:

 On Oct 11 2013, at 14:56 , Bradford Wetmore wrote:

 It never worked like it did in Teamware.

 Thanks Brad, that's what I thought reading the source. It appeared that it 
 had never been implemented for mercurial. I have removed support for -l

 Here's an updated webrev (generated with itself!):

 http://cr.openjdk.java.net/~mduigou/JDK-8026062/1

 In addition to removing support for -l it also cleans up options handling, 
 fixes incorrect escaping of # numeric character entities (pointed out by 
 John Rose), and adds some documentation to the -? help.

 Mike



 Brad

 On 10/11/2013 11:33 AM, Mike Duigou wrote:
 I should also ask if anyone is using the -l option. I would like to 
 delete it as well as it offers no particular value for mercurial (that I 
 can tell).

 Mike

 On Oct 10 2013, at 17:20 , Weijun Wang wrote:



 On 10/10/13 1:13 PM, Mike Duigou wrote:

 On Oct 9 2013, at 22:11 , Weijun Wang wrote:

 Some of us still use wxfile to generate a single webrev for code 
 changes in multiple repos. Is there another way to do it?

 Yes, you can pipe a simple file list to webrev to have it use that 
 list of files. I removed wxfile support in part because it's not 
 documented anywhere and there are alternatives. If you can confirm 
 that the alternatives are adequate I would very much appreciate being 
 able to go ahead with removing wxfile support.

 I tried to create a file list and pipe it to webrev.ksh -N -r -1 but 
 seems not working. Am I using the wrong options?

 Thanks
 Max



 


-- 
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: X509CertImpl.java compilation error on linux-x86

[Dmitry Samersoff]

Erik,

Thank you!

-Dmitry

On 2013-10-14 11:50, Erik Joelsson wrote:
 I have seen this before and filed this bug. It's currently the main
 stopper for making sjavac default.
 
 https://bugs.openjdk.java.net/browse/JDK-8025702
 
 /Erik
 
 On 2013-10-11 23:00, Dmitry Samersoff wrote:
 Brad,

 Thank you for greet idea. sjavac might be a culprit.

 -Dmitry


 On 2013-10-11 22:23, Bradford Wetmore wrote:
 Offhand, no idea.  Instance lives in sun.security.getInstance, and
 you're finding that class.  I haven't tried out sjavac, but given the
 warning build/linux-x86-normal-server-release/jdk/classes/javac_state,
 and that I've never seen this directory, might you be triggering a
 sjavac bug?

 If you simply need to build, I might suggest cleaning your JDK build and
 trying again (without sjavac).

 Brad




 On 10/11/2013 6:02 AM, Dmitry Samersoff wrote:
 Hi Everyone,

 I get weird error trying to compile latest hotspot-rt on linux-x86,

 I suspect something is wrong wit my machine setup, because the same
 workspace on linux-x64 compiles fine.

 Any idea what is happening?


 ## Starting jdk
 Compiling BUILD_JDK
 Note: Some input files use or override a deprecated API.
 Note: Recompile with -Xlint:deprecation for details.
 Note: Some input files use unchecked or unsafe operations.
 Note: Recompile with -Xlint:unchecked for details.
 Note: Some input files use or override a deprecated API.
 Note: Recompile with -Xlint:deprecation for details.
 Note: Some input files use unchecked or unsafe operations.
 Note: Recompile with -Xlint:unchecked for details.
 /usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/x509/X509CertImpl.java:436:


 error: cannot access Instance
   sigVerf = Signature.getInstance(algId.getName(),
 sigProvider);
  ^
 class file for sun.security.jca.GetInstance$Instance not found
 /usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/jca/GetInstance.java:238:


 error: cannot find symbol
   return new Instance(s.getProvider(), instance);
  ^
 symbol:   class Instance
 location: class GetInstance
 /usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/jca/GetInstance.java:245:


 error: cannot find symbol
   return new Instance(s.getProvider(), instance);
  ^
 symbol:   class Instance
 location: class GetInstance
 3 errors
 gmake[2]: ***
 [/usr/home/dms/ESC/JDK-8025812/hotspot-rt/build/linux-x86-normal-server-release/jdk/classes/javac_state]


 Error 255


 -Dmitry


 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.

X509CertImpl.java compilation error on linux-x86

[Dmitry Samersoff]

Hi Everyone,

I get weird error trying to compile latest hotspot-rt on linux-x86,

I suspect something is wrong wit my machine setup, because the same
workspace on linux-x64 compiles fine.

Any idea what is happening?


## Starting jdk
Compiling BUILD_JDK
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
/usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/x509/X509CertImpl.java:436:
error: cannot access Instance
sigVerf = Signature.getInstance(algId.getName(), sigProvider);
   ^
  class file for sun.security.jca.GetInstance$Instance not found
/usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/jca/GetInstance.java:238:
error: cannot find symbol
return new Instance(s.getProvider(), instance);
   ^
  symbol:   class Instance
  location: class GetInstance
/usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/jca/GetInstance.java:245:
error: cannot find symbol
return new Instance(s.getProvider(), instance);
   ^
  symbol:   class Instance
  location: class GetInstance
3 errors
gmake[2]: ***
[/usr/home/dms/ESC/JDK-8025812/hotspot-rt/build/linux-x86-normal-server-release/jdk/classes/javac_state]
Error 255


-Dmitry

-- 
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: X509CertImpl.java compilation error on linux-x86

[Dmitry Samersoff]

Brad,

Thank you for greet idea. sjavac might be a culprit.

-Dmitry


On 2013-10-11 22:23, Bradford Wetmore wrote:
 Offhand, no idea.  Instance lives in sun.security.getInstance, and
 you're finding that class.  I haven't tried out sjavac, but given the
 warning build/linux-x86-normal-server-release/jdk/classes/javac_state,
 and that I've never seen this directory, might you be triggering a
 sjavac bug?
 
 If you simply need to build, I might suggest cleaning your JDK build and
 trying again (without sjavac).
 
 Brad
 
 
 
 
 On 10/11/2013 6:02 AM, Dmitry Samersoff wrote:
 Hi Everyone,

 I get weird error trying to compile latest hotspot-rt on linux-x86,

 I suspect something is wrong wit my machine setup, because the same
 workspace on linux-x64 compiles fine.

 Any idea what is happening?


 ## Starting jdk
 Compiling BUILD_JDK
 Note: Some input files use or override a deprecated API.
 Note: Recompile with -Xlint:deprecation for details.
 Note: Some input files use unchecked or unsafe operations.
 Note: Recompile with -Xlint:unchecked for details.
 Note: Some input files use or override a deprecated API.
 Note: Recompile with -Xlint:deprecation for details.
 Note: Some input files use unchecked or unsafe operations.
 Note: Recompile with -Xlint:unchecked for details.
 /usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/x509/X509CertImpl.java:436:

 error: cannot access Instance
  sigVerf = Signature.getInstance(algId.getName(),
 sigProvider);
 ^
class file for sun.security.jca.GetInstance$Instance not found
 /usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/jca/GetInstance.java:238:

 error: cannot find symbol
  return new Instance(s.getProvider(), instance);
 ^
symbol:   class Instance
location: class GetInstance
 /usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/jca/GetInstance.java:245:

 error: cannot find symbol
  return new Instance(s.getProvider(), instance);
 ^
symbol:   class Instance
location: class GetInstance
 3 errors
 gmake[2]: ***
 [/usr/home/dms/ESC/JDK-8025812/hotspot-rt/build/linux-x86-normal-server-release/jdk/classes/javac_state]

 Error 255


 -Dmitry



-- 
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: 8025796: (s) hgforest.sh could trigger unbuffered output from hg without complicated machinations

[Dmitry Samersoff]

Mike,

You fix looks good for me. Thank you for doing it.

-Dmitry

On 2013-10-10 03:03, Mike Duigou wrote:
 Hello all;
 
 This changeset provides hgforest.sh a more consistent mechanism for ensuring 
 that the mercurial python instance produces unbuffered output (for timely 
 status). The technique used was suggested by Dmitry Samersoff and seems to 
 work on all platforms that I have tested it; linux, macos and solaris. I have 
 yet to test it on windows/cygwin but want to get other user's reports to 
 determine if this is a viable direction. 
 
 The changeset:
 
 http://cr.openjdk.java.net/~mduigou/JDK-8025796/0/webrev/
 
 Thanks,
 
 Mike
 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.

Re: RFR (S): JDK-8025933 Configure should support French cl.exe

[Dmitry Samersoff]

Francis,

We have exactly the same (or may be ever worse) problems in russia but I
still think it's good to stay with english locale during build.

1. Try applocale -

http://www.microsoft.com/en-us/download/details.aspx?id=13209

not sure it works for modern windows, for windowsXP it solved the problem.


2. Personally I use virtual box and virtual image. It allows me to have
clean window in one click when its behaviour become strange.

-Dmitry




On 2013-10-04 22:04, Francis ANDRE wrote:
 Changing the LANG to C or en_US does not work neither. The VS C++
 compiler does not use the LANG variable for providing messages. I know
 that on WXP, there are options to setup the language of work like
 English but I cannot turn my PC to English because others tools like
 Excel will work in English with the decimal point as '.' instead of the
 ',' for France... The setup of the language for WS Studio is just the
 one you choose at download time -- much like the JDK of Sun for Japanese
 or Chinese --; The point here is that I succeed in downloading the ENU
 VS2010 version but after the installation, it is the French version that
 runs
 
 Anyhow, I think that for this specific case of VS C++ which is not a
 compiler that follows the Linux/Cygwin rules --ie LANG=en_US, one should
 provide a way to support non en_US VS C++ compiler for computing the
 vervion used.
 
 Francis
 Le 04/10/2013 19:16, Naoto Sato a écrit :
 The issue here (and the reason why the rule is to run build in en_US)
 is that the build would be error prone if we allow running builds in
 locales other than US English. In the past, we had several build
 errors related to this, e.g., 'date' command produced differently
 formatted date string for each locale which resulted in build errors.

 Naoto

 On 10/4/13 9:42 AM, Magnus Ihse Bursie wrote:
 I agree that the general rule is to build in an English environment.
 Unfortunately, on Windows, it is not as trivial, nor often possible
 to get tools to produce different output by setting a locale. It is
 not the case with cl.exe, anyway. And in this case, Microsoft
 apparently does not provide the English version to French users.
 Hence this fix.

 /Magnus

 4 okt 2013 kl. 18:18 skrev Naoto Sato naoto.s...@oracle.com:

 Hi Magnus,

 Well, it would work for Latin languages, but not for others, e.g.,
 CJK. I thought that the general rule was to run the build in English
 environment. I would think that French CL.EXE would produce English
 version string on Windows configured for en_US locale.

 Naoto

 On 10/4/13 6:12 AM, Magnus Ihse Bursie wrote:
 Bug: https://bugs.openjdk.java.net/browse/JDK-8025933

 In France, it's not possible to download the English version of Visual
 Studio; hence CL.EXE presents itself as:
 Compilateur d'optimisation Microsoft (R) 32 bits C/C++ version
 16.00.30319.01 pour 80x86
 instead of
 Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01
 for 80x86

 With a simple fix we can handle this in configure as well.

 WebRev:
 http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.01



 /Magnus



 


-- 
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): JDK-8025933 Configure should support French cl.exe

[Dmitry Samersoff]

Magnus,

Besides general discussion of multi-language locale

fix looks good for me,

but I would prefer to have more generic comments there like

support for different formats of msvc version output

because the fix isn't french specific.

-Dmitry


On 2013-10-04 17:12, Magnus Ihse Bursie wrote:
 Bug: https://bugs.openjdk.java.net/browse/JDK-8025933
 
 In France, it's not possible to download the English version of Visual
 Studio; hence CL.EXE presents itself as:
 Compilateur d'optimisation Microsoft (R) 32 bits C/C++ version
 16.00.30319.01 pour 80x86
 instead of
 Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01
 for 80x86
 
 With a simple fix we can handle this in configure as well.
 
 WebRev:
 http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.01
 
 
 /Magnus


-- 
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: hgforest.sh still fails to detect Python

[Dmitry Samersoff]

Mike,

Thank you for doing it.

PS: If the only purpose of python detection is inforcing unbufered
output we can just set PYTHONUNBUFFERED [1] and run hg

[1]
http://docs.python.org/2/using/cmdline.html#envvar-PYTHONUNBUFFERED

-Dmitry

On 2013-10-04 08:28, Mike Duigou wrote:
 I did get started on this issue finally and have done the regression testing 
 to make sure it works across all of the required platforms. I will finish up 
 the patch in the next couple of weeks.
 
 Mike
 
 On Sep 11 2013, at 06:48 , Dmitry Samersoff wrote:
 
 Mike,

 hgforest still doesn't detect python because on my linux laptop hg
 headline is

 #!/usr/bin/env python

 I'd attached the patch I use (regenerated against latest tl with 8024200
 changes)

 -Dmitry

 On 2013-09-03 23:43, Mike Duigou wrote:
 Hello all;

 This is a very small change to trim optional whitespace off of the 
 interpreter directive which may appear in the hg wrapper script. The 
 whitespace is legal per https://en.wikipedia.org/wiki/Shebang_%28Unix%29 
 and is now included in some distributions of mercurial (Ubuntu 13.04).

 http://cr.openjdk.java.net/~mduigou/JDK-8024200/0/webrev/

 Mike




 -- 
 Dmitry Samersoff
 Oracle Java development team, Saint Petersburg, Russia
 * I would love to change the world, but they won't give me the sources.
 common.patch
 


-- 
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: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611)

[Dmitry Samersoff]

Dan,

Sorry, for later answer - was busy trying to run UTE on Mac. I can test
non-darwin logic if you give me a link to workspace.

-Dmitry

On 2013-09-30 17:44, Daniel D. Daugherty wrote:
 On 9/30/13 7:13 AM, Staffan Larsen wrote:
 First: thanks for doing this work - it will make debugging on os x so
 much easier!
 
 That's the plan...
 
 
 I'm not done with the review, but here are a couple of comments so far.

 I tried running with:

 $ sh ./configure --with-debug-level=slowdebug --disable-zip-debug-info
 $ make

 which results in:

 ## Starting hotspot
 ...
 make[5]: *** No rule to make target
 `/Users/staffan/mercurial/hotspot-rt-jdk/build/macosx-x86_64-normal-server-slowdebug/hotspot/dist/jre/lib/amd64/libjsig.dylib.dSYM',
 needed by `generic_export'.  Stop.
 make[4]: *** [export_debug] Error 2
 make[3]: *** [all_debug_universal] Error 2
 make[2]: *** [universal_debug] Error 2
 ...
 
 I'm presuming that you're trying with a forest that includes
 closed repos. If so, then you'll need the jdk/make/closed change
 in order for the build to work.
 
 
 Another comment: There are some makefile logic for BSD, non-darwin
 platforms. Have you had a chance to test this logic?
 (hotspot/make/bsd/makefiles/vm.make)
 
 No, I don't have access to a BSD (non-darwin) platform. However, I'll
 be pinging Dmitri Samersoff to ask a few questions...
 
 
 Nit: hotspot/make/bsd/makefiles/vm.make: L345, L356: wrong indentation.
 
 These are make cmd lines:
 
  344   else
  345 $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJVM_DEBUGINFO)
  346 $(QUIETLY) $(OBJCOPY)
 --add-gnu-debuglink=$(LIBJVM_DEBUGINFO) $@
  347 ifeq ($(STRIP_POLICY),all_strip)
 
 so they have to be indented by a tab. Very ugly, but necessary.
 
 Dan
 
 


 /Staffan



 On 21 sep 2013, at 05:36, Daniel D. Daugherty
 daniel.daughe...@oracle.com wrote:

 Greetings,

 I have the initial support for Full Debug Symbols (FDS) on MacOS X done
 and ready for review:

 7165611 implement Full Debug Symbols on MacOS X hotspot
 https://bugs.openjdk.java.net/browse/JDK-7165611

 Here is the JDK8/HSX-25 webrev URL:

 OpenJDK:
 http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/
 Internal:
 http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/

 This webrev includes changes for the follow repos:

 jdk8
 jdk8/hotspot
 jdk8/jdk
 jdk8/jdk/make/closed

 Once these changes are approved, I'm planning to push them to
 RT_Baseline. From there, they can follow the normal path to
 Main_Baseline and eventually JDK8.

 This work enables FDS on MacOS X for the 'hotspot' repo; the changes in
 the other repos are necessary to support importing the .diz files from
 the MacOS X 'hotspot' build into the forest build. I also fixed a few
 FDS related errors in the magic incantations for the new build. This is
 mostly a port from Linux - MacOS X/BSD with the dtrace changes ported
 from Solaris. In other words, this is Frankenstein's monster...

 Thanks to Staffan Larsen for providing an initial set of changes
 which I morphed into what you see here.

 Testing:
 - JPRT HSX build and test on all platforms; verification of .diz
   files in the MacOS X JPRT bundles
 - JPRT JDK8 forest build and test on all platforms; verification of
   .diz files in the MacOS X JPRT bundles
   Note: In previous FDS changesets, I also did a standalone 'jdk'
   repo build and test, but that no longer seems to work.

 As always, comments, questions and suggestions are welcome.

 Dan
 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

Building agent cli (hsdb) with new build system

[Dmitry Samersoff]

Hi Everyone,

How I can have hsdb built with new build system?

Currently I'm building sa-jdi part of hsdb together with res of JDK,
than I have to go hotspot/agent/make, set all ALT_* variables and type
make here.

Is there a better way?

-Dmitry

-- 
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: Building agent cli (hsdb) with new build system

[Dmitry Samersoff]

Staffan,

For instance, CLHSDB not able to initialize js engine.

Exception in thread main java.lang.RuntimeException: can't load
JavaScript engine
at
sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.init(JSJavaScriptEngine.java:447)
at
sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.init(JSJavaScriptEngine.java:464)
at
sun.jvm.hotspot.CommandProcessor$51.init(CommandProcessor.java:1709)
at
sun.jvm.hotspot.CommandProcessor.postAttach(CommandProcessor.java:1709)
at
sun.jvm.hotspot.CommandProcessor.init(CommandProcessor.java:1780)
at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:98)
at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)

-Dmitry

On 2013-09-16 13:46, Staffan Larsen wrote:
 What more than sa-jdi.jar and libsaproc do you need? Both of those are built 
 with normal hotspot or jdk builds.
 
 /Staffan
 
 On 16 sep 2013, at 11:06, Dmitry Samersoff dmitry.samers...@oracle.com 
 wrote:
 
 Hi Everyone,

 How I can have hsdb built with new build system?

 Currently I'm building sa-jdi part of hsdb together with res of JDK,
 than I have to go hotspot/agent/make, set all ALT_* variables and type
 make here.

 Is there a better way?

 -Dmitry

 -- 
 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: Building agent cli (hsdb) with new build system

[Dmitry Samersoff]

Staffan,

Thank you! I finally get it working.

-Dmitry


On 2013-09-16 15:59, Staffan Larsen wrote:
 The solution (unless you want to build images) is to include the 
 nashorn/classes directory on the classpath:
 
 $ make nashorn
 $ build/macosx-x86_64-normal-server-release/jdk/bin/java -cp 
 build/macosx-x86_64-normal-server-release/jdk/lib/sa-jdi.jar:build/macosx-x86_64-normal-server-release/nashorn/classes
  sun.jvm.hotspot.CLHSDB
 
 
 /Staffan
 
 On 16 sep 2013, at 13:38, Staffan Larsen staffan.lar...@oracle.com wrote:
 
 I see. It looks like the nashorn engine hasn't been registered. If you build 
 make images and run from the build/.../j2sdk-images directory it will 
 work. There probably is a way to specify a javascript engine on the command 
 line, but I don't know how.

 /Staffan

 On 16 sep 2013, at 12:24, Dmitry Samersoff dmitry.samers...@oracle.com 
 wrote:

 Staffan,

 For instance, CLHSDB not able to initialize js engine.

 Exception in thread main java.lang.RuntimeException: can't load
 JavaScript engine
   at
 sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.init(JSJavaScriptEngine.java:447)
   at
 sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.init(JSJavaScriptEngine.java:464)
   at
 sun.jvm.hotspot.CommandProcessor$51.init(CommandProcessor.java:1709)
   at
 sun.jvm.hotspot.CommandProcessor.postAttach(CommandProcessor.java:1709)
   at
 sun.jvm.hotspot.CommandProcessor.init(CommandProcessor.java:1780)
   at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:98)
   at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)

 -Dmitry

 On 2013-09-16 13:46, Staffan Larsen wrote:
 What more than sa-jdi.jar and libsaproc do you need? Both of those are 
 built with normal hotspot or jdk builds.

 /Staffan

 On 16 sep 2013, at 11:06, Dmitry Samersoff dmitry.samers...@oracle.com 
 wrote:

 Hi Everyone,

 How I can have hsdb built with new build system?

 Currently I'm building sa-jdi part of hsdb together with res of JDK,
 than I have to go hotspot/agent/make, set all ALT_* variables and type
 make here.

 Is there a better way?

 -Dmitry

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

 


-- 
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: RR(XS): JDK-8022617 Openjdk hotspot build is broken on BSD platforms using gcc

[Dmitry Samersoff]

Erik,

Could I consider this as a review?

-Dmitry

On 2013-08-29 16:02, Erik Joelsson wrote:
 I think it fails when building with configure as AS will only get that
 value when SPEC isn't set.
 
 /Erik
 
 On 2013-08-29 12:49, David Holmes wrote:
 Hi Dmitry,

 This needs to be reviewed by the hotspot group.

 I don't understand your change given we already had:

  AS   = $(CC) -c -x assembler-with-cpp

 Isn't this something that was fixed very recently?

 Your change, as far as I can see, will also add the assembler-with-cpp
 to clang not just gcc.

 ???

 David

 On 29/08/2013 7:09 PM, Dmitry Samersoff wrote:
 David,

 Thank you for the comments.

 Please, take a look to updated webrev:

 http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.03/

 -Dmitry

 On 2013-08-29 04:41, David Holmes wrote:
 Dmitry,

 I don't think this is something that should be handled at the configure
 level. Hotspot compiler flags are handled in the hotspot makefiles.
 This
 should be in gcc.make.

 BTW your changeset should include the generated-configure.sh file not
 configure. And you would also need to regenerate and push the closed
 generated-configure.sh file.

 David

 On 28/08/2013 11:50 PM, Dmitry Samersoff wrote:
 Hi Everyone,

 Please review small fix

 webrev:

 http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.02/

 CR:

 http://bugs.sun.com/view_bug.do?bug_id=8022617


 Gory details:

 bsd_x86_64.s use macro to deal with OS X specific things.

 llvm-gcc preprocess .s and .S files and doesn't support .sx extension
 recommended by GNU for case insensitive filesystem.

 Other operating systems doesn't preprocess .s files, so 
 bsd_x86_64.s
 couldn't be compiled on other bsd systems.

  This patch enforce of preprocessing of all assembly sources by
 command line options (-x assembler-with-cpp).

 -Dmitry





-- 
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: RR(XS): JDK-8022617 Openjdk hotspot build is broken on BSD platforms using gcc

[Dmitry Samersoff]

Erik,

Thank you!
-Dmitry

On 2013-09-11 15:48, Erik Joelsson wrote:
 Hello,
 
 I think the last webrev looks like the correct fix, so for what it's
 worth it's OK by me, but I'm not a reviewer for hotspot.
 http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.03/
 http://cr.openjdk.java.net/%7Edsamersoff/JDK-8022617/webrev.03/
 
 /Erik
 
 On 2013-09-11 13:02, Dmitry Samersoff wrote:
 Erik,

 Could I consider this as a review?

 -Dmitry

 On 2013-08-29 16:02, Erik Joelsson wrote:
 I think it fails when building with configure as AS will only get that
 value when SPEC isn't set.

 /Erik

 On 2013-08-29 12:49, David Holmes wrote:
 Hi Dmitry,

 This needs to be reviewed by the hotspot group.

 I don't understand your change given we already had:

  AS   = $(CC) -c -x assembler-with-cpp

 Isn't this something that was fixed very recently?

 Your change, as far as I can see, will also add the assembler-with-cpp
 to clang not just gcc.

 ???

 David

 On 29/08/2013 7:09 PM, Dmitry Samersoff wrote:
 David,

 Thank you for the comments.

 Please, take a look to updated webrev:

 http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.03/

 -Dmitry

 On 2013-08-29 04:41, David Holmes wrote:
 Dmitry,

 I don't think this is something that should be handled at the configure
 level. Hotspot compiler flags are handled in the hotspot makefiles.
 This
 should be in gcc.make.

 BTW your changeset should include the generated-configure.sh file not
 configure. And you would also need to regenerate and push the closed
 generated-configure.sh file.

 David

 On 28/08/2013 11:50 PM, Dmitry Samersoff wrote:
 Hi Everyone,

 Please review small fix

 webrev:

 http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.02/

 CR:

 http://bugs.sun.com/view_bug.do?bug_id=8022617


 Gory details:

 bsd_x86_64.s use macro to deal with OS X specific things.

 llvm-gcc preprocess .s and .S files and doesn't support .sx extension
 recommended by GNU for case insensitive filesystem.

 Other operating systems doesn't preprocess .s files, so 
 bsd_x86_64.s
 couldn't be compiled on other bsd systems.

  This patch enforce of preprocessing of all assembly sources by
 command line options (-x assembler-with-cpp).

 -Dmitry



 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

hgforest.sh still fails to detect Python

[Dmitry Samersoff]

Mike,

hgforest still doesn't detect python because on my linux laptop hg
headline is

#!/usr/bin/env python

I'd attached the patch I use (regenerated against latest tl with 8024200
changes)

-Dmitry

On 2013-09-03 23:43, Mike Duigou wrote:
 Hello all;
 
 This is a very small change to trim optional whitespace off of the 
 interpreter directive which may appear in the hg wrapper script. The 
 whitespace is legal per https://en.wikipedia.org/wiki/Shebang_%28Unix%29 and 
 is now included in some distributions of mercurial (Ubuntu 13.04).
 
 http://cr.openjdk.java.net/~mduigou/JDK-8024200/0/webrev/
 
 Mike
 
 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
diff -r 73355c4c1bc8 common/bin/hgforest.sh
--- a/common/bin/hgforest.shFri Sep 06 14:15:02 2013 -0700
+++ b/common/bin/hgforest.shWed Sep 11 17:50:57 2013 +0400
@@ -42,17 +42,13 @@
   exit 1
 fi
 
-has_hash_bang=`head -n 1 ${whichhg} | cut -b 1-2`
-python=
-bpython=
+hpython=`sed -n -e '1 s,^[^/]*/,/,p' ${whichhg}`
+python=`$hpython -c import sys; print(sys.executable)` 
+hg=${python} -u ${whichhg}
 
-if [ #! = $has_hash_bang ] ; then
-   python=`head -n 1 ${whichhg} | cut -b 3- | sed -e 's/^[ \t]*//;s/[ 
\t]*$//'`
-   bpython=`basename $python`
-fi
-
-if [ -x $python -a ! -d $python -a `${python} -V 21 | cut -f 1 -d ' '` 
= Python ] ; then
-  hg=${python} -u ${whichhg}
+if ${hg} version | grep -q Mercurial
+then
+  echo Using: ${hg}
 else
   echo Cannot find python from hg launcher. Running plain hg, which probably 
has buffered stdout.
   hg=hg

Re: hgforest.sh still fails to detect Python

[Dmitry Samersoff]

Mike,

I'm using Gentoo Linux, definitely not one of supported.


Nevertheless,

#!/usr/bin/env python

is a very common because it's the output of standard python wrapper
generation utility.

So, I think that ask python to print path to it self

hpython=`sed -n -e '1 s,^[^/]*/,/,p' ${whichhg}`
python=`$hpython -c import sys; print(sys.executable)`

is more reliable and require less code than attempt to guess right
interpreter parsing first line of hg wrapper and output of python -V than.

-Dmitry



On 2013-09-11 23:42, Mike Duigou wrote:
 Sorry I haven't had a chance to look at this. What Linux did you encounter 
 this on? Did it recently change?
 
 Mike
 On Sep 11 2013, at 06:48 , Dmitry Samersoff wrote:
 
 Mike,

 hgforest still doesn't detect python because on my linux laptop hg
 headline is

 #!/usr/bin/env python

 I'd attached the patch I use (regenerated against latest tl with 8024200
 changes)

 -Dmitry

 On 2013-09-03 23:43, Mike Duigou wrote:
 Hello all;

 This is a very small change to trim optional whitespace off of the 
 interpreter directive which may appear in the hg wrapper script. The 
 whitespace is legal per https://en.wikipedia.org/wiki/Shebang_%28Unix%29 
 and is now included in some distributions of mercurial (Ubuntu 13.04).

 http://cr.openjdk.java.net/~mduigou/JDK-8024200/0/webrev/

 Mike




 -- 
 Dmitry Samersoff
 Oracle Java development team, Saint Petersburg, Russia
 * I would love to change the world, but they won't give me the sources.
 common.patch
 


-- 
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: Add s390(x) detection to platform.m4

[Dmitry Samersoff]

Omair,

I'm OK with latest webrev.

-Dmitry

On 2013-09-09 21:34, Omair Majid wrote:
 Hi,
 
 On 09/05/2013 05:43 AM, Dmitry Samersoff wrote:
 It might make sense to set

  VAR_CPU to ESA_390

  VAR_CPU_ARCH to ESA_390 or ever to ESA_3xx

 for both s390 and s390x.

 s370 diverged over time to a variety of more or less compatible series
 and it's possible the same happens (if not already happened) with s390.
 
 I am far from an expert on the contents of VAR_CPU and VAR_CPU_ARCH, but
 it looks like the existing entries are roughly along the lines of the
 arch from the gnu arch triplet. So a name like ESA_390 would look out of
 place when compared to names like sparcv9, sparc and x86_64.
 
 If you still think it's a good idea, I can make the change.
 
 Thanks,
 Omair
 


-- 
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: Add s390(x) detection to platform.m4

[Dmitry Samersoff]

Omair,

It might make sense to set

 VAR_CPU to ESA_390

 VAR_CPU_ARCH to ESA_390 or ever to ESA_3xx

for both s390 and s390x.

s370 diverged over time to a variety of more or less compatible series
and it's possible the same happens (if not already happened) with s390.

-Dmitry

On 2013-09-04 23:26, Omair Majid wrote:
 Hi,
 
 Over in Fedora-land, we are trying to build OpenJDK (using zero) on
 s390(x) [1]. One of the changes needed is updating the platform.m4 file
 to teach it about s390(x). The following webrev does that:
 http://cr.openjdk.java.net/~omajid/webrevs/s390-platform/00/
 
 The patch was written by Dan Horák d...@danny.cz (who works for Red Hat
 and is covered by the CLA).
 
 Thanks,
 Omair
 


-- 
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-8024200 : (xxs) hgforest.sh fails to detect Python correctly if space after shebang

[Dmitry Samersoff]

Mike,

This script probably will not work if first line of hg is

/usr/bin/env python

I would suggest just to ask python to print path to it self.

hpython=`sed -n -e '1 s,^[^/]*/,/,p' ${whichhg}`
python=`$hpython -c import sys; print(sys.executable)`

or at least check for env:

epython=
`sed -n -e '1 s,^[^/]*/\(\([^/]\+/\)\+[^ \t]\+\).*$,/\1,p' ${whichhg}`

bpython=`basename $epython`

if [ ${bpython} = env ]
then
 ...
fi

-Dmitry




On 2013-09-03 23:43, Mike Duigou wrote:
 Hello all;
 
 This is a very small change to trim optional whitespace off of the 
 interpreter directive which may appear in the hg wrapper script. The 
 whitespace is legal per https://en.wikipedia.org/wiki/Shebang_%28Unix%29 and 
 is now included in some distributions of mercurial (Ubuntu 13.04).
 
 http://cr.openjdk.java.net/~mduigou/JDK-8024200/0/webrev/
 
 Mike
 
 


-- 
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: RR(XS): JDK-8022617 Openjdk hotspot build is broken on BSD platforms using gcc

[Dmitry Samersoff]

David,

Thank you for the comments.

Please, take a look to updated webrev:

http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.03/

-Dmitry

On 2013-08-29 04:41, David Holmes wrote:
 Dmitry,
 
 I don't think this is something that should be handled at the configure
 level. Hotspot compiler flags are handled in the hotspot makefiles. This
 should be in gcc.make.
 
 BTW your changeset should include the generated-configure.sh file not
 configure. And you would also need to regenerate and push the closed
 generated-configure.sh file.
 
 David
 
 On 28/08/2013 11:50 PM, Dmitry Samersoff wrote:
 Hi Everyone,

 Please review small fix

 webrev:

 http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.02/

 CR:

 http://bugs.sun.com/view_bug.do?bug_id=8022617


 Gory details:

bsd_x86_64.s use macro to deal with OS X specific things.

 llvm-gcc preprocess .s and .S files and doesn't support .sx extension
 recommended by GNU for case insensitive filesystem.

Other operating systems doesn't preprocess .s files, so  bsd_x86_64.s
 couldn't be compiled on other bsd systems.

 This patch enforce of preprocessing of all assembly sources by
 command line options (-x assembler-with-cpp).

 -Dmitry



-- 
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: RR(XS): JDK-8022617 Openjdk hotspot build is broken on BSD platforms using gcc

[Dmitry Samersoff]

David,

On 2013-08-29 14:49, David Holmes wrote:

 This needs to be reviewed by the hotspot group.

Added to CC

 
 I don't understand your change given we already had:
 
  AS   = $(CC) -c -x assembler-with-cpp

It's guarded by:

 # If a SPEC is not set already, then use these defaults.
 ifeq ($(SPEC),)

as configure sets SPEC, this line is ignored.

 Isn't this something that was fixed very recently?
 
 Your change, as far as I can see, will also add the assembler-with-cpp
 to clang not just gcc.

It's intentional, according to my experiments clang supports this option
as well.

-Dmitry

 
 ???
 
 David
 
 On 29/08/2013 7:09 PM, Dmitry Samersoff wrote:
 David,

 Thank you for the comments.

 Please, take a look to updated webrev:

 http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.03/

 -Dmitry

 On 2013-08-29 04:41, David Holmes wrote:
 Dmitry,

 I don't think this is something that should be handled at the configure
 level. Hotspot compiler flags are handled in the hotspot makefiles. This
 should be in gcc.make.

 BTW your changeset should include the generated-configure.sh file not
 configure. And you would also need to regenerate and push the closed
 generated-configure.sh file.

 David

 On 28/08/2013 11:50 PM, Dmitry Samersoff wrote:
 Hi Everyone,

 Please review small fix

 webrev:

 http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.02/

 CR:

 http://bugs.sun.com/view_bug.do?bug_id=8022617


 Gory details:

 bsd_x86_64.s use macro to deal with OS X specific things.

 llvm-gcc preprocess .s and .S files and doesn't support .sx extension
 recommended by GNU for case insensitive filesystem.

 Other operating systems doesn't preprocess .s files, so 
 bsd_x86_64.s
 couldn't be compiled on other bsd systems.

  This patch enforce of preprocessing of all assembly sources by
 command line options (-x assembler-with-cpp).

 -Dmitry





-- 
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: 8023957: Lock down version of autoconf

[Dmitry Samersoff]

Looks good for me (not a reviewer).

On 2013-08-29 17:43, Erik Joelsson wrote:
 Following the discussion about the autoconf version, here is a patch
 that changes the AC_PREREQ macro to require at least 2.69. For now,
 since there are no newer versions, this will make us require version
 2.69. I also removed the workaround for getting 2.67 that was put into
 autogen.sh.
 
 http://cr.openjdk.java.net/~erikj/8023957/webrev.root.01/
 
 /Erik


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

RR(XS): JDK-8022617 Openjdk hotspot build is broken on BSD platforms using gcc

[Dmitry Samersoff]

Hi Everyone,

Please review small fix

webrev:

http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.02/

CR:

http://bugs.sun.com/view_bug.do?bug_id=8022617


Gory details:

  bsd_x86_64.s use macro to deal with OS X specific things.

llvm-gcc preprocess .s and .S files and doesn't support .sx extension
recommended by GNU for case insensitive filesystem.

  Other operating systems doesn't preprocess .s files, so  bsd_x86_64.s
couldn't be compiled on other bsd systems.

   This patch enforce of preprocessing of all assembly sources by
command line options (-x assembler-with-cpp).

-Dmitry

-- 
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: jdk8 build times

[Dmitry Samersoff]

Pete,

One of ways to get rid of antivirus is to install VirtualBox, another
copy of windows into VirtualBox and do all unsafe internet access from
within this box.


-Dmitry


On 2013-08-09 18:44, Pete Brunet wrote:
 My product is Norton 360.  To turn it off I right click on the Norton
 360 icon in the system tray and choose Disable Antivirus Auto-Protect. 
 If anyone knows if this is not sufficient and what else needs to be done
 please let me know. 
 
 Pete
 
 On 8/9/13 1:58 AM, Erik Joelsson wrote:
 I wonder if anti virus is really turned off here. In my experience,
 it's hard to make it stop completely. I have a slightly older laptop,
 same brand, that builds this in around 40-45 minutes.

 /Erik

 On 2013-08-09 03:32, Pete Brunet wrote:
 Haven't rebuilt a release version yet for a true comparison but here are
 my fastdebug times with anti-virus turned off; about the same as release
 with anti-virus on.

 00:04:30 corba
 00:07:25 demos
 00:16:28 docs
 00:16:15 hotspot
 00:23:13 images
 00:04:18 jaxp
 00:07:29 jaxws
 00:59:41 jdk
 00:05:11 langtools
 00:01:42 nashorn
 02:26:32 TOTAL

 Pete

 On 8/6/13 12:55 PM, Kelly O'Hair wrote:
 4. Using a debug jdk as your boot jdk

 :)

 Langtools taking 6 minutes is crazy long. Since there is no native
 code there, #1 would be my first guess.

 -kto

 On Aug 5, 2013, at 5:54 PM, Weijun Wang wrote:

  From my experiences there are 3 reasons a compile could be slow:

 1. Anti-Virus programs
 2. Virtual Machines
 3. Network folders

 --Max

 On 8/6/13 12:48 AM, Pete Brunet wrote:
 Hi Erik,

 00:05:55 corba
 00:09:46 demos
 00:15:00 docs
 00:18:37 hotspot
 00:17:13 images
 00:03:32 jaxp
 00:11:41 jaxws
 01:05:35 jdk
 00:06:47 langtools
 00:02:26 nashorn
 02:37:45 TOTAL

 Pete

 On 8/5/13 6:55 AM, Erik Joelsson wrote:
 That was disappointingly slow for sure. Do you have the build time
 summary listing?

 /Erik

 On 2013-08-02 22:26, Pete Brunet wrote:
 FWIW I just built 32 bit jdk8 release on 64 bit win 7 with
 cygwin 1.7.21
 on a dual core 8 GB 2.53 GHz Lenovo T500 and the build time was
 2:37:45.
 


-- 
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: Consistent autoconf version

[Dmitry Samersoff]

Martin,

Common practice is to have generated configure.sh in source bundle, but
don't have it in source control.

I would prefer to have the same with JDK, but not sure whether it ever
possible.

-Dmitry

On 2013-08-26 20:34, Martin Buchholz wrote:
 It's traditional to ship the generated configure, although some projects
 have waffled and only ship configure in their release tarballs.  If you
 don't ship configure, you are forcing everyone to install yet more build
 tools, and you introduce bugs based on the autoconf version of the builder.
  I recommend including configure in the SCM, standardizing the version of
 autoconf used to generate configure and enforcing that somehow.
 
 
 On Mon, Aug 26, 2013 at 9:06 AM, David DeHaven 
 david.deha...@oracle.comwrote:
 

 Hi,

 Sorry if this has come up before, but I cannot find anything in the
 archives.

 Is it possible to agree an autoconf version to use to generate the
 checked in generated-configure.sh?

 I recently had to merge, and regenerate this file, and found versions
 that were generated with 2.67, 2.68, and 2.69. Using such different
 versions makes it nearly impossible to see the relevant diffs in
 generated-configure.sh. While using the same version greatly, but not
 completely, simplifies the number of changes.

 Is there any reason why not to agree a specific version?

 My understanding was it is difficult to use a non-standard version on
 some (most?) platforms. Most people would probably balk at having to use
 any version other than that installed by default on their system.
 Alternatively, if we want a specific version we could mandate that the
 checked in generated-configure.sh be pushed by a project owner with access
 to the official version. To my knowledge there's only been one buggy (due
 to buggy autoconf which generated it) generated-configure.sh been checked
 in. The diffs are annoying but in theory you're not really supposed to read
 generated-configure.sh, instead you should be reviewing the autoconf inputs
 which generate it.

 If autoconf is a prerequisite for building, why not just leave
 generated-configure.sh as a generated file rather than in SCM? I understand
 it lengthens the build time a bit, but unless you're tweaking the build
 system you only need to run configure sparingly.

 -DrD-




-- 
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): 8022071 Some vm/jvmti tests fail because cannot attach to the Java virtual machine

[Dmitry Samersoff]

Staffan,

It might be better to just use inline assembler to record start and end
of the routine, as nobody guarantee that thread_end is not optimized out
or some function is not inserted in between thread_func and thread_end.

Something like below should work:

First line of thread_func:

_asm(
   jmp End_Of_Func_Label
)

and, when necessary, read opcode at thread_func (E9 or EB) and extract
imm that comes afterward.

-Dmitry



On 2013-08-16 20:51, Staffan Larsen wrote:
 This failure happens when compiling with the VS 2012 compiler. The attach 
 code relies on the order of two methods in the compiled binary and VS 2012 
 changed that order. The solution used is the linker flag /ORDER [1] which 
 allows us to specify the order in which methods are laid out in the binary 
 image. Since the flag only operates on non-static methods, the methods have 
 been made non-static and also changed name so that they will not clash with 
 other methods.
 
 webrev: http://cr.openjdk.java.net/~sla/8022071/webrev.01/
 
 The change has been tested with both VS 2010 and VS 2012.
 
 Thanks,
 /Staffan
 
 
 [1] http://msdn.microsoft.com/en-us/library/vstudio/00kh39zz.aspx
 


-- 
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: jdk8 build times

[Dmitry Samersoff]

Peter,

1. When you turn norton off it's actually still hook all opens, so
   significantly slow down things.

   Try to create exclusion rule to exclude your build directory from
   protection.

2. Make sure you have SATA controller in AHCI but not legacy mode in a
   BIOS, (make sure you have AHCI driver installed)

3. T500 should be SATA-III

4. T* series has an option to install extra disk to bay instead of DVD,
   adapter cost about $5 on e-bay, so you can try a new disk without
   destroying whole system.

-Dmitry


On 2013-08-09 20:25, Pete Brunet wrote:
 Any suggestions for SSDs?  My T500 takes 2.5 SATA II.
 
 On 8/9/13 10:44 AM, Andreas Rieber wrote:
 Hi Peter,

 try perfmon.exe to see where the bottleneck is. Most likely it is
 memory or io. If you have the option, go for a SSD drive (you will get
 build times ~10 minutes).

 Andreas


 On 09.08.13 16:44, Pete Brunet wrote:
 My product is Norton 360.  To turn it off I right click on the Norton
 360 icon in the system tray and choose Disable Antivirus Auto-Protect.
 If anyone knows if this is not sufficient and what else needs to be done
 please let me know.

 Pete

 On 8/9/13 1:58 AM, Erik Joelsson wrote:
 I wonder if anti virus is really turned off here. In my experience,
 it's hard to make it stop completely. I have a slightly older laptop,
 same brand, that builds this in around 40-45 minutes.

 /Erik

 On 2013-08-09 03:32, Pete Brunet wrote:
 Haven't rebuilt a release version yet for a true comparison but
 here are
 my fastdebug times with anti-virus turned off; about the same as
 release
 with anti-virus on.

 00:04:30 corba
 00:07:25 demos
 00:16:28 docs
 00:16:15 hotspot
 00:23:13 images
 00:04:18 jaxp
 00:07:29 jaxws
 00:59:41 jdk
 00:05:11 langtools
 00:01:42 nashorn
 02:26:32 TOTAL

 Pete

 On 8/6/13 12:55 PM, Kelly O'Hair wrote:
 4. Using a debug jdk as your boot jdk

 :)

 Langtools taking 6 minutes is crazy long. Since there is no native
 code there, #1 would be my first guess.

 -kto

 On Aug 5, 2013, at 5:54 PM, Weijun Wang wrote:

   From my experiences there are 3 reasons a compile could be slow:

 1. Anti-Virus programs
 2. Virtual Machines
 3. Network folders

 --Max

 On 8/6/13 12:48 AM, Pete Brunet wrote:
 Hi Erik,

 00:05:55 corba
 00:09:46 demos
 00:15:00 docs
 00:18:37 hotspot
 00:17:13 images
 00:03:32 jaxp
 00:11:41 jaxws
 01:05:35 jdk
 00:06:47 langtools
 00:02:26 nashorn
 02:37:45 TOTAL

 Pete

 On 8/5/13 6:55 AM, Erik Joelsson wrote:
 That was disappointingly slow for sure. Do you have the build time
 summary listing?

 /Erik

 On 2013-08-02 22:26, Pete Brunet wrote:
 FWIW I just built 32 bit jdk8 release on 64 bit win 7 with
 cygwin 1.7.21
 on a dual core 8 GB 2.53 GHz Lenovo T500 and the build time was
 2:37:45.


 


-- 
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: Assembler error on FreeBSD 9.1, toolchain problem?

[Dmitry Samersoff]

Henry,

It's a known error so I closed your CR as a duplicate of existing one.

-Dmitry


On 2013-08-09 23:51, Henry Jen wrote:
 On 08/09/2013 12:32 PM, Mike Duigou wrote:

 On Aug 8 2013, at 22:57 , David Holmes wrote:

 On 9/08/2013 3:31 PM, Henry Jen wrote:
 man gcc on mac,

file.s
Assembler code.  Apple's version of GCC runs the preprocessor 
 on these files as well as those ending in .S.

file.S
Assembler code which must be preprocessed.

 Is this just a consequence of most MacOS filesystems being case insensitive?

 
 I believe that's the reason.
 
 Anyway, I hit another snag on FreeBSD, bug JDK-8022737 created.
 
 Cheers,
 Henry
 


-- 
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: Assembler error on FreeBSD 9.1, toolchain problem?

[Dmitry Samersoff]

]: *** [product] Error 2
 gmake[1]: ***
 [/home/henryjen/ws/lambda/build/bsd-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
 Error 2




-- 
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: Assembler error on FreeBSD 9.1, toolchain problem?

[Dmitry Samersoff]

David,

On 2013-08-08 16:17, David Holmes wrote:
 Trimmed cc list
 
 On 8/08/2013 9:07 PM, Andrew Haley wrote:
 On 08/08/2013 11:52 AM, Dmitry Samersoff wrote:
 For some unknown for me reason, macros in bsd_x86_64.s is not processed.
 (Makefile issue???)

 It should be called bsd_x86_64.S if this is using GCC.
 
 So gcc (llvm-gcc?) on OSX doesn't require this?

Unfortunately, I'm not a OSX user so can't answer.

-Dmitry

-- 
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: autoconf problem

[Dmitry Samersoff]

Michael,

Try to get fresh workspace or at least run
hg pull -u in the root directory.

get_source.sh not always/doesn't update root folder.

-Dmitry

On 2013-07-16 16:20, Michael McMahon wrote:
 Hi,
 
 Since my latest sync of jdk8/cpu (today) I can't run configure. I get
 the following
 error:
 
 $ bash ./configure
 Warning: The generated configure file contains changes not present in
 the custom generated file.
 Cannot locate autoconf, unable to correct situation.
 Please install autoconf and run 'bash autogen.sh' to update the
 generated files.
 Error: Cannot continue
 mm72272@mm72272-ThinkPad-T420:/export/repos/jdk8-cpu$ bash ./configure
 --help
 Warning: The generated configure file contains changes not present in
 the custom generated file.
 Cannot locate autoconf, unable to correct situation.
 Please install autoconf and run 'bash autogen.sh' to update the
 generated files.
 Error: Cannot continue
 
 Now, I don't have autoconf installed but before I try and continue by
 installing it,
 I'd like to understand more why this is happening. Any ideas?
 
 Thanks!
 Michael
 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.

Re: How to re-run configure?

[Dmitry Samersoff]

David,

On 2013-02-26 22:44, David DeHaven wrote:
 
 config.status does other things too, it's quite handy.

Yes.

 The only problem with it - I typically forget to copy it out
before doing rm -rf build

-Dmitry

 
 -DrD-
 
 Awsome!

 Thanks,
 /Staffan

 On 26 feb 2013, at 16:31, David DeHaven david.deha...@oracle.com wrote:


 build/target dir/config.status --recheck

 -DrD-

 Thanks Dmitry,

 I was looking for a standard way of doing this. While a custom script 
 helps, it would be nice to have the support in the source.

 /Staffan 

 On 26 feb 2013, at 14:53, Dmitry Samersoff dmitry.samers...@oracle.com 
 wrote:

 Staffan,

 1. Keep config.log somewhere
 2. Attached script or something similar will do the trick

 -Dmitry

 On 2013-02-26 13:05, Staffan Larsen wrote:
 Is there a shorthand for re-running configure on one of my
 configurations without having to re-type the configure arguments I
 used when creating the configuration?

 I have a number of configurations and when I have to re-run
 configure, I have to both specify the correct --with-conf-name and
 then the correct configure options I used last time. I know I can
 find those in the configure-arguments file.

 What I would like is something simliar to make CONF=... but for
 configure: sh configure CONF=

 Thanks, /Staffan



 -- 
 Dmitry Samersoff
 Oracle Java development team, Saint Petersburg, Russia
 * Give Rabbit time, and he'll always get the answer
 rr.txt



 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

Re: New build system problems

[Dmitry Samersoff]

Martin,

 257   if test x$OPENJDK_TARGET_OS != xmacosx; then
 258 # Do not probe for cc on MacOSX.
 259 COMPILER_CHECK_LIST=cc $COMPILER_CHECK_LIST
 260   fi
 261   if test x$OPENJDK_TARGET_OS == xwindows; then
 262 COMPILER_CHECK_LIST=cl $COMPILER_CHECK_LIST
 263   fi


1. for windows compiler checklist become:   cl cc gcc

I'm not sure we need to check for cc on windows, also gcc build on
windows is not supported. So It might be better to be more explicit:

 256   COMPILER_CHECK_LIST=cc gcc
   # Overriding COMPILER_CHECK_LIST to set OS specific preferences
 257   if test x$OPENJDK_TARGET_OS = xmacosx; then
 258 # Do not probe for cc on MacOSX.
 259 COMPILER_CHECK_LIST=gcc
 260   fi
 261   if test x$OPENJDK_TARGET_OS = xwindows; then
 262 COMPILER_CHECK_LIST=cl
 263   fi


2. Not all versions of test support == as equation. It's better to use
single one. and I would prefer to have quotes around xmacosx and
xwindows just for consistency. i.e.

if test x$OPENJDK_TARGET_OS = xwindows;

-Dmitry


On 2013-02-24 00:05, Martin Buchholz wrote:
 Hi Erik, Tim, Kelly
 
 Here's a proposed fix for you to review:
 
 http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/
 
 Martin
 
 On Fri, Jan 25, 2013 at 3:51 PM, Martin Buchholz marti...@google.comwrote:
 
 I was trying out the shiny new build system.

 Problem: configure is not executable - must run bash ./configure
 It's traditional for configure scripts to be executable.

 Problem: Your life is hell if you have a non-compiler cl command on your
 PATH, even on Linux.

 checking for cl... /usr/bin/cl
 configure: Resolving CC (as /usr/bin/cl) failed, using /usr/bin/cl
 directly.

 with subsequent failure to compile.

 Even if you specify the compiler explicitly, it doesn't help:

 CC=/usr/bin/gcc CXX=/usr/bin/g++ bash ./configure

 Of course, one can work around this by creating a tools dir, but
 excising the unloved cl from the configure script is tempting and effective.



-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

Re: j2sdk-image and new build system

[Dmitry Samersoff]

David,

May be we can cleanup names in makefiles, but add something
like

  restore_old_names()

doing couple of mv calls to the end of build process.

-Dmitry


On 2013-02-24 03:09, David Holmes wrote:
 On 24/02/2013 4:19 AM, Martin Buchholz wrote:
 On Sat, Feb 23, 2013 at 2:45 AM, Alan Bateman alan.bate...@oracle.com
 mailto:alan.bate...@oracle.com wrote:

 On 23/02/2013 10:29, David Holmes wrote:


 Just be aware there's a lot more involved in doing this than
 just changing one a name in a makefile.

 You beat to me too! Yes, there are likely a lot of scripts and paths
 that assume the image name is j2sdk-image or j2re-image so renaming
 will be a bit disruptive.


 Sure, but you are *already* making a huge disruptive change to build
 directory layout.  People have to change their scripts from
 linux-amd64/j2sdk-image
 to
 linux-x86_64-normal-server-release/images/j2sdk-image
 
 Not quite. You can still have full control of the first directory
 component [1] so for most builds there is no change there at all and no
 disruption.
 
 The additional images directory is also easily accommodated.
 Scripts/processes that copy the images from path-A to path-B just need
 to tweak path-A. But if you rename the actual j2sdk-image etc you have
 to update everything that uses path-B.
 
 Especially the repetition of image seems wrong in the new layout.
 
 The new build tries to have a top-level directory for each major build
 component. Hence images has its own directory.
 
 David
 -
 
 [1] Simplest way is:
 mkdir mydir
 cd mydir
 path-to-configure/configure
 
 
 
 Why not
 images/j2sdk-image
 to
 images/jdk

 If you really want to keep j2sdk-image, move it back into its parent
 directory.

 Also I think the initial goal of the new build system was to get it
 to the point where it generated the same bits as the old build. I
 assume this is why the new build went for the same directory names
 as the old build (and probably because of scripts depending on the
 name too).


 Hopefully the new build system will lead to an increase, not decrease,
 in overall sanity.


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

Re: OpenJDK rebuilding on windows takes a long time

[Dmitry Samersoff]

Ioi,

Approx the same task on 8GB CoreI5 laptop (Gentoo Linux, XFS, SSD
drive), takes about a minute:

real1m14.854s
user1m43.881s
sys 0m6.344s

So the problem may reside in IO speed of the virtual environment.

-Dmitry

On 2013-02-15 06:04, Ioi Lam wrote:
 On 02/14/2013 02:24 AM, Alexander Scherbatiy wrote:
 On 2/13/2013 8:45 PM, Kelly O'Hair wrote:
 You are pointing at the fastdebug jdk as your boot jdk, why?

 The official boot jdk for jdk8 is jdk7u7 we cannot guarantee anything
 else will work, although it should,
 when tracking down issues like this, you need to narrow down all the
 possible differences.

 I have no idea at this time what the 'sync state' is with the awt
 team forest.
 My recommendation would be to clone the official jdk8/jdk8 forest,
 which can be assumed to work since
 RE should have built it, or any integrator pushing changes into it
 should have built it.
 Create 2 forests of so you can do separate experiments on each.
 The question was about time rebuilding JDK after a small change.

What time does it take to rebuild the official  jdk8/jdk8 forest
 with default options after small change in the java file like
 javax.swing.JFrame ?
 
 
 FYI:
 
 I am running on Oracle Enterprise Linux 5.0 with official jdk1.7.0_09 as
 my boot jdk. It's a virtual host with
 Xeon E5-2690 (only 2 cores allocated) and 12 GB RAM. JDK sources is put
 on local disk. A one-liner change in URLClassLoader.java takes about 4
 minutes. I didn't specify sjavac when running configure.
 
 - Build times ---
 Start 2013-02-14 12:12:14
 End   2013-02-14 12:16:13
 00:00:00 corba
 00:00:01 demos
 00:00:12 hotspot
 00:00:23 images
 00:00:00 jaxp
 00:00:00 jaxws
 00:03:23 jdk
 00:00:00 langtools
 00:03:59 TOTAL
 -
 Finished building Java(TM) for target 'images'
 
 Is there an option in the makefiles to compile ONLY the .java file
 that's changed (assuming I know the changes won't affect other classes)?
 
 - Ioi
 
Is sjavac are enabled by default now in the  official  jdk8/jdk8? 
 If no,  what time does it take to rebuild the JDK with the
 --enable-sjavac option?

Thanks,
Alexandr.

 Then do the build from the root with a 7u7 jdk in your PATH (no need
 for the --with-boot-jdk option).
 Do a build without --enable-sjavac on one forest, then with it on the
 other.

 -kto

 On Feb 13, 2013, at 3:38 AM, Alexander Scherbatiy wrote:

 On 2/11/2013 4:03 PM, Erik Joelsson wrote:
 The long term solution to this is sjavac. I do not know if it has
 made it into that forest yet. You can try by adding --enable-sjavac
 to configure and do a clean build. If the build works, you have it,
 and incremental builds will be much faster.
I tried to use the --enable-sjavac option and JDK 7 and 8 as a
 boot JDK.
 --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk7/7u14/b10/jdk1.7.0_14/fastdebug
 --with-target-bits=32 --enable-sjavac
gives compilation error

 --with-boot-jdk=/cygdrive/c/Sun/Tools/JDK/jdk8/b75/jdk1.8.0/fastdebug 
 --with-target-bits=32
 --enable-sjavac
   gives OutOfMemoryError: Java heap space error.

The log files are attached.

Thanks,
Alexandr.

 /Erik

 On 2013-02-11 12:22, Alexander Scherbatiy wrote:
 On 2/8/2013 6:46 PM, Erik Joelsson wrote:
 Ccache is not supported on windows since it doesn't work with
 visual studio AFAIK.

 What kind of change did you do? Was it in native code or java and
 in which repository?
   I use the http://hg.openjdk.java.net/jdk8/awt repository, edit
 java code and build the jdk.
 To reproduce the issue:
   - open the javax.swing.JFrame class and add a comment line:
 // a comment
   - build jdk

 - Build times ---
 Start 2013-02-11 15:09:55
 End   2013-02-11 15:17:08
 00:00:03 corba
 00:00:02 hotspot
 00:00:01 jaxp
 00:00:03 jaxws
 00:06:54 jdk
 00:00:02 langtools
 00:07:13 TOTAL
 -

 My environment:
   OS: Windows 7 Professional, x64
   Processor - Intel Core i7
   Memory - 8 GB

 The log file is attached.

 Thanks,
 Alexandr.
 /Erik


 jdk7_log.txtjkd8_log.txt

 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

Re: Review request: 8006933: Need to use nawk on Solaris to avoid awk limitations

[Dmitry Samersoff]

Looks good for me.

-Dmitry

On 2013-01-30 21:39, Tim Bell wrote:
 Second round of this change:
 
 http://cr.openjdk.java.net/~tbell/8006933/01/
 
 In response to feedback raised on this thread:
 
 David wrote:
 
 Do we fix the old build in the corba repo too?
 
 No, the old build does not generate accurate dependencies in this area,
 so there is nothing similar to fix - the old corba build is all or nothing.
 
 Can we also fix the fact that the failure doesn't cause make to detect
 the error? I think that is caused by the whole thing being executed in a
 sub-shell.
 
 I tried without success (many ways) to trap the error from the original
 /usr/bin/awk.  Given that we are using nawk after this change, I'd like
 to move on.
 
 Dmitry wrote:
 
 It might be better to remove AWK completely

 $(FIND) . -type f | sed 's!\./!$3 : $4/!g'  $5
 
 Good idea, but I was not able to implement it because sed does not
 support captures, and the expression suggested above would drop part of
 the string.
 
 Let me give an example:
 
 If the output of the find is ./org/omg/CORBA/StringSeqHolder.java
 
 $3 is /tmp/jdk8/build/solaris-x86-normal-server-release/corba/gensrc/
 
 $4 is
 /tmp/jdk8/corba/src/share/classes/org/omg/PortableInterceptor/CORBAX.idl
 
 $(SED) 's!\./!$3 : $4/!g' would generate:
 
 /tmp/jdk8/build/solaris-x86-normal-server-release/corba/gensrc/ :
 /tmp/jdk8/corba/src/share/classes/org/omg/PortableInterceptor/CORBAX.idl
 
 (losing the /org/omg/CORBA/StringSeqHolder.java substring)
 
 $(SED) 's!\./!$3/!g' | $(NAWK) '{ print 1 : $4 }' would generate
 what we want:
 
 /tmp/jdk8/build/solaris-x86-normal-server-release/corba/gensrc/org/omg/CORBA/StringSeqHolder.java:
 /tmp/jdk8/corba/src/share/classes/org/omg/PortableInterceptor/CORBAX.idl
 
 
 (and you can see why the length of the strings becomes a problem for the
 old Solaris awk which predates the Posix standard)
 
 
 or ever

 find . -type f -printf $3%s : $4\n
 
 Another good suggestion, but not all versions of find support printf
 (MacOS,  and /usr/bin/find on Solaris).  It would be possible to use
 /usr/bin/gfind on Solaris, but I don't know of a solution on the Mac.
 
 
 Tim
 
 On 01/28/13 02:42, Erik Joelsson wrote:
 The fix looks good to me. What strikes me most is the use of sed
 instead of $(SED) on the same line.

 /Erik

 On 2013-01-25 11:36, Tim Bell wrote:
 Here is the bug report:
 http://bugs.sun.com/view_bug.do?bug_id=8006933

 Use nawk instead of awk to avoid awk: string too long near line 1
 errors when running idlj in corba.  For new 'build-infra' style
 builds, this needs to be fixed in common/makefiles/IdlCompilation.gmk

 The errors are seen if the path to the build directory in the source
 tree is too long, greater than ~92.

   http://cr.openjdk.java.net/~tbell/8006933/00/

 Thanks in advance for any feedback.

 Tim


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

Re: Review request: 8006933: Need to use nawk on Solaris to avoid awk limitations

[Dmitry Samersoff]

Tim,

It might be better to remove AWK completely

$(FIND) . -type f | sed 's!\./!$3 : $4/!g'  $5

or ever

find . -type f -printf $3%s : $4\n

-Dmitry


On 2013-01-25 14:36, Tim Bell wrote:
 Here is the bug report:
 http://bugs.sun.com/view_bug.do?bug_id=8006933
 
 Use nawk instead of awk to avoid awk: string too long near line 1
 errors when running idlj in corba.  For new 'build-infra' style builds,
 this needs to be fixed in common/makefiles/IdlCompilation.gmk
 
 The errors are seen if the path to the build directory in the source
 tree is too long, greater than ~92.
 
   http://cr.openjdk.java.net/~tbell/8006933/00/
 
 Thanks in advance for any feedback.
 
 Tim
 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

Re: Review Request: 8006663: build-infra: Compare two arbitrary zip/jar files with compare.sh

[Dmitry Samersoff]

Erik,

What is the purpose of this comparison. Is it time critical?

On a brief look

unzip -v  /tmp/1
unzip -v  /tmp/2
diff /tmp/1 /tmp/2

do exactly the same but much much faster.

Maybe I missed something.

-Dmitry


On 2013-01-22 14:03, Erik Joelsson wrote:
 Adding functionality to compare.sh to take two zip/jar files as
 arguments and just compare those.
 
 http://cr.openjdk.java.net/~erikj/8006663/webrev.root.01/
 
 /Erik


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

Re: Review Request: 8006663: build-infra: Compare two arbitrary zip/jar files with compare.sh

[Dmitry Samersoff]

Erik,

Thank you for explanation!

-Dmitry


On 2013-01-22 19:05, Erik Joelsson wrote:
 Hello,
 
 The purpose of compare.sh is to compare build output between builds to
 check that nothing changed that shouldn't have. It has been developed
 and used in the build-infra project. Several file types need extra care
 when comparing and various exceptions to be made. For example zip and
 jar files need their contents compared rather than the files. Generated
 class, java and properties files often contain timestamps or other build
 unique strings that need to be filtered. All of this is handled in
 compare.sh.
 
 The problem in this case was that the UI available from compare.sh only
 lets you compare full build output directories. This patch adds a way to
 use the existing functionality for only 2 jar or zip files. I
 implemented it as part of converting the nashorn build to be able to
 verify that I produced an equivalent jar to the old ant build, but
 thought it would be worth pushing it in on its own.
 
 Your suggested solution is basically what compare.sh does with a zip
 file, but doesn't handle all the exceptions and special cases specific
 to openjdk build output.
 
 /Erik
 
 On 2013-01-22 15:49, Dmitry Samersoff wrote:
 Erik,

 What is the purpose of this comparison. Is it time critical?

 On a brief look

 unzip -v  /tmp/1
 unzip -v  /tmp/2
 diff /tmp/1 /tmp/2

 do exactly the same but much much faster.

 Maybe I missed something.

 -Dmitry


 On 2013-01-22 14:03, Erik Joelsson wrote:
 Adding functionality to compare.sh to take two zip/jar files as
 arguments and just compare those.

 http://cr.openjdk.java.net/~erikj/8006663/webrev.root.01/

 /Erik



-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

Re: invalid bug IDs aborting my pull

[Dmitry Samersoff]

Peter,

I guess you have to clone fresh copy rather than pull - someone recreate
server workspace.

-Dmitry

On 2012-11-14 19:53, Pete Brunet wrote:
 Hi I pulled this morning and jcheck aborted my pull -u because of
 invalid bug IDs for
 
 changeset 5413: bugid 8002040, author dholmes
 changeset 5490: bugid 8000989, author twisti
 
 I was able to pull -u over the last week or two.  Am I doing something
 wrong?
 
 Pete
 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

Re: Review Request: 8003274: build-infra: Makefile changes needed for sjavac

[Dmitry Samersoff]

Fredrik,

On 2012-11-12 22:04, Kelly O'Hair wrote:
 
 Interesting. I guess I would have done something like:
if [ `cat file | wc -w` -ne 0 ] ; then   check if we have words... 
 ;^)

I'm for this variant, because it meaning is obvious.

-Dmitry


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

Re: RFR: 8002034 and 8001756 - FDS changes mainly re cross-compiling

[Dmitry Samersoff]

David,

Looks good for me.

-Dmitry

On 2012-11-05 02:32, David Holmes wrote:
 Okay here's the final update :)
 
 http://cr.openjdk.java.net/~dholmes/8002034/webrev.03/
 
 We now have a default objcopy when cross-compiling and I augmented the
 error message if no objcopy is found. These changes only affect the
 linux defs.make.
 
 Thanks,
 David
 
 On 2/11/2012 12:39 PM, David Holmes wrote:
 On 2/11/2012 12:03 PM, BILL PITTORE wrote:
 On 11/1/2012 7:47 PM, David Holmes wrote:
 On 2/11/2012 8:49 AM, Dmitry Samersoff wrote:
 David,

 Sorry, (my eyes) I misread if

 As far as I understand, cross compilation require explicit
 ALT_OBJCOPY.

 Yes.

 Is there any defaults?

 No. The makefiles know nothing about the toolsets for cross-compiling.
 We set CC, CPP, CXX using COMPILER_PATH which gets us to the cross
 tools, why not go for OBJCOPY as well? It may or may not exist. Is that
 worse than the current situation?

 Fair point, we could just assume that when cross-compiling we find
 objcopy in the same place as gcc etc.

 Thanks,
 David


 bill


 Does it make sense to warn if ALT_OBJCOPY isn't set?

 The build already reports:

 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
 INFO: no objcopy cmd found so cannot create .debuginfo files.
 INFO: ENABLE_FULL_DEBUG_SYMBOLS=0

 I could extend that to say:

 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
 INFO: no objcopy cmd found so cannot create .debuginfo files. You may
 need to set ALT_OBJCOPY.
 INFO: ENABLE_FULL_DEBUG_SYMBOLS=0

 Thanks,
 David

 -Dmitry

 On 2012-11-02 02:15, David Holmes wrote:
 Thanks for the review Dmitry.

 On 1/11/2012 10:02 PM, Dmitry Samersoff wrote:
 David,s

 if we use host /usr/bin/objcopy for cross compiling,
 changes looks good for me.

 ??? We don't use host /usr/bin/objcopy for cross-compiling that is
 why
 DEF_OBJCOPY is only set when not cross-compiling.

 Of course you can set ALT_OBJCOPY=/usr/bin/objcopy when
 cross-compiling.
 It probably won't work but you can do it.

 David

 -Dmitry

 On 2012-11-01 07:41, David Holmes wrote:
 No takers so far - don't be shy, it's not a difficult one I
 promise :)

 Updated webrev:
 http://cr.openjdk.java.net/~dholmes/8002034/webrev.01/

 Because of the multiple sub-make invocations that occur during a
 build
 the FDS logic gets processed numerous times, many of which are not
 needed and which might show confusing output (eg that FDS is
 enabled
 when you have disabled it). So I added another conditional to at
 least
 check that BUILD_FLAVOR has been set - that excludes a couple of
 the
 unnecessary executions.

 Thanks,
 David

 On 31/10/2012 5:29 PM, David Holmes wrote:
 http://cr.openjdk.java.net/~dholmes/8002034/webrev/

 This mainly addresses

 JDK-8002034 Allow Full Debug Symbols when cross-compiling

 The initial FDS work simply disables FDS when cross-compilation is
 involved. But we're now ready to deal with the cross-compilation
 case
 (and even if we weren't these changes would be fine anyway). So
 if FDS
 is initially enabled we will rely on ALT_OBJCOPY being set to the
 correct value for cross-compilation; and we don't set the default
 OBJCOPY in that case. So if you do nothing when cross-compiling
 OBJCOPY
 will be empty and that will cause the build to disable FDS, just
 as if
 the OBJCOPY command was not found.

 As this is the same code that causes:

 JDK-8001756 Hotspot makefiles report missing OBJCOPY command in
 the
 wrong circumstances

 I also fixed this by moving the OBJCOPY checks inside the
 ENABLE_FULL_DEBUG_SYMBOLS=1 conditional. Basically unless we are
 asking
 for FDS we shouldn't complain if the OBJCOPY command is not found.

 This will be pushed to the hotspot-emb repo as it is needed there
 ASAP.

 I'll be doing a similar change, under 8002040, for the JDK side of
 things.

 Thanks,
 David







-- 
Dmitry Samersoff
Java development team, SPB04
* There will come soft rains ...

Re: RFR: 8002034 and 8001756 - FDS changes mainly re cross-compiling

[Dmitry Samersoff]

David,

OK. Thank you for the explanation!

-Dmitry

On 2012-11-04 13:45, David Holmes wrote:
 On 3/11/2012 2:17 AM, Dmitry Samersoff wrote:
 David,

 Other projects e.g. linux kernel sets CROSS_COMPILE, to specify the
 prefix for all executables used during compilation.

 e.g.
make CROSS_COMPILE=ia64-linux-

 will cause
  CC=ia64-linux-gcc
  OBJCOPY=ia64-linux-objcopy
 etc

 Could we adopt this convention?
 
 The new build handles cross-compilation more like the above, but hotspot
 makefiles have not been re-written in this way. Regardless that is a
 project way beyond the scope of this CR which requires that we get FDS
 enabled for 7u12 (and hence first in 8).
 
 David
 
 
 -Dmitry


 On 2012-11-02 06:39, David Holmes wrote:
 On 2/11/2012 12:03 PM, BILL PITTORE wrote:
 On 11/1/2012 7:47 PM, David Holmes wrote:
 On 2/11/2012 8:49 AM, Dmitry Samersoff wrote:
 David,

 Sorry, (my eyes) I misread if

 As far as I understand, cross compilation require explicit
 ALT_OBJCOPY.

 Yes.

 Is there any defaults?

 No. The makefiles know nothing about the toolsets for cross-compiling.
 We set CC, CPP, CXX using COMPILER_PATH which gets us to the cross
 tools, why not go for OBJCOPY as well? It may or may not exist. Is that
 worse than the current situation?

 Fair point, we could just assume that when cross-compiling we find
 objcopy in the same place as gcc etc.

 Thanks,
 David


 bill


 Does it make sense to warn if ALT_OBJCOPY isn't set?

 The build already reports:

 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
 INFO: no objcopy cmd found so cannot create .debuginfo files.
 INFO: ENABLE_FULL_DEBUG_SYMBOLS=0

 I could extend that to say:

 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
 INFO: no objcopy cmd found so cannot create .debuginfo files. You may
 need to set ALT_OBJCOPY.
 INFO: ENABLE_FULL_DEBUG_SYMBOLS=0

 Thanks,
 David

 -Dmitry

 On 2012-11-02 02:15, David Holmes wrote:
 Thanks for the review Dmitry.

 On 1/11/2012 10:02 PM, Dmitry Samersoff wrote:
 David,s

 if we use host /usr/bin/objcopy for cross compiling,
 changes looks good for me.

 ??? We don't use host /usr/bin/objcopy for cross-compiling that
 is why
 DEF_OBJCOPY is only set when not cross-compiling.

 Of course you can set ALT_OBJCOPY=/usr/bin/objcopy when
 cross-compiling.
 It probably won't work but you can do it.

 David

 -Dmitry

 On 2012-11-01 07:41, David Holmes wrote:
 No takers so far - don't be shy, it's not a difficult one I
 promise :)

 Updated webrev:
 http://cr.openjdk.java.net/~dholmes/8002034/webrev.01/

 Because of the multiple sub-make invocations that occur during a
 build
 the FDS logic gets processed numerous times, many of which are not
 needed and which might show confusing output (eg that FDS is
 enabled
 when you have disabled it). So I added another conditional to at
 least
 check that BUILD_FLAVOR has been set - that excludes a couple
 of the
 unnecessary executions.

 Thanks,
 David

 On 31/10/2012 5:29 PM, David Holmes wrote:
 http://cr.openjdk.java.net/~dholmes/8002034/webrev/

 This mainly addresses

 JDK-8002034 Allow Full Debug Symbols when cross-compiling

 The initial FDS work simply disables FDS when
 cross-compilation is
 involved. But we're now ready to deal with the cross-compilation
 case
 (and even if we weren't these changes would be fine anyway). So
 if FDS
 is initially enabled we will rely on ALT_OBJCOPY being set to the
 correct value for cross-compilation; and we don't set the default
 OBJCOPY in that case. So if you do nothing when cross-compiling
 OBJCOPY
 will be empty and that will cause the build to disable FDS, just
 as if
 the OBJCOPY command was not found.

 As this is the same code that causes:

 JDK-8001756 Hotspot makefiles report missing OBJCOPY command
 in the
 wrong circumstances

 I also fixed this by moving the OBJCOPY checks inside the
 ENABLE_FULL_DEBUG_SYMBOLS=1 conditional. Basically unless we are
 asking
 for FDS we shouldn't complain if the OBJCOPY command is not
 found.

 This will be pushed to the hotspot-emb repo as it is needed there
 ASAP.

 I'll be doing a similar change, under 8002040, for the JDK
 side of
 things.

 Thanks,
 David









-- 
Dmitry Samersoff
Java development team, SPB04
* There will come soft rains ...

Re: RFR: 8002034 and 8001756 - FDS changes mainly re cross-compiling

[Dmitry Samersoff]

David,

Other projects e.g. linux kernel sets CROSS_COMPILE, to specify the
prefix for all executables used during compilation.

e.g.
  make CROSS_COMPILE=ia64-linux-

will cause
CC=ia64-linux-gcc
OBJCOPY=ia64-linux-objcopy
etc

Could we adopt this convention?

-Dmitry


On 2012-11-02 06:39, David Holmes wrote:
 On 2/11/2012 12:03 PM, BILL PITTORE wrote:
 On 11/1/2012 7:47 PM, David Holmes wrote:
 On 2/11/2012 8:49 AM, Dmitry Samersoff wrote:
 David,

 Sorry, (my eyes) I misread if

 As far as I understand, cross compilation require explicit ALT_OBJCOPY.

 Yes.

 Is there any defaults?

 No. The makefiles know nothing about the toolsets for cross-compiling.
 We set CC, CPP, CXX using COMPILER_PATH which gets us to the cross
 tools, why not go for OBJCOPY as well? It may or may not exist. Is that
 worse than the current situation?
 
 Fair point, we could just assume that when cross-compiling we find
 objcopy in the same place as gcc etc.
 
 Thanks,
 David
 
 
 bill


 Does it make sense to warn if ALT_OBJCOPY isn't set?

 The build already reports:

 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
 INFO: no objcopy cmd found so cannot create .debuginfo files.
 INFO: ENABLE_FULL_DEBUG_SYMBOLS=0

 I could extend that to say:

 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
 INFO: no objcopy cmd found so cannot create .debuginfo files. You may
 need to set ALT_OBJCOPY.
 INFO: ENABLE_FULL_DEBUG_SYMBOLS=0

 Thanks,
 David

 -Dmitry

 On 2012-11-02 02:15, David Holmes wrote:
 Thanks for the review Dmitry.

 On 1/11/2012 10:02 PM, Dmitry Samersoff wrote:
 David,s

 if we use host /usr/bin/objcopy for cross compiling,
 changes looks good for me.

 ??? We don't use host /usr/bin/objcopy for cross-compiling that is why
 DEF_OBJCOPY is only set when not cross-compiling.

 Of course you can set ALT_OBJCOPY=/usr/bin/objcopy when
 cross-compiling.
 It probably won't work but you can do it.

 David

 -Dmitry

 On 2012-11-01 07:41, David Holmes wrote:
 No takers so far - don't be shy, it's not a difficult one I
 promise :)

 Updated webrev:
 http://cr.openjdk.java.net/~dholmes/8002034/webrev.01/

 Because of the multiple sub-make invocations that occur during a
 build
 the FDS logic gets processed numerous times, many of which are not
 needed and which might show confusing output (eg that FDS is enabled
 when you have disabled it). So I added another conditional to at
 least
 check that BUILD_FLAVOR has been set - that excludes a couple of the
 unnecessary executions.

 Thanks,
 David

 On 31/10/2012 5:29 PM, David Holmes wrote:
 http://cr.openjdk.java.net/~dholmes/8002034/webrev/

 This mainly addresses

 JDK-8002034 Allow Full Debug Symbols when cross-compiling

 The initial FDS work simply disables FDS when cross-compilation is
 involved. But we're now ready to deal with the cross-compilation
 case
 (and even if we weren't these changes would be fine anyway). So
 if FDS
 is initially enabled we will rely on ALT_OBJCOPY being set to the
 correct value for cross-compilation; and we don't set the default
 OBJCOPY in that case. So if you do nothing when cross-compiling
 OBJCOPY
 will be empty and that will cause the build to disable FDS, just
 as if
 the OBJCOPY command was not found.

 As this is the same code that causes:

 JDK-8001756 Hotspot makefiles report missing OBJCOPY command in the
 wrong circumstances

 I also fixed this by moving the OBJCOPY checks inside the
 ENABLE_FULL_DEBUG_SYMBOLS=1 conditional. Basically unless we are
 asking
 for FDS we shouldn't complain if the OBJCOPY command is not found.

 This will be pushed to the hotspot-emb repo as it is needed there
 ASAP.

 I'll be doing a similar change, under 8002040, for the JDK side of
 things.

 Thanks,
 David







-- 
Dmitry Samersoff
Java development team, SPB04
* There will come soft rains ...

Re: Enhance jcheck for Copyright location on 0th line ?

[Dmitry Samersoff]

Joe,

I would like to advertize the scripts that saves me lots of time.

This script is plugable and could be extended as necessary.

Actually, I would prefer to have one, uniform script as a part of a
build process and jcheck as the last line defender rather than set of
semi-maintained one-per-problem scripts.

-Dmitry

On 2012-10-18 23:43, Joe Darcy wrote:
 Kumar,
 
 There is now a copyright-checking script in the repos which could/should
 be run before a push or during an integration.
 
 I think this is preferable to having jcheck do more semantic analysis of
 sources given all the special cases that can come about.
 
 -Joe
 
 On 10/18/2012 12:06 PM, Kumar Srinivasan wrote:
 Hi,

 { I don't know if this has been brought my apologies if it has }

 When using NetBeans sometimes the import statements are inserted
 preceding
 the Copyright header, this happens with a new java file containing a
 Copyright header,
 and if import statements are absent, in which case NB does not know
 where to group
 them.

 Does anyone think it would be a worthwhile enhancement to jcheck, ie.
 warn and thereby ensure the Copyright header is on the very first line
 of the file ?

 Kumar
 


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...

Re: Is the skip boot cycle trick still needed?

[Dmitry Samersoff]

Jonathan,

Personally, I would prefer to have a separate set of tests - smoke
tests and appropriate make target. e.g. make test instead of BOOT_CYCLE
logic.

Test suite should have known coverage and predictable effects, otherwise
it makes an illusion of testing.

-Dmitry


On 2012-09-10 19:09, Jonathan Gibbons wrote:
 Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would be
 concerned about its removal.
 
 Is it really that hard to provide the same functionality in the new
 build system?  Surely, it should just be a matter of a couple of
 recursive makes at the top-level, the first into an interim build dir
 and the second using the result of the first as its ALT_BOOTDIR.
 
 -- Jon
 
 
 On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote:
 In the old system, one can set the oddly named SKIP_BOOT_CYCLE to
 false (which, internally, sets the slightly more clearly named
 DO_BOOT_CYCLE=true). This causes the product to build twice, the
 second time using the first build result as the boot jdk.

 This has been used, as I understand it, as a poor mans integration
 test -- if the build output could perform the feat of compiling the
 JDK, then it can't be that broken.

 This kind of behaviour is not implemented in the new build system, and
 I propose that it should not be. The cost for implementing this is
 that all build system for all builds will be more complicated, but the
 gains are more unclear. To me, this is just a test, and it's a bit odd
 to have that as part of the build system. I also believe are now far
 better tests using jtreg, and if they are lacking -- then the tests
 should be improved, not the build system changed.

 Is there anyone who would be protesting if the SKIP_BOOT_CYCLE
 functionality would be dropped in the new build system?

 /Magnus
 


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...

Any plan to cleanup x86 arch names?

[Dmitry Samersoff]

Hi Everyone,

Currently we uses i386, i486 and i586 within x86 build.

Do we have a plan to cleanup it and replace to just x86?

-Dmitry

-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...