Re: Fix zero build on arm

[Erik Joelsson]

On 2013-04-17 04:05, Omair Majid wrote:

Hi,

The following webrev makes zero build succesfully on arm:
http://cr.openjdk.java.net/~omajid/webrevs/zero-on-arm/00/

The only problem I ran into while trying to build zero on armv7l is that
the gcc there does not like -m32. The changes make the build system
check whether the compiler supports the -m32/-m64 flag before using it.

Any thoughts or comments?


In jdk/makefiles/GensrcX11Wrappers.gmk
Line 91: seems to be missing a dash before the m.

./common/autoconf/platform.m4
Line 422: Misspelled comment
Line 437 and 440, could be simplified and moved to before the if.
Line 436: don't you need a "test" after the if? At least that's the form 
we have used in the configure script.


/Erik

Re: RFR: 8011347: JDK-8009824 has broken webrev with some ksh versions

[Daniel Fuchs]

On 4/16/13 5:02 PM, Jim Gish wrote:

I've updated the version to 24.0 and add Mike as a reviewer.  Could
someone please push this for me?


Hi Jim,

Done.

Thanks for the fix!

-- daniel



Thanks,
 Jim

On 04/15/2013 06:34 PM, Mike Duigou wrote:

I think the version number needs to be changed. My vote is to bump it
to 24.0

Mike

On Apr 12 2013, at 11:08 , Jim Gish wrote:


Please review http://cr.openjdk.java.net/~jgish/Bug8011347-webrev/
, which fixes
the current webrev issues on solaris and mac.

Thanks,
   Jim

--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com

Re: Fix zero build on arm

[Andrew Hughes]

- Original Message -
> 
> 
> On 2013-04-17 04:05, Omair Majid wrote:
> > Hi,
> >
> > The following webrev makes zero build succesfully on arm:
> > http://cr.openjdk.java.net/~omajid/webrevs/zero-on-arm/00/
> >
> > The only problem I ran into while trying to build zero on armv7l is that
> > the gcc there does not like -m32. The changes make the build system
> > check whether the compiler supports the -m32/-m64 flag before using it.
> >
> > Any thoughts or comments?
> >
> In jdk/makefiles/GensrcX11Wrappers.gmk
> Line 91: seems to be missing a dash before the m.
> 
> ./common/autoconf/platform.m4
> Line 422: Misspelled comment
> Line 437 and 440, could be simplified and moved to before the if.
> Line 436: don't you need a "test" after the if? At least that's the form
> we have used in the configure script.
> 
> /Erik
> 
> 

Where are you getting this line numbers from?  I don't see any.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

Re: Fix zero build on arm

[Erik Joelsson]

On 2013-04-17 15:56, Andrew Hughes wrote:


Where are you getting this line numbers from?  I don't see any.
I just realized not all the diffs have them. I usually start with 
"Sdiffs" and it shows line numbers. The "New" and "Old" also has them.


/Erik

Found and solved a bug on Cursor Management on Windows platforms

[Morvan Le Mescam]

Dear all,

When developping a Swing client, I face the following problem :
When setting the hand cursor on Windows, I noticed that the default system
cursor was not used.

I analysed the problem and found the rrot cause.
I also made a correction and tested it on Windows 7.

This is my analyse :

When reading Java source code, it is obvious that on Windows, Java does not
use System resources.

In the code (from *jdk\src\windows\native\sun\windows\awt_Cursor.cpp* )
bellow :

AwtCursor * AwtCursor::*CreateSystemCursor*(jobject jCursor)

{

JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2);



jint type = env->GetIntField(jCursor, AwtCursor::typeID);

DASSERT(type != java_awt_Cursor_CUSTOM_CURSOR);



LPCTSTR winCursor;

switch (type) {

  case java_awt_Cursor_DEFAULT_CURSOR:

  default:

winCursor = IDC_ARROW;

break;

  case java_awt_Cursor_CROSSHAIR_CURSOR:

winCursor = IDC_CROSS;

break;

*[…]*

*  case java_awt_Cursor_HAND_CURSOR:*

*winCursor = TEXT("HAND_CURSOR");*

*break;*

  case java_awt_Cursor_MOVE_CURSOR:

winCursor = IDC_SIZEALL;

break;

}

*HCURSOR hCursor = ::LoadCursor(NULL, winCursor);*

if (*hCursor == NULL*) {

/* Not a system cursor, check for resource. */

*hCursor = ::LoadCursor(AwtToolkit::GetInstance().GetModuleHandle(),
*

*   winCursor);*

}

if (hCursor == NULL) {

hCursor = ::LoadCursor(NULL, IDC_ARROW);

DASSERT(hCursor != NULL);

}



AwtCursor *awtCursor = new AwtCursor(env, hCursor, jCursor);

setPData(jCursor, ptr_to_jlong(awtCursor));



return awtCursor;

}



In the case of the HAND_CURSOR (*in red*),  Java will try to load the
cursor from the system (*in blue*).

If it fails (*hCursor == NULL*) then it will try to load the cursor from
its own resource (*in orange*) :

*hCursor = ::LoadCursor(AwtToolkit::GetInstance().GetModuleHandle(),*

*   winCursor);*



In our case, if we check in the AWTToolkit module resources, in *
jdk\src\windows\native\sun\windows\awr.rc*, we find the following content :

#include "windows.h"



// Need 2 defines so macro argument to XSTR will get expanded before
quoting.

#define XSTR(x) STR(x)

#define STR(x)  #x



LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL



*HAND_CURSOR  CURSOR  DISCARDABLE "hand.cur"*

AWT_ICON ICONDISCARDABLE "awt.ico"

CHECK_BITMAP BITMAP  DISCARDABLE "check.bmp"



And we find that java.exe embed its own hand cursor, in *
jdk\src\windows\native\sun\windows\hand.cur* : The “famous” hand that it is
displayed instead of our system cursor.


This is the correction :

, I made the correction into the JRE source code :

  case java_awt_Cursor_HAND_CURSOR:

/* MLM change winCursor = TEXT("HAND_CURSOR"); */

winCursor = IDC_HAND;

break;

I could compile and regenerate a JRE with this change :

D:\Work\Current\openjdk\build\windows-amd64\bin>java -version

openjdk version "1.7.0-u6-unofficial"

OpenJDK Runtime Environment (build 1.7.0-u6-unofficial-b24)

OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)





And this works !

If I change the hand cursor at System level, Java takes it into account.
Last but not least question:

Why did a Sun developper, one day :  winCursor = TEXT("HAND_CURSOR");

This seems so not consistent with other part of the code... So there is
probably a good reason. Perhaps the hand cursor was not existant on Windows
platform when this was done ?


Regards


Morvan

Re: Found and solved a bug on Cursor Management on Windows platforms

[Anthony Petrov]

Hi Morvan,

build-dev@ is the wrong mailing list for this topic. It belongs to 
awt-...@openjdk.java.net only. Please re-post this message there.


--
best regards,
Anthony

On 04/17/2013 09:01 PM, Morvan Le Mescam wrote:

Dear all,

When developping a Swing client, I face the following problem :
When setting the hand cursor on Windows, I noticed that the default system
cursor was not used.

I analysed the problem and found the rrot cause.
I also made a correction and tested it on Windows 7.

This is my analyse :

When reading Java source code, it is obvious that on Windows, Java does not
use System resources.

In the code (from *jdk\src\windows\native\sun\windows\awt_Cursor.cpp* )
bellow :

AwtCursor * AwtCursor::*CreateSystemCursor*(jobject jCursor)

{

 JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2);



 jint type = env->GetIntField(jCursor, AwtCursor::typeID);

 DASSERT(type != java_awt_Cursor_CUSTOM_CURSOR);



 LPCTSTR winCursor;

 switch (type) {

   case java_awt_Cursor_DEFAULT_CURSOR:

   default:

 winCursor = IDC_ARROW;

 break;

   case java_awt_Cursor_CROSSHAIR_CURSOR:

 winCursor = IDC_CROSS;

 break;

*[…]*

*  case java_awt_Cursor_HAND_CURSOR:*

*winCursor = TEXT("HAND_CURSOR");*

*break;*

   case java_awt_Cursor_MOVE_CURSOR:

 winCursor = IDC_SIZEALL;

 break;

 }

*HCURSOR hCursor = ::LoadCursor(NULL, winCursor);*

 if (*hCursor == NULL*) {

 /* Not a system cursor, check for resource. */

 *hCursor = ::LoadCursor(AwtToolkit::GetInstance().GetModuleHandle(),
*

*   winCursor);*

 }

 if (hCursor == NULL) {

 hCursor = ::LoadCursor(NULL, IDC_ARROW);

 DASSERT(hCursor != NULL);

 }



 AwtCursor *awtCursor = new AwtCursor(env, hCursor, jCursor);

 setPData(jCursor, ptr_to_jlong(awtCursor));



 return awtCursor;

}



In the case of the HAND_CURSOR (*in red*),  Java will try to load the
cursor from the system (*in blue*).

If it fails (*hCursor == NULL*) then it will try to load the cursor from
its own resource (*in orange*) :

*hCursor = ::LoadCursor(AwtToolkit::GetInstance().GetModuleHandle(),*

*   winCursor);*



In our case, if we check in the AWTToolkit module resources, in *
jdk\src\windows\native\sun\windows\awr.rc*, we find the following content :

#include "windows.h"



// Need 2 defines so macro argument to XSTR will get expanded before
quoting.

#define XSTR(x) STR(x)

#define STR(x)  #x



LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL



*HAND_CURSOR  CURSOR  DISCARDABLE "hand.cur"*

AWT_ICON ICONDISCARDABLE "awt.ico"

CHECK_BITMAP BITMAP  DISCARDABLE "check.bmp"



And we find that java.exe embed its own hand cursor, in *
jdk\src\windows\native\sun\windows\hand.cur* : The “famous” hand that it is
displayed instead of our system cursor.


This is the correction :

, I made the correction into the JRE source code :

   case java_awt_Cursor_HAND_CURSOR:

 /* MLM change winCursor = TEXT("HAND_CURSOR"); */

 winCursor = IDC_HAND;

 break;

I could compile and regenerate a JRE with this change :

D:\Work\Current\openjdk\build\windows-amd64\bin>java -version

openjdk version "1.7.0-u6-unofficial"

OpenJDK Runtime Environment (build 1.7.0-u6-unofficial-b24)

OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)





And this works !

If I change the hand cursor at System level, Java takes it into account.
Last but not least question:

Why did a Sun developper, one day :  winCursor = TEXT("HAND_CURSOR");

This seems so not consistent with other part of the code... So there is
probably a good reason. Perhaps the hand cursor was not existant on Windows
platform when this was done ?


Regards


Morvan

hg: jdk8/build/hotspot: 19 new changesets

[david . katleman]

Changeset: e437668ced9d
Author:amurillo
Date:  2013-04-11 01:14 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e437668ced9d

8011948: new hotspot build - hs25-b28
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 68fe50d4f1d5
Author:johnc
Date:  2013-04-05 10:20 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/68fe50d4f1d5

8011343: Add new flag for verifying the heap during startup
Summary: Perform verification during VM startup under control of new flag and 
within a VMOperation.
Reviewed-by: stefank, jmasa, brutisso

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp
- test/gc/TestVerifyBeforeGCDuringStartup.java
+ test/gc/TestVerifyDuringStartup.java

Changeset: 8617e38bb4cb
Author:jmasa
Date:  2013-02-11 10:31 -0800
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8617e38bb4cb

8008508: CMS does not correctly reduce heap size after a Full GC
Reviewed-by: johnc, ysr

! 
src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! 
src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/generation.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/memory/tenuredGeneration.cpp
! src/share/vm/memory/tenuredGeneration.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 83f27710f5f7
Author:brutisso
Date:  2013-04-08 07:49 +0200
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/83f27710f5f7

7197666: java -d64 -version core dumps in a box with lots of memory
Summary: Allow task queues to be mmapped instead of malloced on Solaris
Reviewed-by: coleenp, jmasa, johnc, tschatzl

! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/taskqueue.hpp

Changeset: 63f57a8c5283
Author:mgerdin
Date:  2013-04-09 15:32 +0200
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/63f57a8c5283

8009808: TEST-BUG : test case is using bash style tests. Default shell for 
jtreg is bourne. thus failure
Summary: Rewrite test to use Java only instead of shell script
Reviewed-by: mgerdin, brutisso
Contributed-by: leonid.mes...@oracle.com

+ test/gc/6941923/Test6941923.java
- test/gc/6941923/test6941923.sh

Changeset: ba42fd5e00e6
Author:mgerdin
Date:  2013-04-10 13:27 +0200
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ba42fd5e00e6

8010196: NPG: Internal Error: Metaspace allocation lock -- possible deadlock
Summary: Refactor the CLD dependency list into a separate class. Use an 
ObjectLocker to synchronize additions to the CLD dependency list.
Reviewed-by: stefank, coleenp

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
+ test/gc/metaspace/G1AddMetaspaceDependency.java

Changeset: 7b835924c31c
Author:stefank
Date:  2013-04-10 14:26 +0200
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7b835924c31c

8011872: Include Bit Map addresses in the hs_err files
Reviewed-by: brutisso, jmasa

! 
src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! 
src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/utilities/bitMap.cpp
! src/share/vm/utilities/bitMap.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 480d934f62a8
Author:mgerdin
Date:  2013-04-11 16:35 +0200
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/480d934f62a8

Merge

! src/share/vm/runtime/arguments.cpp
- test/runtime/NMT/AllocTestType.java

Changeset: 705ef39fcaa9
Author:neliasso
Date:  2013-04-05 11:09 +0200
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/705ef39fcaa9

8006016: Memory leak at hotspot/src/share/vm/adlc/output_c.cpp
Reviewed-by: kvn, roland
Contributed-by: niclas.adle...@oracle.com

! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp

Changeset: f67065f02409
Author:bharadwaj
Date:  2013-04-08 07:40 -0700
URL:   http://hg.openjdk.j

Find in langtools/makefiles/BuildLangtools.gmk

[Kurchi Hazra]

Hi,

   I had not been able to build on Windows + Cygwin for the past few 
days and it boils down to using find directly (instead of $(FIND)) in
http://opengrok.ireland.sun.com:8080/opengrok/xref/jdk8-tl/langtools/makefiles/BuildLangtools.gmk#59 



  Is this something that should be fixed?

Thanks,
Kurchi

What is the Build Process for Codes inside jdk/src/macosx/native/jobjc

[Dan Xu]

Hi,

As for the sourcecodes for mac platform, it has a special place holding 
native and java codes for jdk, jdk/src/macosx/native/jobjc. I wonder how 
those codes are builtand whether its compilation process has any special 
handling. Thanks!


-Dan

Re: What is the Build Process for Codes inside jdk/src/macosx/native/jobjc

[Dan Xu]

Adding core-libs-dev

On 04/17/2013 04:47 PM, Dan Xu wrote:

Hi,

As for the sourcecodes for mac platform, it has a special place 
holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I 
wonder how those codes are builtand whether its compilation process 
has any special handling. Thanks!


-Dan

Re: What is the Build Process for Codes inside jdk/src/macosx/native/jobjc

[David Holmes]

Hi Dan,

I don't quite understand the question but all native code building is 
handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn 
utilizes the set up from /common/makefiles/NativeCompilation.gmk


HTH

David

On 18/04/2013 9:51 AM, Dan Xu wrote:

Adding core-libs-dev

On 04/17/2013 04:47 PM, Dan Xu wrote:

Hi,

As for the sourcecodes for mac platform, it has a special place
holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
wonder how those codes are builtand whether its compilation process
has any special handling. Thanks!

-Dan

Re: What is the Build Process for Codes inside jdk/src/macosx/native/jobjc

[Dan Xu]

Hi David,

Under src/macosx/native/jobjc folder, it contains not only native *.m 
source files, but also *.java files. If you check the build results in 
build/macosx-x86_64-normal-server-release/jdk folder, it contains some 
build results specific for jobjc, say gensrc_jobjc/, 
gensrc_headers_jobjc/, jobjc_classes/, jobjc_classes_headers/.


So it must have some extra build steps to generate those jobjc results. 
And I wonder what they are and why they are special and not merged into 
the regular native compilation and java compilation processes. Thanks!


-Dan


On 04/17/2013 05:30 PM, David Holmes wrote:

Hi Dan,

I don't quite understand the question but all native code building is 
handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn 
utilizes the set up from /common/makefiles/NativeCompilation.gmk


HTH

David

On 18/04/2013 9:51 AM, Dan Xu wrote:

Adding core-libs-dev

On 04/17/2013 04:47 PM, Dan Xu wrote:

Hi,

As for the sourcecodes for mac platform, it has a special place
holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
wonder how those codes are builtand whether its compilation process
has any special handling. Thanks!

-Dan

Re: What is the Build Process for Codes inside jdk/src/macosx/native/jobjc

[David Holmes]

On 18/04/2013 10:50 AM, Dan Xu wrote:

Hi David,

Under src/macosx/native/jobjc folder, it contains not only native *.m
source files, but also *.java files. If you check the build results in
build/macosx-x86_64-normal-server-release/jdk folder, it contains some
build results specific for jobjc, say gensrc_jobjc/,
gensrc_headers_jobjc/, jobjc_classes/, jobjc_classes_headers/.

So it must have some extra build steps to generate those jobjc results.
And I wonder what they are and why they are special and not merged into
the regular native compilation and java compilation processes. Thanks!


In jdk/makefiles:

- The java files are handled in CompileJavaClasses.gmk.
- There is special handling via GensrcJObjC.gmk

David


-Dan


On 04/17/2013 05:30 PM, David Holmes wrote:

Hi Dan,

I don't quite understand the question but all native code building is
handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn
utilizes the set up from /common/makefiles/NativeCompilation.gmk

HTH

David

On 18/04/2013 9:51 AM, Dan Xu wrote:

Adding core-libs-dev

On 04/17/2013 04:47 PM, Dan Xu wrote:

Hi,

As for the sourcecodes for mac platform, it has a special place
holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
wonder how those codes are builtand whether its compilation process
has any special handling. Thanks!

-Dan