custom extension for make/SourceRevision.gmk

[Christian Thalinger]

Here at Twitter our OpenJDK clone lives in a GIT repository and we would like 
to use the source-revision feature of the release file.

I have all the custom extension logic in place to create the revision tracker:

$ cat 
build/macosx-x86_64-normal-server-release/support/src-rev/source-revision-tracker
 
.:ea60d3b1efc0

but the way make/SourceRevision.gmk is structured (the custom extensions is 
included at the top of the file) always triggers the warning:

$ make
Building target 'default (exploded-image)' in configuration 
'macosx-x86_64-normal-server-release'
Warning: No mercurial configuration present and no .src-rev
Finished building target 'default (exploded-image)' in configuration 
'macosx-x86_64-normal-server-release'

Is there a way so silence the warning without restructuring the upstream file?  
And if no, can we change it so it works?

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 18, 2018, at 1:46 PM, Erik Joelsson  wrote:
> 
> Hello Christian,
> 
> Sometimes we need hooks both close to the beginning and close to the end of 
> the file, and in that case we create a SourceBundle-post.gmk. The recommended 
> position of the post inclusion is right before the typical "all: $(TARGETS)" 
> declaration. This file has the all target depend explicitly on a list of 
> phony targets and no TARGETS variable, so I would recommend changing that to 
> building a TARGETS variable like we usually do. That way you can create a 
> SourceBundle-post.gmk and clear the TARGETS variable from any targets you 
> don't want to run from the open file. Does that sound ok?

Yes, that would be great.  In JDK 11, please :-)

> 
> /Erik
> 
> 
> On 2018-07-18 10:31, Christian Thalinger wrote:
>> Here at Twitter our OpenJDK clone lives in a GIT repository and we would 
>> like to use the source-revision feature of the release file.
>> 
>> I have all the custom extension logic in place to create the revision 
>> tracker:
>> 
>> $ cat 
>> build/macosx-x86_64-normal-server-release/support/src-rev/source-revision-tracker
>> .:ea60d3b1efc0
>> 
>> but the way make/SourceRevision.gmk is structured (the custom extensions is 
>> included at the top of the file) always triggers the warning:
>> 
>> $ make
>> Building target 'default (exploded-image)' in configuration 
>> 'macosx-x86_64-normal-server-release'
>> Warning: No mercurial configuration present and no .src-rev
>> Finished building target 'default (exploded-image)' in configuration 
>> 'macosx-x86_64-normal-server-release'
>> 
>> Is there a way so silence the warning without restructuring the upstream 
>> file?  And if no, can we change it so it works?
> 

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 18, 2018, at 3:28 PM, Christian Thalinger  
> wrote:
> 
> 
> 
>> On Jul 18, 2018, at 1:46 PM, Erik Joelsson  wrote:
>> 
>> Hello Christian,
>> 
>> Sometimes we need hooks both close to the beginning and close to the end of 
>> the file, and in that case we create a SourceBundle-post.gmk. The 
>> recommended position of the post inclusion is right before the typical "all: 
>> $(TARGETS)" declaration. This file has the all target depend explicitly on a 
>> list of phony targets and no TARGETS variable, so I would recommend changing 
>> that to building a TARGETS variable like we usually do. That way you can 
>> create a SourceBundle-post.gmk and clear the TARGETS variable from any 
>> targets you don't want to run from the open file. Does that sound ok?
> 
> Yes, that would be great.  In JDK 11, please :-)

Ok, this is the only way I could make it work:

diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
index 10dd943..13ea407 100644
--- a/make/SourceRevision.gmk
+++ b/make/SourceRevision.gmk
@@ -28,7 +28,7 @@ default: all
 include $(SPEC)
 include MakeBase.gmk
 
-$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
+$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))
 
 

 # Keep track of what source revision is used to create the build, by creating
@@ -94,11 +94,14 @@ ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )
 
   $(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))
 
-  store-source-revision: $(STORED_SOURCE_REVISION)
+  hg-store-source-revision: $(STORED_SOURCE_REVISION)
 
   $(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))
 
-  create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+  hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+
+  STORE_SOURCE_REVISION_TARGET = hg-store-source-revision
+  CREATE_SOURCE_REVISION_TRACKER_TARGET = hg-create-source-revision-tracker
 
 else
   # Not using HG
@@ -106,26 +109,39 @@ else
   ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
 # We have a stored source revision (.src-rev)
 
-store-source-revision:
+src-store-source-revision:
$(call LogInfo, No mercurial configuration present$(COMMA) not updating 
.src-rev)
 
 $(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
$(install-file)
 
-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
   else
 # We don't have a stored source revision. Can't do anything, really.
 
-store-source-revision:
+src-store-source-revision:
$(call LogWarn, Error: No mercurial configuration present$(COMMA) 
cannot create .src-rev)
exit 2
 
-create-source-revision-tracker:
+src-create-source-revision-tracker:
$(call LogWarn, Warning: No mercurial configuration present and no 
.src-rev)
   endif
 
+  STORE_SOURCE_REVISION_TARGET = src-store-source-revision
+  CREATE_SOURCE_REVISION_TRACKER_TARGET = src-create-source-revision-tracker
+
 endif
 
+
+
+$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
+
+
+
+store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
+
+create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
+
 all: store-source-revision create-source-revision-tracker
 
 FRC: # Force target

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 19, 2018, at 12:08 PM, Erik Joelsson  wrote:
> 
> Hello,
> On 2018-07-19 07:43, Christian Thalinger wrote:
>> 
>> 
>>> On Jul 18, 2018, at 3:28 PM, Christian Thalinger >> <mailto:cthalin...@twitter.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Jul 18, 2018, at 1:46 PM, Erik Joelsson >>> <mailto:erik.joels...@oracle.com>> wrote:
>>>> 
>>>> Hello Christian,
>>>> 
>>>> Sometimes we need hooks both close to the beginning and close to the end 
>>>> of the file, and in that case we create a SourceBundle-post.gmk. The 
>>>> recommended position of the post inclusion is right before the typical 
>>>> "all: $(TARGETS)" declaration. This file has the all target depend 
>>>> explicitly on a list of phony targets and no TARGETS variable, so I would 
>>>> recommend changing that to building a TARGETS variable like we usually do. 
>>>> That way you can create a SourceBundle-post.gmk and clear the TARGETS 
>>>> variable from any targets you don't want to run from the open file. Does 
>>>> that sound ok?
>>> 
>>> Yes, that would be great.  In JDK 11, please :-)
>> 
>> Ok, this is the only way I could make it work:
>> 
>> diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
>> index 10dd943..13ea407 100644
>> --- a/make/SourceRevision.gmk
>> +++ b/make/SourceRevision.gmk
>> @@ -28,7 +28,7 @@ default: all
>>  include $(SPEC)
>>  include MakeBase.gmk
>>  
>> -$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
>> +$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))
>>  
>>  
>> 
>>  # Keep track of what source revision is used to create the build, by 
>> creating
>> @@ -94,11 +94,14 @@ ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )
>>  
>>$(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))
>>  
>> -  store-source-revision: $(STORED_SOURCE_REVISION)
>> +  hg-store-source-revision: $(STORED_SOURCE_REVISION)
>>  
>>$(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))
>>  
>> -  create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>> +  hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>> +
> These assignments should be using :=. Applies further down as well.
>> +  STORE_SOURCE_REVISION_TARGET = hg-store-source-revision
>> +  CREATE_SOURCE_REVISION_TRACKER_TARGET = hg-create-source-revision-tracker
>>  
>>  else
>># Not using HG
>> @@ -106,26 +109,39 @@ else
>>ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
>>  # We have a stored source revision (.src-rev)
>>  
>> -store-source-revision:
>> +src-store-source-revision:
>> $(call LogInfo, No mercurial configuration present$(COMMA) not 
>> updating .src-rev)
>>  
>>  $(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
>> $(install-file)
>>  
>> -create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>> +src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>>else
>>  # We don't have a stored source revision. Can't do anything, really.
>>  
>> -store-source-revision:
>> +src-store-source-revision:
>> $(call LogWarn, Error: No mercurial configuration present$(COMMA) 
>> cannot create .src-rev)
>> exit 2
>>  
>> -create-source-revision-tracker:
>> +src-create-source-revision-tracker:
>> $(call LogWarn, Warning: No mercurial configuration present and no 
>> .src-rev)
>>endif
>>  
>> +  STORE_SOURCE_REVISION_TARGET = src-store-source-revision
>> +  CREATE_SOURCE_REVISION_TRACKER_TARGET = src-create-source-revision-tracker
>> +
>>  endif
>>  
>> +
>> +
>> +$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
>> +
>> +
>> +
> I would suggest using the variables directly on the all: line instead of 
> declaring more phony targets. 

Well, the issue is this:

exploded-image: exploded-image-base release-file

  release-file: create-source-revision-tracker

store-source-revision:
+($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk 
store-source-revision)

create-source-revision-tracker:
+($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk 
create-source-revision-tracker)

We need these targets because all isn’t really used.

>> +store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
>> +
>> +create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
>> +
>>  all: store-source-revision create-source-revision-tracker
>>  
>>  FRC: # Force target
>> 
> Do you really need the separate variables? Since both of them are built by 
> all anyway, I would just have one variable TARGETS to which you add 
> everything you wish to build and finish with "all: $(TARGETS)".
> 
> /Erik

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 19, 2018, at 12:46 PM, Erik Joelsson  wrote:
> 
> One thing though. Since you are renaming the top file, we need to coordinate 
> pushing of this change since we are relying on the old name.

We can keep the old name, if you want, but that wouldn’t be very consistent 
with other files.

> 
> /Erik
> 
> 
> On 2018-07-19 09:44, Erik Joelsson wrote:
>> 
>> On 2018-07-19 09:16, Christian Thalinger wrote:
>>> 
>>> 
>>> Well, the issue is this:
>>> 
>>> exploded-image: exploded-image-base release-file
>>> 
>>>   release-file: create-source-revision-tracker
>>> 
>>> store-source-revision:
>>>   +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk 
>>> store-source-revision)
>>> 
>>> create-source-revision-tracker:
>>>   +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk 
>>> create-source-revision-tracker)
>>> 
>>> We need these targets because all isn’t really used.
>>> 
>> Ah, the all target is tricking me and should be removed if not called from 
>> anywhere. Then your suggested patch is good (except for missing the :=).
>> 
>> /Erik
>>>>> +store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
>>>>> +
>>>>> +create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
>>>>> +
>>>>>  all: store-source-revision create-source-revision-tracker
>>>>> 
>>>>>  FRC: # Force target
>>>>> 
>>>> Do you really need the separate variables? Since both of them are built by 
>>>> all anyway, I would just have one variable TARGETS to which you add 
>>>> everything you wish to build and finish with "all: $(TARGETS)".
>>>> 
>>>> /Erik
>>> 
>> 
> 

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 19, 2018, at 12:44 PM, Erik Joelsson  wrote:
> 
> 
> On 2018-07-19 09:16, Christian Thalinger wrote:
>> 
>> 
>> Well, the issue is this:
>> 
>> exploded-image: exploded-image-base release-file
>> 
>>   release-file: create-source-revision-tracker
>> 
>> store-source-revision:
>> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk 
>> store-source-revision)
>> 
>> create-source-revision-tracker:
>> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk 
>> create-source-revision-tracker)
>> 
>> We need these targets because all isn’t really used.
>> 
> Ah, the all target is tricking me and should be removed if not called from 
> anywhere. Then your suggested patch is good (except for missing the :=).

Do you want me to remove the all: target?

> 
> /Erik
>>>> +store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
>>>> +
>>>> +create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
>>>> +
>>>>  all: store-source-revision create-source-revision-tracker
>>>>  
>>>>  FRC: # Force target
>>>> 
>>> Do you really need the separate variables? Since both of them are built by 
>>> all anyway, I would just have one variable TARGETS to which you add 
>>> everything you wish to build and finish with "all: $(TARGETS)".
>>> 
>>> /Erik
>> 
> 

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 19, 2018, at 12:57 PM, Erik Joelsson  wrote:
> 
> 
> 
> On 2018-07-19 09:54, Christian Thalinger wrote:
>> 
>> 
>>> On Jul 19, 2018, at 12:44 PM, Erik Joelsson >> <mailto:erik.joels...@oracle.com>> wrote:
>>> 
>>> 
>>> On 2018-07-19 09:16, Christian Thalinger wrote:
>>>> 
>>>> 
>>>> Well, the issue is this:
>>>> 
>>>> exploded-image: exploded-image-base release-file
>>>> 
>>>>   release-file: create-source-revision-tracker
>>>> 
>>>> store-source-revision:
>>>> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
>>>> SourceRevision.gmk store-source-revision)
>>>> 
>>>> create-source-revision-tracker:
>>>> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
>>>> SourceRevision.gmk create-source-revision-tracker)
>>>> 
>>>> We need these targets because all isn’t really used.
>>>> 
>>> Ah, the all target is tricking me and should be removed if not called from 
>>> anywhere. Then your suggested patch is good (except for missing the :=).
>> 
>> Do you want me to remove the all: target?
>> 
> Yes, that would be a good cleanup to avoid confusion.

How about this:

diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
index 10dd943..6d4a706 100644
--- a/make/SourceRevision.gmk
+++ b/make/SourceRevision.gmk
@@ -1,5 +1,5 @@
 #
-# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
+# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved.
 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 #
 # This code is free software; you can redistribute it and/or modify it
@@ -23,12 +23,10 @@
 # questions.
 #
 
-default: all
-
 include $(SPEC)
 include MakeBase.gmk
 
-$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
+$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))
 
 

 # Keep track of what source revision is used to create the build, by creating
@@ -94,11 +92,14 @@ ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )
 
   $(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))
 
-  store-source-revision: $(STORED_SOURCE_REVISION)
+  hg-store-source-revision: $(STORED_SOURCE_REVISION)
 
   $(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))
 
-  create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+  hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+
+  STORE_SOURCE_REVISION_TARGET := hg-store-source-revision
+  CREATE_SOURCE_REVISION_TRACKER_TARGET := hg-create-source-revision-tracker
 
 else
   # Not using HG
@@ -106,28 +107,39 @@ else
   ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
 # We have a stored source revision (.src-rev)
 
-store-source-revision:
+src-store-source-revision:
$(call LogInfo, No mercurial configuration present$(COMMA) not updating 
.src-rev)
 
 $(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
$(install-file)
 
-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
   else
 # We don't have a stored source revision. Can't do anything, really.
 
-store-source-revision:
+src-store-source-revision:
$(call LogWarn, Error: No mercurial configuration present$(COMMA) 
cannot create .src-rev)
exit 2
 
-create-source-revision-tracker:
+src-create-source-revision-tracker:
$(call LogWarn, Warning: No mercurial configuration present and no 
.src-rev)
   endif
 
+  STORE_SOURCE_REVISION_TARGET := src-store-source-revision
+  CREATE_SOURCE_REVISION_TRACKER_TARGET := src-create-source-revision-tracker
+
 endif
 
-all: store-source-revision create-source-revision-tracker
+
+
+$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
+
+
+
+store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
+
+create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
 
 FRC: # Force target
 
-.PHONY: all store-source-revision create-source-revision-tracker
+.PHONY: store-source-revision create-source-revision-tracker

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

On Thu, Jul 19, 2018 at 1:11 PM Erik Joelsson 
wrote:

> This looks good to me, but will need coordination when pushed as I said
> earlier.
>

Do you want to push it so it’s easier?

/Erik
>
> On 2018-07-19 10:04, Christian Thalinger wrote:
>
>
>
> On Jul 19, 2018, at 12:57 PM, Erik Joelsson 
> wrote:
>
>
>
> On 2018-07-19 09:54, Christian Thalinger wrote:
>
>
>
> On Jul 19, 2018, at 12:44 PM, Erik Joelsson 
> wrote:
>
>
> On 2018-07-19 09:16, Christian Thalinger wrote:
>
>
>
> Well, the issue is this:
>
> exploded-image: exploded-image-base release-file
>
>   release-file: create-source-revision-tracker
>
> store-source-revision:
> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f
> SourceRevision.gmk store-source-revision)
>
> create-source-revision-tracker:
> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f
> SourceRevision.gmk create-source-revision-tracker)
>
> We need these targets because all isn’t really used.
>
> Ah, the all target is tricking me and should be removed if not called from
> anywhere. Then your suggested patch is good (except for missing the :=).
>
>
> Do you want me to remove the all: target?
>
> Yes, that would be a good cleanup to avoid confusion.
>
>
> How about this:
>
> diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
> index 10dd943..6d4a706 100644
> --- a/make/SourceRevision.gmk
> +++ b/make/SourceRevision.gmk
> @@ -1,5 +1,5 @@
>  #
> -# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
> +# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights
> reserved.
>  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  #
>  # This code is free software; you can redistribute it and/or modify it
> @@ -23,12 +23,10 @@
>  # questions.
>  #
>
>
> -default: all
> -
>  include $(SPEC)
>  include MakeBase.gmk
>
>
> -$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
> +$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))
>
>
>
>  
> 
>  # Keep track of what source revision is used to create the build, by
> creating
> @@ -94,11 +92,14 @@ ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )
>
>
>$(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))
>
>
> -  store-source-revision: $(STORED_SOURCE_REVISION)
> +  hg-store-source-revision: $(STORED_SOURCE_REVISION)
>
>
>$(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))
>
>
> -  create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
> +  hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
> +
> +  STORE_SOURCE_REVISION_TARGET := hg-store-source-revision
> +  CREATE_SOURCE_REVISION_TRACKER_TARGET :=
> hg-create-source-revision-tracker
>
>
>  else
># Not using HG
> @@ -106,28 +107,39 @@ else
>ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
>  # We have a stored source revision (.src-rev)
>
>
> -store-source-revision:
> +src-store-source-revision:
> $(call LogInfo, No mercurial configuration present$(COMMA) not
> updating .src-rev)
>
>
>  $(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
> $(install-file)
>
>
> -create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
> +src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>else
>  # We don't have a stored source revision. Can't do anything, really.
>
>
> -store-source-revision:
> +src-store-source-revision:
> $(call LogWarn, Error: No mercurial configuration present$(COMMA)
> cannot create .src-rev)
> exit 2
>
>
> -create-source-revision-tracker:
> +src-create-source-revision-tracker:
> $(call LogWarn, Warning: No mercurial configuration present and no
> .src-rev)
>endif
>
>
> +  STORE_SOURCE_REVISION_TARGET := src-store-source-revision
> +  CREATE_SOURCE_REVISION_TRACKER_TARGET :=
> src-create-source-revision-tracker
> +
>  endif
>
>
> -all: store-source-revision create-source-revision-tracker
>
> +
> +
> +$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
> +
>
> +
> +
> +store-source-revision: $(STORE_SOURCE_REVISION_TARGET)
> +
> +create-source-revision-tracker: $(CREATE_SOURCE_REVISION_TRACKER_TARGET)
>
>
>  FRC: # Force target
>
>
> -.PHONY: all store-source-revision create-source-revision-tracker
> +.PHONY: store-source-revision create-source-revision-tracker
>
>
>

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 19, 2018, at 2:31 PM, Erik Joelsson  wrote:
> 
> I can do that. Do you have a bug?
> 
No.
> /Erik
> 
> On 2018-07-19 10:57, Christian Thalinger wrote:
>> 
>> 
>> On Thu, Jul 19, 2018 at 1:11 PM Erik Joelsson > <mailto:erik.joels...@oracle.com>> wrote:
>> This looks good to me, but will need coordination when pushed as I said 
>> earlier.
>> 
>> 
>> Do you want to push it so it’s easier?
>> 
>> /Erik
>> 
>> On 2018-07-19 10:04, Christian Thalinger wrote:
>>> 
>>> 
>>>> On Jul 19, 2018, at 12:57 PM, Erik Joelsson >>> <mailto:erik.joels...@oracle.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 2018-07-19 09:54, Christian Thalinger wrote:
>>>>> 
>>>>> 
>>>>>> On Jul 19, 2018, at 12:44 PM, Erik Joelsson >>>>> <mailto:erik.joels...@oracle.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>> On 2018-07-19 09:16, Christian Thalinger wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Well, the issue is this:
>>>>>>> 
>>>>>>> exploded-image: exploded-image-base release-file
>>>>>>> 
>>>>>>>   release-file: create-source-revision-tracker
>>>>>>> 
>>>>>>> store-source-revision:
>>>>>>> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
>>>>>>> SourceRevision.gmk store-source-revision)
>>>>>>> 
>>>>>>> create-source-revision-tracker:
>>>>>>> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
>>>>>>> SourceRevision.gmk create-source-revision-tracker)
>>>>>>> 
>>>>>>> We need these targets because all isn’t really used.
>>>>>>> 
>>>>>> Ah, the all target is tricking me and should be removed if not called 
>>>>>> from anywhere. Then your suggested patch is good (except for missing the 
>>>>>> :=).
>>>>> 
>>>>> Do you want me to remove the all: target?
>>>>> 
>>>> Yes, that would be a good cleanup to avoid confusion.
>>> 
>>> How about this:
>>> 
>>> diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
>>> index 10dd943..6d4a706 100644
>>> --- a/make/SourceRevision.gmk
>>> +++ b/make/SourceRevision.gmk
>>> @@ -1,5 +1,5 @@
>>>  #
>>> -# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
>>> +# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights 
>>> reserved.
>>>  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  #
>>>  # This code is free software; you can redistribute it and/or modify it
>>> @@ -23,12 +23,10 @@
>>>  # questions.
>>>  #
>>>  
>>> -default: all
>>> -
>>>  include $(SPEC)
>>>  include MakeBase.gmk
>>>  
>>> -$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
>>> +$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))
>>>  
>>>  
>>> 
>>>  # Keep track of what source revision is used to create the build, by 
>>> creating
>>> @@ -94,11 +92,14 @@ ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )
>>>  
>>>$(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))
>>>  
>>> -  store-source-revision: $(STORED_SOURCE_REVISION)
>>> +  hg-store-source-revision: $(STORED_SOURCE_REVISION)
>>>  
>>>$(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))
>>>  
>>> -  create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>>> +  hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>>> +
>>> +  STORE_SOURCE_REVISION_TARGET := hg-store-source-revision
>>> +  CREATE_SOURCE_REVISION_TRACKER_TARGET := 
>>> hg-create-source-revision-tracker
>>>  
>>>  else
>>># Not using HG
>>> @@ -106,28 +107,39 @@ else
>>>ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
>>>  # We have a stored source revision (.src-rev)
>>>  
>>> -store-source-revision:
>>> +src-store-source-revision:
>>> $(call LogInf

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

> On Jul 19, 2018, at 9:17 PM, Christian Thalinger  
> wrote:
> 
> 
> 
>> On Jul 19, 2018, at 2:31 PM, Erik Joelsson > <mailto:erik.joels...@oracle.com>> wrote:
>> 
>> I can do that. Do you have a bug?
>> 
> No.

Sorry, was on vacation… I don’t see the change in the repo. Did you file one?

>> /Erik
>> 
>> On 2018-07-19 10:57, Christian Thalinger wrote:
>>> 
>>> 
>>> On Thu, Jul 19, 2018 at 1:11 PM Erik Joelsson >> <mailto:erik.joels...@oracle.com>> wrote:
>>> This looks good to me, but will need coordination when pushed as I said 
>>> earlier.
>>> 
>>> 
>>> Do you want to push it so it’s easier?
>>> 
>>> /Erik
>>> 
>>> On 2018-07-19 10:04, Christian Thalinger wrote:
>>>> 
>>>> 
>>>>> On Jul 19, 2018, at 12:57 PM, Erik Joelsson >>>> <mailto:erik.joels...@oracle.com>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2018-07-19 09:54, Christian Thalinger wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Jul 19, 2018, at 12:44 PM, Erik Joelsson >>>>>> <mailto:erik.joels...@oracle.com>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> On 2018-07-19 09:16, Christian Thalinger wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Well, the issue is this:
>>>>>>>> 
>>>>>>>> exploded-image: exploded-image-base release-file
>>>>>>>> 
>>>>>>>>   release-file: create-source-revision-tracker
>>>>>>>> 
>>>>>>>> store-source-revision:
>>>>>>>> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
>>>>>>>> SourceRevision.gmk store-source-revision)
>>>>>>>> 
>>>>>>>> create-source-revision-tracker:
>>>>>>>> +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f 
>>>>>>>> SourceRevision.gmk create-source-revision-tracker)
>>>>>>>> 
>>>>>>>> We need these targets because all isn’t really used.
>>>>>>>> 
>>>>>>> Ah, the all target is tricking me and should be removed if not called 
>>>>>>> from anywhere. Then your suggested patch is good (except for missing 
>>>>>>> the :=).
>>>>>> 
>>>>>> Do you want me to remove the all: target?
>>>>>> 
>>>>> Yes, that would be a good cleanup to avoid confusion.
>>>> 
>>>> How about this:
>>>> 
>>>> diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
>>>> index 10dd943..6d4a706 100644
>>>> --- a/make/SourceRevision.gmk
>>>> +++ b/make/SourceRevision.gmk
>>>> @@ -1,5 +1,5 @@
>>>>  #
>>>> -# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
>>>> +# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights 
>>>> reserved.
>>>>  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>  #
>>>>  # This code is free software; you can redistribute it and/or modify it
>>>> @@ -23,12 +23,10 @@
>>>>  # questions.
>>>>  #
>>>>  
>>>> -default: all
>>>> -
>>>>  include $(SPEC)
>>>>  include MakeBase.gmk
>>>>  
>>>> -$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
>>>> +$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))
>>>>  
>>>>  
>>>> 
>>>>  # Keep track of what source revision is used to create the build, by 
>>>> creating
>>>> @@ -94,11 +92,14 @@ ifneq ($(and $(HG), $(wildcard $(TOPDIR)/.hg)), )
>>>>  
>>>>$(eval $(call CreateSourceRevisionFile, $(STORED_SOURCE_REVISION)))
>>>>  
>>>> -  store-source-revision: $(STORED_SOURCE_REVISION)
>>>> +  hg-store-source-revision: $(STORED_SOURCE_REVISION)
>>>>  
>>>>$(eval $(call CreateSourceRevisionFile, $(SOURCE_REVISION_TRACKER)))
>>>>  
>>>> -  create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
>>>> +  hg-create-sou

Re: custom extension for make/SourceRevision.gmk

[Christian Thalinger]

Done: https://bugs.openjdk.java.net/browse/JDK-8210008

> On Aug 23, 2018, at 4:56 PM, Erik Joelsson  wrote:
> 

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

[Christian Thalinger]

> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie 
>  wrote:
> 
> On 2015-09-14 09:24, Christian Thalinger wrote:
>> The JEP itself can be found here:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8062493 
>> <https://bugs.openjdk.java.net/browse/JDK-8062493>
>> 
>> Here are the webrevs:
>> 
>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ 
>> <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/>
>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ 
>> <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/>
>> 
>> The change has already undergone a few iterations of internal review by 
>> different people of different teams.  Most comments and suggestions were 
>> handled accordingly.  Although there is one open item we agreed we will 
>> address after the integration of JEP 243 and that work is captured in RFE:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8134994 
>> <https://bugs.openjdk.java.net/browse/JDK-8134994>
>> 
>> SQE is still working on the tests and all test tasks can be seen as 
>> sub-tasks of the JEP.
>> 
>> The integration will happen under the bug number:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8136421 
>> <https://bugs.openjdk.java.net/browse/JDK-8136421>
>> 
> Hi Christian,
> 
> (Adding build-dev since this review includes some major build changes.)
> 
> The makefile changes looks good in general to me. I have not reviewed the 
> source code changes.
> 
> Some comments:
> 
> * modules.xml:
> Make sure you get sign-off from a Jigsaw developer for modifying this file.

I’ve asked Alan to take a look.

> 
> * hotspot/make/linux/makefiles/gcc.make:
> Seems unfortunate to have to disable a new warning 
> (undefined-bool-conversion) for newly incorporated code. Is it not possible 
> to fix the code emitting this warning instead?

We had this question before.  It’s not obvious because you can’t see it in the 
regular diff views but this is under:

ifeq ($(USE_CLANG), true)

> 
> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk:
> I see a coming merge conflict. In jdk9/dev, there is now a new function that 
> performs the same function as CreatePath, but it's named PathList. (It's a 
> bit unfortunate that this code snippet has bounced around as patches without 
> a definite name.) I assume you are going to push this through a hotspot 
> forest. If the PathList patch reaches the hotspot repo before this, please 
> remove the CreatePath from MakeBase, and change the calls to CreatePath to 
> PathList instead. (I could only find such calls in 
> hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before that, 
> we'll need to give a heads-up to the integrator about this conflict.

Thanks for the heads up.

> 
> Another potential coming merge conflict relates to ListPathsSafely in 
> Gensrc-java.base.gmk. There is currenlty a review out from Erik which 
> modifies the API for ListPathsSafely. If/when it goes in, the call to 
> ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can 
> give advice on how). Depending on timing, this too might hit the integrator 
> rather than your push.

Ok, thanks.

> 
> /Magnus

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

[Christian Thalinger]

> On Sep 16, 2015, at 10:11 AM, Magnus Ihse Bursie 
>  wrote:
> 
> On 2015-09-16 18:52, Christian Thalinger wrote:
>>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie 
>>>  wrote:
>>> 
>>> On 2015-09-14 09:24, Christian Thalinger wrote:
>>>> The JEP itself can be found here:
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8062493 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8062493>
>>>> 
>>>> Here are the webrevs:
>>>> 
>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ 
>>>> <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/>
>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ 
>>>> <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/>
>>>> 
>>>> The change has already undergone a few iterations of internal review by 
>>>> different people of different teams.  Most comments and suggestions were 
>>>> handled accordingly. Although there is one open item we agreed we will 
>>>> address after the integration of JEP 243 and that work is captured in RFE:
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8134994 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8134994>
>>>> 
>>>> SQE is still working on the tests and all test tasks can be seen as 
>>>> sub-tasks of the JEP.
>>>> 
>>>> The integration will happen under the bug number:
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8136421 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8136421>
>>>> 
>>> Hi Christian,
>>> 
>>> (Adding build-dev since this review includes some major build changes.)
>>> 
>>> The makefile changes looks good in general to me. I have not reviewed the 
>>> source code changes.
>>> 
>>> Some comments:
>>> 
>>> * modules.xml:
>>> Make sure you get sign-off from a Jigsaw developer for modifying this file.
>> I’ve asked Alan to take a look.
>> 
>>> * hotspot/make/linux/makefiles/gcc.make:
>>> Seems unfortunate to have to disable a new warning 
>>> (undefined-bool-conversion) for newly incorporated code. Is it not possible 
>>> to fix the code emitting this warning instead?
>> We had this question before.  It’s not obvious because you can’t see it in 
>> the regular diff views but this is under:
>> 
>> ifeq ($(USE_CLANG), true)
> 
> I'm not sure I understand why that's relevant..? Isn't it just as important 
> to try to submit warning-free code when compiling with clang as with any 
> other compiler? Or is clang just being anal about the code in question?

I don’t have a Clang compiler at hand but Clang is anal about everything.  Do 
you want that suppression to be removed?

> 
> /Magnus
> 
>> 
>>> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk:
>>> I see a coming merge conflict. In jdk9/dev, there is now a new function 
>>> that performs the same function as CreatePath, but it's named PathList. 
>>> (It's a bit unfortunate that this code snippet has bounced around as 
>>> patches without a definite name.) I assume you are going to push this 
>>> through a hotspot forest. If the PathList patch reaches the hotspot repo 
>>> before this, please remove the CreatePath from MakeBase, and change the 
>>> calls to CreatePath to PathList instead. (I could only find such calls in 
>>> hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before 
>>> that, we'll need to give a heads-up to the integrator about this conflict.
>> Thanks for the heads up.
>> 
>>> Another potential coming merge conflict relates to ListPathsSafely in 
>>> Gensrc-java.base.gmk. There is currenlty a review out from Erik which 
>>> modifies the API for ListPathsSafely. If/when it goes in, the call to 
>>> ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can 
>>> give advice on how). Depending on timing, this too might hit the integrator 
>>> rather than your push.
>> Ok, thanks.
>> 
>>> /Magnus

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

[Christian Thalinger]

> On Sep 16, 2015, at 6:52 AM, Christian Thalinger 
>  wrote:
> 
> 
>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie 
>>  wrote:
>> 
>> On 2015-09-14 09:24, Christian Thalinger wrote:
>>> The JEP itself can be found here:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8062493 
>>> <https://bugs.openjdk.java.net/browse/JDK-8062493>
>>> 
>>> Here are the webrevs:
>>> 
>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ 
>>> <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/>
>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ 
>>> <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/>
>>> 
>>> The change has already undergone a few iterations of internal review by 
>>> different people of different teams.  Most comments and suggestions were 
>>> handled accordingly.  Although there is one open item we agreed we will 
>>> address after the integration of JEP 243 and that work is captured in RFE:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8134994 
>>> <https://bugs.openjdk.java.net/browse/JDK-8134994>
>>> 
>>> SQE is still working on the tests and all test tasks can be seen as 
>>> sub-tasks of the JEP.
>>> 
>>> The integration will happen under the bug number:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8136421 
>>> <https://bugs.openjdk.java.net/browse/JDK-8136421>
>>> 
>> Hi Christian,
>> 
>> (Adding build-dev since this review includes some major build changes.)
>> 
>> The makefile changes looks good in general to me. I have not reviewed the 
>> source code changes.
>> 
>> Some comments:
>> 
>> * modules.xml:
>> Make sure you get sign-off from a Jigsaw developer for modifying this file.
> 
> I’ve asked Alan to take a look.
> 
>> 
>> * hotspot/make/linux/makefiles/gcc.make:
>> Seems unfortunate to have to disable a new warning 
>> (undefined-bool-conversion) for newly incorporated code. Is it not possible 
>> to fix the code emitting this warning instead?
> 
> We had this question before.  It’s not obvious because you can’t see it in 
> the regular diff views but this is under:
> 
> ifeq ($(USE_CLANG), true)
> 
>> 
>> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk:
>> I see a coming merge conflict. In jdk9/dev, there is now a new function that 
>> performs the same function as CreatePath, but it's named PathList. (It's a 
>> bit unfortunate that this code snippet has bounced around as patches without 
>> a definite name.) I assume you are going to push this through a hotspot 
>> forest. If the PathList patch reaches the hotspot repo before this, please 
>> remove the CreatePath from MakeBase, and change the calls to CreatePath to 
>> PathList instead. (I could only find such calls in 
>> hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before 
>> that, we'll need to give a heads-up to the integrator about this conflict.
> 
> Thanks for the heads up.

Erik sent me a patch to avoid merge conflicts.  I’ve integrated two changesets:

http://hg.openjdk.java.net/graal/graal-jvmci-9/rev/ddedccc5c0ab 
<http://hg.openjdk.java.net/graal/graal-jvmci-9/rev/ddedccc5c0ab>
http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/fee6b89199c9 
<http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/fee6b89199c9>

> 
>> 
>> Another potential coming merge conflict relates to ListPathsSafely in 
>> Gensrc-java.base.gmk. There is currenlty a review out from Erik which 
>> modifies the API for ListPathsSafely. If/when it goes in, the call to 
>> ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can 
>> give advice on how). Depending on timing, this too might hit the integrator 
>> rather than your push.
> 
> Ok, thanks.
> 
>> 
>> /Magnus
> 

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

[Christian Thalinger]

I would like to add this change:

diff -r 2134e08cc132 src/share/vm/utilities/vmError.cpp
--- a/src/share/vm/utilities/vmError.cppWed Sep 16 14:28:33 2015 -1000
+++ b/src/share/vm/utilities/vmError.cppWed Sep 16 15:04:02 2015 -1000
@@ -517,6 +517,10 @@ void VMError::report(outputStream* st) {
Abstract_VM_Version::vm_release(),
Abstract_VM_Version::vm_info_string(),
TieredCompilation ? ", tiered" : "",
+#if INCLUDE_JVMCI
+   EnableJVMCI ? ", jvmci" : "",
+   UseJVMCICompiler ? ", jvmci compiler" : "",
+#endif
UseCompressedOops ? ", compressed oops" : "",
gc_mode(),
Abstract_VM_Version::vm_platform_string()

It would be useful to see in the crash logs if this experimental feature was 
turned on.

> On Sep 16, 2015, at 12:43 PM, Vladimir Kozlov  
> wrote:
> 
> I updated top and hotspot webrev with latest (build) changes.
> 
> Vladimir
> 
> On 9/16/15 2:28 PM, Christian Thalinger wrote:
>> 
>>> On Sep 16, 2015, at 6:52 AM, Christian Thalinger 
>>>  wrote:
>>> 
>>> 
>>>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie 
>>>>  wrote:
>>>> 
>>>> On 2015-09-14 09:24, Christian Thalinger wrote:
>>>>> The JEP itself can be found here:
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8062493 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8062493>
>>>>> 
>>>>> Here are the webrevs:
>>>>> 
>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ 
>>>>> <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/>
>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ 
>>>>> <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/>
>>>>> 
>>>>> The change has already undergone a few iterations of internal review by 
>>>>> different people of different teams.  Most comments and suggestions were 
>>>>> handled accordingly.  Although there is one open item we agreed we will 
>>>>> address after the integration of JEP 243 and that work is captured in RFE:
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8134994 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8134994>
>>>>> 
>>>>> SQE is still working on the tests and all test tasks can be seen as 
>>>>> sub-tasks of the JEP.
>>>>> 
>>>>> The integration will happen under the bug number:
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8136421 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8136421>
>>>>> 
>>>> Hi Christian,
>>>> 
>>>> (Adding build-dev since this review includes some major build changes.)
>>>> 
>>>> The makefile changes looks good in general to me. I have not reviewed the 
>>>> source code changes.
>>>> 
>>>> Some comments:
>>>> 
>>>> * modules.xml:
>>>> Make sure you get sign-off from a Jigsaw developer for modifying this file.
>>> 
>>> I’ve asked Alan to take a look.
>>> 
>>>> 
>>>> * hotspot/make/linux/makefiles/gcc.make:
>>>> Seems unfortunate to have to disable a new warning 
>>>> (undefined-bool-conversion) for newly incorporated code. Is it not 
>>>> possible to fix the code emitting this warning instead?
>>> 
>>> We had this question before.  It’s not obvious because you can’t see it in 
>>> the regular diff views but this is under:
>>> 
>>> ifeq ($(USE_CLANG), true)
>>> 
>>>> 
>>>> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk:
>>>> I see a coming merge conflict. In jdk9/dev, there is now a new function 
>>>> that performs the same function as CreatePath, but it's named PathList. 
>>>> (It's a bit unfortunate that this code snippet has bounced around as 
>>>> patches without a definite name.) I assume you are going to push this 
>>>> through a hotspot forest. If the PathList patch reaches the hotspot repo 
>>>> before this, please remove the CreatePath from MakeBase, and change the 
>>>> calls to CreatePath to PathList instead. (I could only find such calls in 
>>>> hotspot/make/gensrc/Gensrc-java.base.gmk). If this p

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

[Christian Thalinger]

Since there are no objections I’m going to push this…

http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/6a6766a8cbbf

> On Sep 16, 2015, at 3:05 PM, Christian Thalinger 
>  wrote:
> 
> I would like to add this change:
> 
> diff -r 2134e08cc132 src/share/vm/utilities/vmError.cpp
> --- a/src/share/vm/utilities/vmError.cpp  Wed Sep 16 14:28:33 2015 -1000
> +++ b/src/share/vm/utilities/vmError.cpp  Wed Sep 16 15:04:02 2015 -1000
> @@ -517,6 +517,10 @@ void VMError::report(outputStream* st) {
>Abstract_VM_Version::vm_release(),
>Abstract_VM_Version::vm_info_string(),
>TieredCompilation ? ", tiered" : "",
> +#if INCLUDE_JVMCI
> +   EnableJVMCI ? ", jvmci" : "",
> +   UseJVMCICompiler ? ", jvmci compiler" : "",
> +#endif
>UseCompressedOops ? ", compressed oops" : "",
>gc_mode(),
>Abstract_VM_Version::vm_platform_string()
> 
> It would be useful to see in the crash logs if this experimental feature was 
> turned on.
> 
>> On Sep 16, 2015, at 12:43 PM, Vladimir Kozlov  
>> wrote:
>> 
>> I updated top and hotspot webrev with latest (build) changes.
>> 
>> Vladimir
>> 
>> On 9/16/15 2:28 PM, Christian Thalinger wrote:
>>> 
>>>> On Sep 16, 2015, at 6:52 AM, Christian Thalinger 
>>>>  wrote:
>>>> 
>>>> 
>>>>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie 
>>>>>  wrote:
>>>>> 
>>>>> On 2015-09-14 09:24, Christian Thalinger wrote:
>>>>>> The JEP itself can be found here:
>>>>>> 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8062493 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8062493>
>>>>>> 
>>>>>> Here are the webrevs:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ 
>>>>>> <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/>
>>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ 
>>>>>> <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/>
>>>>>> 
>>>>>> The change has already undergone a few iterations of internal review by 
>>>>>> different people of different teams.  Most comments and suggestions were 
>>>>>> handled accordingly.  Although there is one open item we agreed we will 
>>>>>> address after the integration of JEP 243 and that work is captured in 
>>>>>> RFE:
>>>>>> 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134994 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8134994>
>>>>>> 
>>>>>> SQE is still working on the tests and all test tasks can be seen as 
>>>>>> sub-tasks of the JEP.
>>>>>> 
>>>>>> The integration will happen under the bug number:
>>>>>> 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8136421 
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8136421>
>>>>>> 
>>>>> Hi Christian,
>>>>> 
>>>>> (Adding build-dev since this review includes some major build changes.)
>>>>> 
>>>>> The makefile changes looks good in general to me. I have not reviewed the 
>>>>> source code changes.
>>>>> 
>>>>> Some comments:
>>>>> 
>>>>> * modules.xml:
>>>>> Make sure you get sign-off from a Jigsaw developer for modifying this 
>>>>> file.
>>>> 
>>>> I’ve asked Alan to take a look.
>>>> 
>>>>> 
>>>>> * hotspot/make/linux/makefiles/gcc.make:
>>>>> Seems unfortunate to have to disable a new warning 
>>>>> (undefined-bool-conversion) for newly incorporated code. Is it not 
>>>>> possible to fix the code emitting this warning instead?
>>>> 
>>>> We had this question before.  It’s not obvious because you can’t see it in 
>>>> the regular diff views but this is under:
>>>> 
>>>> ifeq ($(USE_CLANG), true)
>>>> 
>>>>> 
>>>>> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk:
>>>>> I see a coming merge conflict. In jdk9/dev, there is n

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

[Christian Thalinger]

> On Sep 17, 2015, at 10:20 PM, Volker Simonis  wrote:
> 
> For the top-level change I always get a strange error when importing it:
> 
> patch failed, unable to continue (try -v)
> patch failed, rejects left in working dir
> errors during apply, please fix and refresh 8062493_jvmci_top_0911.v1.patch
> 
> It is because of the strange path syntax of the last hunk in the patch file:
> 
> --- old/./modules.xml 2015-09-16 15:11:14.0 -0700
> +++ new/./modules.xml 2015-09-16 15:11:14.0 -0700
> @@ -254,6 +254,14 @@
>   jdk.jfr
> 
> 
> +  jdk.internal.jvmci.hotspot
> +  jdk.jfr
> +
> +
> +  jdk.internal.jvmci.hotspot.events
> +  jdk.jfr
> +
> +
>   sun.misc
>   java.corba
>   java.desktop
> 
> 
> Notice the strange syntax "old/./modules.xml" and "new/./modules.xml".
> If I remove the redundant './' from the path, everything works fine.
> For some reason only the diffs for modules.xml has this strange path
> syntax in the patch.

That’s odd.  Vladimir created the webrevs.  Maybe he did something different 
with the top-level one.

> 
> Regards,
> Volker
> 
> 
> On Thu, Sep 17, 2015 at 10:32 PM, Christian Thalinger
>  wrote:
>> Since there are no objections I’m going to push this…
>> 
>> http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/6a6766a8cbbf
>> 
>>> On Sep 16, 2015, at 3:05 PM, Christian Thalinger 
>>>  wrote:
>>> 
>>> I would like to add this change:
>>> 
>>> diff -r 2134e08cc132 src/share/vm/utilities/vmError.cpp
>>> --- a/src/share/vm/utilities/vmError.cpp  Wed Sep 16 14:28:33 2015 -1000
>>> +++ b/src/share/vm/utilities/vmError.cpp  Wed Sep 16 15:04:02 2015 -1000
>>> @@ -517,6 +517,10 @@ void VMError::report(outputStream* st) {
>>>   Abstract_VM_Version::vm_release(),
>>>   Abstract_VM_Version::vm_info_string(),
>>>   TieredCompilation ? ", tiered" : "",
>>> +#if INCLUDE_JVMCI
>>> +   EnableJVMCI ? ", jvmci" : "",
>>> +   UseJVMCICompiler ? ", jvmci compiler" : "",
>>> +#endif
>>>   UseCompressedOops ? ", compressed oops" : "",
>>>   gc_mode(),
>>>       Abstract_VM_Version::vm_platform_string()
>>> 
>>> It would be useful to see in the crash logs if this experimental feature 
>>> was turned on.
>>> 
>>>> On Sep 16, 2015, at 12:43 PM, Vladimir Kozlov  
>>>> wrote:
>>>> 
>>>> I updated top and hotspot webrev with latest (build) changes.
>>>> 
>>>> Vladimir
>>>> 
>>>> On 9/16/15 2:28 PM, Christian Thalinger wrote:
>>>>> 
>>>>>> On Sep 16, 2015, at 6:52 AM, Christian Thalinger 
>>>>>>  wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie 
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> On 2015-09-14 09:24, Christian Thalinger wrote:
>>>>>>>> The JEP itself can be found here:
>>>>>>>> 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8062493 
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8062493>
>>>>>>>> 
>>>>>>>> Here are the webrevs:
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ 
>>>>>>>> <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/>
>>>>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ 
>>>>>>>> <http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/>
>>>>>>>> 
>>>>>>>> The change has already undergone a few iterations of internal review 
>>>>>>>> by different people of different teams.  Most comments and suggestions 
>>>>>>>> were handled accordingly.  Although there is one open item we agreed 
>>>>>>>> we will address after the integration of JEP 243 and that work is 
>>>>>>>> captured in RFE:
>>>>>>>> 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134994 
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8134994>
>>&

Re: CLANG special case

[Christian Thalinger]

I’ve assigned the bug to me and will verify…

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

Re: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

[Christian Thalinger]

Copy-pasting the comment I made earlier (internally):

>> make/bsd/makefiles/gcc.make:
>> 
>> + ifeq ($(BUILD_STATIC),true)
>> + CXXFLAGS += -DSTATIC_BUILD
>> + CFLAGS += -DSTATIC_BUILD
>> 
>> Can we use the same name everywhere?
> 
> We were trying to differentiate Makefile options from compile time 
> conditionals.
> In one case it’s set to true and the other it’s defined.
> 
> Are there no other cases where this is done?

I’m not sure but looking at make/excludeSrc.make all of them use the same name.

> On Oct 15, 2015, at 8:10 AM, Bob Vandette  wrote:
> 
> Please review this JDK 9 enhancement which allows a completely static build 
> of the JDK for MacOSX x64 platforms.
> 
> https://bugs.openjdk.java.net/browse/JDK-8136556 
> 
> 
> The change involves:
> 
> 1. Producing “.a” archives for each native libraries.
> 2. Ensuring that all symbols across the JDK native libraries are unique.
> 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to 
> have the each library name appended per
>   the JNI specification.
> 4. Modifications to the launcher and launcher Makefiles to allow them to be 
> linked with the java.base and jdk.jdwp.agent libraries
>   and function.
> 
> http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ 
> 
> http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ 
> 
> http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ 
> 
> 
> Note: This change does not link every possible static library with the 
> launchers.  It is currently limited to
> the java.base and jdk.jdwp.agent libraries in order to allow for the TCK 
> validation of the base module only.
> 
> 
> Bob.

Re: RFR: JDK-8139657: Incremental build of jdk.vm.ci-gensrc creates repeated entries in services file

[Christian Thalinger]

Looks good.

Since you are a JDK 9 Reviewer, will you push this fix?

> On Oct 15, 2015, at 2:39 AM, Erik Joelsson  wrote:
> 
> Hello,
> 
> Sorry for not noticing this earlier. Here is a fix for the problem with 
> repeating lines in the services file.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8139657
> Patch:
> diff -r 9ab5571ccea8 make/gensrc/Gensrc-jdk.vm.ci.gmk
> --- a/make/gensrc/Gensrc-jdk.vm.ci.gmk
> +++ b/make/gensrc/Gensrc-jdk.vm.ci.gmk
> @@ -108,7 +108,11 @@
> ($(CD) $(GENSRC_DIR)/META-INF/jvmci.providers && \
> for i in $$($(LS)); do \
>   c=$$($(CAT) $$i | $(TR) -d '\n\r'); \
> -  $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c; \
> +  $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c.tmp; \
> +done)
> +($(CD) $(GENSRC_DIR)/META-INF/services && \
> +for i in $$($(LS) *.tmp); do \
> +  $(MV) $$i $${i%.tmp}; \
> done)
> $(TOUCH) $@
> 
> /Erik
> 
> On 2015-10-08 04:42, Christian Thalinger wrote:
>>> On Oct 5, 2015, at 2:47 AM, Magnus Ihse Bursie 
>>>  wrote:
>>> 
>>> On 2015-09-29 03:12, Christian Thalinger wrote:
>>>>> On Sep 27, 2015, at 11:25 PM, Magnus Ihse Bursie 
>>>>>  wrote:
>>>>> 
>>>>> On 2015-09-25 22:00, Christian Thalinger wrote:
>>>>>> Btw. we found a bug in creating the OptionDescriptors files; we get 
>>>>>> duplicate entries:
>>>>>> 
>>>>>> $ cat 
>>>>>> build/macosx-x86_64-normal-server-release/jdk/modules/java.base/META-INF/services/jdk.internal.jvmci.options.OptionDescriptors
>>>>>> jdk.internal.jvmci.compiler.Compiler_OptionDescriptors
>>>>>> jdk.internal.jvmci.hotspot.HotSpotConstantReflectionProvider_OptionDescriptors
>>>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaFieldImpl_OptionDescriptors
>>>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaMethodImpl_OptionDescriptors
>>>>>> jdk.internal.jvmci.compiler.Compiler_OptionDescriptors
>>>>>> jdk.internal.jvmci.hotspot.HotSpotConstantReflectionProvider_OptionDescriptors
>>>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaFieldImpl_OptionDescriptors
>>>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaMethodImpl_OptionDescriptors
>>>>>> …
>>>>>> 
>>>>>> Would this be the right fix?
>>>>>> 
>>>>>> diff -r db1a815d2f6c make/gensrc/Gensrc-java.base.gmk
>>>>>> --- a/make/gensrc/Gensrc-java.base.gmkThu Sep 24 15:35:49 2015 -1000
>>>>>> +++ b/make/gensrc/Gensrc-java.base.gmkFri Sep 25 18:18:35 2015 +0200
>>>>>> @@ -94,6 +94,7 @@
>>>>>>$(GENSRC_DIR)/_gensrc_proc_done
>>>>>> $(MKDIR) -p $(@D)
>>>>>> ($(CD) $(GENSRC_DIR)/META-INF/jvmci.options && \
>>>>>> +$(RM) -f $@; \
>>>>>>for i in $$(ls); do \
>>>>>>  echo $${i}_OptionDescriptors >> $@; \
>>>>>>done)
>>>>>> 
>>>>> That seems like a reasonable fix, yes.
>>>> Thanks, but… (see below)
>>>> 
>>>>>> And I see the same behavior for HotSpotJVMCIBackendFactory:
>>>>>> 
>>>>>> $ cat 
>>>>>> build/macosx-x86_64-normal-server-release/jdk/modules/java.base/META-INF/services/jdk.internal.jvmci.hotspot.HotSpotJVMCIBackendFactory
>>>>>> jdk.internal.jvmci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory
>>>>>> jdk.internal.jvmci.hotspot.sparc.SPARCHotSpotJVMCIBackendFactory
>>>>>> jdk.internal.jvmci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory
>>>>>> jdk.internal.jvmci.hotspot.sparc.SPARCHotSpotJVMCIBackendFactory
>>>>>> …
>>>>>> 
>>>>>> So I think a similar fix needs to be applied there.
>>>> …I’ve look at the code that creates this file and it isn’t obvious to me 
>>>> how to fix it.  Any good ideas?
>>> Try this:
>>> ($(CD) $(GENSRC_DIR)/META-INF/jvmci.providers && \
>>> for i in $$($(LS)); do \
>>>   c=$$($(CAT) $$i | $(TR) -d '\n\r'); \
>>> +  $(RM) $(GENSRC_DIR)/META-INF/services/$$c; \
>>>   $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c; \
>>> done)
>>> $(TOUCH) $@
>>> 
>>> I have not tested it but it should work.
>> No, this won’t work.  Both implementations of HotSpotJVMCIBackendFactory 
>> (AMD64HotSpotJVMCIBackendFactory and SPARCHotSpotJVMCIBackendFactory) 
>> contain the same service file name:
>> 
>> jdk.internal.jvmci.hotspot.HotSpotJVMCIBackendFactory
>> 
>> since we need to collect all available factories in one service.
>> 
>>> /Magnus
> 

Re: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

[Christian Thalinger]

> On Oct 19, 2015, at 8:09 AM, Bob Vandette  wrote:
> 
> Here’s the updated set of webrev’s that address two issues:
> 
> 1. Move jni_util.h out of jawt.h
> 2. Christians concern over using a single variable name for Makefile and 
> C/C++ logic.

Thanks.  Looks good to me.

> 
> http://cr.openjdk.java.net/~bobv/8136556/webrev.01 
> 
> http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.01 
> 
> http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.01 
> 
> 
> Bob.
> 
>> On Oct 16, 2015, at 2:28 AM, Alan Bateman > > wrote:
>> 
>> On 15/10/2015 19:07, Bob Vandette wrote:
>>> Please review this JDK 9 enhancement which allows a completely static build 
>>> of the JDK for MacOSX x64 platforms.
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8136556 
>>>  
>>> >> >
>>> 
>>> The change involves:
>>> 
>>> 1. Producing “.a” archives for each native libraries.
>>> 2. Ensuring that all symbols across the JDK native libraries are unique.
>>> 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to 
>>> have the each library name appended per
>>>the JNI specification.
>>> 4. Modifications to the launcher and launcher Makefiles to allow them to be 
>>> linked with the java.base and jdk.jdwp.agent libraries
>>>and function.
>>> 
>>> http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ 
>>>  
>>> >> >
>>> http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ 
>>>  
>>> >> >
>>> http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ 
>>>  
>>> >> >
>>> 
>>> Note: This change does not link every possible static library with the 
>>> launchers.  It is currently limited to
>>> the java.base and jdk.jdwp.agent libraries in order to allow for the TCK 
>>> validation of the base module only.
>>> 
>> I've skimmed through the patches and the DEF_* macros look okay. The only 
>> one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the 
>> JDK then I think the include of jni_util.h needs to move from jawt.h to 
>> jawt.c.
>> 
>> If I read the changes correctly then not loading the 
>> JavaRuntimeSupport.framework on Mac means the locale might not be right, is 
>> that correct? Brent might remember this issue as we've often pondered the 
>> implications of this disappearing in an Mac update.
>> 
>> Will there be continuous or at least regular builds setup so that build 
>> breakages will be reported in a timely manner? It would be easy to change 
>> something that breaks the static library build.
>> 
>> -Alan
> 

RFR (XXS): 8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes

[Christian Thalinger]

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

The reason this “works” for a non-bootcycle build is because a JDK 9 javac 
won't enforce the “hidden packages” rules when running on a non-JDK 9 platform.

diff -r a8a8604f890f make/gensrc/Gensrc-jdk.vm.ci.gmk
--- a/make/gensrc/Gensrc-jdk.vm.ci.gmk  Sat Oct 17 19:40:30 2015 -0400
+++ b/make/gensrc/Gensrc-jdk.vm.ci.gmk  Tue Oct 20 09:57:02 2015 -1000
@@ -77,6 +77,7 @@ PROCESSOR_PATH := $(call PathList, \
$(MKDIR) -p $(@D)
$(eval $(call ListPathsSafely,PROC_SRCS,$(@D)/_gensrc_proc_files))
$(JAVA_SMALL) $(NEW_JAVAC) \
+   -XDignore.symbol.file \
-sourcepath $(SOURCEPATH) \
-implicit:none \
-proc:only \

Re: RFR (XXS): 8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes

[Christian Thalinger]

Thanks, Erik.

> On Oct 20, 2015, at 9:51 PM, Erik Joelsson  wrote:
> 
> Looks good to me.
> 
> /Erik
> 
> On 2015-10-20 22:19, Christian Thalinger wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8139935
>> 
>> The reason this “works” for a non-bootcycle build is because a JDK 9 javac 
>> won't enforce the “hidden packages” rules when running on a non-JDK 9 
>> platform.
>> 
>> diff -r a8a8604f890f make/gensrc/Gensrc-jdk.vm.ci.gmk
>> --- a/make/gensrc/Gensrc-jdk.vm.ci.gmk   Sat Oct 17 19:40:30 2015 -0400
>> +++ b/make/gensrc/Gensrc-jdk.vm.ci.gmk   Tue Oct 20 09:57:02 2015 -1000
>> @@ -77,6 +77,7 @@ PROCESSOR_PATH := $(call PathList, \
>>  $(MKDIR) -p $(@D)
>>  $(eval $(call ListPathsSafely,PROC_SRCS,$(@D)/_gensrc_proc_files))
>>  $(JAVA_SMALL) $(NEW_JAVAC) \
>> +-XDignore.symbol.file \
>>  -sourcepath $(SOURCEPATH) \
>>  -implicit:none \
>>  -proc:only \
>> 
> 

RFR (S): 8140091: remove VMStructs cast_uint64_t workaround for GCC 4.1.1 bug

[Christian Thalinger]

https://bugs.openjdk.java.net/browse/JDK-8140091
http://cr.openjdk.java.net/~twisti/8140091/webrev/

There is a bit more context in JIRA but the bottom line is that we shouldn’t be 
building the JDK with GCC 4.1.1.  We have a workaround in just one place but 
that doesn’t mean the bug doesn’t show up in other places (especially new code).

I’m suggesting to remove the workaround and blacklist this particular GCC 
version.

Re: RFR (S): 8140091: remove VMStructs cast_uint64_t workaround for GCC 4.1.1 bug

[Christian Thalinger]

> On Oct 21, 2015, at 10:57 PM, Erik Joelsson  wrote:
> 
> I think this is ok, but we should make sure to add a check in configure in 
> the hotspot build-infra project.

Yes, we should do that.  I was looking for something like this but couldn’t 
find any code so I went ahead and did it in the HotSpot Makefiles.

Do you want to add a check in configure with this bug or a separate one?

> 
> /Erik
> 
> On 2015-10-21 21:46, Christian Thalinger wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8140091
>> http://cr.openjdk.java.net/~twisti/8140091/webrev/
>> 
>> There is a bit more context in JIRA but the bottom line is that we shouldn’t 
>> be building the JDK with GCC 4.1.1.  We have a workaround in just one place 
>> but that doesn’t mean the bug doesn’t show up in other places (especially 
>> new code).
>> 
>> I’m suggesting to remove the workaround and blacklist this particular GCC 
>> version.
> 

Re: RFR [XS] - 8139026 hotspot.script cannot handle command-line arguments with spaces

[Christian Thalinger]

> On Oct 25, 2015, at 10:34 PM, Ioi Lam  wrote:
> 
> Please review a very small fix:
> 
> http://cr.openjdk.java.net/~iklam/8139026-hotspot-script-arg-quoating/

Looks good.  I’m sure you asked, who is still using this script?

> 
> Bug: hotspot/make/hotspot.script cannot handle command-line arguments with 
> spaces
> 
> https://bugs.openjdk.java.net/browse/JDK-8139026
> 
> Summary of fix:
> 
>   The old script was adding $@ to a string like X="A B $@ C". Doing that would
>   lose the quotation on the arguments. This would cause JTREG to fail when 
> running
>   with Jigsaw modules (see bug report for details).
> 
>   The fix is to pass "$@" directly as arguments to all programs launched by
>   hotspot.script
> 
>   Note that the fix does not address the problem with DBX, but at least it's 
> no worse
>   than before.
> 
> Tests:
> 
>I have used the modified version for the past 2 weeks with GDB and JTREG 
> and found
>no issues.
> 
>Also, casual testing shows the quotation is retained:
> 
>$ hotspot 'a a'
>Error: Could not find or load main class a a
>$ hotspot "a' a"
>Error: Could not find or load main class a' a
>$ hotspot "a\"' a"
>Error: Could not find or load main class a"' a
> 
> Thanks
> - Ioi

Re: RFR(XS): 8141416: "expr: syntax error" due to gcc -dumpversion excluding micro

[Christian Thalinger]

> On Nov 4, 2015, at 8:21 AM, Volker Simonis  wrote:
> 
> Hi,
> 
> can somebody please review and sponsor the following tiny build fix:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8141416/
> https://bugs.openjdk.java.net/browse/JDK-8141416
> 
> Building hotspot on certain systems results in a series of:
> expr: syntax error
> expr: syntax error
> expr: syntax error
> expr: syntax error
> 
> It is caused by a peculiarity of the gcc version on Ubuntu where "gcc
> -dumpversion" doesn't print a micro-version:
> 
> Ubuntu:
> $ gcc -dumpversion
> 4.6
> 
> Any other Linux:
> $ gcc -dumpversion
> 4.8.3
> 
> This "feature" is tracked under
> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404 and has
> been fixed for gcc 4.9 but won't be fixed for older versions of gcc.
> 
> In hotspot/make/linux/makefiles/gcc.make we parse the micro-version of
> gcc and use it in the following way:
> 
> CC_VER_MICRO := $(shell $(CC) -dumpversion | sed 's/egcs-//' | cut -d'.' -f3)

I’ve added this.  Thanks for fixing it.

> 
> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 1 \&
> $(CC_VER_MICRO) = 1), 1)
>  $(error "GCC $(CC_VER_MAJOR).$(CC_VER_MINOR).$(CC_VER_MICRO) not
> supported because of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724";)
> endif
> 
> The shell expression results in a syntax error if $(CC_VER_MICRO)
> because it expands to something like "expr 4 = 4 & 3 = 1 & = 1"
> 
> Thank you and best regards,
> Volker

Re: RFR: JDK-8151656: Minor tweaks to old Hotspot build to ease comparison with new

[Christian Thalinger]

> On Mar 15, 2016, at 12:06 AM, Erik Joelsson  wrote:
> 
> Any chance I could get a second review on this? Preferably from the hotspot 
> team.

It’s not quite obvious to me what the __FILE__ change is.  Maybe an example 
would help.

> 
> /Erik
> 
> On 2016-03-11 18:16, Erik Joelsson wrote:
>> In preparation for the new Hotspot build, there are a few changes to the old 
>> build that needs to happen first. These changes should be harmless, but do 
>> impact the generated binaries some. These changes are:
>> 
>> * Standardizing sort order for objects on link command line on Windows to a 
>> locale independent order.
>> * Working around compare differences caused by the __FILE__ macro in certain 
>> generated files by overriding the value of __FILE__ in those files.
>> 
>> By making these changes first and separate from introducing the new build we 
>> reduce the potential impact of when we do introduce the new build.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151656
>> Webrev: http://cr.openjdk.java.net/~erikj/8151656/index.html
>> 
>> /Erik
> 

Re: RFR: JDK-8151656: Minor tweaks to old Hotspot build to ease comparison with new

[Christian Thalinger]

> On Mar 15, 2016, at 10:51 PM, Erik Joelsson  wrote:
> 
> The __FILE__ macro is built into the compiler and evaluates to the file name 
> of the current source file. It's intended use is for debug messages. In the 
> rest of the JDK we eliminated its use completely by providing a macro called 
> THIS_FILE that evaluates to the basename.ext of the source file being 
> compiled. In Hotspot it's still used and it's used in header files, which 
> makes the THIS_FILE solution invalid.
> 
> For most of our compilers, the format of the path is based on how the file 
> was presented on the command line. This matters to us since the old Hotspot 
> build uses relative paths to the generated source and header files and the 
> new build uses absolute paths for all source files. Also, the directory 
> structure in the output directory differ. This means that for certain object 
> files, the constant strings resulting from the use of __FILE__ differ, both 
> in contents and length. The difference in length causes alignment differences 
> in the objects and the resulting libraries.

This is actually a very good point.  Alignment differences can cause 
performance differences.  Sometimes hard to track down and almost impossible to 
reproduce.

> 
> When creating the new build, we are trying very hard to make sure we are 
> still building the same thing. One way to verify this is to compare various 
> aspects of the built binaries. When possible, this is far easier than running 
> a very large amount of tests and it gives us a large amount of confidence in 
> our changes. The alignment differences caused by different lengths of 
> constant strings severely limits the amount of clean comparisons we can do.
> 
> The particular fix here changes how we generate the files from the ADLC tool. 
> The tool already generates #line directives which helps the compiler figure 
> out which actual source file and line parts of the generated files came from. 
> Basically overriding what __FILE__ and __LINE__ will evaluate to. Some of 
> these lines need a bit of post processing, and for that, the build already 
> uses awk to rewrite them. The current awk script looks for lines like this, 
> which the ADLC tool prints when it doesn't know the correct source file:
> 
> #line 99
> 
> and rewrites it to
> 
> #line   file>
> 
> I changed this to instead rewrite to:
> 
> #line  

You removed the +1.  Why was it used in the first place?

> 
> I also added an initial #line first in each file.
> 
> #line 1 
> 
> With these changes, we can do very clean comparisons on Linux, Solaris and 
> Macosx. This helps the new hotspot build immensely, but will also be good in 
> the future as we have a very convenient way of verifying build changes that 
> shouldn't affect the built output.

Now this all makes sense.  Thanks.  The change looks good to me.

> 
> /Erik
> 
> On 2016-03-15 22:02, Christian Thalinger wrote:
>>> On Mar 15, 2016, at 12:06 AM, Erik Joelsson  
>>> wrote:
>>> 
>>> Any chance I could get a second review on this? Preferably from the hotspot 
>>> team.
>> It’s not quite obvious to me what the __FILE__ change is.  Maybe an example 
>> would help.
>> 
>>> /Erik
>>> 
>>> On 2016-03-11 18:16, Erik Joelsson wrote:
>>>> In preparation for the new Hotspot build, there are a few changes to the 
>>>> old build that needs to happen first. These changes should be harmless, 
>>>> but do impact the generated binaries some. These changes are:
>>>> 
>>>> * Standardizing sort order for objects on link command line on Windows to 
>>>> a locale independent order.
>>>> * Working around compare differences caused by the __FILE__ macro in 
>>>> certain generated files by overriding the value of __FILE__ in those files.
>>>> 
>>>> By making these changes first and separate from introducing the new build 
>>>> we reduce the potential impact of when we do introduce the new build.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151656
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8151656/index.html
>>>> 
>>>> /Erik
> 

Re: RFR: JDK-8152666: The new Hotspot Build System

[Christian Thalinger]

> On Apr 5, 2016, at 8:10 AM, Daniel D. Daugherty  
> wrote:

…

> make/Main.gmk
>No comments other than the 'hotspot-ide-project' target
>looks interesting...

Btw. there is already support to generate IDE configurations today via mx:

https://wiki.openjdk.java.net/display/Graal/Instructions

integrated with:

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

One main advantage, as I pointed out in the review, is that it also includes 
generated files so there are no unresolved includes or methods anymore:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-November/020626.html

I’m using this every day.

Re: RFR: JDK-8152666: The new Hotspot Build System

[Christian Thalinger]

> On Apr 5, 2016, at 11:14 PM, Erik Joelsson  wrote:
> 
> Hello,
> 
> I assume the mx projects are for Java code or do they also generate projects 
> for native?

Also native.  Look at the screenshots I posted.  Particularly this one:

http://cr.openjdk.java.net/~twisti/8139921/Screen%20Shot%202015-11-10%20at%202.18.20%20PM.png
 
<http://cr.openjdk.java.net/~twisti/8139921/Screen%20Shot%202015-11-10%20at%202.18.20%20PM.png>

> The new top level target is only meant to replace the old Visual Studio 
> project generator, at least for now.
> 
> /Erik
> 
> On 2016-04-06 03:23, Christian Thalinger wrote:
>> 
>>> On Apr 5, 2016, at 8:10 AM, Daniel D. Daugherty 
>>> mailto:daniel.daughe...@oracle.com>> wrote:
>> 
>> …
>> 
>>> make/Main.gmk
>>>No comments other than the 'hotspot-ide-project' target
>>>looks interesting...
>> 
>> Btw. there is already support to generate IDE configurations today via mx:
>> 
>> https://wiki.openjdk.java.net/display/Graal/Instructions 
>> <https://wiki.openjdk.java.net/display/Graal/Instructions>
>> 
>> integrated with:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8139921 
>> <https://bugs.openjdk.java.net/browse/JDK-8139921>
>> 
>> One main advantage, as I pointed out in the review, is that it also includes 
>> generated files so there are no unresolved includes or methods anymore:
>> 
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-November/020626.html 
>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-November/020626.html>
>> 
>> I’m using this every day.
> 

Re: RFR(S): 8154209: Remove client VM from default JIB profile on windows-x86 and linux-x86

[Christian Thalinger]

> On Apr 14, 2016, at 6:41 AM, Mikael Vidstedt  
> wrote:
> 
> 
> Please review the following change which removes the "client" VM from the 
> default JIB build profile

Is there some public documentation about JIB?  A quick search only showed a few 
JBS bugs that mention JIB.

> on windows-x86 and linux-x86:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8154209
> Webrev (top): http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.01/
> Webrev (hotspot): 
> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.01/hotspot/webrev/
> 
> 
> When not including the client VM, the build system automatically creates a 
> jvm.cfg which makes -client an alias for -server. At some point in the future 
> we may choose to output a warning and/or refuse to start up if -client is 
> specified, but at least for now silently falling back on the -server VM seems 
> appropriate.
> 
> The test/runtime/SharedArchiveFile/DefaultUseWithClient.java test assumes 
> that CDS is always compiled in and enabled in the -client VM on windows-x86. 
> Since -client will fall back on -server that is no longer true, so the test 
> needs to be updated. I added an @ignore and filed the following issue to 
> track fixing the test:
> 
> https://bugs.openjdk.java.net/browse/JDK-8154204
> 
> 
> Testing:
> 
> In addition to a standard JPRT push job, Christian Tornqvist helped me run 
> the runtime nightly tests and apart from the above mentioned test all tests 
> were successful.
> 
> Cheers,
> Mikael
> 

Re: [9] RFR (xs) 8168317: [JVMCI] use reflection instead of jdk 9 Module API in Services.java

[Christian Thalinger]

> On Oct 24, 2016, at 3:48 AM, Erik Joelsson  wrote:
> 
> Adding build-dev, which should be included when discussing build issues. For 
> any new readers, please see [1] for the full discussion.
> In theory it is possible to compile against and run on the exploded image 
> during the build, but I do not recommend it. Igor is correct in the build 
> team being against that design. The rationale is that it adds a lot of 
> complexity to the build. The exploded image cannot be safely run until all 
> java modules have been compiled as it introduces races. Maintaining the build 
> with such a construct will be very brittle when other changes are made. We 
> did allow the gensrc for jdk.vm.ci to run in this way for a short time, since 
> it was only supported on Linux x64, where these races are rarer, but if this 
> would ever need to be built on Windows, we would be in trouble quickly. 
> Luckily, jdk.vm.ci was able to refactor away from needing this annotation 
> processing for that module. 
> I certainly prefer the reflection solution proposed here, but find it sad 
> that it's needed. 
> 

The problem I have with this solution is that jdk.vm.ci code is now restricted 
to JDK N-1 code.  This might be ok right now because we are able to work around 
that issue with reflection but when important features like Valhalla come 
around this is a problem.

Value types will be hugely important for JVMCI and its compilers and we simply 
cannot just skip one JDK release just because the build system can’t handle it.

> /Erik
> 
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-October/024743.html
>  
> <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-October/024743.html>
> 
> On 2016-10-19 21:54, Igor Veresov wrote:
>> 
>>> On Oct 19, 2016, at 12:47 PM, Christian Thalinger >> <mailto:cthalin...@twitter.com>> wrote:
>>> 
>>> 
>>>> On Oct 19, 2016, at 9:40 AM, Vladimir Kozlov >>> <mailto:vladimir.koz...@oracle.com>> wrote:
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8168317 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8168317>
>>>> 
>>>> webrev:
>>>> http://cr.openjdk.java.net/~kvn/8168317/webrev/ 
>>>> <http://cr.openjdk.java.net/%7Ekvn/8168317/webrev/>
>>>> 
>>>> When Graal is built as part of JDK it requires first to build an 
>>>> annotation processor using boot jdk 8.
>>>> After JDK-8167180 changes Services class is referenced by annotation 
>>>> processor but the code is using jdk 9 Module API and it can't be used with 
>>>> jdk 8.
>>> 
>>> I left a comment in the bug: Permalink 
>>> <https://bugs.openjdk.java.net/browse/JDK-8168317?focusedCommentId=14013733&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14013733>
>>> 
>>> Basically, it should be possible to use the newly built javac to compile 
>>> the annotation processors.  Erik?
>> 
>> It’s not only about compilation it’s about running it on the bootstrap JDK, 
>> which in currently 8.
>> 
>> igor
>> 
>>> 
>>> Can you paste or upload the .gmk file?
>>> 
>>>> 
>>>> Use reflection instead of Module API and use code only for running with 
>>>> jdk 9.
>>>> 
>>>> Testing with JPRT and JDK build of Graal.
>>>> 
>>>> Thanks,
>>>> Vladimir
>>> 
>> 
> 

Re: [9] RFR (xs) 8168317: [JVMCI] use reflection instead of jdk 9 Module API in Services.java

[Christian Thalinger]

> On Oct 24, 2016, at 9:01 PM, Doug Simon  wrote:
> 
>> 
>> On 24 Oct 2016, at 23:24, Christian Thalinger  wrote:
>> 
>> 
>>> On Oct 24, 2016, at 3:48 AM, Erik Joelsson  wrote:
>>> 
>>> Adding build-dev, which should be included when discussing build issues. 
>>> For any new readers, please see [1] for the full discussion.
>>> In theory it is possible to compile against and run on the exploded image 
>>> during the build, but I do not recommend it. Igor is correct in the build 
>>> team being against that design. The rationale is that it adds a lot of 
>>> complexity to the build. The exploded image cannot be safely run until all 
>>> java modules have been compiled as it introduces races. Maintaining the 
>>> build with such a construct will be very brittle when other changes are 
>>> made. We did allow the gensrc for jdk.vm.ci to run in this way for a short 
>>> time, since it was only supported on Linux x64, where these races are 
>>> rarer, but if this would ever need to be built on Windows, we would be in 
>>> trouble quickly. Luckily, jdk.vm.ci was able to refactor away from needing 
>>> this annotation processing for that module. 
>>> I certainly prefer the reflection solution proposed here, but find it sad 
>>> that it's needed. 
>>> 
>> 
>> The problem I have with this solution is that jdk.vm.ci code is now 
>> restricted to JDK N-1 code.  This might be ok right now because we are able 
>> to work around that issue with reflection but when important features like 
>> Valhalla come around this is a problem.
>> 
>> Value types will be hugely important for JVMCI and its compilers and we 
>> simply cannot just skip one JDK release just because the build system can’t 
>> handle it.
> 
> I agree. However, I suspect large parts of the JDK will also want to leverage 
> Valhalla so I’m guessing the build problem will have to be solved anyway at 
> some point.

Not necessarily.  Java modules can and are using Java features of JDK N because 
they are compiled with a “new javac” that gets compiled before any Java modules 
are compiled:

# The generate old bytecode javac setup uses the new compiler to compile for the
# boot jdk to generate tools that need to be run with the boot jdk.
# Thus we force the target bytecode to the previous JDK version.
# Add -Xlint:-options to avoid the warning about not setting -bootclasspath. 
Since
# it's running on the boot jdk, the default bootclasspath is correct.
$(eval $(call SetupJavaCompiler,GENERATE_OLDBYTECODE, \

# The generate new bytecode javac setup uses the new compiler to compile for the
# new jdk. This new bytecode might only be possible to run using the new jvm.
$(eval $(call SetupJavaCompiler,GENERATE_JDKBYTECODE, \

So this will just work as it does already today.  Annotation processors need to 
be handled differently because their code is actually executed.

> Maybe it worth filing a tracking bug to revert these changes at that time.
> 
> -Doug
> 
>> 
>>> 
>>> /Erik
>>> 
>>> [1] 
>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-October/024743.html
>>> 
>>> On 2016-10-19 21:54, Igor Veresov wrote:
>>>> 
>>>>> On Oct 19, 2016, at 12:47 PM, Christian Thalinger 
>>>>>  wrote:
>>>>> 
>>>>> 
>>>>>> On Oct 19, 2016, at 9:40 AM, Vladimir Kozlov 
>>>>>>  wrote:
>>>>>> 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8168317
>>>>>> 
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~kvn/8168317/webrev/
>>>>>> 
>>>>>> When Graal is built as part of JDK it requires first to build an 
>>>>>> annotation processor using boot jdk 8.
>>>>>> After JDK-8167180 changes Services class is referenced by annotation 
>>>>>> processor but the code is using jdk 9 Module API and it can't be used 
>>>>>> with jdk 8.
>>>>> 
>>>>> I left a comment in the bug: Permalink
>>>>> 
>>>>> Basically, it should be possible to use the newly built javac to compile 
>>>>> the annotation processors.  Erik?
>>>> 
>>>> It’s not only about compilation it’s about running it on the bootstrap 
>>>> JDK, which in currently 8.
>>>> 
>>>> igor
>>>> 
>>>>> 
>>>>> Can you paste or upload the .gmk file?
>>>>> 
>>>>>> 
>>>>>> Use reflection instead of Module API and use code only for running with 
>>>>>> jdk 9.
>>>>>> 
>>>>>> Testing with JPRT and JDK build of Graal.
>>>>>> 
>>>>>> Thanks,
>>>>>> Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

[Christian Thalinger]

> On Oct 27, 2016, at 2:40 AM, Erik Joelsson  wrote:
> 
> 
> 
> On 2016-10-27 02:45, Vladimir Kozlov wrote:
>> AOT JEP:
>> https://bugs.openjdk.java.net/browse/JDK-8166089
>> Subtask:
>> https://bugs.openjdk.java.net/browse/JDK-8166416
>> Webrev:
>> http://cr.openjdk.java.net/~kvn/aot/top.webrev/
> hotspot.m4: 296: Comment is misleading. Should just be removed.
> 
> CompileJavaModules.gmk: Use of -g flag for java compilation is controlled 
> globally. Please remove.

There is a reason for that.  Some debugging related Graal code makes use of 
classfile information to provide better information.  Since this is Java and 
not C++ it *is* possible to have pleasant debugging experience even in product 
builds.  I want this to be there.

> 
> Main.gmk: buildtools-hotspot should be declared inside the CREATING_BUILDJDK 
> conditional like all other buildtools targets.
> 
>> http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
> The extra exports from java.base needs to go in a new 
> jdk/src/java.base/share/classes/module-info.java.extra since the module 
> jdk.vm.compiler is optional.
>> http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
> Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) to 
> LIBS since that will provide -lc on Solaris automatically. No need to set 
> DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct and 
> controlled globally.
> 
> /Erik
>> 
>> Please, review build changes for AOT.  Only Linux/x64 platform is supported. 
>> 'jaotc' and AOT part of Hotspot will be build only on Linux/x64.
>> 
>> Changes include new 'jaotc' launcher, makefile changes to build 
>> jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
>> Both modules sources are located in Hotspot: hotspot/src/jdk.aot and 
>> hotspot/src/jdk.vm.compiler.
>> 'jaotc' requires installed libelf package on a system to build native part 
>> of 'jaotc'. It is used to generated AOT shared libraries (.so) as result of 
>> AOT compilation.
>> 
>> Hotspot makefile changes will be pushed together with Hotspot AOT changes.
>> 
>> Thanks,
>> Vladimir
> 

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

[Christian Thalinger]

> On Oct 27, 2016, at 8:12 AM, Vladimir Kozlov  
> wrote:
> 
> On 10/27/16 10:55 AM, Christian Thalinger wrote:
>> 
>>> On Oct 27, 2016, at 2:40 AM, Erik Joelsson  wrote:
>>> 
>>> 
>>> 
>>> On 2016-10-27 02:45, Vladimir Kozlov wrote:
>>>> AOT JEP:
>>>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>>> Subtask:
>>>> https://bugs.openjdk.java.net/browse/JDK-8166416
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~kvn/aot/top.webrev/
>>> hotspot.m4: 296: Comment is misleading. Should just be removed.
>>> 
>>> CompileJavaModules.gmk: Use of -g flag for java compilation is controlled 
>>> globally. Please remove.
>> 
>> There is a reason for that.  Some debugging related Graal code makes use of 
>> classfile information to provide better information.  Since this is Java and 
>> not C++ it *is* possible to have pleasant debugging experience even in 
>> product builds.  I want this to be there.
> 
> Chris, do we need -g for JVMCI module too for that?

Yes.

> 
> And do we need -Xlint:-exports for jdk.vm.compiler (Graal)? FOR JVMCI it was 
> added by:
> 
> http://hg.openjdk.java.net/jdk9/hs/rev/81435a812f59 
> <http://hg.openjdk.java.net/jdk9/hs/rev/81435a812f59>

I can’t remember what the reason for -Xlint was but… wait.  That was added 3 
weeks ago.  No clue then.

> 
> Thanks,
> Vladimir
> 
>> 
>>> 
>>> Main.gmk: buildtools-hotspot should be declared inside the 
>>> CREATING_BUILDJDK conditional like all other buildtools targets.
>>> 
>>>> http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
>>> The extra exports from java.base needs to go in a new 
>>> jdk/src/java.base/share/classes/module-info.java.extra since the module 
>>> jdk.vm.compiler is optional.
>>>> http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
>>> Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) to 
>>> LIBS since that will provide -lc on Solaris automatically. No need to set 
>>> DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct and 
>>> controlled globally.
>>> 
>>> /Erik
>>>> 
>>>> Please, review build changes for AOT.  Only Linux/x64 platform is 
>>>> supported. 'jaotc' and AOT part of Hotspot will be build only on Linux/x64.
>>>> 
>>>> Changes include new 'jaotc' launcher, makefile changes to build 
>>>> jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
>>>> Both modules sources are located in Hotspot: hotspot/src/jdk.aot and 
>>>> hotspot/src/jdk.vm.compiler.
>>>> 'jaotc' requires installed libelf package on a system to build native part 
>>>> of 'jaotc'. It is used to generated AOT shared libraries (.so) as result 
>>>> of AOT compilation.
>>>> 
>>>> Hotspot makefile changes will be pushed together with Hotspot AOT changes.
>>>> 
>>>> Thanks,
>>>> Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

[Christian Thalinger]

> On Oct 28, 2016, at 11:23 AM, Mandy Chung  wrote:
> 
>> 
>> On Oct 28, 2016, at 1:52 PM, Vladimir Kozlov  
>> wrote:
>> 
>> Thank you, Mandy
>> 
>> On 10/28/16 1:31 PM, Mandy Chung wrote:
>>> 
 On Oct 26, 2016, at 5:45 PM, Vladimir Kozlov  
 wrote:
 
 http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
>>> 
>>> make/gensrc/Gensrc-jdk.vm.compiler.gmk
>>>  This generates module-info.java.extra at build time to augment 
>>> module-info.java with `uses` and `provides`. module-info.java.extra is 
>>> expected to be checked in the source.
>>> 
>>>  Do you expect the list of `uses` and `provides` are often changed?
>> 
>> Yes, Graal code changes frequently and  we need to run annotation processor 
>> to generate these dependencies for each jdk.vm.compiler (Graal) module build.
>> 
> 
> When the OptionDescriptors list is changed, we can run the tool (you can add 
> a make target if it helps) to generate the list of `uses` and `provides`.  
> Then update module-info.java in the source together with the changes.  That 
> would work too, right?

Why can’t we have it generated?  It’s much more convenient and less maintenance 
overhead.  There needs to be a good reason to give this up.

> 
>>> The alternative is to declare `uses` and `provides` in module-info.java in 
>>> the source repo so that a reader can see the module descriptor content 
>>> without needing to do a build.  A test to detect if the module-info.java is 
>>> out-of-sync with the annotated options.  In addition a make target to 
>>> generate the list of `use` and `provides` can be used to generate 
>>> module-info.java to be included in any change in the annotated options list.
>> 
>> What is "a reader”?
> 
> A person reading the code.
> 
>> And how to check "out-of-sync" without running 'processor’?
> 
> I meant a regression test that will run the annotation processor and compare 
> with module-info.class in the image (using java.lang.module.ModuleDescriptor 
> API)
> 
> Mandy
> 
>> Sorry, I am not familiar with all this modules build process.
>> 
>> Thanks,
>> Vladimir
>> 
>>> 
>>> Mandy

Re: RFR: JDK-8172670: AOT Platform Support for Windows and Mac OS X x64 (Linux and Solaris too)

[Christian Thalinger]

This is amazing!  Awesome work.  I’m glad this got done so soon.

> On Feb 8, 2017, at 9:29 AM, Bob Vandette  wrote:
> 
> SUMMARY:
> 
> Please review the following set of changes that adds Ahead-of-time 
> compilation support for Mac OSX and 
> Windows x64 in JDK 10.  Linux and Solaris x64 AOT support has also been 
> updated to be consistent with 
> the new 100% Java based binary container support included in this changeset.
> 
> This change also removes the build and runtime dependency on the external 
> libelf library and header files.
> 
> Once this change is integrated Ahead of time support will be available for 
> the following set of Platforms:
> 
> - Linux x64
> - Windows x64
> - MacOSX x64
> - Solaris x64
> 
> RFE:
> 
> https://bugs.openjdk.java.net/browse/JDK-8172670 
> 
> 
> WEBREVS:
> 
> TOP LEVEL
> —
> 
> http://cr.openjdk.java.net/~bobv/8172670/webrev.01/
> 
> JDK
> ——
> 
> http://cr.openjdk.java.net/~bobv/8172670/jdk/webrev.01/
> 
> HOTSPOT
> —
> 
> Full Hotspot Webrev:
> http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev.01/ 
> 
> 
> 
> If you’d prefer to review things in smaller chunks, here are the hotspot 
> changes for Linux and
> Solaris including the libelf removal:
> http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-linux.01/ 
> 
> 
> Files added to support Mac OSX:
> http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-mac.01/ 
> 
> 
> Files added to provide Windows support:
> http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-win.01/ 
> 
> 
> Changes to the jtreg tests for AOT:
> http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-test.01/ 
> 
> 
> 
> TESTING:
> 
> 1. JPRT has been run and passes with these changes
> 2. jtreg AOT tests pass on all supported platforms
> 3. AOT compiling of java.base completes and can run basic Java programs on 
> all supported platforms
> 
> NOTE:
> 
> 1. Although these test run correctly on Windows, jtreg AOT tests have been 
> temporarily disabled for this platform.
> This is due to an internal JPRT system configuration issue which will 
> hopefully get resolved soon.  AOT requires 
> access to a local toolchain and our JPRT systems do not regularly install 
> Visual Studio.
> 
> 
> Thanks,
> Bob.

Re: What to pass to --with-custom-make-dir?

[Christian Thalinger]

> On Mar 3, 2017, at 4:09 PM, David Holmes  wrote:
> 
> Hi Christian,
> 
> I think you need to pass an absolute directory, in which all the custom 
> files, regardless of repo, are located. That is essentially how we use it - 
> jdk/make/closed has files included from other repos. Of course that only 
> works if names are unique.

Absolute directory to where?  Is 
$(CUSTOM_MAKE_DIR)/lib/ServiceabilityLibraries.gmk not under jdk/make/closed?

> 
> David
> 
> On 4/03/2017 9:11 AM, Rob McKenna wrote:
>> Hi Christian,
>> 
>> I'm cc'ing build-dev (and bcc'ing jdk8u-dev) as that may be a more 
>> appropriate
>> venue for this discussion.
>> 
>>-Rob
>> 
>> On 03/03/17 10:19, Christian Thalinger wrote:
>>> At Twitter we are using the custom extension mechanism to separate our 
>>> additional code from upstream in order to minimize conflicts.  Yesterday I 
>>> wanted to add a custom extension for:
>>> 
>>> jdk/make/lib/ServiceabilityLibraries.gmk
>>> 
>>> which has this include directive:
>>> 
>>> # Include custom extensions if available.
>>> -include $(CUSTOM_MAKE_DIR)/lib/ServiceabilityLibraries.gmk
>>> 
>>> We are already using the mechanism for top-level make files, e.g. 
>>> make/Main.gmk:
>>> 
>>> # Include the corresponding custom file, if present.
>>> -include $(CUSTOM_MAKE_DIR)/Main.gmk
>>> 
>>> and we a configuring with:
>>> 
>>> --with-custom-make-dir=make/closed
>>> 
>>> This works fine for make/ but not for jdk/make/:
>>> 
>>> $ make jdk CUSTOM_MAKE_DIR=make/closed
>>> …
>>> 
>>> ## Starting jdk
>>> lib/ServiceabilityLibraries.gmk:27: 
>>> make/closed/lib/ServiceabilityLibraries.gmk: No such file or directory
>>> make[2]: *** No rule to make target 
>>> `make/closed/lib/ServiceabilityLibraries.gmk'.  Stop.
>>> make[1]: *** [libs-only] Error 2
>>> make: *** [jdk-only] Error 2
>>> 
>>> (I changed "-include" to “include” to provoke the error.)
>>> 
>>> jdk/make/ files expect CUSTOM_MAKE_DIR to be just “closed” but that doesn’t 
>>> work for top-level:
>>> 
>>> $ make jdk CUSTOM_MAKE_DIR=closed
>>> /Users/cthalinger/twitter8//make/Main.gmk:35: closed/Main.gmk: No such file 
>>> or directory
>>> make: *** No rule to make target `closed/Main.gmk'.  Stop.
>>> 
>>> How is this supposed to work?

Re: What to pass to --with-custom-make-dir?

[Christian Thalinger]

> On Mar 6, 2017, at 8:51 AM, Christian Thalinger  
> wrote:
> 
> 
>> On Mar 3, 2017, at 4:09 PM, David Holmes  wrote:
>> 
>> Hi Christian,
>> 
>> I think you need to pass an absolute directory, in which all the custom 
>> files, regardless of repo, are located. That is essentially how we use it - 
>> jdk/make/closed has files included from other repos. Of course that only 
>> works if names are unique.
> 
> Absolute directory to where?  Is 
> $(CUSTOM_MAKE_DIR)/lib/ServiceabilityLibraries.gmk not under jdk/make/closed?

After reading your message a couple of times :-) I got it.  Basically pass 
/repo/make/closed and have all files there.

But why?  That doesn’t make any sense since there is a jdk/make/closed 
directory.

> 
>> 
>> David
>> 
>> On 4/03/2017 9:11 AM, Rob McKenna wrote:
>>> Hi Christian,
>>> 
>>> I'm cc'ing build-dev (and bcc'ing jdk8u-dev) as that may be a more 
>>> appropriate
>>> venue for this discussion.
>>> 
>>>   -Rob
>>> 
>>> On 03/03/17 10:19, Christian Thalinger wrote:
>>>> At Twitter we are using the custom extension mechanism to separate our 
>>>> additional code from upstream in order to minimize conflicts.  Yesterday I 
>>>> wanted to add a custom extension for:
>>>> 
>>>> jdk/make/lib/ServiceabilityLibraries.gmk
>>>> 
>>>> which has this include directive:
>>>> 
>>>> # Include custom extensions if available.
>>>> -include $(CUSTOM_MAKE_DIR)/lib/ServiceabilityLibraries.gmk
>>>> 
>>>> We are already using the mechanism for top-level make files, e.g. 
>>>> make/Main.gmk:
>>>> 
>>>> # Include the corresponding custom file, if present.
>>>> -include $(CUSTOM_MAKE_DIR)/Main.gmk
>>>> 
>>>> and we a configuring with:
>>>> 
>>>> --with-custom-make-dir=make/closed
>>>> 
>>>> This works fine for make/ but not for jdk/make/:
>>>> 
>>>> $ make jdk CUSTOM_MAKE_DIR=make/closed
>>>> …
>>>> 
>>>> ## Starting jdk
>>>> lib/ServiceabilityLibraries.gmk:27: 
>>>> make/closed/lib/ServiceabilityLibraries.gmk: No such file or directory
>>>> make[2]: *** No rule to make target 
>>>> `make/closed/lib/ServiceabilityLibraries.gmk'.  Stop.
>>>> make[1]: *** [libs-only] Error 2
>>>> make: *** [jdk-only] Error 2
>>>> 
>>>> (I changed "-include" to “include” to provoke the error.)
>>>> 
>>>> jdk/make/ files expect CUSTOM_MAKE_DIR to be just “closed” but that 
>>>> doesn’t work for top-level:
>>>> 
>>>> $ make jdk CUSTOM_MAKE_DIR=closed
>>>> /Users/cthalinger/twitter8//make/Main.gmk:35: closed/Main.gmk: No such 
>>>> file or directory
>>>> make: *** No rule to make target `closed/Main.gmk'.  Stop.
>>>> 
>>>> How is this supposed to work?
> 

Re: What to pass to --with-custom-make-dir?

[Christian Thalinger]

> On Mar 6, 2017, at 10:17 PM, Erik Joelsson  wrote:
> 
> 
> 
> On 2017-03-07 03:22, David Holmes wrote:
>> On 7/03/2017 6:32 AM, Christian Thalinger wrote:
>>> 
>>>> On Mar 6, 2017, at 8:51 AM, Christian Thalinger  
>>>> wrote:
>>>> 
>>>> 
>>>>> On Mar 3, 2017, at 4:09 PM, David Holmes  wrote:
>>>>> 
>>>>> Hi Christian,
>>>>> 
>>>>> I think you need to pass an absolute directory, in which all the custom 
>>>>> files, regardless of repo, are located. That is essentially how we use it 
>>>>> - jdk/make/closed has files included from other repos. Of course that 
>>>>> only works if names are unique.
>>>> 
>>>> Absolute directory to where?  Is 
>>>> $(CUSTOM_MAKE_DIR)/lib/ServiceabilityLibraries.gmk not under 
>>>> jdk/make/closed?
>>> 
>>> After reading your message a couple of times :-) I got it. Basically pass 
>>> /repo/make/closed and have all files there.
>> 
>> It has to be an absolute directory somewhere, not relative to whatever the 
>> current make command is executing. So it could be /repo/jdk/make/closed if 
>> you wanted it to be.
>> 
>>> But why?  That doesn’t make any sense since there is a jdk/make/closed 
>>> directory.
>> 
>> IIRC this was initially a mechanism for customizing jdk/make files, then 
>> another part of the forest also wanted a "closed" custom file and so it was 
>> "enhanced" to allow that. In 9 of course this is all handled completely 
>> differently now.
>> 
> Since we didn't have a top level closed repository in JDK8, we put all common 
> closed makefiles (and autoconf) in jdk/make/closed. This is why the custom 
> makefile includes all point to the same dir in 8u.

Ahh!  That explains the behavior in 8.  I thought there was a closed repository 
in top.  Thanks.

> 
> In JDK 9 we added a top level closed repository and created a macro to handle 
> the includes so that any closed implementor may define that macro as they 
> like and consequently, put their closed additions in any structure they like.

Yes, much better.

> 
> /Erik
>> David
>> 
>>>> 
>>>>> 
>>>>> David
>>>>> 
>>>>> On 4/03/2017 9:11 AM, Rob McKenna wrote:
>>>>>> Hi Christian,
>>>>>> 
>>>>>> I'm cc'ing build-dev (and bcc'ing jdk8u-dev) as that may be a more 
>>>>>> appropriate
>>>>>> venue for this discussion.
>>>>>> 
>>>>>>  -Rob
>>>>>> 
>>>>>> On 03/03/17 10:19, Christian Thalinger wrote:
>>>>>>> At Twitter we are using the custom extension mechanism to separate our 
>>>>>>> additional code from upstream in order to minimize conflicts.  
>>>>>>> Yesterday I wanted to add a custom extension for:
>>>>>>> 
>>>>>>> jdk/make/lib/ServiceabilityLibraries.gmk
>>>>>>> 
>>>>>>> which has this include directive:
>>>>>>> 
>>>>>>> # Include custom extensions if available.
>>>>>>> -include $(CUSTOM_MAKE_DIR)/lib/ServiceabilityLibraries.gmk
>>>>>>> 
>>>>>>> We are already using the mechanism for top-level make files, e.g. 
>>>>>>> make/Main.gmk:
>>>>>>> 
>>>>>>> # Include the corresponding custom file, if present.
>>>>>>> -include $(CUSTOM_MAKE_DIR)/Main.gmk
>>>>>>> 
>>>>>>> and we a configuring with:
>>>>>>> 
>>>>>>> --with-custom-make-dir=make/closed
>>>>>>> 
>>>>>>> This works fine for make/ but not for jdk/make/:
>>>>>>> 
>>>>>>> $ make jdk CUSTOM_MAKE_DIR=make/closed
>>>>>>> …
>>>>>>> 
>>>>>>> ## Starting jdk
>>>>>>> lib/ServiceabilityLibraries.gmk:27: 
>>>>>>> make/closed/lib/ServiceabilityLibraries.gmk: No such file or directory
>>>>>>> make[2]: *** No rule to make target 
>>>>>>> `make/closed/lib/ServiceabilityLibraries.gmk'.  Stop.
>>>>>>> make[1]: *** [libs-only] Error 2
>>>>>>> make: *** [jdk-only] Error 2
>>>>>>> 
>>>>>>> (I changed "-include" to “include” to provoke the error.)
>>>>>>> 
>>>>>>> jdk/make/ files expect CUSTOM_MAKE_DIR to be just “closed” but that 
>>>>>>> doesn’t work for top-level:
>>>>>>> 
>>>>>>> $ make jdk CUSTOM_MAKE_DIR=closed
>>>>>>> /Users/cthalinger/twitter8//make/Main.gmk:35: closed/Main.gmk: No such 
>>>>>>> file or directory
>>>>>>> make: *** No rule to make target `closed/Main.gmk'. Stop.
>>>>>>> 
>>>>>>> How is this supposed to work?

Re: C/C++ IDE support for HotSpot

[Christian Thalinger]

There is already support to generate IDE config files in 9:

$ mx ideinit

(this is part of JVMCI and came in via JEP 243)

> On Mar 22, 2017, at 4:21 AM, Mikael Gerdin  wrote:
> 
> Hi all,
> 
> I've finally grown tired of manually setting up a hand crafted Eclipse CDT 
> configuration for the JVM sources and decided to share my progress towards 
> improving the overall situation for JVM developers.
> 
> To achieve better IDE support without having to add project generators for 
> all different kinds of past or future IDEs I've decided to try to leverage 
> CMake to do project generation.
> The idea is to have the JDK build system generate a CMakeLists.txt describing 
> all the include paths and definitions required by an IDE to interpret the 
> sources correctly.
> 
> Several modern IDEs natively support CMake but we can also rely on the fact 
> that the CMake build system has the ability to generate projects for a number 
> of different IDEs. For information about which generators CMake supports see
> https://cmake.org/cmake/help/v3.5/manual/cmake-generators.7.html
> for your CMake version.
> 
> To try this out check out (heh) my branch "JDK-8177329-cmake-branch" in the 
> jdk10/sandbox forest:
> http://hg.openjdk.java.net/jdk10/sandbox/branches
> So far I've only made changes in the toplevel and hotspot repositories.
> I've written a short readme in the repo:
> http://hg.openjdk.java.net/jdk10/sandbox/raw-file/JDK-8177329-cmake-branch/README-cmake.html
> 
> It would be great if people tried this out to see if it works on their setup 
> but I don't expect it to work on Windows without changing the makefile to do 
> path conversion.
> If we can make this work properly then perhaps we can get rid of the Visual 
> Studio generator and rely on CMake to generate VS projects.
> 
> It would also be great if someone from build-dev could give me some hints 
> about how to do the file writing and "vardeps" thing properly.
> 
> Thanks
> /Mikael

Re: RFR: JDK-8186115 - libelf still referenced after 8172670

[Christian Thalinger]

> On Aug 15, 2017, at 8:55 PM, Bob Vandette  wrote:
> 
> Please review these changes for JDK 10 that remove all dependencies on libelf 
> from the JDK
> build system.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8186115 
> 
> 
> Webrev:
> http://cr.openjdk.java.net/~bobv/8186115/ 
> 
Looks good.

> 
> Compiler team:  Please check CodeSectionProcessor.  Is the stepping through 
> all
> foreign call still necessary?  I only removed the comment.
> 
> Thanks,
> Bob.
> 
>  

Re: [10] RFR(S) 8186462: [Graal] build Graal regardless AOT build

[Christian Thalinger]

> On Aug 28, 2017, at 10:18 AM, Vladimir Kozlov  
> wrote:
> 
> http://cr.openjdk.java.net/~kvn/8186462/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8186462
> 
> We are planning to have Graal as experimental JIT compiler on linux-x64 in 
> next release. For that we should enable its build independent from AOT build.

Needless to say I am very happy to see this.  The change looks good.

> 
> Thanks,
> Vladimir

Re: OpenJDK on PPC/PPC64 -- non-SUN Bootstrap JDK? Cross-compile?

[Christian Thalinger]

On Thu, 2007-07-12 at 12:12 +1200, Abraham Alawi wrote:
> Hi Folks,
> 
> i'm trying to compile OpenJDK on POWERPC (IBM OPENPOWER).
> 
> Has anybody managed to accomplish this yet? Does the Bootstrap JDK have
> to be SUN JDK? Is it possible to cross-compile it on x86 for PPC? Any
> useful information will be much appreciated.

Hi!

I'm having a half-way compiled j2se running with CACAO on PowerPC.
Maybe that is helpful for you:

http://www.advogato.org/person/twisti/
https://c1.complang.tuwien.ac.at/cacaowiki/OpenJDK

- twisti

Re: building JDK for new platform

[Christian Thalinger]

On Thu, 2007-08-16 at 21:33 -0500, Robert Pangrazio wrote:
> Well I will look into that. I think that some more detail maybe
> necessary. I am thinking of building for RiscOS. There is a really
> nice project that allows you to compile programs written for linux, on
> a linux machine, to run on a RiscOS machine. I would like to try to
> use this to build Java. I was just wondering if it was a waste of
> time, as I would be expecting the Linux native Java version to be used
> in the build process.

Hi!

As we're now on a non-HotSpot architecture, I'd give it a try with
CACAO.  That's probably the best give-it-a-try for now.  Here are my
notes:

https://c1.complang.tuwien.ac.at/cacaowiki/OpenJDK

- twisti

Re: JDK GNU/Linux SPARC and MIPS

[Christian Thalinger]

On Wed, 2007-08-22 at 14:56 +0200, Sunil Amitkumar Janki wrote:
> I have GNU/Linux running on x86, MIPS and SPARC but only
> x86 has an up to date JDK. For MIPS I have JDK 1.5.0 and
> for SPARC Blackdown's JDK 1.4.1.
> 
> I would like to see support for both architectures integrated
> into the JDK sources alongside x86, x86_64 and Solaris SPARC
> so all systems can benefit from up to date Java installations.
> 
> Could someone point out to me what I'd have to do to get
> the latest JDK up and running and support for it integrated
> into mainline sources?

Well, you could port HotSpot or join us, in whatever way, in the IcedTea
project where we try to get OpenJDK running on non-HotSpot platforms.

- twisti

RE: Makefile patch needed when building the b20 OpenJDK source drop

[Christian Thalinger]

On Sun, 2007-09-23 at 23:40 -0700, Ted Neward wrote:
> If they can't rest in the same repository, then perhaps a different
> repository?
> 
> I'm just looking to be able to do a "svn up" (or its Mercurial equivalent)
> and know that I've got everything I need to build the OpenJDK; it's a lot
> more tedious to "svn up" then fetch the latest binary plugs (particularly
> since I'm betting they're not going to change as frequently as the source
> does), and only then do a build.

That's wrong.  Every source build has it's matching binary plug.  See:

http://download.java.net/openjdk/jdk7/

- twisti

Re: Building OpenJDK on Fedora Core 6

[Christian Thalinger]

On Fri, 2007-10-12 at 10:39 -0200, Roger Abelenda wrote:
> hi again everyone. I tryied with the jdk6 for the bootstrap, and no
> luck. I'll try downloading other version of the openjdk. I'm loosing
> my hopes and ideas with this one :-(. je.

Shouldn't you try the b21 drop?  Or did I miss something...

- twisti

possible pkcs11 headers problem

[Christian Thalinger]

Hi!

While hunting down a bug in CACAO, which prevented b22 from building, I
noticed that the build system generates the headers for

sun.security.pkcs11.wrapper.PKCS11
sun.security.pkcs11.Secmod

using the classes taken from sunpkcs11.jar from the bootstrapping JDK
and not the newly built classes (somewhere in a tmp/ directory).

Is this intended?

- twisti

RFC: architecture define probably masks variable names in header files

[Christian Thalinger]

Hi!

Today I noticed that it's not a good idea to use an architecture define
as done in OpenJDK:

CPPFLAGS_COMMON = -D$(ARCH) -DARCH='"$(ARCH)"' -DLINUX $(VERSION_DEFINES) \
  -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT

The -D$(ARCH) e.g. on an Alpha system makes big problems because a lot
of variables are called "alpha" in GUI code.

I tried to patch the OpenJDK code in IcedTea but then I reached a point
where it's not possible to fix the issue:

/usr/include/png.h:

typedef struct png_color_8_struct
{
   png_byte red;   /* for use in red green blue files */
   png_byte green;
   png_byte blue;
   png_byte gray;  /* for use in grayscale files */
   png_byte alpha; /* for alpha channel files */
} png_color_8;

This won't work.

Normally build systems use architecture defines as __ALPHA__ or
__alpha__ (these are also defined by the C compiler).

Any chance to get this thing changed/fixed upstream in the OpenJDK code?
As I can't think of another solution of that problem...

Probably someone decides to name a function argument "sparc"
someday... ;-)

- twisti

Re: RFC: architecture define probably masks variable names in header files

[Christian Thalinger]

On Wed, 2008-01-16 at 23:04 +0100, Christian Thalinger wrote:
> Hi!
> 
> Today I noticed that it's not a good idea to use an architecture define
> as done in OpenJDK:
> 
> CPPFLAGS_COMMON = -D$(ARCH) -DARCH='"$(ARCH)"' -DLINUX $(VERSION_DEFINES) \
> -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT
> 
> The -D$(ARCH) e.g. on an Alpha system makes big problems because a lot
> of variables are called "alpha" in GUI code.
> 
> I tried to patch the OpenJDK code in IcedTea but then I reached a point
> where it's not possible to fix the issue:
> 
> /usr/include/png.h:
> 
> typedef struct png_color_8_struct
> {
>png_byte red;   /* for use in red green blue files */
>png_byte green;
>png_byte blue;
>png_byte gray;  /* for use in grayscale files */
>png_byte alpha; /* for alpha channel files */
> } png_color_8;
> 
> This won't work.
> 
> Normally build systems use architecture defines as __ALPHA__ or
> __alpha__ (these are also defined by the C compiler).
> 
> Any chance to get this thing changed/fixed upstream in the OpenJDK code?
> As I can't think of another solution of that problem...
> 
> Probably someone decides to name a function argument "sparc"
> someday... ;-)

So... noone cares?

- twisti

RE: RFC: architecture define probably masks variable names in header files

[Christian Thalinger]

On Wed, 2008-01-23 at 11:14 -0800, Ted Neward wrote:
> This may be an area where you have to implement the fix and submit it as a
> patch, because I can see the developers at Sun not having the bandwidth to
> take time away from the other things they're working on to take care of this
> themselves--they're horribly underresourced (if you'll pardon the
> verbization) from what I understand.
> 
> What change would you suggest, and how deeply would it ripple through the
> code base?

Well, the problem I see is, I don't know the historical reasons how
stuff was done and I don't know where these defines are used.  A grep
can help here, but the knowledge of a long-year Sun employee would
definitely help a lot.

Of course I can try to make a patch, but definitely I'll need help to
verify that what I've done is correct (btw. IcedTea people will also be
of great help here).

- twisti

Re: RFC: architecture define probably masks variable names in header files

[Christian Thalinger]

On Wed, 2008-01-23 at 11:04 -0800, Kelly O'Hair wrote:
> I very much suspect that this -D$(ARCH) could be removed with no consequences.
> The difficult part would be verifying it.
> 
> C macros are a very powerful tool, but some of the global names we have chosen
> over the years have come back to haunt us. :^(

Can someone tell me where these defines are used?  Roughly, in which
part of the code.  Will a simple grep get me to the correct solution?

- twisti

Re: OpenJDK on Solaris Dev Express 1/2008?

[Christian Thalinger]

On Mon, 2008-06-02 at 08:43 -0700, Kelly O'Hair wrote:
> If SXDE contains Sun Studio 12 (SS12), you may have some problems with 
> compiling
> hotspot. I've integrated some hotspot changes to deal with SS12 issues
> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a49545cab84a
> (hasn't been integrated into the master jdk7/jdk7 repositories yet).
> 
> The rest of the jdk may compile file with SS12, but lots of warnings about
> the use of -xarch options, harmless but annoying. I'm working on the rest
> of the SS12 Makefile changes for the jdk, to get rid of these warnings etc.
> 
> If you can get a Sun Studio 11 installed, would be better right now.
> 
> I used a previous version of SXDE to build OpenJDK a while back, but it
> had SS11 in it at that time, so it was a while ago.
> Looks like the latest SXDE includes Sun Studio Express compilers, which
> are effectively SS12+ I assume.

Is it possible to build OpenJDK for OpenSolaris with GCC?

- twisti

Re: OpenJDK on Solaris Dev Express 1/2008?

[Christian Thalinger]

On Tue, 2008-06-03 at 08:28 -0700, Kelly O'Hair wrote:
> I'm not sure what the state of the Makefiles are for building with gcc
> on Solaris. It has been done in the past, from the artifacts I see in the
> Makefiles, however, it won't 'just build', it will take some changes.
> 
> In general we focus on one compiler set per OS, the one that has
> the most potential for performance and makes the most sense for that OS.
> Takes a great deal of testing and performance tests to 'validate' that
> even a particular release of a compiler isn't regressing us.
> 
> We will be going through that validation process as we change our
> default JDK7 compilers to SS12 on Solaris, gcc4 on Linux, and
> VS2008 on Windows.

I see.  Maybe I can give it try someday.

- twisti

Re: OpenJDK on Solaris Dev Express 1/2008?

[Christian Thalinger]

On Tue, 2008-06-03 at 15:51 -0700, Erik Trimble wrote:
> The Hotspot VM (which is (mostly) what is using the compiler), is set up 
> to build with SunStudio 11. As Kelly notes, we're (well, actually, most 
> He) is in the process of validating SS12 as a build compiler.
> 
> GCC will NOT work under Solaris/SPARC, and I'm pretty darned sure it 
> won't work under Solaris/x86 or Solaris/x64.   There are some 
> significant GCC-isms which the JDK does not currently support.

OK.

> 
> That said, it would not be terribly difficult to modify the source to 
> get GCC to work, but you'd definitely have to spend a bit of time doing so.
> 
> 
> Sadly, C compilers are not interchangeable.

Yeah, I know :-/

- twisti

Re: Ability to override compiler from environment

[Christian Thalinger]

On Thu, 2008-06-26 at 08:31 +0200, Mark Wielaard wrote:
> > configure: error: "motif headers were not found -
> > try installing lesstif-devel."
> > 
> > which I now remember to be the place where I gave up the last time as 
> > apparently Motif is not available under OpenSolaris and "pkg search 
> > lesstif" did not show any packages.
> > 
> > I'll look at building lesstif and see what happens then...
> 
> This really shouldn't be necessary anymore. At least not for
> icedtea/jdk7, there might still be some header constants used in
> icedtea6/openjdk6, but if so we should backport the fixes to remove them
> and remove this check.

That would be really nice, as I am currently trying myself to get
OpenJDK/IcedTea built on OpenSolaris.  I'm currently stuck at finding an
appropriate bootstrap JVM, as it seems Boehm-GC has some problems on
Solaris.  But this may be also a CACAO bug, I'll investigate this
further...

- twisti

Re: Ability to override compiler from environment

[Christian Thalinger]

On Wed, 2008-06-25 at 23:14 +0100, Andrew John Hughes wrote:
> I can guarantee that configure will fail on Windows; it tests for ALSA
> and fails if it isn't found.  I think this is stopping Mac OS X and
> probably will stop OpenSolaris too so probably should be made
> optional.  twisti, how did you get round this for OpenSolaris?

- ,[AC_MSG_ERROR("motif headers were not found - 
+ ,[AC_MSG_WARN("motif headers were not found - 

-  AC_MSG_ERROR([Could not find alsa - \
+  AC_MSG_WARN([Could not find alsa - \

:-)  Of course I don't know what happens later in the build process, but
I will see when I'm finally there.

> On a side note, can someone tell me why IMPORT_BINARY_PLUGS is still
> true by default even though the SNMP plugin is optional now (and thus
> no plugs are needed).  I think the great work in making OpenJDK6
> encumbrance free has largely been missed by many people -- it took me
> a failed build and grep to work out that I needed this option which
> doesn't seem to be documented.

Yes, I missed that too.  Thanks Andrew you told me that last night.

- twisti

Re: Building OpenJDK with a more recent compiler

[Christian Thalinger]

On Tue, 2008-09-16 at 14:49 +, [EMAIL PROTECTED] wrote:
> Unfortunately, the "gcc" install (v3.4.6) on my machine is not the
> version required by the build instructions.  Since I don't have root
> access on my box, I worked on pulling down a more recent version of
> gcc (v4.3.1) and building it for my Linux machine.  In order to build
> the gcc tool, I needed updated versions of two GNU libraries (GMP,
> MPFR).  Since I can't update /usr/lib with these libraries, I needed
> to use the --prefix option to build gcc.  

Where did you install these libraries?  When I cross-compile OpenJDK, or
other stuff, I normally copy the libraries into the toolchain so the
compiler finds them by default.

- Christian

RE: Building OpenJDK with a more recent compiler

[Christian Thalinger]

On Tue, 2008-09-16 at 15:20 +, [EMAIL PROTECTED] wrote:
> Hi Christian, 
> 
> I've installed the GMP and MPFR libraries to separate directories
> other than /usr/lib or /usr/bin.  When I built gcc, I used the
> configuration setting to point towards the local builds of these
> libraries.  
> 
> When you mention copying the libraries into the toolchain, is there a
> particular directory you're referring to?  I've tried copying the
> shared objects into the "lib" directory of the gcc build, but this did
> not solve the problem.  

To find the required libraries in my arm-linux toolchain I copied the
libraries into:

$prefix/arm-unknown-linux-gnu/usr/lib

- Christian

forward-port IMPORT_BINARY_PLUGS to OpenJDK7

[Christian Thalinger]

Hi!

Is there currently any plan to forward-port the IMPORT_BINARY_PLUGS
functionality to OpenJDK7?

- Christian

Re: forward-port IMPORT_BINARY_PLUGS to OpenJDK7

[Christian Thalinger]

On Tue, 2008-10-21 at 17:16 -0700, Kelly O'Hair wrote:
> I filed a jdk7 version of the bug
> http://bugs.sun.com/view_bug.do?bug_id=6672710
> Assigned it to me, but I'm not sure when I get it fixed.

OK.

> 
> I seem to recall that this wasn't the only thing needing fixing
> so that the openjdk7 builds would build without access to binary plugs.
> (Understanding that the resulting build might be missing certain body parts). 
> .^)

My current problem is SNMP.  I can't get around it without changing the
build system massively.  And to be honest, I don't want to do that.

- Christian

Re: forward-port IMPORT_BINARY_PLUGS to OpenJDK7

[Christian Thalinger]

On Wed, 2008-10-22 at 11:43 +0100, Andrew John Hughes wrote:
> The main show stopper would be sound support, unless
> Gervill has now been integrated into OpenJDK7.  Otherwise,
> the jsoundhs plug is needed (or the IcedTea replacement).
> SNMP would have the same status as in OpenJDK6; an optional
> proprietary plug.

Right, but I don't care much about sound right now.  I care about a code
base that builds freely.

- Christian

Re: forward-port IMPORT_BINARY_PLUGS to OpenJDK7

[Christian Thalinger]

On Wed, 2008-10-22 at 11:54 +0100, Andrew John Hughes wrote:
> Then why aren't you using IcedTea?

Fair question.  As I wrote in my blog[1], I have problems in building a
64-bit version on OpenSolaris, but I guess I would have the same problem
on Linux.  I'm not exactly sure where the problem is.  Maybe we build
tools.jar wrongly or it's an upstream bug in that the build system
trusts the boot Java has this class.

[1] http://www.advogato.org/person/twisti/diary/20.html

- Christian

Re: forward-port IMPORT_BINARY_PLUGS to OpenJDK7

[Christian Thalinger]

On Wed, 2008-10-22 at 12:08 +0100, Andrew John Hughes wrote:
> Is that error from building the hotspot-tools jar?  If so, you
> probably need to add some additional packages to the list
> in Makefile.am.

It happens when building HotSpot.  Strange thing is, I could get it
working for a 32-bit build but I can't for a 64-bit one.  Maybe I'm too
stupid... ;-)

- Christian

Re: forward-port IMPORT_BINARY_PLUGS to OpenJDK7

[Christian Thalinger]

On Wed, 2008-10-22 at 12:16 +0100, Andrew John Hughes wrote:
> Ok, then it sounds like something is either not being built into the jars
> in bootstrap/jdk1.6.0 or they are being missing off the classpath used
> by HotSpot. IIRC, hotspot-tools.jar should include com.sun.tools.jdi.*.

The class is not in tools.jar but in rt-closed.jar:

$ unzip -l bootstrap/jdk1.7.0/jre/lib/tools.jar | grep jdi.Linked
$ unzip -l bootstrap/jdk1.7.0/jre/lib/rt-closed.jar | grep jdi.Linked
 9421  10-18-08 17:16   com/sun/tools/jdi/LinkedHashMap.class
 2259  10-18-08 17:16   com/sun/tools/jdi/LinkedHashMap$HashIterator.class
 1301  10-18-08 17:16   com/sun/tools/jdi/LinkedHashMap$1.class
 1769  10-18-08 17:16   com/sun/tools/jdi/LinkedHashMap$Entry.class
 1176  10-18-08 17:16   com/sun/tools/jdi/LinkedHashMap$2.class
 2415  10-18-08 17:16   com/sun/tools/jdi/LinkedHashMap$3.class
$

The command line compiling the HotSpot classes is:

/export/home/twisti/projects/openjdk/icedtea6-bootstrap/build-hotspot-m64/bootstrap/jdk1.6.0/bin/javac
 -source 1.4 -classpath 
/export/home/twisti/projects/openjdk/icedtea6-bootstrap/build-hotspot-m64/bootstrap/jdk1.6.0/lib/tools.jar
 -g -d ../generated/saclasses

and bootstrap/jdk1.6.0/lib/tools.jar is linked to:

$ ls -l bootstrap/jdk1.6.0/lib/
total 3
drwxr-xr-x 2 twisti staff   5 Oct 18 17:08 endorsed/
lrwxrwxrwx 1 twisti staff 110 Oct 18 18:49 tools.jar -> 
/export/home/twisti/projects/openjdk/icedtea6-bootstrap/build-hotspot-m64/bootstrap/jdk1.7.0/jre/lib/tools.jar

In my completed 32-bit IcedTea build, tools.jar contains the JDI
classes:

$ unzip -l openjdk/control/build/solaris-i586/lib/tools.jar | grep jdi.Linked
 1177  10-12-08 14:45   com/sun/tools/jdi/LinkedHashMap$2.class
 2389  10-12-08 14:45   com/sun/tools/jdi/LinkedHashMap$3.class
 1763  10-12-08 14:45   com/sun/tools/jdi/LinkedHashMap$Entry.class
 9571  10-12-08 14:45   com/sun/tools/jdi/LinkedHashMap.class
 2244  10-12-08 14:45   com/sun/tools/jdi/LinkedHashMap$HashIterator.class
 1304  10-12-08 14:45   com/sun/tools/jdi/LinkedHashMap$1.class

So it seems IcedTea should add these classes to the tools.jar.

- Christian

Re: forward-port IMPORT_BINARY_PLUGS to OpenJDK7

[Christian Thalinger]

On Thu, 2008-10-23 at 16:42 +0200, Daniel Fuchs wrote:
> Hi guys,
> 
> I could take care of applying the same patch than what I did
> a few months ago for OpenJDK 6.
> 
> Namely, if you compile OpenJDK with the binary plugs, the SNMP
> runtime will be compiled and included in rt.jar. If you compile
> without the binary plugs, the SNMP runtime will not be included.
> 
> If you try to activate the SNMP agent on an OpenJDK instance that
> doesn't have the SNMP runtime in rt.jar then you will get an
> exception.
> 
> This was integrated in OpenJDK 6 b06.
> 6661448: Make the SNMP agent optional when OPENJDK=true
>   and IMPORT_BINARY_PLUGS=false
> 
> Would that help?

A lot!  Would be great if you could apply that one.

- Christian

Re: forward-port IMPORT_BINARY_PLUGS to OpenJDK7

[Christian Thalinger]

On Thu, 2008-10-23 at 18:15 +0100, Andrew John Hughes wrote:
> This isn't Sun's rt-closed.jar, which is proprietary. This is a faked
> version which
> is part of the IcedTea build.  However, on both IcedTea6 and IcedTea7 this 
> only
> includes SNMP and sound stubs (and the latter should probably be removed).
> On IcedTea6, it also includes JNLP.  We should look at enabling
> IMPORT_BINARY_PLUGS=false on IcedTea so these stubs are not needed.

Correct, sorry for the confusion.  It started as an OpenJDK discussion
but ended up in an IcedTea one.

- Christian

[PATCH] hotspot/make/solaris/makefiles/sparcWorks.make misses grep for CC version

[Christian Thalinger]

Hi!

I just wanted to build the new OpenJDK 6 b13 drop on a recent
OpenSolaris Indiana (snv_101a) and ran into this warning:

cd solaris_i486_compiler2/product && make -w
WARNING: You are using CC version 5.10 Usage: CC [ options ] files.  Use 'CC 
-flags' for details and should be using version 5.10
WARNING: You are using cc version cc: `-V' option must have argument and should 
be using version 5.10
expr: syntax error
expr: syntax error
expr: syntax error
expr: syntax error
expr: syntax error

This seems to be related to the update of Sun Studio C++ compiler to
version 5.10, as it didn't happen with 5.9.  I thought it may be fixed
in jdk7, but it isn't.  So here is a patch that fixes this problem:

diff -r 42ca4002efc2 make/solaris/makefiles/sparcWorks.make
--- a/make/solaris/makefiles/sparcWorks.makeThu Nov 06 12:10:20 2008 -0800
+++ b/make/solaris/makefiles/sparcWorks.makeMon Nov 10 15:22:15 2008 +0100
@@ -41,7 +41,7 @@
 
 # Get the last thing on the line that looks like x.x+ (x is a digit).
 COMPILER_REV := \
-$(shell $(CPP) -V 2>&1 | sed -e 's/^.*\([1-9]\.[0-9][0-9]*\).*/\1/')
+$(shell $(CPP) -V 2>&1 | grep "CC:" | sed -e 
's/^.*\([1-9]\.[0-9][0-9]*\).*/\1/')
 C_COMPILER_REV := \
 $(shell $(CC) -V 2>&1 | grep -i "cc:" |  sed -e 
's/^.*\([1-9]\.[0-9][0-9]*\).*/\1/')

- Christian

[PATCH] hotspot/make/solaris/makefiles/sparcWorks.make misses grep for CC version

[Christian Thalinger]

Hi!

I just wanted to build the new OpenJDK 6 b13 drop on a recent
OpenSolaris Indiana (snv_101a) and ran into this warning:

cd solaris_i486_compiler2/product && make -w
WARNING: You are using CC version 5.10 Usage: CC [ options ] files.  Use 'CC 
-flags' for details and should be using version 5.10
WARNING: You are using cc version cc: `-V' option must have argument and should 
be using version 5.10
expr: syntax error
expr: syntax error
expr: syntax error
expr: syntax error
expr: syntax error

This seems to be related to the update of Sun Studio C++ compiler to
version 5.10, as it didn't happen with 5.9.  I thought it may be fixed
in jdk7, but it isn't.  So here is a patch that fixes this problem:

diff -r 42ca4002efc2 make/solaris/makefiles/sparcWorks.make
--- a/make/solaris/makefiles/sparcWorks.makeThu Nov 06 12:10:20 2008 -0800
+++ b/make/solaris/makefiles/sparcWorks.makeMon Nov 10 15:22:15 2008 +0100
@@ -41,7 +41,7 @@
 
 # Get the last thing on the line that looks like x.x+ (x is a digit).
 COMPILER_REV := \
-$(shell $(CPP) -V 2>&1 | sed -e 's/^.*\([1-9]\.[0-9][0-9]*\).*/\1/')
+$(shell $(CPP) -V 2>&1 | grep "CC:" | sed -e 
's/^.*\([1-9]\.[0-9][0-9]*\).*/\1/')
 C_COMPILER_REV := \
 $(shell $(CC) -V 2>&1 | grep -i "cc:" |  sed -e 
's/^.*\([1-9]\.[0-9][0-9]*\).*/\1/')

- Christian

Re: b39 build problems on Ubuntu 8.10

[Christian Thalinger]

On Fri, 2008-11-21 at 19:25 +, Andrew John Hughes wrote:
> 2008/11/21 Kelly O'Hair <[EMAIL PROTECTED]>:
> > Sorry, I meant to explicitly call out the 3 "WARNING:" messages.
> > The bcopy problem is a separate thing, more serious and needs to be
> > fix in OpenJDK sources. Glad to hear that IcedTea has them fixed.
> >
> 
> We just remove the offending lines from
> openjdk/hotspot/src/share/vm/libadt/port.hpp which works on GNU/Linux
> platforms but I'm not sure if anyone has built the result on Solaris.

Yes, I did and it works.  I just checked the patch
(patches/icedtea-no-bcopy.patch) is in my IcedTea checkout and it was
applied.

$ openjdk/control/build/solaris-i586/j2sdk-image/bin/java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (build 1.6.0_0-b12)
OpenJDK Server VM (build 1.6.0_0-b12, mixed mode)

- Christian

Re: forward-port IMPORT_BINARY_PLUGS to OpenJDK7

[Christian Thalinger]

On Thu, 2008-10-23 at 16:42 +0200, Daniel Fuchs wrote:
> Hi guys,
> 
> I could take care of applying the same patch than what I did
> a few months ago for OpenJDK 6.
> 
> Namely, if you compile OpenJDK with the binary plugs, the SNMP
> runtime will be compiled and included in rt.jar. If you compile
> without the binary plugs, the SNMP runtime will not be included.
> 
> If you try to activate the SNMP agent on an OpenJDK instance that
> doesn't have the SNMP runtime in rt.jar then you will get an
> exception.
> 
> This was integrated in OpenJDK 6 b06.
> 6661448: Make the SNMP agent optional when OPENJDK=true
>   and IMPORT_BINARY_PLUGS=false
> 
> Would that help?

Ping?

- Christian

Re: forward-port IMPORT_BINARY_PLUGS to OpenJDK7

[Christian Thalinger]

On Tue, 2008-12-09 at 12:25 +0100, Christian Thalinger wrote:
> On Thu, 2008-10-23 at 16:42 +0200, Daniel Fuchs wrote:
> > Hi guys,
> > 
> > I could take care of applying the same patch than what I did
> > a few months ago for OpenJDK 6.
> > 
> > Namely, if you compile OpenJDK with the binary plugs, the SNMP
> > runtime will be compiled and included in rt.jar. If you compile
> > without the binary plugs, the SNMP runtime will not be included.
> > 
> > If you try to activate the SNMP agent on an OpenJDK instance that
> > doesn't have the SNMP runtime in rt.jar then you will get an
> > exception.
> > 
> > This was integrated in OpenJDK 6 b06.
> > 6661448: Make the SNMP agent optional when OPENJDK=true
> >   and IMPORT_BINARY_PLUGS=false
> > 
> > Would that help?
> 
> Ping?

Too little time to port that patch?

- Christian

Re: New project: getting rid of IcedTea local patches

[Christian Thalinger]

On Wed, 2009-04-01 at 10:47 -0700, Kelly O'Hair wrote:
> I can certainly help out with any build related (makefiles etc.)
> changes.

Ohh, that reminds me of this one:

https://bugs.openjdk.java.net/show_bug.cgi?id=100011

Because one change touches a jdk Makefile, I didn't push yet.  Either
someone from the jdk team approves the change and I push it through the
hotspot-comp gate or the changes go in as two different changesets.

-- Christian

Re: New project: getting rid of IcedTea local patches

[Christian Thalinger]

On Wed, 2009-04-01 at 11:33 -0700, Kelly O'Hair wrote:
> The changes to the jdk files look fine.
> One question though, does the name "CORE_BUILD" have a meaning to the
> JDK, or just the VM? Just wondering if a "VM_CORE_BUILD" or
> "HOTSPOT_CORE_BUILD" might be a better name. Not a big deal.

I don't know, but maybe Gary does...

> If you have changesets I can send them through the jdk7/build forest,
> with the appropriate jdk test builds (the changes look independent,
> so should be fine) or you can send them through the hotspot-comp forest.
> Although you should make sure the hotspot integrators
> are aware that you have made changes to non-hotspot repositories, just
> to make sure they don't forget to do a full forest push.

I see.  Maybe you should do the push :-)  Should I prepare a changeset
and send it over to you?

-- Christian

Re: hotspot build failure on ubuntu x86_64

[Christian Thalinger]

On Fri, 2009-10-23 at 14:32 +0800, Weijun Wang wrote:
> Hi Martin
> 
> Since the error line is only a printf message, I just remove the line.
> And now everything builds fine!
> 
> I'll see if the PTR_FORMAT macro is used in other places and why there's
> no problem there.

This line is part of the new JSR 292 code and a fix for the build issue
will be commited (with all other JSR 292 stuff) before M5.  Sorry for
the inconvenience.

-- Christian

Re: Cross Compiling for x86_64 on x86

[Christian Thalinger]

On Mon, 2009-12-07 at 14:55 +0530, Deepak Mathews wrote:
> Can the building of OpenJDK made independant of the host machine. Or
> does it run some programs which are dependant (like adlc) which will
> make cross compilation impossible?
> 
> 
> What about cross compiling for MIPS or PPC from the same 32 bit host?
> Will this same VM  problem be there for that also?

There problem here is ADLC, which is part of the server compiler.  Let
me try to get it built for a 32-bit host...

Cross-compiling IcedTea for MIPS or PPC should work OK, as there is no
server or client compiler port so Zero is used and that builds fine.

You could also build x86_64 Zero (Gary, does that work?) on your 32-bit
system and use that one.  But keep in mind that it's C++ interpreter
only.

-- Christian

Re: Cross Compiling for x86_64 on x86

[Christian Thalinger]

On Mon, 2009-12-07 at 10:39 +0100, Christian Thalinger wrote:
> There problem here is ADLC, which is part of the server compiler.  Let
> me try to get it built for a 32-bit host...

A really ugly (but possibly working) hack to build a full OpenJDK
successfully would be to copy a 32-bit adlc over the 64-bit one when the
build fails:

$ cp build/solaris/solaris_i486_compiler2/generated/adfiles/adlc 
build/solaris/solaris_amd64_compiler2/generated/adfiles/adlc

Then just restart the build.

-- Christian

Re: Review Request: Final Shark buildsystem piece

[Christian Thalinger]

On Tue, 2010-08-17 at 13:51 -0700, Kelly O'Hair wrote:
> Gary,
> 
> I had assumed this was a file in the hotspot repo, but it's actually  
> in the top repo.
> Feel free to push this change into the tl forest, or whereever you  
> pushed it's cohort changeset.

Gary, do you need a new CR?  -- Christian

Re: Disable compressedOop,

[Christian Thalinger]

On Mar 4, 2011, at 3:38 PM, Dang Nhan Nguyen wrote:
> Hi all,
> 
> I am trying to debug a small piece of code with hotspot using VS2010, on Win7 
> 64bit. 
> My code caused a bug whenever I referred to an object in Young Generation of 
> the heap which has its klass as a CompressedOop. As a workaround, I want to 
> disable using CompressedOop.
> 
> Does anybody know how to disable CompressedOop when I build the hotspot?

I'm not sure I understand.  What do you mean by "when I build the hotspot"?  Do 
you hit this bug *while* building HotSpot?

To disable compressed oops use: -XX:-UseCompressedOops

-- Christian

Fwd: RFR: 8000780: make Zero build and run with JDK8

[Christian Thalinger]

This patch contains a Makefile change:

http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.03/make/Makefile.udiff.html

-- Chris

Begin forwarded message:

> From: Roman Kennke 
> Subject: Re: RFR: Make Zero build and run with JDK8
> Date: October 17, 2012 4:09:13 PM PDT
> To: Christian Thalinger 
> Cc: hotspot-...@openjdk.java.net
> 
> Am Mittwoch, den 17.10.2012, 15:34 -0700 schrieb Christian Thalinger:
>> On Oct 17, 2012, at 3:05 PM, Roman Kennke  wrote:
>> 
>>> Am Mittwoch, den 17.10.2012, 14:40 -0700 schrieb Christian Thalinger:
>>>> On Oct 16, 2012, at 8:01 AM, Roman Kennke  wrote:
>>>> 
>>>>> Hi Christian,
>>>>> 
>>>>>>>>>> In the recent weeks I worked on the Zero interpreter, to get it to 
>>>>>>>>>> build
>>>>>>>>>> and run with JDK8, and in particular with the latest changes that 
>>>>>>>>>> came
>>>>>>>>>> from mlvm (meth-lazy). The following webrev applies to 
>>>>>>>>>> hsx/hotspot-main:
>>>>>>>>>> 
>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
>>>>>>>> 
>>>>>>>> src/share/vm/asm/codeBuffer.cpp:
>>>>>>>> 
>>>>>>>> -  if (dest->blob() == NULL) {
>>>>>>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
>>>>>>>> 
>>>>>>>> Do we really need this when you have this:
>>>>>>> 
>>>>>>> The above is needed, because the loop above it that initializes
>>>>>>> dest_filled is never executed. However, I will change the test to
>>>>>>> dest_filled != NULL :-)
>>>>>>> 
>>>>>>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
>>>>>>>> 
>>>>>>>> -  memset(to, value, count);
>>>>>>>> +  if ( count > 0 ) memset(to, value, count);
>>>>>>>> 
>>>>>>>> }
>>>>>>> 
>>>>>>> Turns out that this is 1. not related to the other change above and 2.
>>>>>>> not needed. I'll remove it.
>>>>>>> 
>>>>>>>> src/share/vm/interpreter/interpreter.cpp:
>>>>>>>> 
>>>>>>>> -  assert(_entry_table[kind] == _entry_table[abstract], "previous 
>>>>>>>> value must be AME entry");
>>>>>>>> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == 
>>>>>>>> _entry_table[abstract], "previous value must be AME entry or NULL");
>>>>>>>> 
>>>>>>>> Why did you need that change?
>>>>>>> 
>>>>>>> Apparently, before the whole table was initialized, and the methodhandle
>>>>>>> related entries left as abstract. Now the methodhandle entries are
>>>>>>> simply left to NULL. I suppose we could change the assert to 
>>>>>>> 
>>>>>>> assert(_entry_table[kind] == NULL, "previous value must be NULL");
>>>>>>> 
>>>>>>> Alternatively, we could fix the code that puts the other entries to also
>>>>>>> set the methodhandle entries to AME and go back to the original assert.
>>>>>>> What do you think?
>>>>>> 
>>>>>> TemplateInterpreterGenerator::generate_all sets all MH entries to AME:
>>>>>> 
>>>>>> // method handle entry kinds are generated later in 
>>>>>> MethodHandlesAdapterGenerator::generate: 
>>>>>>  
>>>>>> for (int i = Interpreter::method_handle_invoke_FIRST; i <= 
>>>>>> Interpreter::method_handle_invoke_LAST; i++) {   
>>>>>>
>>>>>> Interpreter::MethodKind kind = (Interpreter::MethodKind) i;  
>>>>>>  
>>>>>>
>>>>>> Interpreter::_entry_table[kind] = 
>>>>>> Interpreter::_entry_table[Interpreter::abstract];
>>>>>>   

Re: RFR: 8000780: make Zero build and run with JDK8

[Christian Thalinger]

Thank you, Kelly.  -- Chris

On Oct 29, 2012, at 11:05 AM, Kelly O'Hair  wrote:

> Looks fine.
> 
> -kto
> 
> On Oct 29, 2012, at 10:42 AM, Christian Thalinger wrote:
> 
>> This patch contains a Makefile change:
>> 
>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.03/make/Makefile.udiff.html
>> 
>> -- Chris
>> 
>> Begin forwarded message:
>> 
>>> From: Roman Kennke 
>>> Subject: Re: RFR: Make Zero build and run with JDK8
>>> Date: October 17, 2012 4:09:13 PM PDT
>>> To: Christian Thalinger 
>>> Cc: hotspot-...@openjdk.java.net
>>> 
>>> Am Mittwoch, den 17.10.2012, 15:34 -0700 schrieb Christian Thalinger:
>>>> On Oct 17, 2012, at 3:05 PM, Roman Kennke  wrote:
>>>> 
>>>>> Am Mittwoch, den 17.10.2012, 14:40 -0700 schrieb Christian Thalinger:
>>>>>> On Oct 16, 2012, at 8:01 AM, Roman Kennke  wrote:
>>>>>> 
>>>>>>> Hi Christian,
>>>>>>> 
>>>>>>>>>>>> In the recent weeks I worked on the Zero interpreter, to get it to 
>>>>>>>>>>>> build
>>>>>>>>>>>> and run with JDK8, and in particular with the latest changes that 
>>>>>>>>>>>> came
>>>>>>>>>>>> from mlvm (meth-lazy). The following webrev applies to 
>>>>>>>>>>>> hsx/hotspot-main:
>>>>>>>>>>>> 
>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
>>>>>>>>>> 
>>>>>>>>>> src/share/vm/asm/codeBuffer.cpp:
>>>>>>>>>> 
>>>>>>>>>> -  if (dest->blob() == NULL) {
>>>>>>>>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
>>>>>>>>>> 
>>>>>>>>>> Do we really need this when you have this:
>>>>>>>>> 
>>>>>>>>> The above is needed, because the loop above it that initializes
>>>>>>>>> dest_filled is never executed. However, I will change the test to
>>>>>>>>> dest_filled != NULL :-)
>>>>>>>>> 
>>>>>>>>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
>>>>>>>>>> 
>>>>>>>>>> -  memset(to, value, count);
>>>>>>>>>> +  if ( count > 0 ) memset(to, value, count);
>>>>>>>>>> 
>>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> Turns out that this is 1. not related to the other change above and 2.
>>>>>>>>> not needed. I'll remove it.
>>>>>>>>> 
>>>>>>>>>> src/share/vm/interpreter/interpreter.cpp:
>>>>>>>>>> 
>>>>>>>>>> -  assert(_entry_table[kind] == _entry_table[abstract], "previous 
>>>>>>>>>> value must be AME entry");
>>>>>>>>>> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == 
>>>>>>>>>> _entry_table[abstract], "previous value must be AME entry or NULL");
>>>>>>>>>> 
>>>>>>>>>> Why did you need that change?
>>>>>>>>> 
>>>>>>>>> Apparently, before the whole table was initialized, and the 
>>>>>>>>> methodhandle
>>>>>>>>> related entries left as abstract. Now the methodhandle entries are
>>>>>>>>> simply left to NULL. I suppose we could change the assert to 
>>>>>>>>> 
>>>>>>>>> assert(_entry_table[kind] == NULL, "previous value must be NULL");
>>>>>>>>> 
>>>>>>>>> Alternatively, we could fix the code that puts the other entries to 
>>>>>>>>> also
>>>>>>>>> set the methodhandle entries to AME and go back to the original 
>>>>>>>>> assert.
>>>>>>>>> What do you think?
>>>>>>>> 
>>>>>>>> TemplateInterpreterGenerator::generate_all sets all MH entries to AME:
>>>>>>>> 
>>>>>

Fwd: RFR: 8000780: make Zero build and run with JDK8

[Christian Thalinger]

This patch contains a Makefile change:

http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.03/make/Makefile.udiff.html

-- Chris

Begin forwarded message:

> From: Roman Kennke 
> Subject: Re: RFR: Make Zero build and run with JDK8
> Date: October 17, 2012 4:09:13 PM PDT
> To: Christian Thalinger 
> Cc: hotspot-...@openjdk.java.net
> 
> Am Mittwoch, den 17.10.2012, 15:34 -0700 schrieb Christian Thalinger:
>> On Oct 17, 2012, at 3:05 PM, Roman Kennke  wrote:
>> 
>>> Am Mittwoch, den 17.10.2012, 14:40 -0700 schrieb Christian Thalinger:
>>>> On Oct 16, 2012, at 8:01 AM, Roman Kennke  wrote:
>>>> 
>>>>> Hi Christian,
>>>>> 
>>>>>>>>>> In the recent weeks I worked on the Zero interpreter, to get it to 
>>>>>>>>>> build
>>>>>>>>>> and run with JDK8, and in particular with the latest changes that 
>>>>>>>>>> came
>>>>>>>>>> from mlvm (meth-lazy). The following webrev applies to 
>>>>>>>>>> hsx/hotspot-main:
>>>>>>>>>> 
>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
>>>>>>>> 
>>>>>>>> src/share/vm/asm/codeBuffer.cpp:
>>>>>>>> 
>>>>>>>> -  if (dest->blob() == NULL) {
>>>>>>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
>>>>>>>> 
>>>>>>>> Do we really need this when you have this:
>>>>>>> 
>>>>>>> The above is needed, because the loop above it that initializes
>>>>>>> dest_filled is never executed. However, I will change the test to
>>>>>>> dest_filled != NULL :-)
>>>>>>> 
>>>>>>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
>>>>>>>> 
>>>>>>>> -  memset(to, value, count);
>>>>>>>> +  if ( count > 0 ) memset(to, value, count);
>>>>>>>> 
>>>>>>>> }
>>>>>>> 
>>>>>>> Turns out that this is 1. not related to the other change above and 2.
>>>>>>> not needed. I'll remove it.
>>>>>>> 
>>>>>>>> src/share/vm/interpreter/interpreter.cpp:
>>>>>>>> 
>>>>>>>> -  assert(_entry_table[kind] == _entry_table[abstract], "previous 
>>>>>>>> value must be AME entry");
>>>>>>>> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == 
>>>>>>>> _entry_table[abstract], "previous value must be AME entry or NULL");
>>>>>>>> 
>>>>>>>> Why did you need that change?
>>>>>>> 
>>>>>>> Apparently, before the whole table was initialized, and the methodhandle
>>>>>>> related entries left as abstract. Now the methodhandle entries are
>>>>>>> simply left to NULL. I suppose we could change the assert to 
>>>>>>> 
>>>>>>> assert(_entry_table[kind] == NULL, "previous value must be NULL");
>>>>>>> 
>>>>>>> Alternatively, we could fix the code that puts the other entries to also
>>>>>>> set the methodhandle entries to AME and go back to the original assert.
>>>>>>> What do you think?
>>>>>> 
>>>>>> TemplateInterpreterGenerator::generate_all sets all MH entries to AME:
>>>>>> 
>>>>>> // method handle entry kinds are generated later in 
>>>>>> MethodHandlesAdapterGenerator::generate: 
>>>>>>  
>>>>>> for (int i = Interpreter::method_handle_invoke_FIRST; i <= 
>>>>>> Interpreter::method_handle_invoke_LAST; i++) {   
>>>>>>
>>>>>>  Interpreter::MethodKind kind = (Interpreter::MethodKind) i; 
>>>>>>  
>>>>>> 
>>>>>>  Interpreter::_entry_table[kind] = 
>>>>>> Interpreter::_entry_table[Interpreter::abstract];
>>>>>>   

Fwd: RFR: 8000780: make Zero build and run with JDK8

[Christian Thalinger]

This patch contains a Makefile change:

http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.03/make/Makefile.udiff.html

-- Chris

Begin forwarded message:

> From: Roman Kennke 
> Subject: Re: RFR: Make Zero build and run with JDK8
> Date: October 17, 2012 4:09:13 PM PDT
> To: Christian Thalinger 
> Cc: hotspot-...@openjdk.java.net
> 
> Am Mittwoch, den 17.10.2012, 15:34 -0700 schrieb Christian Thalinger:
>> On Oct 17, 2012, at 3:05 PM, Roman Kennke  wrote:
>> 
>>> Am Mittwoch, den 17.10.2012, 14:40 -0700 schrieb Christian Thalinger:
>>>> On Oct 16, 2012, at 8:01 AM, Roman Kennke  wrote:
>>>> 
>>>>> Hi Christian,
>>>>> 
>>>>>>>>>> In the recent weeks I worked on the Zero interpreter, to get it to 
>>>>>>>>>> build
>>>>>>>>>> and run with JDK8, and in particular with the latest changes that 
>>>>>>>>>> came
>>>>>>>>>> from mlvm (meth-lazy). The following webrev applies to 
>>>>>>>>>> hsx/hotspot-main:
>>>>>>>>>> 
>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
>>>>>>>> 
>>>>>>>> src/share/vm/asm/codeBuffer.cpp:
>>>>>>>> 
>>>>>>>> -  if (dest->blob() == NULL) {
>>>>>>>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
>>>>>>>> 
>>>>>>>> Do we really need this when you have this:
>>>>>>> 
>>>>>>> The above is needed, because the loop above it that initializes
>>>>>>> dest_filled is never executed. However, I will change the test to
>>>>>>> dest_filled != NULL :-)
>>>>>>> 
>>>>>>>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
>>>>>>>> 
>>>>>>>> -  memset(to, value, count);
>>>>>>>> +  if ( count > 0 ) memset(to, value, count);
>>>>>>>> 
>>>>>>>> }
>>>>>>> 
>>>>>>> Turns out that this is 1. not related to the other change above and 2.
>>>>>>> not needed. I'll remove it.
>>>>>>> 
>>>>>>>> src/share/vm/interpreter/interpreter.cpp:
>>>>>>>> 
>>>>>>>> -  assert(_entry_table[kind] == _entry_table[abstract], "previous 
>>>>>>>> value must be AME entry");
>>>>>>>> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == 
>>>>>>>> _entry_table[abstract], "previous value must be AME entry or NULL");
>>>>>>>> 
>>>>>>>> Why did you need that change?
>>>>>>> 
>>>>>>> Apparently, before the whole table was initialized, and the methodhandle
>>>>>>> related entries left as abstract. Now the methodhandle entries are
>>>>>>> simply left to NULL. I suppose we could change the assert to 
>>>>>>> 
>>>>>>> assert(_entry_table[kind] == NULL, "previous value must be NULL");
>>>>>>> 
>>>>>>> Alternatively, we could fix the code that puts the other entries to also
>>>>>>> set the methodhandle entries to AME and go back to the original assert.
>>>>>>> What do you think?
>>>>>> 
>>>>>> TemplateInterpreterGenerator::generate_all sets all MH entries to AME:
>>>>>> 
>>>>>> // method handle entry kinds are generated later in 
>>>>>> MethodHandlesAdapterGenerator::generate: 
>>>>>>  
>>>>>> for (int i = Interpreter::method_handle_invoke_FIRST; i <= 
>>>>>> Interpreter::method_handle_invoke_LAST; i++) {   
>>>>>>
>>>>>> Interpreter::MethodKind kind = (Interpreter::MethodKind) i;  
>>>>>>  
>>>>>>
>>>>>> Interpreter::_entry_table[kind] = 
>>>>>> Interpreter::_entry_table[Interpreter::abstract];
>>>>>>   

Re: RFR (S): 8006965: test_gamma should run with import JDK

[Christian Thalinger]

On Feb 21, 2013, at 8:10 PM, David Holmes  wrote:

> Hi Christian,
> 
> cc'ing build-dev
> 
> On 22/02/2013 12:40 PM, Christian Thalinger wrote:
>> http://cr.openjdk.java.net/~twisti/8006965
>> 
>> 8006965: test_gamma should run with import JDK
>> Reviewed-by:
>> 
>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where
>> JDK n is the version we are actually compiling for).  This setup is
>> unsupported and thus should not be done during HotSpot builds.
>> 
>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when
>> running test_gamma.
> 
> First, the simplest change seems to me to just to do:
> 
> ! MAKE_ARGS += JAVA_HOME=$(JDK_IMPORT_PATH)
> 
> and not need to change anything in buildtree.make.

Maybe.  But the conditional setting of JAVA_HOME in env.sh is a problem.

> 
> But this forces everyone outside of Oracle (and some inside) to have to set 
> ALT_JDK_IMPORT_PATH explicitly otherwise they get:
> 
> JDK_IMPORT_PATH=$(SLASH_JAVA)/re/j2se/$(JDK_VERSION)/promoted/latest/binaries/$(PLATFORM)

That should be set by the OpenJDK build.  And people who are only building 
hotspot are probably setting this anyway (and are special).

> 
> And the boot JDK is only JDK n-1 for our official builds - people can use 
> whatever boot JDK works for them including latest JDK.

Right.  They can use whatever boot JDK they want but not import.

> 
> I see the problem you want to fix, and I know why you've hit it, but this 
> doesn't seem like a general solution. I don't know what to suggest.
> 
>> make/bsd/makefiles/buildtree.make
>> make/defs.make
> 
> Why did you add:
> 
> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR)
> 
> ?

Because JAVA_HOME was overwritten by ABS_BOOTDIR which looks completely wrong 
to me (and caused a problem with a version of the patch that still had the 
conditional setting of JAVA_HOME).

-- Chris

> 
> David
> -
> 
>> make/linux/makefiles/buildtree.make
>> make/solaris/makefiles/buildtree.make
>> 

Re: RFR (S): 8006965: test_gamma should run with import JDK

[Christian Thalinger]

I talked to a lot of people about this today.  What we really want is to not 
run tests when we build.  Mikael and I were looking into how we could do that 
without gamma and there is a way:

http://cr.openjdk.java.net/~twisti/8006965/

This would be the first of three fixes:

Fix 1)  The patch above removes test_gamma and uses some weirdness in the VM 
(-Dsun.java.launcher=gamma) to run it with an existing JDK; add 
test_{product,fastdebug,debug} targets

Fix 2)  Remove gamma and all the ugly code that comes with it (copies of the 
jdk launcher in hotspot and other pieces); make the hotspot script work like 
the test targets in Fix 1

Fix 3)  Remove the -Dsun.java.launcher=gamma and possibly replace the existing 
-Dsun.boot.library.path weirdness by explicit command line options like 
-Xbootlibrarypath:{/p,/a}

-- Chris

On Feb 22, 2013, at 3:21 PM, Christian Thalinger 
 wrote:

> 
> On Feb 22, 2013, at 12:58 AM, Staffan Larsen  
> wrote:
> 
>> I'm not sure what the correct solution is, but when you do find out, the 
>> jdkpath.sh target should also be updated.
> 
> How many are actually using the hotspot script?  Would people be very 
> sentimental if we would remove the gamma launcher altogether?
> 
> Taking to people here it seems that most are copying their libjvm into a JDK 
> and use java anyway.
> 
> -- Chris
> 
>> 
>> Thanks,
>> /Staffan
>> 
>> On 22 feb 2013, at 03:40, Christian Thalinger 
>>  wrote:
>> 
>>> http://cr.openjdk.java.net/~twisti/8006965
>>> 
>>> 8006965: test_gamma should run with import JDK
>>> Reviewed-by:
>>> 
>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where
>>> JDK n is the version we are actually compiling for).  This setup is
>>> unsupported and thus should not be done during HotSpot builds.
>>> 
>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when
>>> running test_gamma.
>>> 
>>> make/bsd/makefiles/buildtree.make
>>> make/defs.make
>>> make/linux/makefiles/buildtree.make
>>> make/solaris/makefiles/buildtree.make
>>> 
>> 
> 

Re: RFR (S): 8006965: test_gamma should run with import JDK

[Christian Thalinger]

On Feb 24, 2013, at 2:54 PM, David Holmes  wrote:

> On 23/02/2013 1:55 PM, Christian Thalinger wrote:
>> I talked to a lot of people about this today.  What we really want is to not 
>> run tests when we build.  Mikael and I were looking into how we could do 
>> that without gamma and there is a way:
>> 
>> http://cr.openjdk.java.net/~twisti/8006965/
>> 
>> This would be the first of three fixes:
>> 
>> Fix 1)  The patch above removes test_gamma and uses some weirdness in the VM 
>> (-Dsun.java.launcher=gamma) to run it with an existing JDK; add 
>> test_{product,fastdebug,debug} targets
> 
> This logic is not suitable:
> 
> 541 # Testing the built JVM
> 542 ifeq ($(JAVA_HOME),)
> 543   RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java 
> -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) 
> -Dsun.java.launcher=gamma
> 544 else
> 545   RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server 
> -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma
> 546 endif
> 
> I have JAVA_HOME set in my environment for use by other tools/scripts and it 
> points at JDK7. The existing logic does not use my environments JAVA_HOME 
> setting so neither should the revised logic!

That's not entirely correct.  test_gamma uses your JAVA_HOME setting:

cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
 export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64
cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
 ./test_gamma 
Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre

cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
 export JAVA_HOME=/foo
cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
 ./test_gamma 
JAVA_HOME must point to a 64-bit OpenJDK.

And here comes this little snippet into play:

-MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR)
+MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR)

Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a 
JAVA_HOME set.

I have added this logic so that users can control what JDK is used when running 
the test.  In fact they should use ALT_JDK_IMPORT_PATH if they want to control 
that.

> 
> I also don't see why the above sets JAVA_HOME at #543 - what will read that 
> environment variable?

It's the odd logic in os::jvm_path guarded by 
Arguments::created_by_gamma_launcher().  A clean-up of that logic would be part 
of Fix 3.

> 
> I still have concerns over what JDK_IMPORT_PATH will point to for different 
> JDK builders.

It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR.  Since most people don't want to 
export their libjvm into a JDK we have to use JDK_IMPORT_PATH.  We could add 
some logic that checks if JDK_IMAGE_DIR exists and use that one.

-- Chris

> 
> And this addition still makes no sense to me:
> 
> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR)
> 
> Why do you need to add BOOTDIR to the MAKE_ARGS?
> 
> David
> 
> 
>> Fix 2)  Remove gamma and all the ugly code that comes with it (copies of the 
>> jdk launcher in hotspot and other pieces); make the hotspot script work like 
>> the test targets in Fix 1
>> 
>> Fix 3)  Remove the -Dsun.java.launcher=gamma and possibly replace the 
>> existing -Dsun.boot.library.path weirdness by explicit command line options 
>> like -Xbootlibrarypath:{/p,/a}
>> 
>> -- Chris
>> 
>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger 
>>  wrote:
>> 
>>> 
>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen  
>>> wrote:
>>> 
>>>> I'm not sure what the correct solution is, but when you do find out, the 
>>>> jdkpath.sh target should also be updated.
>>> 
>>> How many are actually using the hotspot script?  Would people be very 
>>> sentimental if we would remove the gamma launcher altogether?
>>> 
>>> Taking to people here it seems that most are copying their libjvm into a 
>>> JDK and use java anyway.
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> Thanks,
>>>> /Staffan
>>>> 
>>>> On 22 feb 2013, at 03:40, Christian Thalinger 
>>>>  wrote:
>>>> 
>>>>> http://cr.openjdk.java.net/~twisti/8006965
>>>>> 
>>>>> 8006965: test_gamma should run with import JDK
>>>>> Reviewed-by:
>>>>> 
>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where
>>>>> JDK n is the version we are actually compiling for).  This setup is
>>>>> unsupported and thus should not be done during HotSpot builds.
>>>>> 
>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when
>>>>> running test_gamma.
>>>>> 
>>>>> make/bsd/makefiles/buildtree.make
>>>>> make/defs.make
>>>>> make/linux/makefiles/buildtree.make
>>>>> make/solaris/makefiles/buildtree.make
>>>>> 
>>>> 
>>> 
>> 

Re: RFR (S): 8006965: test_gamma should run with import JDK

[Christian Thalinger]

On Feb 25, 2013, at 11:24 PM, David Holmes  wrote:

> On 26/02/2013 4:42 AM, Christian Thalinger wrote:
>> On Feb 24, 2013, at 2:54 PM, David Holmes  wrote:
>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote:
>>>> I talked to a lot of people about this today.  What we really want is to 
>>>> not run tests when we build.  Mikael and I were looking into how we could 
>>>> do that without gamma and there is a way:
>>>> 
>>>> http://cr.openjdk.java.net/~twisti/8006965/
>>>> 
>>>> This would be the first of three fixes:
>>>> 
>>>> Fix 1)  The patch above removes test_gamma and uses some weirdness in the 
>>>> VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add 
>>>> test_{product,fastdebug,debug} targets
>>> 
>>> This logic is not suitable:
>>> 
>>> 541 # Testing the built JVM
>>> 542 ifeq ($(JAVA_HOME),)
>>> 543   RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java 
>>> -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) 
>>> -Dsun.java.launcher=gamma
>>> 544 else
>>> 545   RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server 
>>> -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma
>>> 546 endif
>>> 
>>> I have JAVA_HOME set in my environment for use by other tools/scripts and 
>>> it points at JDK7. The existing logic does not use my environments 
>>> JAVA_HOME setting so neither should the revised logic!
>> 
>> That's not entirely correct.  test_gamma uses your JAVA_HOME setting:
> 
> This is so confusing. Our makefiles are an abomination!

I couldn't agree more.

> 
> So this all started because the makefile has:
> 
> JAVA_HOME=$(ABS_BOOTDIR)
> 
> which was flagged as wrong because gamma would run in the boot JDK. But now 
> it seems the make variable JAVA_HOME is irrelevant anyway because the 
> test_gamma script will use the JAVA_HOME environment variable.
> 
> So how did the boot JDK come back into this???
> 
>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>  export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64
>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>  ./test_gamma
>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre
>> 
>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>  export JAVA_HOME=/foo
>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>  ./test_gamma
>> JAVA_HOME must point to a 64-bit OpenJDK.
>> 
>> And here comes this little snippet into play:
>> 
>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR)
>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR)
>> 
>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have 
>> a JAVA_HOME set.
> 
> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is 
> this BOOTDIR value being used? There is no use of it in 
> http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it 
> pre-existing ??

I talked to John Coomes about that yesterday and we can remove that line.  
ABS_BOOTDIR is only used by Windows.

-- Chris

> 
> Thanks,
> David
> 
>> I have added this logic so that users can control what JDK is used when 
>> running the test.  In fact they should use ALT_JDK_IMPORT_PATH if they want 
>> to control that.
>> 
>>> 
>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that 
>>> environment variable?
>> 
>> It's the odd logic in os::jvm_path guarded by 
>> Arguments::created_by_gamma_launcher().  A clean-up of that logic would be 
>> part of Fix 3.
>> 
>>> 
>>> I still have concerns over what JDK_IMPORT_PATH will point to for different 
>>> JDK builders.
>> 
>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR.  Since most people don't want 
>> to export their libjvm into a JDK we have to use JDK_IMPORT_PATH.  We could 
>> add some logic that checks if JDK_IMAGE_DIR exists and use that one.
>> 
>> -- Chris
>> 
>>> 
>>> And this addition still makes no sense to me:
>>> 
>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR)
>>> 
>>> Why do you need to add BOOTDIR to the MAKE_ARGS?
>>> 
>>> David
>>> 
>>> 
>>>> Fix 2)  Remove gamma and all the ugly code that comes with it (copies of 
>>>> the jdk launcher in

Re: RFR (S): 8006965: test_gamma should run with import JDK

[Christian Thalinger]

On Feb 26, 2013, at 6:09 PM, Christian Thalinger 
 wrote:

> 
> On Feb 25, 2013, at 11:24 PM, David Holmes  wrote:
> 
>> On 26/02/2013 4:42 AM, Christian Thalinger wrote:
>>> On Feb 24, 2013, at 2:54 PM, David Holmes  wrote:
>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote:
>>>>> I talked to a lot of people about this today.  What we really want is to 
>>>>> not run tests when we build.  Mikael and I were looking into how we could 
>>>>> do that without gamma and there is a way:
>>>>> 
>>>>> http://cr.openjdk.java.net/~twisti/8006965/
>>>>> 
>>>>> This would be the first of three fixes:
>>>>> 
>>>>> Fix 1)  The patch above removes test_gamma and uses some weirdness in the 
>>>>> VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add 
>>>>> test_{product,fastdebug,debug} targets
>>>> 
>>>> This logic is not suitable:
>>>> 
>>>> 541 # Testing the built JVM
>>>> 542 ifeq ($(JAVA_HOME),)
>>>> 543   RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java 
>>>> -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) 
>>>> -Dsun.java.launcher=gamma
>>>> 544 else
>>>> 545   RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server 
>>>> -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma
>>>> 546 endif
>>>> 
>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and 
>>>> it points at JDK7. The existing logic does not use my environments 
>>>> JAVA_HOME setting so neither should the revised logic!
>>> 
>>> That's not entirely correct.  test_gamma uses your JAVA_HOME setting:
>> 
>> This is so confusing. Our makefiles are an abomination!
> 
> I couldn't agree more.
> 
>> 
>> So this all started because the makefile has:
>> 
>> JAVA_HOME=$(ABS_BOOTDIR)
>> 
>> which was flagged as wrong because gamma would run in the boot JDK. But now 
>> it seems the make variable JAVA_HOME is irrelevant anyway because the 
>> test_gamma script will use the JAVA_HOME environment variable.
>> 
>> So how did the boot JDK come back into this???
>> 
>>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>>  export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64
>>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>>  ./test_gamma
>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre
>>> 
>>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>>  export JAVA_HOME=/foo
>>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>>  ./test_gamma
>>> JAVA_HOME must point to a 64-bit OpenJDK.
>>> 
>>> And here comes this little snippet into play:
>>> 
>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR)
>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR)
>>> 
>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have 
>>> a JAVA_HOME set.
>> 
>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is 
>> this BOOTDIR value being used? There is no use of it in 
>> http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it 
>> pre-existing ??
> 
> I talked to John Coomes about that yesterday and we can remove that line.  
> ABS_BOOTDIR is only used by Windows.

Btw. I've updated the webrev.  I think we can also remove the -server switch 
from the run command line because we point the VM to the libjvm anyway.  How 
about this change?

-- Chris

> 
> -- Chris
> 
>> 
>> Thanks,
>> David
>> 
>>> I have added this logic so that users can control what JDK is used when 
>>> running the test.  In fact they should use ALT_JDK_IMPORT_PATH if they want 
>>> to control that.
>>> 
>>>> 
>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read 
>>>> that environment variable?
>>> 
>>> It's the odd logic in os::jvm_path guarded by 
>>> Arguments::created_by_gamma_launcher().  A clean-up of that logic would be 
>>> part of Fix 3.
>>> 
>>>> 
>>>> I still have concerns over what JDK_IMPORT_PATH will point to for 
>>>> different JDK builders.
>>> 
>>> I

Re: RFR (S): 8006965: test_gamma should run with import JDK

[Christian Thalinger]

On Feb 26, 2013, at 6:09 PM, Christian Thalinger 
 wrote:

> 
> On Feb 25, 2013, at 11:24 PM, David Holmes  wrote:
> 
>> On 26/02/2013 4:42 AM, Christian Thalinger wrote:
>>> On Feb 24, 2013, at 2:54 PM, David Holmes  wrote:
>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote:
>>>>> I talked to a lot of people about this today.  What we really want is to 
>>>>> not run tests when we build.  Mikael and I were looking into how we could 
>>>>> do that without gamma and there is a way:
>>>>> 
>>>>> http://cr.openjdk.java.net/~twisti/8006965/
>>>>> 
>>>>> This would be the first of three fixes:
>>>>> 
>>>>> Fix 1)  The patch above removes test_gamma and uses some weirdness in the 
>>>>> VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add 
>>>>> test_{product,fastdebug,debug} targets
>>>> 
>>>> This logic is not suitable:
>>>> 
>>>> 541 # Testing the built JVM
>>>> 542 ifeq ($(JAVA_HOME),)
>>>> 543   RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java 
>>>> -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) 
>>>> -Dsun.java.launcher=gamma
>>>> 544 else
>>>> 545   RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server 
>>>> -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma
>>>> 546 endif
>>>> 
>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and 
>>>> it points at JDK7. The existing logic does not use my environments 
>>>> JAVA_HOME setting so neither should the revised logic!
>>> 
>>> That's not entirely correct.  test_gamma uses your JAVA_HOME setting:
>> 
>> This is so confusing. Our makefiles are an abomination!
> 
> I couldn't agree more.
> 
>> 
>> So this all started because the makefile has:
>> 
>> JAVA_HOME=$(ABS_BOOTDIR)
>> 
>> which was flagged as wrong because gamma would run in the boot JDK. But now 
>> it seems the make variable JAVA_HOME is irrelevant anyway because the 
>> test_gamma script will use the JAVA_HOME environment variable.
>> 
>> So how did the boot JDK come back into this???
>> 
>>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>>  export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64
>>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>>  ./test_gamma
>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre
>>> 
>>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>>  export JAVA_HOME=/foo
>>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>>  ./test_gamma
>>> JAVA_HOME must point to a 64-bit OpenJDK.
>>> 
>>> And here comes this little snippet into play:
>>> 
>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR)
>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR)
>>> 
>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have 
>>> a JAVA_HOME set.
>> 
>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is 
>> this BOOTDIR value being used?

Ha!  I can remember.  It's used by jmvti.make (implicitly).  The logic in 
rules.make is:

ifdef ALT_BOOTDIR

COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac

else

ifdef BOOTDIR

COMPILE.JAVAC = $(BOOTDIR)/bin/javac

else

ifdef JAVA_HOME
else

endif
endif
endif

BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set 
to ABS_BOOTDIR).

This all sucks and needs to be replaced by something completely different.  
Soon.

-- Chris

>>  There is no use of it in 
>> http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it 
>> pre-existing ??
> 
> I talked to John Coomes about that yesterday and we can remove that line.  
> ABS_BOOTDIR is only used by Windows.
> 
> -- Chris
> 
>> 
>> Thanks,
>> David
>> 
>>> I have added this logic so that users can control what JDK is used when 
>>> running the test.  In fact they should use ALT_JDK_IMPORT_PATH if they want 
>>> to control that.
>>> 
>>>> 
>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read 
>>>> that environment variable?
>>> 
>>> It's the odd logic in os::jvm_path guarded by 
>>> Arguments::created_by_gamma_launc

Re: RFR (S): 8006965: test_gamma should run with import JDK

[Christian Thalinger]

On Mar 13, 2013, at 4:44 PM, Christian Thalinger 
 wrote:

> 
> On Feb 26, 2013, at 6:09 PM, Christian Thalinger 
>  wrote:
> 
>> 
>> On Feb 25, 2013, at 11:24 PM, David Holmes  wrote:
>> 
>>> On 26/02/2013 4:42 AM, Christian Thalinger wrote:
>>>> On Feb 24, 2013, at 2:54 PM, David Holmes  wrote:
>>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote:
>>>>>> I talked to a lot of people about this today.  What we really want is to 
>>>>>> not run tests when we build.  Mikael and I were looking into how we 
>>>>>> could do that without gamma and there is a way:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~twisti/8006965/
>>>>>> 
>>>>>> This would be the first of three fixes:
>>>>>> 
>>>>>> Fix 1)  The patch above removes test_gamma and uses some weirdness in 
>>>>>> the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add 
>>>>>> test_{product,fastdebug,debug} targets
>>>>> 
>>>>> This logic is not suitable:
>>>>> 
>>>>> 541 # Testing the built JVM
>>>>> 542 ifeq ($(JAVA_HOME),)
>>>>> 543   RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java 
>>>>> -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) 
>>>>> -Dsun.java.launcher=gamma
>>>>> 544 else
>>>>> 545   RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server 
>>>>> -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma
>>>>> 546 endif
>>>>> 
>>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and 
>>>>> it points at JDK7. The existing logic does not use my environments 
>>>>> JAVA_HOME setting so neither should the revised logic!
>>>> 
>>>> That's not entirely correct.  test_gamma uses your JAVA_HOME setting:
>>> 
>>> This is so confusing. Our makefiles are an abomination!
>> 
>> I couldn't agree more.
>> 
>>> 
>>> So this all started because the makefile has:
>>> 
>>> JAVA_HOME=$(ABS_BOOTDIR)
>>> 
>>> which was flagged as wrong because gamma would run in the boot JDK. But now 
>>> it seems the make variable JAVA_HOME is irrelevant anyway because the 
>>> test_gamma script will use the JAVA_HOME environment variable.
>>> 
>>> So how did the boot JDK come back into this???
>>> 
>>>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>>>  export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64
>>>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>>>  ./test_gamma
>>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre
>>>> 
>>>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>>>  export JAVA_HOME=/foo
>>>> cthaling@sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$
>>>>  ./test_gamma
>>>> JAVA_HOME must point to a 64-bit OpenJDK.
>>>> 
>>>> And here comes this little snippet into play:
>>>> 
>>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR)
>>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR)
>>>> 
>>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you 
>>>> have a JAVA_HOME set.
>>> 
>>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is 
>>> this BOOTDIR value being used?
> 
> Ha!  I can remember.  It's used by jmvti.make (implicitly).  The logic in 
> rules.make is:
> 
> ifdef ALT_BOOTDIR
> 
> COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac
> 
> else
> 
> ifdef BOOTDIR
> 
> COMPILE.JAVAC = $(BOOTDIR)/bin/javac
> 
> else
> 
> ifdef JAVA_HOME
> else
> 
> endif
> endif
> endif
> 
> BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set 
> to ABS_BOOTDIR).

Back to my favorite review these days :-)  I put the BOOTDIR setting back 
because we need it.

Any reviewers who approve or veto pushing this change?

-- Chris

> 
> This all sucks and needs to be replaced by something completely different.  
> Soon.
> 
> -- Chris
> 
>>> There is no use of it in 
>>> http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it 
>>> pre-existing ??
>>

RFR (XXS): 8011678: test/Makefile should pick up JT_HOME environment variable

[Christian Thalinger]

http://cr.openjdk.java.net/~twisti/8011678

8011678: test/Makefile should pick up JT_HOME environment variable
Reviewed-by:

The JT_HOME can only be overridden by a make argument or JPRT_JTREG_HOME.  
Picking up the JT_HOME environment variable would be helpful.

test/Makefile

Re: RFR (XXS): 8011678: test/Makefile should pick up JT_HOME environment variable

[Christian Thalinger]

After checking the OpenJDK census it seems that only Vladimir is an official 
reviewer.  But that's just the official part.  Thanks for the reviews!

-- Chris

On Apr 6, 2013, at 11:58 PM, Mike Duigou  wrote:

> This looks good to me. I will make the same change in the jdk/test/makefile 
> for when it is invoked directly.
> 
> There is also an outstanding issue to add a --with-jtreg option to the 
> configure script:
> 
> JDK-8007129 build-infra Add configure --with-jtreg option for location of 
> JTREG home directory.
> 
> Mike
> 
> On Apr 6 2013, at 21:39 , Christian Thalinger wrote:
> 
>> http://cr.openjdk.java.net/~twisti/8011678
>> 
>> 8011678: test/Makefile should pick up JT_HOME environment variable
>> Reviewed-by:
>> 
>> The JT_HOME can only be overridden by a make argument or JPRT_JTREG_HOME.  
>> Picking up the JT_HOME environment variable would be helpful.
>> 
>> test/Makefile
>> 
> 

RFR (S): 7172922: export_ makefile targets do not work unless all supported variants are built

[Christian Thalinger]

http://cr.openjdk.java.net/~twisti/7172922

7172922: export_ makefile targets do not work unless all supported variants are 
built
Reviewed-by:

GEN_DIR can be overwritten by other configurations if multiple JVM_VARIANT_*s 
are defined. The fix is to use the *_BASE_DIRs directly to install the correct 
files.

make/Makefile

Re: RFR (S): 7172922: export_ makefile targets do not work unless all supported variants are built

[Christian Thalinger]

On Apr 12, 2013, at 5:10 PM, David Holmes  wrote:

> Hi Chris,
> 
> On 13/04/2013 4:58 AM, Christian Thalinger wrote:
>> http://cr.openjdk.java.net/~twisti/7172922
>> 
>> 7172922: export_ makefile targets do not work unless all supported variants 
>> are built
>> Reviewed-by:
>> 
>> GEN_DIR can be overwritten by other configurations if multiple 
>> JVM_VARIANT_*s are defined. The fix is to use the *_BASE_DIRs directly to 
>> install the correct files.
>> 
>> make/Makefile
> 
> This looks like a simple temporary solution - thanks.

Yes, it's not perfect but good enough for now.

> 
> More long term I hope we should be able to generate the set of targets based 
> on the selected JVM_VARIANTS, without needing all those duplicated blocks.
> 
> One query with the current situation: why doesn't MISC_DIR cause us a 
> problem? It would seem to have the same issue as GEN_DIR. ???

MISC_DIR has the same problem but I didn't want to mess with Windows.

How about this one?

http://cr.openjdk.java.net/~twisti/7172922

-- Chris

> 
> Thanks,
> David
> 

Re: RFR (S): 7172922: export_ makefile targets do not work unless all supported variants are built

[Christian Thalinger]

On Apr 14, 2013, at 4:39 PM, David Holmes  wrote:

> Hi Chris,
> 
> On 14/04/2013 2:03 PM, Christian Thalinger wrote:
>> 
>> On Apr 12, 2013, at 5:10 PM, David Holmes  wrote:
>> 
>>> Hi Chris,
>>> 
>>> On 13/04/2013 4:58 AM, Christian Thalinger wrote:
>>>> http://cr.openjdk.java.net/~twisti/7172922
>>>> 
>>>> 7172922: export_ makefile targets do not work unless all supported 
>>>> variants are built
>>>> Reviewed-by:
>>>> 
>>>> GEN_DIR can be overwritten by other configurations if multiple 
>>>> JVM_VARIANT_*s are defined. The fix is to use the *_BASE_DIRs directly to 
>>>> install the correct files.
>>>> 
>>>> make/Makefile
>>> 
>>> This looks like a simple temporary solution - thanks.
>> 
>> Yes, it's not perfect but good enough for now.
>> 
>>> 
>>> More long term I hope we should be able to generate the set of targets 
>>> based on the selected JVM_VARIANTS, without needing all those duplicated 
>>> blocks.
>>> 
>>> One query with the current situation: why doesn't MISC_DIR cause us a 
>>> problem? It would seem to have the same issue as GEN_DIR. ???
>> 
>> MISC_DIR has the same problem but I didn't want to mess with Windows.
>> 
>> How about this one?
>> 
>> http://cr.openjdk.java.net/~twisti/7172922
> 
> I like the addition simplification of getting rid of BASE_DIR and MISC_DIR.
> 
> However I think you still need conditionals for Windows otherwise this:
> 
> 315 $(EXPORT_JRE_BIN_DIR)/%.diz:$(C2_DIR)/%.diz
> 316 $(install-file)
> 
> for example, is going to be executed for all platforms and dump the diz files 
> into the bin directory.

Only if a $(EXPORT_JRE_BIN_DIR)/*.diz file is on the EXPORT_LIST.

-- Chris

> 
> David
> -
> 
>> -- Chris
>> 
>>> 
>>> Thanks,
>>> David
>>> 
>> 

Re: RFR (S): 7172922: export_ makefile targets do not work unless all supported variants are built

[Christian Thalinger]

On Apr 14, 2013, at 9:54 PM, David Holmes  wrote:

> On 15/04/2013 2:36 PM, Christian Thalinger wrote:
>> 
>> On Apr 14, 2013, at 4:39 PM, David Holmes  wrote:
>> 
>>> Hi Chris,
>>> 
>>> On 14/04/2013 2:03 PM, Christian Thalinger wrote:
>>>> 
>>>> On Apr 12, 2013, at 5:10 PM, David Holmes  wrote:
>>>> 
>>>>> Hi Chris,
>>>>> 
>>>>> On 13/04/2013 4:58 AM, Christian Thalinger wrote:
>>>>>> http://cr.openjdk.java.net/~twisti/7172922
>>>>>> 
>>>>>> 7172922: export_ makefile targets do not work unless all supported 
>>>>>> variants are built
>>>>>> Reviewed-by:
>>>>>> 
>>>>>> GEN_DIR can be overwritten by other configurations if multiple 
>>>>>> JVM_VARIANT_*s are defined. The fix is to use the *_BASE_DIRs directly 
>>>>>> to install the correct files.
>>>>>> 
>>>>>> make/Makefile
>>>>> 
>>>>> This looks like a simple temporary solution - thanks.
>>>> 
>>>> Yes, it's not perfect but good enough for now.
>>>> 
>>>>> 
>>>>> More long term I hope we should be able to generate the set of targets 
>>>>> based on the selected JVM_VARIANTS, without needing all those duplicated 
>>>>> blocks.
>>>>> 
>>>>> One query with the current situation: why doesn't MISC_DIR cause us a 
>>>>> problem? It would seem to have the same issue as GEN_DIR. ???
>>>> 
>>>> MISC_DIR has the same problem but I didn't want to mess with Windows.
>>>> 
>>>> How about this one?
>>>> 
>>>> http://cr.openjdk.java.net/~twisti/7172922
>>> 
>>> I like the addition simplification of getting rid of BASE_DIR and MISC_DIR.
>>> 
>>> However I think you still need conditionals for Windows otherwise this:
>>> 
>>> 315 $(EXPORT_JRE_BIN_DIR)/%.diz:$(C2_DIR)/%.diz
>>> 316 $(install-file)
>>> 
>>> for example, is going to be executed for all platforms and dump the diz 
>>> files into the bin directory.
>> 
>> Only if a $(EXPORT_JRE_BIN_DIR)/*.diz file is on the EXPORT_LIST.
> 
> Oops! My bad.
> 
> I still think I prefer seeing platform specific targets in platform specific 
> conditionals, rather than using comments.

I don't have a strong opinion about this.  Will add the ifdefs tomorrow.

-- Chris

> But if we can macrofy this as the next step (different CR) then that can be 
> handled once within the macro.
> 
> Thanks,
> David
> 
>> -- Chris
>> 
>>> 
>>> David
>>> -
>>> 
>>>> -- Chris
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> David
>>>>> 
>>>> 
>> 

Re: RFR (S): 7172922: export_ makefile targets do not work unless all supported variants are built

[Christian Thalinger]

On Apr 14, 2013, at 10:14 PM, David Holmes  wrote:

> On 15/04/2013 2:56 PM, Christian Thalinger wrote:
>> 
>> On Apr 14, 2013, at 9:54 PM, David Holmes  wrote:
>> 
>>> On 15/04/2013 2:36 PM, Christian Thalinger wrote:
>>>> 
>>>> On Apr 14, 2013, at 4:39 PM, David Holmes  wrote:
>>>> 
>>>>> Hi Chris,
>>>>> 
>>>>> On 14/04/2013 2:03 PM, Christian Thalinger wrote:
>>>>>> 
>>>>>> On Apr 12, 2013, at 5:10 PM, David Holmes  
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi Chris,
>>>>>>> 
>>>>>>> On 13/04/2013 4:58 AM, Christian Thalinger wrote:
>>>>>>>> http://cr.openjdk.java.net/~twisti/7172922
>>>>>>>> 
>>>>>>>> 7172922: export_ makefile targets do not work unless all supported 
>>>>>>>> variants are built
>>>>>>>> Reviewed-by:
>>>>>>>> 
>>>>>>>> GEN_DIR can be overwritten by other configurations if multiple 
>>>>>>>> JVM_VARIANT_*s are defined. The fix is to use the *_BASE_DIRs directly 
>>>>>>>> to install the correct files.
>>>>>>>> 
>>>>>>>> make/Makefile
>>>>>>> 
>>>>>>> This looks like a simple temporary solution - thanks.
>>>>>> 
>>>>>> Yes, it's not perfect but good enough for now.
>>>>>> 
>>>>>>> 
>>>>>>> More long term I hope we should be able to generate the set of targets 
>>>>>>> based on the selected JVM_VARIANTS, without needing all those 
>>>>>>> duplicated blocks.
>>>>>>> 
>>>>>>> One query with the current situation: why doesn't MISC_DIR cause us a 
>>>>>>> problem? It would seem to have the same issue as GEN_DIR. ???
>>>>>> 
>>>>>> MISC_DIR has the same problem but I didn't want to mess with Windows.
>>>>>> 
>>>>>> How about this one?
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~twisti/7172922
>>>>> 
>>>>> I like the addition simplification of getting rid of BASE_DIR and 
>>>>> MISC_DIR.
>>>>> 
>>>>> However I think you still need conditionals for Windows otherwise this:
>>>>> 
>>>>> 315 $(EXPORT_JRE_BIN_DIR)/%.diz:$(C2_DIR)/%.diz
>>>>> 316 $(install-file)
>>>>> 
>>>>> for example, is going to be executed for all platforms and dump the diz 
>>>>> files into the bin directory.
>>>> 
>>>> Only if a $(EXPORT_JRE_BIN_DIR)/*.diz file is on the EXPORT_LIST.
>>> 
>>> Oops! My bad.
>>> 
>>> I still think I prefer seeing platform specific targets in platform 
>>> specific conditionals, rather than using comments.
>> 
>> I don't have a strong opinion about this.  Will add the ifdefs tomorrow.
> 
> Don't bother unless someone else feels strongly about it. (I don't want to 
> have to re-review :) )

Even better :-)  If there are no objections tomorrow I will push it.  Thanks 
for reviewing.

-- Chris

> 
> David
> -
> 
>> -- Chris
>> 
>>> But if we can macrofy this as the next step (different CR) then that can be 
>>> handled once within the macro.
>>> 
>>> Thanks,
>>> David
>>> 
>>>> -- Chris
>>>> 
>>>>> 
>>>>> David
>>>>> -
>>>>> 
>>>>>> -- Chris
>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> David
>>>>>>> 
>>>>>> 
>>>> 
>> 

RFR (M): 8008772: remove gamma launcher

[Christian Thalinger]

http://cr.openjdk.java.net/~twisti/8008772/

8008772: remove gamma launcher
Reviewed-by:

Remove linking the gamma launcher and it's associated source files.

make/Makefile
make/bsd/makefiles/launcher.make
make/bsd/makefiles/vm.make
make/hotspot.script
make/linux/makefiles/launcher.make
make/linux/makefiles/vm.make
make/solaris/makefiles/launcher.make
make/solaris/makefiles/vm.make
make/windows/makefiles/debug.make
make/windows/makefiles/fastdebug.make
make/windows/makefiles/launcher.make
make/windows/makefiles/product.make
make/windows/makefiles/projectcreator.make
make/windows/projectfiles/common/Makefile
src/os/posix/launcher/java_md.c
src/os/posix/launcher/java_md.h
src/os/posix/launcher/launcher.script
src/os/windows/launcher/java_md.c
src/os/windows/launcher/java_md.h
src/share/tools/launcher/java.c
src/share/tools/launcher/java.h
src/share/tools/launcher/jli_util.c
src/share/tools/launcher/jli_util.h
src/share/tools/launcher/wildcard.c
src/share/tools/launcher/wildcard.h

This change removes the duplicated java launcher files (which were subject to 
bit-rot) and modifies the hotspot script to pick up the libjvm in the current 
build directory.

The modified hotspot script works with GDB and DBX:

cthal...@intelsdv03.us.oracle.com:/export/twisti/build/8008772/build/linux_i486_compiler2/debug$
 ./hotspot -gdb -version
GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
.
Missing separate debuginfo for 
/net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b86/binaries/linux-i586/bin/java
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install 
/usr/lib/debug/.build-id/5e/85e6dced3b388a7b0e50630242f4c7ee5e31a3.debug
Function "JNI_CreateJavaVM" not defined.
Breakpoint 1 (JNI_CreateJavaVM) pending.
[Thread debugging using libthread_db enabled]
[New Thread 0xf7fe4b70 (LWP 13459)]
[Switching to Thread 0xf7fe4b70 (LWP 13459)]

Breakpoint 1, JNI_CreateJavaVM (vm=0xf7fe4378, penv=0xf7fe4374, args=0xf7fe4364)
at 
/net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/prims/jni.cpp:5062
5062  jint result = JNI_ERR;
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.7.el6.i686
(gdb) break CompileBroker::compile_method
Breakpoint 2 at 0xaef852: file 
/net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/compiler/compileBroker.cpp,
 line 1205.
(gdb) c
Continuing.
[New Thread 0xf7f93b70 (LWP 13460)]
[New Thread 0xb4398b70 (LWP 13461)]
[New Thread 0xb41ffb70 (LWP 13462)]
[New Thread 0xb3effb70 (LWP 13463)]
[New Thread 0xb3cffb70 (LWP 13464)]
[New Thread 0xb3affb70 (LWP 13465)]
[New Thread 0xb38ffb70 (LWP 13466)]
[New Thread 0xb36ffb70 (LWP 13467)]
[New Thread 0xb34ffb70 (LWP 13468)]
[New Thread 0xb32ffb70 (LWP 13469)]
[New Thread 0xb30ffb70 (LWP 13470)]
[New Thread 0xb2effb70 (LWP 13471)]
[New Thread 0xb2cffb70 (LWP 13472)]
[New Thread 0xaf8e8b70 (LWP 13473)]
[New Thread 0xb4156b70 (LWP 13474)]
[New Thread 0xb3c7eb70 (LWP 13475)]
[New Thread 0xb3a7eb70 (LWP 13476)]
[New Thread 0xaeeffb70 (LWP 13477)]
[New Thread 0xaecffb70 (LWP 13478)]
[New Thread 0xb387eb70 (LWP 13479)]
[New Thread 0xaeaffb70 (LWP 13480)]
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b86)
Java HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed mode)
[Thread 0xaeaffb70 (LWP 13480) exited]
[Thread 0xb3a7eb70 (LWP 13476) exited]
[Thread 0xaf8e8b70 (LWP 13473) exited]
[Thread 0xf7fe4b70 (LWP 13459) exited]
[Thread 0xb2cffb70 (LWP 13472) exited]
[Thread 0xb2effb70 (LWP 13471) exited]
[Thread 0xaecffb70 (LWP 13478) exited]
[Thread 0xb387eb70 (LWP 13479) exited]
[Thread 0xaeeffb70 (LWP 13477) exited]
[Thread 0xb3c7eb70 (LWP 13475) exited]
[Thread 0xb4156b70 (LWP 13474) exited]
[Thread 0xb32ffb70 (LWP 13469) exited]
[Thread 0xb34ffb70 (LWP 13468) exited]
[Thread 0xb36ffb70 (LWP 13467) exited]
[Thread 0xb38ffb70 (LWP 13466) exited]
[Thread 0xb3affb70 (LWP 13465) exited]
[Thread 0xb3cffb70 (LWP 13464) exited]
[Thread 0xb3effb70 (LWP 13463) exited]
[Thread 0xb41ffb70 (LWP 13462) exited]
[Thread 0xb4398b70 (LWP 13461) exited]
[Thread 0xf7f93b70 (LWP 13460) exited]
[Thread 0xb30ffb70 (LWP 13470) exited]

Program exited normally.
(gdb) 


cthaling@intelsdv01:/export/twisti/build/8008772/build/solaris_i486_compiler2/debug$
 /bin/bash ./hotspot -dbx -version
dbx: warning: using the alternate init file: /home/cthaling/.dbxrc
Reading java
Reading ld.so.1
Reading libjli.so
Reading libthread.so.1
Reading libdl.so.1
Reading libc.so.1
Reading libjvm.so
Loaded loadobject: 
/export/twisti/build/8008772/build/solaris_i486_compiler2/debug/libjvm.so
Running: java -Dsun.java